Хм, а почему не учить бы сразу то, что нужно? )

Я вот жадею, что начал с C, а не с C++ =\

Под Бейсиком имелось в виду и QBasic 4.5, и VB 6.0.
Вывод о том, что в программировании я ничего не понял - вот это забавно. 




Нет, не снисхотидельно. Вообще-то, если заглянуть назад, то улыбнулся я над фразой "У вас очень грамотные преподаватели".
Если по математике и сходным наукам хороших преподавателей у нас действительно много, то по программированию их почти нет.
Вирт тут вообще ни при чем. Не его же вина, что мне не нравится Паскаль. А фразу про "язык оказался настолько хорошим" я уже где-то слышал.

Но это я от темы отвлекся, извините за оффтоп.

  

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

Кому интересно моя история такова: BASIC -> Z80 ASM -> PASCAL -> X86 ASM ->C -> C++ Builder -> C++

К сожалению, структура билдера так развращает, что назвать "это" C++, язык не поворачивается.

И еще раз повторяю. Имея большой опыт работы на Си (или на билдеровском С++), обучиться С++ очень тяжело. По себе знаю.

nerezus, к сожалению не всегда знаешь, что тебе нужно)

Да даже если и знаешь - жизнь иногда поворачивается совсем неожиданной стороной. Несколько лет назад для меня повернулась так, что имея хороший опыт в С и С++ пришлось программировать на Perl, подвернулась просто ну очень хорошая работа. Потом вернулся опять к плюсам, а вот следующая работа уже довольно хорошо обрисовалась и будет под дотнет (C#). Были еще всякие варианты с джавой, но я ее совсем не знаю (и большого желания учить нет), хотя, если бы приспичило - думаю, что справился бы.

Это я к чему? Начиная с какого-то времени (опыта), язык становится больше инструментом, а на первый план выходит проектирование, дизайн. Если он удачный - тогда и код писать легко, если нет - там и отличное знание языка мало помогает, приходится все по ходу переделывать или разные извраты городить.

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

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

Это сообщение отредактировал(а) Hurricane - 22.5.2007, 18:07

 Подвернулась 1 раз — подвернется и еще, но в более радужных вариантах. Я бы не стал кодить на языке, к которому у меня отвращение.

 В том то и прикол, что надо наметить цель и идти к ней. А не лишь пытаться это сделать.(фраза откуда-то из НЛП   )

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

Мне, например, было интересно открыть для себя что-то новое. И совсем не скажу, что это время было потрачено впустую. Я уж не говорю о том, что моя работа в том проекте была в основном проектирование и создание прототипа, самого кодирования было как раз немного.

Так что все зависит от того, как человек сам к этому относится. И (опять же ИМХО) "я не буду кодить на языке, потому что у меня к нему отвращение" - эта мысль мне не кажется удачной.


Разницу улавливаешь? У тебя ключевое слово - "идти", а у меня - "наметить". Ничуть не умаляя важности слова "идти".   

И как первая фраза согласуется со второй?   Или Вы сами наступили на грабли и сейчас тяните других за собой?



 А мне както совсем опыт работы на С++ Builder не мешал знать С++. Наоборот, помогал, освободить мозги от нудного создания интерфейса и сосредоточить  усилия непосредственно на функционале

Добавлено через 4 минуты и 44 секунды

Предлагаете плохой стиль программирования лечить дизайном? 

Лучше сразу делать все в лучшем свете, и все.




Тут +1. Билдер развращает за счет того, что содержит кучу не ANSI-расширений и ключевых слов вне стандарта. Доками по тому же Билдеру явно приветствуется такой код, а потом оказывается, что ведь функционал, даже не имеющий к GUI никакого отношения, зависит от VCL. Чего только AnsiString стоит.


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


Кстати, а функционал пишете в зависимости от VCL или без оной?

Вы считаете, что в VCL не позволяет использовать STL и свои "чистые классы"? Для того чтобы написать программу у меня все есть: стандарт, который определяет, все то , что не касается расширений, и документация по VCL и расширениям, в которой кстати четко заявлено, что не следует путать С++ классы с VCL классами, ибо это совершенно разные вещи  и в некторых случаях они ведут себя по разному.


Стандарт не запрещает  расширения  . 
Беда не в том, что есть расширения, которые облегчают процесс программирования и предназначены для в основном поддержки парадигмы визуального программирования.. Беда в том, что есть люди, которые кроме  этого облегченного процесса не желают ничего знать глубже. Но причем тут Билдер? Не виноваты же автомобили, за то, что некоторые  из нас разучились бегать. Я полагаю, что количество хороших программистов в процентоном отношении во времени  постоянно. Просто  остальные , те которые особо не вникали, во времена  царствования командной строки и MultiEdit  ставновились просто  программистами, что называется, так себе, а во времена , когда программа может быть создана путем пары кликов,  становятся ламерами-кликальщиками. По-моему , большой разницы между ними нет. 
И если человек, перед тем, как воспользоваться различными "подпорками", научится программировать правильно, то  эти "подпорки" просто послужат повышению эффективности  работы, а код написанный им будет безупречен, неважно, что они использует VCL или MFC.
Если же этот базис в свое время не был получен, то есть вероятность, что программист так  и останется "xромым". Но в каждом конкретном случае это зависит от человека.
Но  я, например, утверждаю следущее. Что если Вы изучаете самостоятельно процедурное программирование, то "С"  не "подвинет" Вас писать правильно, а Pascal - "подвинет", ибо для того и создавался этот строгий язык.  То же самое и  ООП и С++. Взявшись за чистый С++, Вы возможно и научитесь писать правильно даже , если это С++Builder.  Но если обучение начнется с клепания форм на том же С++Builder, то вероятность того, что Вы правильно будет создавать свои программы, ичпользуя парадигму ООП будет резко стремиться к нулю.
 

Я нисколько не умоляю достоинств Билдера. Это лучшая среда быстрого создания оконных приложений под Windows (а может и вообще) из виданных мною. Но. Лично мне знакомство с ним навредило. Так как сначала (после Си) у меня был "C with classes" (это borland c++ 3.1), а затем я перешел на этот билдер. А в билдере в основном именно процедурное программирование идет (хотя эти процедуры являются методами класса формы).
Короче. Считаю, что знакомство с билдером для неокрепшего программистского ума вредно. А для профессионала - это отличный инструмент.

Нет, конечно. Но многие пишут в зависимости от VCL и думают, что так и надо и это есть С++. А потом - бац, в других средах ничего не работает...


Тут +1.


Тоже +1. Но! Ежели изначально писать под консоль, например, то намного меньше вероятность, что программист (если не бросит свое дело) станет кликальщиком по формам.



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


Чистый +1.


В этом вопросе у меня двойственность... с одной стороны, и мне тоже довольно-таки навредило. В вопросах знания языка и стандартной runtime lib. С другой стороны, сейчас это хороший инструмент (вернее, изученная мною часть) у меня в кармане для Rapid Application Development, и бывает, что он оказывается полезным.

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


Вы страшные люди! Зачем так человека нагрузили! Человек просто спросил:
что мне делать найти книжку по С и начать с него или забить на него и проосто начать самому С++ учить...
А вы сделали из мухи слона! Ну и что, что он написал объяснить ему не в трех словах - что теперь читать ему
всю историю C и C++?

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



Да, и вполне логично, что академический язык учит, а промышленный не предназначен для этого.

-------------------------------

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

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

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

Также С++ стал успешным и заложил фундамент успеха Java, C# и так далее благодаря тому, что сам не был "чистым" ООП языком, на что также указывает Страуструп, говоря что С++ реализует ряд парадигм (включая структурную, процедурную, объектно-ориентированную и так далее), то есть он полностью включает подмножество С, но не является его конкурентом.

Следствием этого является, что на данный момент С является одной из парадигм, реализуемой С++. Поэтому в общем случае можно начинать изучение именно С++, если рассматривать его как многоцелевой язык и в дальнейшем специализироваться в отдельных областях (например, при необходимости низкоуровневого программирования изучать С, при  необходимости высокоуровневого программирования STL и boost, при необходимости полного перехода к парадигме ООП - Java или C#).

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