ML языки - отстой

А обосновать - слабО?

E.g., напиши HOL/HOLlight на Java или Common Lisp.

обосновать могу
- это языки которые сделаны просто глупо
и крайне непрактично в использовании
возможно они и мета языки только
на земле люди хлеб растят а не занимаются вычислением количества ангелов на острие иглы ...
_______
HOL/HOLlight ?
а зачем ?
напиши мне бинарный ввод вывод на любом ML
а это задача встречающаяся на порядок чаще

Пока на XML не перепишут Линукс, место им на помойке

1) Задачи бывают разные. Каждой задаче - свой язык. Логика - дело крайне нужное, тот же HOL использовался в разработке ядра StrongARM - для верификации железа.

2) Бинарный ввод/вывод - делается тривиально, и гораздо проще, чем на императивных языках. Читать Олега Киселёва (у него, правда, на Схеме примеры).

3) про "непрактично" - ложь полная

4) про "глупо" - не тебе судить, сначала своим умом обзаведись.

Умри, гадёнышь.

>> 1) Задачи бывают разные. Каждой задаче - свой язык
вот именно - но ML языки слишком для спецефических задач
>> 2) Бинарный ввод/вывод - делается тривиально, и гораздо проще, чем на императивных языках.
мил человек - ты его сделай а потом говори что тривиально
в добавок код покажи - а мы подивимся на полученное уродство
>> 3) про "непрактично" - ложь полная
полная правда - ни один ML язык не расчитан на применение в повседневной практике. только на решение своих спецефических задач.
мораль - придурков которые их пихают как языки общего назначения - топить
>> 4) про "глупо" - не тебе судить, сначала своим умом обзаведись.
..... мой ум, моя правда

_____
этот топик флэймообразующий и задуман так специально
по причине того что
МЕНЯ ДОСТАЛИ УРОДЫ КОТОРЫЕ КРИЧАТ ЧТО ML лучше всех
ML - ДЕРЬМО в качестве языка общего назначения

1) Никто никогда не говорил, что ML лучше всех.

2) ML - как раз очень даже неплохой язык общего назначения (с учётом того, что вообще хороших языков общего назначения не бывает и быть не может - все - дерьмо). Если не согласен - ОБОСНУЙ. Покажи, какой язык "общего назначения" - лучше. На конкретных примерах. И о какой реализации ML идёт речь.

3) Удавись насмерть, мразь.

>>1) Никто никогда не говорил, что ML лучше всех.

возможно и нет. но один очень известный в негкоторых кругах человек
утверждал что с++ по сравнени с ним - отстой

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

что все дерьмо согласен
но некоторые просто пытаются быть "используемыми" а другие
только кичатся своей правильностью

пример - напиши перекодировку big endian <-> little endian на ML
напиши макроподстановку типа #define X 1 на ML

реализация ML - caml

>> 3) Удавись насмерть, мразь.
не буду так как не хочу

1) C++ - таки реально отстой в сравнении с ML. По всем абсолютно параметрам.

2) Про преобразования и макры - читать Харрисона, там, где он описывает построение парсера на комбинаторах. Делается это гораздо проще и эффективнее, чем даже на перле - регулярные выражения быстрее работают. Хотя, конечно же, на Лиспе оно ещё быстрее получится - там регулярное выражение будет в машинный код откомпилированно.

1) C++ - таки реально отстой в сравнении с ML. По всем абсолютно параметрам.

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

2) Про преобразования и макры - читать Харрисона

ok
только почему в с++
для этого мне не надо читать Харрисона ?
у меня простая задача - нужна макроподстановка
МНЕ НЕ НУЖЕН ПАРСЕР !!!!! черт возьми
(и регулярные выражения тоже, мать моя)
зачем для
#define X 1
нужно изучать построение формальных граматик ?

В ML - это сделать проще, чем в C++. Для C++, однако, тебе надо читать Шалдта, Страуса, Ёккеля, и прочих лохов. Уж лучше читать Харрисона.

И ещё - как ты препроцессор, который умеет #define X 1 понимать, напишешь хотя бы и на C++, не зная, что такое регулярные выражения?!?

домой пойду
интересно что на все это скажут
защитники "функционала"
еще раз
этот топик флэймообразующий
и создан для того чтобы попробовать найти:
- чем и как ML языки могут быть лучше с++ в решении
простых задач программирования
- сомнения у меня жутко сильные. вот и высказываю их сдесь
- может найдется человек который меня переубедит
PS
знаю что никто не обязан меня переубеждать
но так вышло что я столкнулся с горой Ocaml кода
и просто ВЫНУЖДЕН с ним работать
- ничего хорошего пока не увидел .... - одни только маты

>> В ML - это сделать проще, чем в C++. Для C++, однако, тебе надо читать Шалдта, Страуса, Ёккеля, и прочих лохов. Уж лучше читать Харрисона.

не знаю - читал, ничего страшного - жив
а если проще то как ?
не забудь что int 31 битный .... :(

>> И ещё - как ты препроцессор, который умеет #define X 1 понимать, напишешь хотя бы и на C++, не зная, что такое регулярные выражения?!?

просто напишу - в системе есть cpp ...
(тоько он с ocaml и тп работать не будет - знаешь почему ?
- идиоты не подумали что такой препроцессор легко можно было бы использовать для повседневных задач и реализовали синтаксис параметрического полиморфизма через задницу)
это раз
два - если бляха муха для такой простой вещи мне надо использовать
регулярные выражения - то ..... (напомню что написание препроцессора - одна из "слабых" задач из К&R )

В решении любых, и простых, и сложных задач ML будет лучше, чем C++ - потому как это решение будет короче и читабельнее. Код, который тебе попал, вполне может быть и плохим, а может - просто у тебя неправильно мозги заточены, так, что тот же STL ты худо-бедно понимаешь, а на фига нужен List.fold_left - не догоняешь. Ну так когда догонишь - на убогий и кривенький STL тебе смотреть не захочется. И на boost - тоже...

Используй boxed int, и всё те же битовые операции.

Про CPP - ты бы задачи проще формулировал. Я думал, ты хочешь сам аналог CPP написать. А так - юзай CamlP4, он на порядки мощнее, чем CPP.

let rec iter f = function
[] -> ()
| a::l -> f a; iter f l

let rec fold_left f accu l =
match l with
[] -> accu
| a::l -> fold_left f (f accu a) l

let rec fold_right f l accu =
match l with
[] -> accu
| a::l -> f a (fold_right f l accu)

let rec map2 f l1 l2 =
match (l1, l2) with
([], []) -> []
| (a1::l1, a2::l2) -> let r = f a1 a2 in r :: map2 f l1 l2
| (_, _) -> invalid_arg "List.map2"

let rev_map2 f l1 l2 =
let rec rmap2_f accu l1 l2 =
match (l1, l2) with
| ([], []) -> accu
| (a1::l1, a2::l2) -> rmap2_f (f a1 a2 :: accu) l1 l2
| (_, _) -> invalid_arg "List.rev_map2"
in
rmap2_f [] l1 l2
;;


читабельнее ???? %(
ну может быть но о literate програмировании
кто нибудь в стане функциональщиков слышал
?
или великим людям не до этого ?

boost я кстати не люблю
и примером его приводить не буду
____
я согласен что функциональное программирование позволяет
компактно записывать функторы
НО !
представь - необходимость в кунструкциях второго порядка
возникает на порядок реже (прости те за каламбур)
чем простые задачи ...
в которых ML слабы или глупо переусложнены

_______
я бы с радостью воспользовался ocamlp4
но для этого надо ломать билд всей системы
идиотский принцип
что препроцессор это модификатор граматики языка .....
Я НЕ ХОЧУ ЕЕ МОДИФИЦИРОВАТЬ
И НЕ ХОЧУ ПИСАТЬ СОБСТВЕННЫЙ ПРЕПРОЦЕССОР
я хочу просто заменить 64 слова на 64 соотвествующих подстановки
существует cpp (c pre processor ) который стандарт де факто
КАКОГО ЛЯДА ФУНКЦИОНАЛЬЩИКИ ПРОИГНОРИРОВАЛИ ПРОСТОЕ РЕШЕНИЕ ?
что бы заставить писать меня много и сложно ?
в этом суть функционального програмирования и програмирования вообще ?
- суть в том что cpp не может работать с ocaml файлом так как
выражением для полиморфного определения было выбрано 'a
а то что это пересекается с определением строки
никого не волновало
гениям позволено не думать о реальности, идиоты бля
___
в окамле нет боксинга -
объектная система откровенно тормознутая
и сделана из принцыпа - "как угодно дерьмово но не реализация не как в С"
- просто протестируйте ее - и увидете насколько она плоха
поэто я не могу сделать свою обертку - дурная задача
Int32 - приводит к откровенно грязному коду
____
кстати функциональщики когда либо слышали о "Конкретных типах"
или гениальным людям можно заниматься исключительно любованием
своей гениальности (генитальности ...) в зеркале
и срать на простые решения для простых задач

Дорогой мой, если не умеете, просто помолчите, зачем кичиться собственной безграмотностью?

Вы о боксинге ?
ну зачем так голословно ?
просто продемострируйте его пример ....
желательно без конструкций типа Int32.add x1 x2 в последствии
и со скоростью операции сложения не медленне чем в два раза
по сравненинию хотя бы просто с вызовом функции сложения
____
а если о препроцессоре - тогда
пожалуста продемонстрируйте решение в одну строку
#define X 1

и еще раз - я не собирался утверждать что ML - это плохо
трэд специально был начать как флэймообразующий
так как я надеялся
что есть есть в нашем отечестве мастера которые меня быстро обломают
и покажут где я не прав
без заглядывания в зеркало: "ну я же знаю как просто все можно сделать
а он дурак не знает, хи-хи"

Слабый закос под Луговского. Не пыжься.

> ни один ML язык не расчитан на применение в повседневной практике. только на решение своих спецефических задач. Есть пиринговая программа mldonkey для Линукса (есть и виндовый порт, впрочем). Написана на ocaml. Чем тебе не практическое применение?

да
и извините кто-нибудь может привести объяснение тому факту
что для того что-бы подключить модуль нужно записать
open Module - Module обязательно с большой буквы
а вот файл должен называться module, обязательно с маленькой буквы

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

и кажись это "фича" только окамля (может всех мл'эй ?)
и
зачем делает динамическую посылку сообщения к методу класса
даже если тот не виртуальный и отсутствуют способы делать
этот вызов посредством хотя-бы рефлексии? -
это типа - "зато-крута! - нам удалось
доказать что ООП хуже функционального программирования"
?

если то мне- я не собираюсь косить под луговского
я все жду что он придет и объяснит мне в чем я не прав
____
mldonkey - хорошо согласен
но у меня такая думка -
написан или для того что-бы доказать что на ocaml
можно писать
или кем-то кто был увлечен окамлем
- в обоих случаях это сродни фанатизму
а фанатики и не такое могут вытворить

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

Про странную систему модулей спрашивать с Ксавье Лероя. Он так и не объяснил внятно, зачем это надо. Имя модуля с большой буквы - хинт компилятору, что объект - модуль. Типа, упростили так, незнамо зачем. В SML таких выгребонов нет.

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

>читабельнее ???? %( ну может быть но о literate програмировании кто нибудь в стане функциональщиков слышал

Ну ты, блин, даешь. Я про *ML за всю жизнь прочел страницы 3 на всех - и как полностью некомпетентный в них человек заявляю:

Это не нужно документировать. Ибо оно тривиально. Следовательно читаемость хороша. (Хотя они (MLи) мне тоже не нравятся)

ладно ребята
звиняйте за наезды
---
сколько бы я тут не жалился - работать надо
- попробуем что нибудь с этим недозрелым лимоном что-нить сделать
__
я в конце концов хотел бы уточнить свою точку зрения
-- с++ это язык который развивался исходя из необходимости того
или иного использования
он такой потому-что он нужен таким и никаким другим
он вынужден быть корявым что бы дать мне все то что мне _реально_ может понадобится
он позволяет делать простые вещи - просто
__
ML же равивался не исходя из практики, а исходя из научных интересов
потому база использования для него маленькая
потому и он крив в реальном использовании
(кстати разказ о закрытых-тайных проектах очень похож на байку о неуловимом Джо ....)

PS
в конце концов наверное придется перелопатить его грамматику
и модули и сделать что то приличное а не ту дурь которая есть сейчас
- не визжать ! - это мое личное IMHO
__
что бы называться языком общего назначения надо быть как минимум простым для простого
PPS
и уберите же из него сборщик мусора наконец - достали :)))

> Есть пиринговая программа mldonkey для Линукса (есть и виндовый порт, впрочем).

Слухи о виндовом порте явно преждевременны, и тут не вина mldonkey или ocaml, вина скорей виндов.

> Слухи о виндовом порте явно преждевременны

Как это? Что же, по-твоему, я использовал в виндах?

:))
это так - обдумав
- выражения в программе не должны быть короткими
они должны быть в меру длинными
и способность кратко записать сложное выражение -
не та способность которой язык программирования может гордиться
APL тому пример (его смерть - точнее)
__
а сократительные абревиатуры в интерфейсе стандартной библиотеки
- хамство
и не уважение к возможным
(ну к функциональным языкам это наверное не относится)
милионам пользователей
- вы же в приличном обществе по фене не болтаете ?

> Как это? Что же, по-твоему, я использовал в виндах?

Либо только клиентскую часть, либо глючную и покоцанную серверную, которая не идёт ни в какое сравнение с ослом запущенным под операционной системой.

> а сократительные абревиатуры в интерфейсе стандартной библиотеки

А где ты их увидел в _интерфейсе_? Приведенный код был реализацией. Причем дедсадовского уровня сложности, документировать _это_ - все равно что требовать развернутого комментария к i++;

> вы же в приличном обществе по фене не болтаете

А вы i,j,k для счетчиков цыклов не используете никогда?

>Применений не мало - как раз во всяких закрытых штучных проектах, где время разработки особенно важно. Понятно, что информация о таких проектах наружу редко выходит...

Не надо ляля, секретные ученые пишут на фортране http://www.compitech.ru/html.cgi/arhiv/03_05/stat_12.htm ...рассказывает член Ядерного общества России, один из создателей Комплекса графических программ на Фортране (ГРАФОР)...

>выражения в программе не должны быть короткими они должны быть в меру длинными

Определение "в меру": выражения должны быть как можно короче, при условиях 1.достаточной различимости символов в их области видимости и 2.соответствия описания алгоритма "предмету".

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

В приведеном примере нет ни того, ни другого. Поэтому они могут (и должны) писать именно так (коротко). Я бы еще посокращал(-: rev_, _left и _right излишне длинны:-)

ok -
берем

let rev_map2 f l1 l2 =
let rec rmap2_f accu l1 l2 =
match (l1, l2) with
| ([], []) -> accu
| (a1::l1, a2::l2) -> rmap2_f (f a1 a2 :: accu) l1 l2
| (_, _) -> invalid_arg "List.rev_map2"
in
rmap2_f [] l1 l2
;;

интерфейсная часть
let rev_map2 f l1 l2 =

вы мне можете сказать что это такое исходя только из строки
let rev_map2 f l1 l2 =
????
что такое rev_map2 - реверсированние списка ? вы уверены ?
почему цифра 2 - два раза это делать ?
l1 & l2 это списки ? уверены ?
зачем ?
f функция - точно ? а зачем ?

я верю что вы умный человек
.....
можете дальше любоваться собой в зеркале
.....
но проблема что просматривая 7 мегабайт кода я в конце концов могу устать расшифровывать ваши абревиатуры
пожалейте людей которые вас будут читать ......
мальчиков которые не думают о том что их код будут читать
еще раз - ЧИТАТЬ
надо выгонять немедленно
просто 20 минут его работы выльется в 5 часов работы
человека после него - ЭТО ВРЕДИТЕЛИ - гоните их в шею
___
да кстати - долбанутый принцип выведения типов ......
очень тяжело с ходу сообразить что происходит в этом модуле
если он использует типы из другого
- очень много лишних движений
если это еще и сдобрить "гениальными" абревиатурами
возникает мысль о том что жаль что чей-то отец не был бесплодным ...

чаще всего я использую count
иногда iter
- это коротко и читабельно
__чрезвычайно__ редко использую более одного цикла
в одном блоке

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

не знаком с такими языками
- наверное это QBasic ? никогда на нем ничего не писал, не знаю
__
кстати почему то из за долбаной системы модулей Вирта-(Modula мертва !)
не развитости объектной системы
ocaml как раз и провоцирует на глобальные определения

так что - длинные имена удел окамля - не зачем
скрывать их абревиатурами - и делать вид что все Ok

PS
lambda - не есть высокий уровень абстракции - это к слову.

Да уж блинь, System.Threading.Mutex.ReleaseMutex() - внятнее?!? Жопу рвать за такие длинные и подробные идентификаторы - даже IDE с автокомплитом не защищает такой многословный язык от ненависти пользователей. Уж лучше окамловый Mutex.lock, Mutex.unlock...

>А вы i,j,k для счетчиков цыклов не используете никогда?

1. Только когда код не будет использован вторично и только при наличии не более 2х таких переменных в функции.

Конечно кулпрогерам некогда писать идентификаторы. Пох что потом люди это читают и анализируют. Давайте пихать всё в одну кучу, а лучше вообще без идентификаторов.

во первых
mutex.release ()

во вторых
в осамле
Mutex.lock mutex
вмеcто краткого mutex.lock

:(

> интерфейсная часть
let rev_map2 f l1 l2 =

Неа.

> l1 & l2 это списки ? уверены ? зачем ?

 ([], []) -> ...
| (a1::l1, a2::l2) -> ...
| (_, _) -> ...

^^^^^
Вот интерфейсная часть. 

>  f функция - точно ? а зачем ? 

А какая разница?

.............................
это юмор ?

Это суровая правда жизни.

тяжела жизнь однако .... %))

>вы мне можете сказать что это такое исходя только из строки let rev_map2 f l1 l2 =

В даном конкретном случае я угадал правильно:-) Хотя то, что они "zipWith" назвали "map2"-ом - и нарисовали отдельную ф-ю вместо "reverse . zipWith" еще больше "дискредитировало" ocaml в моих глазах.