alf
то есть Пайк долго и поверхностно рассказывает что дизайн языка и имплементация языка — это сложно. И это правда, несомненно, но это такая же правда как то что вода мокрая, а снег белый. ‎- alf
Интересна и красива мысль про то что все языки становятся одинаковыми. ‎- alf
map/flter — тут он меня потерял. Во-первых, я не верю что более выразительный язык скомпилируется в более дорогой код: это очень сильное утверждение, и хотелось бы подтвердить его чем-то кроме несомненного авторитета. ‎- alf
подождите, был же только что тред. а, вот он https://mokum.place/achteranker/98796 ‎- operazioni di FAP
При этом правда и то что, эммм, ну возьмём монады и DSL-и, скажем,— это тихий гроб, потому что даже опытные программисты садятся и неделями изучают систему типов вокруг или DSL вместо того чтобы накидать менее компактный, но замечательно работающий код за пару часов. ‎- alf
^^ да, это по следам. Я не готов пока обсуждать это с настоящими сварщиками, мне бы свои мысли собрать :) ‎- alf
При этом все эти страшные способы писать код и правда дают огромный бонус к тому как ты *думаешь* о проблеме. Это ужасная банальность, я знаю, но у меня пока ощущение такое что хорошо бы писать для себя на хаскеле, а продакшн код — наджави. Волшебная чалма, как водится, не работает без сковородки. ‎- alf
Очень согласен, хотя и почему-то не ожидал такой точки зрения от Альфа. ‎- Все собаки попадают в рай
имхо, плохо это совмещается. майндсет переключился на другой набор идиом, и столкновение с джавкой будет сопровождаться болью. :) ‎- BSOD bluez
^программисту боль, а продукту польза! ‎- сосиски супремасиски
ага, работа тем отличается от хобби, что не приносит удовольствия :) ‎- BSOD bluez
Совмещается ок, подлец человек ко всему привыкает. ‎- alf
Но что именно такое в джаве даёт такой бонус? Рома Елизаров говорил, что джава хороша тем что один сеньор может подчищать код за десятью джуниорами. ‎- alf
То есть мы имеем (1) "общепринятый" "хороший" стиль и (2) возможность "легко" и быстро (as in ~10% от времени, потраченного на написание) привести код, который делает что-то к этому стилю. ‎- alf
Это же нам продают в Go, кстати. Это же нам продавали в питоне (кстати, питон ещё лучше джавы, но есть нюансы). ‎- alf
(1) в джаве берётся в основном из-за изолированности коммьюнити: считается хорошим тоном писать на чистой джавке. В результате есть очень, очень много кода, на который можно посмотреть, и он более или менее одинаковый, потому что в детстве (когда нарабатывался весь этот корпус) язык не был сложным. ‎- alf
(2) берётся из инструментов: в подавляющем большинстве случаев в джавном коде нет никакой магии вообще. В принципе, можно написать что-то магическое, но до Java 8 это было таким адом, что авторы сдавались ещё на подходах. ‎- alf
Удивительно, кстати, что AOP практически не прижился, оставшись вспомогательной технологией. ‎- alf
Но вот тут коллеги напомнили про слово Composability, а меня мучает то что Rx безумно прекрасен и позволяет описывать суть процесса, а не детали реализации. ‎- alf
И тут два мира встречаются: с одной стороны, когда я смотрю на код, я хочу видеть что он делает, без какой-либо магии. С другой стороны, я точно так же хочу видеть, что автор имел в виду. ‎- alf
Вот мы видим как бы противоречие: хочется, чтобы код был прямолинейным, без магии, но при этом выразительным, без ощутимого boilerplate. Есть языки, которые вторым пренебрегают в погоне за первым. Тогда начинает разрастаться архитектурная астронавтика: выразить сложное как-то надо, но готовых средств для этого, и средств для внятного создания таких средств, нет. Возникают AbstractInterfaceFacadeFactoryFactory и подобное; не от хорошей жизни. Или (как в случае #golang) возникают приведения типов на каждый чих и фактически области кода с динамической типизацией внутри, поскольку статическая слишком невыразительна. Ну или возникает бесхитростное copy-paste programming. Все три несут печаль, баги и потерянное время. ‎- 9000
Магия плоха, понятно, непредсказуемостью и непрозрачностью. Для этого не надо продвинутых фич, позволяющих менять синтаксис, как в плюсах или руби. Простой сишный набор из нескольких слоёв #define + #include позволяет сделать так, что значение конкретного символа, поглядев на него и рядом с ним, предсказать невозможно; то, что в одном файле он работает так, не значит, что в другом он не работает эдак. ‎- 9000
Поэтому одним из св. граалей программирования мне видится язык, который позволяет внятно описывать всё более сложные абстракции, не теряя прозрачности, лёгкости отслеживания до первопринципов. Не исключено, такой совершенный язык теоретически невозможен. Не исключено и то, что можно приблизиться к нему достаточно для практических целей. Также не исключено, что это вопрос адекватности инструментов; моя способность работать с разветвлёнными сетями классов на Java сильно растёт при применении IDE с индексом и мгновенной навигацией. ‎- 9000
Можно заранее отбросить сейчас случаи, когда жмёт производительность. Как правило, мест, требующих высокой производительности, мало, и их можно написать на языке близкого к железу уровня, хоть на ассемблере. На них вполне разумно потратить в 10 раз больше времени засчёт этого. ‎- 9000
Задача усложняется устройством мозгов человека (пресловутые 5±2 регистра оперативной памяти). Компьютеру тривиально отследить раскрытие макроса, а человеку — чаще всего не особо. Поэтому из идейно крайне простого лиспа легко с самыми лучшими намерениями сделать вполне ужасную нечитаемую магию. Идеальный язык должен этому как-то противиться — но не путём же отъёма средств абстракции совсем. Иначе кривая реализация половины лиспа самозародится в системе, как замечали классики (Greenspun 10th). ‎- 9000
Ещё есть засада с тем, чтобы накидать менее компактный код за пару часов. Если автор dsl / монады / иной сложной либы не устроил overengineering на ровном месте, то, возможно, сложность, описываемая его интерфейсом, как-от отражает сложность предметной области, и срезать её кардинально, скорее всего, не получится: пара часов становится иллюзией, когда автор двухчасового кода осознаёт сложность и на неё тратит два дня, или опасной иллюзией, когда сложность упускается и проблемы возникают уже в production. ‎- 9000
Вообще чем проще задача, тем проще приемлемый инструмент. Фортрана-IV (это где if x-y goto less_label, eq_label, greater_label) хватало написать метод Рунге-Кутта 4-го порядка. Но для вещей вроде управления воздушным движением уже пришлось выдумывать структурное программирование и Алгол. Такое ощущение, что авторы того же #golang не предполагают, что на го будут писаться крупные монолитные программы со сложными внутренними интерфейсами. Тогда composability становится вопросом внешних (сетевых) интерфейсов, где совсем другие соображения. Хотя, кмк, они всё равно обрезали возможности абстракции слишком коротко: становится трудно написать даже сложную библиотеку, если хочется статической проверки типов. ‎- 9000
Также "что автор имел в виду" в значительной мере выражается с помощью типов. В хаскеле из этого сделан принципиальный момент, в яве или C# проще, но не тривиально — всё равно ключевым интрументом остаются классы. Теория типов, меж тем, сложна и не сильно прямолинейна, насколько я понимаю. Не факт, что типы — вообще лучший инструмент для выражения ограничений, накладываемых на код (несмотря на вещи вроде http://strictlypositive.org/Easy.pdf). Но остальные, вроде эйфелевых контрактов, на практике как минимум не лучше, а то бы стали популярными. Возможно, мы просто ещё не изобрели инструмента, который позволяет одновременно и прозрачно показать, "что делает код" и "что автор имел в виду" в достаточном диапазоне практических случаев. (#programming) ‎- 9000
это, конечно, хорошо когда в джавном проекте нету магии. а то ведь понатащат всякого спринга, разрисуют стены аннотациями, абстрагируются от базы (just in case), подпилят аспектами пару-тройку библиотечных методов, да еще и согласно заветам церкви святых GoF разнесут стейт по десятку другому разных классов. а бывает еще и hazelcast какой-нибудь сверху вкорячат ну и дальше героически преодолевают "трудности" ;) ‎- BSOD bluez
^ у меня в проектах было всё это и ещё немного. Всё это куда проще чем один неплохо написанный вебсервис на spray-can :) Ну и вышеупомянутый сеньор должен подгребать постоянно, а не заходить раз в полгода ужаснуться. ‎- alf
Для тебя - уверен что так. Представь теперь чувака, который еще не сходил 10 раз туда-обратно по этому полю из граблей и костылей - есть ли для него тут "магия"? :) ‎- BSOD bluez
но это все лирика, скажи лучше - покупаешь ли ты поинт чувака вот по этой ссылке? - http://www.infoq.com/presentations/Simple-Made-Easy ‎- BSOD bluez
Там слишком много пойнтов :) Основной, про simple vs easy и complex == bad,— да, конечно. Но он построен так чтобы его купили. А дальше начинается types are complex, syntax is complex... и появляются вопросы. ‎- alf
Но с лиспоподобными языками у меня слишком мало опыта чтобы о чём-то судить. Надо найти контракт на Clojure :)) ‎- alf
То есть ещё один бонус джавки в том что (если забыть на секунду про ныне модные fluent interfaces) я могу взять переменную, нажать кнопку с точкой и увидеть, что я могу с ней сделать. Я пока не видел удобных инструментов, помогающих мне перейти от переменной к тому что я могу с ней сделать для, скажем, Clojure — и это, опять же, серьёзная нагрузка на бедные 7±2 слота. ‎- alf
Для хаскела есть прекрасный hoogle. Для Idris есть vim плагин :) Что ещё есть для задачи "я имею в виду вот это, но не знаю как написать"? ‎- alf
Stack overflow да, но нет ‎- alf
И вот ты пишешь по опыт, да? Хитрость с опытом ещё и в том что у Хики его двадцать лет. ‎- alf
clojuredocs.org + clojars.org? ‎- BSOD bluez
но я не кложу пытаюсь ендорсить, я за language semantics based on stack of flexible abstractions :) ‎- BSOD bluez
так cursive релизнулся, там наверняка можно автодополнение и тд. ‎- адский хардлайн в засаде

2015-2016 Mokum.place