Мне 16 лет. Какой язык выбрать?

[nikedeforest]

Специальность моя САПР, т.е. я думаю это все объясняет, но на всякий случай поясняю. Наша кафедра выпускает (теоретически ) специалистов САПР (системы автоматизированного проектирования). Специальность широка, но неотделима от  программирования в любом случае.  Образно говоря и в кратце, простым языком, специалисты САПР - это инженеры-программисты. В дальнейшем кто-то станет инженером (к примеру ПАХТ-процессы и аппараты химических технологий), кто-то программистом (базы данных компьютерная графика, сети и прочее), а кто-то  инженером-программистом (все предыдущее плюс применение Выч. мата, ТАУ, оптимизации, и т.д.).
 Альф, дело втом, что на специальностях, где программирование не профелирующий предмет до ООП обычно не доходят и язык там чаще всего один изучают (не обязательно Паскаль, где-то и С). На изучение языка программирования, чаще всего на таких специальностях выделяют один семестр (н-р в моем ВУЗе), там как раз
 

отчитали обязаловку, приняли формально зачеты-экзамены - и до свидания.

ЗЫ: Забыл упомянуть, что нас также обучали SQL и теории БД. Выделили на это 1 семестр, поэтому я знаком с основами, но зато если самостоятельно поднимать эту область, то уже будет легче, также сейчас изучаю "Сети ЭВМ и телекоммуникации", схемотехника. До этого изучал электротехника, физика, выч. мат (численные методы), мат. анализ, теория вероятности, дискретная  математика, оптимизация (до сих пор), компьютерная графика и т.д. Плюс еще  в каждом семестре по одному-два левому предмету типа философии, истории, политологии, экономики, ин. яз. и пр. Я думаю, что по списку предметов как раз видно, что и инженеры и программитсы.

[Dimyan]

=)) тока увидел эту тему =))
а мне 22 и я немогу придумать чего выпить =))

[Mitnick]

Доброе время суток всем !

Хотел бы высказаться насчет того, устарело ли программирование под Дисковую...
Мне 14 лет и программированием занимаюсь уже больше года. Всё это время занимался программированием под ДОС (Pascal, c++,c,BASIC) и для интернета(PHP,JavaScript) сам лично не считаю, что потратил время зря, занимаясь BASIC'ом или Pascal'ем. Если следовать такому принципу, как некоторые здесь предлагали (типа начать сразу с Object Pascal или Visual Basic), то почему бы не выкинуть из школьного курса той же физики механику, оптику и т.д., а оставить только ядерную физику ? Ведь сами понимаете, что из этого получиться. Я знаю людей, которые могут написать программу для Windows на Visual Basic'e, но абсолютно не представляют даже, что такое WinAPI и чем они по сути занимаются , и как написать на BASIC'e что-то для  ДОС. Поэтому лично я думаю, что начинать надо с самого начала. то есть писать под  консоль.

P.S.: Лично я начинал с С++ , хотя всем советую начать с Паскаль или Бейсик.

[Hottabych]

Начинать надо с Ассемблера. Если с него не начать, то потом труднее будет освоить.

[fevdokimov]

>Специально для обучения программированию Никлаус Вирт разработал язык Pascal. Правда, на сегодняшний
>день он устарел, поскольку ориентирован на структурное программирование. Однако его объектное
>расширение, например, Delphi, вполне подойдет.

Если говорить о продолжении линии Никлауса Вирта, то самые простые языки программирования для изучения и освоения хорошего стиля программирования это OBERON или Companent Pascal(Black Box).
Что касается Delphi, то это ответвление Pascal даже не стандартизировано, хотя по всем признакам входит в группу промышленных языков программирования.
   Вообще для выбора языка программирования почитайте историю развития языков.
С УВАЖЕНИЕМ.

[Alf]

Если говорить о продолжении линии Никлауса Вирта, то самые простые языки программирования для изучения и освоения хорошего стиля программирования это OBERON или Companent Pascal(Black Box).
Что касается Delphi, то это ответвление Pascal даже не стандартизировано, хотя по всем признакам входит в группу промышленных языков программирования.

Я полагаю, новичков в первую очередь интересует не абстрактное изучение теории, а обучение языку, знание которого позволит в дальнейшем использовать его на практике (в идеале - зарабатывать этим на жизнь). Боюсь, знание OBERON'а не слишком повысит шансы новоиспеченного программиста получить работу. А вот с неуклюжим, устаревшим по всем канонам C++ найдет работу запросто. Да и с Delphi не пропадет, ибо на сложившемся рынке труда в области IT мало кого интересует длинная череда цифр ISO, которой соответствует данная среда программирования, если уж ей пользуется достаточно большой круг программистов.

Вообще для выбора языка программирования почитайте историю развития языков.

Так и сделали. Взял для начала известный плакат O'Reilly (http://www.oreilly.com/news/graphics/prog_lang_poster.pdf)- ниасилил, много стрелок.

Затем поискал в Яндексе по ключевым словам "история языков программирования" - наткнулся на собственную же статью:


Кругом облом...

P.S. IMHO рекомендовать для выбора языка программирования руководствоваться историей их развития - все равно что на вопрос, какую микросхему лучше выбрать для данного применения, посоветовать изучить историю электроники, начиная с грозоотметчика Попова и вакуумных ламп. Познавательно, но неконструктивно.

[Dimka]

Что касается точки зрения преподавателей.

Через полгодика смогу поделиться впечатлениями от прочтения курса ООП. По поводу времени преподавания - 1 семестр, хотя под ООП понимается и анализ, и проектирование и программирование. Причём это профильный курс для программистов. Такое радовать не может. В официальной вузовской программе федеральный компонент ООП составляет всего 100 часов (всех видов занятий: лекций, лабораторных работ, практических занятий и т.п.). Мне выделено 220, из них аудиторных 68 часов (с точки зрения студента). Думаю, что курс ООП для нынешнего программиста также фундаментален, как и курс обычного (процедурного) программирования. В министерстве образования так не думают. Языки: C++ и UML.

Что касается дискуссии между Джоном и Alf'ом о том, с чего начать. Для себя решил в самом начале давать чистый стандартный C++ (в консоли), включая STL (но не с самого начала). Могу сказать, почему не хочу начинать с GUI. Потому что студенту, не знающему азов ООП (что такое объект, класс, событие, отношения) понятие объектов GUI придётся принимать, как тут уже Джон говорил, "на веру" - есть кнопка, есть окно и т.п., совершенно не понимая, что это такое и как этим пользоваться. Более того, не понимая, что такое экранная компонента (то же окно), он будет делать непреодолимые для себя ошибки (которые он не сможет самостоятельно исправить). Проверено на практике. Имхо, такое начало лучше всего отбивает желание учиться.

Вспоминаю, как лет 7 назад впервые взялся за Delphi после TP 7.0 под DOS (хотя объектами пользоваться уже научился), да ещё не зная архитектуры Windows. Формочка, кнопочка. Первый вопрос: а куда писать код, где этот цикл repeat ... until WantExit; ? Самый тот факт, что форма получает лишь события, а цикл получения событий скрыт от пользователя, до меня дошло лишь после изучения Turbo Vision, а затем знакомства с WinAPI.

Т.е. написать первую ГАРАНТИРОВАННО рабочую программу на C++ (не "Hello world!") с использованием GUI затруднительно. Здесь я не согласен с Alf'ом. НО! Лишь до тех пор, пока среда не станет такой, чтобы ей можно было доверять, чтобы невозможно было сделать ошибку внутри среды. Эту мысль надо пояснить.

Думаю, что главным понятием является язык, точнее домен понятий, в которых выражается какая-то предметная область. Пока среда (IDE типа VS или Delphi) на неверно размещённый компонент будет генерировать ошибки вида: "Syntax error: ....... line X", пока эта среда вообще будет требовать влезать в нутро ею сгенерированного кода, чтобы наполнить его содержанием, начинать с того, с чего предлагает Alf, не будет представляться возможным. Всякая ошибка должна быть выражена теми понятиями, которые образует среда. И ошибка должна выглядеть именно в том виде, в котором её можно исправить: "Компонент помещён в недопустимую область". И исправление ошибки должно быть выражено на том же уровне оперирования (перетащить этот компонент мышкой туда, куда надо). До тех пор, пока системы программирования будут на действия в графическом дизайнере генерировать возможно ошибочный код, они не образуют ту среду, в которой возможно начинать обучение на качественно ином уровне. Такой качественный переход в программировании близок, но пока ещё не наступил в полной мере.

Чур меня сразу окунать студента в MFC с его макросами или ATL. Конечно, есть множество библиотек поэлегантнее MFC (с точки зрения внешнего вида кода) и без COM-объектов, но мне кажется, что начинать надо с начала, и до освоения азов уже вовсю использовать то, что студент не понимает - путь ошибочный, порождающий программистов с мышлением: "если в справочнике не написано, то задача не решается", или в переложении на Delphi: "Если нет компоненты, то задача не решается."

После освоения азов думаю перейти к .NET - там уже и GUI будет. (Курс Java у нас в университете читается отдельно, поэтому этот язык и всё с ним связанное не рассматриваю).

[Olegator]

Что касается дискуссии между Джоном и Alf'ом о том, с чего начать. Для себя решил в самом начале давать чистый стандартный C++ (в консоли), включая STL (но не с самого начала). Могу сказать, почему не хочу начинать с GUI. Потому что студенту, не знающему азов ООП (что такое объект, класс, событие, отношения) понятие объектов GUI придётся принимать, как тут уже Джон говорил, "на веру" - есть кнопка, есть окно и т.п., совершенно не понимая, что это такое и как этим пользоваться. Более того, не понимая, что такое экранная компонента (то же окно), он будет делать непреодолимые для себя ошибки (которые он не сможет самостоятельно исправить). Проверено на практике. Имхо, такое начало лучше всего отбивает желание учиться.

Всё то, что ты здесь написал сводиться к одному принципу:
Поведение человека зависит только от обстоятельств. У человека нет свободной воли. И, чтобы человек начал поступать правильно, надо поставить его в правильные обстоятельства.
Конечно, многие, или может быть даже большинство, именно такие. А людей, которые поступают в жизни по своей свободной воле не зависимо от обстоятельств меньшинство. И возможно, что для студентов, которым ты всё это преподаёшь это наиболее оптимально.
Т.е. причины я здесь вижу только психологические.
В тех вещах, которые ты противопоставляешь, разницы с точки зрения изучения основ нет.
И там и там найдутся те, кто примет за веру, и те, кто полезет изучать. И там и там можно изучать объект, класс, событие, отношения.
В общем, препятствий технических нет. Есть только психологические.

[Dimka]

А людей, которые поступают в жизни по своей свободной воле не зависимо от обстоятельств меньшинство.

Попытаюсь переложить на практику - будет видно, как я эту фразу понял.

Если студент, не зная ничего, садится писать программу и получает непонятную ошибку: большинство бросит, а кто-то полезет выяснять. Рассмотрим подробнее последний случай. Он выяснит, что в такой-то строчке такой-то объект что-то там делает и т.п. НО! Прежде чем он это ПОЙМЁТ, он должен понять, что есть объект и пр.

Цель преподавания - не отбор тех 3-5 самых толковых, активных и интересующихся, которые захотят сами свернуть горы и разобраться. Цель - передача знаний, чтобы эти знания дошли даже до не очень способных троечников. Потому что в противном случае им не за что давать диплом. Получается вместо стандартной подготовки 40 человек, элитная подготовка 3-х в условиях, приближенных к боевым. Причём остальные 37 напишут вполне законную жалобу, что их плохо учат.

Как говорится, "Не-ет! На это я пойтить не могу!" (Лёлик, "Бриллиантовая рука")

Качество преподавания определяется как % положительных результатов проверки знаний студентов по окончании курса (причём положительных не для галочки, а в самом деле положительных). Я ж не претендентов на работу отбираю. Это разные области.

Особое внимание к тем, кому это нужно, помимо программы-минимума для всех - это отдельная история, к теме относящаяся косвенно.

[Alf]

...
Т.е. написать первую ГАРАНТИРОВАННО рабочую программу на C++ (не "Hello world!") с использованием GUI затруднительно. Здесь я не согласен с Alf'ом.

Сказать по правде, я бы и сам категорически не согласился с Alf'ом. При условии, конечно, если бы Alf выдал мнение, которое ему зачем-то приписали.

Во-первых, GUI (даже звучит как-то не очень прилично) не есть самоцель программирования. Это скорее неизбежное зло, которое вытекает из того, что пользователь желает иметь интерфейс для диалога с программой; более того, он желает иметь красивый интерфейс. И если есть способ избежать возни с рисованием кнопочек и окошечек, не следует ей пренебрегать. Не они составляют соль программирования. Хоть без них, повторюсь, зачастую никуда не деться. (Правда,мои любимые программы, над которыми я работал с особым удовольствием, запускаются из командной строки, признаюсь по секрету).

Во-вторых, GUI не есть синоним MFC, хотя многие почему-то ставят между ними знак тождества. С точки зрения парадигмы ООП графические (да и остальные) средства MFC - это скорее пародия на объектную библиотеку. Собрать в кучу низкоуровневые структуры и прилепить к ним функции для работы с ними, гордо назвав "методами" - еще не значит разработать объектно-ориентированное решение. И обучать сегодня программировать на C++ с использованием MFC - все равно что готовить специалистов по обработке данных на FoxPro для DOS. Ушел поезд, эти инструменты сослужили верную службу и остались в прошлом веке. Те, кто в свое время блестяще овладел ими и научился успешно бороться с их закидонами, еще протянут несколько лет на старых запасах. Учить этому новое поколение - значит потратить время на их оболванивание.

Кстати, очень показательна недавняя дискуссия по поводу своенравных радиокнопок. Чтобы заставить их правильно работать в MFC, нужно и первую кнопку в группе специально пометить, и порядок табуляции поменять... Пардон, это и есть ООП XXI-го века? Если да, то нуегонафих, уж лучше FORTRAN с перфокартами, там все логичнее.

[Olegator]

Если студент, не зная ничего, садится писать программу и получает непонятную ошибку: большинство бросит, а кто-то полезет выяснять. Рассмотрим подробнее последний случай. Он выяснит, что в такой-то строчке такой-то объект что-то там делает и т.п. НО! Прежде чем он это ПОЙМЁТ, он должен понять, что есть объект и п

В каком-нибудь turbo C++ он тоже ничего в начале знать не будет. Ты не понял:

Во-первых, GUI (даже звучит как-то не очень прилично) не есть самоцель программирования.

Т.е. как я понял Alf`а в VC++ также можно заставить студента написать свой собственный класс по работе с комплексными числами и использовать его в программе с графическим интерфейсом. И плюс к этому ты получишь студента который может работать используя современные способы написания программ. А в том же Turbo C++ можно запросто не зная ничего про написание класса передрать у других. Т.е. разницы на самом деле никакой. А согласно твоей логики следует, что если есть что-то готовое, то это исключает написание чего-то своего. А это не так. Ты стереотипно мыслишь.
Хотя я ещё сам в этом новичок. И может я не понял Alf`а. Так пускай он меня поправит.

[Dimka]

Т.е. как я понял Alf`а в VC++ также можно заставить студента написать свой собственный класс по работе с комплексными числами и использовать его в программе с графическим интерфейсом. И плюс к этому ты получишь студента который может работать используя современные способы написания программ. А в том же Turbo C++ можно запросто не зная ничего про написание класса передрать у других. Т.е. разницы на самом деле никакой. А согласно твоей логики следует, что если есть что-то готовое, то это исключает написание чего-то своего. А это не так. Ты стереотипно мыслишь.

Пардон, а кто говорил про Turbo C++? Тем паче, что он последних версий стандарта не поддерживает. Я не говорил точно. Вчера как раз VS .NET 2003 поставили для лабораторных работ в классах.

Я всего лишь хочу сказать, что начинать надо с самого простого и с минимального набора понятий.

То, что сейчас дизайнеры генерируют код, а потом приходится руками туда что-то добавлять, исправлять - можно переложить на времена DOS и более ранние. Программист писал код на языке высокого уровня, получал ассемблерный, и исправл его, делал ассемблерные вставки. Чтобы написать что-то дельное в таких условиях, без знания ассемблера не обойтись. Сейчас в принципе подобная картина, только на более высоком уровне. Вот когда средства разовьются до такой степени, когда не будет необходимости знать более низкий уровень, тогда уже можно сразу начинать учить с более высокого.