Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года:
The best way to predict the future is to invent it.
Лучший способ предсказать будущее это изобрести его.
У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой объектно-ориентированного программирования. Он был одним из первопроходцев в области персональных компьютеров и графического интерфейса, он разработал Smalltalk — один из первых самых влиятельных языков программирования всех времен.
У нас в Хекслете, особенно в чате, постоянно поднимается вопрос «что такое ООП» и «что имел ввиду Алан Кэй на самом деле». В этой заметке собраны интересные цитаты Алана о состоянии современной разработки, ООП и языке Лисп.
Про разработку ПО
Алан Кэй считает, что компьютерная революция еще впереди (The Real Computer Revolution Hasn’t Happened Yet), и разработка ПО развивается обратно пропорционально Закону Мура: железо улучшается каждый год, а софт становится раздутее без надобности:
проблема в слабых, плохо масштабируемых идеях и инструментах, лени, нехватке знаний и т.д.
Эту ситуацию хорошо описывает короткая шутка:
What Andy giveth, Bill taketh away
Энди дал, Билл взял
Энди Грув, CEO Интела, и Билл Гейтс, тогдашний CEO Майкрософта.
Улучшение текущего состояние разработки было целью исследовательского проекта STEPS Toward The Reinvention of Programming (pdf). Задача — достигнуть «Закона Мура» в выразительности через «сокращение количества необходимого кода в 100, 1000, 10000 раз и больше».
В его открывающем глаза докладе Programming and Scaling (видео) эта тема рассматриватеся подробнее. По мнению Алана, software engineering заглох и становится забытой наукой, которая не успевает за железом, другими науками и инженерными дисциплинами. Большие проекты стали свалками кода и достигли такой точки, когда никто не способен понять 100 миллионов строк кода MS Vista или MS Word. А в реальности кода в таких проектах должно быть на порядок меньше.
Алан считает Интернет, протоколы TCP/IP, интерпретаторы LISP, Nile (Math DSL for Vector Graphics) и OMeta (OO PEG) (PDF) примерами элегантного софта с минимальным кодом.
Он называет Интернет (TCP/IP) одним из немногих масштабных софтверных проектов, который был правильно разработан, и его уровень сложности — в балансе с уровнем комплексности (complication vs. complexity). Этот проект, в котором меньше 20 тысяч строк кода, работает как живая, динамическая система, способная поддерживать миллиарды узлов, и она ни разу не отключалась после первого запуска в сентябре 1969 года. Мы просто перестали считать Интернет нормальным софт-проектом, созданным людьми:
Интернет разработан настолько хорошо, что многие относятся к нему как к естественному ресурсу, вроде Тихого океана, а не к плоду человеческого труда. Когда в последний раз мы видели настолько стабильную, четкую технологию без ошибок? Для сравнения, Веб это ерунда. Веб создан дилетантами.
Про объектно-ориентированное программирование
Первое, что меня интересовало, это его первоначальное видение ООП. Его опыт в микробиологии сыграл важную роль:
Я считал объекты чем-то вроде биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.
и опыт в математике:
Мой опыт в математике заставил меня понять, что каждый объект может иметь несколько алгебр, они могут объединяться в семейства, и это может быть очень полезным.
Идеи позднего свзяывания и мощных мета-возможностей LISPa:
Вторая фаза — это понимание LISPa и использование этого понимания для создания более удобных, маленьких и мощных структур и более позднее связывание.
И вскоре Алан стал поддерживать идею того, что динамические языки это будущее разработки ПО (pdf). В частности, ему важна легкость изменения:
Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)
И потенциал для изменений на ходу и более быстрых итераций:
Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды.
который отсутствует в статически-типизированных языках:
Если вы используете языки с ранним связыванием, как это делает большинство, то вы запираете себя в рамки того, что уже написали. Переформулировать с легкостью уже не получится.
Удивительно, но его мысл про ООП ограничивались этим:
ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.
И ничего про наследование. Это не тот ООП, который мы знаем сегодня:
Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей.
Большая идея, которой не хватает современным статически-типизированным ОО-языкам:
Большая идея это «сообщения»
Он считает, что нужно фокусироваться на сообщениях, слабой связи и взаимодействии модулей, а не на внутренностях объекта:
Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.
Статически-типизированные языки кажутся ему неполноценными:
Я не против типов, но мне не знакома ни одна система типов, которая не вызывала бы боли. Так что мне все еще нравится динамическая типизация.
Некоторые популярные языки сегодня используют идеи передачи сообщений Smalltalk'а, позднее связывание, и конструкцию doesNotUnderstand: forwardInvocation в Objective-C, method_missing в Ruby и noSuchMethod в Гугловском Dart.
Уничтожить все и создать что-то лучше
У Алана есть интересная теория о развитии информатики:
Мне кажется, что существует только один тип компьютерной науки, и это наука похожа на строительство мостов. Кто-то строит мосты, а кто-то разрушает их и создает новые теории. И нам нужно продолжать строить мосты.
Про LISP
Алан Кэй считает Лисп
лучшим языком программирования всех времен
И что его должен изучать каждый выпускник в computer science:
Большинство людей, получающих дипломы в CS, не понимают всей важности Lisp. Lisp это самая важная идея в computer science.
Про правильную атмосферу и контекст
Он часто вспоминает об уникальной атмосфере в Xerox PARC и ARPA, где «видение важнее целей» и «финансирование людей, а не проектов».
Точка зрения дает 80 баллов IQ.
Алан Кэй считает:
История ARPA/PARC демонстрирует, как комбинация видения, скромного финансирования, правильного контекста и процесса может волшебным образом рождать новые технологии, которые не только влияют на цивилизацию, но и создают огромную ценность для общества.
И это правда. Взгляните на впечатляющий список изобретений PARC, многие из которых сыграли очень важную роль в развитии нашего мира. Например:
- Лазерные принтеры
- Объектно-ориентированное программирование / Smalltalk
- Персональные компьютеры
- Ethernet / распределенные вычисления
- GUI / компьютерная мышь / WYSIWYG
А в ARPA создали ARPANET, который стал прародителем Интернета.
P.S. Алан Кэй отвечает на вопросы сообщества Hacker News.
Комментарии (135)
potan
21.06.2016 15:29+2Интересно, что он говорит про Erlang.
toxicmt
21.06.2016 15:31+9kartD 18 hours ago
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 говорил прямо вчера
sheknitrtch
21.06.2016 15:36+3Улётный мужик этот Алан Кэй. Жаль Smalltalk не стал таким популярным как Python, Ruby или PHP.
potan
21.06.2016 17:42Я думаю, что основная причина — слишком тесная интеграция с UI. Не было окружения, в которой было бы удобно разрабатывать серверные приложения и программы, ориентированные на CLI.
Fesor
21.06.2016 19:32What Killed Smalltalk Could Kill Ruby — RailsConf 09: Robert Martin
kemiisto
21.06.2016 23:04+3Ох, опять этот Мартин. :D Но тем не менее, отдаю должное мужику: пускай и с кучей лирических отступлений, но суть он уловил и передал хорошо. «It is just too easy to make a mess.» © Касается, в принципе любого языка с динамической типизацией. 100-200 строчек — полёт нормальный, как начинаются серьёзные объёмы кода, так начинаются неприятности. В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля. Ну а самое парадоксальное, что это ещё и преподносится как преимущество. Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…
P.S. Меня одного раздражает его манера публичных выступлений?Fesor
21.06.2016 23:48-1В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто
Ну справедливости ради это относится ко всем языкам вообще. Неужели все огромные проекты на Java прям таки мега гибкие? Что-то сильно сомневаюсь, количества легаси на джаве думаю побольше чем в том же PHP.
Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…
Как говорится, хватит писать легаси код! Почему-то люди предпочитают революционный подход более естественному эволюционному.
P.S. Меня одного раздражает его манера публичных выступлений?
Как он выступает на конференциях меня особо не раздражает. Наверное это потому что я когда-то посмотрел его курс лекций по чистому коду где он раз в минуту сменял образ и костюм… вот там бесило дико.
iroln
22.06.2016 09:04В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля.
Разве в плохо написанном большом проекте, например, на C++, легко и просто поменять или добавить что-то? Если вы пишете проект без оглядки на какую-либо архитектуру и проектирование, не делая рефакторинг, без тестов, без соглашений, то в конце-концов независимо от языка ваш проект превратится в свалку спагетти-говнокода и костылей, который невозможно будет развивать и расширять без боли. Хороший пример — проект notepad++ (статья про это)potan
22.06.2016 11:30C++ — случай особый. В нем слишком велика разница между хорошим кодом и плохим, и плохой код писать гораздо легче.
Как ни странно, большой проект на чистом C обычно поддерживать проще, чем на плюсах.
chaetal
22.06.2016 10:55Меня тоже раздражает манера. Но больше — содержание. Этот тезис про «динамическую типизацию» (уж простите мне категоричность, но, думаю, я могу себе ее в данном случае позволить, долго уже занимаюсь этими вопросами) — полная чушь. И уж точно не это «убило» Smalltalk… Не говоря уже о том, что ничто его и не убивало: он вполне себе живет в разных формах и, уверен, еще проявит себя в одной из них (пусть и пока еще не существующей).
Fesor
22.06.2016 18:06-1Этот тезис про «динамическую типизацию» (уж простите мне категоричность, но, думаю, я могу себе ее в данном случае позволить, долго уже занимаюсь этими вопросами) — полная чушь
Он где-то говорил что всему виной динамическая типизация? Я как-то этого не услышал. Ну и для справки — боб часто упоминает что сильная динамическая типизация + тесты намного эффективнее статической типизации без тестов).chaetal
22.06.2016 20:50… А я не с ним спорил (прошу прощения за неудачную разбивку по абзацам) — пока и не дорос спорить с дядюшкой Бобом… Тем более заочно :) Тем более по теме «Что убило Smalltalk…» — будучи уверенным, как я уже писал, что пациент скорее жив. Его доклад слушал давно, конкретных деталей, которые меня отвратили от данного оратора (кроме манеры подачи информации), уже не помню. Большого желания тратить время на пересматривание пока нет :)
potan
22.06.2016 11:27Статическая типизация, конечно, в большинстве случаев полезна (особенно такая, как в Haskell). Но все-таки бывают динамические языки, на которых приятно поддерживать большие проекты. Так на Erlang разрабатываются огромные телекоммуникационные системы. Я сам участвовал в довольно крупном проекте на языке Schema — динамическая типизация создавала не так уж много проблем.
chaetal
22.06.2016 11:53Наверняка это не всегда так, но по личному опыту: споры о вкусе устриц и кокосовых орехов обычно затевают не те, кто их ел :)
Рассуждения о том, что динамическая типизация на «больших» проектах приводит к бОльшему количеству ошибок или к сложностям с поддержкой проектов на таких языках, скорее выдают человека, который устриц-то не пробовал. А если пробовал, то давайте ближе к фактам: на каком проекте, какой язык, какие сложности…potan
22.06.2016 11:58На своем опыте — на Perl и js у меня довольно много ошибок приходилось вылавливать runtime, хотя проекты были и не большие.
Да и на Scheme вывали случаи, когда я путал строки и числа и компилятор это пропускал. Правда, обычно это было связано с чтением внешних данных.chaetal
22.06.2016 13:17Даже не знаю, что и сказать… Попробуем так. Вы какой тезис обосновываете? Что в динамически-типизируемом языке система позволит передать строку туда, куда по замыслу программиста нужно передать число? Спасибо, КО! :)
Вопрос-то не в этом. В «большом», серьезном проекте (кстати, независимо от типизации… даже если это великий Haskell, наверное — поправьте, если не так) будут предприняты меры по контролю «правильности» кода (те же тесты как минимум), и исходное утверждение нужно читать в одном из двух возможных вариантов:
- проектом на динамически-типизированном языке невозможно управлять так же хорошо, как аналогичным на статически-типизированном
- управлять можно примерно так же, но сделать это сложнее
Какой из этих тезисов вы хотите обосновать своим опытом?destroy
22.06.2016 14:10+2Зачем писать тесты на то, что может предотвратить статическая типизация?
Fesor
22.06.2016 18:08+1Затем что статическая типизация предотвращает лишь малую долю проблем связанных с рефакторингом и разработкой.
solver
23.06.2016 17:03+2Так динамическая-то вообще ничего не предотвращает. Какой профит?
Fesor
23.06.2016 20:26-1сильная динамическая отлавливает ошибки с типами в рантайме. С другой стороны динамическая типизация минимально но ускоряет разработку простых систем.
Посмотрите на python. Там есть тайпхинтинг, при помощи которого можно организовать статический анализ (у нас есть вся необходимая информация о типах), с другой стороны тайпхинтинг вообще не влияет на рантайм и мы все еще имеем дело с динамической типизацией.
potan
23.06.2016 19:41+1Когда я программировал на Haskell, бОльшая часть компилируемого кода работала правильно без всякой отладки. Процентов 80-90 по ощущениям, хотя статистику я не собирал.
Слышал аналогичные отзывы про Rust.Fesor
23.06.2016 20:29-1бОльшая часть компилируемого кода работала правильно без всякой отладки
когда я писал на PHP бОльшая часть интерпритируемого кода работала правильно без всякой отладки. Процентов 80-90 по ощущениям, хотя статистику я не собирал.
Слышал аналоничные отзывы про Python.
chaetal
22.06.2016 13:32Кстати, мне казалось, мы говорим об одном и том же… По крайней мере я пытался поддержать тезис «существуют динамически-типизированные языке, на которых поддерживать большие проекты приятно». На всякий случай очевидное: наличие обратных примеров не опровергает этот тезис.
potan
22.06.2016 14:28+1Да, я согласен. Мой опыт большого проекта на Scheme это подтверждает.
Но и там изредка возникали проблемы, от которых статическая типизация бы избавила.
kemiisto
21.06.2016 23:29+1Слишком тесной интеграцией с GUI можно объяснить почему Smalltalk «не взлетел» как скриптовый язык, но ни почему он «упал» как язык для разработки этих самых GUI-приложений. А потом, если вести отсчёт с начала 2000-х, то GNU Smalltalk, который вполне себе отвязанный от GUI и скриптовый, тогда уже вполне живой был, но в итоге как скриптовый язык в 2000-х «взлетел» Python, а не Smalltalk. Или возьмите те же веб-фреймворки: Seaside появился на пару-тройку лет раньше Rails и Django, но как-то не очень это помогло. Там то слишком тесная интеграция с GUI уж точно проблемой не была.
chaetal
22.06.2016 10:58+1В истории Smalltalk-а еще много удивительных «почему»… Постепенно сложилось впечатление, что этот «невзлет» объясняется очень просто: слишком рано.
kemiisto
22.06.2016 12:06Согласен. В общем и целом, если обобщить, то можно про любой «невзлетевший» язык сказать: «невовремя». Либо слишком поздно, когда ниша уже занята, либо слишком рано, когда ниши ещё и нет совсем.
chaetal
22.06.2016 13:18+1Я сказал не «не вовремя», а «рано». И дело совсем не в нишах — это все мелочи.
potan
22.06.2016 11:21Потому что рынок GUI-приложений не такой большой, как кажется. А нишевые языки со временем вытесняются более популярными даже из своих ниш.
iroln
21.06.2016 20:27+1Жаль Smalltalk не стал таким популярным как Python, Ruby или PHP.
Вы перечислили языки, в которых нарушается принцип «Всё доступно для изменения в любое время» (Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений). Нельзя внести изменения в работающую программу, например, на Python, её придётся остановить и запустить заново. При этом Smalltalk, и, насколько я знаю, Lisp это позволяют.Если вы хотите изменить интегрированную среду разработки, вы можете сделать это в работающей системе, без остановки, перекомпиляции и перезапуска. Если вам необходима в языке новая управляющая структура, вы можете добавить её. В некоторых реализациях вы можете также изменить синтаксис языка или способ работы сборщика мусора.
iperov
21.06.2016 17:00>>>разработка ПО развивается обратно пропорционально Закону Мура: железо улучшается каждый год, а софт становится раздутее без надобности
конечно, если в IT сообществах изобретение велосипедов высмеивается в пользу готовых фреймворков.
Когда программист сталкивается с избыточностью и нечитабельностью макросов в C++, или с осознанием факта, что есть 20 других компиляторов С++, которые скомпилят его продукт по-другому, в чем возникает необходимость подстраивать продукт под каждый компилятор и каждый тип архитектур, ему это надоедает (потому что он перфекционист) и изобретает новый язык… скажем C#.
Вот только создать C# на истеричной ноте отвращения к C++, сугубо под свои нужды, не продумав на 20 лет вперед, что еще может понадобится в языке через 10 лет, привело к тому что огромные деньги вбуханы в поддержку и раскрутку языка, и эта инертность по факту тормозит развитие программизма в целом. Теперь будем еще 10 лет обсасывать причёсывание C# с каждой спецификацией, т.к. фундаментально в нем уже ничего не изменить.
Конечно будут появляться новые языки от различных фирм, но я считаю, если язык не создан долларовым гигантом, то такой язык обречен изначально.
Поэтому я жду и надеюсь, что выйдет нечто эдакое революционное.Fesor
21.06.2016 19:41Вот только создать C# на истеричной ноте отвращения к C++
C# создавали на истеричной ноте того что писать на C# дешевле выходит для бизнеса. Меньше рисков, скорость разработки выше, стоимость поддержки меньше. Бизнес счастлив. А то что C# аж в 2 раза медленее C++ — это мелочи которые не сильно интересуют бизнес. Сервера стоят дешевле.
Ну и да, C# очень лаконичный язык. Его минус — привязка к конкретной платформе (mono не считаем) но это скоро думаю изменится.
Поэтому я жду и надеюсь, что выйдет нечто эдакое революционное.
Rust смотрели? Очень приятный язык который по скорости равен Си (то есть быстрее плюсов). Вот только в статье говорится что будущее за языками с динамической типизацией, аля ruby, python и т.д.iperov
21.06.2016 21:33Будущее наступит, когда кодовая база перестанет каждый раз переписываться на вновь изобретенный язык.
Тогда «изобретаторы» смогут более чаще изобретать новые языки, и тестировать их в условиях широкомасштабного применения, итоговой целью которого будет создание <последнего языка программирования> для процессоров с бинарной логикой.
avost
21.06.2016 21:37C# очень лаконичный язык. Его минус — привязка к конкретной платформе (mono не считаем) но это скоро думаю изменится.
Вот любопытно, что заставляет вас считать, что скоро всё изменится и какова ваша оценка этому "скоро"? А то ведь этому "скоро" уже два года (как код открыли). Хоть куда-то оно сдвинулось?Fesor
22.06.2016 00:41Хоть куда-то оно сдвинулось?
ну относительно недавно мелкософт купил ксамарин, и вместе с ним получил mono и теперь спонсирует его разработку. Словом ресурсы в это дело они вбухивают.avost
22.06.2016 11:10Ну, насчёт того зачем они купили замарин у меня иное мнение, но я-то про реальный выхлоп. А то правда, восторги о том, что скоро всё будет длятся с 2014, а сделано хотя бы что-то? За два года микрософты успевают выпустить платформу и похоронить её.
PsyHaSTe
23.06.2016 14:04Что похоронить? .Net Core живет и здравствует, я 2 недели назад перевел проект на RC2, через месяц релиз будет уже на реальном стенде (go live позволяет такое обращение с RC), будет возможность работать и на линуксе и на винде. Если это не «что-то», то я даж не знаю :)
avost
23.06.2016 15:56Так я не в курсе, поэтому и спрашиваю. На линуксе можно работать или, как последние два года, по-прежнему «скоро будет, а вы там держитесь»? :)
Просто для меня довольно очевидно, что им не выгодно делать, чтобы что-то работало на линуксе и других платформах. Поэтому они покупают, да (чтобы потом убить).PsyHaSTe
23.06.2016 16:53Они как раз заинтересованны в линуксе, и тем больше, чем популярнее становится Azure.
Что касается .Net core, то вполне себе норм разрабатывается. Единственное что после перехода на RC2 слетела подсветка студии для кастомных депенденси, но это скоро должны починить.
На линуксе все работает точно также, как не на линуксе :) По крайней мере за ASP.Net Core говорю. То есть достаточно сложный веб-сервер живет и здравствует, причем работает быстрее чем на иисе.
0xd34df00d
22.06.2016 00:59по скорости равен Си (то есть быстрее плюсов)
Так толсто, что даже тонко. Что в плюсах медленно?
Язык, впрочем, приятный, это да.Fesor
22.06.2016 01:57+1Что в плюсах медленно?
Все то что делает плюсы плюсами а не надстройкой над Си. Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Но в целом согласен, толстова-то вышло. Rust быстрее плюсов на очень небольшом классе задач, и причем по памяти кушает больше.0xd34df00d
22.06.2016 02:13Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
При этом компилятор способен девиртуализировать такие вызовы, и это делать проще, чем в случае сей.
Да и на С аналогичные решения аналогичных задач давали бы как минимум такой же оверхед, разве нет?
Как по мне, плюсы плюсами делают всякие там темплейты, например, move semantics и так далее, что позволяет ещё проще писать эффективный код.
DarkEld3r
22.06.2016 11:05Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Там где в плюсах будут нужны виртуальные вызовы в расте будут "трейт-объекты" которые устроены примерно так же.
Про память тоже интересно. Это результат тестов каких-то? Что в расте принципиально больше памяти требует?potan
22.06.2016 11:44+1Rust все-таки подталкивает не использовать ссылки на трейты слишком часто. А там, где используются объекты известного типа (даже если это типовой параметр) код можно сгенерировать более эффективный.
Ссылки на трейт действительно требуют больше памяти — указатель на vtbl хранится в каждой копии ссылки, а не в самом объекте, как в плюсах.DarkEld3r
22.06.2016 12:04указатель на vtbl хранится в каждой копии ссылки, а не в самом объекте, как в плюсах.
Да, справедливо. Хотя "на глазок" и кажется, что большой разницы из-за этого всё-таки быть не должно.
potan
22.06.2016 11:38+1Когда требуется полиморфизм, на C виртуальный метод вызывают руками точно так же, как это сделал компилятор. Я много работал с кодом ядра FreeBSD и читал код ядра Linux, там таких примеров очень много. Кое что даже компилятор может сделать эффективнее. Хотя как-то столкнулся с интересным примером подмены vtbl у живого объекта — заставить компилятор C++ такое сделать можно только с помощью очень рискованных трюков.
Но шаблоны C++ способны порождать более эффективный код, чем человек напишет руками на C. За счет специализации на этапе компиляции.
chaetal
22.06.2016 11:01+1Насчет лаконичности C# — это такой тонкий троллинг? :)
PsyHaSTe
23.06.2016 14:06Какой еще троллинг? Тот же LINQ позволяет в однострочник записать несколько десятков строк, и это будет прозрачно и понятно. Можно конечно и на LINQ наворотить хрень, но основные кейсы обычно покрываются нормальным использованием.
chaetal
23.06.2016 21:43Так речь о лаконичности кода на C#? Не самого языка?
Или таки о лакончности кода на LINQ? ;)
… (мечтательно) А если добавить еще пару десятков ключевых слов и несколько «служебных под-языков», то станет еще лаконичнее!…PsyHaSTe
23.06.2016 22:15+1LINQ можно было и самим написать, ничего сверхъестественного там нет, десяток методов-однострочников. Так что LINQ это именно что средствами самого языка реализованная фишка, никакой не дар свыше и не забитая в платформу гвоздями функциональность, которую кроме МС никто не может себе позволить.
chaetal
24.06.2016 07:34Охотно верю!
…Но факт остается фактом: чтобы добавить поддержку новой возможности/удобства, в язык приходится добавлять новые конструкции. Чтобы добавить сопрограммы — введем новое ключевое слов. Чтобы было удобнее обрабатывать «внешние» данные — добавим еще несколько… да что там мелочиться?! добавим сразу язык… Ну и т.д.: с каждой новой версией язык все пухнет и пухнет. Количество концепций в языке все больше и больше. Сложность все растет и растет… А это сложность, с которой разработчику приходится иметь дело буквально каждую секунду.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Между тем, еще в 60 – 70-е годы показали (Lisp, Simula-67, Smalltalk…), что это можно и нужно делать не в языке (что приводит к взрывному росту сложности), а в «библиотеках» (что позволяет усложнять только там, где нужно, и равно на столько, насколько нужно). Собственно, расширение возможностей системы разработки без усложнения языка и отличает хороший язык от плохого. Прошло 50, даже 60+ (или уже 70?) лет, а мы снова там, где были. Об этом же, как мне видится, и пытается сказать Кэй.PsyHaSTe
24.06.2016 11:41То что вы предлагаете как раз решается современными средствами типа Rosylin или LLVM — то есть можно вставлять свои промежуточные слои преобразования кода. Просто тут проблема в 15 различных стандартах, когда каждый кто в лес, кто по дрова. Когда есть единый центр выпуска фич, каждую из которых крутят с разных сторон на предмет нужности, это лучший исход, чем когда ты меняешь работу, а там типа такой же язык, но де-факто полная ересь, совершенно не такая, как была на старом месте :)
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Брейнфак не меняется с момента создания, наверное это говорит о целостности его идей и его выразительной мощи?:)
Не все изменения языка мне нравятся (например оператор is, с out-параметров выглядит очень не очень), но никто не заставляет использовать ВСЕ возможности. Причем разные возможности рассчитаны на разный стиль программирования, и разный уровень абстракции разработчика. Например pattern match рассчитан на высокоуровневые разработки, активно использующие LINQ и т.п., где лаконичность важнее производительности (каждый раз вызывать делегат вместо простого куска кода это всегда оверхед). А например ref-возвращаемые значения они для низкоуровневых операций, когда нам копирование ссылки капец как портит производительность. Ну и какие-то записи просто упрощают, вроде readonly-свойств или лямбдосвойств. В целом эволюция идет в правильном направлении. Усложняется язык — что поделать, нельзя добавить функцинальность, не добавив её. Главное чтобы она была ортогональна.
kemiisto
24.06.2016 11:56+2Fesor, по-моему, неточно выразился в самом начала этого треда: C# — никак не лаконичный язык, но он позволяет (местами) писать лаконичный код (за счёт кучи «сахарка», навроде того же LINQ). А с Вами согласен: если единственный способ сделать что-то выразительным (а не просто выразимым) — расширить сам язык, добавив в него новую сущность, а не написать на уже имеющемся языке библиотеку, то с языком таки что-то не так…
snuk182
21.06.2016 17:00-1> Статически-типизированные языки кажутся ему неполноценными
Ровно до момента, когда принесут на саппорт крупный проект на «полноценном» языке.potan
21.06.2016 17:43+1На Erlang реализованы очень крупные проекты с надежностью в несколько девяток и горячими обновлениями кода.
snuk182
21.06.2016 17:51+1На Javascript и РНР тоже, что вовсе не значит море удовольствия от поддержки проектов на этих языках. Больше проверок кода, как вручную, так и статическими тулзами.
Fesor
21.06.2016 19:55На Javascript и РНР тоже
На них просто реализовано много больших проектов, но это не значит что они надежны. А вот Erlang в этом плане оч крутой.
Маленькое уточнение — Erlang язык с сильной динамической системой типов, что уже делает его чуть лучше других (PHP или JS например). То есть никакого жанглирования типами как в PHP. Это только если говорить о системе типов. А так erlang предоставляет много крутых вещей которые повышают надежность систем. Собственно этот язык для надежных систем и предназначался изначально.
lorc
21.06.2016 20:19+1Мне всегда казалось, что PHP — это stringly-typed (sic) язык. Поэтому он тут немного не в кассу.
Gryphon88
21.06.2016 17:46Lisp велик, но писать на нем чудовищно сложно :( Попробую объяснить, что я считаю «мощной структурой»: структура является тем более мощной, чем выше отношения того, сколько слов, не являющихся абстракциями, заложенными в сам ЯП, надо потратить, чтобы объяснить, что она делает и как работает, к количеству самостоятельных строк, нужных, чтобы заставить её работать. Если мысль полная и завершенная, то она выделяется, например, в функцию и объект, который уже может общаться с другими через сообщения.
Языки дают нам ключевые слова, библиотеки — дополнительные типы данных и функции, из них мы делаем прикладные абстракции. Если все средства узкоспециализированы (или привязаны к архитектуре), в языке появляется «ползучий фичеризм», а кодинг становится многословным. Но если ключевых слов мало, то абстракция становится сложной, её сложно держать в голове, а особенно представлять её динамику и наследования. А в Lisp я это делать обязан Хотя, может, я не умею правильно его готовить.chaetal
22.06.2016 11:14+1Хотелось бы уточнить, что же вы хотели сказать? Должен язык содержать мало «ключевых слов», много их, или «достаточно»?
Не приходила ли мысль о том, что таки язык должен быть как можно проще (соответственно, минимум «ключевых слов») и естественнее (соответственно, ближе к человеку), но позволять расширять сам себя новыми «абстракциями», удобными в использовании. То есть, эти абстракции должны лежать в рамках всего одной концепции, вокруг которой построен язык. Кстати, это как раз описывает (цели) Lisp и Smalltalk. …Другой вопрос, насколько они к этим целям приблизились. Lisp сложно назвать изначально естественным для человека; Smalltalk-таки пожертвовал чистотой в угоду прагматичности… впрочем, современным языкам и до этого далеко.
… И да — никаких DSL здесь не потребуется: все будет в рамках исходного языка.Gryphon88
22.06.2016 14:52Сразу оговорюсь, я не люблю писать код и не занимаюсь этим профессионально, отсюда растут мои дилетантские рассуждения о том, какой должен быть язык. И я не знаю, сколько должно быть ключевых слов в самый раз. Расширение внутри одной концепции — это правильно, но с метапрограммированием иногда кажется, что ты играешь в драконий покер. А хороший тон лиспа требует мало слов и много «мета». Конечно, и из него можно сделать бейсик, но при создании языка наверно что-то другое имелось в виду :) Грубо говоря, если следовать советам из книги «Structure and Interpretation of Computer Programs» я должен думать образом, отличным от того, как если бы решал задачу вручную, чтобы раскрыть все возможности лиспа, а мне лень вывихивать мозг.
Код должен быть одновременно близок человеку (чтобы легко читаться и писаться) и машине (чтобы быстро работать). Языковые конструкции не должны сбивать с мысли, когда пытаешься наложить свою модель процесса на средства языка. Для себя я пишу на матлабе (прототипирование или программы на пару запусков) и на С, когда надо пережёвывать много данных. Сравнивая длину кода, служащего одной и той же задаче, матлаб выигрывает в разы: например, я могу к числу относиться как к числу, к матрице — как к матрице, а в сях я должен явно указать, что это за число, и относиться к нему как к ячейке по адресу в памяти. Зато матлаб медленный.
ArisChik
21.06.2016 18:59+1Луговский (по-крайне мере образца середину нулевых) одобрительно кивает головой. Помню, как 10 лет назад он был едва ли не единственным адептом мета-программирования, ФП и «правильного» ООП
potan
22.06.2016 11:46+1Виталий все-таки сторонник статической типизации :-).
chaetal
22.06.2016 11:55Если честно не знаю, кто это… Но как «правильное ООП» может уживаться со статической типизацией?!? :)
potan
22.06.2016 12:04Не совсем «правильный», но все же ООП есть в хорошо статически типизированных языках OCaml и Scala.
А совсем «правильных» языков, основанных на сообщениях, можно считать что и нет. Ну разве что Erlang, но его недостаточно что бы говорить о невозможности ни чего другого.chaetal
22.06.2016 13:28Совсем правильных языков нет, согласен. Но наиболее близки к ним (из известных мне) Smalltalk и Self. Они очень неплохо для современного уровня отражают «правильный ООП» (по крайней мере, таковой в моем понимании; не уверен, что тут мы говорим об одном и том же). …Может быть еще Newspeak, но он таки имхо не в ту сторону пошел. Про Erlang судить не берусь.
Я поясню, почему у меня вызывает отторжение сочетание «праильного ООП» и статической типизации. Идея ООП состоит в том, чтобы быть как можно проще. Объекты и сообщения — и больше ничего. Статическая типизация сюда явно не вписывается. Динамическая — чуть лучше, в плане того, что это личное дело каждого объекта.
Это, разумеется, не значит, что типизация — это плохо. И у статической есть свои преимущества. Но она не должна быть реализована в языке. Вытащите это (как и многое другое, впрочем) в «библиотеку» и будет (почти) всем (почти) счастье :) Для того же Smalltalk-а это было (даже неоднократно) показано.potan
22.06.2016 14:36+1Но сообщения между собой как-то должны различаться? Что мешает к этому добавить их классификацию по типам, которую можно проверить статически?
chaetal
22.06.2016 21:20-1Как подсказывает логика и подтверждает практика, добавить можно почти все что угодно почти куда угодно :) Вопрос в другом — зачем? И еще не мешает подумать о том, к чему это приведет… Собственно, я свою мысль уже изложил, но, видимо, плохо. При этом что именно вас смущает — мне не ясно. Поэтому для продолжения диалога, наверное, надо как-то уточнить, в чем именно загвоздка.
potan
22.06.2016 23:29Для меня статическая тимизация — это способ задать ограничения на программы, которые бы с одной стороны позволяли компилятору создавать более эффективный код, а с другой — обнаруживали бы часть ошибок на этапе компиляции, которые бы иначе возникли бы во время исполнения.
Эти ограничения как минимум, заменяют часть тестов. То есть усложняют язык не более, чем использование тестового фреймвока.
То есть тип переменной — это более простой способ написать assert, проверяющий ее принадлежность к этому типу и срабатывающий заранее.Fesor
23.06.2016 00:13+1Справедливости ради, 100% покрытие кода тестами не гарантирует отлов 100% ошибок. Есть проекты на динамических языках программирования (к примеру команда Doctrine) в которых разработчики делились информацией, что в проекте с 100% покрытием кода тестами и проведением мутационного тестирования добавление информации о типах позволило выявить новые проблемы.
Но это мы говорим о языке со слабой динамической типизацией. Чуваки из Python или Ruby сообщества больше переживают из-за оверюза (именно оверюза) возможностей манкипатчинга нежели системы типов их языка.
chaetal
23.06.2016 07:50Вот это действительно интересно! Какие были обнаружены проблемы при 100% покрытии тестами? Где об этом почитать? Навскидку нагуглить не удалось.
Fesor
23.06.2016 09:37Это было на реддите где-то с пару месяцев назад. Я сейчас затрудняюсь найти дискуссию… Можно вот у этого человека спросить: https://github.com/Ocramius
chaetal
23.06.2016 21:30-1Типы в языке — лишняя сущность. Язык сложнее.
Типы обязательны — лишние действия при объявлении переменных/методов. Писать код сложнее.
Чтобы код запустить на выполнение нужно обеспечить совместимость типов, даже если мне в данный момент это не нужно. Исследовать/разрабатывать сложнее.
…PsyHaSTe
23.06.2016 22:24имена переменных в языке — лишняя сущность.
ограниченное количество ключевых слов — лишняя сущность.
Похоже вы гений, который всегда с 1 раза пишет правильно все модули системы и никогда не пользуется кнопочкой debug.chaetal
24.06.2016 07:51-1Если язык функциональный, то имена переменных — лишняя сущность. Функциональщики лучше объяснят. А если объектный, то объявление переменных — лишний синтаксис. Достаточно иметь объект-контекст с методом добавления в него переменных.
Ключевые слова… не знаю, можно ли обойтись без них, но ясно, что их должно быть как можно меньше. В том же Smalltalk-е их всего ничего: self, super, nil, true, false, thisContext. Да и они, в общем-то необязательны — так, сахарок. Есть правда еще куча другого синтаксиса… Впрочем, «куча» — очень относительно. По сравнению с C# его почти и нет :) Но все равно — слишком много, язык далек от совершенства… Не буду развивать мысль, рановато пока.
P.S.: Предлагаю не переходить на личности. Вы меня совершенно не знаете. И то, что вы, судя по вашим комментариям, пока не понимаете то, что я стараюсь сказать, не дает повода пытаться меня задеть ;)PsyHaSTe
24.06.2016 12:35Я? Задеть? Я наоборот, восхищен вами!
Лично я, как и мои коллеги на работе, умудряются в статически типизируемых языках находить ошибки, а вы в динамике умудряетесь такие подвиги совершать. По мне так это достойно всяческой похвалы. В жизни я таких людей не встречал, так что это очень большая редкость и радость видеть Вас наяву.
chaetal
23.06.2016 07:55У меня вдруг родилась формула:
1. Статическая типизация нужна для оптимизации
// по производительности кода
// по проверке его правильности
// (еще почему-то не упоминали, вроде) по проведению рефакторинга…
2. «Преждевременная оптимизация — корень всех зол» (Д. Кнут или кто-то еще)
sshikov
21.06.2016 19:36Интернет никогда не отключался? Да ладно!
Он просто состоит из множества реально независимых частей, которые сами по себе отключатся регулярно, просто они друг другу не нужны. В том числе — отключаются по вполне себе внутренним причинам.
Fesor
21.06.2016 19:44Весь интернет никогда не отключался. Отключались датацентры. Но если повредился один из маршрутов система адаптируется.
sshikov
21.06.2016 19:56Видите ли, в же стиле можно сфорулировать любую чушь.
Интернет — в том смысле, который ему придает сам автор цитаты, т.е. софт TCP/IP, еще как отключается. Позвольте мне не давать вам ссылки на множественные уязвимости серверов любого рода, которые позволяют их легко уронить? Да, система адаптируется, и сильно. Но тем не менее любой из нужных именно вам ресурсов в любой момент может быть недоступен. А то что мы видим — лишь результат дублирования.
Если угодно — общая конструкция интернета, как фиговины состоящей из большого числа независимых частей — она да, устойчивая. Но протоколы, которые в нее входят, и отдельные узлы — совсем нет.
dendron
21.06.2016 20:23Не понял, как протокол является примером софта?
chaetal
22.06.2016 11:20+2Отличный вопрос! Прекрасно показывает как мы сегодня все это (неправильно) понимаем. Типа, софт — это код.
Речь, как мне видится, идет о построении сложных систем. Код на языке — это лишь способ связать компоненты этой системы между собой, дать им возможность общаться. В этом смысле протокол — как раз способ общения, то есть полный аналог языка. В случае с инетом удалось каким-то волшебным способом построить сверх-сложную систему, сделать ее саморегулируемой… и при этом относительно простыми средствами.
arielf
22.06.2016 00:43+4Alan Kay — действительно гениальный инженер, один из немногих такого уровня. И на мой взгляд немалая заслуга его гениальности в широком американском образовании, когда вы можете сразу по нескольким направлениям получить научную степень бакалавра. В его случае это были математика и биология. У нас, увы, такое невозможно. Даже внутри одного вуза, например, в нашем СПбГУ очень мало взаимодействия между факультетами и огромный снобизм у представителей разных наук по отношению друг к другу.
geekmetwice
22.06.2016 06:07-6Забавный бред для человека, вышедшего из прошлого века. Жаль, что он вообще не понимает, насколько ИТ изменился — насколько стал сложным, дорогим и ответственным. Время хакеров-одиночек прошло, время бредовых языков — тоже (включая ЛИСП, Рефал, Брэйнфак и прочую ересь). Сейчас есть «мэйнстрим» и «хобби» и Алан так и остался в мире «хобби». А большинство прогеров работают в мэйнстриме, где нет места «сейчас, я только побырому интерпретатор напишу!». Динамические языки тоже показали свою несостоятельность — взлетели на волне хтмл-страничек и домашних перделок, но дальше — ни ногой. Так что спасибо, Алан, за интересные истории, но советы я спрошу у кого-нибудь другого. Например, у Уолтера Брайта.
iroln
22.06.2016 09:21Вот последние результаты опросов Python-разработчиков: раз, два
Scientific, Data Analysis, Numeric, Financial — это те области, где Python становится очень популярен.potan
22.06.2016 11:50+2Питон популярен вообще. И анализ данный сейчас стал очень популярен.
Не удивительно, что многие питонисты занимаются данными, а многие специалисты по данным используют питон. Это не говорит о том, что питон как-то особенно хорош в этой области.iroln
22.06.2016 12:19Python имеет проблемы с рождения, но он действительно хорош и уже достаточно зрелый, поэтому он в последнее время становится так популярен не только в web-разработке. Ruby, например, остался популярен практически всецело в web и, по большей части, благодаря Rails. Python же и его экосистема сейчас активно продвигается как удобный инструмент для учёных и инженеров не только в области data mining. Я думаю, в ближайшем будущем Python со стеком библиотек, вроде scipy, vispy и т. п. серьёзно потеснит Matlab и прочие инженерные и научные пакеты. Даже сейчас, например, Python-дистрибутив «Anaconda» от Continuum Analytics и среды разработки, вроде Spyder или rodeo заменяют базовую функциональность Matlab и его основные тулбоксы. Добавьте к этому то, что Python-код зачастую является production-ready, в отличии от всяких matlab/mathematica.
geekmetwice
22.06.2016 14:58-3Ну вы ещё опрос похапэшников приведите! *смайл «пацталом»*
Что он должен доказывать? Что бросаем всё и бежим учить Лисп? Писать биллинг на Смоллтоке? Закладывать таймбомбы поздним связыванием?
Вы пропускаете ключевые слова, смысл которых очень важен: мэйнстрим, предсказуемость, сопровождаемость, надёжность. И всё это вообще не про Питон! Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости. Поэтому когда «отцы ИТ» (а по-хорошему, сильно постаревшие мальчишки-хакеры из 50-ых) начинают развозить в воздухе «вы должны...», становится смешно. Особенно про ЛИСП.iroln
22.06.2016 15:55Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости
Хорошо, давайте так. Есть две функции:
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++.
Azoh
23.06.2016 12:47А что плохого в позднем связывнии? Отличная же концепция, если язык еще и предоставляет удобные инструменты для реализации (скажем виртуальные функции), то совсем хорошо
kovyl
22.06.2016 13:23+2>> время бредовых языков — тоже (включая ЛИСП, Рефал, Брэйнфак и прочую ересь)
Вот жесть. Вы, пардон, по какому принципу составили этот список?geekmetwice
22.06.2016 14:36Вы, пардон, слово «мэйнстрим» пропустили?
chaetal
22.06.2016 21:39+2В 70-е годы тоже был мэйнстрим — компьютеры размером с квартиру. И было хобби — маленькие такие смешные компьюшки, собранные любителями в гаражах. И вот, судя по всему, похожие на вас ребята сидели в дорогих креслах в шикарных кабинетах и с такой же снисходительной издевкой объясняли, что на этом бизнес не построить, денег не заработать, и вообще они «пацталом» от этих несерьезных волосатых детишек в джинсах… Надеюсь, понятно, что отматывать подобные истории можно долго и на много-много лет (веков) назад? Оцените свою роль в истории ;)
geekmetwice
22.06.2016 23:03-1Вы спросили про принцип — я ответил. По-делу есть что?
chaetal
23.06.2016 07:35Я-то ничего не спрашивал :) …и комментарий был не для вас — вам-то все ясно и понятно.
Gryphon88
22.06.2016 14:19Не соглашусь с Вами, в частности про бредовые языки. Мне кажется, что прочесть хотя бы getting started по таким языкам нужно для того, чтобы потом не говорить «А что, так можно было?!». В коде мы излагаем своё представление об объекте управления, и разные вещи удобнее выражать с помощью разных парадигм. Я не верю, просто на эмоциях, в применимость «чистых», однопарадигменных языком, но считаю, что использовать «чистые» парадигмы удобно. Я видел код на плюсах, в котором одним программистом в разных кусках применялись ФП, ООП, аспектно-ориентированное программирование и С с классами. Было понятно и, чёрт возьми, красиво!
geekmetwice
22.06.2016 14:48-8Мы не говорим про студентов, которым как любопытной Варваре — интересно всё подряд — я уже этот этап прошёл. Я про коммерческую разработку, где «серьёзные дяди» платят большие деньги и хотят предсказуемый результат. И извините, я никогда не выйду к ним с языками типа Пестона, Сипипи или Раста. Или того хуже — ЛИСП.
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ. Так вот: на _сегодня_ Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны. Никому не нужны макросы или «живой бардак» типа Смоллтока — нужны простые, надёжные решения — это моя ежедневная работа. И уверяю, без ЛИСПа можно вполне хорошо писать системы — есть хорошие языки типа C#, D, Java, код которых можно СОПРОВОЖДАТЬ. В случае ЛИСП — увы, это write-only язык и его незнание ну вообще никак не влияет на ваш профессионализм.chaetal
22.06.2016 21:43+1Спасибо вам за подтверждение моего тезиса, что именно «обизнесовывание» убивает всякое развитие, в частности в IT! Давно хотелось услышать подтверждение из первых уст. Буду на вас ссылаться, вы не против?
geekmetwice
22.06.2016 23:08-6Вы дурь-то свою не светите, милейший! Ваши тезисы не интересуют никого, кроме вас самих. Если не понимаете, чем живёт мэйнстрим и бизнес — это к папе, не ко мне.
chaetal
23.06.2016 07:39:D
Я принимаю это как положительный ответ! Если необходимо указывать точное авторство, скиньте ФИО в личку или куда-нибудь. Я вполне серьезно: буду вас цитировать.
Fesor
22.06.2016 22:16+2где «серьёзные дяди» платят большие деньги и хотят предсказуемый результат.
А получают гору легаси на Java. Ну ок.
И извините, я никогда не выйду к ним с языками типа Пестона, Сипипи или Раста.
Скажите, почему Rust это плохой язык а D хороший? Мне нравится и Rust и D, но как я вижу поддерживать решения на Rust сегодня проще и дешевле чем на D. Вопрос размера комьюнити и вложений от крупных компаний.
Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны.
бизнесу эти вещи знать не надо. им важен результат. То о чем вещает Алан показывает высокий результат. Культура разработки, профессианализм, это все намного важнее "языка". А сейчас очень много разработчиков которые не доконца понимают что они делают. И это не зависит от языка разработки (хотя кое какие корреляции существуют).
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ
Dlang — хобби. Java — начинался как хобби. javascript — начинался как хобби, php — начинался как хобби, python — начинался как хобби. ruby — начинался как хобби. Мне продолжать? Конечно же я утрирую говоря о хобби. Этим я хочу подчеркнуть субъективную точку зрения создателей этих языков. Например C# можно воспринимать как чисто коммерческий язык, который был под чистую слизан с Java но с небольшой работой над ошибками. При создании оного мотивировались исключительно потребностями бизнеса, причем самой компании Microsoft. И при этом у них неплохо вышло.
код которых можно СОПРОВОЖДАТЬ
А теперь вспомните, сколько было написано легаси когда на этих языках который сопровождать проблематично? Я думаю существенно больше чем кода, удобного в поддержке.
Fesor
22.06.2016 18:27Сейчас есть «мэйнстрим» и «хобби» и Алан так и остался в мире «хобби»
Сейчас есть армия клепателей контроллеров. Для 80% проектов это может быть ок, а для остальных 20% это приводит к высокому уровню тех долга и большим расходам на суппорт приложений. Алан входит в категорию тех, для которых программирование является профессией, а не хобби. Я думаю вы должны понимать разницу. Как раз таки "мэйнстрим" чуваки обычно действуют более стихийно, как буд-то бы это хобби.
Динамические языки тоже показали свою несостоятельность — взлетели на волне хтмл-страничек и домашних перделок
http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htmlkemiisto
22.06.2016 20:26Ну а что Вы хотели услышать от одного из апологетов TDD? Опять эти сказки, как TDD спасает мир. «You don't need static type checking if you have 100% unit test coverage.» Вы вот много видели проектов со 100% покрытием? «Therefore, I predict, that as TDD becomes ever more accepted as a necessary professional discipline, dynamic languages will become the preferred languages.» Even more? Мужик не заметил, что hype вокруг TDD уже прошёл? Как, собственно и вокруг динамической типизации. Что поделать, цирк уехал искать новые buzz word'ы, ну а кто в таких случаях остаётся, Вы прекрасно знаете.
P.S. «So says this old C++ programmer.» Вот что меня убивает, что сравнивают как всегда с С++ и его потомками. Ну покажите деду хоть Аду что-ли или Модулу-3. Хотя там в середине есть пассаж «Pascal, I felt, was a language for babies.» после которого писанину этого «взрослого» вообще можно не читать…
Rulexec
22.06.2016 18:45+3Вот сидите вы в своём энтерпрайзе глухо, десятками лет оттачиваете навыки джавы/шарпов, ходите на конференции, разрабатываете серьёзные системы и считаете, что всё так и будет и дальше, куда может деться спокойное энтерпрайзное программирование? 50 лет стояло — ещё 50 простоит.
Но я уверен, что беда придёт откуда не ждали. Функциональное программирование медленно, но верно просачивается всюду, пускает свои ростки. Вы смотрите, уже и в джаве наступает время конкурентности, а не параллельности. И лямбды, мапы, фильтры и, страшно подумать… свёртки списков!
Сейчас оно проникнет в мейнстрим и люди начнут массово мыслить «функционально».
И тут всплывёт вопрос типизации. Вот вы говорите, что язык должен быть статически типизирован. Что если я скажу вам, что с моей точки зрения типизация джавы — какое-то ребячество, позволяющее только отличить строку от числа?
Полиморфная типизация уступает зависимой в бесконечность раз. Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются и пока выглядят очень плохо и хило. Но есть ребята, которые двигают HoTT и в процессе формализации HoTT в HoTT получат нечто божественное.
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации, и как бонус — в нём нет ни одной излишней динамической проверки и он работает быстрее любого си-кода, который написан человеком.
И тогда будет лишь два вида разработки — «серьёзная», где требуется надёжность. И «несерьёзная» — где можно тяп-ляп и на динамическом ЯП быстро заставить машину сделать чего нужно.
Языки «среднего класса» умрут.geekmetwice
22.06.2016 19:40-3Ну вот тем и отличаются люди-практики от Аланокеев — одни живут сегодня и кормят семью, а другие теоретизируют на кафедрах за 20 тыщ рублей и кормят мир светлым будущим.
Дело не только в интыпрайзе, но в самой сути людей: ОЧЕНЬ сложно просто взять ЛИСПовский код и за минуту объяснить, что он делает. Люди ограничены, даже если имеют за плечами десятки языков (я лично писал на более, чем 20-ти). Поэтому я уверен, «простота и мощь» была и будет главным девизом ИТ, а его применимость к интыпрайзу — лишь приятный бонус.
ФП? Не смешите мой дисковод! За те годы, что о нём знают, он давно вылез бы в топы, если бы не был таким кривомысленным, ортогональным нормальному человеческому мышлению. То, что какой-нть C# позаимствовал лямбды, НИЧЕГО не говорит в пользу ФП. Посмотрите на это так: была функция сортировки с захардкоженным сравнением a < b. Функцию расширили (каким угодно механизмом) и теперь сравнивать можно любым переданным методом — ПРИЧЁМ ТУТ ФП ВООБЩЕ? Это просто кастомизация функции сравнения, она вообще могла быть передана как в Ди — СТРОКОЙ. Это говорит о том, что ваше видение ФП идолизировано до того, что вы не отличаете парадигму от заимствований отдельных плюшек и где слышите «функция», сразу думаете о ФП. Функции были всегда, даже в ассемблере, но никто и никогда не выпячивал их как достоинство ФП парадигмы.
> Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются… А затем окажется… И тогда будет…
Не многовато будущих времён? :) (см. первое предложение) Даже в обозримом будущем (лет так на 20) вполне видно, что ФП — не у дел, Лигическое п-е — на задворках кафедр, ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным — потому что это близко человеку — разбирать на составляющие и собирать вновь. Из ближайших перспектив — метапрограммирование, но не в диком смысле ЛИСПа, а в стиле Немерле. Это лучшее, что может произойти с программингом в ближайшие годы.
> Языки «среднего класса» умрут.
:) Спасибо, этим вечером сильно нехватало улыбки! Вы лучший.kemiisto
22.06.2016 20:09-1По ФП согласен. Вы там важную вещицу упомянули. Очень часто, когда рассуждают, почему ФП не взлетел, начинают ругать Иоганн «нашего» фон Неймана за его богомерзкую архитектуру. Но ведь не только машины (что вторично на самом дело), но и, самое главное, люди мыслят всё-таки преимущественно «императивно». Собственно, машины мы потому такими и построили. Алгоритмическое мышление у большинства особей Homo sapiens ограничено набором инструкций, описывающих порядок действий, и только лишь «издевательство» годами матана способно заставит редких индивидов «думать» алгоритмы в терминах аплликаций функций.
chaetal
22.06.2016 22:03+1Ну вот тем и отличаются люди-практики от Аланокеев
geekmetwice
22.06.2016 23:23-3То есть вы даже на секунду не можете прожить без идолов? Ну хорошо, продолжайте фапать на аланокеев.
По картинке: Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.Fesor
23.06.2016 00:28+4Давайте так. Коль уж отказываться от идолов и убеждений, так с обоих сторон переговоров. А то так не конструктивно выходит.
Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
Давайте взгянем на web приложение на lisp. Что-нибудь простенькое, минималистичный клон твиттера: http://eudoxia.me/lucerne/docs/example--a-twitter-clone.html
Вы хотите сказать что код не читаем? Или что его дорого поддерживать потому что язык плохой? Давайте уж на чистоту, CommonLisp в web разработке не применяется потому что есть другие более популярные языки, с большим количеством разработчиков и большим количеством готовых решений. Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны, поскольку это сокращает расходы на разработку, я думаю вы не будете спорить в этом.
Но говорить что сам по себе Lisp разработан теоретиками и никто его не юзает потому что он именно такой — это лишь говорит о том что вы понятия не имеете что такое Lisp.
Идем дальше.
ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным
вот мне нравится у людей периодически спрашивать как отличить ОО код от не ОО кода. К примеру, я, как похапэшник, имею дело с такой ORM как Doctrine, которая предоставляет возможность делать сущности как обычный объекты, и мэпит их на базу. Подавляющее большинство делает эти объекты как анемичную модель, то есть куча пропертей, геттеры и сеттеры. Я думаю вы видели подобные вещи.
И в итоге мы имеем: объект хранящий состояние, и объект сервисного слоя, который это состояние меняет. Состояние отдельно, поведение которое меняет состояние — отдельно. Вроде бы у нас и объекты есть, и наследование с полиморфизмом имеются, но отсутствует инкапсуляция и мы имеем дело лишь с состоянием (один объект) и процедурами (методы другого stateless объекта).
То есть если мы вдруг захотим добавить в сущности новое поле с датой изменения, или механизм ревизий изменений, то мы не сможем это сделать красиво и быстро прямо в сущности, так как логика изменения состояния вынесена в другой объект. У нас нарушена инкапсуляция. И по итогу вместо красивого и понятного ООП с инкапсуляцией, возможностью делать декомпозицию системы, изолировать состояние и побочные эффекты, мы имеем старый добрый процедурный код с классами.
Ох, а еще веселье когда народ начинает просто так использовать сингелтоны как глобальное состояние. Встречался мне проектик под iOS, где ребята вынесли состояние в сингелтон с сотней пропертей, и мутировали его в куче разных методов разных объектов разбросанных по всей системе.
Или когда народу дико хочется заиметь множественное наследование (которое к чертям ломает полиморфизм в большинстве юзкейсов ради которого его хотят ввести), просто что бы было удобнее комбинировать процедурки по классам.
Fesor
23.06.2016 22:56А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации
А как быть с побочными эффектами? Извините за глупые вопросы.Rulexec
24.06.2016 08:08+1Функция с побочными эффектами это функция, принимающая значение состояния нашей Вселенной и возвращающая некий результат, плюс новое состояние Вселенной.
Доказывать то, что некие данные появились из I/O, а не от балды легко — ввести типов вроде IsStringFromStdin, значения которых будут возвращаться только из встроенных функций для работы с I/O. С гарантиями записи так же.
В итоге программа будет являться отображением Вселенной во Вселенную, плюс кучей типов вроде ВЭтойВселеннойБылОткрытПорт(80) и ДляПотокаБайтБылИспользованПарсер(html), ЕслиОткрывалиФайлПоЗапросуАЕгоНетВернулиHTTP404 и так далее (хотя я на самом деле этого не представляю, никто в жизни не сможет формально описать программу целиком, только её основные части).
Входящие данные обрабатываются так же как и обычно. Просто функция сравнения, например, возвращает не Boolean, а тип-сумму из доказательства или опровержения равенства. А дальше обычный switch и две ветки исполнения.
arielf
23.06.2016 03:15+2Какой мощный, но примитивный вброс! Я даже не знаю, за кого мне больше стыдно — за Вас или за целую ветку из комментаторов. Я обычно игнорирую подобное, но здесь не удержался.
Hayate
Это всё про фундаментальное программирование, или про прикладное?
Fesor
А вы можете сформулировать в чем по вашему разница?
Hayate
Я скорее всего неправильно оперирую терминологией.
Фундаментальное — это когда собираются ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч других программистов.
Прикладное — это когда «ИП Махачетурян» нужно автоматизировать бизнес-процесс и у него нет денег на оплату труда кандидатов и доцентов и исполнитель скажет — «Алгебра? Почему несколько алгебр? Она в 11 классе закончилась, потом был только матанализ и линейная геометрия».
begor
> ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки
Какое странное представление о занятиях «ботанов».
Hayate
Ну надеюсь с «ИП Махачетурян» хотя бы я не ошибся?
arielf
Ошиблись, то, что вы назвали 'прикладным' программированием, вообще им не является. Программирование, оно, как и любая инженерная работа, по умолчанию прикладное.
KoCMoHaBT61
… и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч их студентов.
KlimovDm
Как коллеги уже справедливо заметили, все эти «библиотеки, фреймворки, RFC» пишутся в сугубо прикладных целях. Мне другое интересно — почему вы так считаете? Сами придумали или этому учат там же, где и «линейной геометрии» :?
Hayate
Если вы про моё образование и программирование в альма-матер, то там были только лабораторные в стиле fizzbuzz и лабы на матлабе, посчитать какую-нибудь фигню в эсперименте. Всё максимум строк в 30.
Я ответил на ваш вопрос?
А имел в виду я всего навсего то что для написания TCP/IP и для складского калькулятора нужны разные уровни квалификации.
Хабр такой смешной, когда такой агрессивный.