На С# не нужно запариваться про память, если вы запариваетесь про память, значит вы С++ программист )) Сам грешу этим, ну что делать. Я бы не стал учить Сишарп первым,но отнюдь не по этой причине, это ООП язык - раз, если сразу программить на нём - то боюсь разницы между ООП и не ООП не почувствуете. И второе - это block orinted language, это значит, что программа в шарпе собирается из блоков, блоками являются классы библиотеки .NET, такого счастья в С++ нету , там есть другое счастье STL, но how fast does it allocate the memory:))) снова свалились к вопросу про память, о черт. ЗЫ. - Для тех кто не знает - STL супер библиотека, там своя куча и память там выделяется быстро.

Интересно, zauropod вы сами это придумали или где-то услышали? Советую хоть немного ознакомиться с историей языка С++ (в этом смысле ничего лучше книги Страуструпа "Дизайн и Эволюция C++" не найти). Намекну мельком: во-первых С++ появился не сразу - сначала был С с классами, где классы траслировались средствами препроцессора (а затем компилялись сишным компилятором), в нём не было ничего мудрённого (и понятие класса на тот момент уже существовало в Simula откуда собственно и было позаимствованно) и уж тем более медленного; во-вторых основная цель С++ при его развитии была следующая: "программист не должен платить за то что не использует". На практике это означало и означает, то что C++ может показывать быстродействие одинаковое с С. Для этого необходимо просто проявлять небольшую дисциплину - не использовать виртуальные функции без надобности; отказаться от оператора dynamic_cast (в правильно спроектированной программе необходимость его использования и так минимальна), скажем, использовать его только в debug конфигурациях; не злоупотреблять исключениями и др. А чё там, кстати, за игры были до появления C++?
А теперь по теме. Если учиться серьёзно программированию. То вопрос "какой язык стоит выучить?" абсолютно некорректный. Профессиональный программист за время своей работы и учёбы (а учиться ему приходится постоянно, каким бы профессионалом он бы не был) выучивает не один десяток языков. Считается правильным изучать не меньше одного нового языка в год. Насчёт того как начать, то тут есть проверенная годами метода. Первым языком лучше сделать Turbo Pascal (недаром его предка создавали специально для обучения студентов программированию), затем стоит осилить assembler, С и связки assembler - Pascal, assembler - C (именно в этот момент рождается ощущение власти над машиной). Вот теперь уже можно пускаться в плавание. Дальше я считаю необходимо начать штурм C++ (профессиональному программисту вряд ли удастся обойти этот язык стороной). При изучении Turbo Pascal уже должны быть получены первоночальные представления об ООП - поэтому проблем с изучением не должно быть. Параллельно с этим можно изучать SQL, HTML, XML, XSLT, Visual Basic, VBA и др. После не лишним будет занятся вопросами проектирования (глубокое изучение ООП, паттерны проектирования, UML и др.) и, хотя бы в общих чертах (остальному научат на работе), общими вопросами разработки (тестирование, профилировка, отладка, рефакторинг, системы контроля версий и др.). Вообще, с самого начало обучения программированию стоит уделять самое пристольное внимание различным инструментам, самым главным из которых должен стать отладчик, чем быстрее им овладеете тем больше времени сэкономите. Ну а дальше как жизнь сложится - кто-то сделает уклон на Java; кто-то на Visual C++, COM, DDE и другии windows-технологии; кто-то на С#; кто-то на SQL, PHP, Perl, Python; кто-то на системное программирование; кто-то на ... да чё там, направлений дальнейшего развития огромное количество, выбрать есть из чего , и тут советовать бесполезно, у кого к чему душа лежит (да и сменить направление в принципе никогда не поздно). Такая последовательность изучения программистского ремесла в большОй степени соответствует истории этой науки. Так учился я, многии мои коллеги, друзья и знакомые программисты.
P.S. Если учиться программированию всерьёз, то надо быть готовым, что придётся читать книги и очень много. Да, и про английский не стоит забывать.

Obscury
Сколько людей - столько и мнений. Я лично считал и продолжаю считать, что с pascal на си и ему подобные переходить хреново. Я лично начал с вб (до него, конечно много других было и паскаль в том числе, но всю основу взял от него), а после перешел на с++ (параллельно в учебном заведении, проходя паскаль). Ну а дальше уже побежали десятки языков на изучение сразу.

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

sashar2
Забавно. Когда я учился в лицеи, там нам преподавали именно VB как первый язык. Помню как хреново я его выкупал. Правда в то время у меня и компьютера та не было. Тяжко было очень: операторы, переменные, массивы и тут же окна, кнопочки - жуть какая в голове каша была. Потом поступил в универ, там к счастью программирование начинает изучаться с нуля. И первым языком, как я уже говорил, стал Pascal. После этого всё пошло как по маслу. Очень простая IDE, полное абстрагирование от всяких GUI - есть консоль, есть память, в которой можно размещать переменные. Всё! Можно, наконец,заняться циклами, ветвлениями, массивами и, чем чёрт не шутит, начать писать алгоритмы .

Товарищ Obscury всё очень правильно сказал.но про кое что он забыл, а именно - про информатику. Если сценарий будет такой как написан выше,то из вас в конце концов выйдет перец в красной кепке, который учил 1 язык в год и знает их в совершенстве, но ни одну реальную задачу решить не может, потому что нужно ещё изучать алгоритмы.

ASM/C/C++/Perl/PHP/Java наше все %) Плюс C# перспективен.

Ненавижу Pascal, QBasic, Visual Basic

У вас в лицее просто были совершенно никуда не годящиеся преподы - если человек не знает что есть что, то надо давать лишь самые основы, создавая "программистское мышление".
Pascal сейчас нужен очень мало, в основном для поддержки старого кода, новичкам его изучать нет смысла (разве что чтобы создать то самое "мышление").


Языки действительно надо изучать, но нормальное изучение одного языка может занимать очень разное время, ибо у них у всех - разные области использования. Если Lua или Python можно за месяц изучить в совершенстве(благо нужны они лишь для небольших скриптов), то набивать новые шишки в C# или C++ ты будешь годами, ибо приспособлены они для гораздо большего спектра задач.


Наивный. Почитай-ка http://www.simple-talk.com/dotnet/.net- ... -profiler/

Всем здравствуйте.

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

ИМХО, язык для начинающих должен удовлетворять следущим требованиям:
1) Содержать в себе все базовые програмные структуры, такие как подпрограммы, ветвления, циклы, рекурсия (не обязатеьно еще и хвостовая) и т.д.
2) Быть минимально привязаным к железной части, но и не радовать такими фишками, как динамическая типизация.
3) Синтаксис языка должен быть интуитивно понятен.
4) Иметь при себе большое количество обучающей литературы.
5) Давать возможность создания современного GUI - спорный момент.
6) Быть простым в обучении, по количеству необходимых знаний для написания хорошо работающего кода.

Если проанализировать эти пункты, то лучше всего для этого пункта подходит Паскаль. Си, Дельфи, Питон и Жаба отметаются по разным критериям.

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

Естественно, парралельно, человек должен перелопачивать кучу литературы по информатике и computer science.

Все вышесказанное - ИМХО.

А можно пример того. что вы имели сейчас в виду ? Понимания каких конструкций вы хотите добиться ?

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

Все критические мысли прошу аргументировать.

C++, C#, и ещё SQL Server изучить неплохо, для студентов Microsoft на халяву раздает Server 2003/2008, Visual Studio 2005/2008 так что дерзайте

wild_r,

Присваивание, ветвление, циклы - и все базовое усваивается за 20-30 минут нормальноразвитым человеком.

Алгоритмы и их написание можно изучать ВЕЧНО и тем более на этом даже можно сделать открытие, если таки решить NP-полные задачи. Большинство же известных необходимых алгоритмов с средней сложностью и выше уже закодировано(различные сортировки, криптоалгоритмы, алгоритмы рисования графики).
Более того, известные алгоритмы лучше изучать отдельно от реализации посредством какого-нибудь учебника по дискретке.

Я против Паскаля. Почему? Потому что если человек хочет стать программистом(а понятие довольно размытое), то лучше изучать какой-нибудь чистый ООП язык(так как скорее всего в реале он будет решать задачи).
Если дальнейшее применение - математика - то ML-подобные языки(в том числе и F#) али какой-нибудь логический(Prolog). Именно с функциональных языков и начинают обучение большинство известных западных ВУЗов.
Весь парадокс учебного паскаля - что он обычно не дает дальше развиваться. Люди и дальше пишут на нем и на дельфи...Всю жизнь. Развитие моментально останавливается.

Я начал с ...С++. И когда на 1 курсе мне начали преподавать Pascal...было не по себе.


Если не ошибаюсь, то последний стандарт С...с классами. Поэтому по-видимому все подразумеваются в этой теме старый С.

Obscury

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

1) Видел кучу людей, в т.ч. и в своей группе - они очень долго доходили до некоторых простых моментов.
2) Теория типов не так проста. А она следует логически из желания человека нормально использовать и понимать ООП. Вообще, есть очень много нетривиальных вещей, связанных с структурами языков. Например, можно очень долго понимать генерики из жабы.
3) А я против начинания с си. Я вообще за язык, обладающий сборщиком мусора, без ООП. ООП - хорошее подспорье в структурировании программ, но не более. Правда некоторые принципы ООП я и в жизни вижу.
4) Чужие реализации - хорошо, но и самому попробовать нужно. Дискретка - хорошо, но и кодирующей обезъянкой не надо становиться.
5) То, что Паскаль не дает развиваться - бред. Такой человек просто ленив или недалек.
6) F# то не надо тут упоминать, если господа из Майкрософта хотят иметь свой функциональный язык, пусть придумывают свое, а не копируют.

З.Ы. Я начинал с обычного Бэйсика, потом был Паскаль, потом Дельфи и OCaml, потом Жаба и Питон, потом Си и Фортран, и т.д. Никаких ограничений от Паскаля не имею, тем более, что я уже забыл его и все его прнципы. Но он помог мне понять многие элементарные вещи без лишней нагрузки в виде основ и тонкостей ООП.

З.Ы.Ы. Вы действительно считаете, что возможно решить задачу P<>NP?

Именно поэтому паскаль с консолью, а не VB с контрольчиками.

На Delphi ещё много чего пишется, не так уж он бесполезен...

Как можно изучать ООП, не понимая в совершенстве таких вещей как функции, структуры (записи), потоки выполнения, композиция? ООП не на пустом же месте родилось. Вот потом люди и начинают плести, что-то вроде:

Это вы о чём? Вызов виртуальной функции происходит косвенно через указатель из vtbl, отсюда снижение в скорости (если функция маленькая, скажем метод-аксессор, и вызывается в цикле, потери могут быть заметны), дополнительные расходы памяти - полиморфный тип требует выделение памяти под таблицу виртуальных методов, информацию о типе и самое главное каждый объект типа получает в нагрузку по 4 байта (vptr) на каждый полиморфный базовый класс (собственные виртуальные функции присоединятся к первой vtbl, по крайней мере так поступает Visual C++). Т.е. если у класса 4 полиморфных базовых класса, то каждый объект становится на 16 байт тяжелее плюс создаются четыре таблицы vtbl, соответственно каждой таблице базовых классов. К тому же у компилятора меньше возможностей для оптимизации в случае полиморфного вызова (встроить такой вызов уж точно не получиться ). Появляются различные лазейки для ошибок (вызовы чисто виртуальных функций, ограниченная виртуализация в конструкторах и деструкторах, отсутствие виртуализации аргументов по умолчанию и многое другое), хотя это уже немного не о том. Если метод может быть невиртуальным, значит таким его и надо делать. Насчёт Буча, то тут, я полагаю, имеется ввиду гибкость архитектуры, масштабируемость, т.е. производительность программиста, сопровождающего программу , ну уж никак не производительность самой программы.

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

Да уж...

Можно смысл написать? Я могу сгенерить много ситуаций и мыслей, соотв. этим фразам. Именно поэтому я писал про аргументированность и полноту общения.

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

Эта фраза просто обескуражила. Формально, конечно, так можно сказать о чём угодно. Например, С# - хорошее подспорье в структурировании программ, но не более, ведь всё можно написать и на ассемблере. ООП - это не подспорье, это не удобная надстройка над процедурным программированием, это совершенно иное мышление, это совершенно иные архитектурные принципы и без понимания этого никуда.
Всё высказывание как бы передаёт мысль, что ООП это так, не стоит на него тратить время, типа когда будет нужно за два вечера разберётесь. Но это не так, написать крупный проект без ООП нереально, а изучить его даже за двадцать вечеров ещё нереальнее.[/i]

1) Сборка мусора (а именно ее вы имели ввиду?) вполне хорошо поддается автоматизации. Так зачем увеличивать количесвто ошибок?

2) Если посмотреть на три принципа ООП, то все именно так, как я сказал. А вот если принять во внимание реализацию и использование всего этого на примере Жабы, как прямого наследника Smalltalk, то все намного серъезнее. ООП действительно является идеологией, образолм мыслей, но она довольно естественна, во всяком случае естесвенее функционального прораммирования.

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

Все-же написать хоорший проект возможно, например, используя функциональный язык и работая в определнной сфере, и там не будет ООП. Другое дело - комерческий проект на с++ или жабе, там грех не восползоваться ООП.

В общем - моя мысль такова - оно хорошо, оно солжно для обучнения, оно не является панацеей. А сборка мусора - это уже совсем другой разговор.

З.Ы. Я совершенно точно могу сказать, что ИМХО, динамическая типизация - зло.

Вот не понимаю я ценность сборщика мусора для профессионального программиста и всё тут. Зачем расплачиваться производительностью и затратами памяти за то, без чего элементарно можно обойтись (мы ж не и**усы). Например, я в настоящее время занимаюсь разработкой и поддержкой проектов на Visual С++ без всяких сборщиков, автоматизация и так происходит, но на значительно более управляемом уровне. Могу сказать следующее: в коммерческом коде вы не найдётё явного освобождения ресурсов или использования массивов в стиле С (кроме особых случаев). Структурная обработка исключений просто "несовместима" с подобными вещами. Для управления ресурсами всегда используются различные враперы (такие как смарт поинтеры) и коллекции (даже для буферов используются коллекции байтов). Ладно, не буду заводить долгие повествования, просто скажу, что освобождение ресурсов в профессиональном коде без сборщика мусора значительно более прозрачно и управляемо. Для меня всегда важно что и главное когда освобождается в программе. Кроме того, сборщик мусора подвержен ошибкам как и любой программный продукт (нет всё-таки меня понесло). Отлавливание и разрешение его ошибок значительно сложнее, чем устранение утечек в программах без сборщиков. Вообще, сама проблема сильно преувеличена - утечки памяти (в отсутствии сборщика) легко отлавливаются профайлерами и в подавляющем большинстве случаев исправляются в течении 5 минут. Всё что нужно, это знать обёртки которые используешь и осмысливать каждый детач нативных объектов (что неизбежно при взаимодействии с различными библиотеками) - это практически единственное опасное место в смысле утечек при работе с ресурсами.
Не смотря на это, хочу заметить, что очень тепло отношусь к .NET и Java .

Для создания больших проектов (> 1000000 строк) альтернативы просто нет. Что тут ещё обсуждать? Пример с фортраном не удачен (как и с функциональными языками на мой взгляд) - это специализированный язык программирования, на нём не пишут большие проекты, на нём работают инженеры, математики, а не люди, избравшие своей профессией создание программ.

Занавес. Что значит зло? Источник ошибок? Не без этого, конечно, но преимущества этой штуки настолько колоссально, что выразить сложно в одном предложении. Вы когда-нибудь что-нибудь слышали о плагинах, компонентно-ориентированном программировании, понятии интерфейса и имплементации, паттернах проектирования (это всё просто основа основ разработки программного обеспечения)?

Большая часть кода, котрый пишут на с++ - отнюдь не такого высокого качества, как хотелось - бы. Если на то пошло, то можно допустить два варианта работы - автоматический и ручной.



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



Я вам не про контроль типов, который должне быть везде, а про использование сего инструмента для обучения вплоть до достижения некого "профессионального" уровня. А обо всем том, что вы написали, представьте себе, я не только слышал. И опять вы в ООП влезли. Существует в мире не только оно, есть еще функциональное программирование, например. Которое хорошо справляется с неким кругом задач.

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

Научные расчёты весьма специфическая область программирования. Люди, работающие в этой области, вряд ли будут задаваться вопросом "Хочу научиться программированию. Вопрос: что выбрать?":).

Ну если в таком смысле, то соглашусь.

Про контроль типов я вроде ничего не говорил (и даже не думал)...