Comments 139
Это всё про фундаментальное программирование, или про прикладное?
А вы можете сформулировать в чем по вашему разница?
Я скорее всего неправильно оперирую терминологией.
Фундаментальное — это когда собираются ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч других программистов.
Прикладное — это когда «ИП Махачетурян» нужно автоматизировать бизнес-процесс и у него нет денег на оплату труда кандидатов и доцентов и исполнитель скажет — «Алгебра? Почему несколько алгебр? Она в 11 классе закончилась, потом был только матанализ и линейная геометрия».
Фундаментальное — это когда собираются ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч других программистов.
Прикладное — это когда «ИП Махачетурян» нужно автоматизировать бизнес-процесс и у него нет денег на оплату труда кандидатов и доцентов и исполнитель скажет — «Алгебра? Почему несколько алгебр? Она в 11 классе закончилась, потом был только матанализ и линейная геометрия».
> ботаны, аспиранты, кандидаты, доценты и пишут библиотеки и фреймворки
Какое странное представление о занятиях «ботанов».
Какое странное представление о занятиях «ботанов».
… и пишут библиотеки и фреймворки, сочиняют RFC, которые потом будут использовать десятки тысяч их студентов.
UFO just landed and posted this here
Если вы про моё образование и программирование в альма-матер, то там были только лабораторные в стиле fizzbuzz и лабы на матлабе, посчитать какую-нибудь фигню в эсперименте. Всё максимум строк в 30.
Я ответил на ваш вопрос?
А имел в виду я всего навсего то что для написания TCP/IP и для складского калькулятора нужны разные уровни квалификации.
Хабр такой смешной, когда такой агрессивный.
Я ответил на ваш вопрос?
А имел в виду я всего навсего то что для написания TCP/IP и для складского калькулятора нужны разные уровни квалификации.
Хабр такой смешной, когда такой агрессивный.
Интересно, что он говорит про Erlang.
kartD 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 говорил прямо вчера
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 говорил прямо вчера
Улётный мужик этот Алан Кэй. Жаль Smalltalk не стал таким популярным как Python, Ruby или PHP.
Я думаю, что основная причина — слишком тесная интеграция с UI. Не было окружения, в которой было бы удобно разрабатывать серверные приложения и программы, ориентированные на CLI.
What Killed Smalltalk Could Kill Ruby — RailsConf 09: Robert Martin
Ох, опять этот Мартин. :D Но тем не менее, отдаю должное мужику: пускай и с кучей лирических отступлений, но суть он уловил и передал хорошо. «It is just too easy to make a mess.» © Касается, в принципе любого языка с динамической типизацией. 100-200 строчек — полёт нормальный, как начинаются серьёзные объёмы кода, так начинаются неприятности. В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля. Ну а самое парадоксальное, что это ещё и преподносится как преимущество. Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…
P.S. Меня одного раздражает его манера публичных выступлений?
P.S. Меня одного раздражает его манера публичных выступлений?
В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто
Ну справедливости ради это относится ко всем языкам вообще. Неужели все огромные проекты на Java прям таки мега гибкие? Что-то сильно сомневаюсь, количества легаси на джаве думаю побольше чем в том же PHP.
Rewritten from scratch! Ну теперь то заживём! Но не проходит и пару лет…
Как говорится, хватит писать легаси код! Почему-то люди предпочитают революционный подход более естественному эволюционному.
P.S. Меня одного раздражает его манера публичных выступлений?
Как он выступает на конференциях меня особо не раздражает. Наверное это потому что я когда-то посмотрел его курс лекций по чистому коду где он раз в минуту сменял образ и костюм… вот там бесило дико.
В конечном счёте большинство крупных проектов на динамически типизированных языках относительно быстро превращаются в абсолютно неуправляемое нечто, так что даже добавить какую-ту небольшую функциональность или что-то несущественное поменять из уже имеющегося становиться настолько сложно, что проще начать всё с нуля.Разве в плохо написанном большом проекте, например, на C++, легко и просто поменять или добавить что-то? Если вы пишете проект без оглядки на какую-либо архитектуру и проектирование, не делая рефакторинг, без тестов, без соглашений, то в конце-концов независимо от языка ваш проект превратится в свалку спагетти-говнокода и костылей, который невозможно будет развивать и расширять без боли. Хороший пример — проект notepad++ (статья про это)
Меня тоже раздражает манера. Но больше — содержание. Этот тезис про «динамическую типизацию» (уж простите мне категоричность, но, думаю, я могу себе ее в данном случае позволить, долго уже занимаюсь этими вопросами) — полная чушь. И уж точно не это «убило» Smalltalk… Не говоря уже о том, что ничто его и не убивало: он вполне себе живет в разных формах и, уверен, еще проявит себя в одной из них (пусть и пока еще не существующей).
Этот тезис про «динамическую типизацию» (уж простите мне категоричность, но, думаю, я могу себе ее в данном случае позволить, долго уже занимаюсь этими вопросами) — полная чушь
Он где-то говорил что всему виной динамическая типизация? Я как-то этого не услышал. Ну и для справки — боб часто упоминает что сильная динамическая типизация + тесты намного эффективнее статической типизации без тестов).
… А я не с ним спорил (прошу прощения за неудачную разбивку по абзацам) — пока и не дорос спорить с дядюшкой Бобом… Тем более заочно :) Тем более по теме «Что убило Smalltalk…» — будучи уверенным, как я уже писал, что пациент скорее жив. Его доклад слушал давно, конкретных деталей, которые меня отвратили от данного оратора (кроме манеры подачи информации), уже не помню. Большого желания тратить время на пересматривание пока нет :)
Статическая типизация, конечно, в большинстве случаев полезна (особенно такая, как в Haskell). Но все-таки бывают динамические языки, на которых приятно поддерживать большие проекты. Так на Erlang разрабатываются огромные телекоммуникационные системы. Я сам участвовал в довольно крупном проекте на языке Schema — динамическая типизация создавала не так уж много проблем.
Наверняка это не всегда так, но по личному опыту: споры о вкусе устриц и кокосовых орехов обычно затевают не те, кто их ел :)
Рассуждения о том, что динамическая типизация на «больших» проектах приводит к бОльшему количеству ошибок или к сложностям с поддержкой проектов на таких языках, скорее выдают человека, который устриц-то не пробовал. А если пробовал, то давайте ближе к фактам: на каком проекте, какой язык, какие сложности…
Рассуждения о том, что динамическая типизация на «больших» проектах приводит к бОльшему количеству ошибок или к сложностям с поддержкой проектов на таких языках, скорее выдают человека, который устриц-то не пробовал. А если пробовал, то давайте ближе к фактам: на каком проекте, какой язык, какие сложности…
На своем опыте — на Perl и js у меня довольно много ошибок приходилось вылавливать runtime, хотя проекты были и не большие.
Да и на Scheme вывали случаи, когда я путал строки и числа и компилятор это пропускал. Правда, обычно это было связано с чтением внешних данных.
Да и на Scheme вывали случаи, когда я путал строки и числа и компилятор это пропускал. Правда, обычно это было связано с чтением внешних данных.
Даже не знаю, что и сказать… Попробуем так. Вы какой тезис обосновываете? Что в динамически-типизируемом языке система позволит передать строку туда, куда по замыслу программиста нужно передать число? Спасибо, КО! :)
Вопрос-то не в этом. В «большом», серьезном проекте (кстати, независимо от типизации… даже если это великий Haskell, наверное — поправьте, если не так) будут предприняты меры по контролю «правильности» кода (те же тесты как минимум), и исходное утверждение нужно читать в одном из двух возможных вариантов:
Какой из этих тезисов вы хотите обосновать своим опытом?
Вопрос-то не в этом. В «большом», серьезном проекте (кстати, независимо от типизации… даже если это великий Haskell, наверное — поправьте, если не так) будут предприняты меры по контролю «правильности» кода (те же тесты как минимум), и исходное утверждение нужно читать в одном из двух возможных вариантов:
- проектом на динамически-типизированном языке невозможно управлять так же хорошо, как аналогичным на статически-типизированном
- управлять можно примерно так же, но сделать это сложнее
Какой из этих тезисов вы хотите обосновать своим опытом?
Зачем писать тесты на то, что может предотвратить статическая типизация?
Затем что статическая типизация предотвращает лишь малую долю проблем связанных с рефакторингом и разработкой.
Так динамическая-то вообще ничего не предотвращает. Какой профит?
сильная динамическая отлавливает ошибки с типами в рантайме. С другой стороны динамическая типизация минимально но ускоряет разработку простых систем.
Посмотрите на python. Там есть тайпхинтинг, при помощи которого можно организовать статический анализ (у нас есть вся необходимая информация о типах), с другой стороны тайпхинтинг вообще не влияет на рантайм и мы все еще имеем дело с динамической типизацией.
Когда я программировал на Haskell, бОльшая часть компилируемого кода работала правильно без всякой отладки. Процентов 80-90 по ощущениям, хотя статистику я не собирал.
Слышал аналогичные отзывы про Rust.
Слышал аналогичные отзывы про Rust.
… А еще можно это делать для того, чтобы лучше понять задачу
Кстати, мне казалось, мы говорим об одном и том же… По крайней мере я пытался поддержать тезис «существуют динамически-типизированные языке, на которых поддерживать большие проекты приятно». На всякий случай очевидное: наличие обратных примеров не опровергает этот тезис.
Слишком тесной интеграцией с GUI можно объяснить почему Smalltalk «не взлетел» как скриптовый язык, но ни почему он «упал» как язык для разработки этих самых GUI-приложений. А потом, если вести отсчёт с начала 2000-х, то GNU Smalltalk, который вполне себе отвязанный от GUI и скриптовый, тогда уже вполне живой был, но в итоге как скриптовый язык в 2000-х «взлетел» Python, а не Smalltalk. Или возьмите те же веб-фреймворки: Seaside появился на пару-тройку лет раньше Rails и Django, но как-то не очень это помогло. Там то слишком тесная интеграция с GUI уж точно проблемой не была.
В истории Smalltalk-а еще много удивительных «почему»… Постепенно сложилось впечатление, что этот «невзлет» объясняется очень просто: слишком рано.
Потому что рынок GUI-приложений не такой большой, как кажется. А нишевые языки со временем вытесняются более популярными даже из своих ниш.
Жаль Smalltalk не стал таким популярным как Python, Ruby или PHP.Вы перечислили языки, в которых нарушается принцип «Всё доступно для изменения в любое время» (Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений). Нельзя внести изменения в работающую программу, например, на Python, её придётся остановить и запустить заново. При этом Smalltalk, и, насколько я знаю, Lisp это позволяют.
Если вы хотите изменить интегрированную среду разработки, вы можете сделать это в работающей системе, без остановки, перекомпиляции и перезапуска. Если вам необходима в языке новая управляющая структура, вы можете добавить её. В некоторых реализациях вы можете также изменить синтаксис языка или способ работы сборщика мусора.
Smalltalk живее всех живых, за 40 лет не умер и ещё всех переживёт!
а кто может подсказать где прочитать про «видение важнее целей» и «финансирование людей, а не проектов»?
>>>разработка ПО развивается обратно пропорционально Закону Мура: железо улучшается каждый год, а софт становится раздутее без надобности
конечно, если в IT сообществах изобретение велосипедов высмеивается в пользу готовых фреймворков.
Когда программист сталкивается с избыточностью и нечитабельностью макросов в C++, или с осознанием факта, что есть 20 других компиляторов С++, которые скомпилят его продукт по-другому, в чем возникает необходимость подстраивать продукт под каждый компилятор и каждый тип архитектур, ему это надоедает (потому что он перфекционист) и изобретает новый язык… скажем C#.
Вот только создать C# на истеричной ноте отвращения к C++, сугубо под свои нужды, не продумав на 20 лет вперед, что еще может понадобится в языке через 10 лет, привело к тому что огромные деньги вбуханы в поддержку и раскрутку языка, и эта инертность по факту тормозит развитие программизма в целом. Теперь будем еще 10 лет обсасывать причёсывание C# с каждой спецификацией, т.к. фундаментально в нем уже ничего не изменить.
Конечно будут появляться новые языки от различных фирм, но я считаю, если язык не создан долларовым гигантом, то такой язык обречен изначально.
Поэтому я жду и надеюсь, что выйдет нечто эдакое революционное.
конечно, если в 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 и теперь спонсирует его разработку. Словом ресурсы в это дело они вбухивают.
Ну, насчёт того зачем они купили замарин у меня иное мнение, но я-то про реальный выхлоп. А то правда, восторги о том, что скоро всё будет длятся с 2014, а сделано хотя бы что-то? За два года микрософты успевают выпустить платформу и похоронить её.
Что похоронить? .Net Core живет и здравствует, я 2 недели назад перевел проект на RC2, через месяц релиз будет уже на реальном стенде (go live позволяет такое обращение с RC), будет возможность работать и на линуксе и на винде. Если это не «что-то», то я даж не знаю :)
Так я не в курсе, поэтому и спрашиваю. На линуксе можно работать или, как последние два года, по-прежнему «скоро будет, а вы там держитесь»? :)
Просто для меня довольно очевидно, что им не выгодно делать, чтобы что-то работало на линуксе и других платформах. Поэтому они покупают, да (чтобы потом убить).
Просто для меня довольно очевидно, что им не выгодно делать, чтобы что-то работало на линуксе и других платформах. Поэтому они покупают, да (чтобы потом убить).
Они как раз заинтересованны в линуксе, и тем больше, чем популярнее становится Azure.
Что касается .Net core, то вполне себе норм разрабатывается. Единственное что после перехода на RC2 слетела подсветка студии для кастомных депенденси, но это скоро должны починить.
На линуксе все работает точно также, как не на линуксе :) По крайней мере за ASP.Net Core говорю. То есть достаточно сложный веб-сервер живет и здравствует, причем работает быстрее чем на иисе.
Что касается .Net core, то вполне себе норм разрабатывается. Единственное что после перехода на RC2 слетела подсветка студии для кастомных депенденси, но это скоро должны починить.
На линуксе все работает точно также, как не на линуксе :) По крайней мере за ASP.Net Core говорю. То есть достаточно сложный веб-сервер живет и здравствует, причем работает быстрее чем на иисе.
UFO just landed and posted this here
Что в плюсах медленно?
Все то что делает плюсы плюсами а не надстройкой над Си. Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Но в целом согласен, толстова-то вышло. Rust быстрее плюсов на очень небольшом классе задач, и причем по памяти кушает больше.
UFO just landed and posted this here
Взять к примеру вызовы виртуальных методов, уже неслабый оверхэд.
Там где в плюсах будут нужны виртуальные вызовы в расте будут "трейт-объекты" которые устроены примерно так же.
Про память тоже интересно. Это результат тестов каких-то? Что в расте принципиально больше памяти требует?
Rust все-таки подталкивает не использовать ссылки на трейты слишком часто. А там, где используются объекты известного типа (даже если это типовой параметр) код можно сгенерировать более эффективный.
Ссылки на трейт действительно требуют больше памяти — указатель на vtbl хранится в каждой копии ссылки, а не в самом объекте, как в плюсах.
Ссылки на трейт действительно требуют больше памяти — указатель на vtbl хранится в каждой копии ссылки, а не в самом объекте, как в плюсах.
Когда требуется полиморфизм, на C виртуальный метод вызывают руками точно так же, как это сделал компилятор. Я много работал с кодом ядра FreeBSD и читал код ядра Linux, там таких примеров очень много. Кое что даже компилятор может сделать эффективнее. Хотя как-то столкнулся с интересным примером подмены vtbl у живого объекта — заставить компилятор C++ такое сделать можно только с помощью очень рискованных трюков.
Но шаблоны C++ способны порождать более эффективный код, чем человек напишет руками на C. За счет специализации на этапе компиляции.
Но шаблоны C++ способны порождать более эффективный код, чем человек напишет руками на C. За счет специализации на этапе компиляции.
Насчет лаконичности C# — это такой тонкий троллинг? :)
Какой еще троллинг? Тот же LINQ позволяет в однострочник записать несколько десятков строк, и это будет прозрачно и понятно. Можно конечно и на LINQ наворотить хрень, но основные кейсы обычно покрываются нормальным использованием.
Так речь о лаконичности кода на C#? Не самого языка?
Или таки о лакончности кода на LINQ? ;)
… (мечтательно) А если добавить еще пару десятков ключевых слов и несколько «служебных под-языков», то станет еще лаконичнее!…
Или таки о лакончности кода на LINQ? ;)
… (мечтательно) А если добавить еще пару десятков ключевых слов и несколько «служебных под-языков», то станет еще лаконичнее!…
LINQ можно было и самим написать, ничего сверхъестественного там нет, десяток методов-однострочников. Так что LINQ это именно что средствами самого языка реализованная фишка, никакой не дар свыше и не забитая в платформу гвоздями функциональность, которую кроме МС никто не может себе позволить.
Охотно верю!
…Но факт остается фактом: чтобы добавить поддержку новой возможности/удобства, в язык приходится добавлять новые конструкции. Чтобы добавить сопрограммы — введем новое ключевое слов. Чтобы было удобнее обрабатывать «внешние» данные — добавим еще несколько… да что там мелочиться?! добавим сразу язык… Ну и т.д.: с каждой новой версией язык все пухнет и пухнет. Количество концепций в языке все больше и больше. Сложность все растет и растет… А это сложность, с которой разработчику приходится иметь дело буквально каждую секунду.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Между тем, еще в 60 – 70-е годы показали (Lisp, Simula-67, Smalltalk…), что это можно и нужно делать не в языке (что приводит к взрывному росту сложности), а в «библиотеках» (что позволяет усложнять только там, где нужно, и равно на столько, насколько нужно). Собственно, расширение возможностей системы разработки без усложнения языка и отличает хороший язык от плохого. Прошло 50, даже 60+ (или уже 70?) лет, а мы снова там, где были. Об этом же, как мне видится, и пытается сказать Кэй.
…Но факт остается фактом: чтобы добавить поддержку новой возможности/удобства, в язык приходится добавлять новые конструкции. Чтобы добавить сопрограммы — введем новое ключевое слов. Чтобы было удобнее обрабатывать «внешние» данные — добавим еще несколько… да что там мелочиться?! добавим сразу язык… Ну и т.д.: с каждой новой версией язык все пухнет и пухнет. Количество концепций в языке все больше и больше. Сложность все растет и растет… А это сложность, с которой разработчику приходится иметь дело буквально каждую секунду.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Между тем, еще в 60 – 70-е годы показали (Lisp, Simula-67, Smalltalk…), что это можно и нужно делать не в языке (что приводит к взрывному росту сложности), а в «библиотеках» (что позволяет усложнять только там, где нужно, и равно на столько, насколько нужно). Собственно, расширение возможностей системы разработки без усложнения языка и отличает хороший язык от плохого. Прошло 50, даже 60+ (или уже 70?) лет, а мы снова там, где были. Об этом же, как мне видится, и пытается сказать Кэй.
То что вы предлагаете как раз решается современными средствами типа Rosylin или LLVM — то есть можно вставлять свои промежуточные слои преобразования кода. Просто тут проблема в 15 различных стандартах, когда каждый кто в лес, кто по дрова. Когда есть единый центр выпуска фич, каждую из которых крутят с разных сторон на предмет нужности, это лучший исход, чем когда ты меняешь работу, а там типа такой же язык, но де-факто полная ересь, совершенно не такая, как была на старом месте :)
Брейнфак не меняется с момента создания, наверное это говорит о целостности его идей и его выразительной мощи?:)
Не все изменения языка мне нравятся (например оператор is, с out-параметров выглядит очень не очень), но никто не заставляет использовать ВСЕ возможности. Причем разные возможности рассчитаны на разный стиль программирования, и разный уровень абстракции разработчика. Например pattern match рассчитан на высокоуровневые разработки, активно использующие LINQ и т.п., где лаконичность важнее производительности (каждый раз вызывать делегат вместо простого куска кода это всегда оверхед). А например ref-возвращаемые значения они для низкоуровневых операций, когда нам копирование ссылки капец как портит производительность. Ну и какие-то записи просто упрощают, вроде readonly-свойств или лямбдосвойств. В целом эволюция идет в правильном направлении. Усложняется язык — что поделать, нельзя добавить функцинальность, не добавив её. Главное чтобы она была ортогональна.
Вряд ли это свидетельствует о лаконичности (выразительной мощи) языка и заложенных в нем идей, не находите?
Брейнфак не меняется с момента создания, наверное это говорит о целостности его идей и его выразительной мощи?:)
Не все изменения языка мне нравятся (например оператор is, с out-параметров выглядит очень не очень), но никто не заставляет использовать ВСЕ возможности. Причем разные возможности рассчитаны на разный стиль программирования, и разный уровень абстракции разработчика. Например pattern match рассчитан на высокоуровневые разработки, активно использующие LINQ и т.п., где лаконичность важнее производительности (каждый раз вызывать делегат вместо простого куска кода это всегда оверхед). А например ref-возвращаемые значения они для низкоуровневых операций, когда нам копирование ссылки капец как портит производительность. Ну и какие-то записи просто упрощают, вроде readonly-свойств или лямбдосвойств. В целом эволюция идет в правильном направлении. Усложняется язык — что поделать, нельзя добавить функцинальность, не добавив её. Главное чтобы она была ортогональна.
Fesor, по-моему, неточно выразился в самом начала этого треда: C# — никак не лаконичный язык, но он позволяет (местами) писать лаконичный код (за счёт кучи «сахарка», навроде того же LINQ). А с Вами согласен: если единственный способ сделать что-то выразительным (а не просто выразимым) — расширить сам язык, добавив в него новую сущность, а не написать на уже имеющемся языке библиотеку, то с языком таки что-то не так…
> Статически-типизированные языки кажутся ему неполноценными
Ровно до момента, когда принесут на саппорт крупный проект на «полноценном» языке.
Ровно до момента, когда принесут на саппорт крупный проект на «полноценном» языке.
На Erlang реализованы очень крупные проекты с надежностью в несколько девяток и горячими обновлениями кода.
На Javascript и РНР тоже, что вовсе не значит море удовольствия от поддержки проектов на этих языках. Больше проверок кода, как вручную, так и статическими тулзами.
Посмотрел бы я на ATM Switch, запрограммированный на пхп и js.
На Javascript и РНР тоже
На них просто реализовано много больших проектов, но это не значит что они надежны. А вот Erlang в этом плане оч крутой.
Маленькое уточнение — Erlang язык с сильной динамической системой типов, что уже делает его чуть лучше других (PHP или JS например). То есть никакого жанглирования типами как в PHP. Это только если говорить о системе типов. А так erlang предоставляет много крутых вещей которые повышают надежность систем. Собственно этот язык для надежных систем и предназначался изначально.
Мне всегда казалось, что PHP — это stringly-typed (sic) язык. Поэтому он тут немного не в кассу.
Lisp велик, но писать на нем чудовищно сложно :( Попробую объяснить, что я считаю «мощной структурой»: структура является тем более мощной, чем выше отношения того, сколько слов, не являющихся абстракциями, заложенными в сам ЯП, надо потратить, чтобы объяснить, что она делает и как работает, к количеству самостоятельных строк, нужных, чтобы заставить её работать. Если мысль полная и завершенная, то она выделяется, например, в функцию и объект, который уже может общаться с другими через сообщения.
Языки дают нам ключевые слова, библиотеки — дополнительные типы данных и функции, из них мы делаем прикладные абстракции. Если все средства узкоспециализированы (или привязаны к архитектуре), в языке появляется «ползучий фичеризм», а кодинг становится многословным. Но если ключевых слов мало, то абстракция становится сложной, её сложно держать в голове, а особенно представлять её динамику и наследования. А в Lisp я это делать обязан Хотя, может, я не умею правильно его готовить.
Языки дают нам ключевые слова, библиотеки — дополнительные типы данных и функции, из них мы делаем прикладные абстракции. Если все средства узкоспециализированы (или привязаны к архитектуре), в языке появляется «ползучий фичеризм», а кодинг становится многословным. Но если ключевых слов мало, то абстракция становится сложной, её сложно держать в голове, а особенно представлять её динамику и наследования. А в Lisp я это делать обязан Хотя, может, я не умею правильно его готовить.
Можно не долелывать. Современные версии вполне полноценны без всяких DSL.
Хотелось бы уточнить, что же вы хотели сказать? Должен язык содержать мало «ключевых слов», много их, или «достаточно»?
Не приходила ли мысль о том, что таки язык должен быть как можно проще (соответственно, минимум «ключевых слов») и естественнее (соответственно, ближе к человеку), но позволять расширять сам себя новыми «абстракциями», удобными в использовании. То есть, эти абстракции должны лежать в рамках всего одной концепции, вокруг которой построен язык. Кстати, это как раз описывает (цели) Lisp и Smalltalk. …Другой вопрос, насколько они к этим целям приблизились. Lisp сложно назвать изначально естественным для человека; Smalltalk-таки пожертвовал чистотой в угоду прагматичности… впрочем, современным языкам и до этого далеко.
… И да — никаких DSL здесь не потребуется: все будет в рамках исходного языка.
Не приходила ли мысль о том, что таки язык должен быть как можно проще (соответственно, минимум «ключевых слов») и естественнее (соответственно, ближе к человеку), но позволять расширять сам себя новыми «абстракциями», удобными в использовании. То есть, эти абстракции должны лежать в рамках всего одной концепции, вокруг которой построен язык. Кстати, это как раз описывает (цели) Lisp и Smalltalk. …Другой вопрос, насколько они к этим целям приблизились. Lisp сложно назвать изначально естественным для человека; Smalltalk-таки пожертвовал чистотой в угоду прагматичности… впрочем, современным языкам и до этого далеко.
… И да — никаких DSL здесь не потребуется: все будет в рамках исходного языка.
Сразу оговорюсь, я не люблю писать код и не занимаюсь этим профессионально, отсюда растут мои дилетантские рассуждения о том, какой должен быть язык. И я не знаю, сколько должно быть ключевых слов в самый раз. Расширение внутри одной концепции — это правильно, но с метапрограммированием иногда кажется, что ты играешь в драконий покер. А хороший тон лиспа требует мало слов и много «мета». Конечно, и из него можно сделать бейсик, но при создании языка наверно что-то другое имелось в виду :) Грубо говоря, если следовать советам из книги «Structure and Interpretation of Computer Programs» я должен думать образом, отличным от того, как если бы решал задачу вручную, чтобы раскрыть все возможности лиспа, а мне лень вывихивать мозг.
Код должен быть одновременно близок человеку (чтобы легко читаться и писаться) и машине (чтобы быстро работать). Языковые конструкции не должны сбивать с мысли, когда пытаешься наложить свою модель процесса на средства языка. Для себя я пишу на матлабе (прототипирование или программы на пару запусков) и на С, когда надо пережёвывать много данных. Сравнивая длину кода, служащего одной и той же задаче, матлаб выигрывает в разы: например, я могу к числу относиться как к числу, к матрице — как к матрице, а в сях я должен явно указать, что это за число, и относиться к нему как к ячейке по адресу в памяти. Зато матлаб медленный.
Код должен быть одновременно близок человеку (чтобы легко читаться и писаться) и машине (чтобы быстро работать). Языковые конструкции не должны сбивать с мысли, когда пытаешься наложить свою модель процесса на средства языка. Для себя я пишу на матлабе (прототипирование или программы на пару запусков) и на С, когда надо пережёвывать много данных. Сравнивая длину кода, служащего одной и той же задаче, матлаб выигрывает в разы: например, я могу к числу относиться как к числу, к матрице — как к матрице, а в сях я должен явно указать, что это за число, и относиться к нему как к ячейке по адресу в памяти. Зато матлаб медленный.
Луговский (по-крайне мере образца середину нулевых) одобрительно кивает головой. Помню, как 10 лет назад он был едва ли не единственным адептом мета-программирования, ФП и «правильного» ООП
Виталий все-таки сторонник статической типизации :-).
Если честно не знаю, кто это… Но как «правильное ООП» может уживаться со статической типизацией?!? :)
Не совсем «правильный», но все же ООП есть в хорошо статически типизированных языках OCaml и Scala.
А совсем «правильных» языков, основанных на сообщениях, можно считать что и нет. Ну разве что Erlang, но его недостаточно что бы говорить о невозможности ни чего другого.
А совсем «правильных» языков, основанных на сообщениях, можно считать что и нет. Ну разве что Erlang, но его недостаточно что бы говорить о невозможности ни чего другого.
Совсем правильных языков нет, согласен. Но наиболее близки к ним (из известных мне) Smalltalk и Self. Они очень неплохо для современного уровня отражают «правильный ООП» (по крайней мере, таковой в моем понимании; не уверен, что тут мы говорим об одном и том же). …Может быть еще Newspeak, но он таки имхо не в ту сторону пошел. Про Erlang судить не берусь.
Я поясню, почему у меня вызывает отторжение сочетание «праильного ООП» и статической типизации. Идея ООП состоит в том, чтобы быть как можно проще. Объекты и сообщения — и больше ничего. Статическая типизация сюда явно не вписывается. Динамическая — чуть лучше, в плане того, что это личное дело каждого объекта.
Это, разумеется, не значит, что типизация — это плохо. И у статической есть свои преимущества. Но она не должна быть реализована в языке. Вытащите это (как и многое другое, впрочем) в «библиотеку» и будет (почти) всем (почти) счастье :) Для того же Smalltalk-а это было (даже неоднократно) показано.
Я поясню, почему у меня вызывает отторжение сочетание «праильного ООП» и статической типизации. Идея ООП состоит в том, чтобы быть как можно проще. Объекты и сообщения — и больше ничего. Статическая типизация сюда явно не вписывается. Динамическая — чуть лучше, в плане того, что это личное дело каждого объекта.
Это, разумеется, не значит, что типизация — это плохо. И у статической есть свои преимущества. Но она не должна быть реализована в языке. Вытащите это (как и многое другое, впрочем) в «библиотеку» и будет (почти) всем (почти) счастье :) Для того же Smalltalk-а это было (даже неоднократно) показано.
Но сообщения между собой как-то должны различаться? Что мешает к этому добавить их классификацию по типам, которую можно проверить статически?
Как подсказывает логика и подтверждает практика, добавить можно почти все что угодно почти куда угодно :) Вопрос в другом — зачем? И еще не мешает подумать о том, к чему это приведет… Собственно, я свою мысль уже изложил, но, видимо, плохо. При этом что именно вас смущает — мне не ясно. Поэтому для продолжения диалога, наверное, надо как-то уточнить, в чем именно загвоздка.
Для меня статическая тимизация — это способ задать ограничения на программы, которые бы с одной стороны позволяли компилятору создавать более эффективный код, а с другой — обнаруживали бы часть ошибок на этапе компиляции, которые бы иначе возникли бы во время исполнения.
Эти ограничения как минимум, заменяют часть тестов. То есть усложняют язык не более, чем использование тестового фреймвока.
То есть тип переменной — это более простой способ написать assert, проверяющий ее принадлежность к этому типу и срабатывающий заранее.
Эти ограничения как минимум, заменяют часть тестов. То есть усложняют язык не более, чем использование тестового фреймвока.
То есть тип переменной — это более простой способ написать assert, проверяющий ее принадлежность к этому типу и срабатывающий заранее.
Справедливости ради, 100% покрытие кода тестами не гарантирует отлов 100% ошибок. Есть проекты на динамических языках программирования (к примеру команда Doctrine) в которых разработчики делились информацией, что в проекте с 100% покрытием кода тестами и проведением мутационного тестирования добавление информации о типах позволило выявить новые проблемы.
Но это мы говорим о языке со слабой динамической типизацией. Чуваки из Python или Ruby сообщества больше переживают из-за оверюза (именно оверюза) возможностей манкипатчинга нежели системы типов их языка.
Вот это действительно интересно! Какие были обнаружены проблемы при 100% покрытии тестами? Где об этом почитать? Навскидку нагуглить не удалось.
Это было на реддите где-то с пару месяцев назад. Я сейчас затрудняюсь найти дискуссию… Можно вот у этого человека спросить: https://github.com/Ocramius
Типы в языке — лишняя сущность. Язык сложнее.
Типы обязательны — лишние действия при объявлении переменных/методов. Писать код сложнее.
Чтобы код запустить на выполнение нужно обеспечить совместимость типов, даже если мне в данный момент это не нужно. Исследовать/разрабатывать сложнее.
…
Типы обязательны — лишние действия при объявлении переменных/методов. Писать код сложнее.
Чтобы код запустить на выполнение нужно обеспечить совместимость типов, даже если мне в данный момент это не нужно. Исследовать/разрабатывать сложнее.
…
имена переменных в языке — лишняя сущность.
ограниченное количество ключевых слов — лишняя сущность.
Похоже вы гений, который всегда с 1 раза пишет правильно все модули системы и никогда не пользуется кнопочкой debug.
ограниченное количество ключевых слов — лишняя сущность.
Похоже вы гений, который всегда с 1 раза пишет правильно все модули системы и никогда не пользуется кнопочкой debug.
Если язык функциональный, то имена переменных — лишняя сущность. Функциональщики лучше объяснят. А если объектный, то объявление переменных — лишний синтаксис. Достаточно иметь объект-контекст с методом добавления в него переменных.
Ключевые слова… не знаю, можно ли обойтись без них, но ясно, что их должно быть как можно меньше. В том же Smalltalk-е их всего ничего: self, super, nil, true, false, thisContext. Да и они, в общем-то необязательны — так, сахарок. Есть правда еще куча другого синтаксиса… Впрочем, «куча» — очень относительно. По сравнению с C# его почти и нет :) Но все равно — слишком много, язык далек от совершенства… Не буду развивать мысль, рановато пока.
P.S.: Предлагаю не переходить на личности. Вы меня совершенно не знаете. И то, что вы, судя по вашим комментариям, пока не понимаете то, что я стараюсь сказать, не дает повода пытаться меня задеть ;)
Ключевые слова… не знаю, можно ли обойтись без них, но ясно, что их должно быть как можно меньше. В том же Smalltalk-е их всего ничего: self, super, nil, true, false, thisContext. Да и они, в общем-то необязательны — так, сахарок. Есть правда еще куча другого синтаксиса… Впрочем, «куча» — очень относительно. По сравнению с C# его почти и нет :) Но все равно — слишком много, язык далек от совершенства… Не буду развивать мысль, рановато пока.
P.S.: Предлагаю не переходить на личности. Вы меня совершенно не знаете. И то, что вы, судя по вашим комментариям, пока не понимаете то, что я стараюсь сказать, не дает повода пытаться меня задеть ;)
Я? Задеть? Я наоборот, восхищен вами!
Лично я, как и мои коллеги на работе, умудряются в статически типизируемых языках находить ошибки, а вы в динамике умудряетесь такие подвиги совершать. По мне так это достойно всяческой похвалы. В жизни я таких людей не встречал, так что это очень большая редкость и радость видеть Вас наяву.
Лично я, как и мои коллеги на работе, умудряются в статически типизируемых языках находить ошибки, а вы в динамике умудряетесь такие подвиги совершать. По мне так это достойно всяческой похвалы. В жизни я таких людей не встречал, так что это очень большая редкость и радость видеть Вас наяву.
У меня вдруг родилась формула:
1. Статическая типизация нужна для оптимизации
// по производительности кода
// по проверке его правильности
// (еще почему-то не упоминали, вроде) по проведению рефакторинга…
2. «Преждевременная оптимизация — корень всех зол» (Д. Кнут или кто-то еще)
1. Статическая типизация нужна для оптимизации
// по производительности кода
// по проверке его правильности
// (еще почему-то не упоминали, вроде) по проведению рефакторинга…
2. «Преждевременная оптимизация — корень всех зол» (Д. Кнут или кто-то еще)
Интернет никогда не отключался? Да ладно!
Он просто состоит из множества реально независимых частей, которые сами по себе отключатся регулярно, просто они друг другу не нужны. В том числе — отключаются по вполне себе внутренним причинам.
Весь интернет никогда не отключался. Отключались датацентры. Но если повредился один из маршрутов система адаптируется.
Видите ли, в же стиле можно сфорулировать любую чушь.
Интернет — в том смысле, который ему придает сам автор цитаты, т.е. софт TCP/IP, еще как отключается. Позвольте мне не давать вам ссылки на множественные уязвимости серверов любого рода, которые позволяют их легко уронить? Да, система адаптируется, и сильно. Но тем не менее любой из нужных именно вам ресурсов в любой момент может быть недоступен. А то что мы видим — лишь результат дублирования.
Если угодно — общая конструкция интернета, как фиговины состоящей из большого числа независимых частей — она да, устойчивая. Но протоколы, которые в нее входят, и отдельные узлы — совсем нет.
Не понял, как протокол является примером софта?
Отличный вопрос! Прекрасно показывает как мы сегодня все это (неправильно) понимаем. Типа, софт — это код.
Речь, как мне видится, идет о построении сложных систем. Код на языке — это лишь способ связать компоненты этой системы между собой, дать им возможность общаться. В этом смысле протокол — как раз способ общения, то есть полный аналог языка. В случае с инетом удалось каким-то волшебным способом построить сверх-сложную систему, сделать ее саморегулируемой… и при этом относительно простыми средствами.
Речь, как мне видится, идет о построении сложных систем. Код на языке — это лишь способ связать компоненты этой системы между собой, дать им возможность общаться. В этом смысле протокол — как раз способ общения, то есть полный аналог языка. В случае с инетом удалось каким-то волшебным способом построить сверх-сложную систему, сделать ее саморегулируемой… и при этом относительно простыми средствами.
Alan Kay — действительно гениальный инженер, один из немногих такого уровня. И на мой взгляд немалая заслуга его гениальности в широком американском образовании, когда вы можете сразу по нескольким направлениям получить научную степень бакалавра. В его случае это были математика и биология. У нас, увы, такое невозможно. Даже внутри одного вуза, например, в нашем СПбГУ очень мало взаимодействия между факультетами и огромный снобизм у представителей разных наук по отношению друг к другу.
Забавный бред для человека, вышедшего из прошлого века. Жаль, что он вообще не понимает, насколько ИТ изменился — насколько стал сложным, дорогим и ответственным. Время хакеров-одиночек прошло, время бредовых языков — тоже (включая ЛИСП, Рефал, Брэйнфак и прочую ересь). Сейчас есть «мэйнстрим» и «хобби» и Алан так и остался в мире «хобби». А большинство прогеров работают в мэйнстриме, где нет места «сейчас, я только побырому интерпретатор напишу!». Динамические языки тоже показали свою несостоятельность — взлетели на волне хтмл-страничек и домашних перделок, но дальше — ни ногой. Так что спасибо, Алан, за интересные истории, но советы я спрошу у кого-нибудь другого. Например, у Уолтера Брайта.
Питон популярен вообще. И анализ данный сейчас стал очень популярен.
Не удивительно, что многие питонисты занимаются данными, а многие специалисты по данным используют питон. Это не говорит о том, что питон как-то особенно хорош в этой области.
Не удивительно, что многие питонисты занимаются данными, а многие специалисты по данным используют питон. Это не говорит о том, что питон как-то особенно хорош в этой области.
Python имеет проблемы с рождения, но он действительно хорош и уже достаточно зрелый, поэтому он в последнее время становится так популярен не только в web-разработке. Ruby, например, остался популярен практически всецело в web и, по большей части, благодаря Rails. Python же и его экосистема сейчас активно продвигается как удобный инструмент для учёных и инженеров не только в области data mining. Я думаю, в ближайшем будущем Python со стеком библиотек, вроде scipy, vispy и т. п. серьёзно потеснит Matlab и прочие инженерные и научные пакеты. Даже сейчас, например, Python-дистрибутив «Anaconda» от Continuum Analytics и среды разработки, вроде Spyder или rodeo заменяют базовую функциональность Matlab и его основные тулбоксы. Добавьте к этому то, что Python-код зачастую является production-ready, в отличии от всяких matlab/mathematica.
Ну вы ещё опрос похапэшников приведите! *смайл «пацталом»*
Что он должен доказывать? Что бросаем всё и бежим учить Лисп? Писать биллинг на Смоллтоке? Закладывать таймбомбы поздним связыванием?
Вы пропускаете ключевые слова, смысл которых очень важен: мэйнстрим, предсказуемость, сопровождаемость, надёжность. И всё это вообще не про Питон! Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости. Поэтому когда «отцы ИТ» (а по-хорошему, сильно постаревшие мальчишки-хакеры из 50-ых) начинают развозить в воздухе «вы должны...», становится смешно. Особенно про ЛИСП.
Что он должен доказывать? Что бросаем всё и бежим учить Лисп? Писать биллинг на Смоллтоке? Закладывать таймбомбы поздним связыванием?
Вы пропускаете ключевые слова, смысл которых очень важен: мэйнстрим, предсказуемость, сопровождаемость, надёжность. И всё это вообще не про Питон! Динамические языки в серьёзном мэйнстриме несостоятельны уже в силу полной непредсказуемости. Поэтому когда «отцы ИТ» (а по-хорошему, сильно постаревшие мальчишки-хакеры из 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++.
А что плохого в позднем связывнии? Отличная же концепция, если язык еще и предоставляет удобные инструменты для реализации (скажем виртуальные функции), то совсем хорошо
"… но в песне ты не понял, увы, …ничего!" (с) Шевчук ;)
>> время бредовых языков — тоже (включая ЛИСП, Рефал, Брэйнфак и прочую ересь)
Вот жесть. Вы, пардон, по какому принципу составили этот список?
Вот жесть. Вы, пардон, по какому принципу составили этот список?
Вы, пардон, слово «мэйнстрим» пропустили?
В 70-е годы тоже был мэйнстрим — компьютеры размером с квартиру. И было хобби — маленькие такие смешные компьюшки, собранные любителями в гаражах. И вот, судя по всему, похожие на вас ребята сидели в дорогих креслах в шикарных кабинетах и с такой же снисходительной издевкой объясняли, что на этом бизнес не построить, денег не заработать, и вообще они «пацталом» от этих несерьезных волосатых детишек в джинсах… Надеюсь, понятно, что отматывать подобные истории можно долго и на много-много лет (веков) назад? Оцените свою роль в истории ;)
Не соглашусь с Вами, в частности про бредовые языки. Мне кажется, что прочесть хотя бы getting started по таким языкам нужно для того, чтобы потом не говорить «А что, так можно было?!». В коде мы излагаем своё представление об объекте управления, и разные вещи удобнее выражать с помощью разных парадигм. Я не верю, просто на эмоциях, в применимость «чистых», однопарадигменных языком, но считаю, что использовать «чистые» парадигмы удобно. Я видел код на плюсах, в котором одним программистом в разных кусках применялись ФП, ООП, аспектно-ориентированное программирование и С с классами. Было понятно и, чёрт возьми, красиво!
Мы не говорим про студентов, которым как любопытной Варваре — интересно всё подряд — я уже этот этап прошёл. Я про коммерческую разработку, где «серьёзные дяди» платят большие деньги и хотят предсказуемый результат. И извините, я никогда не выйду к ним с языками типа Пестона, Сипипи или Раста. Или того хуже — ЛИСП.
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ. Так вот: на _сегодня_ Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны. Никому не нужны макросы или «живой бардак» типа Смоллтока — нужны простые, надёжные решения — это моя ежедневная работа. И уверяю, без ЛИСПа можно вполне хорошо писать системы — есть хорошие языки типа C#, D, Java, код которых можно СОПРОВОЖДАТЬ. В случае ЛИСП — увы, это write-only язык и его незнание ну вообще никак не влияет на ваш профессионализм.
Наверное, имеет смысл ещё раз обратить внимание читающей публики на два ключевых слова: ХОББИ и КОММЕРЦИЯ. Так вот: на _сегодня_ Алан говорит языком «хобби» — рассуждает о вещах, которые в КОММЕРЦИИ просто смехотворны. Никому не нужны макросы или «живой бардак» типа Смоллтока — нужны простые, надёжные решения — это моя ежедневная работа. И уверяю, без ЛИСПа можно вполне хорошо писать системы — есть хорошие языки типа C#, D, Java, код которых можно СОПРОВОЖДАТЬ. В случае ЛИСП — увы, это write-only язык и его незнание ну вообще никак не влияет на ваш профессионализм.
Спасибо вам за подтверждение моего тезиса, что именно «обизнесовывание» убивает всякое развитие, в частности в IT! Давно хотелось услышать подтверждение из первых уст. Буду на вас ссылаться, вы не против?
где «серьёзные дяди» платят большие деньги и хотят предсказуемый результат.
А получают гору легаси на 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
Ну а что Вы хотели услышать от одного из апологетов 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.» после которого писанину этого «взрослого» вообще можно не читать…
P.S. «So says this old C++ programmer.» Вот что меня убивает, что сравнивают как всегда с С++ и его потомками. Ну покажите деду хоть Аду что-ли или Модулу-3. Хотя там в середине есть пассаж «Pascal, I felt, was a language for babies.» после которого писанину этого «взрослого» вообще можно не читать…
Вот сидите вы в своём энтерпрайзе глухо, десятками лет оттачиваете навыки джавы/шарпов, ходите на конференции, разрабатываете серьёзные системы и считаете, что всё так и будет и дальше, куда может деться спокойное энтерпрайзное программирование? 50 лет стояло — ещё 50 простоит.
Но я уверен, что беда придёт откуда не ждали. Функциональное программирование медленно, но верно просачивается всюду, пускает свои ростки. Вы смотрите, уже и в джаве наступает время конкурентности, а не параллельности. И лямбды, мапы, фильтры и, страшно подумать… свёртки списков!
Сейчас оно проникнет в мейнстрим и люди начнут массово мыслить «функционально».
И тут всплывёт вопрос типизации. Вот вы говорите, что язык должен быть статически типизирован. Что если я скажу вам, что с моей точки зрения типизация джавы — какое-то ребячество, позволяющее только отличить строку от числа?
Полиморфная типизация уступает зависимой в бесконечность раз. Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются и пока выглядят очень плохо и хило. Но есть ребята, которые двигают HoTT и в процессе формализации HoTT в HoTT получат нечто божественное.
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации, и как бонус — в нём нет ни одной излишней динамической проверки и он работает быстрее любого си-кода, который написан человеком.
И тогда будет лишь два вида разработки — «серьёзная», где требуется надёжность. И «несерьёзная» — где можно тяп-ляп и на динамическом ЯП быстро заставить машину сделать чего нужно.
Языки «среднего класса» умрут.
Но я уверен, что беда придёт откуда не ждали. Функциональное программирование медленно, но верно просачивается всюду, пускает свои ростки. Вы смотрите, уже и в джаве наступает время конкурентности, а не параллельности. И лямбды, мапы, фильтры и, страшно подумать… свёртки списков!
Сейчас оно проникнет в мейнстрим и люди начнут массово мыслить «функционально».
И тут всплывёт вопрос типизации. Вот вы говорите, что язык должен быть статически типизирован. Что если я скажу вам, что с моей точки зрения типизация джавы — какое-то ребячество, позволяющее только отличить строку от числа?
Полиморфная типизация уступает зависимой в бесконечность раз. Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются и пока выглядят очень плохо и хило. Но есть ребята, которые двигают HoTT и в процессе формализации HoTT в HoTT получат нечто божественное.
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации, и как бонус — в нём нет ни одной излишней динамической проверки и он работает быстрее любого си-кода, который написан человеком.
И тогда будет лишь два вида разработки — «серьёзная», где требуется надёжность. И «несерьёзная» — где можно тяп-ляп и на динамическом ЯП быстро заставить машину сделать чего нужно.
Языки «среднего класса» умрут.
Ну вот тем и отличаются люди-практики от Аланокеев — одни живут сегодня и кормят семью, а другие теоретизируют на кафедрах за 20 тыщ рублей и кормят мир светлым будущим.
Дело не только в интыпрайзе, но в самой сути людей: ОЧЕНЬ сложно просто взять ЛИСПовский код и за минуту объяснить, что он делает. Люди ограничены, даже если имеют за плечами десятки языков (я лично писал на более, чем 20-ти). Поэтому я уверен, «простота и мощь» была и будет главным девизом ИТ, а его применимость к интыпрайзу — лишь приятный бонус.
ФП? Не смешите мой дисковод! За те годы, что о нём знают, он давно вылез бы в топы, если бы не был таким кривомысленным, ортогональным нормальному человеческому мышлению. То, что какой-нть C# позаимствовал лямбды, НИЧЕГО не говорит в пользу ФП. Посмотрите на это так: была функция сортировки с захардкоженным сравнением a < b. Функцию расширили (каким угодно механизмом) и теперь сравнивать можно любым переданным методом — ПРИЧЁМ ТУТ ФП ВООБЩЕ? Это просто кастомизация функции сравнения, она вообще могла быть передана как в Ди — СТРОКОЙ. Это говорит о том, что ваше видение ФП идолизировано до того, что вы не отличаете парадигму от заимствований отдельных плюшек и где слышите «функция», сразу думаете о ФП. Функции были всегда, даже в ассемблере, но никто и никогда не выпячивал их как достоинство ФП парадигмы.
> Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются… А затем окажется… И тогда будет…
Не многовато будущих времён? :) (см. первое предложение) Даже в обозримом будущем (лет так на 20) вполне видно, что ФП — не у дел, Лигическое п-е — на задворках кафедр, ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным — потому что это близко человеку — разбирать на составляющие и собирать вновь. Из ближайших перспектив — метапрограммирование, но не в диком смысле ЛИСПа, а в стиле Немерле. Это лучшее, что может произойти с программингом в ближайшие годы.
> Языки «среднего класса» умрут.
:) Спасибо, этим вечером сильно нехватало улыбки! Вы лучший.
Дело не только в интыпрайзе, но в самой сути людей: ОЧЕНЬ сложно просто взять ЛИСПовский код и за минуту объяснить, что он делает. Люди ограничены, даже если имеют за плечами десятки языков (я лично писал на более, чем 20-ти). Поэтому я уверен, «простота и мощь» была и будет главным девизом ИТ, а его применимость к интыпрайзу — лишь приятный бонус.
ФП? Не смешите мой дисковод! За те годы, что о нём знают, он давно вылез бы в топы, если бы не был таким кривомысленным, ортогональным нормальному человеческому мышлению. То, что какой-нть C# позаимствовал лямбды, НИЧЕГО не говорит в пользу ФП. Посмотрите на это так: была функция сортировки с захардкоженным сравнением a < b. Функцию расширили (каким угодно механизмом) и теперь сравнивать можно любым переданным методом — ПРИЧЁМ ТУТ ФП ВООБЩЕ? Это просто кастомизация функции сравнения, она вообще могла быть передана как в Ди — СТРОКОЙ. Это говорит о том, что ваше видение ФП идолизировано до того, что вы не отличаете парадигму от заимствований отдельных плюшек и где слышите «функция», сразу думаете о ФП. Функции были всегда, даже в ассемблере, но никто и никогда не выпячивал их как достоинство ФП парадигмы.
> Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются… А затем окажется… И тогда будет…
Не многовато будущих времён? :) (см. первое предложение) Даже в обозримом будущем (лет так на 20) вполне видно, что ФП — не у дел, Лигическое п-е — на задворках кафедр, ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным — потому что это близко человеку — разбирать на составляющие и собирать вновь. Из ближайших перспектив — метапрограммирование, но не в диком смысле ЛИСПа, а в стиле Немерле. Это лучшее, что может произойти с программингом в ближайшие годы.
> Языки «среднего класса» умрут.
:) Спасибо, этим вечером сильно нехватало улыбки! Вы лучший.
По ФП согласен. Вы там важную вещицу упомянули. Очень часто, когда рассуждают, почему ФП не взлетел, начинают ругать Иоганн «нашего» фон Неймана за его богомерзкую архитектуру. Но ведь не только машины (что вторично на самом дело), но и, самое главное, люди мыслят всё-таки преимущественно «императивно». Собственно, машины мы потому такими и построили. Алгоритмическое мышление у большинства особей Homo sapiens ограничено набором инструкций, описывающих порядок действий, и только лишь «издевательство» годами матана способно заставит редких индивидов «думать» алгоритмы в терминах аплликаций функций.
Ну вот тем и отличаются люди-практики от Аланокеев
То есть вы даже на секунду не можете прожить без идолов? Ну хорошо, продолжайте фапать на аланокеев.
По картинке: Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
По картинке: Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
Давайте так. Коль уж отказываться от идолов и убеждений, так с обоих сторон переговоров. А то так не конструктивно выходит.
Давайте взгянем на web приложение на lisp. Что-нибудь простенькое, минималистичный клон твиттера: http://eudoxia.me/lucerne/docs/example--a-twitter-clone.html
Вы хотите сказать что код не читаем? Или что его дорого поддерживать потому что язык плохой? Давайте уж на чистоту, CommonLisp в web разработке не применяется потому что есть другие более популярные языки, с большим количеством разработчиков и большим количеством готовых решений. Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны, поскольку это сокращает расходы на разработку, я думаю вы не будете спорить в этом.
Но говорить что сам по себе Lisp разработан теоретиками и никто его не юзает потому что он именно такой — это лишь говорит о том что вы понятия не имеете что такое Lisp.
Идем дальше.
вот мне нравится у людей периодически спрашивать как отличить ОО код от не ОО кода. К примеру, я, как похапэшник, имею дело с такой ORM как Doctrine, которая предоставляет возможность делать сущности как обычный объекты, и мэпит их на базу. Подавляющее большинство делает эти объекты как анемичную модель, то есть куча пропертей, геттеры и сеттеры. Я думаю вы видели подобные вещи.
И в итоге мы имеем: объект хранящий состояние, и объект сервисного слоя, который это состояние меняет. Состояние отдельно, поведение которое меняет состояние — отдельно. Вроде бы у нас и объекты есть, и наследование с полиморфизмом имеются, но отсутствует инкапсуляция и мы имеем дело лишь с состоянием (один объект) и процедурами (методы другого stateless объекта).
То есть если мы вдруг захотим добавить в сущности новое поле с датой изменения, или механизм ревизий изменений, то мы не сможем это сделать красиво и быстро прямо в сущности, так как логика изменения состояния вынесена в другой объект. У нас нарушена инкапсуляция. И по итогу вместо красивого и понятного ООП с инкапсуляцией, возможностью делать декомпозицию системы, изолировать состояние и побочные эффекты, мы имеем старый добрый процедурный код с классами.
Ох, а еще веселье когда народ начинает просто так использовать сингелтоны как глобальное состояние. Встречался мне проектик под iOS, где ребята вынесли состояние в сингелтон с сотней пропертей, и мутировали его в куче разных методов разных объектов разбросанных по всей системе.
Или когда народу дико хочется заиметь множественное наследование (которое к чертям ломает полиморфизм в большинстве юзкейсов ради которого его хотят ввести), просто что бы было удобнее комбинировать процедурки по классам.
Смоллтоки и ЛИСПы — это как раз предложение заменить круглые колёса треугольными черепами.
Давайте взгянем на web приложение на lisp. Что-нибудь простенькое, минималистичный клон твиттера: http://eudoxia.me/lucerne/docs/example--a-twitter-clone.html
Вы хотите сказать что код не читаем? Или что его дорого поддерживать потому что язык плохой? Давайте уж на чистоту, CommonLisp в web разработке не применяется потому что есть другие более популярные языки, с большим количеством разработчиков и большим количеством готовых решений. Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны, поскольку это сокращает расходы на разработку, я думаю вы не будете спорить в этом.
Но говорить что сам по себе Lisp разработан теоретиками и никто его не юзает потому что он именно такой — это лишь говорит о том что вы понятия не имеете что такое Lisp.
Идем дальше.
ООП — рулит. Даже если ООП морфирует от «наследования-полиморфизма» в сторону Смоллтока, оно всё ещё останется объектным
вот мне нравится у людей периодически спрашивать как отличить ОО код от не ОО кода. К примеру, я, как похапэшник, имею дело с такой ORM как Doctrine, которая предоставляет возможность делать сущности как обычный объекты, и мэпит их на базу. Подавляющее большинство делает эти объекты как анемичную модель, то есть куча пропертей, геттеры и сеттеры. Я думаю вы видели подобные вещи.
И в итоге мы имеем: объект хранящий состояние, и объект сервисного слоя, который это состояние меняет. Состояние отдельно, поведение которое меняет состояние — отдельно. Вроде бы у нас и объекты есть, и наследование с полиморфизмом имеются, но отсутствует инкапсуляция и мы имеем дело лишь с состоянием (один объект) и процедурами (методы другого stateless объекта).
То есть если мы вдруг захотим добавить в сущности новое поле с датой изменения, или механизм ревизий изменений, то мы не сможем это сделать красиво и быстро прямо в сущности, так как логика изменения состояния вынесена в другой объект. У нас нарушена инкапсуляция. И по итогу вместо красивого и понятного ООП с инкапсуляцией, возможностью делать декомпозицию системы, изолировать состояние и побочные эффекты, мы имеем старый добрый процедурный код с классами.
Ох, а еще веселье когда народ начинает просто так использовать сингелтоны как глобальное состояние. Встречался мне проектик под iOS, где ребята вынесли состояние в сингелтон с сотней пропертей, и мутировали его в куче разных методов разных объектов разбросанных по всей системе.
Или когда народу дико хочется заиметь множественное наследование (которое к чертям ломает полиморфизм в большинстве юзкейсов ради которого его хотят ввести), просто что бы было удобнее комбинировать процедурки по классам.
> Вы хотите сказать что код не читаем?
ОН УЖАСЕН. Вместо красивых, чистых конструкций — лапша из скобок, выворачивающая наизнанку мышление. Каждая строчка заставляет прищуриваться на минуту, чтобы отыскать что и зачем делается. Это не код, это «машинопись» — коды, хорошо понятные компу, но выбешивающие людей.
> Или что его дорого поддерживать потому что язык плохой?
Тут главное — правильно определить слово «плохой». Он плохой в смысле поддерживаемости, понимаемости, реюзабельности. Но он «хороший» в плане динамики — можно хоть чёрта лысого сгенерить и это будет работающая программа! Только оно надо?
> CommonLisp в web разработке не применяется потому что…
… потому что это самый отвратительный язык для мэйнстрима — см. «поддерживаемость».
> Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны
Тогда с чем вы спорите? Я и смотрю именно на бизнес! Какой смысл разбирать «хобби»? Для себя можно и на Рефале гонять, тут вообще никакие критерии неприменимы! Вот поэтому вы говорите глупость, когда приравниваете Алана к «профи» (в совр. смысле). Да, чувак занимался наукой, что-то наизобретал, но сегодня «Лисп» и «профи» — несовместимые вещи. Языки, созданные в научном угаре, больше не являются «жемчужинами ИТ» — они «забавная пыль истории».
Я даже сам к какой-то игрухе писал на Лиспе обработчики и это занятие заслуживает единственное слово — «прикольно!». Только вот оно нифига не прикольно, когда надо писать надёжный код и «уже вчера». Так что я согласен с вами — Лисп занятный язык, он ЛУЧШЕ большинства языков по своим возможностям, но именно эти возможности и есть «игра с порохом» — ну его нафик!
ОН УЖАСЕН. Вместо красивых, чистых конструкций — лапша из скобок, выворачивающая наизнанку мышление. Каждая строчка заставляет прищуриваться на минуту, чтобы отыскать что и зачем делается. Это не код, это «машинопись» — коды, хорошо понятные компу, но выбешивающие людей.
> Или что его дорого поддерживать потому что язык плохой?
Тут главное — правильно определить слово «плохой». Он плохой в смысле поддерживаемости, понимаемости, реюзабельности. Но он «хороший» в плане динамики — можно хоть чёрта лысого сгенерить и это будет работающая программа! Только оно надо?
> CommonLisp в web разработке не применяется потому что…
… потому что это самый отвратительный язык для мэйнстрима — см. «поддерживаемость».
> Все, на этом преимущества заканчивают. Для бизнеса эти преимущества важны
Тогда с чем вы спорите? Я и смотрю именно на бизнес! Какой смысл разбирать «хобби»? Для себя можно и на Рефале гонять, тут вообще никакие критерии неприменимы! Вот поэтому вы говорите глупость, когда приравниваете Алана к «профи» (в совр. смысле). Да, чувак занимался наукой, что-то наизобретал, но сегодня «Лисп» и «профи» — несовместимые вещи. Языки, созданные в научном угаре, больше не являются «жемчужинами ИТ» — они «забавная пыль истории».
Я даже сам к какой-то игрухе писал на Лиспе обработчики и это занятие заслуживает единственное слово — «прикольно!». Только вот оно нифига не прикольно, когда надо писать надёжный код и «уже вчера». Так что я согласен с вами — Лисп занятный язык, он ЛУЧШЕ большинства языков по своим возможностям, но именно эти возможности и есть «игра с порохом» — ну его нафик!
А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации
А как быть с побочными эффектами? Извините за глупые вопросы.
Функция с побочными эффектами это функция, принимающая значение состояния нашей Вселенной и возвращающая некий результат, плюс новое состояние Вселенной.
Доказывать то, что некие данные появились из I/O, а не от балды легко — ввести типов вроде IsStringFromStdin, значения которых будут возвращаться только из встроенных функций для работы с I/O. С гарантиями записи так же.
В итоге программа будет являться отображением Вселенной во Вселенную, плюс кучей типов вроде ВЭтойВселеннойБылОткрытПорт(80) и ДляПотокаБайтБылИспользованПарсер(html), ЕслиОткрывалиФайлПоЗапросуАЕгоНетВернулиHTTP404 и так далее (хотя я на самом деле этого не представляю, никто в жизни не сможет формально описать программу целиком, только её основные части).
Входящие данные обрабатываются так же как и обычно. Просто функция сравнения, например, возвращает не Boolean, а тип-сумму из доказательства или опровержения равенства. А дальше обычный switch и две ветки исполнения.
Доказывать то, что некие данные появились из I/O, а не от балды легко — ввести типов вроде IsStringFromStdin, значения которых будут возвращаться только из встроенных функций для работы с I/O. С гарантиями записи так же.
В итоге программа будет являться отображением Вселенной во Вселенную, плюс кучей типов вроде ВЭтойВселеннойБылОткрытПорт(80) и ДляПотокаБайтБылИспользованПарсер(html), ЕслиОткрывалиФайлПоЗапросуАЕгоНетВернулиHTTP404 и так далее (хотя я на самом деле этого не представляю, никто в жизни не сможет формально описать программу целиком, только её основные части).
Входящие данные обрабатываются так же как и обычно. Просто функция сравнения, например, возвращает не Boolean, а тип-сумму из доказательства или опровержения равенства. А дальше обычный switch и две ветки исполнения.
Какой мощный, но примитивный вброс! Я даже не знаю, за кого мне больше стыдно — за Вас или за целую ветку из комментаторов. Я обычно игнорирую подобное, но здесь не удержался.
Sign up to leave a comment.
Алан Кэй, создатель ООП, про разработку, Лисп и ООП