Бред полный. Чудак спрашивает почему функциональный эрланг не такой как С и приводит примеры в которых он не такой. Единственный легитимный посыл там это про невозможность в гуардах использовть ничего кроме BIFов. Все остальное просто бред сишника который не понимает зачем нужна иммутабельность и что такое паттерн матчинг.
хаха! Кажется писать на всё «ххх не нужен» превратилось на лоре не только в традицию но и в правило морали, раз этого так ждут!
Я просто изучаю эрланг потихоньку, вот и подумал, что было бы интерестно узнать, где статическая типизация в эрланге действительно была бы полезна. Так что в моём вопросе нет никаких попыток повысить какой-нибудь там чсв, а лишь технический, програмистский интерес.
>опиши гипотетический пример, где она могла бы пригодится.
Опишу реальный писал вчера. Есть простой сервис который имеет интерфейс из двух функций зарезервировать телефонный номер, освободить телефонный номер. Рассмотрим последнюю функцию ее тип грубо говоря:
release :: Num -> (Reservaion | unknown_number | not_reserved)
Там где я ее использую мне очень хочется, чтобы компилятор метя ткнул там, где я не сделаю comprehensive match. В эрланге таких ходов конями 9 из 10 фукнций, а то и больше. И то что компилятор тут не помогает - вызывает тоску.
Еще ладно если я только что это написал. А если я исправляю то что было написано когда-то? Я уже себя приучил когда я правлю такие функции - грепать все исходники и смотреть на использование - чем это обернется в каждом конкретном случае. Эту дурную работу должен делать компилятор, а не человек.
А вообще то встречаются ходы конями от которых хочется Армстронгу дать подсрачник, чтобы не ленился. Взять хотябы behaviors. От необходимости pz на исходники проекта для _компилятора_ чтобы он проэвалюэйтил behaviour_info (функцию внутри компилируемых исходников компилятор вазывает чтобы получить - хаха - структуру бихэвиора (считай описание интерфейса) для статической проверки исходников) хочется рыдать. Я такое последний раз уже и не помню когда видел - одно смутное ощущение с реликтовых времен осталось.
За -include хочется надавать по шапке - ну е-мое запихни весь этот бред в beam-файлы, шо такое. В стектрейсах отсутствуют номера строк.Поэтому стектрейсы тяжело назвать стектрейсами.
Я тут не говорю о языке или как его переделать - он вполне гармоничен хотя мне многого не хватает. Но то что я упомянул - это ж не принципиальные вещи или заложенный дизайн.
Увы ничего не могу сказать по эрлангу, думал вы имеете ввиду что статическая типизация не нужно вообще. Тогда бы ЛОР свалил бы на вас все накопленные за всю историю какашки
Problem seems to be в том что Катс относится к ерлангу как к странному такому C. А если бы он имел хотя бы глю о прологе, из которого заимствован синтаксис эрланга он бы понимал что
A(), B(), C()
которые он пишет как «statements»
A(),
B(),
C()
в прологе являются предикатами A и B и C то исть _и_.
А запись
A() ->...;
B() ->...;
C() ->....
Является списком альтернатив - то есть _или_.
Что гармонично сочестается с гуардами где запятая обозначает «и» а точка с запятой - «или». И это все единоообразно.
Erlang expression separators vary context to context and it's simply more mental work to get right.
Так что единственный mental work который нужно сделать - это вылезти из как он назвал «algol based» стереотипов.
Интересно какой бы ему mental work сделал хаскельный f $ g x.
If Expressions
The problem is it prevents simple code like this:
if
Logging ->
log(«Something happened»)
end
Потому что такой код в языке типа ерланг писать не надо. В языке типа эрланг надо писать такой код:
Или сделать макрой, или если совсем одолеет скука - код реврайтер написать, если хочется ленивости. А не тянуть свои сишные привычки.
Functional Programming Mismatch
In C, lets say you have some code:
int f(int x) {
x = foo(x);
x = bar(x);
return baz(x);
}
Consider the Erlang equivalent:
f(X) ->
X1 = foo(X),
X2 = bar(X1),
baz(X2).
Erlang's context dependent expression separators and _immutable variables end up being huge liabilities_...
facepalm.beam.
Records
F#foo{c=C + 1}.
f.c += 1;
И что чудак не заметил семантическую разницу последних двух строк? По последним у меня такое впечатление что вообще не понял что написал. Потому как учитывая
bar(#foo{a=A,b=B,c=C}=F) ->
Эрланговская строка ему родит badmatch и пошлет нахер.
Так что походу эту дерьмовую статейку он написал до того как осилил эрланг.
Где вы находите задачи или их решения, в которых так критична статическая типизация? По мне, даже специализатор без нее можно написать без особого труда.
Почему в эрланг/лисп/хаскель срачах я никогда не вижу много кода на этих ЯП, а всегда несколько строк, в которых используются какие-то базовые вещи? Наоборот же, в срачах о более-менее общеупотребимых ЯП можно запросто найти простыни кода с разными фичами и хаками этих ЯП. Складывается ощущение, что все эти крутые прогеры на лиспах - на самом деле школота, прочитавшая мануал для быдла на двух страницах и теперь выёживающиеся на форумах.
> Где вы находите задачи или их решения, в которых так критична статическая типизация? По мне, даже специализатор без нее можно написать без особого труда.
Потому что выразительные свойства эранголиспоаскелей таковы что пара строк показывает или концепцию или проблему без простыней кода, как это делается в «общеупотребимых» языках где чтобы что-то выразить - без IDE не обойдешься. Так что ощущение у тебя неверное. Школота освоила «общеупотребимый» язык, почувстввовала себя крутым прогером, не имеет никакой базовой теоретической подготовки, и постит простыни кода чтобы решить проблемы которые вообще не должны существовать.
> Потому что выразительные свойства эранголиспоаскелей таковы что пара строк показывает или концепцию или проблему без простыней кода
В том то и дело, что в этих ваших лиспосрачах проблемы больше походят на школьные задачки по программированию.
Из последнего:
Видел на дотнете спор про обработку изображений, а именно про то, как лочить битмап в памяти, правильно проходить по пикселям через указатели, перескакивать паддинг и т.д.
На лиспе же: как чувак круто, играя мускулами, заюзал reduce, и таким образом переписал какую-то императивную фигню, которая и без этого неплохо работала, хоть и занимала на три строчки больше места.
Первая задача - решение какой-то прикладной проблемы. Хоть и не особо важной. Вторая - конь в вакууме, типа «смарите, как я могу на лиспе написать в одну строку то, что вы на си напишете в три».
>Первая задача - решение какой-то прикладной проблемы. Хоть и не особо важной. Вторая - конь в вакууме, типа «смарите, как я могу на лиспе написать в одну строку то, что вы на си напишете в три».
Первая задача не является проблемой вообще. Она порождена самим инструментом - все это твое хождение по указателям. ЗАйди на SQL.ru ты найдешь тучи народу которые занимаются копированием масивчиков или возвратом локальных char * . Это все проблемы порожденные инструментом. Это был первый поинт.
А второй поинт - такие смешные проблемы не являются проблемами для людей которые владеют эрланголиспохаскелями - это не проблемы, это скучно, это не интересно.
Редьюс это не просто сферический конь в вакууме - это обсуждение определенного теоретического подхода, с широкими возможностями углубления, начать можно со «смотрите как редьюс заменяет фор» и закончить катаморфизмами и теорие категорий. Это интересно людям которые программируют на лиспохаскелеэрлангах.
Не надо путать тут сравнивать прикладные проблемы и теоретические вопросы.
Расскажите мне пожалуйста в двух словах (на пальцах) об этих ваших катаморфизмах и прочих теориях категорий. Потому что я о них часто слышу, но на практике получается опять таки одна-две строчки на хаскеле, которые выводят «привет, мир».
Мне хочется услышать, как эти ваши катаморфизмы влияют на жизнь обычных программистов, и, главное, что они дают. Только не надо, пожалуйста, меня отсылать вгуголь - там много умных слов, но мало прикладного смысла.
И заодно расскажите о монадах. Потому что я перерыл весь этот ваш интернет и так и не нашёл простого человеческого объяснения что это такое.
>> Значит, говно этот LINQ. Скорость выборки из БД не должна сильно зависеть от языка клиентской программы.
Я ничего не говорил про БД. Это может быть, например, БД. А может быть и массив.
Ну что ж ты не указал, из какой именно коллекции выполняется выборка. А сравнение выборки из массива на Си и C# что с LINQ, что без, выглядит как-то нелепо.
LINQ он такой.
Если LINQ замедляет операцию в несколько раз по сравнению с аналогичной операцией без без LINQб он говно. так понятнее?
Динамическая типизация - говно. Лисп - говно. Эрланг - говно. И хаскель - тоже говно.
Я говорю, что динамическая типизация - говно, исходя из многолетнего опыта работы. А ты сколько лет работал с Эрлангом/Лиспом/Хаскелем?
> ...но при этом поимеешь замедление в N раз, зависимость от мелкомягкой копроплатформы, и пицод проклятий.
Вы забыли сказать, что сравнение вели для C и C#. По моим наблюдениям тот же LINQ to Object бывает быстрее банального for\foreach. Про удобство за счёт ленивости я молчу (хотя вполне допускаю, что можно огрести проблем, если криво использовать LINQ и его ленивость).
Мне хочется услышать, как эти ваши катаморфизмы влияют на жизнь обычных программистов, и, главное, что они дают.
Жал был я, писал на жабе модульный сервер с зависимой мнгофазовой многоуровневой инициализацией модулей. Это был ужос ужос, рекурсия для зависимой инициализации перемешаная с императивными циклами которыё просто «объектно» неабстрагирвоались. Потом я на это плюнул, все нахрен стер, включил голово, сказал себе - мужик - зависимая инициализация - это не что иное как свертка древовидной структуры которую можно абстрагировать относительно некой алгебры реализациями которых будут эти самые инициализации. В результате была написан либа свертывающая дерево лениво строящееся из списка модулей с зависимостями, и куча различных алгебр которё производят кучу различных инициализаций, связываний и прочих хреней. На жабе код конечно выглядел неблестяще, но менее страшно чем решение этой проблемы в лоб, а работал железобетонно и был мегареюзабелен.