Образец годного ЯП

Возможно это пункт 5, но я бы хотел еще мощную и стабильную платформу со 100500 библиотек. Нету времени городить костыли и переизобретать велосипеды.

Не увидел сложного способа.

Дженерик-тип зависит только от типов. Функторы дают возможность типам зависеть от переменных. Не от их значений, правда, а от их identity, но чтобы сделать такое без них, нужно сильно извратиться. Даже на Хаскеле.

module type T = sig val x : int end
module type SF = functor (A : T) -> sig type t val a : t end
module S : SF = functor (A : T) -> struct type t = int let a = 146 + A.x end
module T1 = struct let x = 0 end
module T2 = struct let x = 1 end
module T3 = struct let x = 0 end
module S1 = S(T1)
module S2 = S(T2)
module S3 = S(T3)

Здрасьте, а Jane Street куда подевали?

Еще Citrix, Facebook и много-много других. Для них Окамл — секретное оружие. Уровень их программистов намного превышает среднестатистический. Им с лихвой достает ресурсов вносить изменения под свои нужды. И если Окамл как проект закончится, то сильно расстраиваться они не станут. Ну, может быть только выложат некоторое количество своих собственных веток в открытый доступ... Ентерпрайз, проприетарщина.

У хаскеля, кстати, такие же в точности проблемы. С той лишь малой разницей, что его развитием рулит команда из M$ Research. И именно как долгосрочный исследовательский проект, а не как обеспечение для Coq. Но и настолько ярких адоптеров как Jane Street у хаскеля нет и не предвидится.

Как раз Haskell более чем работоспособен.

Хаскель намного более высокоуровневый. Иногда настолько, что до источников тормозов, протечек (разных видов) и ошибок, добраться просто невозможно.

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

Да и проблем с (не)мутабельностью, и (не)ленивостью хватает. Чего в Окамле нет принципиально.

Еще ocaml (+coq сотоварищи) де-факто стандарт в верификации и формализации математических систем и программ. Да и системы автоматического поиска (и предотвращения атак) уязвимостей проектируют на нём, см. AEG и AEP.

P.S. Руководитель проекта Haskell вроде же ушёл из MS Research?

Ты путаешь компилируемость и интерпретируемость с видами типизации.

в этой области coq не одинок) вон HOL написан на SML и широко используется во всяких интелах для верификации железок.

Да, кстати, рекомендую еще посмотреть Idris, язык с полностью зависимыми типами, очень похож на Haskell.

P.S. Руководитель проекта Haskell вроде же ушёл из MS Research?

Нет вроде

Хаскелевская программа может взять и запросто сожрать всю доступную память. И объяснить — почему, достаточно сложно.

Мой опыт говорит обратное. Профайлер достаточно хорошо помогает найти, где течёт.

Да и проблем с (не)мутабельностью, и (не)ленивостью хватает.

Опять-таки, иммутабельность скорее избавляет от проблем, чем создаёт их. Там, где надо — мутабельность ставится явно и видна отовсюду.

Нет вроде

Вроде, второй Саймон, который Марлоу, таки ушёл.

кстати да, «+.»(и прочие) - это прекрасно!

Еще ocaml (+coq сотоварищи) де-факто стандарт в верификации и формализации математических систем и программ.

Не без этого. Но теория не стоит на месте... И новые логические фреймворки будут появляться. Вон не так давно подогнали HoTT... И будущим поколениям адептов ФП придется разбираться уже и в самой настоящей топологии.

Руководитель проекта Haskell вроде же ушёл из MS Research

Саймон Марлоу — да. Я, если честно, слабо разбираюсь в источниках финансирования... Сколько там общенаучных грантов, сколько идет от M$, сколько от IHG. Но в долгосрочной перспективе ситуация крайне шаткая.

но я бы хотел еще мощную и стабильную платформу со 100500 библиотек

ты же и так нашел себе scala. Или еще чего-то хочется?

Нет, я хочу именно компилируемый язык со строгой статической. И никаких уток.

Пф, лол. Scala хороша, JVM хороша, платформа Java хороша. А вот уроды которые тащат в проект библиотеку на Scala сделанную школьниками за два вечера потому что она на Scala, вместо проверенной на Java должны чистить клозеты. Гонка за идиоматичностью - болезнь. Потом проекты страдают от того что в них натащили всякого говнища как Play, Lift, SBT, Specs, Dispatch, Scalaz. И эти все поделия, которые падают, глючат, страдают от осутствия документации, обратной совместимости и рекомендуемых практик усилено пиарят в бложеках и на конференциях. Потом что не проект, сразу все с горящими глазами переубеждают друг друга что «wow, Play 2 is so exciting». Мудаки

Под первые три пункта идеально подходит ада. 4 - нет, 5 - ну не знаю, сложно сказать.

ты уже столько раз мне говорил что play 2 - гогно, и даже аргументировал, я даже его по большей части стараюсь теперь избегать, но все-таки для простеньких вещей он мне понравился.

Две проблемы - они не пропагандируют нормальную модульность и тестируемость, второе - плохая поддержка инструментами, аля IDE. Кто конкретно в этом виноват тяжело определить, но факт есть фактом - это мешает в проектах.

В play есть много хороших вещей, но пускай бы он бы был чуть более энтерпрайзным.

А то что бывают статические интерпретируемые языки и динамические компилируемые — это ничего?

Pascal.

Мне F# много больше нравится. И они давно с окамлом разошлись.

Java

≠ бросить исключение. И вот почему: http://blog.manki.in/2012/09/error-handling-java-vs-go.html
Если функция может ошибку при нормальном выполнении, её декларация должна дать чётко понять, что функция возвращает ошибку. Если программист решил проигнорировать ошибку, возвращённую функцией, должно быть видно, что программист игнорирует ошибку.
Так делают современные языки, вроде go, rust или scala, но так не делают java, c# и c++.

И вот почему: http://blog.manki.in/2012/09/error-handling-java-vs-go.html

Это ужасно. А если я хочу ошибку обработать не в месте вызова, а несколькими уровнями выше?

Так делают современные языки, вроде go, rust или scala

В scala exception'ы применяются.

А если я хочу ошибку обработать не в месте вызова, а несколькими уровнями выше?

...то твоя функция возвращает ошибку на уровень выше.

В scala exception'ы применяются.

К счастью, не только они: http://tersesystems.com/2012/12/27/error-handling-in-scala
tl;dr: для ожидаемых ошибок стоит использовать Try или Either, для непредвиденных или критичных — исключения.
Когда-то, наверное, у них были только исключения, но сейчас уже нет.

...то твоя функция возвращает ошибку на уровень выше.

Путем многократной передачи через return ? Убожество же!

для ожидаемых ошибок стоит использовать Try или Either, для непредвиденных или критичных — исключения.

Почему? Чем это лучше? Только создает нагромождение кода.

Когда-то, наверное, у них были только исключения, но сейчас уже нет.

В реальных продакшен проектах на scala используются исключения. Пример: apache kafka.

вот оба ужасно медленно работают с попиксельной отрисовкой графики.

А как же вот эти http://www.processing.org/examples/ отрисовывают графику на жабе? не попиксельно?

Нет, они используют дефолтовые методы. Но вот, увы, я не придумал, как можно вывести спектрограмму во времени не попиксельно.

Мне F# много больше нравится.

Это ради бога. Нравится-не нравится — дело сугубо добровольное.

Путем многократной передачи через return ? Убожество же!

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

Почему? Чем это лучше? Только создает нагромождение кода.

Возврат ошибки не происходит внезапно, чёткое разделение между ожидаемыми ошибками и критичными. И в конце-концов, конструкции try-catch-finally тоже бывают весьма громоздкими.

В реальных продакшен проектах на scala используются исключения.В реальных продакшен проектах на scala используются исключения.

Ну, Scala 2.10 совсем недавно вышла, а пока продакшен среагирует, ещё лет 5-10 пройдёт, особенно учитывая обратную совместимость и то, что люди программируют так, как они привыкли.

Но вот, увы, я не придумал, как можно вывести спектрограмму во времени не попиксельно.

Ты хотя бы додумался до использования двойной буферизации?

я читал что в Swingе двойная буферизация с незапамятных времен

LISP

мощную и стабильную платформу со 100500 библиотек.

JDK

Я же не говорил что нету, просто спрашивали о критериях

При правильной архитектуре это работает вполне просто и изящно.

Только надо писать в 2-3 раза больше кода с гоутами. Больше кода - больше ошибок.

Короче, чувак, ты не в теме со своим go. raii, exception safety и умные указатели спасут мир. Выучи нормально спп.

Я разрешения не спрашивал. Это я к тому, что ты тут напраслину льешь на F#. Где еще есть окамловские модули? Да практически нигде больше, и ничего, языки живут без этого. По большинству же остальных параметров F# превосходит заметно. Но вера многих крепка, и ничем ее не сломить.

Только надо писать в 2-3 раза больше кода

Может, в с++ и надо, но мы же говорим про языки программирования.
Советую поближе познакомиться с программированием на языках, отличных от с++ и ему подобных. Узнаешь много нового, особенно если не будешь писать на любом языке программу на с++.

но мы же говорим про языки программирования.

отличных от с++ и ему подобных

В эрланге например вообще пофиг на ошибки. При ошибках дерево процессов супервайзер перегрузил и всё. Никаких тебе кодов ошибок и никаких эксепшенов. Что скажешь по этому поводу? Там тоже не правильно?

Что скажешь по этому поводу?

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

с эрлангом близко не сталкивался.

Ну так иди и почитай про языки отличные от с++ и ему подобных, ок?

Ок. Сейчас читаю про J.

А я про rust.

Вы не до конца прочитали пост. Там написано, как правильно делать расширенную диагностику, которой хвалятся фанаты исключений.

Ты хотя бы додумался до использования двойной буферизации?

А чего там додумываться? Это не отменяет необходимости миллион раз вызывать методы установки пикселей, либо выгружать сырой массив данных и считать смещения.

Блестящий аргумент.

Это не отменяет необходимости миллион раз вызывать методы установки пикселей

Не знаю, какую именно задачу ты решаешь, но ты делаешь это неправильно.

Дело даже не в расширенной диагностике.

вот это?

Не знаю, какую именно задачу ты решаешь, но ты делаешь это неправильно.

Я же сказал, спектрограмму хочу (развёртку STFT / DCT / FFT во времени). С нужной мне расцветкой. Я знаю два метода сделать это на java/C#. Либо вызывать метод для каждого пикселя, либо выгружать всю картинку в бинарном виде и править, высчитывая смещения (для 24 бит не столь очевидно). Если есть другие методы, с удовольствием выслушаю.