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

Пример не совсем удачный к сожалению, ибо например есть вот это: www.o3-software.de/en/index.xhtml Ну и для Active Oberon веб-сервак тоже есть искаропки.

Да и дернуть сишную либу можно легко из любого в общем императивного языка (особенно из реализации которая компилируется в нативный бинарь). Без костылей.
Потом он это дело бросил. В общем, в итоге этот PHP стал жить и стал со временем гораздо популярнее, чем Perl. Но вот эта его «родовая травма» (задумка как набор макросов для Перла) с ним сыграла довольно злую шутку. Язык получился странный. То есть он развивался сам по себе, его никто не проектировал, никто не администрировал процесс развития (ни компания, ни какой-то человек)...

Что за очередная претвзятая чушь? Да еще и из Яндекса. Знания автора в области скриптовых языков так и остались на уровне конца 90-тых кажется. Если вы ни чего не знаете о современном PHP и его месте, не дурите людей. По крайней мере ясно, чего это Кинопоиск не взлетел.

Пруфы для автора:
www.zend.com — Фирма
www.php-fig.org — Стандарты
packagist.org — Репозитории пакетов.

Единственное — PHP умрёт раньше, чем Python, поэтому если вы ленитесь учиться новому, то учитесь Питону. Большой разницы не заметите, но подольше протянете.

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

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

У PHP банально больше 80% веба. Такой объём будет умирать десятилетями, даже если PHP завтра перестанут разрабатывать. Рано хоронить, да.
«Проблема уйдёт» — это чрезмерно оптимистично. Проблема на какой-то промежуток времени станет наоборот ещё хуже: нужно будет знать оба имени функции, потому что невозможно не прикасаться с хоть немного старому коду. Сконвертировать сразу огромный проект может быть проблематично. Для всяких библиотек обратная совместимость может быть очень важна. Реально проблема уйдёт в районе версии 10-й (если переименуют в 8-й), потому что к тому времени на обратную совместимость можно будет забить в большем объёме кода.

Если память не изменяет, в рассылке этот RFC с особым энтузиазмом не приняли, поэтому его судьба под большим вопросом.
Почему только скриптовых? :)

Например, Алгол создан совсем не 68 году :)
Наверное он рассматривал становление языка, насколько можно судить по вики — версии `60 и `68 совершенно разные, при этом `68, цитата «рассматривается как самостоятельный язык». Но да, опять же судя по вики — дата старше на ~десяток лет.
Подводя итог, что можно сказать? Какие языки хорошие, а какие плохие? Ну внутри какой-то группы языков, например между Ruby, Python и PHP, что выбрать? Конечно, правильный ответ Питон, но на самом деле разница между ними в количестве багов допускаемых, в количестве ещё чего-то — 5%, ну, может 10%.

www.tiobe.com/index.php/content/paperinfo/tpci/index.html — Вот тут наглядно о «хороших» и «плохих» языках.
TIOBE меряет «модность» и «трендовость». Это последнее, на что я бы ориентировался.
Интересно чем лектору так не угодил Ruby, да есть некоторые проблемы у языка, возможно не так быстро решаются как хотелось бы (ждем не дождемся когда GIL уберут в MRI), но сам язык как его экосистема и идеология дали для разработки не мало ИМХО.
Слишком синтаксически насыщенный. Сейчас мода (в хорошем смысле) на простоту.
НЛО прилетело и опубликовало эту надпись здесь
Что было бы здорово? Во-первых, какой-нибудь опенсорс-проект, который вы от начала и до конца написали. Желательно, если я делаю какую-нибудь инфраструктуру, чтобы данные быстро считались, ещё что-то, то, конечно, мне было бы интересно, чтобы мне написали чего-нибудь опенсорсное. Не сайтик какой-то сделали, а чего-нибудь по теме. Почему мне это интересно? Могу посмотреть на ваш код, я могу посмотреть как часто вы коммитили, могу посмотреть как вы реагировали на баги от пользователей, баги от разработчиков, которые это используют — всё записано, я всё смотрю и думаю: «Во, тут баг два года уже не закрывали, тут вы невежливо ответили пользователю, тут ещё чего-то — не беру»

Перевод — «Поработай бесплатно, выложи в опенсорс что-нибудь что поможет мне по моей работе, и тогда я может быть рассмотрю твоё резюме». Какая-то дедовщина и поиск халявы.
Рассказывать про историю скриптовых языков и не упомянуть TCL, это надо догадаться.
Писать про разные языки и забыть Lisp, Prolog, Haskell и OCaml как -то странно.
Давать рекомендации по выбору языка не упомянув ни одного современного и перспективного (Scala, Clojure, F#, Rust, хотя бы swift и go) — просто диверсия.
«Scala, Clojure, F#, Rust, хотя бы swift и go» они пока «перспективные» и пока не станут мэйнстримом смысла рекомендовать их я например не вижу.
П.С. прощай карма…
«Мейнстримовость» — не самый лучший критерий при выборе языка.
К тому же последние два уже вполне мейнстрим.
Если выбор осуществляется с целью, гарантированно найти работу после обучения, то это в общем то главный критерий.
Зная только последние два из них, найти работу будет очень и очень не просто, рынок языков очень узок, зная тот же swift не зная objective-c устроиться на работу на порядок сложнее, чем зная objective-c.
«Мейнстримовость» самый надежный критерий. Нужно учить язык на котором «говорит» сообщество, а не вы один. Например, в универе учат английский/немецкий/французкий, а не ньереп, какой-нибудь.
Ага. Я зашел почитать про Haskell и Erlang. Ушел грустный ни с чем.
Но ведь все равно статья во многом интересная.
Как за 1,5 часа рассказать о том, о чем не рассказать за 100 часов? Проходная лекция. Для прям начинающих-начинающих, даже не школьный уровень. Куча неточностей и откровенного ИМХО автора усугубляют ситуацию, поэтому для дошкольных учреждений так же не рекомендовал бы.
А вот тут лекция примерно на ту же тему.

По моему тут лучше рассказано. Хотя и не без огрехов конечно.
Автор, хоть и является очень классным профессионалом (я читал его статьи раньше), очень предвзят и ретрограден. Так компиляторы и библиотеки пишут далеко не только на его любимых C и C++.

PS. И его компилятор C++ не единственный отечественный. В частности мой однокласник участвовал в разработке C++ для процессора «NeuroMatrix» фирмы «Модуль».
Ну, непредвзятых выступлений на подобные темы я вообще не видел. Кроме того, всегда авторы подобных лекция-статей-книг имеют крайней не ровные знания в разных ЯП. То есть прямо видно, что часто автор не в теме.

Что же касается Зуева, у него, судя по этому видео, предвзятость сместилась в сторону Rust/Swift/Go :-) По крайней мере он именно их перечисляет в списке перспективных ЯП, у которых есть будущее.

Ну и понятное дело, что библиотеки пишут на всех ЯП, как жить вообще без библиотек, то есть без повторного использования кода на данном ЯП?
Досмотрел до конца — про перспективные языки, кроме их наличия, он так ни чего и не сказал. Критикуя джаваскрипт он не упомянул наличие большого количества языков, компилируемых в него. А среди них есть и такие, которые позволяют программировать веб-приложения не зная js (например elm).
Системы пишутся на сях.
Очень много инфраструктурных вещей и технологий под веб — Postgres, интерпретаторы PHP, Python (Cpython) и тд пишутся на нем

Крутой язык.
Совет писать Facebook на PHP убил. Особенно учитывая тот факт, что лектор в курсе, что придётся ещё немного поправить PHP и немного написать для него свой транслятор в C.
Фейсбук отказался в HHVM от трансляции в Си, т.к. иногда он проигрывал скорости, но основная причина была в долгой сборке. Сейчас HHVM использует гибридное исполнение, некоторое собирается, а некоторое работает в рантайме через JIT. Это позволило значительно повысить производительность на «прогретых» скриптах и увеличить скорость сборки.

Но это ещё не всё, недавно был выпущен php 7.0, который не сильно уступает hhvm, а, например в случае Laravel 5.1 значительно превосходит его по скорости.

Но и это ещё не всё, php 7.0 был выпущен без JIT, его реализация находится в другой веточке: github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit и является экспериментальной, но перспектива огромна. Так, по некоторым тестам php 7 с разогретым jit превосходит по скорости работы реализацию на сях (gcc -o2), в частности в бенчмарке алгоритма Мандельброта: gist.github.com/dstogov/12323ad13d3240aee8f1

Так что ничего в пыхе уже менять не надо, он обеспечивает нынче более чем достаточную скорость работы, что бы не городить велосипедов из трансляторов. ;)
Если вы конечно уже занимаетесь php, то выбор на чём писать любой веб — очевиден.
А вообще java быстрее, nodejs асинхроннее, go и то и другое, плюс хипсторее :)
1) Только кода на джаве требуется раза в три больше.
2) Да и скоро эта ситуация может измениться (см. бенчмарки), за что я яро радею.

Хотя мне нравится джава, а js только в виде ES7 стандарта или Coffee перевариваю. Надо бы попробовать go, спасибо что напомнили =)
Кода на джаве будет немного больше, за счёт необходимости указывать типы данных. В процентах не скажу, но незначительно больше. И это код, опять же за счёт статической типизации, будет значительно надёжнее.

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

Вообще чем старше становится php, тем больше он похож на джаву. Место, видимо, такое :).
… введения многопоточности

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

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

В некоторых случаях, динамический язык с JIT после «прогрева» может быть быстрее статического. Конечно, это специально подобранные тесты и на практике такое почти не случается, но с развитием JIT-компиляторов возможно динамические языки сравняются со статическими по скорости.
Замечание насчёт JIT интересное, но в java это самый JIT присутствует в полном объёме, так что с его помощью джаву не перегнать. Догнать — может быть когда-нибудь и получится.

Что касается модели памяти — да — дело отдалённого будущего.
1) Только кода на джаве требуется раза в три больше.

Не особо. Кода больше обычно из-за рутинных штук, вроде геттеров/сеттеров/конструкторов. Такое генернит IDE. Ещё есть lombok, который значительно уменьшает размер кода.

2) Да и скоро эта ситуация может измениться (см. бенчмарки), за что я яро радею.

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

Более-менее нормальные бенчмарки есть тут. Там в лидерах java (или что-то для jvm), c, c++, go. Все интерпретируемые языки пока довольно сильно отстают.
На мой взгляд, на нём можно только писать, читать его нельзя. Когда я смотрю на код на Перле и пытаюсь что-то понять, я ничего не понимаю. Может быть, если бы я знал его лучше, я бы что-то понимал, но как я слышал от тех людей, которые всё таки умеют, — они говорят, что легче переписать заново. То есть, программки получаются коротки и реально проще переписать заново, чем разобраться с тем, что там есть и исправить.


Ох уж эти слухи, ох уж эти умельцы.
Мегахоливорная лекция.
Просто неисчерпаемый источник тем для рубки на топорах.
Могу посоветовать автору ещё десяток хотя бы книжек почитать, прежде чем такие статьи писать. Много личной тенденциозности и почти отсебятины. Хотя бы про аду в вики почитал, давно её гражданские используют, в частности, в серьёзном банковском секторе.
Питон лучше рубина? Пельмени лучше жаркого? И современный PHP — это очень мощный инструмент, с быстродействием, благодаря JIT, близким даже к C. Забыт весьма популярный и достойный язык Lua. Где самые модные ныне функциональные языки, начиная с лиспа? Тут можно было бы и про С++ пару добрых слов сказать…
Странные перескоки, например, ругают ручное управление памятью в С (хотя есть и gc для автоматического), а потом пишут, что С++ улучшился объектностью, будто это как-то связано…
Выделил более десятка цитат, достойных скорее всего негативной оценки. Возьму одну. «А в C++ (STL) как реализована строка? Ну, как-то реализована.» Автор, прочитайте хотя бы Страуструпа…
Отличная статья, спасибо.

Думаю, на эту тему в принципе невозможно написать статью, за которую не будут ругать в предвзятости, тенденциозности и неосведомлённости. Но у вас получилось очень объективно. И не потому что мнение совпадает с моим, сам по ходу чтения хотел высказать пару «фэ» :)
> То есть, если у вас уже готовый проект на PHP написан, то никто в здравом уме не будет говорить: «Давайте перепишем всё на Python»

Ну да, ну да…
Автору необходимо детально изучить историю каждого рассматриваемого языка, а не пересказывать легенды из «курилки». Враньё или неточности во многих местах.
Довольно неплохая презентация за исключением одного. Лектор крайне предвзят и слишком саркастичен в отношении многих аспектов многих языков (конечно по большей части php).

И, пожалуй, некие нотки надменности присутствуют. Хотя, скорее всего, я ошибаюсь.

Тем не менее, спасибо за интересный материал))))
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.