Форум программистов CodeGuru
18 Январь 2018, 08:03:21 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
Новости:
 
   Начало   Помощь Войти Регистрация  
Страниц: [1]   Вниз
  Печать  
Автор Тема: Прошло 5 лет...я вернулся  (Прочитано 3532 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Gudvin ill be back
Новичок
*
Офлайн Офлайн

Сообщений: 5


Просмотр профиля
« : 18 Октябрь 2013, 17:10:57 »

Давным давно в далёкой далёкой галактике...

5 лет назад я обратился на этот форум в надежде, что из меня сделают программиста.
У меня было 500 мегабайт интернета и надежда что ВЫ, форумчане поможите мне. Но нет! Вы писали всякие непонятности и отказались рассказывать свои тайны исскуства программирования. Рассказывали про какой-то завод в Новосибирске, где выпускают программистов, шутили и издевались надо мной...Мне понадобились годы, чтобы пережить эти унижения. Но это сделало меня сельнее! Теперь у меня есть гигабайт интернета (модем Мегафон) и желание...вам всем назло сделаться
всё-таки программистом! Злой Я уже почти веб-мастер, доучиваю HTML. Осталось чуть-чуть...и я покорю интернет. Английский дался легко, читаю почти без словаря.

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

 
Записан
3V
Администратор
Ветеран
*****
Офлайн Офлайн

Сообщений: 1347



Просмотр профиля WWW
« Ответ #1 : 18 Октябрь 2013, 23:02:37 »

5 лет назад

Как жеж время то летит..  Не в себе

шутили и издевались надо мной...

Да где-ж такое было то ?
Все по-доброму  Смущение

сельнее!

 ГЫ !

Осталось чуть-чуть...и я покорю интернет.

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

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

Задавайте вопросы. Правильно заданный вопрос - половина ответа!
Записан

Gudvin ill be back
Новичок
*
Офлайн Офлайн

Сообщений: 5


Просмотр профиля
« Ответ #2 : 03 Ноябрь 2013, 18:56:34 »

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

 
Записан
Gudvin ill be back
Новичок
*
Офлайн Офлайн

Сообщений: 5


Просмотр профиля
« Ответ #3 : 25 Ноябрь 2013, 21:18:03 »

 :cry:Так я и знал. С годами ваша чёрствость не прошла! Вы, программисты , всё так же не хотите делать меня программистом и скрываете секреты мастерства.
Записан
3V
Администратор
Ветеран
*****
Офлайн Офлайн

Сообщений: 1347



Просмотр профиля WWW
« Ответ #4 : 25 Ноябрь 2013, 23:13:17 »

У мну есть вакцина программизма. Но она убивает в FF.FFFFFFFF процентов случаев. Можно пропробовать Вам впрыснуть. Но жаль было бы терять такого общительного собеседника.

Лучше уж через глаза и уши обучаться (классическим способом), чем через попу (вакцина с непонятным эффектом).
Записан

Al G
Интересующийся
**
Офлайн Офлайн

Сообщений: 28


Просмотр профиля
« Ответ #5 : 27 Июнь 2014, 18:42:44 »

сглючило, репост (прошу удалить первое):

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

1.

Первым делом ты должен решить, хочешь ли ты быть одним из массовых программистов, имеющих возможность сменить работу в любой момент; или же ты хочешь уметь писать КАЧЕСТВЕННЫЕ программы - для личных нужд, для научных нужд, в ответственных сферах - и быть мишенью для хедхантеров, которые сами переманивают к себе особо ценных сотрудников. Может, ты мечтаешь написать систему управления АЭС или МКС, или работать в банковской сфере, а может, хочешь просто перед девками светить названием места работы типа "майкрософт". Выбрать оба варианта тут не то чтобы невозможно, а, скажем так, трудно и долго. Просто массовое программирование идёт по пути, ПРЯМО ПРОТИВОПОЛОЖНОМУ качеству. Я серьёзно.

Ты никогда не задумывался, почему программы так часто хотят обновляться через интернет? Нет, это не для безопасности. Совсем наоборот - качественные программы не обновляются. По крайней мере, не каждый день и даже не каждый месяц. И не глючат. И не требуют лютых вычислительных ресурсов, работают годами на антикварных машинах. Но выжимают из них на порядок большие возможности, чем говённые программы. Для примера почитай про VMS и сравни с Windows. Массовые же программы умышленно создаются заведомо говёнными, и каждое обновление устраняет одни ошибки и добавляет новые. Это называется копроэкономика, или теория говна.

Ты никогда не задумывался, почему M$Word такой говённый, и зачем было выпущено СТОЛЬКО его версий, если ни одна из них реально не добавляет абсолютно ничего такого, чего бы не было доступно уже в версии от 97 года? А потому что дорого. Потому что его пишут тысячи программистов, подчиняющихся целой иерархии архитекторов-пиэмов-тимлидов-кого-там-ещё. Вся эта армия нужна вовсе не по причине сложности проекта. Проект-то плёвый. Чтобы создать мощный текстовый редактор, позволяющий верстать профессионально выглядящие документы, достаточно трёх-пяти человек и полсотни подмастерьев. Не веришь? Посмотри, что такое TeX и LyX. Ворд с ними сравнивать просто даже смешно, при этом они дешевле. Ну то есть так-то они вообще бесплатные, но даже если бы они были коммерческими, реальная себестоимость их разработки была бы ноль целых хрен десятых. А для писем маме за глаза хватает чего-то вроде WordPad, за который даже M$ стесняется отдельно брать деньги. Для получения арсенала хороших программ для всевозможных задач всего-то и нужно, что немного подумать. Армия же программистов нужна для того, чтобы во-первых, разработка обходилась достаточно дорого (это производит впечатление на акционеров и привлекает инвестиции), и во-вторых, чтобы продукт выходил достаточно говённого качества, чтобы на нём можно было стабильно и хорошо зарабатывать. Чтобы с пользователями можно было играть на всяких юзабили-тестах, книгах и учебных курсах по использованию и загружать трафик скачиванием заплаток, а значит и прокладывать новые кабели, и изготавливать медиаконверторы-шлюзы и т.д. и т.п. Заставь всех пользователей планеты дружно пересесть на TeX+WordPad - и сотни тысяч паразитов потеряют работу, примерно как когда-то телефонистки и извозчики.

Нет, это не значит, что на хороших программах нельзя зарабатывать. Почитай Beating the Averages - это автобиографическая статья человека, который на хорошем программировании заработал с коллегой 50 миллионов долларов на двоих меньше чем за год. Просто на говне зарабатывать ПРОЩЕ: голову напрягать не надо, только жопу.

Так вот, если твоя цель - быть "одним из" - то я тебе не советчик. Мне серость по боку. На просторах Cети орава быдлокодеров, которые тебе помогут пополнить свои твердолобые ряды. Будешь писать говно, и получать за него пусть и небольшую, но стабильную зряплату. Но допустим, что твоя цель - не просто программировать, а хорошо программировать. Не важно, за деньги или для науки, или даже для того, чтобы не самому писать, а быдлокодерами эффективно руководить - по вопросам бухгалтерии тебя проконсультируют на другом форуме. Если тебя интересует качество программного обеспечения, то тогда читай меня дальше. Путь качества долог и тернист, и никоим образом не пересекается с быдлокодерским (т.е. даже проконсультироваться будет не с кем, придётся самому во всём разбираться), но и плюшки на том конце тоннеля слаще. Я охотно расскажу тебе, чем занимаются высококвалифицированные профессионалы в программировании, ибо у 95% программистов представление о содержании профессионализма в программировании очень сильно искажено. Хорошо, что ты здесь спросил, ибо, к сожалению, в России хорошему программированию не учат. Иногда знакомят, но очень редко и очень поверхностно. Молодец, что упорствуешь. Мне в своё время пришлось не один год пробиваться сквозь кирпичную стену. На ваше поколение вся надежда.

2.

То, что ты пять лет шёл по пути С++ - плохо и грустно. Культура С++ состоит из заблуждений чуть более, чем на 100%. С другой стороны, то, что ты только хелловорд осилил, говорит о том, что ты ещё не успел как следует замусорить и изуродовать свой мозг, так что ещё не всё потеряно. Начинать надо с языков Scheme, Standard ML, OCaml. Эти языки идут первыми языками программирования в авторитетных мировых вузах - Оксфорде, Массачусетском Технологическом, и т.д. и т.п. Мировая программистская элита учится на них. Быдлокодеры учатся на C++, Java, Php. Случайность?

Правильный выбор первого языка, в который ты погрузишься с головой, крайне важен. Язык - это не просто инструмент для изложения мыслей, как многие думают (точнее, знают - знают неправильно). Язык формирует САМО мышление. Чего не позволяет выразить язык - на то не способен мозг. Это называется Гипотезой Сепира-Уорфа. Например, Дейкстра (известный профессор информатики) утверждал, что студенты, которые успели достаточно тесно окунуться в Бейсик перед его курсами, ментально исковерканы и обучить их хорошему программированию просто невозможно.

С++ишки считают, что "сложность равно квалификация". Т.е. буквально, чем более сложным способом ты решаешь простые проблемы, тем ты круче. Для них является нормой, что удвоение сложности задачи приводит к двадцатикратному и двухсоткратному усложнению кодирования и управления проектом. Поэтому тех, чьим основным языком является ублюдочный С++, не слушай. Вообще. Даже если некоторое конкретное С++ишко честно признается тебе, что С++ слишком сложен и не подходит для твоих нужд, его совет всё равно будет заведомо неправильным. У них просто ОШИБОЧНОЕ понимание того, что такое в принципе программирование и зачем оно нужно.

Иногда можно прислушаться к советам тех, кто пишет на old-school-Pascal / Oberon / Component Pascal (blackbox). У этих людей тоже хватает заблуждений, но как минимум есть представление о дисциплине. Тех, кто пишет на Object Pascal / Delphi или Visual Basic, посылай лесом, это вообще клиника. Java может быть инструментом в руках грамотных людей, но если человек знает ТОЛЬКО джаву, то мышление у него квадратно-гнездовое. Короче, учись выбирать, кого можно слушать, а кого нет. Программисты - народ самовлюблённый и своё мнение (точнее, своё неправильное знание) навязывать любит особенно. Да, мои советы тоже не надо принимать слепо на веру - гугл в помощь. Поскольку моя точка зрения объективна и обоснованна, то я проверок не боюсь. Это С++ишки тебе будут петь в уши про популярность (не могут же миллионы леммингов ошибаться???), я же всегда назову язык плохим только в сравнении с каким-то другим языком и с учётом конкретной задачи. Но если я не назову тебе определённые ключевые слова, то вряд ли назовёт кто-то другой, объективность здесь прямо противоположна популярности.

3.

Кого слушать? Ключевые слова для проверки людей - Лисп, ML, Хиндли-Милнер, функциональное программирование.

Читай книгу SICP. Потом Харпера "Введение в Стандартный ML". Коли владеешь английским - хорошо, по ML ты много литературы найдёшь, и советую читать Paulson "ML for the working programmer". Кое-что на русском есть, но не так много. Можно отступиться от Х-М и почитать Гвидо ван Россума про Python, его хватит для практик - а за него, кстати, и быдлокодеры готовы хорошо платить, т.е. пригодится. Но углубляться не надо, для более грамотного человека Питон изучается целиком вообще за пару дней, а новичка его мультипарадигменность может изрядно запутать. Есть определённое количество литературы по Окамлу, Эрлангу и Хаскелу, но она, как правило, изложена либо слишком витиевато, либо наоборот, слишком хелловорлдно. По Окамлу переведён Джон Харрисон "Функциональное программирование". Есть хороший курс лекций русского автора Душкина про Haskell. Однако, Хаскел в качестве первого языка нифига не подходит, слишком сложный - в совершенно ином смысле, нежели С++, смысле - от него просто мозги плавятся, так и вкус к программированию отбить недолго. Хаскел и прочие Агды - это скорее высший пилотаж для особо суровых программистов, туда не спеши соваться, но позже я пару слов скажу. SML и OCaml куда лучше для первоначального изучения. Наверно, что-то по Scala или F# найдёшь - правда, там тебя будут путать ООПной хренью, но ничего, это потом можно будет вытряхнуть из головы, так что в принципе вариант.

Именно языками семейства ML я советую больше всего заниматься, вне зависимости от того, к чему ты в конце концов придёшь. Хиндли-Милнер воспитывает самое главное - понятие о качестве, дисциплину и культуру программирования. Лисп - первое поколение (без Х-М), ML - второе, Хаскел - третье. Динамически типизированные языки и ошибок дают больше, и работают медленнее. Зато, если ты набил руку (точнее, мозг Улыбка) на Х-М, то и на динамически типизированных будешь писать много аккуратнее. Некоторые устают от Х-М и приходят к Эрлангу, Питону или Руби. Субъективно я таких альтернатив не одобряю, но объективно это язычки простые в использовании, лаконичные, обеспечивающие очень хорошую производительность труда, да и открытых хорошо оплачиваемых вакансий по ним хватает. Но глубокое понимание сути для таких вакансий часто критично: если ты напишешь С++-программу на Питоне, то не всякая Питон-команда тебя примет с распростёртыми объятиями. Это как переводить программу с Фортрана на Си, используя всё те же кружева из GOTO. ML-программа на Питоне - совсем другое дело. Всё ещё встречаются олдскульщики, считающие отстоем всё, кроме Лиспа. Они легко назовут десяток задач, которые на Лиспе решаются много проще, чем на любом из MLей, а потом добьют фразой, что из Лиспа ML изобразить можно легко, а наоборот нет. Со всем этим спорить не стану, но отмечу, что надо внимательно смотреть, стоит ли овчинка выделки. Если ты хочешь штурмовать наукоёмкие задачи - Лисп может и пригодиться. Для более насущной практики он - как стрельба из пушки по воробьям. Но знать его надо, это безусловно.

Есть известное высказывание: Лисп следует изучить даже в том случае, если ты не собираешься им пользоваться. Он формирует ПРАВИЛЬНЫЙ программистский склад мышления, прямо противоположный тому, который формирует С++. Отличие на всех, вплоть до системы ценностей: что есть хорошо, что есть плохо.

4.

С++ - это язык, в котором простые задачи решаются очень сложно, а сложные не решаются вообще. Смысл существования этого языка в программировании. В смысле, в процессе программирования. Не понятно? С++ не предназначен для получения продукта, он превращает программирование в самоцель. Он разработан для решения трёх задач: чтобы держать программистов постоянно занятыми, предоставить им возможность выстрелить себе в ногу, а писателям - возможность издавать руководства о том, как этого не сделать. Если знаешь английский, Ian Joyner об этом говорит подробно и честно, не стесняясь. Программирование на С++ есть суть непрерывное преодоление собственных сложностей инструмента вместо достижения результата. Это как пила, которая начинает изгибаться волнами при поднесении её к бруску. Любая программа на С++ всегда содержит ошибку, поэтому бОльшая честь времени разработки уходит не на собственно описание проблемы компьютеру, а на отладку этого описания. Если тебя интересует результат, а не процесс, то С++ тебе нужен в последнюю очередь. Нужен он тем, кто заинтересован в удорожании разработки на ровном месте, ни за что. Просто за саму по себе якобы "объективную сложность программирования". Разработка на С++ обходится дорого не как следствие каких-то объективных непреодолимых факторов, а наоборот - потому и на С++, чтобы было дорого. Кажется бессмыслицей? Почитай, что такое Кобол и legacy code. Кобол - это четвёртый в мире язык программирования по возрасту (после Fortran, Lisp, Algol), и второй в мире по степени собственной сложности/уродливости (после С++). Точнее, представители программистской элиты часто даже не могут определённо сказать, какой язык программирования из известных науке они ненавидят больше всего - С++ или Кобол - то есть он может даже и первый. Этот пример легко проверить, дурную славу Кобола никто не прячет. А знаешь, сколько зарабатывают спецы по Коболу? Снижать стоимость разработок, увеличивая маржу, стараются те, кто пишет для себя, т.к. они отчётливо понимают, что один раз переписать плохой код на хороший - это в конечном счёте дешеле, чем годами поддерживать плохой. Финансовые воротилы же не заинтересованы в снижении себестоимости собственных программных разработок, поскольку вопрос встаёт уже не об увеличении маржи, а о лопании мыльного пузыря. Как аскариды заинтересованы в поддержании круговорота говна в природе, так и ушлые парни с уолл-стрит заинтересованы в поддержании копроэкономики. Она ещё иначе называется капитализмом, и суть её - не в созидании или преобразовании (как оно было этимологически заложено в содержание слова "экономика"), а в растратах, в поощрении выбрасывания. Чаще звучит термин "культ потребления", но правильнее говорить "культ выбрасывания", ведь для того, чтобы люди покупали (потребляли) что-то новое, они сперва должны выбросить старое. Заставить их выбросить то, что работает, можно двумя способами: религиозным воспитанием (так делает Apple) и политикой (так делает Microsoft). Труп страуса технически поддерживает процесс снизу: регулярно выбрасывает С++, заменяя его на новый; это вынуждает кодеров на С++ выбрасывать рабочие коды, исправляя то, что уже отлажено, это в свою очередь порождает несовместимость программ, и вынуждает пользователей выбрасывать старые продукты, переходя на новые, но новые продукты сделаны с завышенной ресурсоёмкостью, и они также оказываются вынуждены выбрасывать старое железо, а это вынуждает разработчиков выбрасывать старые драйверы, и круг замыкается. Закон сохранения энергии в шоке. На научно-технический прогресс и внутреннее совершенствование просто нет времени, надо рециркулировать говно, переписывая одну и ту же книгу в разных обложках. Microsoft были настолько глубоко восхищены его изобретательностью, что последовали его примеру, поведя .Net (свою единственную вменяемую разработку за все годы) по тому же пути. Вернее даже, они это делали ещё до дотнета - на эту тему есть отдельная интересная статья: Истории программных революций Microsoft. Ещё посмотри фильмы "Луковые новости" и "Идиократия". Всё это не секрет, это открыто, легально, лежит на поверхности, я никакую новую планету тут не открываю. Потому многие и не замечают всего этого: оно слишком очевидно. Хочешь что-то хорошенько спрятать - положи это на самое видное место.

Если ты чистоплотен и хочешь покинуть цикл говноворота в программировании - просто уходи от С++ в экзотику, к языкам, нацеленным на скорейшее получение продукта. Только и всего. Правда, душевая будет немного болезненной, т.к. потребует предъявить на входе умение использовать Unix-like, а это отдельная головная боль. Проще всего начать с Mageia или Ubuntu, но даже для использования Cygwin тебе придётся прочитать немало литературы по никсам - что такое make, пакет, репозиторий, Git и прочее. Но про bash лучше всего читать Unix-Haters Handbook. Там тоже не всё гладко, но так исторически сложилось, что для вменяемых языков эта среда родная, так что отмыть голову можно, но ногами придётся остаться по колено в болоте. Простуда, как видишь, неизбежна, только у программистов её основным симптомом является не соплетечение, а красноглазие. Соответственно, надо следить за здоровьем, заниматься спортом - это защищает и от застойных явлений в кровотоке головного мозга, и от спинно-мозговых грыж (работа-то сидячая).

5.

На позывы к ООП ты неизбежно напорешься, да уже небось напоролся. Так вот знай, ООП есть Smalltalk. Также оно есть CLOS, Python, OCaml и другие. Но С++ не имеет с ООП ВООБЩЕ НИЧЕГО ОБЩЕГО. Учебники по С++ будут тебе кричать обратное - не верь ни единому слову. Ian Joyner прекрасно рассказал, какие фундаментальные ошибки допустил труп мудака страуса при выдумывании С++, что сделали его столь неэффективным, невыразительным и негибким инструментом разработки. Показательно, как Линус Торвальдс (это ведущий разработчик ядра Linux, если ты не в курсе) относится к С++. Сам ты не поймёшь причины всей этой ругани, пока не изучишь грамотно продуманные языки, разработанные по науке, а не левой пяткой по пьяни. Да-да, природа С++ к науке не имеет никакого отношения. Существует даже такая книга "Design & Evolution of C++", где автор на нескольких сотнях страниц объясняет, почему за 30 лет развития его творение пока только намазывается хорошо. А ответом, собственно, является само название книги. Просто, видишь ли, язык НЕ ДОЛЖЕН эволюционировать. Ни в коем случае. Он должен проектироваться как целостная формальная система. Результатом такого проектирования становится формальное определение языка. Его можно раз в декаду пересмотреть и облагородить на основе накопленного опыта крупных разработок, но чаще это означает выбрасывание или видоизменение чего-либо имевшегося, нежели внедрение чего-то нового. Имеются ввиду не библиотечные накопления (такие как поддержка юникода), а семантические возможности языка - т.е. те самые степени свободы, которыми ты можешь мыслить. Стандартизация библиотек - совершенно отдельный вопрос, тут хорошим примером служит Common Lisp. Сам Лисп с 1960-го года по сути не изменился, как был языком из десятка конструкций, так и остался. Но уточнений и наработок по нему за десятилетия отработки на очень серьёзных задачах (на С++ не решаемых физически) накопилось СТОЛЬКО, что их лет восемь только пересматривали, прежде чем выбрать те, что достойны стандартизации. С++ идёт прямо противоположным путём - регулярно выпускается СТАНДАРТ, который ПРЕДЛАГАЕТ новые возможности, хотя никто не просил. И "стандарт" этот непортируем по своей природе, т.к. пестрит словосочетанием "implementation-dependent". Было бы смешно, если бы не было так грустно.

Иногда некоторые одарённые от природы интуитивно понимают-таки, что работать надо как-то иначе, и приходят к чему-то вроде Тёмного программирования. Не смотря на название, это посылы светлые, хорошие, но единичные, запоздалые, несмелые и главное неформальные, так что окружающие быдлокодеры не поддерживают - ты видишь, сколько там в камментах дебилов несогласных. Зная же грамотные языки, ты и с С++ легко управишься, но тебе, в отличие от закоренелых С++ишков, откроются не только все его подводные камни, но и более-менее вменяемые способы эти камни обходить. Что бы тебе ни свистели в уши С++ишки, ГРАМОТНО на нём может писать ТОЛЬКО матёрый MLщик/Хаскельщик. Однако, в последнее время развелось немало людей, которые кроме С++ и Java знают ещё Haskell, Python, Erlang, J/K, Ruby (в разных сочетаниях). Эти более-менее представляют степень уродства С++, но тем не менее избавляться от него самого даже не помышляют. Хуже того - часто они смеют вслух вякать, будто его уродство неизбежно для эффективности - ведь прочие названные языки тяжеловеснее в среднем на порядок-другой. Потому и важно начинать с SML или OCaml - они легко уделывают С++ по эффективности в хвост и в гриву, и, более того, трюки с повышением эффективности обязательно рассматриваются в учебниках. Вот тебе лабораторное испытание в арсенал аргументов (ибо поспорить с С++ишками тебе со временем неизбежно придётся):
Ray Tracer Language Benchmark

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

Всякий язык может быть хорош на одних задачах и плох на других. Только вот не существует, уверяю тебя, такой задачи, для которой С++ был бы оптимальным выбором. Для всякого, без исключения, случая применения С++ в истории всегда сущестововал инструментарий, который позволял бы получить результат намного лучшего качества при намного меньших затратах. Использовался он по единственной причине - люди искренне верили, что изучить другой язык труднее и дороже, чем воевать с известным. А это заблуждение в них воспитано самим С++, которой был преподан им со школы, и при этом держит мировой рекорд сложности (об этом писали ненавистники Unix). Объективной же критики (если брать программиста не лодыря, а свободно владеющего широким спектром языков) С++ не выдерживает. Изучать его имеет смысл лишь в качестве образца того, каким не должен быть язык, в качестве идеальной коллекции анти-паттернов в задаче создания инструмента для разработки. По этому показателю Кобол ему определённо уступает.

Хороший программист обязан знать Си. Но не надо путать (и позволять другим путать!) Си и С++. Несмотря на то, что формально С++ является надмножеством слегка видоизменённого Си, программирующих на Си как на подмножестве С++ надо гнать взашей. Торвальдс сказал об этом. Так что не углубляйся в С++ - учи Си, Lisp, ML. Потом учи Forth, Smalltalk, Prolog. Погляди что такое программирование продолжениями (continuations) и программирование ограничениями (constraints, и constraint programming). Ты удивишься, но всё это вместе проще, чем один С++, а твои возможности такой арсенал расширяет несоизмеримо. Тебе будет первое время трудно воспринять многое, потому что не будет вериться, что четыре строки кода на некотором языке делают больше, чем сорок экранов кода на С++. Тебе будет казаться, что ты чего-то недопонял, что-то упустил. Не может же такого быть, чтобы миллионы леммин... Или может? Прозрев, ты сможешь играючи решать задачи, которые на С++ либо не решены потому, что ВНП всей планеты не хватило бы, либо не решаются физически. Ну то есть "проще и легко" в смысле по объективным показателям качества ПО, но ума и знаний для освоения и использования от тебя потребуется несколько больше (т.е. действует принцип "день потерять - потом за пять минут долететь"). Если осилишь, то после этого ты и сам будешь от С++ плеваться. Если не осилишь - ну, что ж ... Знай своё место. Тот, кто ПОНЯЛ суть этих технологий, не отзовётся о С++ положительно НИКОГДА. Гарантированно. В качестве примера преимущества: любая программа на SML корректна. На Ocaml - почти любая. Т.е. программа либо не существует (не компилируется), либо не глючит. Она может вести себя не так, как хотел пользователь, если программист неверно понял задание или просто что-то напутал, но она никогда не вылетит с Access Violation и не испортит открытый файл. То же верно и для языка Ada, только на Аде разработка идёт в девять раз медленее, чем на С++, а на ML - в девять раз быстрее. Как ты понимаешь, при таком положении вещей говорить "я знаю ML, но люблю С++" будет либо наглый врун, либо мудак.

Функциональные языки часто преследуются впечатлениями, будто они все надмозговые, сделаны надмозгами и предназначены сугубо для надмозговых задач. Это иллюзия. Среди них есть вполне доступные, практичные, приземлённые языки. Просто повседневные задачи, решаемые с колоссальными усилиями на мейнстримовых языках, на ФЯ решаются настолько просто, что авторам учебников часто даже внимание им уделять лень: страница постановки задачи и две строки кода. Им интереснее решать на ФЯ задачи, которые на мейнстримовом говне либо не решаются совсем, либо решаются с заоблачной трудоёмкостью (т.е. на практике всё равно не решаются). Тем не менее, найти простые, не парящие мозг книжки можно, например вот.

Труп Страуса высказал умную мысль: "все языки делятся на функциональные и те, которыми все пользуются". Делая поправку на его глубокобыдлокодерскую квалификацию, уточняем слово "все" до 95%, и всё становится на свои места.

Очень красивые, простые и показательные примеры, наглядно подтверждающие всё вышесказанное - это Паттерн Команда, Паттерн Стратегия и Паттерн Посетитель. При всей пафосности и громоздкости этих конструкций, они вызывают удивление самим фактом своего существования, если ты уже знаешь, что такое Функция высшего порядка и Алгебраический тип данных. Функции высшего порядка в простейшем виде ты уже встречал - это callback-функции, передаваемые через указатели в качестве параметра другим функциям. Так вот, буквально, "паттерн Команда" - это ООПное изображение функции высшего порядка. Примерно как есть суп ложкой, зажав ложку в столярные тиски, закреплённые на верстаке, и, либо ворочая верстаком по всей комнате и пытаясь попасть ложкой в тарелку, либо подсовывая тарелку под закреплённую ложку. Вот так, людям проще изобрести хитрый способ использования неподходящего к задаче инструмента, чем сменить инструмент. Вот тебе и объяснение про Джаву - в ней ВООБЩЕ нет функций высшего порядка, т.е. нужно ВСЕГДА строить "паттерн Команду". Почитай Исполнение в Королевстве Существительных. Да, после секунды раздумий мы приходим к тому, что у JavaScript с Java из общих черт одно только название, и википедия наглядно показывает разницу. К сожалению, JavaScript часто используют закостенелые Джависты-С++ишки, так что найти там говнокод труда не составит, а хороший ещё придётся поискать.

6.

Теперь о том, ЧТО программировать.

Нельзя ведь "просто программировать" - можно решать конкретные задачи. Даже если в мечтах ты хочешь создать Искусственный Интеллект, который бы сам себе развивал свои алгоритмы мышления и потом решал конкретные задачи за тебя, а ты бы с попкорном сидел перед монитором, закинув ноги на стол - всё равно, эти самые эволюционирующие алгоритмы ты должен написать. Это, кстати, не мечта, такие вещи реально пишутся, но уж точно не на C++, ибо от языка требуется такое качество как homoiconicity, т.е. представление кода самой программы как данных, которыми эта же самая программа может вертеть в процессе своей работы, изучая, изменяя и расширяя саму себя.

Так вот, в процессе изучения любого языка неизбежно рассматриваются те или иные задачи. Но для разных языков разные. Курсы по быдлокодерским языкам начинаются с "принт хеллоуворлд". Курсы по ФП начинаются с расчёта факториала. Есть курсы, ориентированные на первональное изучение программирования (такие как SICP или "ML for the working programmer"), а есть ориентированные на уже опытных программистов, которые уже знают все основные элементы семантик для разных классов языков и просто хотят расширить арсенал инструментов (такие как курс лекций Душкина по Хаскелу). В первом случае задач много, и они тянут математику на том или ином уровне. Иногда соответствующий мат.аппарат рассказывается прямо по месту, но чаще учебник предполагает, что ты этим мат.аппаратом уже владеешь, и лишь хочешь научиться реализовывать его на ЭВМ. Обычно такие вещи как аналитическая геометрия или транспонирование матриц включаются неизбежно. А это значит, что изучать программирование раньше лет 16 оказывается затруднительно - нужна полная школьная база, хотя что-то можно подтягивать и попутно. Во втором случае (ориентировка на опытных) в качестве учебных примеров мелькают фрагменты, с которыми любой опытный программист неоднократно сталкивался в сложных проектах, но которые новичку в двух словах никак не объяснить - т.е. своего рода профессиональный жаргон. С этих курсов начинать нежелательно, т.к. в твоей структуре знаний окажется много дыр. Люди, которые учили программирование по второй схеме, например, могут гордо заявлять, что знают С++, и при этом не быть способными объяснить, чем отличается new от malloc. Или ещё хуже, полагать, что паттерн-метчинг - это встроенный в язык паттерн Composite-Visitor. Чуишь, да? Если ты это сейчас запомнешь и станешь повторять как мантру, то вырастешь напыщенным и глупым. Ты должен пройти всё по порядку, встретить эти понятия последовательно, вникнуться в них и прийти к этому выводу самостоятельно. А может, и к другому. Может, я здесь всё с ног на уши перевернул - тебе почём знать? Проверяй, и всему своё время. Упёршись в некий тупик, просто переключись на другой курс, по другому языку или другой сфере применения. Старайся развиваться вширь, а не вглубь. Детали, там библиотеки и API всякие, зазубривать ни в коем случае не надо. Ни один настоящий специалист ни в одной дисциплине никогда не держит в голове все константы и формулы - он знает суть и умеет работать со справочной литературой. И хорошие институты именно этого и стараются добиться от студентов. Школа С++ же ничего не проверяет, она просто постулирует. Их есть Си С Двумя Плюсами, ибо их есть Наше Всйо.

Допустим, тебя интересует веб со всякими XML, JSON и т.п. На С++ эти вещи изучаются отдельными курсами и требуют подключения громоздких библиотек. На иных технологиях они же воплощаются настолько просто, что я даже напрягаться со ссылками не стану. Стал бы я давать ссылку на подробное рассмотрение того, как на С++ прибавить три к двум? Посмотри что такое SXML - это вся XML Schemа с XSLT вкупе, только на уровне два плюс три, если ты уже владеешь языком Scheme. Облачка там всякие перестают быть проблемой для Erlang, Rebol. А уж для продолжений - и всё веб-программирование: SISCweb. Особенно хороша картина выплывает при усложнении задачи, вот эпичный холивар на эту тему. Также ты неизбежно столкнёшься с GUI, и тебе наверняка скажут, что ООП тут самое место, и что особенно рулит Qt. Фигня. ООП в GUI только мешается. Примеры хорошей гуйни: Tcl, Fudgets, eXene. Интересный пример wxHaskell - привязка ООПной библиотеки wxWidgets к не-ООПному языку Haskell. От ООП там не остаётся и следа, и как прямое следствие, код получается лаконичен. Самый детский пример, проще которого опускаться уже некуда - это реализация разных структур данных: списка, стека, очереди, дерева, словаря и пр. На С++ это настолько трудоёмко (минимум по 3-5 дней работы на каждый с учётом отладки, а с требованием отменной портируемости и того больше), что без библиотечной реализации их применение немыслимо. Отсюда и всякие STL'и с бустами. На ML или Haskell эти структуры данных сами определяются по одной-две строки кода, в чём ты убедишься при изучении понятия "алгебраический тип", и строк по пять-десять нужно на основные методы (всяких вспомогательных, которыми С++ная реализация обязана пестрить, типа конструкторов копирования, деструкторов и прочего хлама, вообще не требуется). Т.е. их все можно слабать за день. Отладка, как я уже говорил, не нужна - если оно скомпилировалось, значит оно корректно и портабельно. В результате, то, что бригада жалких С++ишек пишет за полгода, один Хаскельщик пишет за пару недель. Т.е. если продукты продавать в Майкрософтовских масштабах маркетинговой политики, то денег на душу программиста за тот же продукт достанется в сотни раз больше - всё зависит от того, ЧТО ты будешь писать, и для кого.

Как видишь, я не случайно сделал акцент на языках, отбросив в сторону технологии. Успешные технологии становятся кросс-языковыми; более своеобразные слишком легки для усвоения по месту, чтобы зубрить их заранее. Главное - теория, суть.

7.

А таки нужна ли программисту вообще математика? И да, и нет, но скорее да. Математическое образование положительно влияет на склад мышления. Программист, не знающий банальных основ, не только не сможет решать интересные задачи, но и на детсадовских задачах будет писать индусокод. Понимание многих идей, лежащих в основе языков, часто зависит от понимания основ некоторой мат.модели (к примеру, ООП - есть суть теория множеств... но законченные ООПшники этого уже не понимают, для них ООП - это что-то вроде законов физики во вселенной программирования). Но для эффективного использования Эрланга не нужно зубрить выкладки Милнера по пи-исчислению. Раз уж я уже ссылался на Торвальдса, сошлюсь ещё раз: в недавнем интервью он сказал, что в программистской практике ему математика не требуется, но если бы он мог прожить жизнь второй раз, он бы всё равно её учил.

Вот знание аналитической геометрии и векторного-матричного исчисления нужно практически везде, я что-то не припомню такой задачки, где бы не потребовались хотя бы декартовы координаты или какой-нибудь синус. Эта такая азбука, что её даже забывают упоминуть. Много где бывают нужны основы теории вероятности и статистики. Если твоя цель - игродельство, то самое сложное, что тебе из математики потребуется - это алгоритмы поиска на графах и численные методы решения дифференциальных уравнений, да и то не всегда. Вот если реально хитрый AI делать будешь - то там уже интереснее, там и теория игр тебе будет, и много чего.

Гораздо важнее знания определённых прикладных наук, для воплощения которых ЭВМ и должна использоваться. Скажем, для разработки CAD/CAM/CAE нужна и стереометрия, и всё машиностроение, и куча разных физик - механика, тепловая и пр. Чтобы делать грамотный GUI, не рискуя получить нечто вроде этого нового дебильного Ribbon (от которого нормальных пользователей тошнит, а идиоты привыкают по схеме "и зайца можно научить курить", после чего имеют наглось заявлять, что он будто бы, тьфу, удобен),- нужна инженерная психология. Для разных моделирований - химических, планетологических, социологических - куча высшей математики, даже перечислять не буду - надо будет, узнаешь. Криптография - вообще самостоятельная вещь, там один матан, к собственно программированию отношение имеющий слабое. Необходимую базу ты почерпнёшь из учебников по соответствующим предметам. Главная мысль, которую я пытаюсь донести - что программирование должно быть не более чем средством для воплощения конкретного замысла, а не самим замыслом. Не будь наёмником, даже если работаешь по найму. Специализируйся на какой-либо прикладной дисциплине, воспринимающий ЭВМ как инструмент, а не как объект изучения. Это крайне важно. Не занимающиеся конкретными прикладными дисциплинами "голые программисты" часто создают откровенную ахинею. Например, в тех же CAD/CAM/CAE некоторые дебилы отождествляют машиностроение либо со стереометрией, либо с физикой, не понимая, что такое чисто инженерные знания как отдельная сфера со своими принципами. Или, наоборот, не осиливают выстраивать модель инженерного дела по законам информатики, получая нечто вроде Askon Kompas. Прескверное дело - "программировать, как задали; раз я получаю деньги, значит я профессионал". Нужно изучить и предметную область, и людей, которые в неё погружены с головой - чего они хотят от продукта здесь и сейчас, чего ожидают в перспективе, какие мелочи являются для них слишком очевидными, чтобы прописывать их в ТЗ.

В идеале программист должен под каждую задачу делать так называемый предметно-специфичный язык (Domain Specific Language, DSL), который воплощает в цифровом виде все особенности профессионального знания, и синтаксически похож на соответствующий жаргон. Такой язык приближает компьютер к пользователю куда эффективнее, чем все свистоперделки, вместе взятые. И этот "идеал" всё ближе, все легче достигается. Сейчас умелые люди играючи делают DSL почти под каждую задачу чуть сложнее хелловорлда. Что забавно, так это то, что оно автоматически стягивает все прочие составляющие программирования. Т.е. умеющий хорошо реализовывать языки автоматически хорошо умеет решать почти все остальные задачи программирования. Ещё забавнее, что это же и проявляет ненужность ООП, т.к. большинство вменяемых людей отдаёт себе отчёт, что ООП в компиляторе или интерпретаторе нужно как козе пятая нога. Поэтому умение разрабатывать языки под любую задачу - это то, к чему ты должен стремиться. Присыплю голову пеплом: это требует весьма немалых знаний информатики. Как только ты залезешь в разработку языков, то сразу потянется целый ворох матана. К счастью, основная теория по этой теме в прикладном виде собрана у Ахо-Сети-Ульмана и переведена на русский.

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

8.

Возьмём такую актуальную задачу как формальная верификация. Ты, наверно, уже слышал о системах статической проверки программ на С++? Там много матана - логика предикатов, разные теории типов, и др., однако всё автоматическое доказательство неизбежно упирается либо непосредственно в Хиндли-Милнера, либо в другой узел лямдба-куба. Вообще такие задачи как исследование определённого свойства программ (например, корректности), автоматическое эквивалентное преобразование программ, автоматическое порождение или даже эволюционное выращивание программ - всё это принципиально решается ТОЛЬКО с использованием функционального или логического подхода. Т.е. если ты простые задачи начал решать на ML, то когда придёт время, твоя голова будет ГОТОВА вместить более серьёзные задачи. А если ты всю жизнь занимался С++, то ты только и сможешь задействовать чужие дорогостоящие вещи, разработанные другими людьми на Lisp/ML/Prolog, т.к. ни понять их уже не сможешь (см. Сепира-Уорфа), ни из С++ этих решений не выжмешь.

Пример религиозных заблуждений и объективного, математематически обоснованного опровержения. С++ишки с остекленелым взором твердят, что ручное управление памятью будто бы эффективнее, чем заложенное профессионалами в компилятор с учётом проблем аппаратной архитектуры, ставших следствием экономических соображений. На деле Garbage Collector заведомо эффективнее. Банально: удаление одновременно кучи объектов требует одного входа в функцию управления памятью и одного выхода, и счётчик объектов сбрасывается одной командой; а если ты удаляешь N объектов по одному, то ты имеешь N входов, N возвратов и N операций декремента счётчика объектов. Есть и более интересные детали. У Окамла GC развит до небес, там штук пять разных стратегий сбора применяется, и язык выбирает оптимальную для каждой переменной. А в результате программа в два раза компактнее, в сто раз стабильнее и при этом работает с той же скоростью, что и на С++. Просто в realtime GC не всегда допустим (это любимая отмазка плюсистов, хотя realtime-задач в мире процентов так ажно два с половиной). Но есть ещё такая штука - region-based memory management, он позволяет собирать мусор за константное время (см. MLKit), и С++ тут может только шмыгать носом. Этого нельзя добиться ни перегрузкой оператора new, ни даже залезанием в компилятор, тут требуется перекраивать всё определение языка под ноль, всю грамматику и семантику, получая новый язык, не совместимый со старым. Например, так был получен язык D (нет, я его не рекомендую, и регионов там нет, просто как пример - что станет с С++, если таки убрать ручное управление памятью). Если же определение языка построено с учётом того, что ненужные значения растворяются в воздухе сами, то разработчики компиляторов получают полную свободу действий, и могут выбирать разные способы управления памятью в зависимости от задачи. В Хаскеле значения даже не всегда вычисляются - большинство значений в программах лишь подразумеваются. Глобально-оптимизирующие компиляторы (MLton, Stalin Scheme, экспериментальный JHC) стараются хвататься за любую информацию, которую можно почерпнуть из исходника, и если значение переменной у тебя не читается извне, а присваивается прямо в программе, то они могут раскрутить его как константу, так что в некоторых случаях сложная не-интерактивная программа с расчётами в принципе может скомпилироваться в "принт результат".

Чаще всего высокоуровневые языки компилируют в исходник на Си, как в кроссплатформенный ассемблер, а заодно и более широко распространённый язык. Смысл порождать код на Си вместо того, чтобы писать его самостоятельно - в повышении скорости разработки и одновременно стабильности программ. В книгах по С++ ты о таких техниках оптимизации не узнаешь, там тебя будут учить как не выстрелить себе в ногу. А ещё будут учить заранее выбирать, считать ли в динамике или на этапе компиляции, и соответственно выбирать один из двух непохожих друг на друга языков - сам С++ или язык темплейтов - т.е. делать работу оптимизатора вручную. Псевдонаука для тех, кто хочет казаться умным. Если тебе надо перейти от обычных int'ов к числам произвольной точности, то в С++ тебе надо переписать всю программу под ноль, чтобы ВМЕСТО int обращаться к библиотеке VeryLongNumber, а в Lisp/ML ничего делать не надо - либо компилятор сменить на тот, что под это дело заточен, либо одной строкой сменить привязку модуля. В каждом варианте код будет настолько эффективен, насколько это возможно, ненужные операции компилятор из машинного кода выбросит, т.е. если ты используешь 32-битный int, то тебе не нужно платить за то, что кто-то использует большие числа. С++ заявляет, что ты якобы "не платишь за то, чего не используешь", но это всё демагогия - на деле ты постоянно платишь за его сложность своей головной болью. Потому функциональные языки и предпочитаются в научных кругах - там у людей на всякую возню с деталями ЭВМ нет времени, у них куда более интересные задачи висят, так что они внедрили знания об ЭВМ в компилятор, и не парятся. А С++ишкам думать некогда, им трясти надо.

9.

Выше я отметил, что ФП развивается под никсами, и портируется на винду со скрипом. Хоть это уже не информатика, а политика, я уделю внимание этой теме, чтобы ты не путался с мотивацией и образцами для подражания. Причина проблем совместимости в том, что все люди, серьёзно занимающиеся информатикой, за десятилетия развития сошлись к единым стандартам, названным POSIX, а Microsoft НИКОГДА не сделает свою ось POSIX-совместимой - для них это было бы самоубийством. Если все необходимые тебе программы свободно портируются, то какой тебе смысл использовать худшую из ОСей?

Орудием завоевания неосознанно стали игроделы. Dедь именно играми и интересуется большинство пользователей. Все остальные приложения давно работали под Unix или Mac (а теперь Apple вообще заменили своё ядро на Linux). Некоторые профессиональные мультимедиа-программы (студийные пакеты для серьёзной работы с графикой и звуком, на которых голливуд рисовал всякие "Матрицы") вообще изначально росли под никсами. Сетевые технологии в винде наследованы аккурат из VMS, о чём можно убедиться на википедии. Да и само ядро было честно стырено с OS/2. Т.е. ничего ценного сам дядя Билли не изобрёл. Типографией с 80-х рулила Adobe, тогда ещё конкурент M$. Слово "portable" в аббревиатуре PDF означает, что тебе не нужна винда для просмотра или редактирования документа - он корректно открывается в любых условиях, а не по усмотрению M$, как ".doc". То же можно писать и про PostScript, и про SVG, и про очень много разных технологий, для каждой из которых M$ предлагает своё конкурирующее непортируемое решение. Так как же всё это говно могло занять доминирующее положение на рынке?

Их вынудили подставить руки, чтобы помочь маленьким и мягким сделать три гигантских хода "конём" через свои головы. Индустрия игр была попросту порабощена Microsoft. Сперва (в начале 90-х) они позиционировали OpenGL как тормознутое 3D (жизнь игроделов в то время в принципе была тяжела, а такая информация в прессе очень способствовала убеждению писать под DirectX). После того, как им показали, что это не так, они как бы невзначай попридержали реализацию своих OpenGL-драйверов на годик. И сделали это аккурат в пубертатный период закона Мура: в момент всплеска пентюхов-MMXов. Этим они добились того, что 99% нового поколения игр вышло реализованными под их DirectX, а не под OpenGL, а потом портировать потрудились немногие. Это создало и школу, и legacy code.

Одним из первых взбунтовавшихся был Джон Кармак - за один уикенд переписал он Doom под OpenGL. Вторым был Сэм Лантига. Работая в Loki Software, он разработал кроссплатформенную библиотеку SDL и с её помощью портировал под Linux десяток популярных игр. Фирмочку, как водится, прикрыли, но Лантига не сдался - он продолжил поддержку SDL самостоятельно и устроился в Blizzard. Не случайно все их игрушки спокойно работают под линухом. Сейчас он работает в Valve, которая фактически вообще объявила мелкомягким войну - им хватает наглости ваять ажно свою платформу. Если такие как Лантига вдруг начнут помирать от рака, журналистам стоит насторожиться и провести аналогию с эпидемией рака среди латиноамериканских политиков. M$ ведь не скрывает своей дружбы со спецслужбами - они даже Skype купили специально для того, чтобы можно было спокойно слушать разговоры по неломаемому протоколу. Опять же, это не секрет, всё гуглится и проверяется (вот навскидку). Они вообще не лыком шиты. Кое-кого они все эти годы сумели удерживать на поводке возле ноги - например, запуск Симсов под линухом не гарантирует даже коммерческая CrossOver. Но это мелкий бой. Истинно военно-тактическим третьим ходом конём была Виста. Просто разработка Longhorn или как там ёё затянулась и вышла из бюджета, и чтобы остаться на плаву, было решено выпустить полупереваренную пищу путём вскрытия пупка. Понятно, что большинство людей не очень любит подобные анатомические мерзости, и M$ рисковала быть забаненным за нецензурщину. Они это знали, и заранее прижали производителей железа к стенке с ножом у горла. Всеми правдами и неправдами вынудили они производителей компов предустанавливать Висту, в результате чего они смогли и дальше хорошо питаться, а производители железа оказались вынуждены писать новое поколение драйверов. Смоделированная "популярность" Висты (в кавычках, потому что пользователи её сносили, т.к. большинство имевшихся на тот момент программ в ней попросту не запускались) дала производителям программ отмашку портировать свои творения. К моменту выхода семёрки M$ были обеспечены всей необходимой поддержкой, так что катях вышел крепкий, твёрдый, даже не вонючий. Многие даже сочли его хорошим, годным продуктом, пока он не начал разлагаться в восьмёрку. Ну не будет M$ отказываться от копроэкономики, нечего даже надеяться на это. Не думай, что они ничего не знают про ФП - ещё как знают. Саймон Пейтон-Джонс (один из создателей Хаскела) у них работает, и F# - их творение. Просто популяризировать ФП им не выгодно, а у себя умных людей держать - пригодится. Единственный способ разомкнуть кольцо зла - писать изначально кроссплатформенные приложения, при необходимости компилируя их под Cygwin или MinGW. А С++ для этого не подходит, т.к. по определению непортируем. И существование GCC с Qt само по себе не является аргументом, спасающим положение: С++ в GCC и С++ в VS - это два разных языка, да и само по себе использование Qt ещё не делает все твои программы кроссплатформенными. Между прочим, Qt/KDE ваяли свой MOC, а не юзали темплейты (главный предмет гордости всея С++), именно потому что непортабельно. Как видишь, всё взаимосвязано - либо Вижуал тебе Студия до глубой старости, либо высокое качество по всем показателям сразу (скорость разработки, портируемость, надёжность, удобство пользования и пр.).

А как обстоят дела с мультимедиа и рилтаймом в ФП? Хорошо обстоят. Есть порты SDL и wxWidgets, есть компиляторы, заточенные под это дело, и компилирующие под самое разное железо и разные ОСи, разрабатываются DSLи с явными конструкциями управления временем. Всё бесплатно и опенсорсно, но разрешается применять в коммерческих продуктах. Тот бенчмарк, что я дал выше, сравнивает языки как раз на 3D-графике, только что без рилтайма. И ядра ОС, и драйвера разрабатываются. ВСЁ, что можно написать на С++, можно написать на функциональных языках, не волнуйся. Библиотеки же ты не переписываешь, ты только сращиваешь их в конкретную задачу, а библиотеки, если сделаны не криворучкой, подключаются куда угодно - это называется FFI (Foreign Function Interface). Всё это ты со временем найдёшь, сейчас нет смысла говорить подробно, т.к., повторюсь, слишком много науки инкапсулировано внутрь языка, и для понимания пяти строк на нём, при всей их лаконичности, нужно сперва как следует поучиться, да ещё немалая часть времени из этого уйдёт только на выбивание из головы последствий С++ного программирования.
« Последнее редактирование: 27 Июнь 2014, 18:59:00 от Al G » Записан
Al G
Интересующийся
**
Офлайн Офлайн

Сообщений: 28


Просмотр профиля
« Ответ #6 : 14 Июль 2014, 23:07:05 »

10.

Ещё один момент насчёт соотнесения математики с программированием. Тема весьма болезненная, т.к. в русской школе программирования, к большому сожалению, это соотношение вандалистически покорёжено отвёрткой. У нас олимпиадные задачи ПО ИНФОРМАТИКЕ (!) зачастую формируются по схеме "дано ровно 255 строк, каждая длиной до 255 символов, надо посчитать общее количество разных слов в них". Простора продемонстрировать искусство программирования здесь как в деревенском туалете. Сложность алгоритма оценивать незачем (раз данные заведомо конечны, то и время программы сильно разниться не будет), структурно задача идеально одномерная, никакого проектирования нет, модифицируемость кода не важна, детерминированность на уровне Капитана Очевидность, так что разработка будет чистейшим waterfall. Т.е. это задача на самом деле-то по математике, а не по программированию вовсе: строишь устные рассуждения, как это делали 100 лет назад (можно даже не самые эффективные) и тупо переносишь цепочку действий на синтаксис чётко озвученного в условиях языка. Если ты предъявишь код на более мощном языке, то тебе скажут "молодец, а теперь перепеши на заданный, а то нам не понятно". Ставят такие задачи "программисты" на Бейсике или Паскале, т.е. другими словами, быдлокодеры с математическим образованием. У нас таких много. Эти дилетанты искренне убеждены, что программирование=математика (где под математикой понимается Евклид и Пифагор, а не Карри и Милнер), и конечно же, что выбор языка программирования дело исключительно субъективное и значения не имеет. Предложи им условия по-интереснее: пусть на входной поток поступает по 255 строк в секунду и словарь надо считать непрерывно, при необходимости раскидывая вычисления на ферму. Они деликатно уйдут от ответа с румянцем на лице. Программисты они такие программисты. В общем, просто хотел предупредить о существовании такого вот мощного демотиватора. Задачи ведь служат мотиватором к постижению инструментов, а такие дилетантские задачи могут здорово подпортить представление о том, что такое программирование и с каким соусом его надо подавать к столу.
Записан
3V
Администратор
Ветеран
*****
Офлайн Офлайн

Сообщений: 1347



Просмотр профиля WWW
« Ответ #7 : 15 Июль 2014, 23:14:23 »

Очень интересно было почитать вас. Очень
Я проникся. Честно  Улыбка

Я вот думаю сына хоть немного приучить к программированию.
И никак не пойму как.
На его компе линух. С самого начала. Но вот фиг. "Не заводится".

Все более прихожу к мысли о том чтобы подсунуть ему питон и какие-то интересные решения на нем.
« Последнее редактирование: 16 Июль 2014, 21:14:40 от 3V » Записан

Al G
Интересующийся
**
Офлайн Офлайн

Сообщений: 28


Просмотр профиля
« Ответ #8 : 29 Июль 2014, 23:08:41 »

Я вот думаю сына хоть немного приучить к программированию.
И никак не пойму как.
На его компе линух. С самого начала. Но вот фиг. "Не заводится".
Даже не знаю, что посоветовать. В наши годы ZX-Spectrum со встроенным Бейсиком заводил ввиду отсутствия чего бы то ни было другого. Современное поколение живёт на всём готовом. Но одна мысль есть. Методологически не отработанная, так что за результат не отвечаю, но попытка не пытка. Закидайте его какой-нибудь рутинной задачей, пока она ему надоест, а потом покажите, как её один раз автоматизировать алгоритмически чтобы забыть про неё навсегда. Лень, как известно, является едва ли не основным двигателем прогресса, так что очень может быть, что сработает.
Записан
apro3
Новичок
*
Офлайн Офлайн

Сообщений: 2


Просмотр профиля WWW
« Ответ #9 : 09 Февраль 2015, 01:23:11 »

5 лет назад я обратился на этот форум в надежде, что из меня сделают программиста.

Я через 8 лет вернулся Улыбка
Записан

Автострахование: ОСАГО, КАСКО, пролонгация.
VivaBrunko
Новичок
*
Офлайн Офлайн

Сообщений: 2


Просмотр профиля
« Ответ #10 : 30 Апрель 2015, 16:43:13 »

время летит очень быстро...
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!