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

Условно задача сводится к преобразованию матрицы NxM -> f(x) -> LxK с последующим её выводом на экран в виде картинки максимально быстро и просто. Где N,M,L,K порядка 1000.

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

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

Смешно, как уже на протяжении >20 лет система обработки ошибок в Common Lisp остается единственной вменяемой из всех языков программирования (которые я пробовал).

Генери битмап.

Ну а я что делаю? Я, вроде, уже объяснял, в чём проблема. В битмапе нужно считать смещения в массиве, включая паддинги до целых байт. Это не просто arr[x][y] = 16500; Для таких вещей должны быть нормальные методы в языке. Всё-таки визуализации рисовать приходится часто. Кроме того, придётся генерить много мелких битмапов и уже из них составлять результирующую картинку, т.к. спектрограмма должна обновляться в реальном времени, с возможностью прокрутки к старым данным. Перерисовывать столько данных целиком не удастся.

Ну а я что делаю?

Не знаю. Или генерацию битмапа ты называешь «выгрузкой картинки» (откуда выгружаешь-то)?

В битмапе нужно считать смещения в массиве, включая паддинги до целых байт

Байты? O_o

http://docs.oracle.com/javase/6/docs/api/java/awt/image/Raster.html

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

есть же unsafe код ну или биндинги к directx

Его-то я и искал скорее всего.

Java тормозит, поэтому ты его и не смог найти :)

Ну, ещё не факт, что оно подойдёт. Я ещё не пробовал, мож и там есть подводные камни.

Да вам, с такими требованиями, Turbo Pascal нужен. Причём, именно Turbo.

По большинству же остальных параметров F# превосходит заметно.

Эм... кого превосходит-то? Родителя, в смысле, OCaml? Что-то не видно.

Например, С++ не скриптовый, но не строгий в типизации.

Эээ? Это тебя implicit int <-> bool не устраивает чтоли?

ТС, для какой (реализуемой) цели ЯП выбираешь?

int i=(int)j;

Чорд, хотел уже спросить «А зачем int к int'у приводить?» а потом понял, что тип j явно не указан.

Вот что делают общепринятые имена :)

Можно подумать, 100500 цитат про секретаршу хотя бы чем-то лучше.

Обзорчик ниочинь.

Разумеется. А какой ещё обзор можно написать на столь толстый вброс?

Не смеши народ. В строгих статических языках тоже не обязательно писать везде типы.

Где я в сообщении на которое вы ссылаетесь это отрицал?

Товарищ Сталин, прошу прощения, я не узнал вас в гриме.

Ты почему-то назвал только выгодные тебе Java & C#, жалкий ты манипулятор фактами :)

Общего назначения && userland. Драйверы и ядро не интересуют.

Ну как вариант j мог быть объявлен ранее как float и нам надо из него сохранить значение к примеру приведённые к int.

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

int i = (int)f;

Еще вспомнилась бородатая шутка:
«Переменные i, j — 25 лет на рынке счётчиков».

лучше использовать другое имя

согласен

«Переменные i, j — 25 лет на рынке счётчиков».

Прикольно, я не слышал :)

F# и окамл давно разошлись как языки. Были времена, когда первые компиляторы F# были написаны на подмножестве окамла, но они давно прошли.

Вот, ты как хаскелист, вероятно осознаешь важность нотации do, если не ошибаюсь. По этой теме я сравнивал многие языки. В каком-то виде что-то отдаленно похожее есть для Scala и даже для окамла, но там везде такая фигня на постном масле по сравнению с вычислительными выражениями F#. Отличаются как небо и земля. А я считаю эту фичу крайне важной, по крайней мере, для меня, из-за чего я не могу использовать Scala в одном своем проекте, хотя пытался много раз, и что-то осмысленное и работающее даже получалось.

Есть и другие отличия. Например, в F# довольно неплохое и удобное ООП (дотнетовское), и тут я совершенно не понимаю ненавистников. И как тут уже написали, даже многие окамлисты редко используют окамловское ООП, что говорит о многом.

Наконец, для F# есть хорошие IDE: Visual Studio и Xamarin Studio. Непоследняя деталь.

Вот, ты как хаскелист, вероятно осознаешь важность нотации do, если не ошибаюсь.

Нет, это микроскопический синтаксический сахар. Вместо

action >>= \x ->
otherAction >>= \y ->
lastAction

x <- action
y <- otherAction
lastAction

неплохое и удобное ООП (дотнетовское)

Как раз попытка более-менее вместиться в чужую систему типов привела к урезанию возможностей языка. При этом полностью не удалась, естественно.

И как тут уже написали, даже многие окамлисты редко используют окамловское ООП, что говорит о многом.

Угу. О том, что окамл — достаточно сильный язык, которому подпорки в виде ООП оказались не нужны.

Наконец, для F# есть хорошие IDE

Согласен. Но это не черта языка.

Нет, это микроскопический синтаксический сахар.

В случае хаскеля, но не в случае F#. Там компилятор проделывает гораздо больше работы, учитывая гибридность языка. Рекомендую все же ознакомиться с предметом обсуждения. Одного знания окамла здесь будет мало.

В случае хаскеля, но не в случае F#.

Ну, про хаскель не я заговорил в данном случае.

Рекомендую все же ознакомиться с предметом обсуждения.

Ну дык просвети.

Я как-то доклад про это дело слушал, у меня сложилось ощущение, что оно примерно то же самое.

Там компилятор проделывает гораздо больше работы

Угу. В F# 2.0 для типа T = A of .. | B of .. | C of .. Генерировался класс T, а в нём иннер-классы T.A, T.B, T.C. Видимо он джиттер не любит, вот и подкидывает ему работы.

Например, в F# довольно неплохое и удобное ООП (дотнетовское)

Вот и главная проблема. Дон Сайм и КО сочетают несочетаемое. Во-первых, такое ООП дает простор для возникновения NRE. Во-вторых, это общепринятое ООП не очень, камлёвое гораздо удобнее, ИМХО. Попробуйте подумать в чём не нуждается камлёвое ООП по сравнению с мейнстримным.

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

Уж как смогу объяснить :)

Там основная идея заключается в том, что можно взять почти «обыкновенный» код на F# и интерпретировать его по своему, разбавив подключениями для монад и монодоидов типа seq и list [1], создав на выходе соответствующее (абстрактное) вычисление. Это подразумевает, что нужно уметь обрабатывать такие императивные конструкции как try-finally, try-with, while и for. Поскольку язык использует энергичную стратегию вычислений, то нужно еще имитировать ленивость в некоторых случаях.

Там все довольно хорошо продумано. В сухом остатке получается, что код, задающий вычисление, выглядит почти так же, как обычный код, и это очень важно для практики [2]. То есть, порог вхождения для использования довольно низкий. Что еще важно, компилятор F# выдает обычно осмысленные ошибки на неправильный код.

Но в любом случае я не смогу объяснить лучше, чем это сделано в учебниках по F#.

[1] У seq и list давно еще до релиза задепрекейтили монадическую связку, хотя была.

[2] Почему мне совершенно не нравится for-comphrehension в Scala - его же просто невозможно использовать для сложных вещей.

А как бы стал F# интегрироваться с .NET, если бы там было нестандартное ООП?

Кому как, а на мой взгляд ООП в F# очень органично вписывается. Мне нравится. Ключевые инструкции для ООП выбраны изящно и со смыслом.

У меня против использования F# был только один пунктик - я долго думал, что его будет сложно использовать не на винде. Оказалось, что он замечательно работает и на линуксе, и на маках. Есть даже неплохая IDE Xamarin Studio (MonoDevelop).

Как пример. У человека был стандартный код на F#. Ему понадобилась рекурсия с глубокой вложенностью, превышающей лимит операционки (stack overflow). Тогда я ему предложил просто взять и сделать из его кода вычисление Async. Буквально означает, что код охватывается в билдер async, а в местах рекурсивного вызова пишем либо let!, либо return! в зависимости от того, хотим получить результат или нет. Человек прекрасно справился с задачей, причем я на 100% уверен, что он не знает как работают продолжения, да он, вроде бы, и сам признавался. Вижу в этом большой потенциал.

А разве существуют какие-то другие языки программирования, на которых пишут дельный десктопный софт? С++, Java, С#, может D (который те же плюсы, но сбоку). С не в счёт, ибо подмножество.

Я что-то упустил? Ну кроме python ничего.

нет-нет, все в порядке. ты ничего не упустил. все в порядке.

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