Комментарии 91
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется тут не в модной технологии проблема, а то что небыли проведены нормальные предварительные тесты. Вы проверяли производительность перед тем как переписать?
Время потратили зря.
Ну вы прям совсем неопытные. Надо было всех убедить, что это только кажется, что монга тормозит, а на самом деле она делает в три раза больше очень нужной работы, без которой просто невозможно обойтись, и вообще она вся такая распределённая не то что этот примитивный mysql. Проект объявляется большим успехом, участники проекта получают премию и повышение зарплаты, после чего уходят на другие проекты, а поддержка и дальнейшее развитие монги передается каким-нибудь только что нанятым junior-ам.
Чей это логотип с ласточкой в левом углу на картинке?
Ещё забыли про зависимость от библиотек!
Даже в одном языке новая версии вызывает проблемы с совместимостью, и код который компилировался перестаёт собираться.
Переносил с php на питон, конструкции конечно похожее но если в php по умолчанию много чего встроено то в питоне надо подцеплять библиотеки. Например в питоне часть математики типа логарифмом, работа с изображениями, хеш-функции, регексы выполнена в виде отдельных библиотек ( правда много чего идет сразу с языком).
Функция Z, допустим лучше, но другие многочисленные функции Fi — не факт. Так что миграция проекта на язык Y требуется народцу, лучше владеющему этим языком. А соображения лучшего функционирования — это вопрос отдельного исследования.
Вообще, вопрос интересный — откуда такое вавилонское столпотворение языков? Долгоживущий язык постепенно впитывает в себя многие появляющиеся фичи новых языков и, вроде, миграции не требуется. Но, тем не менее, происходят революции с побиванием камнями старых языков. На мой взгляд, это идет не от технологий и оптимизации разработки. Тут какие-то психологические, социальные и иные причины. Вроде смены поколений разработчиков и их тим лидеров.
Вообще, вопрос интересный — откуда такое вавилонское столпотворение языков? Долгоживущий язык постепенно впитывает в себя многие появляющиеся фичи новых языков и, вроде, миграции не требуется. Но, тем не менее, происходят революции с побиванием камнями старых языков. На мой взгляд, это идет не от технологий и оптимизации разработки. Тут какие-то психологические, социальные и иные причины. Вроде смены поколений разработчиков и их тим лидеров.
> откуда такое вавилонское столпотворение языков?
ИМХО причины две
1. Большая часть языков очень плохи, они делаются только ради одной фичи и всё за пределами это фичи сделано плохо. Видимо человек-проектировщик недостаточно умён чтобы сделать хороший язык, тут нужен либо особый талант (Python), либо математика (Haskell).
2. Люди ленивые и наивные, они думают что не нужно ничего изучать, ведь есть «простые» языки в которых сразу всё работает, только они не задумываются что эта простота хороша в простых задачах, а если задача становится чуть сложнее, то от такой простоты только хуже. Например php выстрелил потому что на нём просто было сделать home page, а когда стали делать что-то чуть сложнее оказалось что есть проблемы и языку пришлось эволюционировать в очередную копию джавы, хотя как понимаю полностью от того наследия избавиться не удастся.
ИМХО причины две
1. Большая часть языков очень плохи, они делаются только ради одной фичи и всё за пределами это фичи сделано плохо. Видимо человек-проектировщик недостаточно умён чтобы сделать хороший язык, тут нужен либо особый талант (Python), либо математика (Haskell).
2. Люди ленивые и наивные, они думают что не нужно ничего изучать, ведь есть «простые» языки в которых сразу всё работает, только они не задумываются что эта простота хороша в простых задачах, а если задача становится чуть сложнее, то от такой простоты только хуже. Например php выстрелил потому что на нём просто было сделать home page, а когда стали делать что-то чуть сложнее оказалось что есть проблемы и языку пришлось эволюционировать в очередную копию джавы, хотя как понимаю полностью от того наследия избавиться не удастся.
Всё это понятно, однако не отменяет проблемы — желающих программировать на умирающих языках больше не становится, их трудно хантить, они дорого стоят, я вот например, уже совсем не хочу на перле писать (хотя весь мой опыт на нём) и пойду даже стажёром ради того чтобы сменить технологию.
Конечно переписать целиком весь проект не очень реально, но заменять по частям вполне возможно, и даже не всегда для этого требуется нормальная архитектура проекта, например тот же Perl умеет вызывать Python код, а значит новые вещи можно писать на нём.
Конечно переписать целиком весь проект не очень реально, но заменять по частям вполне возможно, и даже не всегда для этого требуется нормальная архитектура проекта, например тот же Perl умеет вызывать Python код, а значит новые вещи можно писать на нём.
'Вымирающих' языков не бывает, пока на языке пишут, он жив. А уж сколько всего написано (и продолжает писаться) на Perl. И на Ada, и на Fortan и на Asm всё ещё пишут и причём немало. Объём рынка программ и людей — не показатель. Если язык не используется массово в бесчисленных OOO 'Вектор', и на нём не верстают формы в банках, это не значит, что с языком плохо. Немало нишевых языков не могут в принципе быть массовыми. Когда в банках перешли с C++ на Java, с последним ничего не случилось. Скорее наоборот, избавление от массы плохих программистов и случайных людей пошло ему на пользу. Теперь на нём пишут лишь те, кому он действительно нужен. И хорошего спеца найти проще.
Ну как не бывает, вот перл отличный пример — новых проектов на нём очень мало, старые мигрируют на python (насколько помню рамблер так делал), php (юпорн например) и т.д.
Про смерть Perl байки травят наверное, уже лет 10, если не больше, равно как и про ультимативную победу Ruby над всем и вся. Вас почитать, так понятно, что Python близок к идеалу. А в какой-нибудь книге по Lisp подробно объяснят, что если и есть настоящий язык программирования, то это, несомненно, Lisp, а всё остальное отстой и всему хорошему у себя обязано Lisp-у.
Новых проектов на Perl меньше, чем на Python? Это ещё не значит, что язык умирает. Вашему личному опыту могу противопоставить свой — в моей фирме несколько проектов разрабатываются и поддерживаются на Perl, в фирме-партнере запускаются новые проекты на Perl.
Новых проектов на Perl меньше, чем на Python? Это ещё не значит, что язык умирает. Вашему личному опыту могу противопоставить свой — в моей фирме несколько проектов разрабатываются и поддерживаются на Perl, в фирме-партнере запускаются новые проекты на Perl.
Конечно элемент субъективности есть, хотя в коллекцию фактов можно добавить практически полное вымирание русскоязычной рассылки по перлу — moscow.pm, с другой стороны даже если бы перл набирал популярность, он бы не становился от этого привлекательнее.
И да, про lisp тоже много хорошего пишут, и про haskell, но не про perl.
И да, про lisp тоже много хорошего пишут, и про haskell, но не про perl.
И про перл пишут много хорошего — смотря что и где читать. Привлекательность — субъективная штука. Мне нравится писать на перле не меньше, чем на питоне, а в определённых ситуациях (особенно, связанных с использованием регулярных выражений) — куда больше. В русскоязычной среде мало публикаций по перлу? Со всем уважением, русскоязычная среда это ещё не весь мир. Но кстати, mail.ru зачем-то в 2015 году опубликовали целый (и довольно качественный на мой взгляд) курс по умирающему перлу. Там работают исключительно глупцы и плохие программисты? Недавно была очередная встреча русскоязычных перл-программистов. Так что и в России перл не такой уж и мёртвый. Но опять же, мир не ограничивается Россией.
У перла огромная экосистема модулей. Много проектов на перле, в том числе и таких, как MVC фреймворки, живёт себе и развивается. Пусть хейтеры минусуют сколько хотят, но умирает? Отнюдь.
У перла огромная экосистема модулей. Много проектов на перле, в том числе и таких, как MVC фреймворки, живёт себе и развивается. Пусть хейтеры минусуют сколько хотят, но умирает? Отнюдь.
Позвольте вбросить немного статистики
Ну и что эта ваша статистика?
Я не выступаю ни за перл, ни за питон.
Но вот статистика… её трактовать можно по-разному. Например так: питон гораздо менее хороший язык, нежели пхп и перл — требует большего количества программистов для решения аналогичных программ, а так же чаще заставляет отвлекаться от производства на поиск решений тривиальных задач.
Вот уж точно — вбросили.
Ну и даже если далеко не ходить и на хабре посмотреть профильные хабы, то количество страниц с постами:
php — 226
python — 166
perl — 29
php — 226
python — 166
perl — 29
Ох, ну давайте и я вброшу для симметрии.
На графике TIOBE позиции Perl с 2014 года по наши дни явно имеют тенденцию к укреплению. Если так буквально интерпретировать эти данные, то это C и Java надо назвать умирающими языками, причём умирающими стремительно. Кто-то серьёзно считает их умирающими языками?
Perl is not dead: It was early web novices that gave it a bad name
Is Perl dead?
The 7 Most In-Demand Programming Languages for 2017
The top 9 Best Programming Languages You Should Learn In 2017
Perl events
На графике TIOBE позиции Perl с 2014 года по наши дни явно имеют тенденцию к укреплению. Если так буквально интерпретировать эти данные, то это C и Java надо назвать умирающими языками, причём умирающими стремительно. Кто-то серьёзно считает их умирающими языками?
Perl is not dead: It was early web novices that gave it a bad name
Is Perl dead?
The 7 Most In-Demand Programming Languages for 2017
The top 9 Best Programming Languages You Should Learn In 2017
Perl events
Я привел статистику с двух авторитетных рейтингов и с хабра. Вы привели ссылки на статьи с заголовком «цой жив» и на блоги неизвестных блогеров на неизвестных блогах. Это не симметрия.
К тому же, я уже неоднократно встречался с тенденцией миграции перловых проектов на питон (в контексте юниксовых утилит). Обратной миграции я, кажется, ни разу не видел.
К тому же, я уже неоднократно встречался с тенденцией миграции перловых проектов на питон (в контексте юниксовых утилит). Обратной миграции я, кажется, ни разу не видел.
Вы привели два графика (кстати, без ссылок на источники), причём в первом Perl на подъёме, а касательно второго, если зайти на PYPL и посмотреть статистику по странам, то окажется, что в Германии, UK и Франции у перла всё ровно. Но сами способы сбора статистики и её корректной интерпретации вызывают вопросы, и не только у меня.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
Впрочем, хотите считать, что если язык не в хайпе, то он умирает — дело Ваше.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
Впрочем, хотите считать, что если язык не в хайпе, то он умирает — дело Ваше.
НЛО прилетело и опубликовало эту надпись здесь
Приведите пример какого нибудь большого проекта, который стартовал не более года назад на асме. Ну вы поняли. :3 Можно ли назвать асм умершим? Нельзя. В любой ОС на нём написаны весьма важные функции.
НЛО прилетело и опубликовало эту надпись здесь
Можно ли назвать асм умершим? Нельзя.Можно (с оговорками). Никто сегодня не будет писать ничего на asm'е — хотя когда-то игрушки (и не только игрушки!) писались целиком на ASM'е.
P.S. Оговорки — это «малые формы». На tinyAVR и тому подобные «игрушки» до сих под проекты на ассемблере делают… но они как бы по определению не могут быть «большими».
Большой проект не получится. На ассемблере проекты получаются в десятки килобайт ввиду эффективности недостижимой в принципе ЯВУ.
Только вот думать, что «большой — это хорошо» это мозговыверт в результате промывания мозгов. См. например:
https://habrahabr.ru/post/318916/
Только вот думать, что «большой — это хорошо» это мозговыверт в результате промывания мозгов. См. например:
https://habrahabr.ru/post/318916/
Эффективности, простите, чего? Скорости и надежности разработки?
Какая хорошая ссылка — полностью согласен с её автором!
На ассемблере проекты получаются в десятки килобайт ввиду эффективности недостижимой в принципе ЯВУ.Бред какой. Большой проект — это, в первую очередь, проект, в котором задействовано много людей. А уже сколько они там кода порождают — дело десятое.
И вы, в принципе, правы: а на ассемблере проекты получаются маленькими — потому что «большие» оказываются жутко ограниченными и выходят гораздо позже аналогов, написанных на более высокоуровневых языках.
Не то, что больших проектов на ассемблере не бывает в принципе — бывают (вот, например) — просто из на много порядков меньше сегодня, чем было лет 20-30 назад.
Зато если без фанатизма покопаться в Google trends, пробуя разные запросы по разным странам, то можно получить более объективную картину, которую хейтеру уже не захочется демонстрировать.
В вашем понимании «более объективная статистика» формируется, если «копаться, пробуя разные запросы по разным странам»? Более объективная по сравнению с чем? С графиками по всему миру? Это как раз таки более субъективная.
Я тоже считаю статистику с этих рейтингов не идеально показательной, но она точно превосходит по объективности метод «копаться в интернете в поисках мест и сфер, где перл еще не умирает».
Большие проекты сейчас на перле никто не начинает, потому что понимают, что требования к гибкости языка выросли, и новые требования перл никогда не сможет удовлетворить без значительных изменениях в языке. Поэтому перл не дает той гибкости архитектуры, которая необходима для простого масштабирования и развития проекта.
Более того, сколько программистов на перле, столько и диалектов, ибо об этом гласит главный догмат перла «одну задачу можно решить миллионом способов». Вот и получается, что проект либо написан на разных диалектах, либо написан по какому-то стандарту, нарушая идеологию перла (тогда смысл в перле?). Эта идеология была признана бесперспективной, поэтому перл-6 так сильно отличается от перл-5.
Перл не умирает, он будет жить вечно в однострочниках и регулярках.
То, что делает mail.ru к программистам имеет мало отношения, это бизнес, когда есть куча кода работающих проектов на древнем и мутном языке, на котором дефицит специалистов, приходится шевелиться.
НЛО прилетело и опубликовало эту надпись здесь
Сложно (судя по методу исключения)
Делают это сложно :)
Переносить сразу весь проект — гиблое дело, и статья скорее об этом (ровно как и «выбросить старый код и написать все на X»). Но если писать новые модули только на языке X, постепенно рефакторить и адаптировать старый код под безболезненную миграцию… вполне даже реально.
обычно сочетают возможности нескольких языков. Например, для той же home page нужны: php, html (браузер не умеет работать с php исходниками), css (оформление же), js (динамика для страницы в браузеры), sql (php не умеет в SQL базы данных*), json или xml (сериализация данных)
* Под «php не умеет в SQL базы данных» имею ввиду, что php не сможет подключиться к базе данных и взять какие-то данные напрямую без прослойки, только через SQL, а это используется уже другой язык. Хотя в те же файловые БД вполне умеет (данные в файлах), но серьезно этот момент я не расматриваю.
И тут мы вспоминаем, что неплохо завести свое приложение в гуглмаркете. И тут добавляется еще один (или даже не один) язык, т.к. php не пользуется популярностью для создания приложений на android (я сильно сомневаюсь, что создание на php будет тривиальной задачей, хотя это возможно). А еще клиент на ПК. Повезет, если предыдущий язык позволит создать такой клиент, иначе будет выбран еще один язык.
Команда разрастается, создаются новые отделы. Первоначальная страница уже далеко не home page, а полноценное бизнес-приложение, исходный код на десятках языков занимает десятки и сотни тысяч строк кода. И тут приходит человек, который является Свидетелем Нового Языка и заявляет:
— Новый Язык лучше вашего.
И тут выясняется:
1) для перехода на новый язык нужно покупать лицензии всяких IDE (у некоторых IDE, особенно игровых, есть пункт — бесплатен для некоммерческого пользования)
2) нанимать новых программистов и переучивать старых
3) выхлоп от затеи может быть незначительный (если вообще он будет)
4) тратить время на переписывание кода
5) нарушается заповедь: «Работает — не трогай!»
И даже когда придет время разработки нового проекта получим, что хорошие профи на старом языке могут сделать куда лучшую систему, чем свидетель на Новом языке.
* Под «php не умеет в SQL базы данных» имею ввиду, что php не сможет подключиться к базе данных и взять какие-то данные напрямую без прослойки, только через SQL, а это используется уже другой язык. Хотя в те же файловые БД вполне умеет (данные в файлах), но серьезно этот момент я не расматриваю.
И тут мы вспоминаем, что неплохо завести свое приложение в гуглмаркете. И тут добавляется еще один (или даже не один) язык, т.к. php не пользуется популярностью для создания приложений на android (я сильно сомневаюсь, что создание на php будет тривиальной задачей, хотя это возможно). А еще клиент на ПК. Повезет, если предыдущий язык позволит создать такой клиент, иначе будет выбран еще один язык.
Команда разрастается, создаются новые отделы. Первоначальная страница уже далеко не home page, а полноценное бизнес-приложение, исходный код на десятках языков занимает десятки и сотни тысяч строк кода. И тут приходит человек, который является Свидетелем Нового Языка и заявляет:
— Новый Язык лучше вашего.
И тут выясняется:
1) для перехода на новый язык нужно покупать лицензии всяких IDE (у некоторых IDE, особенно игровых, есть пункт — бесплатен для некоммерческого пользования)
2) нанимать новых программистов и переучивать старых
3) выхлоп от затеи может быть незначительный (если вообще он будет)
4) тратить время на переписывание кода
5) нарушается заповедь: «Работает — не трогай!»
И даже когда придет время разработки нового проекта получим, что хорошие профи на старом языке могут сделать куда лучшую систему, чем свидетель на Новом языке.
НЛО прилетело и опубликовало эту надпись здесь
Вредная заповедь? Зависит от контекста. Где-то эта заповедь всего лишь оправдание лени и нежелание разбираться с черным ящиком.
В то же время существуют ситуации, где эта заповедь оправдана:
1) новый разраб менее компетентен в задаче и его код выполняется медленно и с большим количеством багов. Старый код приоритетен, а его недостатки давно изучены.
Или вообще отсутствие свободных специалистов, которые могут заняться этим кодом.
2) неприоритетный/некритичный участок.
3) изменение кода никогда не окупится.
4) дедлайн
5) код не используется в коммерческом секторе (сочетается с п.3)
По третьему пункту часто встречается в бюджетных организациях, там встречаются программы со времен DOS. И видел работающие компьютеры, которые не смогут потянуть даже устаревшую Windows XP. Доходило до того, что предприятие может выделить на обновление IT-сектора не более 1к руб в год из-за зависимости от гос.бюджета. Конечно, отсутствие квалифицированных IT-специалистов негативно сказывается, но даже у частников предложение по вакансиям в районе 5-10к руб (10к руб для начальника отдела!). Соответственно, специалисты предпочитают уехать.
В такой ситуации (пункты 1,3 и 5), когда все работает неведомым образом, только и остается надеяться на продолжение чуда. И заповедь «Работает — не трогай!» вполне спасает от слабых специалистов. Либо качнуть квалификацию и уехать заграницу, хотя бы в ту же Россию.
В то же время существуют ситуации, где эта заповедь оправдана:
1) новый разраб менее компетентен в задаче и его код выполняется медленно и с большим количеством багов. Старый код приоритетен, а его недостатки давно изучены.
Или вообще отсутствие свободных специалистов, которые могут заняться этим кодом.
2) неприоритетный/некритичный участок.
3) изменение кода никогда не окупится.
4) дедлайн
5) код не используется в коммерческом секторе (сочетается с п.3)
По третьему пункту часто встречается в бюджетных организациях, там встречаются программы со времен DOS. И видел работающие компьютеры, которые не смогут потянуть даже устаревшую Windows XP. Доходило до того, что предприятие может выделить на обновление IT-сектора не более 1к руб в год из-за зависимости от гос.бюджета. Конечно, отсутствие квалифицированных IT-специалистов негативно сказывается, но даже у частников предложение по вакансиям в районе 5-10к руб (10к руб для начальника отдела!). Соответственно, специалисты предпочитают уехать.
В такой ситуации (пункты 1,3 и 5), когда все работает неведомым образом, только и остается надеяться на продолжение чуда. И заповедь «Работает — не трогай!» вполне спасает от слабых специалистов. Либо качнуть квалификацию и уехать заграницу, хотя бы в ту же Россию.
Вообще не понимаю, зачем менять шило на мыло? Чем Perl хуже был? Я ещё понимаю, переписывание с Fortran на C++.
Зачем переписывать с Fortran на C++ это не понятно, действительно.
Неразумная затея, т.к. на Fortran может быть записана математическая библиотека и обоснована, что она работает верно!
И перенос на С++ порождает:
1) необходимость наличия доказательства, что преобразование эквивалентно, т.е. одна операция не превратится в другую.
2) отладка и доказательство, что полученный код верен.
Для серьезных институтов перенос работающих алгоритмов ради… А собственно, ради чего переносить код на другой язык? Вот серьезно?
И перенос на С++ порождает:
1) необходимость наличия доказательства, что преобразование эквивалентно, т.е. одна операция не превратится в другую.
2) отладка и доказательство, что полученный код верен.
Для серьезных институтов перенос работающих алгоритмов ради… А собственно, ради чего переносить код на другой язык? Вот серьезно?
Почему практически все статьи по философии и методологии программирования — переводные? Что ни размышление — перевод. Неужели в России подобные вопросы не возникают ни у кого?
Потому что на Земле живут 7 миллиардов человек, а в России из них — 7 миллиардов.
Плюс та же причина по которой американская литература в России лучше русской, а русская в Америке — лучше американской: «совсем отстой» переводить никто не будет, так что среди переводных вещей количество стоящего автоматически больше, чем среди оригинальных…
Плюс та же причина по которой американская литература в России лучше русской, а русская в Америке — лучше американской: «совсем отстой» переводить никто не будет, так что среди переводных вещей количество стоящего автоматически больше, чем среди оригинальных…
Странное утверждение, я ведь не сравниваю русскоязычные статьи с переводными, я говорю, что по этому направлению в России в принципе не пишут ничего.
Думаю, что достойные профессионалы из России(СНГ), которые могли бы написать хорошие статьи либо свалили, либо у них «срочно, важно, п***ц» и им не до того.
Кстати недостаток ресурсов приводит к тому, что в проекте нет документации и тестов на начальном этапе, а потом проект кое-как сдают и забивают на него совсем, до стадии полного цикла доходят единицы разработчиков в больших софтовых компаниях типа Я, М, и др ([шепотом] и даже там тоже «срочно, важно, п***ц», вместо «think, plan, do, check»).
Это я все к чему: если человек не практикует полный цикл разработки годами на глубоком системном уровне (банально не участвовал в архитектуре, разработке и внедрении чего-то уровня cURL), то он скорее всего не способен что-то внятное написать про философию разработки, а те единицы, которые способны — как я уже сказал — вечно заняты.
Кстати недостаток ресурсов приводит к тому, что в проекте нет документации и тестов на начальном этапе, а потом проект кое-как сдают и забивают на него совсем, до стадии полного цикла доходят единицы разработчиков в больших софтовых компаниях типа Я, М, и др ([шепотом] и даже там тоже «срочно, важно, п***ц», вместо «think, plan, do, check»).
Это я все к чему: если человек не практикует полный цикл разработки годами на глубоком системном уровне (банально не участвовал в архитектуре, разработке и внедрении чего-то уровня cURL), то он скорее всего не способен что-то внятное написать про философию разработки, а те единицы, которые способны — как я уже сказал — вечно заняты.
Это от того, что статьи «по философии» программирования в 90% случаев — реклама от евангелиста новообразовавшегося форка программирования. Язык «X» лучше, потому что все вокруг меня программируют на нём. И начинается притягивание за уши аргументов «за».
А вот по методологии программирования — то есть программирования как науки — таких статей мало вообще. И они теряются в общем гомоне холивара.
Ну, и математическая школа в России вырождается вместе с общим вырождением. Аргумент заработка побеждает голос разума.
А вот по методологии программирования — то есть программирования как науки — таких статей мало вообще. И они теряются в общем гомоне холивара.
Ну, и математическая школа в России вырождается вместе с общим вырождением. Аргумент заработка побеждает голос разума.
Наверняка возникают, но много работы на иностранных заказчиков, которые и заказывают музыку выбирают технологии. Кроме того, сложилась определенная концентрация профессионального сообщества. Рискну предположить, что переводы в основном с английского, а авторы живут/работают чаще в США ;)
Скорее приверженность к использованию английского в IT:
https://blog.codinghorror.com/the-ugly-american-programmer/
https://blog.codinghorror.com/the-ugly-american-programmer/
Я один считаю прыгание с языка на язык полным идиотизмом?
По-моему, для того, что-бы стать Вильямом, понимаете ли, нашим Шекспиром, необходимо мировоззрение обогащать, а не диалекты английского языка изучать.
А то получается: не знаю 3-й закон Ньютона — изучу его… а, н-нет! Изучу восточноанглийские диалекты — это и даст мне знания в области физики!
Когда ты с опытом работы начинаешь видеть, что твой язык спроектирован криво, не позволяет писать выразительный код и т.п., а вот рядом есть язык в котором все эти проблемы имеют элегантное решение, то начинаешь думать — а зачем я трачу своё время на работу с технологией, которая кажется отстойной?
Да она рабочая, да можно написать работающее приложение, но преимуществ нет, а неудобства есть, а время уходит.
Да она рабочая, да можно написать работающее приложение, но преимуществ нет, а неудобства есть, а время уходит.
Но обычно всё наоборот — люди используют не лучшие, а наиболее распространённые в мире технологии и языки, (что ещё больше способствует их расширению). При этом их первичная популярность может быть обусловлена чем угодно — низким порогом вхождения, открытостью и бесплатностью, моделью разработки или идеологией, или вообще случайными вещами.
Коммерческие UNIX машины были (и есть во многом) объективно лучше Linux. MINIX и BSD спроектированы лучше Linux. Успех его был обусловлен изначальной бесплатностью и открытой 'базарной' моделью разработки с 'вирусной' лицензией — фактически по идеологическим причинам.
Аналогично Ada много лучше C++, а Smalltalk много лучше Java, но закрытые модели и излишне высокие цены во время массового распространения сетей и персоналок не позволили им вырваться в лидеры.
И это плохо, ибо очень тормозит науку и инженерию. Последствия PHP бума не разгребут ещё многие годы.
Коммерческие UNIX машины были (и есть во многом) объективно лучше Linux. MINIX и BSD спроектированы лучше Linux. Успех его был обусловлен изначальной бесплатностью и открытой 'базарной' моделью разработки с 'вирусной' лицензией — фактически по идеологическим причинам.
Аналогично Ada много лучше C++, а Smalltalk много лучше Java, но закрытые модели и излишне высокие цены во время массового распространения сетей и персоналок не позволили им вырваться в лидеры.
И это плохо, ибо очень тормозит науку и инженерию. Последствия PHP бума не разгребут ещё многие годы.
так и я использовал и убеждал себя что неплохой язык (у него действительно есть плюсы), что деньги платят и т.п., но как-то накопилось, больше не хочется, пока не прижмёт буду искать что-то лучшее, пока интересны Python, Elixir и Haskell
Коммерческие UNIX машины были (и есть во многом) объективно лучше Linux.Когда-то — были лучше. Сейчас — остались только отдельные, очень узкие ниши, где они имеют преимущество.
MINIX и BSD спроектированы лучше Linux. Успех его был обусловлен изначальной бесплатностью и открытой 'базарной' моделью разработки с 'вирусной' лицензией — фактически по идеологическим причинам.Совершенно неважно — с чего начался успех. В какой-то момент начинается эффект «каши из топора», независимо ни от чего.
Аналогично Ada много лучше C++, а Smalltalk много лучше JavaОчень спорное отверждение. У обоих языков есть интересные идеи, «утерянные» в C++ и Java, но в целом — оба языка оказываются в подавляющем большинстве случаев сильно менее удобными и гораздо более слабыми.
Последствия PHP бума не разгребут ещё многие годы.Вы правы, конечно, но попытки заставить переписать всё с PHP на Ada ни к чему хорошему не приведут. Куда более разумный подход — постепенная модификация языка и избавление от «болячек». Да, не так эффектно, как переписывание тысяч строк кода с perl на python, но, в конечном итоге, более эффективно…
Проблема того же PHP даже не в самом PHP, а в качестве комьюнити.
Вообще «пышечка» изначально была придумана как надстройка над HTML. Фактически это темплейтный движок, в нем даже классов не было, а все функции глобальные. Ну чем не темплейтный движок?
Ну естественно темплейтный движок точно такой же Тьюринг полный язык как и любой другой, и естественно на нем можно писать серверный код, а не патчить HTML налету. Если до этого все было хорошо, то вот тут резко стало грустно. Вот на секундочку закройте глаза и представьте, что вы на Markdown решили в базу ходить и файлики читать… ну как, понравилось?
Примерно то же самое происходит сейчас с JS. Он уехал на сервер и теперь он везде, даже ваш любимый Slack на JS и пара популярных редакторов. И опять же JS далеко не идеален (кстати до ES6 в нем тоже классов не было, «Совпадение? Не думаю», ну прототипы не в счет), но плохой код можно писать на любом языке программирования, а порог входа ничтожно низкий. Думаю горя мы еще хряпнем, но проблема НЕ в технологиях, а в социодинамике.
Ну и вдогонку: что для PHP, что для JS в итоге запилены надстройки с типизацией. Питон вон тоже пошел по пути типизации. Совпадение? Ну вы поняли.
Вообще «пышечка» изначально была придумана как надстройка над HTML. Фактически это темплейтный движок, в нем даже классов не было, а все функции глобальные. Ну чем не темплейтный движок?
Ну естественно темплейтный движок точно такой же Тьюринг полный язык как и любой другой, и естественно на нем можно писать серверный код, а не патчить HTML налету. Если до этого все было хорошо, то вот тут резко стало грустно. Вот на секундочку закройте глаза и представьте, что вы на Markdown решили в базу ходить и файлики читать… ну как, понравилось?
Примерно то же самое происходит сейчас с JS. Он уехал на сервер и теперь он везде, даже ваш любимый Slack на JS и пара популярных редакторов. И опять же JS далеко не идеален (кстати до ES6 в нем тоже классов не было, «Совпадение? Не думаю», ну прототипы не в счет), но плохой код можно писать на любом языке программирования, а порог входа ничтожно низкий. Думаю горя мы еще хряпнем, но проблема НЕ в технологиях, а в социодинамике.
Ну и вдогонку: что для PHP, что для JS в итоге запилены надстройки с типизацией. Питон вон тоже пошел по пути типизации. Совпадение? Ну вы поняли.
Проблема PHP и прочих 'базарных' моделей в их стихийности, они не были спроектированы сразу нормальными и расширяемыми.
Комьюнити сталеет, набирается критическая масса опытных специалистов для качественных переходов. JS был разработан за 10 дней, у первой версии PHP так же был малый цикл. Это не Haskell с его академическими выкладками, или Erlang под долгой вычисткой. Поэтому ожидать отсутствия ошибок в ядре не приходится… но срабатывает принцип «количество в качество». Чем обширнее компьюнити, тем вероятнее появление качественных архитектурных решений.
В C++ опытный разработчик может использовать автоматическое управление памятью в сложных структурах данных — а в Ada одно из двух, или сложная структура данных, или автоматическое управление памятью.
Так что я бы не сказал что Ada был лучше C++.
По отзывам людей из аэрокосмической индустрии (в США само собой, про Россию ничего не знаю) код на Ada пишется быстрее и получается чище и безопаснее. причина, по которой многие используют в ней C++ — страх не найти быструю замену увольвшегося инженера. (При этом о качестве мало кто думает). Ну и в С++ нет автоматического управления памятью, все shared ptr и прочие — не более чем кривые костыли — реализованные в стандартной либе как классы.
В чем принципиальное отличие механизма, реализованного в языке и механизма, реализованного в стандартной библиотеке?
Ни в чём, ежели он реализован хорошо, но после Objective C и Ada в C++ всё кажется плохо. Впрочем, как язык написания игр и прочих быстрых, но не критических приложений, он ничего (ещё бы названия классов и методов нормальными были), а программы для боинга я бы на нём не рискнул. Вы лучше не моё личное примечание обсуждайте — а первые предложения с объективными мнениями опытных инженеров. То же самое говорили в компаниях после вынужденного перехода с Smalltalk на Java.
Тигр был лучше Т34 объективно, но войну проиграл. Lamborghini лучше Lada, но популярнее Lada. И всё это не по идеологическим причинам, а вполне по экономическим.
Так же и со всеми языками, операционками и прочим софтом. Всё было обусловлено экономически. Требовалась ОС, которую можно кастомизировать, и дешевле оказался кривой Linux, чем коммерческие UNIX'ы. ЯП выигрывают, когда появляется много раб. силы соответствующей квалификации по соответствующей цене.
Я один считаю прыгание с языка на язык полным идиотизмом?
Нет, другие идиоты тоже так считают. Не нужно прыгать с плохого языка на плохой, прыгайте на хороший.
Видите ли, судя по всему, вы ошибочно полагаете, что все языки одинаковы (иначе бы вы так не считали). Посему осмелюсь предположить, что вы не видите разницы в языках кроме синтаксиса, а дальше примитивных управляющих конструкций (if, for, function) вы не ушли. А ведь существует еще множество современных механизмов, которые сильно упрощают применение многих паттернов и проектирование сложных механизмов, повышая и читаемость, и дальнейшую поддержку проектов.
И даже наличие конструкции A в языке X не говорит о том, что в языке X конструкция A будет реализована так же удобно, гибко и выразительно, как в языке Y. Например, perl фактически умеет ООП, но вы его там видели? Это кактус, который рано или поздно устанешь жрать. Даже в пхп лучше. А обработку исключений видели? Если какой-нибудь питонист/явист взглянет на обработку исключений в перле, на ее гибкость и удобство, с ним случится неминуемый инсульт.
Изначально я считал перл нормальным языком, потому что оперировал чисто фактически заявленными данными, пока не столкнулся с ним лично и не увидел реализацию всех этих возможностей. Теперь я понимаю тенденции переписывания с перла на питон. Кроме того, я искренне разделяю скорбь тех, кто в силу огромного количества кода не может это осуществить, а желающих поддерживать подобные монстр-проекты с каждым днем все меньше.
И вот из сегодняшнего почитайте, коллега пишет
Сами вы идиот (коли уж решили меня идиотом назвать). Я никого идиотами не называл, а сказал, что подход идиотский.
Где я говорил, что прыгать нужно с плохого на плохое?
Мою мысль так и не услышали: не по языкам скакать надо, а о цели думать.
Мою мысль так и не услышали: не по языкам скакать надо, а о цели думать.
Согласен, а если язык является не средством достижения цели, а тормозильным фактором, то о чем стоит подумать?
Никто не учитывает почему-то, что переписывание кода ведется в хронологической последовательности много позже, чем оригинал. А это многое решает. Мне, например, довелось переписывать с C++ на Python (бывает и такое). Так вот код сократился многократно. Не потому, что С++ более многословен, а потому что у меня в 2017-м году есть возможность использовать то, что 10 лет назад у парней, пишущих оригинал этого приложения, не было. Например ZeroMQ тогда еще не существовал. Kafka не существовала.
Я просто выкинул 70% велосипедов в помойку, заменив это чужими продуктами.
А еще я, в отличие от тех, кто писал программу, которую гонят вперед запросы сейлзов, имел возможность видеть почти полный функционал изначально. А это значит, что и архитектуру можно построить намного удобнее и сократить код.
Я просто выкинул 70% велосипедов в помойку, заменив это чужими продуктами.
А еще я, в отличие от тех, кто писал программу, которую гонят вперед запросы сейлзов, имел возможность видеть почти полный функционал изначально. А это значит, что и архитектуру можно построить намного удобнее и сократить код.
Да, это же повод для рефакторинга — как говорил классик — программа становится хорошей только после того как переписана три раза.
а потому что у меня в 2017-м году есть возможность использовать то, что 10 лет назад у парней, пишущих оригинал этого приложения, не было. Например ZeroMQ тогда еще не существовал. Kafka не существовала.
А что мешало использовать С++ библиотеки для работы с ZeroMQ? Может быть и оставшиеся 30% не надо было бы переписывать?
Не, тут два разных момента. Заменить велосипеды на 3rd-party и вообще провести рефакторинг — это была одна задача из нескольких. Если бы она была только одной, менять язык бы не было смысла.
У нас другая проблема. Мы не успеваем за придурью сейлзов. А сейлзы в нашей компании иерархически находятся над хозяевами компании. Вся придурь, что они хотят — мы должны имплементировать за сутки. Переделывать потом ничего не надо — ведь придет новая порция придури. Технический долг? Нет такого слова!
Короче, проще так объяснить: я живу на востоке (Израиль). Тут все тяп ляп и все быстро. Впарили продукт, а потом хоть трава не расти.
C++ дорого наказывает быдлокодеров. Нам это не подходит. Нам нужен язык, на котором можно быстро забацать прототип перед POC и степень быдлокодести которого к нам будет лояльна.
P.S. это не я вас минусанул
У нас другая проблема. Мы не успеваем за придурью сейлзов. А сейлзы в нашей компании иерархически находятся над хозяевами компании. Вся придурь, что они хотят — мы должны имплементировать за сутки. Переделывать потом ничего не надо — ведь придет новая порция придури. Технический долг? Нет такого слова!
Короче, проще так объяснить: я живу на востоке (Израиль). Тут все тяп ляп и все быстро. Впарили продукт, а потом хоть трава не расти.
C++ дорого наказывает быдлокодеров. Нам это не подходит. Нам нужен язык, на котором можно быстро забацать прототип перед POC и степень быдлокодести которого к нам будет лояльна.
P.S. это не я вас минусанул
Лучше бы потратили это время не на ручное преобразование, а на написание автоматизированного инструмента делающего эту рутинную работу. Пользы было бы куда больше и возможно управились бы даже быстрее.
Я думаю ограничений два:
1. Отсутствие в «принимающем» языке возможностей «изначального» языка: допустим есть программа, которая что-то пишет по адресам (фиксированным) памяти, откуда читают другие программы. Перепишем её на языке, который вообще не имеет понятия указателей, адресов и их арифметики? Нет.
2. Отсутствие такого же функционала (что не только выражается в разных библиотеках, а скажем в реализации понятия интерфейс, интерфейсы и объекты в delphi имеют определенную реализацию, заточенную под COM. Если их переносить втупую в другой язык (скажем С), придется написать много чего специфического для такой задачи (работа с COM, диспетчеризация по имени). Хотя простую программу перенести можно без труда. Значит для специфических возможностей в принимающем языке должны быть реализованы соответствующие «библиотеки», причем так, чтобы все известные «трюки» старого языка либо продолжили работать, либо были отслежены и переделаны (например, ведущая длина строки в строке, или завершающий ноль, или отрицательные смещения в структуре).
Можно согласится с тем, что «просто переписать на язык X» невозможно, однако сделать сложную программу для трансляции все-таки возможно, и тогда остальные программы уже будет переводить просто.
1. Отсутствие в «принимающем» языке возможностей «изначального» языка: допустим есть программа, которая что-то пишет по адресам (фиксированным) памяти, откуда читают другие программы. Перепишем её на языке, который вообще не имеет понятия указателей, адресов и их арифметики? Нет.
2. Отсутствие такого же функционала (что не только выражается в разных библиотеках, а скажем в реализации понятия интерфейс, интерфейсы и объекты в delphi имеют определенную реализацию, заточенную под COM. Если их переносить втупую в другой язык (скажем С), придется написать много чего специфического для такой задачи (работа с COM, диспетчеризация по имени). Хотя простую программу перенести можно без труда. Значит для специфических возможностей в принимающем языке должны быть реализованы соответствующие «библиотеки», причем так, чтобы все известные «трюки» старого языка либо продолжили работать, либо были отслежены и переделаны (например, ведущая длина строки в строке, или завершающий ноль, или отрицательные смещения в структуре).
Можно согласится с тем, что «просто переписать на язык X» невозможно, однако сделать сложную программу для трансляции все-таки возможно, и тогда остальные программы уже будет переводить просто.
Если переписывание с языка на язык сводится к копипасте, то зачем вообще это делать?
Говоря проще: Потому что просто только кошки родятся.
«Просто переписать на язык Х» невозможно.
Таки зависит от языков, например для переписывания Fortran на C существуют инструменты, которые дают код, который можно сразу компилировать и он даёт результаты идентичные оригинальному. Хотя я понимаю, что в статье скорее всего имеется в виду более современные ЯП.
Таки зависит от языков, например для переписывания Fortran на C существуют инструменты, которые дают код, который можно сразу компилировать и он даёт результаты идентичные оригинальному. Хотя я понимаю, что в статье скорее всего имеется в виду более современные ЯП.
Это не переписывание, это трансляция. Так-то можно с помощью и с помощью Emscriptenа с C++ на JavaScript «переписать» или с помощью Cythonа с Python'а на C — вот только потом этот код ни читать, ни исправлять невозможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Почему вы просто не перепишете это на язык X?»