[Aguinore]

0

Вопрос: Работаю программистом на Java. Есть ли смысл в свободное время изучать С++?

1. Да, знание двух языков - это круто и большой плюс к потенциальной зарплате		31	(63.27%)
2. Нет, лучше учить Java, тем более, знаешь ты ее не так чтобы очень глубоко, а зарплаты в ней тоже не маленькие		15	(30.61%)
3. Да, учить надо, но не С++, а напишу в комментах, что.		3	(6.12%)
Всего:		49

Comments

[Flex Ferrum]

yulia_shabunio, в целом - согласен.

Для понимания ООП в частности и проектированию вообще, наверное, лучше пары курсов по RUP сложно что-либо придумать. А там одни сплошные картинки.

[yulia_shabunio]

Flex Ferrum,

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

Жестко, но действенно! )))

[Flex Ferrum]

Жестко, но действенно! )))

Отож! Причём даже в таком виде с первого раза не всё доходит.

[mikluho]

yulia_shabunio,

Да можно этому научиться, и технологии есть.

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

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

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

[dixie_flatline]

mikluho, Гради Буч даёт весь необходимый теорминимум.

[Flex Ferrum]

mikluho, курсы по архитектуре ПО (в рамках RUP с использованием UML) дают необходимые представления и направляют мозги в нужную сторону. Но тут необходимо понимать - какую именно проблему хочешь решить. В том смысле, что если ты уверен, что все в порядке, и архитектуры у тебя получается идеальные, и заказчик доволен, и всё такое прочее - то курсы не помогут.

[CD_Eater]

терпел, терпел, да всё-таки выскажусь
обращаюсь к топикстартеру

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

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

и да, красивый язык вовсе не обязан быть медленным. щас сишники на меня накинутся, потому что я обращаю внимание на рушащийся на глазах последний оплот их аргументации. Уже рулят JIT-компиляторы - они на ходу строят очень оптимизированный нативный код для наиболее часто выполняемых частей программы, причём их оптимизация превосходит оптимизацию статических компиляторов, ведь у последних нет информации о том, по какому пути идёт выполнение программы, причём если со временем программа пойдёт другим путём, то код JIT-компилятора будет перегенерён в реальном времени с учётом новых обстоятельств - мы получаем адаптивную оптимизацию, с которой не сравнится статическая. Короче, уже несколько лет в тестах производительности на наборе типовых алгоритмов JIT-компилятор языка Lua делает gcc-шный код на несколько процентов по скорости! Да, Си - уже не самый быстрый, несмотря на то, как много усилий приходится прикладывать программисту, чтобы оптимизировать код (фактически, он должен предугадывать код ассемблера, когда пишет на Си - а это и есть одна из разновидностей того самого мусора в голове сишников )))

[yulia_shabunio]

CD_Eater, а теперь делайте поправку на то, что человек, не знающий хотя бы в общих чертах хотя бы штук пять разных языков (очень разных) - он просто не поймет, что вы тут сейчаснаписали

Чтобы выбрать самый красивый язык для души - надо иметь возможность их сравнивать!...

[CD_Eater]

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

[yulia_shabunio]

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

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

Flex Ferrum,

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

>> Собственно, "интерфейсов" в С++ нет по той простой причине, что тогда, когда C++ только зарождался, никому в голову не приходило, что "интерфейсы" надо выделять каким-то особенным образом.
да какбе с "того времени" уже не один десяток лет прошел, можно было бы и досыпать синтаксического сахарку. Более молодые языки динамично развиваются уже прям с момента создания (и не только в плане введения синтаксического сахара), а кресты вот только-только оживились, родив 11 и 14 (в процессе) стандарты.

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

>> У каждого из эти способов - есть свои причины появления. И если ты их не понимаешь - это не значит, что обоснования нет, и никто другой не понимает.
Отче, я уверовал! Да вот только многие из этих способов - банально хаки, которые позволяют тут и там чего-то сэкономить или обойти, но вообще код их использующий является антипаттерном или просто решением, принятым без учёта возможных последствий.
Вот вы все пишете, мол "должно быть в голове" "не хочешь - не используй" и т.п. Оно-то хорошо и правильно, да вот отношения к реальному миру имеет не так уж и много. Есть пара-тройка нердов, которые за 10 лет затворничества вызубрили всё и могут обходить и учитывать все проблемы вплоть до багов конкретного компилятора, а есть орава вчерашних студентов, которые вбивают ошибки компилятора в гугл и копипастят решения с стековерфлоу даже не понимая толком что там собственно написано. А есть некоторое промежуточное состояние между этими двумя крайностями, в котором и находится большинство разработчиков.
В крестах они находятся в зоне риска, даже не смотря на давно зазубренные советы "не используй эксепшены, не используй множественное наследование, аккуратно с шаблонами" и пр.
Риальне, если скажешь, что все эти "способы" в плюсовом коде который ты видел в большинстве своём использовались хорошо и грамотно - забирай меня в свою страну эльфов чудесных и образованных программистов, я весь твой

>> Не густо. Вообще, месяца два назад на Хабре C-шники с C++-никами пузиками мерялись, кто лучше кое-какой алгоритм соптимизирует. Языковыми средствами, конечно же. В отношении того, что ты привёл в качестве примера - от этого, вообще говоря, мало толку.
ээ, не передёргивать Там вообще была попытка потроллить разговор за волшебные кейворды, которые ускоряют крестовый код (ну пожалуй сюда ещё можно добросить rvalue references и restrict). А так и я могу рассказать, как в хотспотах делать cache-aware оптимизацию (которая тоже достигается грамотным применением простейших средств языка) или пугать одноклассников коллег обмазанным битовыми операциями кодом. Но это не отменяет того факта, что из-за слабой системы типов программисту в оптимизации требуется делать работу компилятора (+ учитывать много-много деталей, к примеру где-то выиграв статическим полиморфизмом можно проиграть по кэшу из-за распухания кода, даже несмотря на то, что альтернатива тратит время на поиски в vtable. Хотя в данном конкретном утверждении могу и ошибаться, реверсить и мерять надо), и собственно результаты напрямую зависят от того, насколько он хорош в качестве придатка к статическому анализатору его квалификации.
О том, что мы живём в 21 веке и ручное байтоложество является не единственным способом оптимизации (хотя бы то же автоматическое распараллеливание взять) лучше вообще не вспоминать. C++ сложен для статического анализа, что идёт во вред много чему, в т.ч и оптимизациям.

mikluho,
>> Ой... вот развели же холивар...
В ру_программинге уныло, надо ж поразвлекаться Дело-то хорошее.

CD_Eater, а я наивно думал, что это я тут зелёный и толстый

[Flex Ferrum]

CD_Eater, вы, по идее, должны знать, что в сфере софтварной разработки нет абсолюта. И методы, которые хорошо подходят в одних случаях, плохо подходят в других. И наоборот. В частности, я, например, чаще всего хочу быть уверенным в коммутативности операции '+'. Особенно в таких случаях:

var a = 10;
var b = "20";
var c = a + b;
var d = b + a;

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

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

[CD_Eater]

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

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

кстати, в джаве строки конкатенируются плюсиком (разумеется, некоммутативно), вас это нервирует? )))

[Flex Ferrum]

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

Эммм.... Пардон. Так переменные типизированы или нет?

что вы хотели сказать с примером про сложение строк и чисел - не понял.

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

[CD_Eater]

Flex Ferrum,

Так переменные типизированы или нет?

ну вот, и вы попались на непонимании этой фундаментальной свободы. )))
переменные нетипизированы
значения, присваиваемые переменным - имеют тип
на "момент компиляции" по выражению А+Б ничего сказать нельзя
о том, что именно будет происходить при сложении А+Б, станет известно только в рантайме, когда управление дойдёт до этой команды
обработчик плюса определится исходя из имеющихся обработчиков для типов левого и правого значений
да, тривиальные методы оптимизации кода идут лесом, туда им и дорога
вот такие они, динамические языки программирования

если из выражения явным образом не следует его семантика - это плохо записанное выражение

так пишите так, чтобы плюсик для всех ваших типов означал что-то общечеловеческо-понятное
кто ж вам мешает?
А.Add(Б) - абсолютно такая же проблема с семантикой в ООП

[Flex Ferrum]

да какбе с "того времени" уже не один десяток лет прошел, можно было бы и досыпать синтаксического сахарку. Более молодые языки динамично развиваются уже прям с момента создания (и не только в плане введения синтаксического сахара), а кресты вот только-только оживились, родив 11 и 14 (в процессе) стандарты.

твой фаворит,
а смысл? Если существующими средствами можно добиться того же поведения, зачем плодить лишние сущности? Ну, если так уж хочется слова interface в тексте программы - сделай #define interface struct

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

Ну так и ножом порезаться можно, если резать им прям по пальцу. Что ж теперь то? Не знаешь, как использовать ту или иную фишку - не используй. В чём проблема то.

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

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

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

Боюсь, собеседование не пройдёшь. Впрочем, я могу ошибаться.

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

Ещё раз: зачем использовать то, что не знаешь, как использовать? Подавляющее большинство продакшен-кода на C++, который я видел, может быть переписано на любом другом императивном языке (с поддержкой ОО-парадигмы) с весьма небольшими переделками.

ээ, не передёргивать

А я и не передёргиваю. Специально посмотрел дискуссию - не было там ничего о том, что "только ключевые слова".

О том, что мы живём в 21 веке и ручное байтоложество является не единственным способом оптимизации

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

[Flex Ferrum]

ну вот, и вы попались на непонимании этой фундаментальной свободы. )))

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

а смысл? Если существующими средствами можно добиться того же поведения, зачем плодить лишние сущности? Ну, если так уж хочется слова interface в тексте программы - сделай #define interface struct

И препроцессор на пёрле, который если не видит =0 после прототипа метода - поставит #error, приготовь себе кресты сам А вообще брр, я когда это увидел - сразу вспомнил про MFC, и эти воспоминания нельзя назвать хорошими)

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

ухты. А вот на практике он будет менять работу каждый год за +300$ к текущему окладу и ходить по собеседованиям с наглой рожей "а-лучше-всё-равно-хрен-найдёте" А тимлиды и тех.директоры будут продолжать плакать, мол одни имбецилы ходят на собеседования, куда же подевались все нормальные пацаны.
В продуктовых компаниях часто ситуация другая, но именно из-за аутсорсеров люди не самого высокого уровня шляются в святой уверенности, что их возьмут. И куда-нибудь да возьмут, и причём удовлетворят требования по окладу.
И предвосхищая "а не надо работать там, где таких берут" - кривой и косой код мог быть написан ещё до прихода Моего Величества на проект, но теперь-то уж всех построю и всё-всё исправлю, ага-ага

.

Боюсь, собеседование не пройдёшь. Впрочем, я могу ошибаться.

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

Ещё раз: зачем использовать то, что не знаешь, как использовать? Подавляющее большинство продакшен-кода на C++, который я видел, может быть переписано на любом другом императивном языке (с поддержкой ОО-парадигмы) с весьма небольшими переделками.

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

А я и не передёргиваю. Специально посмотрел дискуссию - не было там ничего о том, что "только ключевые слова".

Ну значицца пущай останется на моей совести, буду и дальше оптимизировать программы register'ом и auto

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

"- Вы готовы, дети? Да, капитан!"
А я-то было думал, что раз уж перешли к деталям языка то этап алгоритмической оптимизации можно в разговоре опустить в силу его некоторой ммм.... очевидности? В следующих выпусках нам наверное расскажут про O-нотацию и отличия листа от вектора.
А ещё бывает что на этапе проработки архитектуры недодали сервису масштабируемости (какой-нибудь внезапно взлетевший стартап, допустим) и сделать +1 нода легко и просто не получится. И пока специально обученные архитекторы думают как же это всё расширить и углубить, оптимизировать mission-critical сервис надо уже сейчас, и тогда в ход идёт всё на свете
Хотя мысль-то там была простая - оптимизирущий компилятор нормального языка, адекватно поддающегося статическому анализу, способен сделать с простым и понятным кодом гораздо больше (хотя бы в количественном эквиваленте) чем извращающийся со своим кодом программист на крестах.

[yulia_shabunio]

Люди, я с вас...

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

[Flex Ferrum]

И препроцессор на пёрле, который если не видит =0 после прототипа метода - поставит #error

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

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

Угу. Из серии:
- Кто мы?
- Говнокодеры!
- Что мы хотим??
- Писать говнокод за бабло!!
- Как мы это хотим делать???
- Так, чтобы говнокод волшебным образом работал как надо!!!
Понимаешь, о чём я? По сути ты говоришь: в реальной жизни куча программистов, которые нифига не хотят учиться программировать, а хотят забивать бабло в стартапах и аутсорсинговых конторах. По этому давайте мы сделаем такой инструментарий, чтобы такие программисты чувствовали себя максимально комфортно и могли писать более-менее вменяемый код. Ты не находишь это странным?

Эх, а мне вот попадалось почему-то дикое 5+-летнее легаси с архитектурными решениями

Могу только посочувствовать.

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

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

А ещё бывает что на этапе проработки архитектуры недодали сервису масштабируемости

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

[mikluho]

.umi,

Гради Буч даёт весь необходимый теорминимум

Flex Ferrum,

курсы по архитектуре ПО (в рамках RUP с использованием UML) дают необходимые представления и направляют мозги в нужную сторону

Всё это не учит думать правильно и эффективно. Знать ху из ху и написать типовую реализацию - да, худо-бедно подобрать паттерн под конкретную ситуацию - порой. Писать хороший код без мучительного выбора правильной парадигмы/паттерна - нет.

CD_Eater,

что такое красивый язык?

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

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

[Flex Ferrum]

Всё это не учит думать правильно и эффективно.

mikluho,
По большому счёту, "правильно и эффективно" думать учит только собственный опыт. В смысле серия факапов, косяков, побед и т. п. с последующим post mortem. Помогает окружение, в которое попадаешь. Жесткая критика твоих решений более опытными коллегами, и т. п. Курсы по RUP, которые я слушал, дают очень хороший импульс к тому, чтобы начать думать в правильном направлении. Т. е. понимать, с какой стороны к задаче вообще подходить надо. Причём слушать их надо не менее двух раз. После первого раза кажется, что всё понятно, начинаешь применять на практике, видишь, что нифига не понял, и второе прослушивание уже отвечает на возникшие вопросы.

Flex Ferrum,

Зачем? Виртуальный метод без тела (т. е. у которого есть только объявление) выдаст ошибку линковки.

link-time вообще-то некошерно, потому что полагаясь на него ты можешь выстрелить уже не себе, а кому-нибудь в ногу своей статической библиотекой, например А потом затыкивай такие "интерфейсы" фигурными скобочками.

Ну а если ты в интерфейс добавишь невиртуальный метод - так хуже от этого точно никому не будет.

>> в интерфейс
>> невиртуальный метод

И эти люди называют кого-то говнокодером. Ты точно уверен в том, что ты сейчас написал?
IFoo
^
Bar

IFoo *i = new Bar();
....
С хотя бы одним не невиртуальным методом в IFoo тебя ждёт тот самый поиск его реализации линковщиком А если добавить в невиртуальный метод тело, то это уже какой-то интересный "интерфейс".
Абстрактный класс и интерфейс это всё-таки несколько разные вещи, пускай и в крестах технически это одно и то же.

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

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

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

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

[Flex Ferrum]

link-time вообще-то некошерно, потому что полагаясь на него ты можешь выстрелить уже не себе, а кому-нибудь в ногу своей статической библиотекой, например

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

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

Ай-яй-яй-яй-яй! И эти люди говорят что-то о языковой оптимизации. Конечно уверен! Декларация не-виртуального метода (без его определения) останется таковой ровно до того момента, пока её никто не вызовет в коде. Если вызовов в коде нет - то мало того, что определения может уже и не потребоваться, так ещё и линкер может это определение (если есть) выкинуть.

Абстрактный класс и интерфейс это всё-таки несколько разные вещи

Для меня то, что кроется за ключевым словом "interface", и то, что скрывается за понятием "интерфейс" - совершенно разные вещи. Ну и что с того? Всё, в конечном итоге, зависит от принятых соглашений в команде.

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

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

О дивный идеальный мир.

Речь не об идеальном мире. Речь о том, что кое-кто считает, что профессиональный рост (реальный, а не зарплатный) ему ни к чему. А это проблема немного другого характера. И дело совсем не в нердах, которых надо откуда-то вытаскивать. Как правильно было замечено (не мной) - люди могут делать говно и нисколько этого не стыдиться. И объяснять это тем, что, мол, бизнес такой, заказчики в затылок дышат, у нас идеальные инструменты и фреймворки, которые в нужных местах соломки подложат и т. п.

[mikluho]

Flex Ferrum,

По большому счёту, "правильно и эффективно" думать учит только собственный опыт

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

Или пример из области программинга. Школьное задание (далёкий 91-й год): нарисовать на basic-е шахматную доску и шашки на ней (черно-белые квадратики и кружочки). Сколько можно придумать способов?... а треть класса писала 64 прямоугольника и 24 кружочка плюс заливка цветом каждого элемента (всего-то 176 строк). Кто поумнее - писал циклами. Кто-то даже вложенными, ибо таки усвоил материал пару предыдущих уроков. Но и то, клеточки отдельно, шашечки - отдельно, с заливкой гемор. Самая короткая же, и универсальная и красивая программа брала размер экрана, делила на 8, рисовала сетку, итерационно одним циклом заливала цветом клетки, одновременно рисуя шашки, где надо. Итого, из класса в 30 человек, 1 программер, 4 кодера, 6 говнокодера, остальные вообще не при чём.

Думалка, она же работает и без умных курсов/книжек и т.п. У меня, например, в молодости не было этих книжек. И только много лет спустя, я узнал, что многие используемые мной приёмчики, оказывается, имеют красивые названия

[Flex Ferrum]

mikluho, ну тогда ответ на ваш первоначальный вопрос: думать научить нельзя. Программист это либо умеет делать, либо нет. Можно только развить имеющиеся навыки, но не более того. Так?

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

Ну так аналогично.

[yulia_shabunio]

mikluho, Flex Ferrum,

Программист это либо умеет делать, либо нет.

Эти люди называются "картостроители" и "паковщики".

The Programmers' Stone, классика же

[Flex Ferrum]

The Programmers' Stone, классика же

Эту классику я не читал.

[mikluho]

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

[yulia_shabunio]

Flex Ferrum, ну, я рекомендую
Вот цитата про ООП, например:
«ООП очень по-разному воспринимается картостроителями и паковщиками. Карта картостроителя - это вид объектной модели, в которой множество объектов и взаимосвязей. Картостроитель рассматривает ООП как элегантный способ разрабатывать программы, если они уже поняли проблему. Паковщик смотрит на ООП как на способ побродить вокруг проблемной области, создать программные объекты, а затем просто соединить их как получится. Таким образом, ООП воспринимается как процедурный механизм для перехода от проблемы к программе без вмешательства понимания.»

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

mikluho, я рада, что вам понравилось