Я за этой темой слежу с самого начала.

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

Вы далеко отошли от заданной темы и переходите на оскорбления. Тема ведь была в том с чего начать. А перед началом нужно понимать, если человек на чистом энтузиазме начинает учить язык, то этот язык должен быть максимально прост и показателен.
Например, VB.
Я если его загнать в VC++ или заставить писать на Делфе базы данных (не говоря о есемблире) это энтузиазм быстро кончиться и человек попросту потеряет время и нервы.
Но если программирование подкрепляется экономическим эффектом (хотя бы в перспективе), то этот экономичный эффект сам определит язык на котором нужно писать для достижения поставленной цели.

YEAH!а ято касается с чего начать, то я начинал с Паскаля. Рзазумеется, не очень перспективно.
Но зато потом проще Дельфи идет, а это имхо намного интиереснее

я тоже с самого начала слежу за темой.
Сам я зарабатываю с 1996 администрением, и мне очень повезло, что сразу пришлось освоить и юникс (FreeBSD 2.1) и novell netware 3.11, и вскоре после того MacOS. Естественно и от винды не отвертелся )
Последние 2 года я перешел на программинг (Perl/php/c).

Современный программинг отличается от 10 лет назад как кролик от черепахи. Очень многое решает опыт работы с конкретными, назовем для простоты библиотеками (точное назвавние framework, но его просто так на русский не переведешь). То есть чтобы все делать, нужно _все_ знать, что не есть реально. Конечно, есть заведомо более простые пути - PHP, Java, поскольку под оные создано множество шаровых решений большинства возникающих задач, однако, чтобы эффективно использовать, нужно понимать.

Следовательно нужно (по аналогии с изучением иностранных языков), изучить что-то основополагающее, конечно лучше если оно еще и не совсем мертвое.
Вобщем-то C++ не самый худший вариант, но с учетом множества литературы лучше всего именно turbo pascal (object pascal). Тогда удастся легко перейти к Delphi и VB.
Так человек становится кодером. Программисту нужны еще знания - об этом дальше.

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

После этого уже можно стажироваться программистом.

Чтобы писать эффективные проги на C++, а уж тем более что-то риалтаймовое, нужно еще изучить устройство хотя-бы i8080 и i386. Как минимум, чтобы не задавать дурацкие вопросы )
Еще неплохой практикой будет попрограммить для синклера - поймете, почему ассемблер быстрей, и где есть смысл этим пользоваться.
Прграмминг на асме под винды/юникс на современной аппаратуре слишком заморочлив, и дает очень малый выигрыш в большинстве приложений, чтобы быть наглядным и полезным для обучения.

Вот, после всего этого можно куда угодно, в том числе и на жаву переходить.

Да, вообще все кроме турбопаскаля и синклера лучше делать на OpenSource - увидите много примеров кода.Если взять действительно хорошие примеры (mysql, mod_perl) - это лучше любого учебника.
Вообще Open Source код имеет очень существенные преимущества- он доступен, и разработчики не связаны временными рамками, поэтому могут чаще писать хорошо

Vetaliy Python - идеальный язык для обучения.

Это уж точно (сарказтически)... Отсутствующая типизация, отсутствие инкапсуляции, "ракообразная" ООП, никакой стардартизации, что приводит к хаотичности, например меня просто взбесило отсутствие абстрактного IO, что сильно ограничивает разработчика. Хотя и есть приятные вещи, но недостатков я увидел больше чем "приятностей". Так что я очень не рекомендую начинать с Питона, если не хотите привить себе плохие навыки программирования.

За Java и .NET будущее, по крайней мере в ближайшие лет 5-10, ИМХО.

А новичкам советую вначале выучить теорию, а то потом приходят "перцы" на собеседования и не знают даже что такое "полиморфизм".

ИМХО С с ассемблерными вставками являеться налучшим способом для системного программиста...конечно на *NIX'овых с асмовыми вставками геморой возникает, но в целом жить можно...

так нужно не жаву учить, а smalltalk и лисп.
Жава она совсем отдельная ветвь эволюции(?) ООП (это насчет плохих навыков).
И учить там особо нечего. Как я уже раньше заметил, сейчас не язык определяет, а технология. Хотя, все новье действительно вначале под жаву пишут, но пик интереса к жаве уже прошел.

Сейчас все больше заметна специализация, то есть на компилируемых языках пишут ядро, а интерфейс, как более изменчивая часть, не требующая риалтайма пишется на том же питоне.

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

IvanoBuloЭто плюс или в крайнем случае имеет свои положительные моменты.[/quote]
Ну без этого вообще жить нельзя...
И в чем же это проявляется?
Скажем так, не язык определяет "правильность" программирования, а программист.
Зачем начинать с заведомо более сложного языка? Чтобы "трахаться" с самим языком? Один объём программ на Java больше аналогичной программы на Python в разы!! (точно не помню, надо искать)

zyxmanСовершенно верно.

Позвольте узнать, а каким это образом Java превратилась в отдельную ветвь эволюций ООП? Отсутствием безобразного множественного наследования? Или тем что позволяет выйти на более уровень абстракции с помощью интерфейсов? Или тем что избавляет разработчиков от необходимости собственноручно прибирать за собой "мусор"? И где Вы в ней увидели плохие навыки?

Согласен, но любой "язык программирования", как вы называете я склонен считать "технологией программирования", потому как язык это не более чем синтаксис, а всё остальное что окружает язык - это технологии для создания программ на этом языке.
Если пик Java уже прошёл, так почему же на почти каждом мобильном телефоне присутствует эта "умирающая" Java? Почему серьёзные компании мира (http://www.ertico.com/partners/list_par.htm) выбрали именно Java-технологию для своих амбициозных планов (http://www.ertico.com/about_us/about_us.htm)? Или Вы рассуждаете о популярности технологий на основе того что вы привыкли видеть у себя на десктопах? Откройте глаза!

Попрошу не путать проблемно-ориентированные задачи с системно-ориентированными...

Всё бы Вам ядра писать а вот я на месте заказчика перед тем как пускать к программингу чего-либо "нового" лучше посмотрю, а нет ли уже того-же готового и отработаного, чтобы быстрее начать решать задачи бизнеса...

Добавлено спустя 15 минут, 24 секунды:

Без этого нельзя создать надёжную систему.

Если Вы сможете привести отличия между темплейт-методом и стратегией тогда можно будет говорить об этом дальше

Только от части, язык либо помогает избегать ошибок, либо способствует их появлению. Как бы не был хорош программист, он в первую очередь человек, а человеку свойственно ошибатся, этого никто не может избежать.

Несмотря на кол-во строк, разработка на Java или .NET больших систем в разы быстрее. А вот всякие мелкие утилитки я предпочитаю писать на Питоне.
Сложность задачи определяет инструмент, а не наоборот.

IvanoBulo
Отсутствующая типизация,
бред. это не так
отсутствие инкапсуляции,
тоже бред.
"ракообразная" ООП
ну поясните чтоли, что вы под этим понимаете.

А новичкам советую вначале выучить теорию, а то потом приходят "перцы" на собеседования и не знают даже что такое "полиморфизм".
а сами то знаете?

А как? Как понимать отсутствие типизации параметров метода, переменных?

Обоснуйте плиз. Я так понимаю, что если любое свойство экземпляра класса может быть изменено из другого класса, то этот класс не защищён, а значит инкапсуляции нет.

А Вы знаете ООП? Просто если б вы знали то таких вопросов не задавали.

знаю, не волнуйтесь

IvanoBulo
Как понимать отсутствие типизации параметров метода, переменных?
Советую почитать мануал или Гвидо ван Россума много нового узаете о python. В том числе и о типах. От того что программист не определяет типы явно еще не следует, что язык безтиповой. Python сам определяет согласованность типов.
Обоснуйте плиз. Я так понимаю, что если любое свойство экземпляра класса может быть изменено из другого класса, то этот класс не защищён, а значит инкапсуляции нет.
ну это от слабых знаний ООП и python'a. Во-первых, ООП вообще и инкапсуляция в частности не панацея и не догма. Более того для полей есть возможность определить property. Далее вы судя по всему не подозреваете о существовании такой вещи как паттерн Bridge. Советую с ним ознакомиться.

А Вы знаете ООП? Просто если б вы знали то таких вопросов не задавали.
ну дык а вы судя по всему крутой "знаток" раз делаете такие смелые заявления по отношению к языку, которого! судя по всему толком и не знаете. Ну так поясните нам что вы имели ввиду под словами "ракообразная" ООП . Или это безосновательные утверждения, [удалено]?

знаю, не волнуйтесь
вообще возникают сомнения. Не растолкуете нам, что это такое, а?

Не надо переходить на личности. vor

Вы ушли от темы. На чем учиться и в чем работать - вещи несколько разные.
И уж тем более не нужно здесь обсуждать, какой язык "лучше". Это вообще бессмысленный вопрос.

Хорошо, допустим, что вы считаете, что лучше сразу учиться именно тому языку, в котором придется работать.
Тогда все зависит от работы!

Есть задачи, для которых VC++ будет оставаться лучшим средством. Да и ассемблер всегда будет применяться.

vor
извиняюсь за несдержанность, накипело

Хорошо, допустим, что вы считаете, что лучше сразу учиться именно тому языку, в котором придется работать.
вся проблема в том, что большинство тех кто хочет обучиться программированию сами толком не знают чего они хотят. В таком случае скриптовые языки вроде Python'a самое оптимальное, имхо.

Есть задачи, для которых VC++ будет оставаться лучшим средством.
а вот для неофита таких задач может и не быть. Да и по сроком время овладевания тем же Python по сравнению с С++ значительно меньше.

Я например, начал с того что посоветовал выучить вначале теорию, пускай человек почитает Бутча, Фаулера, Кернигана, GoF, а уж потом сам определится, что ему учить в дальнейшем.

Полностью согласен, просто некоторые товарищи считают свой любимый язык программирования панацеей для решения любых задач.

IvanoBulo
что посоветовал выучить вначале теорию, пускай человек почитает Бутча, Фаулера, Кернигана, GoF
Очень интересно посмотреть на человека, который никогда в жизни не программировал, разбирающего листинги в Gof или Бутча на С++. И чего он там поймет?

да кстати я все жду разъяснений по поводу ракообразная" ООП в Python

Человек как правило с "там-тарары" не начинает заниматся программированием, он наверняка имеет уже некоторые базовые навыки в этой области полученные в школе или в ВУЗе.
Но если предположить худшее, т.е. человек "0" в этом вопросе, то для начала пусть прочитает книгу по информатике например...


1. Нет инкапсуляции, о чём я говорил ранее:
http://docs.python.org/tut/node11.html:


2. Не всё является обьектами (в стандартном понимании этого слова). Согласен, что например в Java и .NET есть тоже простые типы как-то int, float и т.п., но это сделано исключительно с точки зрения увеличения производительности. В Питоне же преобладают именно типы, мало того понятие "обьект" в Питоне это вовсе не обязательно "экземпляр класса", что для большинства Smalltalk, Java и .NET программистов является просто абсурдом. Для примера меня просто взбесил тот факт что Timer в модуле threading не является классом, хотя в документации написано что это класс, а мне нужно было от него пронаследоватся. Вообщем-то не проблема - сделал делегат, но потратив лишнее время и нервы.
3. Отсутствие статической типизации, а также отсутсвие интерфейсов, просто не позволяет создать чёткую архитектуру системы для того чтобы просто посмотрев на сигнатуру метода разработчик смог работать с ним правильно, что органичивает паралелизацию разработки.
4. Множественное наследование. Не знаю как Вам, но я считаю что это плохо для ООП, мух и котлеты лучше не мешать.

В итоге моё ИМХО таково, что Питон это отличная тулза для небольших программ, а также идеальное средство для замены shell-скриптов. Но большие системы с развитой и сложной архитектурой не для него.

IvanoBulo
Человек как правило с "там-тарары" не начинает заниматся программированием
перевидал кучу людей, которые начинают именно с "там-тарары"
да и такие знания имеет уже некоторые базовые навыки могут и не помочь понять, что написано у тех же gof.

1. Нет инкапсуляции, о чём я говорил ранее:
Во-первых, инкапсуляции можно добиться если она так уж нужна (как - описано мною выше).
Во-вторых, как я уже говорил ООП это вообще не панацея от всех бед.
Питоне же преобладают именно типы
это плохо? Python не чисто об-ориентированный язык. Если уж на то пошло объект это конкретная реализация типа.
что органичивает паралелизацию разработки.
спорно.
Множественное наследование.
ну дык не используйте если не нравится.

Отсутствие статической типизации
а на кой черт она нужна? Это же убожество. Или вы имеете ввиду что-то другое?

IvanoBulo Хе, хе. Вот как можно серьёзно относиться к Вашим высказываниям, если пишите заведомо бред??? Можно сказать, что Отсутсвие типизации и инкапсуляции является потенциальными причинами ошибок, но не более!!!!

[удалено]
Последнее устное предупреждение. vor
Нужны простые и понятные ВСЕМ факты. Если их нет - то лучше помолчать.
Неправда. Имеменно програмист определяет "правильность" программирования. Язык лишь может ограничить появление некоторых специфических видов ошибок. Хотя бы пример со "сбором мусора".
Во-первых, основные преимущества разработки больших систем на Java не в языке программирования. А во-вторых какое значение это имеет в данном случае? Вы же сами пишите, что программы на Python гораздо меньше, чем на Java! Соответсвенно их проще писать и проще понимать.

DeaD...Just DeaDИмелась ввиду статическая типизация.
Отчасти это правда. Имеются некоторые ограничения и отличия от классического ООП. Но эти моменты не являются ключевыми или очень важными в программировании.

vorВопрос в том, что изучать программирование гораздо проще именно с Python. Этот язык можно использовать и как "процедурный", и как ООП... Малый объём программ... Развитые встроенные типы...

Enot
ввиду статическая типизация.
да нет в python статической типизации. Параметрический полиморфизм он же поддерживает. При статической типизации это было бы невозможно.
Отчасти это правда. Имеются некоторые ограничения и отличия от классического ООП
классический ООП это то что Буч предлагает? Не, мне такого нафик не надо
И если уж пошло меряние ООПшными пиписьками, что С++, Java уже поддерживают multiple dispatch?