Pull to refresh

Comments 285

Знаю много опытных Java-программистов, которые не знают С++ потому что не пишут на нем. Про С++ — предрассудки.
Знаю парня, который ядром Linux'a и драйверами занимается, т.е. C. Так вот, он совершенно не знает C++.
Статистика за 2012 год? В статье для молодых программистов? Вы серьезно?
У меня вообще по ходу чтения возникло ощущение, что статью писали лет 10 назад и только слегка подредактировали с тех пор.
Очень абстрактно…
Есть несколько хороших мыслей, но большая половина просто вода и вводит в заблуждение.
Такое ощущение что автор где-то рядом с IT но не программист… и даже не веб…
Любят VS. Часто сидят под Linux.

НАУКА О КАСТАХ

Вы серьезно???
Я тоже очень хотел по этому блоку пройтись, но автор его переработал :-( Хотя всё-равно осталось в статье много «странностей».
Напоминает анекдот про математика, который начинает письмо к другу словами «Здравствуй, дорогой Вася! Пусть X — Банахово пространство...»
Материал статьи излагается в терминах и понятиях, знакомых опытному программисту, но отдающимися шумом прибоя в ушах новичка.
Вы этот анегдот только что сами придумали (поиск находит только эту статью)? Серьезно, если напоминает анегдот, то можно дать ссылку.
Анекдот воспроизвёл по памяти, читал его много лет назад уже не помню где. Возможно, в ФИДО. В любом случае, содержание тут воспроизведено полностью и почти без искажений.
Небольшая просьба: можно оформить текст чуть более читабельно? Отступы там, разбитие на абзацы, что бы текст не сливался в один поток… Всё-таки хороший программист как правило умеет оформлять документацию так, что бы читающим её не было больно.
Не любят на хабре посты для новичков, говорю вам как автор подобной статьи.
По теме поста, сам начинал изучение программирования с С++ и могу с полной уверенностью сказать, что это язык не для новичков, его надо знать если хочется программировать что-то сложнее рекламных баннеров, хорошее знание основ языка, работа с указателями и с памятью могут дать понять то, чего не понять программируя только на языках высшего уровня. Однако углубляться в изучение именно С++ стоит только если вы хотите связать с ним свою жизнь, изучить его на 100% практически невозможно, уж слишком это сложный язык.
Согласен про Delphi, молодящийся старичок, ему пора на пенсию и уж точно не стоит того чтобы быть первым языком.
Я начинал изучение программирования с калькулятора MK-61 (не смейтесь, это почти как ассемблер), потом был Pascal/Delphi, потом С++. Считаю С++ вполне адекватным начальным языком, только учить его надо правильно. Во-первых, не весь сразу, а во-вторых, учить именно как С++, а не «Си с классами».
О, живой юзер МК-61.
Не было ли у вас проблемы с отваливающимися регистрами? :)
Нет, не припомню такого. Как в толстенном мануале было описано, так всё и работало :)
Тоже когда-то юзал. Проблемы не было.
думаете удалить пост? )) пока совсем не придушили.
Ну как видите, я посмел высказать своё мнение в комментариях и мне уже высказали своё «фи» в виде негативной оценки. А пост, да, лучше спрятать подальше, пока до 3к просмотров не дошло, тогда магическим образом вылезает нечисть и злостно минусит вообще по любому поводу будь то «слишком много написал» или «слишком мало написал» или «сегодня полнолуние и в такое время я не хочу видеть статьи на эту тему».
UFO just landed and posted this here
Просто написать хорошую статью для новичков зачастую куда сложнее, чем для продвинутых юзеров. Но многие этого не понимают и просто фигачат поток своих мыслей.
Ох как минусуют то )
Да, сыровато написал, но просто наболело.
Сам имею опыт программирования 20 лет.
Секрет в том. что здесь свои мысли надо уметь выдавать за иностранные переводные. Тогда читают намного более уважительно, ругают автора, а не переводчика. Все же знают, что пророков нет в Отечестве своём.
Ну потому что много пустого пафоса и субъективизма. Надо было хотя бы в преамбуле написать, что это личный взгляд и мнение автора. А такие вещи как «программирование — это сугубо исследовательский творческий, а не технический процесс» или «программирование — это процесс полета креативной мысли, часто выходящий за рамки рабочего дня и даже образа жизни» вообще писать не нужно было. Просто потому что это наивно и неправильно. Программирование — это сугубо инженерная работа. Пока вы молодой и незнакомы с паттернами проектирования, у вас есть чувство новизны, открытия чего-то нового, изобретения алгоритмов. Но вы сами пишете, что дескать, ваш опыт 20 лет. И что в вашей работе может быть креативного? Придумать архитектуру очередного бизнес-приложения? Вы их наизусть должны знать. Придумать пользовательский интерфейс? Да вот они, все гайдлайны. Известные вдоль и поперёк.
Если вдруг вам круто повезло в жизни, и вы оказались в какой-то конторе, находящейся на переднем рубеже технологий, поздравляю. Но это будет не потому, что вы программист, а потому, что вы вытащили счастливый билет.
И еще, не обижайте Паскаль/Delphi. Этот динозавр в свою эпоху был крутейшим инструментом, который дал путёвку в жизнь многим программистам.
>>И еще, не обижайте Паскаль/Delphi. Этот динозавр в свою эпоху был крутейшим инструментом, который дал путёвку в жизнь многим программистам.
Многие на нём до сих пор пишут. И открою небольшой секрет, делфи до сих пор крутой инструмент :)
я тоже начинал с TurboPascal under DOS ;) но с делфи быстро ушел на Builder… на ПАскаль возвращаться уже не хотелось… нынешние претензии к дельфи и билдер — очень жирные ЕХЕ… хотя сейчас все жирное.
Но проги написанные на дельфи легко определяю по замедленности интерфейса.
Но проги написанные на дельфи легко определяю по замедленности интерфейса.

Никогда не замечал.
Все проги с замедленным интерфейсом, которые мне встречались, оказывались на Java, или .NET (реже). И то, подозреваю, это связано с кривизной рук.
претензии к дельфи и билдер — очень жирные ЕХЕ

А суммарный «вес» приложения на Qt с приложением на Delphi сравнивали?
проги написанные на дельфи легко определяю по замедленности интерфейса

При условии, что весь интерфейс на делфях практически обёртка над апи, как и MFC, то читать это несколько странно.

Сам уже более 7 лет программист на С++. Но если нужно набросать очень маленькую утилитку для того, что бы отдать наладчикам, к примеру прога по настройке модема, или терминальное приложение по автоматическому редактированию файлов настроек embedded linux — делфи рулит больше билдера (билдер не люблю со времён борланд, говорят многое поменялось, но мне проще в студии плюсы использовать), ибо апликация на делфи полностью самодостаточна и «весит» 500-600 кб, а если ещё и upx применить — раза в два меньше. То же самое на Qt займёт от 50МБ.
У Delphi проблема в том, что если из всего класса используется только один метод из сотни — то в бинарник тянется весь класс и, соответственно, все зависимости по иерархии полностью.

Не знаю, осталось ли это на текущий момент, но года два назад так и было ещё.

Именно поэтому бинарники огромные, потому что для Hello world тащится ВСЯ библиотека VCL.
Не уверен, что это решило проблему, но отмечу, что с Delphi 2006 (он же BDS 4.0) есть поддержка .NET-компонентов.
Во-первых, .NET уже не поддерживается, это был Delphi.NET.

Во-вторых, как бы это помогло?
Понимаю, что .NET устарел. На тот момент, .NET был в самый раз.
Не уверен, но скорее всего, Delphi тоже идет в ногу со временем.

Delphi.NET — это обертка над .NET. Это не полноценная реализация .NET, а лишь провайдер, соединяющий Delphi с .NET. Это сделано для того, чтобы компоненты могли вытаскиваться на форму. В противном случае, .NET компонентами можно было пользоваться хоть на Delphi 7. Только, приходилось бы их создавать и манипулировать непосредственно из кода программы.
.NET не устарел, просто в Дельфи он больше не поддерживается.

Delphi.NET делал ненативные бинарники для платформы .NET (CLR).
30Кб это жирное приложение? Смотря как делать, знаете ли. Можно и 20Мб сделать, а можно и в тысячу раз меньше. Зависит от задач.
В тысячу раз меньше — это тридцать байт?
Посмотрел бы я на такое приложение.
30 байт — это в 1024 раза меньше. Кстати, ничего, вполне пригодный объем для некоторых программок в COM-формате.
На приложение размером в 30.72 байта я бы посмотрел с ещё большим интересом.
Могу ошибаться, но реализация format.com в MSDOS, как раз, занимала около 30 байт.
Точно, ошибался. Стало интересно, скачал DOS 6.22, там format.com занимал 23кб.
Давно это было, когда учился еще в школе. Вспоминаю.
По всей видимости, речь шла не о самой format.com, а о том, что можно набрать в .com-файле, что бы выполнилось что-то вроде format.com c: /q. Из рабочих инструментов Norton Commander и Turbo Pascal. А сам DOS был урезан на вредные утилиты типа format.com.
На чистом ассемблере без help-а и парсинга параметров вполне могла уместиться в килобайт.
На Turbo Pascal сделать программу в 30 байт нельзя, в силу того, что во-первых он умеет компоновать только exe-файлы (по крайней мере, если не брать в расчет самые первые три версии), во-вторых, он все равно впихнет в бинарник базовые структуры модуля System, и несколько килобайт это займет.
На чистом ассемблере… если просто в цикле вызывать int 13h с подфункцией форматирования для всех цилиндров/головок накопителя, то думаю байт 20 вполне хватит для такой чудо-программы.
Эта функция вызывает соответствующую команду накопителя, а они уже давным давно её банально игнорируют, наверно уже не осталось в мире таких винчестеров которые по честному выполняют команду форматирования(это наверно все винчестеры объёмом не более 300Мб). Это так называемое низкоуровневое форматирование.
А нам нужно уничтожение данных… а это запись напрямую в сектора и создание чистой главной директории и чистой FAT.
По-моему, мы просто обсуждали, сколько байт могло понадобиться для простой утилиты форматирования во времена DOS, а не о том, чтобы грохнуть винт :) Мы даже не говорили о том, что надо было форматировать винт, а не дискету, например.
Форматирование через 13-е прерывание и есть банальное уничтожение данных. Оно не создаст автоматически FAT на диске.
Зачем Turbo Pascal?

Тут нужен всего-лишь hex-редактор. Программу набирали вручную, списывая код с листочка (так как дисководы были отключены).
Не нужен никакой HEX-редактор… любой редактор способный сохранить файл без форматирования и не реагирующий на спецсимволы. ALT+<код> на цифровой клавиатуре.
Фига… не больше сотни байт.
Всего-то загрузить в регистр указатель на область памяти с мусором(опционально можно выделить и очистить нулями) размером 512 байт, инициализировать регистры нужными значениями(код функции, начальный сектор диска) и вызвать int 13h фунция 03h(по-простому но медленно, или 0Bh побыстрее но мороки больше) в цикле по всем секторам и дорожкам диска(функция 08h). В конце цикла вызвать INT19h и аллес…
Всё это укладывается менее чем в 100 байт COM-файла. Помешать может только защита записи в 0-й сектор на уровне BIOS-а или хитрый резидентный антивирусник перехватывающий 13-е прерывание который не даст затереть загрузочный сектор и FAT.
Вот я и говорю, переписывали содержание «format.com» на бумажку, и по бумажке набирали содержание «format.com» через hex-редактор.

В те времена, в школе дисководы были отключены, а дома даже принтер — это уже роскошь!
Приходилось переносить .com-файлы ручками через бумажку.
Все 23КБ через бумажку переносили?
зачем? там без help-а и разбора параметров легко уложишься в 100 байт. А то и в 50!
Издеваетесь что ли?
Исходники MS-DOS 2.10
FORMAT.ASM занимает 46КБ, 1627 строк, из них разбор параметров — примерно 80 строк. Хелпа в той версии не было вообще.
В комментарии Alexeyslav — программа, затирающая служебные сектора мусором.
В вашем комментарии — «format.com без help-а и разбора параметров»
Надеюсь, вам не нужно объяснять, что format.com — это не просто «программа с хелпом и разбором параметров, затирающая служебные сектора мусором»?
Если 20Мб \ 1000 = 30 байт, то я уже и не знаю.
Так в билдере те же библиотеки, как можно определить что оно на дельфях?
cmdline-приложения отнюдь не были жирными. Полагаю, основной объём exe-шника простого приложения — вкомпиленные части VCL. И то получалось и даже сейчас получается сравнительно компактно, если сравнить с exe-шником такого же приложения, скомпилированным в том же Lazarus.
Потому что RTTI-фреймворк. Когда предполагается, что компоненты будут динамически создаваться прямо в рантайме, причём возможно с подгрузкой из внешнего источника, линкер не может выкинуть всё то, что не используется приложением, ведь оно может понадобиться. Отсюда в бинарник попадает очень много неиспользуемого кода. Кардинально проблема решается лишь отказом от высокоабстрактных фреймворков.
В том же Delphi, если создавать приложения без VCL, на чистых API или с использованием альтернативных фреймворков, получалось очень компактно, по крайней мере на момент начала 2000-х годов вполне сравнимо с C++ компиляторами от Microsoft. На Delphi даже 64Кб-демки писались (создать окно через WinAPI, подключить OpenGL и вперёд).
Более того, Delphi был вполне пригоден для системного программирования. Во времена Win98 мне даже доводилось на нём VxD-драйвер писать. Для этого отключалось всё лишнее, вплоть до кода инициализации/финализации приложения (Delphi позволял и это!), объявлялись внешние символы, а среда настраивалась на создание obj-файла, который потом преобразовывался в VxD при помощи линкера из комплекта Win 98 DDK.
Простите, не удержался. В 2005м на делфи как раз таки пробовал что-то собрать типа демосцены. Вышло 163Кб, правда из них сто тридцать музыка жрёт.
batteryeater.com/temp/sota.zip
В трекерном модуле больше всего места занимают сэмплы. Я бы для уменьшения размера заменил MiniFMOD на uFMOD, предварительно сохранив сэмплы с использованием APDCM и обработав трекерный модуль XMStrip.
Ну а вообще, конечно, самый труЪ-способ — линковка трекерного модуля вообще без сэмплов, которые потом генерируются в рантайме при помощи FM-синтеза. Раньше по этой тематике можно было найти множество статей, сейчас же в связи с резким падением интереса к демосцене (бабла же она не приносит, а современные кодеры даже вирус не сядут писать без предварительно составленного бизнес-плана), большинство ресурсов уже умерло вместо со всем содержимым.
VCL в общем-то у них тоже не очень-то жручий. У меня вполне себе на нём получалось писать не особо сложные прикладные программки со стандартными компонентами без интерфейсных наворотов; exe получались объёмом меньше мегабайта (на Delphi 2009). При этом можно было отдельно положить в дистрибутив bpl-ку с VCL (у 2009 она чуть больше мегабайта размером), и тогда exe занимал вообще десятки килобайт. Сейчас делаю на нём системные службы для выполнения некоторых задач на Windows-серверах. Язык в целом нравится: строгая типизация дисциплинирует, возможностей ООП для большинства задач ИМХО вполне хватает.
И еще, не обижайте Паскаль/Delphi. Этот динозавр в свою эпоху был крутейшим инструментом, который дал путёвку в жизнь многим программистам.

Darthman всё верно говорит про современное использование.
Именно так, например, известный и популярный плеер для Windows уже кроссплатформенный — AIMP как раз на Delphi написан.
Полистал сайт AIMP-а. Кроссплатформенность это наличие плеера под Android?
Да и версия 2.0 переводится на общую кодобазу с виндовым вариантом.
Кто это Вам сказал? Мне вот автор AIMP'а подсказывает что никакой общей кодобазы нет.
Хм, странно, видимо я ошибся и перепутал с другим проектом.
Спорная и консерваторская заметка.
Напоминает старческий хрип.
согласен что спорная… тема очень холиворная, я же предупреждал вначале.
но для новичков тут много бесценного материала. Дальше они сами найдут свой путь.
P.S. и да… кхм кхм…
Насчет «много» — спорное утверждение. Как минимум не упомянуто модульное тестирование и функциональные языки программирования (Haskel, Erlang...). Да и веб-разработку Вы как-то ограничили только PHP.
Опять же какие-нибудь относительно новые языки типа Clojure, Scala, Go, Rust не были упомянуты.
А необходимость знать C++ — довольно спорное утверждение. Много тонкостей которые актуальны, только при его использовании как основного языка. Без их знания читать код написанный профессиональными программистами будет сложно, а на их изучение нужно много времени, которое лучше потратить на более детальное изучение понравившегося языка.
И конечно прикладному программисту стоит изучить и попробовать несколько языков, чтобы уметь выбрать более подходящий для решения той или иной задачи :)
для новичков тут много бесценного материала

Простите, но это хвастовство.
То, что вы пытались рассказать в статье, давно написано в первых 5 главах (специально проверил) у Макконнелла.
Причем написано гораздо лучше и без восхваления одного языка и опускания других.
Автор — явно дельфист. Написано много, когда написать можно было то же самое, но в три строчки.
И это ж надо перепутать C и C++.
не дельфист. Но VCL-щик. Хотя есть проекты и на QT и Java и на С++ под Linux.
А что я перепутал с С и С++?
И вот опять… Перепутал Qt и QuickTime (aka QT).

:-)
не дельфист

Ну, паскалист. Это одно и то же. Они характеризуются тем, что не могут лаконично выражать мысли, так как не привыкли писать лаконичный код.

А что я перепутал с С и С++?

Ну, всё, что ты написал про C++, относится к C. То есть ты не знаешь разницы между этими двумя разными языками.
Мир на C++ клином не сошелся. Да, это основной системный язык на данный момент. Но как язык — он не очень. Скорее всего в долгосрочной перспективе будет замещен чем-то другим.

А про производительность — чушь. Нередко та же Java обгонит программу на С++ за счет статистического анализа. Или, во всяком случае, отработает не хуже.
Согласен. Мир клином не сошелся. Но много лет подряд C++ был практически панацеей, потому что ничего больше не было. Сейчас есть выбор!
Но обратите внимание, что операционные системы продолжают почему-то писать на С++.
Потому-что они уже были написаны на плюсах и переписывать нет смысла?

Существует полно ОС (написанных в учебных целях), написанных, например, на расте. Но вообще написание ОС — ну очень специфическая задача.
Единственная операционная система на C++ из распространенных — Symbian, и она уже давно мертва
Да он даже не разбирается, где какой язык.
Про операционные системы написанные на С++ это Вы Линусу скажите. Привести его цитату про плюсовый код в ядре Линукса? :)
Он, кстати, это сказал ещё в 2007 что ли году. И, кстати, многие мнения о C++ сложены на основе стандартов C++98/03
Статический анализ чего и как это связано с производительностью Java?
статистический анализ, было сказано. Анализируется статистика выполнения программы в рантайме и под нее модифицируется машинный код, например, инлайнятся процедуры.
Пардон, оговорился. Статистический анализ ветвлений в коде, типов передаваемых аругментов и вызываемых методов. JIT-компилятор Java в процессе исполнения меняет исполняемый байткод с учетом этих данных. Причем в процессе работы сгенерированный байткод может меняться многократно.

Допустим у вас есть сервер, который примиает POST и GET запросы (представленные разными классами на уровне кода приложения). И какой-то кусок кода, который в зависимости от запросов что-то делает.
Если вы на такой сервер в рамках-стресс теста натравите непрерывный поток POST-запросов, то JVM может решить перекомпилировать некоторые методы под оптимальную обработку конкретно POST запроса (возможно в ущерб производительности GET-запросов).
Такой анализ, который вы описали, стоит дороже чем выигрыш от каких то потенциальных оптимизаций по его результатам
Смотря какой временной интервал рассматривать.

PS: Разработчики Java JIT как бы не дураки и тоже это учитывают. В частности, тот код, который выполняется всего несколько раз — даже не компилируется в байткод, а просто интерпретируется.
Основной системный язык, пожалуй, Си, а не плюсы.
Сейчас много хайпа по переходу эмбеддеда на C++14 (не Си). Мол, эффективнее.
Кажись автор так и остался в том самом 2012(а может и раньше) году.
прошло всего-то 3-4 года… ))) мир программирования быстро не меняется.
к тому-же свежая статистика такая и осталась.
обновил на свежую статистику )
А в чем причина выделения C/C++/C#/ObjC в единую группу? Разные языки же.
я счел, что для новичков их можно объединить… хотя это принципиально различающиеся языки.
Я прошу прощения, а зачем вы для новичков даете советы, которые в корне неверные, и вредные? Начнём с того, что даже С и С++ — это принципиально разные языки, и сейчас они имеют различные сферы применения. Но вы зашли дальше, и поставили «бок о бок» С++ и С# (!)
Вы делили по идеологии разработки? А почему тогда Паскаль выделили в отдельную группу? Между С++ и Паскалем общего намного больше, чем между С++ и С#. По синтаксису? Тогда почему же Java и РНР почему-то от группы С-подобных языков отделили? Тем более что Java вообще функциональный аналог С#, ну разве что с более куцым набором языковых средств. Судя по всему, вы лишь одну логическую связь между этими языками установили — по наличию буквы С в названии. Но делать такое «упрощение» для новичков — это издевательство над неокрепшими мозгами.
Не хочу показаться занудным, C# появился позже Java, так что скорее он является аналогом Java. И давно ли Java стал функциональным? Java, в первую очередь, объектно-ориентированный язык.
«Функциональный» в моей фразе не в смысле наличия возможностей функционального программирования, а в смысле сходной области применения и сходной парадигмы разработки приложений. C#, впрочем, также как и Java, в первую очередь объектно-ориентированный язык, с расширениями для функционального программирования. Например, лямбда-выражения уже и в Java есть. А так да, по старшинству приоритет за Java :)
Прошу прощения, не правильно понял «функциональный» :) В указанном смысле с Вами полностью согласен.
Спасибо конечно за статью, но уж сильно жестко и абстрактно вы завернули )) Если целью было напугать юнных дарований, чтобы проверить их желание — думаю у вас получилось )) в остальном — очень абстрактно и субьективно. Больше примеров и полезных советов — и было бы норм ))) не учитывая провакиционный характер статьи, который так и тянет начать холивар ^_^
а я специально пугаю… потому что много развелось псевдопрограммистов…
ко мне устраиваться таких приходит море.
Ну, тут я не согласен. Это попахивает каким-то, извините меня за сравнение, «фашизмом».
Если разделять людей на классы и касты, вешать на них ярлыки и оценивать по возможностям — можно прийти к гитлеровскому подходу — «оставить одних правильных, а всех остальных фтопку!!! ЗИГ ХАЙЛЬ!!!» ))
Все люди разные, у каждого разные возможности и разное мышление. Ровно как и направлений в разработке множество, так почему говорить, что те кто не знает C++ конченные?
Я бы согласился, если бы вы написали именно с таким мнением, что не все могут работать с С\С++, равно как и с ассемблером и вообще даже с аппараткой. Но это не делает их конченными программистами, они просто другие. У меня есть парочку примеров людей, которые виртуозно работают с C++, но как-то решились попробовать себя в веб-разработке и потерпели фиаско, только потому что тут подходы разные. И я думаю многие могут такие примеры привести. Так что называть людей псевдопрограммерами и тем более указывать им на то, что если они не разобрались в указаниях данного «майн кампфа» им надо выйти вон — очень не этично, я бы даже сказал бестактно.
А вот сказать им в таком ключе «Ну вот не получается у вас делать качественные приложения на C\C++, может стоить попробовать себя в другом? Есть много вариантов и альтернатив. И честно говоря, не каждый кто будет прилагать тонну усилий в течение 20 лет станет гуру.» — было бы намного тактичнее, и как сейчас модно говорить, толерантно. У всех разные возможности и способности. Но это не значит что один убогий и его надо сжечь на костре, а другой — опора мира разработки.
Вроде все сказал))
P.S. Извините, пожалуйста, за сравнение с фашизмом и за все, что с ним связано, но я просто не смог найти другого сравнения. Очень мне напомнило именно расистский подход.
ко мне устраиваться таких приходит море.
Пожалуйста уточните, «ко мне» — это куда?
Напрасно гиперболизируете. Зачем именно С++, а не С? Что такого есть в плюсах, чего нет в голом си, и что должен знать высокоуровневый программист для понимания работы памяти, указателей, компиляторов? Уж не ООП ли вы рекомендуете постигать на примере С++?
UFO just landed and posted this here
Нет, с точки зрения обучения, зачем С++? Чему такому он может полезному научить, чему не могут научить другие языки? Для низкоуровневости подойдет си, для высокоуровневости питон/шарп/ява.
UFO just landed and posted this here
Думаете высокоуровневость правильнее всего учить на С++ вместо мною названных? Хотите отбить желание человеку?
UFO just landed and posted this here
UFO just landed and posted this here
Я не понимаю, что Вы пытаетесь сказать. Что порог вхождения в высокоуровневость с помощью С++ такой же, как и с помощью шарпа/явы/питона? И что высокоуровневость эффективнее учить именно на плюсах?
UFO just landed and posted this here
Соглашусь. Всякий, научившийся водить уазик, легко пересядет на лексус с автоматом и камерой заднего вида. Поэтому в автошколах мы не видим уазиков, но и выпускники в свою очередь не станут профессиональными гонщиками.

То есть у С++ выше порог вхождения, но эффективность результата того стоит.

Другими словами, Вы хотите сказать, что лучше отбить желание, чем воспитать очередного недоучку? Если так, то я согласен с этой позицией.
По-моему, с какого языка начинать (и какими языками продолжать) — наименее важное, что должно интересовать начинающего программиста.
Разница в производительности между программой, скомпилированной разными компиляторами — проценты. Ну, может, десятки процентов.
Разница в производительности между программой, написанной криворуко и программой, написанной грамотно — разы и порядки.
а я и не пишу что С — панацея.
Я вообще рекомендую начать с Паскаля, потом перейти на С… потом уже можно или Ява или Пайтон или чего душа пожелает…
С, ИМХО, неплохая стартовая площадка!!!
Я стерпел С/С++/Obj-C
Я стерпел путанье языка(делфи) и IDE(Builder)
Но это! Ява — остров, Джава — язык!
Немного позанудствую :) Остров называется Java по-английски и Ява по-русски. Названный в честь него кофе называется так же. Почему тогда вдруг названный в честь кофе язык программирования должен называться иначе?
Delphi, кстати, это IDE. Понятие «язык Delphi» появилось уже спустя семь или восемь версий этой IDE.
Понятие «язык Delphi» появилось очень и очень давно (c седьмой версии IDE, если мне не изменяет память).
А вы до конца прочитали последнюю фразу в моём предыдущем комментарии? ;)
Угу. Delphi, на данный момент, в первую очередь — язык.
А почему «в первую очередь», а не в какую-то другую? Есть IDE, которая были изначально, ещё до «объявления о появлении языка», и которую никто не отменял после его появления. И помните, как много лет кряду новичков, которые говорили «язык Delphi», тыкали носом, что нет такого языка, что это IDE, пока им Борланд не пошла на уступки? Разве с этого момента что-то поменялось, и Delphi IDE исчезла? Нет, вроде бы. Если вы поставите современную Embarcadero RAD Studio, она вам также создаст ярлычки конфигураций Delphi XE<чего-то там> и С++Builder XE<чего-то там>.
Программирование — это процесс полета креативной мысли...
Эх, лучше Фредерика Брукса вам всё равно не сказать, а он писал (я, с вашего позволения, оставлю язык оригинала):

«The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination...»
Написал первую версию программы!? Выкинь и начните писать вторую версию.
А потом выкинь и её. Именно вторую версию и надо выкидывать. Опять же из Брукса:

«This second is the most dangerous system a man ever designs. <...> The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a „big pile.“

Из того, с чем могу согласиться — Паскаль — хороший учебный язык.
Рекомендация читать Страуструпа — довольно жестокая, в том смысле, что книга не простая. Я сделал первый подход к этому снаряду лет двадцать назад, но так и не осилил до сих пор (впрочем я не пишу на этом языке). Для изучения С++ есть более подходящие книги (но не „изучи С++ за двадцать один день“, конечно же). Лучше Кернигана и Ричи прочесть.
Вообще, чтобы стать программистом, надо просто иметь „инженерный“, живой и в какой-то мере чуть „хакерский“ склад ума и, самое главное, научиться учиться, так как суть программиста в непрерывном обучении и адаптации к постоянно меняющимся технологиям и требованиям к ПО, ну а всё остальное приложится.
Есть области программирования, к которым всё, что вы изложили, применимо с большим трудом (ну я вот, начав с программирования на DEC PDP11, теперь программирую машинное зрение и промышленную автоматику, и при этом это не эмбеддинг — у меня свои узкоспециализированные инструменты и библиотеки — ну каким боком ко мне все эти фрейморки и ЯП относятся ?).
K&R это ж чистый «С» или я что-то упустил?
Кстати, имея большой опыт в плюсах (не считаю себя гуру, но и не новичёк) так и не могу осилить Страуструпа, а вот Майерс был прочитан на одном дыхании и сильно вправил мозг в нужное русло избавив от многих ошибочных привычек, так что я бы порекомендовал его книги, но не как учебники, а постучебный материал.
Да, конечно, я просто неясно выразил мысль. Я не имел ввиду книгу для изучения С++, а книгу, которую имеет смысл прочитать в начале пути программиста. Она хоть и полностью о языке С, но изложение материала там настолько приятное и последовательное, что она реально учит не только С, но и программированию вообще.
берите QT C++.

Фреймворк называется Qt.
Переменные самодокументируемые — szPersonName

Это Вы в C++ рекомендуете такую нотацию использовать? Для QString например? :) От венгерской нотации сейчас в ходу остались разве что «m_» для членов класса…
Какой-то сборник предрассудков и просто глупостей. Очень много громких фраз (чего только стоит само слово «Канон»), высосанных из пальца. Да ещё и эти «настоящие программисты», аки «настоящие мужуки». Моё мнение: ТАК нельзя писать статьи для новичков. Да ещё и подача информации сильно страдает: «мультиреляционный», «инкрементировать», «компилятору», «набор макросов от ассемблеристов» и т.д… Вы для кого пишете? Для зелёных страждующих нового первашей, которые такие слова первый раз в глаза видят, или для выпускников или уже действующих программистов?

Зачем то привязались к C++. Очень позабавил рейтинг tiobe. Ради интереса вбил на местном hh слова c++, php, javascript. Нетрудно догадаться, каких вакансий было больше. А у вас там на web выделено 6%. Зачем то долго и муторно «опустили» Delphi (я и сам его недолюбливаю, но писать про него такие глупостистранности точно бы не стал).

Моё личное мнение: в качестве первоначального языка, для завлечения и скорости понимания самой сути, нужно брать несложный для понимания язык высокого уровня. Чаще всего берут python, если я правильно уследил за новостями в этой области. И мне кажется это отличный выбор. Уже затем нужно копать в сторону ручного управления памяти, семафоров, регистров и пр…

ИМХО: в статье есть несколько разумных доводов (вроде того, что в ВУЗах не учат программировать, этому приходится учиться самостоятельно). Но большая часть статьи всё же сильно попахивает. Статьи для новичков НЕЛЬЗЯ писать в стиле, «слушайте сюда пацаны, запоминайте и мотайте на ус, сурьёзный дядя вам щас всё объяснит».
каждый кулик свое болото хвалит…
Статья для тех кто уже в IT, и в терминологии немного шарит.
Такий вводный курс, так сказать… мутный, согласен, но вводный.
Статья для тех кто уже в IT, и в терминологии немного шарит.
Такий вводный курс, так сказать… мутный, согласен, но вводный.

Одно противоречит другому. Если люди уже «в IT», то зачем им вводный курс?
Слушайте, а вам что, точек слишком много завезли? Чего вы ими разбрасываетесь?
Я, наверное, все-таки спрошу. Скажите, а написанное в статье (например, «программирование — это» или «настоящий программист — это») основано только на вашем личном мнении, или вы можете сослаться на какие-то независимые источники?
мое личное мнение.
настоящих программистов наверно выдумал… это как некий идеал, к которому надо стремиться. )
Ну а раз мы говорим о личном мнении, то лично мне бы не хотелось ни стремиться к выбранному вами идеалу настоящего программиста и определению программирования, ни видеть такие стремления у новичков — потому что, в рамках моего личного мнения, это губительный идеал.
UFO just landed and posted this here
Я, кстати, тоже. По мне идеал в программировании — это меньше работать, меньше писать код. В идеале просто говорить машине: сделай мне вот это и вот это. Но это увы, недостижимый идеал.
UFO just landed and posted this here
Мне хватило вот этого: «уже запуская программу на исполнение, «правильный» программист прекрасно знает, как она выполнится, потому что до этого она словно «проиграла как музыка» в его голове.»
Настоящий, «правильный» программист — он как бесконечный разум из «Теории доказательств» Гаиси Такеути.
Он способен перебрать бесконечное множество строчек кода за конечное время.
Перед таким — трепещи аналитик, от такого — беги прочь тестировщик, сторонись его ПМ, избегай его заказчик.
Вы, батенька, ни разу не программист, а упитанный тролль, вы просто ничего не поймете из статьи пока не начнете программировать, а вы никогда не начнете.
Зря всё-таки паскаль похоронили. С++ конечно мощь, но в нём сложнее ошибки искать за счёт хитрых конструкций символов «в одну строчку» как это любят делать профи. Разница-то в языках только в буквах, и если бы на начальном этапе больше сил приложили на развитие паскаля то именно он стал бы системным, но сейчас ничего уже не исправить — слишком он стал далёк от системного.
Профи-то как раз таких «хитрых конструкций» избегают и пишут очень понятно. Конструкции громоздят энтузиасты, с восторгом осваивающие язык и вообще программирование.
Статья мне почему то напомнила журнал «хакер» начала 90х. Очень субъективно, но стиль похож. Такой панибратский, с не совсем удачными попытками имитировать разговорную речь, частыми зачеркиваниями, спорными шуточками и т.п.

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

Программирование — это сугубо исследовательский творческий, а не технический процесс.

Я бы сказал, что для многих программистов это вполне себе ремесло — и этого не надо стыдиться и выставлять как нечто плохое. Более того, это вполне технический процесс оперирования требованиями, граничными ситуациями, алгоритмами и т.п. Написание тестов, документации… обычная рабочая рутина. Как везде.

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

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

При этом «Самое главное умение в программировании, это научиться воспроизводить (исполнять) код в уме.» — достаточно верное замечание.

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

Только плохие учителя утверждают, что не могут кого-то чему-то научить, если у ученика есть желание :-)
Но при этом опять же соглашусь, что «что бы учиться плавать — надо плавать». Но так это ко [b]всем профессиям[/b] относится! Чем тут программисты особенные?

Программист — это человек, который не только пишет программы, но и у которого они работают.

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

Существует много языков программирования, но особняком в это списке всегда стоял С++.

На данный момент, только С++ дает самый быстрый и оптимизированный код под нативную родную платформу.

Именно поэтому видимо постоянно пытаются написать более безопасные языки-альтернативы C++.
А игры на каком-нибудь Unity могут летать на бОльшей части актуального железа. При том что программист, пишущий её, не напишет ни строчки кода на C++. Да, конечно нативный код будет быстрее, но скорость написания программы тоже играет роль, а управляемые языки вполне могут выдать достаточную скорость. Ну ок, выдаст игрушка на 90% компьютеров не 110 FPS, а 100 — велика ли потеря, что бы отказываться от удобства?

Теперь посмотрим на мировую статистику за 2015 год, так на чем все-таки пишут программы?

А теперь посмотрим на какой-нибудь HH по городу Екатеринбургу. 8 вакансий на С++ из 180.
Специально взял не Москву/Питер, а нечто поменьше. Остальное — C#/Java/PHP/Ruby/Python и даже 1С.

Пункт «ФРЕЙМВОРК И КОМПИЛЯТОР(IDE).» вообще не ясно зачем тут. Новичок, погрузившийся тему весь этот блок узнает в течении пары-тройки в день.

ХОРОШИЕ ПРАВИЛА ПРОГРАММИРОВАНИЯ
1. Написал первую версию программы!? Выкинь и начните писать вторую версию.

Кажется, это ПЛОХОЕ правило программирования. Рефакторить нужно, а не выбрасывать.

2. Проектирование программы начинайте на бумаге — блоки, связи, морфология, схемы (UML)

Не встречал в реальности ни единого разу. Обсудить работу чего-то конкретного, почеркать на доске или листочке? Было. Ну да я не на C++ пишу, а на C#/Java, куда уж мне…

Блок «КАКИЕ ОНИ БЫВАЮТ?» тоже ни к селу ни к городу и содержит местами откровенный бред.

Прикладные программисты — это люди, делающие что-то осмысленное для людей, для пользователя. Кому нужны драйвера и ОС без прикладных приложений? Кому нужен фундамент без здания — плохая аналогия, но красивая)

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

Я дико извиняюсь, но это что, венгерская нотация? Вот эта вот b перед именем — это bool?
Это даже хуже.
Учитывая, что переменная вроде как «валидность имени», то оно, наверное, или валидное или не валидное; bool как-то больше подходит.
Согласен. Вроде и информация о типе, но ещё и сомнения вносит. Я из префиксной нотации использую только: g_ для глобальных переменных, s_ для статических в единице трансляции и m_ для приватных членов класса.
Кто-то ещё использует t_ для имён параметров функции, встречал такое.
Венгерская нотация — зло.

Правильнее было бы назвать как-то вроде IsPersonNameValid / is_person_name_valid /… (стиль именования выбирайте сами)
Я своим комментарием именно это и хотел сказать, собственно.
Она не зло, просто перевели неправильно и поняли неправильно. IsPersonNameValid — это как раз пример венгерской нотации — здесь Is и есть тот префикс.
Исходники венгерской нотации от Спольски.
То, что изначально этот венгр имел в виду другое, тоже слышал. Но я как раз об употреблении венгерской нотации в общепринятом смысле.
Is — это не «префикс», это обычное слово английского языка.
UFO just landed and posted this here
В таком случае Valid — семантический суффикс, обозначающий смысл переменной, ну и так далее.
Да-а… Одна фраза
С++ — это минималистичный язык, возникший как набор макросов от ассемблеристов.

в этой статье чего стоит…

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

вы будете компилировать гигантского размера программы

Это говорит только о неумении использовать инструмент. Даже в почти последней ХЕ8 можно создавать приложения по 30Кб весом без особых сложностей. А вот плюсовые приложения, не запускающиеся без гиганских С++ редистрибьютейблов это, увы, реальность. Зато ЕХЕ маленькое.
C++ Runtime можно тоже статично вкомпилировать и будет использоваться то, что нужно.
Волков бояться в лес не ходить. Брал в комманду новичков и буду брать. Никогда не забывай как помогали тебе и давали шанс набраться опыта, спасибо им, особенно Андрею Сорокину — земля пухом тебе Андрюша. Понятно никто им не давал архитектуру закладывать, но на подхвате, вполне справлялись, а главное, старались. Не то что бы красотой кода затмевали, но работало, а если работало плохо показывали как правильно, книжки давали, код показывали, заставляли переписать, учили. И молодежи польза и «старикам» рутины поменьше. А набраться самому опыта а потом с высока посматривать, лучше помоги чем можешь. Они ведь не претендуют на зарплаты архитектов.
п.с. Поэтом может он не быть а программистом станет.
Я начинал учиться именно с плюсов, точнее с си по книге Кернигана/Ричи и потом плюсы с ооп. Джава, пхп, перл, жс потом зашли отлично.
Если бы вы начали учиться с Паскаля, Бейсика или кодов МК-52, результат был бы абсолютно таким же, уж поверьте.
Насчет МК-52 не уверен. Там больше не программирования было а решения головоломок куда бы чего запихнуть эдак чтобы в память вместилось.
Когда не было альтернативы, это было круто… но как только появились «Радио-86РК» и ему подобные калькулятор потерял свою привлекательность.
Дык, в этом и прелесть. Написать алгоритм, чтобы впихнуть его в 105 байт памяти кода и 16 регистров — это надо научиться не просто писать алгоритмы, а еще и отлично оптимизировать. Самое что ни на есть программирование :). После этого К580ВМ80А с 48К памяти — это просто безграничные ресурсы.
Это не прелесть, а способ занять мозги. Оно конечно хорошо, но низкоуровневой оптимизацией прекрасно справляются компиляторы, просто на Z80 и 48К памяти горизонты возможностей несколько шире.
На современном железе 16Гб — это довольно узкие горизонты для современных задач, наверно на уровне тех же 105 ячеек(кстати ячеек а не байт, они ведь там 4-битные).
Умение видеть слабые места алгоритма и точки для оптимизации — это важнейшее качество программиста тех лет, и далеко не лишнее сейчас. У вас не было оптимизирующих компиляторов на МК-52, у вас их не было на Радио-86РК, не было на ZX-Spectrum, да и на IBM PC они появились ближе к закату жизни этой машинки, и были не особо умными. Сейчас да, они есть, но опять же таки, мы оперируем во многих случаях монстроидальными объектами монстроидальных библиотек, и зачастую приходится так же сражаться с их причудами и «фичами». А неумелым алгоримом легко уложить на лопатки любую современную машину, хотя насчет «узких горизонтов» 16Гб вы, конечно, преувеличили. Пока что их с лихвой хватает практически для любых задач персонального компьютера. Но это пока.
Ячейки памяти кода у МК-52 не четырехбитные, у него 65 команд плюс 10 цифр, итого 75 инструкций, каждая занимает одну ячейку. Минимум 7 бит надо. Это у него ППЗУ было с четырехбитной адресацией.
Ну, в масштабах Гугла, например, 16Гб — это ничто. Вспомним БАК, где количество записываемых экспериментальных данных измеряется эксабайтами… и их надо чем-то перемалывать. Вот по сравнению с ними 16Гб это те 105 ячеек.
В то время как рядовые люди используют калькуляторы всего с двумя регистрами.
Просто и Гугл, и БАК, и все остальные BigData в масштабах мирового ИТ — это крохотная капля в море. В мире успешно трудятся миллиарды ЭВМ, и почти все они имеют ресурсы намного скромнее даже 16Гб.
Умение видеть слабые места алгоритма и точки для оптимизации — это важнейшее качество программиста тех лет, и далеко не лишнее сейчас.

Сейчас — размер программы почти никогда не имеет значения, но имеет значение время её выполнения.
Оптимизация алгоритмов для скорости работы и для компактности кода — две совершенно разные задачи, опыт/навыки в одной из них неприменимы в другой.
Это у компилятора С++ оно как две совершенно разные задачи в опциях стоит :) У живого программиста скорость выполнения и компактность кода обычно сильно коррелируют. Компилятор вам не подскажет, какой XML-парсер использовать в своем проекте, и где надо бы обрабатывать десятимегабайтный пакет данных SAX-парсером, а не грузить его в DOM, например.
У живого программиста скорость выполнения и компактность кода обычно сильно коррелируют.

Мы сейчас сравниваем «как писать код» или «какую библиотеку подключить»?
Потому что я сходу приведу кучу примеров, где — при написании кода без оптимизирующего компилятора, как на старинном железе — приходится выбирать между скоростью выполнения и компактностью кода. Разворачивание циклов, инлайнинг функций, выравнивание данных, использование битовых полей, выбор между хэш-таблицей и поиском в массиве, между арифметическим приближением математических функций и таблицей заранее рассчитанных значений…
> Мы сейчас сравниваем «как писать код» или «какую библиотеку подключить»?
Второе — часть первого. Причем одна из существенных. Если вы не работаете с embedded либо с чем-то высоконагруженным (криптование, обработка сетевых пакетов, стриминг), вам не придётся думать на инлайнингом функций, выравниванием под машинное слово или разворачиванием циклов. Просто потому, что ваши старания никто не заметит, ни пользователь, ни компьютер. А вот пример с DOM vs SAX в прикладном программировании встречается часто. И знаете, если вышеупомянутые действия позволят вам сэкономить несколько миллисекунд процессорного времени, то в случае обработки XML от вашей оптимизации будет зависеть, будет ли приложение работать быстро, или уложит на лопатки весь компьютер, т.е. банально на обработке текста в 2016-м году.
Давайте я вам поверю на слово, что навыки оптимизации кода для МК-52, Радио-86РК и ZX-Spectrum помогают вам выбрать, какую библиотеку подключить для парсинга XML.
да, и в добавок к «Большая часть программистов — самоучки»
тот кого учили программированию и он потом набирался опыта и тот кто все сам учил и набирался опыта две большие разницы. Возможно есть исключения, но из тех с кем мне приходилось иметь дело — первые писали грамотнее.
Хочется сказать новичкам, не бойтесь, и главное не останавливайтесь на пол дороги. Терпение и труд все перетрут, будет праздник и на Вашей улице.
Программирование противно человеческой природе, то что хорошо в науке и технике — то плохо в программировании, и наоборот. Это мир зазеркалья в прямом смысле. Инженер ищет решение вопроса, а программист ищет малейшую лазейку для пользователя или тех.процесса, или компьютера отработать неправильно. Все люди враги. Человек добившийся чего то в науке и технике порой просто не хочет и не может перестроить свое сознание с позитива на негатив.

Да, терпение и труд — самое худшее для программиста, терпеливая работа уже на завтра оказывается в корзине для бумаг, лучше бы в тот день ваще не ходил на работу. Новичкам следует сказать — все придурки, один ты умный, так быстрее идет адаптация сознания.
какое то извращённое странное у Вас понятие о программировании. Как может быть противно то что доставляет удовольствие? Я инженер по профессии, технарь, всю жизнь занимаюсь программированием (с 1985 года). И не вижу большой разницы между инженером и программистом. Тех процесс схож, планирование разработка, тестирование. Все требует и математики и прочих специфичных знаний. Везде постоянно приходится учиться новому в твоей области и постоянно осваивать смежные области для которых что то разрабатываешь. Надо учиться работать в комманде. Если все делать правильно то в итоге все работает. Мы ведь не говорим о говнокодерах и снобах?
п.с. не будьте так критичны и максималистичны, смотрите на жизнь и профессию проще. Если она Вам не нравится, Вы просто не правильно её приготовили…
Вот я беру десяток программистов, вычисляю количество человеко-часов за месяц и количество операторов кода. А потом беру все то же самое за пять лет. Опс, 90% кода в корзинке. Что мы делали все эти пять лет? Да, наши старинные версия стоят у клиента и крутятся, однако… Ага, математики… Да математики в софте тех. процесса от силы 2%, а все остальное if не то, if не это, погнали копировать массив… Ага, смежные области… Это вместо того, чтобы осваивать соответствующие библиотеки, так как абсолютно все написано до нас и упаковано в среду с документацией. Вместо того, чтобы писать не убиваемый класс лучше мы в команде обсудим как он не будет работать. Производительность одного программиста 100%. Двух — 150%, трех 175%, четырех 187%. Добавим сюда понижающий коэффициент тупого начальника — 0,8%. Во, получилась команда в пять человек с производительностью в полтора программиста. Оставьте двух, разделите задачу пополам — бинго. А если заболеет? На такой зарплате не заболеет.
UFO just landed and posted this here
Вам не подскажу, но зато могу программистам, которые передали нам свой софт на сопровождение, подсказать наличие всяких разных контейнеров в стандартных библиотеках, и наличие библиотечных средств для работы с SMTP. И еще много-много других хороших библиотечных средств.
И вы знаете, по моим ощущениям, ваш случай частный, а мой — распространенный :)
Лично мне в статье не хватило рассказа о том, что интересного в программировании. Т.е. что такого мы в этом деле находим, что готовы тратить на это занятие даже выходные :)
Поразительный пример оптической иллюзии, коллеги! Статья вроде бы и неплохая, но плохая одновременно. Есть пара интересных и полезных для новичков мыслей в начале, но автор, видимо испугавшись возможного успеха, начал вдруг нести какую-то околесицу про C++ и остаток статьи стал похож на рассуждения «640 килобайт памяти хватит всем».
автор изложил свое видение, которое может показаться и околесицей
«Как не стать программистом или… тебе здесь не место» Воистину нам не место в вышеописанном программировании, и новичкам такого не желаю. ;) Только про компиляцию в голове ок сказал.
Откуда такое негодование к популярному Pascal?

Понятное дело, что раз его изучают новички, на этом ЯП по статистике всегда будет максимальное количество говнокода.
Но! Это не проблема самого Pascal. Вполне лаконичный ЯП.

Существует и активно-развиваемый Free Pascal.

И вы можете использовать любые компоненты от VCL и .NET до любых кросс-платформенных. Какие компоненты вы используете — не зависит от ЯП.

Есть еще свободное подобие Delphi — Lazarus.

PS Я на Pascal давно ничего не программирую. Но я никогда не отговаривал новичков от этого славного ЯП.

Вы поймите, если все будут изучать программирование с таких ЯП как C++, JavaScript, Python, Java, сразу же весь говнокод из Паскаля и Delphi перетечёт в говнокод C++, JavaScript, Python, Java. — Кто от этого выиграет непонятно: работник или работодатель?
Простите, не удержался, но FreePascal полон багов чуть более чем полностью, поставляется вместе с убогой IDE.
Насчет компонентов — да, можно использовать что угодно — но скорее в теории, чем на практике, Delphi, как и Лазарус вынуждают использовать поставляемые с IDE компоненты. Это отучает от программирования как такового и приучает к рутиному использованию определенного набора компонентов, которые больше нигде и не используются (та же VCL).

Но! Это не проблема самого Pascal. Вполне лаконичный ЯП.


Чистый паскаль как раз совсем не лаконичен:

PROCEDURE Example (VAR ARG1, ARG2: INTEGER)
VAR
 One, Two : INTEGER;
BEGIN
  {Код}
END;
;

Что мы тут видим? Блок описания для переменных, блок констант, громоздкий синтаксис.

Аналог этой же процедуры на C++:

void Example(int arg1, int arg2){
    int one, two;
    //Код
}


Я думаю разница очевидна — и это безо всяких примеров с синтаксическим сахором C++ 11.

Во времена пиратского Delphi 7, помню целые dvd-диски с компонентами к нему. Никто не заставлял использовать VCL. Причем, было все равно, на чем был написан распространяемый уже откомпилированным модуль/компонент. Если это .obj, то для использования хватит и заголовочника .h. А если .dll, структура модуля хранится уже в самом .dll.

Я начинал изучать программирование с C. С появлением на моем компьютере Windows 95, стал изучать CBuilder3. — Вот это была жесть! Позже, года через 3, в институте освоил Delphi. Так до сих пор жалею, что не пересел на него раньше. Ну, а после института купил iBook G4, и на этом моя работа с продуктами Borland завершилась.

Pascal — отличный для обучения язык. Должны же существовать языки с низким порогом вхождения. Сейчас и так тяжело найти нормального программиста на C++. Если всех новичков обучать с C++, — это, грубо говоря, понижает среднестатистический IQ общества программистов C++. И вы думаете, будет принципиально больше специалистов? Думаете, станет легче найти сеньоров С++? Как по мне, так станет еще сложнее.
согласен с Вами абсолютно. С++ не для всех. Кому стоит остаться и на ПАскале, что я и наблюдаю.
Я уже писал что С++-программиста в полумиллионном городе мы ищем 1-2 года. Паскалистов море. Но они не хотят переобучаться и это их дело.
Их может и много, но они не знают и не умеют ничего. И это дело не в ЯП. Паскаль \ Делфи был проще и они освоили хоть что-то. А плюсы не освоили бы с таким подходом даже базово.
Разницы нет НИКАКОЙ.
Или вы громоздкость измеряете в количестве символов которые надо набрать? Так это не та проблема на которую надо обращать внимание. Вот когда вы начнёте генерить исходники безостановочно со скоростью машинистки 240 знаков в секунду тогда это может оказаться критичным, но тут уже мозг не будет успевать генерировать такой поток чистого сознания.
Программирование — это не профессия, это диагноз.

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

Программирование — это всего лишь работа. Порой творческая, порой не очень.

Программирование — намного проще, чем теоретическая физика.

Проще, чем теория алгебраических многообразий.

Проще, чем дискретная математика (если не верите — откройте «Теорию моделей» Робертсона).

И для многих программистов оно даже проще, чем игра в футбол.

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

Это сидячая работа, чреватая ожирением, остеохондрозом и проблемами со зрением.

Но программистам хорошо платят.
Кстати, шутка «Программирование — это не профессия, это диагноз.» это не мое. Это древний программисткий юмор.
Я отчасти согласен что программировать просто. Но для этого должен быть определенный склад ума.
Было бы это легко, сейчас не было бы недостатка в нормальных программистах. Это страшный дефицит в регионах.
А так, бродят дипломированные программисты. А написать ничего не могут. Диплом есть, а программировать не умеют.
Как говорится — легко выучить, сложно использовать и тем более использовать хорошо и правильно.
Я не говорил, что программировать просто. Я говорил, что есть в принципе более сложные занятия.
Сложность «программирования» сильно зависит от сложности решаемых программой прикладных задач.

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

И с футболом в России дела обстоят еще хуже, чем с программированием.
А знаете, что самое грустное? Автор говорит, что у него опыта программирования 20 лет.
Мое сумбурное изложение моего видения обучения программирования никак не связаны с опытом работы.
Я 20 лет пишу коммерческое ПО, которое к тому же поставляется и на зарубежные рынки. Есть даже версия на китайском.
ПО работает стабильно.
Я сам не претендую на звание какого особого крутого программиста. Оцениваю средне свои способности.
Меня пугает другое. Крайне тяжело стало находить программистов. Их катастрофически мало с каждым годом. В нашем полумиллионном городе их просто единицы. Иногда уходит год-два чтобы найти приличного разработчика ПО для нового проекта.
Да, толпами ходят веб-разработчики (которые в разработку десктопного софта идти не хотят), много скучающих паскалистов (но у нас в конторе дефактовый стандарт С++). Я уже молчу про то, чтобы найти разраба под микроконтроллер.
Очень многие просто боятся соваться в эту отрасль. Тут надо много думать!
Очень многие просто боятся соваться в эту отрасль
Потому как это очень узкая отрасль и, в случае увольнения, или желания сменить работу, будет сильно сложнее найти себе применение. Эмбеддед, всё же, накладывает свои отпечатки.
Подскажите пожалуйста, как вы определяете, хороший разработчик или нет?
Вы к с своему опыту в комментариях апеллировали. Но речь не о том, какой вы программист. А в том, как вы оцениваете людей и технологии. В статье вы с легкой руки гнобите и опускаете одни области и языки и превозносите другие. Хотя вроде как с годами должно выработаться понимание, что каждому инструменту есть своё применение. И что если человек занимается не не тем же чем и вы — это не значит, что он занимается чем-то отстойным. У вас же вся статья этим пропитана.

Речь не о том, что отрасль сложнее — там есть свои нюансы, но они везде есть. Просто большинство выбирает более популярные направления. Ведь приятно иметь выбор из 20 потенциальных мест работы, а не из 2х. Вы таки считаете, что это глупо?
Я б хотел сунуться в эмбеддед-разработку.

Но проблема в том, что от эмбеддед-разработчика требуется опыт в эмбеддед-разработке. А как его получить? Замкнутый круг.
Научиться держать паяльник с правильной стороны, купить микроконтроллер, читать тонны информации в интернете, экспериментировать. В свободное время. Если понравится — то приобретёте опыт.
В паяльник я умею, гуглить умею, свободное время найду, а дальше нет. Какой микроконтроллер купить, например?
Какую задачу попробовать сделать?
Видится мне, что не обязательно покупать микроконтроллер, наверняка, есть роутер, который можно перепрошить альтернативной прошивкой и получить полный доступ к системе, для начала этого хватит. Подключите к нему метеостанцию по USB например и сделайте получение данных и отображение на других устройствах :)
Начните делать «умный дом» — купите управляемые выключатели, датчики движения и сделайте систему управления освещением (сколько стоит и какие брать — не знаю, так как особо не интересовался).
И вот таким способом можно освоить кросс-компиляцию с пользой для дома :) Ведь встроенные устройства это не только программирование микроконтроллеров.
P.S.
Мне кажется, я вас понимаю — иногда хочется что-тот освоить, но дальше простых примеров не придумать или придумать, но что-то совсем сложное, что руки опускаются :)
Начать с классики. ATMEGA8 или любая из ардуин сначала помигать диодом(один день) потом сделать часы без внешнего RTC а затем и с применением RTC. Вам этих задач и сопутствующих подводных камней хватит чтобы понять что это такое.
Потом то же самое можно попробовать реализовать на STM32, сравнить сложность и возможности.
Почему часы? Да потому что куда не ткнись — каждый пытается их сделать, а значит можно будет подсмотреть разные реализации и их недостатки — а это бесценно для начинающего.
И раз уж собрались в эмбед вот эта www.ozon.ru/context/detail/id/2644328 («Конструирование высокоскоростных цифровых устройств. Начальный курс черной магии») книга должна быть настольной. Сначала скачать в электронном виде, а после успешной реализации первого проекта приобрести её. Оттуда вы узнаете для чего нужны блокировочные конденсаторы в цифровой схеме и почему схема может не работать как надо на макетке с длинными проводами и еще много-много всего интересного.
А Raspberry Pi у меня тут есть в близкой доступности, оно тоже считается embedded?
AVR (без ардуиновского софта, разумеется, Си на Атмел студии) хорош для вхождения. Есть голый камень и делаешь с ним что хочешь. Можно посмотреть в какой машинный код превращается программа, шагать по инструкциям, изучать оптимизацию прямо в IDE: следить за размером кода и таймингами.
RPi хоть и технически можно встроить, но это по философии ближе к x86, так можно и последние интеловские мелкие платы взять, привычно писать на как под PC и считать себя эмбеддером. Только из мегабайтов или гигабайтов того, что будет крутиться на камне не имеет к тебе никакого отношения, и глюки будут в основном не твои, и риалтайм не тот.
Нет идей что именно сделать? Да просто посмотреть по сторонам и автоматизировать что-нибудь в хозяйстве: аквариум, полив цветов, курятник, наконец.
Это как бы слишком сахарно, её можно на потом после того как прочувствуешь низкий уровень и при НЕОБХОДИМОСТИ высокой производительности(распознавание образов? онлайн-трансляция?) или мощи линуксовых скриптов. На ней тоже можно эмбед делать, но не прочувствовав основы будешь ходить по граблям и собирать все камни.
People also put an absurd emphasis on the amount of experience programmers have. «We want a programmer with five years of C programming experience» is a silly statement. If a programmer hasn't learned C after a year or two, the next three years won't make much difference.

— Steve McConnell
/// Вопли автора про паскаль

За десятилетия правления Борланда и InPrise он превратился в монстра, заимствовав (украв) часть синтаксиса из С++. Сейчас компания Embarcadero продолжает выращивать этого монстра, в чреве которого вы будете компилировать гигантского размера программы. Кстати и для Андроида тоже.

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

/// Вопли автора про "начинающих"

Возможно это вызов и вам, господа дельфисты! Попробуйте написать прогу на С++.

Что касается первого языка — то тут Паскаль очень даже ничего.

/// Вопли автора о обязательном знании плюсов

С++ — это минималистичный язык, возникший как набор макросов от ассемблеристов. Вернее сначала возник С. Но не в этом суть, я не историк.
Почему рядовой программист должен знать С++?
Это примерно как священник, не знающий Библию. Как маркетолог, не знающий о правиле 4П. Как фотомодель без макияжа. Так и С++ — это тот самый необходимый багаж, который должен просто хотя бы лежать в голове на одной из полок.

Для саморазвития очень даже неплохо знать C или C++.
Но это не значит что их нужно знать всем.


/// Скажу про C++ от себя

Синтаксис C++ прекрасен и это мой любимый язык. Пишу в основном только на нем.
Идеальный вариант для своих проектов — вычислительная часть на плюсах в .dll, а GUI на C# или Java
Как-то у вас всё грустно :)
СТАНОВЛЕНИЕ

Школа
Сначала было слово...Нет, сначала была книжка «Лекции профессора Фортрана». Было переписывание малюсеньких листингов программ на Бейсике от туда и их интерпретация в голове. Потом более крупные листинги из журнала Морской Сборник (вроде), там всякие расчёты таблиц девиации для штурманов — что это, я не понимал, но было круто. Компьютера не было. Потом он появился и был QBasic. Потом Turbo Basic и первые EXE. Потом стало тесно. Услышал про Си. Ниасилил. Поэтому появился Turbo Pascal. В школе информатики не было. Год играл в игры, поглядывая на паскаль и что-то там рисуя. Потом снова попробовал Си — все же тогда кульхацкерами были. А какой кульхацкер без Си. Ассемблер? Не, литературы не было. Как и интернета. Точнее был, но нужно было покупать модем и платить много нефти.

Со второй попытки Си, почему-то, дался без проблем. МНОГО времени никогда не уделялось. Поэтому была всякая фигня: Borland C++ (компилятор так назывался, писалось чисто в Си-стиле), программирование графики через отображение в память, парсинг и вывод на экран BMP, мелкие утилитки, все яркие от использование conio.h, патчер для сейвов Fallout 2, что бы персонаж был очень крут сразу и навсегда. Больше ничего и не припомню.

Потом был Дельфи. Потом C++ Builder (ведь Дельфи не круто, Паскаль же!). Первый маленький зловред, который сидел, сидел, а потом начинал открывать и закрывать лоток CD-ROM. Потом второй зловред (Borland C++, т.к. DOS): при помощи него увели игру у учителя по экономике (уж названия не помню, она там что-то считала потом выводила распечатки, мы анализировали и корректировали вложения, амортизации и прочие, выигрывала команда, которая не прогорала), которую она очень не хотела давать (тут же немного социальной инженерии: утверждалось, что программа расширяет доступное место на дискете, а что мы официально хотели скопировать я уже не помню).

Потом Linux. Тут пока освоился и школа усё. Amp только допилил, что бы плейлисты поддерживал. Другого проигрывателя не было.

Универ
Другой город. Первый курс. Электроснабжение. Visual Basic, ещё на Win 3.11. Лабы по 10 руб/штука или 1 бутылка пива/штука. Курсовой 250 руб/штука без блок-схемы, 500руб/штука с блок схемой, пивной эквивалент не принимался. Потихоньку что-то курочилось в опенсорсе, т.к. курсовые позволили купить модем, а за интернет договорился с родителями.

Много пилось пива со всяким около-IT людом, что принесло первую работу связанную с программированием курсе на втором-третьем (а так же полухалявные интернеты, но удобные и халявные интернеты, но не совсем удобные). За деньги. По контракту. Писал под X11, познакомился с RS232, pthreads, TCP/IP и ещё чем-то. Ну и новыми людьми. Узнал про отладчик (ага, именно сейчас, не раньше). Начал читать книжки. Статьи.

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

Иии… вот он я! :)
а я неправильный программист — пиво не пью. Вот где собака то зарыта!
А Ваш опыт очень похож на мой. Разве что я в Linux позже ушел.
Заметил тенденцию последнее время на хабре: если в посте больше ста комментариев, значит в самом посте ничего полезного нет.
В полезных и умно написанных постах обсуждать и критиковать, в общем-то, особо нечего.
затроньте холиворную тему и получите сотни комментов… у многих людей — покритиковать, это в крови…
Даже у гуру программирования есть много спорных моментов.
Брукс настаивал что первую версию ПО надо выбросить, другие писали что это ошибочно.
Достаточно почитать Макконнелла чтобы понять как много мнений в мире программирования иногда бывают полностью противоположны.
Если вы считаете, что C++ vs Delphi — это холивор, то вы давно не выглядывали в остальной мир. Это последний раз было актуально лет десять назад, и уже никого ни грамма не волнует. Вас критикуют не потому, что вы подняли какой-то спорный/конфликтный вопрос, а потому, что вы опубликовали статью якобы «для новичков» с кучей ляпов и откровенной ерунды.
Хорошая статья для начинающих. Лично я не со всем согласен, но это мелочи. И да, статистика за 2012 год — это сильно! ))
статистику я поправил через 2 часа после выхода статьи… )
она не сильно изменилась.
Самый высокооплачиваемый сегмент программирования.


Сирьезна???
да… не все любят копаться в ассемблере, и при программировании оперировать 6-8 регистрами и пытаться не запороть стек…
хотя сейчас IAR и Keil дают возможность писать на С и особо не залезать в ассемблер.
там где это востребовано — у железякеров ЗП высокие…
Да ладно, сравните зп java senior developer (web) или asp.net senior developer и embedded system developer (в Москве, например).
Я 4 года назад, когда стоял на распутье: разрабатывать софт под железо или писать на шарпике, выбрал шарпик, потому что семью кормить тоже нужно.
Это когда исходный код текущего модуля словно подгружается в мозг и там отрабатывается (ака отлаживается).

Так это, сначала программист в голове прокрутил-отладил, потом просто записал на листочке.

{не стоит воспринимать это всерьез}
Это для случаев не сложнее Hello World справедливо разве что :-)
Либо просто мы с вами не подходим под определение «настоящего программиста» :)
Я — точно не настоящий программист :-) Никогда на бумажке ничего не пишу, только в отладчике. Особенно криптографию, потому что бумаги не хватает :-D
Сарказм про «настоящего программиста» принят. ) Я таких еще не видел. Если только на бумаге.
Про писать на бумажке. У меня проекты такие, что без UML и без проектирования никак не выйдет.
У нас промышленные приборы, к ним обильно-GUI-ый софт с кучей экспортов, шаблонов печати, протоколирований и пр.
Почитайте Макконнелла опять же. Он уделяет проектированию не одну главу. Нормальная крупная программа начинается с бумаги и схем.
Отладчик, ИМХО, нужен, когда не понимаешь, а «как этот код работает»?
У меня тупо: криптография без внятного описания что и как. Иногда оно не работает :-( Или парсинг бинарных файлов, который тоже иногда не работает. Гуя нет, только молотьба данных.
Что имеем в итоге. У автора 2 статьи, за первую он получил +114 за вторую -50. При этом карма -10.
Почти все свои комментарии автор написал тут. Элементарная математика(114 > 50) показывает что система кармы хабра не работает. Люди ставят плюсы ГОРАЗДО реже чем МИНУСА(а должно быть по идее одинаково). Надеюсь администрация обратит внимание на этот факт.
И что они сделают, после того как обратят внимание? Заставят в карму плюсовать?
Люди чаще идут что-то делать когда не довольны. Поэтому «волнения» кармы в данном случае вполне логичны. Автор задел чувства большого количества людей. Даже мне, человеку пишущему на Java, было немного обидно, что меня не причислили к «нормальным пацанам». Что уж говорить про остальных.
Имхо лучше просто отказаться от кармы и перевести все на один рейтинг. Тогда и за полезные комментарии больше пользы будет.
кстати, да! обидно мне. ) Почему карма ушла в минус, если 114 больше 50?
администрация? ау!
Вы просто не понимаете карму. Людям нравится статья — они её плюсуют (и наоборот), то есть рейтинг — это оценка именно статьи. Карма же — это отношение людей непосредственно к автору. Эти две оценки, вообще говоря, не зависят друг от друга (хотя зачастую коррелируют).
И я такой не один
http://habrahabr.ru/post/274219/#comment_8720027
http://habrahabr.ru/post/274219/#comment_8719671

Карма тут уже давно сломалась, карма должна отображать отношение сообщества к юзеру, но сейчас человек который написал кучу крутых статей может сидеть с кармой еле превышающей 15 как например Delphinum. Это по вашему реальное отношение сообщества к этому человеку? Скорее всего либо сообщество нездорово либо правила, я больше склоняюсь ко второму. Нам дали правила которые просто устарели. Не нужно их защищать, они уже давно не работают как надо.
Часто это решается путем обязательного сопровождения «плюсика» комментарием. Мы (во времена wap'а) так решали эту проблему. Другой вариант — дать возможность пользователю по собственному желанию полностью отказаться от системы рейтинга со всеми плюсами и минусами для него (высокий рейтинг это ведь тоже хорошо).
Вообще на этом сайте карма имеет другое предназначение — она стимулирует людей писать контент для сайта. Если пишешь статьи (не такие как эта, конечно), то естественным путем будет положительная карма. Если не пишешь, то опять же таки, естественным путем накопится отрицательная, и через пару-тройку лет попадешь в режим «только чтение», или покинешь сайт, или начнешь писать статьи, только и всего.
Люди не роботы. Карма не совсем работает как надо именно из-за человеческой природы. Если постоянно не расширять горизонт и тематику статей то новых "+" в карму не получишь, поскольку круг читателей стабилизируется а "+" можно поставить одному человеку только один раз. А вот мимо проходящие минусующие — постоянно новые, в итоге малейшая оплошность и минуса, которые не компенсируются плюсами.
Единственный способ не уйти в минус — писать статьи на широкий круг разных тем и молчать в тряпочку, иногда нейтрально отвечая в коментарии. И не дай бог вляпаться в какую-то дискуссию — рано или поздно получишь шквал минусов в карму на ровном месте которые будет очень сложно компенсировать! От тех самых мимо проходящих, которых случайно задел неосторожным словом. Они поставят минус и уйдут, а тебе сидеть в яме.
Но с другой стороны… как ещё можно отслеживать и сдерживать истинных вредителей-троллей? Заниматься этим вручную — неблагодарнейшее дело!
На сайте с инвайтами хлопнуть тролля вручную в общем-то не проблема.
Хлопнуть в ручную не проблема, а проблема в том что вовремя его нужно распознать и остановить. А для этого нужно постоянное, 24 часа в сутки присутствие ответственного за это модератора который будет выявлять их и уничтожать, а это очень накладно и непродуктивно. К тому же пресловутый человеческий фактор и предвзятость.
В то же время, простые пользователи присутствуют практически круглосуточно — получается такой обезличенный модератор который опирается на существенное количество голосов простых смертных и дежурит 24 часа в сутки без выходных, больничных и праздничных дней.

И да кстати, сколько примерно пишется статей/коментариев в сутки которые необходимо будет вручную проверять? И справится ли с этим человек, так чтобы назвать это «легко» и «не проблема»?
Один — наверное не справится. Но их тут не один. А существование крупных форумов говорит, что это не такая уж проблема. Система инвайтов обеспечивает тот немаловажный факт, что троллить можно только один раз. Если человека сразу не прихлопнули, ну, самое страшное, что произойдет — он успеет нагадить в какой-то ветке комментариев, прежде чем его удалят вместе со всеми его комментариями. Разве это проблема?
Проверять все комментарии вручную не надо, тут как раз отлично работает коллективный разум в виде кнопки «пожаловаться».
Но мне кажется, вы ошибаетесь в определении «Карма не совсем работает как надо». Я подозреваю, что карма работает как надо, только это «надо» настроено в интересах сайта, а не посетителей. Карма как раз настроена как стимул строчить новости и статьи, а не как инструмент оценки пользователей. А свежие новости и статьи, независимо от их качества, повышают рейтинг сайту. А рейтинг — это денюжка.
Вы, мне кажется, таки не понимаете что такое карма. Зачем проверять комментарии, они влияют на рейтинг, а не на карму.
С комментариев всё начинается… они конечно на карму не влияют, но срачи с кармопадом начинаются именно с них.
UFO just landed and posted this here
И вот тут уже начинает играть роль рейтинг. Но и он тоже животное довольно строптивое.
Всё бы ничего, только вот в С и в С++ есть куча способов прострелить себе ногу, начиная с переполнения буфера, огребая кучу загадочных багов, не говоря уже про безопасность. Именно поэтому народ оттуда перебежал в Джаву, ибо она уже не требует такого опыта, тонн набитых шишек и внимательности, хоть и сильно уступает в производительности.
Довелось тут кое-что дописать на новом стандарте. Переполнился стек и… думаете выскочил адекватный эксепшн? Нет, переполнение буфера и в результате печать мусора в консоль. Рекомендация тут поможет ИМХО одна — переходить на современный язык.
Если вы не умеете писать, то новый стандарт ни при чём. Зачем создавать миллион переменных на стэке?
Вы слышали про рекурсивные функции?
Прекрасно слышал и понимаю, о чём вы. Стэк переполняется в любом языке. Не используйте рекурсивные функции.

Любой кейс применения рекурсии можно решить и без рекурсии.
1. Тогда Вы, наверное, в курсе что, например, в Java, Вы получите java.lang.StackOverflowError. А вот в С++ со всеми последними костылями я получил мусор в консоли.
2. Не используйте рекурсивные функции — это ещё почему? А может ещё индексы в массивах не использовать, чтоб не выйти за пределы? Или, может, память не выделять?
1. Пишите на java, кто ж вас ограничивает? Ловить stack overflow можно в C++, но это не исключения языка, а функция операционной системы. Вас никто не ограничивает. Вы можете не ловить и не получить оверхед. Можете ловить с чеком размера стэка и соответствующим оверхедом.

Не нравится свобода? Пишите на Java.

И что значит со всеми последними костылями? Вы в любом C++ получите мусор в консоли.

2. В C++ есть vector с bounds-checking (std::vector::at[i]), используйте, никто вам не мешает.
И приведите пример, что за такая рекурсивная функция, что аж стэк переполнился? Может быть, вы просто неправильно что-то делаете.
Любой кейс применения рекурсии можно решить и без рекурсии.

Можно, но это может сильно усложнить алгоритм (и/или ухудшить его читабельность).
С C++11/14/17 и их функциональными теперь возможностями можно и не разворачивая рекурсию, вот приведите пример рекурсивной функции, где возникает оверфло стэка.
DFS на большом графе (и, как следствие, все производные алгоритмы, типа SCC).
DFS элементарно реализуется нерекурсивно на std::stack, главное чтобы памяти из кучи хватило

Я уж думал что-то посложнее.

И хорош минусовать.
Да любой рекурсивный алгоритм «элементарно» реализуется на стеке, это очевидно, другое дело, что он после этого становится сложнее и менее читабельным. В частности, когда вам в том же DFS надо возвращать элементы в порядке обхода (причем в зависимости от задачи — разным), и вы хотите, чтобы это была ленивая последовательность — это уже совсем не так «элементарно». А рекурсивный генератор для этого остается тривиальным.
Тем не менее, как вам поможет рекурсивный генератор, если он сгенерирует эксепшн, даже если его можно перехватить?

И вот вам и подсказка для второго решения: можно сделать его на генераторах (yield/await).
Тем не менее, как вам поможет рекурсивный генератор, если он сгенерирует эксепшн, даже если его можно перехватить?

Тем, что он проще, чем нерекурсивное решение. Речь шла не о том, лучше ли исключения (хотя они лучше, чем мусор), я отвечал на вашу просьбу «привести пример рекурсивной функции, где возникает оверфло стэка». Привел.

И вот вам и подсказка для второго решения: можно сделать его на генераторах (yield/await).

И снова спасибо, кэп. И рекурсивное решение все равно будет проще.
Проще — не значит лучше. Давайте на этом и остановимся.
Проще — при прочих равных — лучше. Потому что основная задача программиста — борьба со сложностью.
Если рекурсивная функция не решает задачи (возникает stack overflow), то какой в ней смысл?
Прямой. Если исходная задача предполагала «разумные объемы» данных, и под них было выбранное рекурсивное решение, как более читаемое, то было бы круто, если бы программа валилась с разумным исключением (которое потом еще можно и перехватить и обработать), а не мусором. Но, повторюсь, речь не об этом. Вы просили пример — вы его получили.
Ещё раз: хотите перехватывать stack overflow — перехватывайте, C++ это вполне себе позволяет.
Тогда почему размер стека не увеличили? Основная задача программиста не со сложностью бороться а следить что происходит с руками. Борьба со сложностью это одна из задач, но не самая первая.
Когда речь идёт о рекурсии — нужно внимательно следить за стеком. Даже если возникает исключение или по тихому портятся данные это означает что алгоритм для данных условий не годен. Рекурсию можно применить только если есть уверенность что она не выжрет больше половины стека за раз. Даже если алгоритм получается проще, нужно ограничивать входные данные чтобы не допускать переполнение стека, чтобы потом не пришлось искать место возникновения проблем, и даже если выделить памяти под стек в 4 раза больше чтобы точно хватило возникнет такая задача которой не хватит и его.
Тогда почему размер стека не увеличили?

В какой момент?

Основная задача программиста не со сложностью бороться а следить что происходит с руками.

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

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

Оценили, все влезало.

Если предпочитаете следить за бизнес-процессом, тогда не используйте рекурсию.

Ну здраствуйте. То есть давайте мы выкинем полезный и нужный инструмент только потому, что он требует хождения вокруг него на цыпочках.
Зачем выкидывать? Инструментом надо уметь пользоваться. И как любой инструмент у него есть свои требования — рекурсия очень неустойчива к стеку, и если сам алгоритм не образует бесконечных петель то размер требуемого стека очевидно зависит от размера входных данных, и когда нет никакого ограничения по входным данным то никакого стека не хватит. И в таких случаях применять рекурсию просто опасно, как газовую сварку в ямах и низинах — то что рванёт это лишь вопрос времени.
Ну так никто и не спорит, что рекурсивные алгоритмы надо аккуратно планировать и вписывать в доступную глубину рекурсии.
Проблема была не в том, что он не смог оценить требуемую глубину стека сразу. Он, в общем-то, и не должен был, эти вещи зачастую выясняются эмпирически как раз путем прогона программы на тестовых данных. Проблема в том, что компилятор не сгенерировал «по умолчанию» механизм защиты стека, и приложение вместо управляемого крэша получило неуправляемый.
Поставили бы неограниченную глубину стека, и всего делов :-)
К сожалению это невозможно т.к. память под стек должна быть выделена заранее и непрерывным куском. перевыделить её в процессе работы программы с целью увеличения будет крайне проблематично, если вообще возможно.
К счастью это давно возможно. Причем даже не на уровне компилятора, а на уровне операционки.

ulimit -s unlimited

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

А вот вам реализация на уровне компилятора: gcc.gnu.org/wiki/SplitStacks
Это уже какой-то невероятный костыль, применим к многопоточным приложениям — каждому потоку по отдельному стеку…

Обычно размер стека ограничен — памяти не так много чтобы каждому процессу выделать гигабайт памяти под стек когда реально используется по нескольку килобайт. Нет смысла зря держать память которая скорей всего никогда не будет использована. Обычно размер стека указывается по умолчанию при создании проекта, его можно переопределить но это мало когда нужно — дефолтное значение покрывает практически все нужды.
Не нужно по гигабайту выделять каждому приложению. Просто попробуйте запустить свое тестовое приложение с этим вот ulimit -s unlimited и посмотрите что будет.

Операционка может выделять вам под стек динамически столько памяти, сколько вам нужно. Память будет выделяться по мере исчерпания стека.

И никаких костылей. :-)
А меня беспокоит то что такие вещи выясняют эмпирически. Следующий шаг — писать программы с применением гадалок и бросая кубики.
Нельзя такое определять эмпирически. Как минимум должна быть грубая оценка снизу и сверху. И если для обычного алгоритма глубина стека не очень критична(вложенность вызовов небольшая, массивные параметры функций редко передаются через стек) то как только видим рекурсию сразу должен сработать рефлекс — держать стек под контролем, и как минимум оценить наихудший вариант.
А почему беспокоит? Он же не блок управления гидравликой на летящем самолёте перепрограммирует. Какая-то грубая оценка всегда есть. Но вот не угадал с оценкой, ошибся. Запустил, увидел ошибку, изменил свою оценку в нужную сторону. Ничего страшного не произошло, это как раз нормальный процесс разработки. Даже то, что попортил стек во время отладки — это не авария, данные не потеряны, железо не сломалось.
Беспокоит тем что это может пережить все отладки и возникнуть в продуктиве. Там хоть ничего и не сломается, но может не посчитаться зарплата или предприятие встанет на час-другой…
Вот поэтому компилятор и должен помогать программисту. Потому что программистов, которые способны «в уме» без ошибок рассчитать потребности алгоритмов в ресурсах, не существует.
В боевых искусствах вопрос «чье кунфу лучше» определяется просто — кто лежит на полу, тот проиграл. При этом используемый бойцом стиль — десятое дело, хотя на этом вопросе и зарабатывались деньги.
Поэтому для меня всегда была загадкой проблема срача (они же холивары) — нравится тебе С++ — пользуй его, нравится Delphi — да ради бога, Python & Erlang & etc — выбирай не хочу. Хороший программист и на делфях напишет хорошую программу (благо прецеденты есть), плохой же — на любом языке сделает глюкало и тормозило.
Тот же С и С++ на которых понаписано действительно много (чем автор статьи бравирует, кстати) — у огромного количества программ есть одни и те же недостатки, например, я регулярно читаю про очередные баги связанные с переполнением. Это говорит о том что большая часть програмеров С и иже с ним или криворукие или есть недоработка в языке? Или Java — общее мнение уже сложилось: «жрет много памяти».
Недостатки и недоработки можно найти в любом языке, так же как можно найти условия в которых будет побеждать (к примеру) старый добрый Basic.
Поэтому: кончайте срачи и пишите код. Меня как сисадмина интересует именно стабильная работа приложений и возможность понять что идет не так в процессе эксплуатации. Остальное абсолютно неважно.
Хорошего вам кода, уважаемые.
Спасибо за ваше отличное мнение.
Тут Вы правы.
Каждый язык имеет свою нишу и свое время жизни.
Когда-то С (С++) был очень актуален. Мне и самому приятней писать на Java.
Наверно времена С (С++) уходят. Java и C# набирают обороты. Более того, тут кто-то писал, что многие с Java уходят на Scala, что она еще более совершенней )
Я, как автор статьи, признаю свою ошибку. Слишком сильный упор сделал на свой любимый язык. Слишком жестко отозвался о других ЯПах.
И неумно высказался по некоторым вопросам.
Всем спасибо за комментарии. Для меня это был полезный опыт. Как и упавшая карма тоже.
С (С++) никуда не денется. На чём еще можно написать драйвер для самодельного устройства? Кроме ассемблера, конечно.
Просто его ниша на рынке уменьшится и станет уделом узких профессионалов.
Sign up to leave a comment.

Articles