Comments 139
А вы можете сформулировать в чем по вашему разница?
Фундаментальное — это когда собираются ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч других программистов.
Прикладное — это когда «ИП Махачетурян» нужно автоматизировать бизнес-процесс и у него нет денег на оплату труда кандидатов и доцентов и исполнитель скажет — «Алгебра? Почему несколько алгебр? Она в 11 классе закончилась, потом был только матанализ и линейная геометрия».
Какое странное представление о занятиях «ботанов».
Я ответил на ваш вопрос?
А имел в виду я всего навсего то что для написания TCP/IP и для складского калькулятора нужны разные уровни квалификации.
Хабр такой смешной, когда такой агрессивный.
Hi Alan, What do think about the current state of language design (Swift, Rust, Go)? Anything that makes you happy/annoys you?
reply
alankay1 17 hours ago
I think all languages today annoy me — just put me down as a grump. They seem to be at a very weak level of discourse for the 21st century. (But a few are fun when looked at from the perspectives of the past e.g. Erlang ...)
Отсюда https://news.ycombinator.com/item?id=11939851 говорил прямо вчера
What Killed Smalltalk Could Kill Ruby — RailsConf 09: Robert Martin
P.S. Меня одного раздражает его манера публичных выступлений?
В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто
Ну справедливости ради это относится ко всем языкам вообще. Неужели все огромные проекты на Java прям таки мега гибкие? Что-то сильно сомневаюсь, количества легаси на джаве думаю побольше чем в том же PHP.
Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…
Как говорится, хватит писать легаси код! Почему-то люди предпочитают революционный подход более естественному эволюционному.
P.S. Меня одного раздражает его манера публичных выступлений?
Как он выступает на конференциях меня особо не раздражает. Наверное это потому что я когда-то посмотрел его курс лекций по чистому коду где он раз в минуту сменял образ и костюм… вот там бесило дико.
В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля.Разве в плохо написанном большом проекте, например, на C++, легко и просто поменять или добавить что-то? Если вы пишете проект без оглядки на какую-либо архитектуру и проектирование, не делая рефакторинг, без тестов, без соглашений, то в конце-концов независимо от языка ваш проект превратится в свалку спагетти-говнокода и костылей, который невозможно будет развивать и расширять без боли. Хороший пример — проект notepad++ (статья про это)
Этот тезис про «динамическую типизацию» (уж простите мне категоричность, но, думаю, я могу себе ее в данном случае позволить, долго уже занимаюсь этими вопросами) — полная чушь
Он где-то говорил что всему виной динамическая типизация? Я как-то этого не услышал. Ну и для справки — боб часто упоминает что сильная динамическая типизация + тесты намного эффективнее статической типизации без тестов).
Рассуждения о том, что динамическая типизация на «больших» проектах приводит к бОльшему количеству ошибок или к сложностям с поддержкой проектов на таких языках, скорее выдают человека, который устриц-то не пробовал. А если пробовал, то давайте ближе к фактам: на каком проекте, какой язык, какие сложности…
Да и на Scheme вывали случаи, когда я путал строки и числа и компилятор это пропускал. Правда, обычно это было связано с чтением внешних данных.
Вопрос-то не в этом. В «большом», серьезном проекте (кстати, независимо от типизации… даже если это великий Haskell, наверное — поправьте, если не так) будут предприняты меры по контролю «правильности» кода (те же тесты как минимум), и исходное утверждение нужно читать в одном из двух возможных вариантов:
- проектом на динамически-типизированном языке невозможно управлять так же хорошо, как аналогичным на статически-типизированном
- управлять можно примерно так же, но сделать это сложнее
Какой из этих тезисов вы хотите обосновать своим опытом?
Затем что статическая типизация предотвращает лишь малую долю проблем связанных с рефакторингом и разработкой.
сильная динамическая отлавливает ошибки с типами в рантайме. С другой стороны динамическая типизация минимально но ускоряет разработку простых систем.
Посмотрите на python. Там есть тайпхинтинг, при помощи которого можно организовать статический анализ (у нас есть вся необходимая информация о типах), с другой стороны тайпхинтинг вообще не влияет на рантайм и мы все еще имеем дело с динамической типизацией.
Слышал аналогичные отзывы про Rust.
Жаль Smalltalk не стал таким популярным как Python, Ruby или PHP.Вы перечислили языки, в которых нарушается принцип «Всё доступно для изменения в любое время» (Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений). Нельзя внести изменения в работающую программу, например, на Python, её придётся остановить и запустить заново. При этом Smalltalk, и, насколько я знаю, Lisp это позволяют.
Если вы хотите изменить интегрированную среду разработки, вы можете сделать это в работающей системе, без остановки, перекомпиляции и перезапуска. Если вам необходима в языке новая управляющая структура, вы можете добавить её. В некоторых реализациях вы можете также изменить синтаксис языка или способ работы сборщика мусора.
конечно, если в IT сообществах изобретение велосипедов высмеивается в пользу готовых фреймворков.
Когда программист сталкивается с избыточностью и нечитабельностью макросов в C++, или с осознанием факта, что есть 20 других компиляторов С++, которые скомпилят его продукт по-другому, в чем возникает необходимость подстраивать продукт под каждый компилятор и каждый тип архитектур, ему это надоедает (потому что он перфекционист) и изобретает новый язык… скажем C#.
Вот только создать C# на истеричной ноте отвращения к C++, сугубо под свои нужды, не продумав на 20 лет вперед, что еще может понадобится в языке через 10 лет, привело к тому что огромные деньги вбуханы в поддержку и раскрутку языка, и эта инертность по факту тормозит развитие программизма в целом. Теперь будем еще 10 лет обсасывать причёсывание C# с каждой спецификацией, т.к. фундаментально в нем уже ничего не изменить.
Конечно будут появляться новые языки от различных фирм, но я считаю, если язык не создан долларовым гигантом, то такой язык обречен изначально.
Поэтому я жду и надеюсь, что выйдет нечто эдакое революционное.
Вот только создать C# на истеричной ноте отвращения к C++
C# создавали на истеричной ноте того что писать на C# дешевле выходит для бизнеса. Меньше рисков, скорость разработки выше, стоимость поддержки меньше. Бизнес счастлив. А то что C# аж в 2 раза медленее C++ — это мелочи которые не сильно интересуют бизнес. Сервера стоят дешевле.
Ну и да, C# очень лаконичный язык. Его минус — привязка к конкретной платформе (mono не считаем) но это скоро думаю изменится.
Поэтому я жду и надеюсь, что выйдет нечто эдакое революционное.
Rust смотрели? Очень приятный язык который по скорости равен Си (то есть быстрее плюсов). Вот только в статье говорится что будущее за языками с динамической типизацией, аля ruby, python и т.д.
Тогда «изобретаторы» смогут более чаще изобретать новые языки, и тестировать их в условиях широкомасштабного применения, итоговой целью которого будет создание <последнего языка программирования> для процессоров с бинарной логикой.
C# очень лаконичный язык. Его минус — привязка к конкретной платформе (mono не считаем) но это скоро думаю изменится.
Вот любопытно, что заставляет вас считать, что скоро всё изменится и какова ваша оценка этому "скоро"? А то ведь этому "скоро" уже два года (как код открыли). Хоть куда-то оно сдвинулось?
Хоть куда-то оно сдвинулось?
ну относительно недавно мелкософт купил ксамарин, и вместе с ним получил mono и теперь спонсирует его разработку. Словом ресурсы в это дело они вбухивают.
Просто для меня довольно очевидно, что им не выгодно делать, чтобы что-то работало на линуксе и других платформах. Поэтому они покупают, да (чтобы потом убить).
Что касается .Net core, то вполне себе норм разрабатывается. Единственное что после перехода на RC2 слетела подсветка студии для кастомных депенденси, но это скоро должны починить.
На линуксе все работает точно также, как не на линуксе :) По крайней мере за ASP.Net Core говорю. То есть достаточно сложный веб-сервер живет и здравствует, причем работает быстрее чем на иисе.
Что в плюсах медленно?
Все то что делает плюсы плюсами а не надстройкой над Си. Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Но в целом согласен, толстова-то вышло. Rust быстрее плюсов на очень небольшом классе задач, и причем по памяти кушает больше.
Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Там где в плюсах будут нужны виртуальные вызовы в расте будут "трейт-объекты" которые устроены примерно так же.
Про память тоже интересно. Это результат тестов каких-то? Что в расте принципиально больше памяти требует?
Ссылки на трейт действительно требуют больше памяти — указатель на vtbl хранится в каждой копии ссылки, а не в самом объекте, как в плюсах.
Но шаблоны C++ способны порождать более эффективный код, чем человек напишет руками на C. За счет специализации на этапе компиляции.
Или таки о лакончности кода на LINQ? ;)
… (мечтательно) А если добавить еще пару десятков ключевых слов и несколько «служебных под-языков», то станет еще лаконичнее!…
…Но факт остается фактом: чтобы добавить поддержку новой возможности/удобства, в язык приходится добавлять новые конструкции. Чтобы добавить сопрограммы — введем новое ключевое слов. Чтобы было удобнее обрабатывать «внешние» данные — добавим еще несколько… да что там мелочиться?! добавим сразу язык… Ну и т.д.: с каждой новой версией язык все пухнет и пухнет. Количество концепций в языке все больше и больше. Сложность все растет и растет… А это сложность, с которой разработчику приходится иметь дело буквально каждую секунду.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Между тем, еще в 60 – 70-е годы показали (Lisp, Simula-67, Smalltalk…), что это можно и нужно делать не в языке (что приводит к взрывному росту сложности), а в «библиотеках» (что позволяет усложнять только там, где нужно, и равно на столько, насколько нужно). Собственно, расширение возможностей системы разработки без усложнения языка и отличает хороший язык от плохого. Прошло 50, даже 60+ (или уже 70?) лет, а мы снова там, где были. Об этом же, как мне видится, и пытается сказать Кэй.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Брейнфак не меняется с момента создания, наверное это говорит о целостности его идей и его выразительной мощи?:)
Не все изменения языка мне нравятся (например оператор is, с out-параметров выглядит очень не очень), но никто не заставляет использовать ВСЕ возможности. Причем разные возможности рассчитаны на разный стиль программирования, и разный уровень абстракции разработчика. Например pattern match рассчитан на высокоуровневые разработки, активно использующие LINQ и т.п., где лаконичность важнее производительности (каждый раз вызывать делегат вместо простого куска кода это всегда оверхед). А например ref-возвращаемые значения они для низкоуровневых операций, когда нам копирование ссылки капец как портит производительность. Ну и какие-то записи просто упрощают, вроде readonly-свойств или лямбдосвойств. В целом эволюция идет в правильном направлении. Усложняется язык — что поделать, нельзя добавить функцинальность, не добавив её. Главное чтобы она была ортогональна.
Ровно до момента, когда принесут на саппорт крупный проект на «полноценном» языке.
На Javascript и РНР тоже
На них просто реализовано много больших проектов, но это не значит что они надежны. А вот Erlang в этом плане оч крутой.
Маленькое уточнение — Erlang язык с сильной динамической системой типов, что уже делает его чуть лучше других (PHP или JS например). То есть никакого жанглирования типами как в PHP. Это только если говорить о системе типов. А так erlang предоставляет много крутых вещей которые повышают надежность систем. Собственно этот язык для надежных систем и предназначался изначально.
Языки дают нам ключевые слова, библиотеки — дополнительные типы данных и функции, из них мы делаем прикладные абстракции. Если все средства узкоспециализированы (или привязаны к архитектуре), в языке появляется «ползучий фичеризм», а кодинг становится многословным. Но если ключевых слов мало, то абстракция становится сложной, её сложно держать в голове, а особенно представлять её динамику и наследования. А в Lisp я это делать обязан Хотя, может, я не умею правильно его готовить.
Не приходила ли мысль о том, что таки язык должен быть как можно проще (соответственно, минимум «ключевых слов») и естественнее (соответственно, ближе к человеку), но позволять расширять сам себя новыми «абстракциями», удобными в использовании. То есть, эти абстракции должны лежать в рамках всего одной концепции, вокруг которой построен язык. Кстати, это как раз описывает (цели) Lisp и Smalltalk. …Другой вопрос, насколько они к этим целям приблизились. Lisp сложно назвать изначально естественным для человека; Smalltalk-таки пожертвовал чистотой в угоду прагматичности… впрочем, современным языкам и до этого далеко.
… И да — никаких DSL здесь не потребуется: все будет в рамках исходного языка.
Код должен быть одновременно близок человеку (чтобы легко читаться и писаться) и машине (чтобы быстро работать). Языковые конструкции не должны сбивать с мысли, когда пытаешься наложить свою модель процесса на средства языка. Для себя я пишу на матлабе (прототипирование или программы на пару запусков) и на С, когда надо пережёвывать много данных. Сравнивая длину кода, служащего одной и той же задаче, матлаб выигрывает в разы: например, я могу к числу относиться как к числу, к матрице — как к матрице, а в сях я должен явно указать, что это за число, и относиться к нему как к ячейке по адресу в памяти. Зато матлаб медленный.
А совсем «правильных» языков, основанных на сообщениях, можно считать что и нет. Ну разве что Erlang, но его недостаточно что бы говорить о невозможности ни чего другого.
Я поясню, почему у меня вызывает отторжение сочетание «праильного ООП» и статической типизации. Идея ООП состоит в том, чтобы быть как можно проще. Объекты и сообщения — и больше ничего. Статическая типизация сюда явно не вписывается. Динамическая — чуть лучше, в плане того, что это личное дело каждого объекта.
Это, разумеется, не значит, что типизация — это плохо. И у статической есть свои преимущества. Но она не должна быть реализована в языке. Вытащите это (как и многое другое, впрочем) в «библиотеку» и будет (почти) всем (почти) счастье :) Для того же Smalltalk-а это было (даже неоднократно) показано.
Эти ограничения как минимум, заменяют часть тестов. То есть усложняют язык не более, чем использование тестового фреймвока.
То есть тип переменной — это более простой способ написать assert, проверяющий ее принадлежность к этому типу и срабатывающий заранее.
Справедливости ради, 100% покрытие кода тестами не гарантирует отлов 100% ошибок. Есть проекты на динамических языках программирования (к примеру команда Doctrine) в которых разработчики делились информацией, что в проекте с 100% покрытием кода тестами и проведением мутационного тестирования добавление информации о типах позволило выявить новые проблемы.
Но это мы говорим о языке со слабой динамической типизацией. Чуваки из Python или Ruby сообщества больше переживают из-за оверюза (именно оверюза) возможностей манкипатчинга нежели системы типов их языка.
Это было на реддите где-то с пару месяцев назад. Я сейчас затрудняюсь найти дискуссию… Можно вот у этого человека спросить: https://github.com/Ocramius
Типы обязательны — лишние действия при объявлении переменных/методов. Писать код сложнее.
Чтобы код запустить на выполнение нужно обеспечить совместимость типов, даже если мне в данный момент это не нужно. Исследовать/разрабатывать сложнее.
…
ограниченное количество ключевых слов — лишняя сущность.
Похоже вы гений, который всегда с 1 раза пишет правильно все модули системы и никогда не пользуется кнопочкой debug.
Ключевые слова… не знаю, можно ли обойтись без них, но ясно, что их должно быть как можно меньше. В том же Smalltalk-е их всего ничего: self, super, nil, true, false, thisContext. Да и они, в общем-то необязательны — так, сахарок. Есть правда еще куча другого синтаксиса… Впрочем, «куча» — очень относительно. По сравнению с C# его почти и нет :) Но все равно — слишком много, язык далек от совершенства… Не буду развивать мысль, рановато пока.
P.S.: Предлагаю не переходить на личности. Вы меня совершенно не знаете. И то, что вы, судя по вашим комментариям, пока не понимаете то, что я стараюсь сказать, не дает повода пытаться меня задеть ;)
Лично я, как и мои коллеги на работе, умудряются в статически типизируемых языках находить ошибки, а вы в динамике умудряетесь такие подвиги совершать. По мне так это достойно всяческой похвалы. В жизни я таких людей не встречал, так что это очень большая редкость и радость видеть Вас наяву.
1. Статическая типизация нужна для оптимизации
// по производительности кода
// по проверке его правильности
// (еще почему-то не упоминали, вроде) по проведению рефакторинга…
2. «Преждевременная оптимизация — корень всех зол» (Д. Кнут или кто-то еще)
Интернет никогда не отключался? Да ладно!
Он просто состоит из множества реально независимых частей, которые сами по себе отключатся регулярно, просто они друг другу не нужны. В том числе — отключаются по вполне себе внутренним причинам.
Весь интернет никогда не отключался. Отключались датацентры. Но если повредился один из маршрутов система адаптируется.
Видите ли, в же стиле можно сфорулировать любую чушь.
Интернет — в том смысле, который ему придает сам автор цитаты, т.е. софт TCP/IP, еще как отключается. Позвольте мне не давать вам ссылки на множественные уязвимости серверов любого рода, которые позволяют их легко уронить? Да, система адаптируется, и сильно. Но тем не менее любой из нужных именно вам ресурсов в любой момент может быть недоступен. А то что мы видим — лишь результат дублирования.
Если угодно — общая конструкция интернета, как фиговины состоящей из большого числа независимых частей — она да, устойчивая. Но протоколы, которые в нее входят, и отдельные узлы — совсем нет.
Речь, как мне видится, идет о построении сложных систем. Код на языке — это лишь способ связать компоненты этой системы между собой, дать им возможность общаться. В этом смысле протокол — как раз способ общения, то есть полный аналог языка. В случае с инетом удалось каким-то волшебным способом построить сверх-сложную систему, сделать ее саморегулируемой… и при этом относительно простыми средствами.
Не удивительно, что многие питонисты занимаются данными, а многие специалисты по данным используют питон. Это не говорит о том, что питон как-то особенно хорош в этой области.
Что он должен доказывать? Что бросаем всё и бежим учить Лисп? Писать биллинг на Смоллтоке? Закладывать таймбомбы поздним связыванием?
Вы пропускаете ключевые слова, смысл которых очень важен: мэйнстрим, предсказуемость, сопровождаемость, надёжность. И всё это вообще не про Питон! Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости. Поэтому когда «отцы ИТ» (а по-хорошему, сильно постаревшие мальчишки-хакеры из 50-ых) начинают развозить в воздухе «вы должны...», становится смешно. Особенно про ЛИСП.
Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости
Хорошо, давайте так. Есть две функции:
int calculate(int value1, float value2)
{
// ...
return result;
}
def calculate(value1: int, value2: float) -> int:
# ...
return result
Где тут непредсказуемость, касаемо функции на Python? Мы написали аннотации для параметров. Мы знаем, с какими типами эта функция работает. Боле того, если вы параноик или перфекционист, можете воспользоваться советом Google Python Code Style и включить проверки входных аргументов в каждой функции и возвращаемых в вызывающей функции. А также использовать mypy.
Касаемо предсказуемости вашего "мэйнстрима", C/C++ хоть и статически типизированные языки, но из система типов слабая. Сколько граблей уже собрано из-за неявного приведения типов, даже ракеты падали. Тут на хабре ребята из PVS-Studio уже давно показывают, что бывает, если не использовать статический анализатор кода для C/C++.
Вот жесть. Вы, пардон, по какому принципу составили этот список?
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ. Так вот: на _сегодня_ Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны. Никому не нужны макросы или «живой бардак» типа Смоллтока — нужны простые, надёжные решения — это моя ежедневная работа. И уверяю, без ЛИСПа можно вполне хорошо писать системы — есть хорошие языки типа C#, D, Java, код которых можно СОПРОВОЖДАТЬ. В случае ЛИСП — увы, это write-only язык и его незнание ну вообще никак не влияет на ваш профессионализм.
где «серьёзные дяди» платят большие деньги и хотят предсказуемый результат.
А получают гору легаси на Java. Ну ок.
И извините, я никогда не выйду к ним с языками типа Пестона, Сипипи или Раста.
Скажите, почему Rust это плохой язык а D хороший? Мне нравится и Rust и D, но как я вижу поддерживать решения на Rust сегодня проще и дешевле чем на D. Вопрос размера комьюнити и вложений от крупных компаний.
Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны.
бизнесу эти вещи знать не надо. им важен результат. То о чем вещает Алан показывает высокий результат. Культура разработки, профессианализм, это все намного важнее "языка". А сейчас очень много разработчиков которые не доконца понимают что они делают. И это не зависит от языка разработки (хотя кое какие корреляции существуют).
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ
Dlang — хобби. Java — начинался как хобби. javascript — начинался как хобби, php — начинался как хобби, python — начинался как хобби. ruby — начинался как хобби. Мне продолжать? Конечно же я утрирую говоря о хобби. Этим я хочу подчеркнуть субъективную точку зрения создателей этих языков. Например C# можно воспринимать как чисто коммерческий язык, который был под чистую слизан с Java но с небольшой работой над ошибками. При создании оного мотивировались исключительно потребностями бизнеса, причем самой компании Microsoft. И при этом у них неплохо вышло.
код которых можно СОПРОВОЖДАТЬ
А теперь вспомните, сколько было написано легаси когда на этих языках который сопровождать проблематично? Я думаю существенно больше чем кода, удобного в поддержке.
Сейчас есть «мэйнстрим» и «хобби» и Алан так и остался в мире «хобби»
Сейчас есть армия клепателей контроллеров. Для 80% проектов это может быть ок, а для остальных 20% это приводит к высокому уровню тех долга и большим расходам на суппорт приложений. Алан входит в категорию тех, для которых программирование является профессией, а не хобби. Я думаю вы должны понимать разницу. Как раз таки "мэйнстрим" чуваки обычно действуют более стихийно, как буд-то бы это хобби.
Динамические языки тоже показали свою несостоятельность — взлетели на волне хтмл-страничек и домашних перделок
http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html
P.S. «So says this old C++ programmer.» Вот что меня убивает, что сравнивают как всегда с С++ и его потомками. Ну покажите деду хоть Аду что-ли или Модулу-3. Хотя там в середине есть пассаж «Pascal, I felt, was a language for babies.» после которого писанину этого «взрослого» вообще можно не читать…
Но я уверен, что беда придёт откуда не ждали. Функциональное программирование медленно, но верно просачивается всюду, пускает свои ростки. Вы смотрите, уже и в джаве наступает время конкурентности, а не параллельности. И лямбды, мапы, фильтры и, страшно подумать… свёртки списков!
Сейчас оно проникнет в мейнстрим и люди начнут массово мыслить «функционально».
И тут всплывёт вопрос типизации. Вот вы говорите, что язык должен быть статически типизирован. Что если я скажу вам, что с моей точки зрения типизация джавы — какое-то ребячество, позволяющее только отличить строку от числа?
Полиморфная типизация уступает зависимой в бесконечность раз. Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются и пока выглядят очень плохо и хило. Но есть ребята, которые двигают HoTT и в процессе формализации HoTT в HoTT получат нечто божественное.
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации, и как бонус — в нём нет ни одной излишней динамической проверки и он работает быстрее любого си-кода, который написан человеком.
И тогда будет лишь два вида разработки — «серьёзная», где требуется надёжность. И «несерьёзная» — где можно тяп-ляп и на динамическом ЯП быстро заставить машину сделать чего нужно.
Языки «среднего класса» умрут.
Дело не только в интыпрайзе, но в самой сути людей: ОЧЕНЬ сложно просто взять ЛИСПовский код и за минуту объяснить, что он делает. Люди ограничены, даже если имеют за плечами десятки языков (я лично писал на более, чем 20-ти). Поэтому я уверен, «простота и мощь» была и будет главным девизом ИТ, а его применимость к интыпрайзу — лишь приятный бонус.
ФП? Не смешите мой дисковод! За те годы, что о нём знают, он давно вылез бы в топы, если бы не был таким кривомысленным, ортогональным нормальному человеческому мышлению. То, что какой-нть C# позаимствовал лямбды, НИЧЕГО не говорит в пользу ФП. Посмотрите на это так: была функция сортировки с захардкоженным сравнением a < b. Функцию расширили (каким угодно механизмом) и теперь сравнивать можно любым переданным методом — ПРИЧЁМ ТУТ ФП ВООБЩЕ? Это просто кастомизация функции сравнения, она вообще могла быть передана как в Ди — СТРОКОЙ. Это говорит о том, что ваше видение ФП идолизировано до того, что вы не отличаете парадигму от заимствований отдельных плюшек и где слышите «функция», сразу думаете о ФП. Функции были всегда, даже в ассемблере, но никто и никогда не выпячивал их как достоинство ФП парадигмы.
> Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются… А затем окажется… И тогда будет…
Не многовато будущих времён? :) (см. первое предложение) Даже в обозримом будущем (лет так на 20) вполне видно, что ФП — не у дел, Лигическое п-е — на задворках кафедр, ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным — потому что это близко человеку — разбирать на составляющие и собирать вновь. Из ближайших перспектив — метапрограммирование, но не в диком смысле ЛИСПа, а в стиле Немерле. Это лучшее, что может произойти с программингом в ближайшие годы.
> Языки «среднего класса» умрут.
:) Спасибо, этим вечером сильно нехватало улыбки! Вы лучший.
Ну вот тем и отличаются люди-практики от Аланокеев
По картинке: Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
Давайте взгянем на web приложение на lisp. Что-нибудь простенькое, минималистичный клон твиттера: http://eudoxia.me/lucerne/docs/example--a-twitter-clone.html
Вы хотите сказать что код не читаем? Или что его дорого поддерживать потому что язык плохой? Давайте уж на чистоту, CommonLisp в web разработке не применяется потому что есть другие более популярные языки, с большим количеством разработчиков и большим количеством готовых решений. Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны, поскольку это сокращает расходы на разработку, я думаю вы не будете спорить в этом.
Но говорить что сам по себе Lisp разработан теоретиками и никто его не юзает потому что он именно такой — это лишь говорит о том что вы понятия не имеете что такое Lisp.
Идем дальше.
ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным
вот мне нравится у людей периодически спрашивать как отличить ОО код от не ОО кода. К примеру, я, как похапэшник, имею дело с такой ORM как Doctrine, которая предоставляет возможность делать сущности как обычный объекты, и мэпит их на базу. Подавляющее большинство делает эти объекты как анемичную модель, то есть куча пропертей, геттеры и сеттеры. Я думаю вы видели подобные вещи.
И в итоге мы имеем: объект хранящий состояние, и объект сервисного слоя, который это состояние меняет. Состояние отдельно, поведение которое меняет состояние — отдельно. Вроде бы у нас и объекты есть, и наследование с полиморфизмом имеются, но отсутствует инкапсуляция и мы имеем дело лишь с состоянием (один объект) и процедурами (методы другого stateless объекта).
То есть если мы вдруг захотим добавить в сущности новое поле с датой изменения, или механизм ревизий изменений, то мы не сможем это сделать красиво и быстро прямо в сущности, так как логика изменения состояния вынесена в другой объект. У нас нарушена инкапсуляция. И по итогу вместо красивого и понятного ООП с инкапсуляцией, возможностью делать декомпозицию системы, изолировать состояние и побочные эффекты, мы имеем старый добрый процедурный код с классами.
Ох, а еще веселье когда народ начинает просто так использовать сингелтоны как глобальное состояние. Встречался мне проектик под iOS, где ребята вынесли состояние в сингелтон с сотней пропертей, и мутировали его в куче разных методов разных объектов разбросанных по всей системе.
Или когда народу дико хочется заиметь множественное наследование (которое к чертям ломает полиморфизм в большинстве юзкейсов ради которого его хотят ввести), просто что бы было удобнее комбинировать процедурки по классам.
ОН УЖАСЕН. Вместо красивых, чистых конструкций — лапша из скобок, выворачивающая наизнанку мышление. Каждая строчка заставляет прищуриваться на минуту, чтобы отыскать что и зачем делается. Это не код, это «машинопись» — коды, хорошо понятные компу, но выбешивающие людей.
> Или что его дорого поддерживать потому что язык плохой?
Тут главное — правильно определить слово «плохой». Он плохой в смысле поддерживаемости, понимаемости, реюзабельности. Но он «хороший» в плане динамики — можно хоть чёрта лысого сгенерить и это будет работающая программа! Только оно надо?
> CommonLisp в web разработке не применяется потому что…
… потому что это самый отвратительный язык для мэйнстрима — см. «поддерживаемость».
> Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны
Тогда с чем вы спорите? Я и смотрю именно на бизнес! Какой смысл разбирать «хобби»? Для себя можно и на Рефале гонять, тут вообще никакие критерии неприменимы! Вот поэтому вы говорите глупость, когда приравниваете Алана к «профи» (в совр. смысле). Да, чувак занимался наукой, что-то наизобретал, но сегодня «Лисп» и «профи» — несовместимые вещи. Языки, созданные в научном угаре, больше не являются «жемчужинами ИТ» — они «забавная пыль истории».
Я даже сам к какой-то игрухе писал на Лиспе обработчики и это занятие заслуживает единственное слово — «прикольно!». Только вот оно нифига не прикольно, когда надо писать надёжный код и «уже вчера». Так что я согласен с вами — Лисп занятный язык, он ЛУЧШЕ большинства языков по своим возможностям, но именно эти возможности и есть «игра с порохом» — ну его нафик!
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации
А как быть с побочными эффектами? Извините за глупые вопросы.
Доказывать то, что некие данные появились из I/O, а не от балды легко — ввести типов вроде IsStringFromStdin, значения которых будут возвращаться только из встроенных функций для работы с I/O. С гарантиями записи так же.
В итоге программа будет являться отображением Вселенной во Вселенную, плюс кучей типов вроде ВЭтойВселеннойБылОткрытПорт(80) и ДляПотокаБайтБылИспользованПарсер(html), ЕслиОткрывалиФайлПоЗапросуАЕгоНетВернулиHTTP404 и так далее (хотя я на самом деле этого не представляю, никто в жизни не сможет формально описать программу целиком, только её основные части).
Входящие данные обрабатываются так же как и обычно. Просто функция сравнения, например, возвращает не Boolean, а тип-сумму из доказательства или опровержения равенства. А дальше обычный switch и две ветки исполнения.
Алан Кэй, создатель ООП, про разработку, Лисп и ООП