Будущее Smalltalk и Ъ-ООП

И последнее. В общем, этот синтаксический сахар нужен для «нормальной» реализации асинхронности - популярная и востребованная ныне тема.

Тут только стоит упомянуть, что асинхронными вычислениями обычно называют две похожих, но разных вещи. Иногда обозначают ими задачи, уже запущенные в бэкграунде (хаскель, C#). С ними много проще.

Еще асинхронными вычислениями называют вычисления, которые только планируется запустить (F#). Вот, тут естественно возникает монада (F# async workflow), основанная на продолжениях, и для удобного и полнофункционального использования нужен хороший синтаксический сахар. Очень нужен как воздух.

У меня немного другой случай. Частный и академический. Но без этого сахара там просто никуда. Поэтому перестал использовать Scala. Практически полностью отказался. Главный язык - Haskell. Дополнительный - F#.

Был тут как-то один аноним, пытавшийся доказать обратное, но у него не получилось (завалился на фейковых переменных, а что говорить про поддержку паттерн-матчинга, if, while и for внутри такого сахара).

Да ладно, с фейковыми переменными можно делать «_ <- value» - что с точки зрения синтаксиса не слишком существенно. А на счет if/while/for ты так и не смог объяснить в чем проблема (что вполне логинчо - ведь никакой проблемы нету и if/while/for в скале с do работает в точности так же как и в хаскеле)

Кстати говоря сейчас же на курсере курс по reactive programming, причем Одерски как раз начал с монадок. Вот и посмотрим, что там у них с сахаром.

кури модель акторов хьюита.

и да подход блюпринтов из «статических» «компилирующих» языков было компромиссом , обусловленным временем и местом .

вся равно ко- и контр-? вариантность пускает «строгую» типизацию на свалку так шта.

это в том же го - где интерфейс(контракт) и типы как записи тут можно «синьками» как типами регулярных данных - а вот когда обьекты - строгое отношение какой они расы - и без(либо со сложностями) динамического изменения набора методов это просто не нужное ограничение.

Как раз проблема в синтаксисе, точнее в его достаточном минимализме. А так, те же монадические вычисления можно записать и на C#, и на Java. И ведь пишут. Просто это тот случай, где начинает работать диалектика, когда количественные изменения (меньше избыточного кода) переходят в качественные (лучшее понимание кода).

Вообще, я надеюсь на появление нового гибридного языка, где будут вычислительные выражения по подобию F#. Как понимаю, язык может быть и динамическим (это возможно - там типы можно не использовать). Я, вообще, эту фишку, включая нотацию do хаскеля, рассматриваю как фундаментальную, но возможно, что она идет впереди своего времени (как Филипп Вадлер и Дон Сайм). И это мое частное мнение, которое может не совпадать с мнением других :)

юзай мелкийбазар поверх жабкаскрипта

посмотри чем ща заняты Кей и Ингалс в своей ври

скорее по политическим причинам обжС не взлетел в начале 90ых - когда калькуляторы были уже не так медлены как в момент его появления в середине 80ых

однако плюсы получили всю славу тру ооп-языка промышленного использования.

скажи это пхп :(

Как раз проблема в синтаксисе

Если пример проблемы невозможно привести, то это значит что нету никакой проблемы.

Вообще, я надеюсь на появление нового гибридного языка, где будут вычислительные выражения по подобию F#. Как понимаю, язык может быть и динамическим (это возможно - там типы можно не использовать). Я, вообще, эту фишку, включая нотацию do хаскеля, рассматриваю как фундаментальную, но возможно, что она идет впереди своего времени (как Филипп Вадлер и Дон Сайм).

Или просто добавьте банальные syntax-rules макросы.

вся равно ко- и контр-? вариантность пускает «строгую» типизацию на свалку так шта.

С чего вдруг?

Скаловская for-comprehension не ровня нотации do

а можно пример увидеть?

и F# рядышком, если не трудно

В текущей скале есть как минимум плагин продолжений, пусть это маргинальненько, но дает то же, что async. Также асинхронность на акторах и фьючерах нормально (хоть и, подозреваю, неакадемично) сделана в akka (в т.ч. там есть композиция фьючеров и подобные вещи). В общем, я бы тоже посмотрел на конкретное сравнение F# и скалы по этому поводу.

ах если бы все(среди промышленных языков) были бы SOLID удобными ( т.е. легче всего и очевидней было бы следование солиду в синтаксисе - однако это не так самые простые и короткие пути в мелочах отличаются от солид и как следствие - ад и угар)

Ну, чего же вы с анонимом не хотите учить F#? Там все есть. Среди программеров российских распространено какое-то пренебрежение по отношению к F#, тем не менее, это - очень интересный и хорошо продуманный язык программирования. На мой взгляд более продуманный, чем Scala.

Примеры приводить мне надоело. Ради этого не стану я открывать книги. Еще подавай сравнительный анализ - да вы просто опупели. Свой код тоже показывать не буду. Желающие могут сыграть в детскую игру «почувствуй себя сливным бачком», если хотят.

А так, у меня есть собственные примеры для имитационного моделирования. На хаскеле они выглядят хорошо. На F# чуть похуже, но примерно также как на хаскеле, местами даже лучше. Внешний вид кода на Sсala вызывает слезы умиления. Это при том, что я довольно много прежде писал на Scala, и уже в этом частном случае искал самые разные пути для того, чтобы научиться красиво записывать имитационные модели. На хаскеле и F# получилось на мой взгляд. На Scala - фигня какая-то вышла (что через for, что через flatMap, что через плугин продолжений), да еще с обрезанным функционалом (это не считая того, что пришлось бороться с боксингом в jvm при реализации функций Scala, но это уже относится к другой теме).

Что касается упомянутого плугина продолжений. В теории его достаточно, чтобы реализовать многие монады (желаемую связку flatMap засунуть в shift), но с точки зрения практики это часто бывает просто чудовищно неэффективно. Многие - потому что неясно как быть с экстренной отменой вычисления. Почему-то плугин этот не поддерживает такой фундаментальной вещи, хотя она бывает важна, когда фактически идет преобразование CSP.

Нет, я тут понимаю. Scala - это сейчас модно, молодежно, трендово, да, вообще, хипстерская штучка. Бложики, конференции, печеньки, трёп, девчонкам можно похвастаться и т.п. и т.д. Просто я раньше других ею увлекся, и период увлечения уже прошел. Раньше, чем у других.

P.S. Сдается мне, что экстренную отмену вычисления можно засунуть во flatMap, но это тоже будет через одно место.

Примеры приводить мне надоело.

Как надоело, если вы так ничего ни разу и не привели?

Ну, чего же вы с анонимом не хотите учить F#? Там все есть.

Ну так вот в том и дело - и в хаскеле и в шарпе все есть. Такое же как в скале. В точности. А вы говорите что, оказывается, есть что-то еще - не прописанное в документации и никому кроме вас неизвестное. Сразу возникает очевидный интерес.

Еще подавай сравнительный анализ

Да зачем сравнительный анализ? Просто кинули пример кода, который, по вашему, на скале не пишется/пишется криво. И либо все посмотрят и с вами согласятся, либо предложат адекватный вариант на скале. Профит в обоих случаях.

интересный и хорошо продуманный

Язык программирования не должен быть «интересным» или даже «продуманным». Он даже хитровыдрюченным не должен быть.

Язык должен быть практичным. Чтобы быть практичным, он должен быть простым и популярным. Для этого язык должен называться Java , C или PHP. В крайнем случае Python. А фшарпы и скалы это равнозначно бесполезные хипстерские поделки.

Всем прогрессивным людям давно понятно, что иммутабельность и простые структуры данных — это хорошо, а скрытое состояние с прибитым к нему гвоздями поведением — это плохо.

Аргументация уровня «четыре ноги - хорошо, две - плохо!».

Можете продолжать спорить сами с собой дальше. Не буду мешать.

То есть пример кода так никто и не увидит, ок.