LINUX.ORG.RU

СКАЖИ СВОЕМУ КОМПЬЮТЕРУ, ЧТОБЫ ЗАПЕР ДВЕРЬ

любительская автоматизация; устройство с открытой прошивкой
исходные тексты всех программ, открытые библиотеки
http://www.unicontrollers.com/products/unc01x

[#] Ответ на: комментарий от ovk48 03.11.2011 8:24:33  
r

>http://damienkatz.net/2008/03/what_sucks_abou.html

Бред полный. Чудак спрашивает почему функциональный эрланг не такой как С и приводит примеры в которых он не такой. Единственный легитимный посыл там это про невозможность в гуардах использовть ничего кроме BIFов. Все остальное просто бред сишника который не понимает зачем нужна иммутабельность и что такое паттерн матчинг.

***** ()
[#] Ответ на: комментарий от vertexua 03.11.2011 18:26:17  
mi_estas

хаха! Кажется писать на всё "ххх не нужен" превратилось на лоре не только в традицию но и в правило морали, раз этого так ждут!

Я просто изучаю эрланг потихоньку, вот и подумал, что было бы интерестно узнать, где статическая типизация в эрланге действительно была бы полезна. Так что в моём вопросе нет никаких попыток повысить какой-нибудь там чсв, а лишь технический, програмистский интерес.

* ()
[#] Ответ на: комментарий от mi_estas 03.11.2011 13:03:13  
r

>опиши гипотетический пример, где она могла бы пригодится.

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

release :: Num -> (Reservaion | unknown_number | not_reserved)

Там где я ее использую мне очень хочется, чтобы компилятор метя ткнул там, где я не сделаю comprehensive match. В эрланге таких ходов конями 9 из 10 фукнций, а то и больше. И то что компилятор тут не помогает - вызывает тоску.

Еще ладно если я только что это написал. А если я исправляю то что было написано когда-то? Я уже себя приучил когда я правлю такие функции - грепать все исходники и смотреть на использование - чем это обернется в каждом конкретном случае. Эту дурную работу должен делать компилятор, а не человек.

А вообще то встречаются ходы конями от которых хочется Армстронгу дать подсрачник, чтобы не ленился. Взять хотябы behaviors. От необходимости pz на исходники проекта для _компилятора_ чтобы он проэвалюэйтил behaviour_info (функцию внутри компилируемых исходников компилятор вазывает чтобы получить - хаха - структуру бихэвиора (считай описание интерфейса) для статической проверки исходников) хочется рыдать. Я такое последний раз уже и не помню когда видел - одно смутное ощущение с реликтовых времен осталось.

За -include хочется надавать по шапке - ну е-мое запихни весь этот бред в beam-файлы, шо такое. В стектрейсах отсутствуют номера строк.Поэтому стектрейсы тяжело назвать стектрейсами.

Я тут не говорю о языке или как его переделать - он вполне гармоничен хотя мне многого не хватает. Но то что я упомянул - это ж не принципиальные вещи или заложенный дизайн.

А Катс написал полный бред.

***** ()
[#] Ответ на: комментарий от r 03.11.2011 18:20:16  

> Все остальное просто бред сишника который не понимает зачем нужна иммутабельность и что такое паттерн матчинг.

Знать про эрланг и не знать кто такой Катц — это ЛОЛИЩЕ³.

** ()
[#] Ответ на: комментарий от r 03.11.2011 18:57:02  
mi_estas

А как насчёт dializer'а? Я правда про него только читал чуть-чуть, но никогда не пользовался. Он случайно в подобных ситуациях не может помочь?

* ()
[#] Ответ на: комментарий от mi_estas 03.11.2011 18:55:28  
vertexua

Увы ничего не могу сказать по эрлангу, думал вы имеете ввиду что статическая типизация не нужно вообще. Тогда бы ЛОР свалил бы на вас все накопленные за всю историю какашки

*** ()
[#] Ответ на: комментарий от mi_estas 03.11.2011 19:06:12  
r

>Он случайно в подобных ситуациях не может помочь?

Типа может - но там не все так просто и надо type аннотации везде прописать.

***** ()
[#] Ответ на: комментарий от baverman 03.11.2011 19:00:36  
r

Можем даже копнуть конкретно:

> Basic Syntax

> .....

> What's the problem?


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


Потому что такой код в языке типа ерланг писать не надо. В языке типа эрланг надо писать такой код:

debug(Logging, "Something happened").
.....
debug(true, X) -> log(X);
debug(_, _) -> ok.

Или сделать макрой, или если совсем одолеет скука - код реврайтер написать, если хочется ленивости. А не тянуть свои сишные привычки.

>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 и пошлет нахер.

Так что походу эту дерьмовую статейку он написал до того как осилил эрланг.

***** ()
[#]  
buddhist

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

*** ()
[#] Ответ на: комментарий от buddhist 04.11.2011 14:06:19  
r

>Где вы находите задачи или их решения, в которых так критична статическая типизация?

Для любого немикроскопического проекта поможет статическая типизация если не хочется воевать с мельницами.

***** ()
[#]  

Почему в эрланг/лисп/хаскель срачах я никогда не вижу много кода на этих ЯП, а всегда несколько строк, в которых используются какие-то базовые вещи? Наоборот же, в срачах о более-менее общеупотребимых ЯП можно запросто найти простыни кода с разными фичами и хаками этих ЯП. Складывается ощущение, что все эти крутые прогеры на лиспах - на самом деле школота, прочитавшая мануал для быдла на двух страницах и теперь выёживающиеся на форумах.

anonymous ()
[#] Ответ на: комментарий от buddhist 04.11.2011 14:06:19  

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

$likes = "много" + 1

anonymous ()
[#] Ответ на: комментарий от anonymous 04.11.2011 20:04:45  
jtootf
>>-----Цитата---->>

простыни кода с разными фичами и хаками этих ЯП

<<-----Цитата----<<

потому что всё то, что для этих ЯП - фичи и хаки, в Erlang/CL/Haskell - базовые вещи? :)

***** ()
[#] Ответ на: комментарий от anonymous 04.11.2011 20:04:45  
r

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

***** ()
[#] Ответ на: комментарий от r 04.11.2011 20:23:37  

> Потому что выразительные свойства эранголиспоаскелей таковы что пара строк показывает или концепцию или проблему без простыней кода

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

Из последнего:

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

На лиспе же: как чувак круто, играя мускулами, заюзал reduce, и таким образом переписал какую-то императивную фигню, которая и без этого неплохо работала, хоть и занимала на три строчки больше места.

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

anonymous ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:22:08  

> "смарите, как я могу на лиспе написать в одну строку то, что вы на си напишете в три".

Если программы на Х и Y решают одну задачу, но проограмма на X в 3 раза меньше другой - это уже весомый довод в пользу X.

***** ()
[#] Ответ на: комментарий от tailgunner 04.11.2011 21:25:48  

> Если программы на Х и Y решают одну задачу, но проограмма на X в 3 раза меньше другой - это уже весомый довод в пользу X.

На шарпе с LINQ можно написать выборку из какой-нить коллекции в одну строку, которую на C ты напишешь в двадцать-тридцать...

...но при этом поимеешь замедление в N раз, зависимость от мелкомягкой копроплатформы, и пицод проклятий.

anonymous ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:29:35  

> На шарпе с LINQ можно написать выборку из какой-нить коллекции в одну строку, которую на C ты напишешь в двадцать-тридцать...

Да, наверное. Но Си - он не для SQL-выборок сделан.

> ..но при этом поимеешь замедление в N раз

Значит, говно этот LINQ. Скорость выборки из БД не должна сильно зависеть от языка клиентской программы.

А вообще-то топик о том, что динамическая типизация - говно.

***** ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:22:08  
r

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

Первая задача не является проблемой вообще. Она порождена самим инструментом - все это твое хождение по указателям. ЗАйди на SQL.ru ты найдешь тучи народу которые занимаются копированием масивчиков или возвратом локальных char * . Это все проблемы порожденные инструментом. Это был первый поинт.

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

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

Не надо путать тут сравнивать прикладные проблемы и теоретические вопросы.



***** ()
[#] Ответ на: комментарий от tailgunner 04.11.2011 21:33:45  

> Да, наверное. Но Си - он не для SQL-выборок сделан. Я лишь хотел сказать, что длинее - не значит хуже.

> Значит, говно этот LINQ. Скорость выборки из БД не должна сильно зависеть от языка клиентской программы. Я ничего не говорил про БД. Это может быть, например, БД. А может быть и массив. LINQ он такой.

> А вообще-то топик о том, что динамическая типизация - говно. Дык, да. Динамическая типизация - говно. Лисп - говно. Эрланг - говно. И хаскель - тоже говно.

anonymous ()
[#] Ответ на: комментарий от r 04.11.2011 21:39:31  

> и закончить катаморфизмами и теорие категорий

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

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

И заодно расскажите о монадах. Потому что я перерыл весь этот ваш интернет и так и не нашёл простого человеческого объяснения что это такое.

anonymous ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:40:18  

>> Значит, говно этот LINQ. Скорость выборки из БД не должна сильно зависеть от языка клиентской программы.

> Я ничего не говорил про БД. Это может быть, например, БД. А может быть и массив.

Ну что ж ты не указал, из какой именно коллекции выполняется выборка. А сравнение выборки из массива на Си и C# что с LINQ, что без, выглядит как-то нелепо.

> LINQ он такой.

Если LINQ замедляет операцию в несколько раз по сравнению с аналогичной операцией без без LINQб он говно. так понятнее?

> Динамическая типизация - говно. Лисп - говно. Эрланг - говно. И хаскель - тоже говно.

Я говорю, что динамическая типизация - говно, исходя из многолетнего опыта работы. А ты сколько лет работал с Эрлангом/Лиспом/Хаскелем?

***** ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:29:35  
Norgat

> ...но при этом поимеешь замедление в N раз, зависимость от мелкомягкой копроплатформы, и пицод проклятий.

Вы забыли сказать, что сравнение вели для C и C#. По моим наблюдениям тот же LINQ to Object бывает быстрее банального for\foreach. Про удобство за счёт ленивости я молчу (хотя вполне допускаю, что можно огрести проблем, если криво использовать LINQ и его ленивость).

** ()
[#] Ответ на: комментарий от Norgat 04.11.2011 23:01:25  

> Про удобство за счёт ленивости я молчу (хотя вполне допускаю, что можно огрести проблем, если криво использовать LINQ и его ленивость).

Ленивость же суть много-много итераторов, которые дёргают друг друга.

anonymous ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:43:49  
r

>Потому что я о них часто слышу, но на практике получается опять таки одна-две строчки на хаскеле, которые выводят "привет, мир".

Это печально. http://en.wikipedia.org/wiki/Catamorphism

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


Жал был я, писал на жабе модульный сервер с зависимой мнгофазовой многоуровневой инициализацией модулей. Это был ужос ужос, рекурсия для зависимой инициализации перемешаная с императивными циклами которыё просто "объектно" неабстрагирвоались. Потом я на это плюнул, все нахрен стер, включил голово, сказал себе - мужик - зависимая инициализация - это не что иное как свертка древовидной структуры которую можно абстрагировать относительно некой алгебры реализациями которых будут эти самые инициализации. В результате была написан либа свертывающая дерево лениво строящееся из списка модулей с зависимостями, и куча различных алгебр которё производят кучу различных инициализаций, связываний и прочих хреней. На жабе код конечно выглядел неблестяще, но менее страшно чем решение этой проблемы в лоб, а работал железобетонно и был мегареюзабелен.

***** ()
[#] Ответ на: комментарий от mi_estas 03.11.2011 13:03:13  

>опиши гипотетический пример, где она могла бы пригодится.

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

А есть еще типы высших порядков... И небольшой примерчик http://chrisdone.com/posts/2011-10-16-rankntypes.html

**** ()
[#] Ответ на: комментарий от anonymous 04.11.2011 21:43:49  

> И заодно расскажите о монадах. Потому что я перерыл весь этот ваш интернет и так и не нашёл простого человеческого объяснения что это такое.

да вот хотя бы http://bartoszmilewski.wordpress.com/2011/01/09/monads-for-the-curious-programme... http://www.cc.gatech.edu/~yannis/fc /fcpp-lambda.pdf

http://bartoszmilewski.wordpress.com/2011/07/11/monads-in-c/

anonymous ()