Comments 50
Окамл — ужасный язык. На нём написана часть xenapi для xencloudplatform, каждый раз отчаянно матерюсь, на него натыкаясь. Ну написали бы на питоне, почему обязательно этот ужас?
Крик души? Давайте лучше по порядку, чем он ужасен и почему вы считаете, что питон всегда способен его заменить? Попробуем решить Вашу проблему.
ОК, излагаю проблему — это не мейстрим язык, который мне совсем не хочется учить, чтобы поправить какую-нибудь тривиальную вещь. И да, конечно, автор имеет право писать на любом языке — от braifuck.net до PL/I, но я, как человек, возящийся с софтом, вполне могу материть тех, кто использует в продакте (не в академических исследованиях) всякого рода erlang'и, ocaml'ы, haskell'и, прологи и т.д.
Первое предложение последнего абзаца в статье как раз для Вас.
И вряд ли Окамль был выбран по каким-то мазохистским соображениям, не такой уж он и страшный.
И вряд ли Окамль был выбран по каким-то мазохистским соображениям, не такой уж он и страшный.
Вы такой толстый :)
Я смотрел и окамловый xenapi и питоновый xend. В виду громосткости и сложности управления самим xen, оба достаточно тяжелы для восприятия. Ах да на момент ковыряния, оба не имели вообще никакой документации по коду.
Сами разработчики считают, что OCaml им очень сильно помог в плане разработки, сопровождения, и найма толковых программистов: www.cl.cam.ac.uk/~avsm2/icfp2010-xen-draft.pdf
Вот таких php-программистов уважаю :-)
ппц… а быдлокодеров на пайтоне или руби?
Сами себе ответьте, ок? ;)
я не смог… но, чудным образом улавив настроение вашего сообщения, спешу поблагодарить вас за то, что с высоты сложнейших программных продуктов, красивейших алгоритмов, правильного и безошибочного кода на правильных языках программирования вы не забываете о братьях своих меньших, милых, пушистых, и таких по-детски наивных и забавных быдлоphp-программистах.
низкий вам поклон.
низкий вам поклон.
о боже, быдлокодеры в минусомётной атаке!
я покусился на их самое святое…
я покусился на их самое святое…
OCaml — язык с человеческим синтаксисом, Scheme — с удобным. ;)
Если честно, со Scheme я знаком исключительно по статье в википедии, и как раз он мне кажется языком «для маньяков». Зачем нужен, например, этот фанатизм с превращением арифметических операторов в функции? Да, так удобно оператор плюс передать параметром, и машине подобная польская запись понятнее, но таки мало людей, которые выражения записывают подобным образом и им это удобно.
> Да, так удобно оператор плюс передать параметром, и машине подобная польская запись понятнее, но таки мало людей, которые выражения записывают подобным образом и им это удобно.
Я и говорю, не человеческий, но удобный.
Я и говорю, не человеческий, но удобный.
Тогда код на таких языках, на мой взгляд, должны генерировать человеческие языки :)
Результат ничем не будет отличаться от простого использования неуклюжих, но человеческих языков.
На мой взгляд (с), это как раз тот случай, когда проще изменить людей, чем языки. Вы только взгляните на весь этот инфиксный ад неLISP-образных языков вроде питона или С++. ;)
На мой взгляд (с), это как раз тот случай, когда проще изменить людей, чем языки. Вы только взгляните на весь этот инфиксный ад неLISP-образных языков вроде питона или С++. ;)
А в чём ад-то? У вас в школе же не было никаких проблем с вычислением выражений? Конструкции типа тернарного оператор ?: тоже вроде не должны вызывать проблем, по крайней мере у русского человека: «Если_условие_выполняется? то_А: в_противном_случае_Б»
Во внесении лишних сущностей вроде приоритета и сильном усложнении компилятора и, следовательно, системы макросов, или даже полной невозможности её реализовать. А вообще-то там смайлик стоял. ;)
Да, после сишного условного оператора каждый раз спотыкаюсь об питоновский вывернутый наизнанку
А if условие else Б
При выборе между удобством в частном случае и унифицированным подходом я бы выбрал второе. Хотя да, синтаксис у LISP-образных языков адский :)
> Если честно, со Scheme я знаком исключительно по статье в википедии
В таком случае, не делайте поспешных выводов насчет операторов-функций и префиксной записи.
В таком случае, не делайте поспешных выводов насчет операторов-функций и префиксной записи.
М? Я всего лишь высказываю свою точку зрения, что использование подобной польской записи мне, как человеку, кажется неудобным. Да и конкатенация строк, например, куда удобнее выглядит в записи «вася» ^ «купил» ^ «попить», нежели какое-нибудь (^) ((^) «вася» «купил») «попить»).
Конкатенация строк удобнее выглядит в Tcl (или JavaFX с небольшими изменениями):
set who Вася
set did купил
set what попить
set str "$who $did $what"
А в Scheme это будет так:
(string-join '(«вася» «купил» «попить») " ")
Выглядит страшновато, но если в вашем языке ^ соединяет строки именно разделяя их пробелом (что послужит причиной кучи проблем), то делаем так:
(define (^ . strs) (string-join strs " "))
И используем так:
(^ «вася» «купил» «попить»)
Можно написать (нетривиальный) ридер-макрос, с которым получится и как в Tcl:
#^"$who $did $what"
Вот в чём прелесть конструкторов языков. ;)
> (^) ((^) «вася» «купил») «попить»
Если заменить ^ на ++, то получится Haskell, но там как-раз инфиксная запись есть, а (++) используется для превращения (на уровне синтаксиса) оператора в функцию:
«вася» ++ «купил» ++ «попить» или (++) ((++) «вася» «купил») «попить»
set who Вася
set did купил
set what попить
set str "$who $did $what"
А в Scheme это будет так:
(string-join '(«вася» «купил» «попить») " ")
Выглядит страшновато, но если в вашем языке ^ соединяет строки именно разделяя их пробелом (что послужит причиной кучи проблем), то делаем так:
(define (^ . strs) (string-join strs " "))
И используем так:
(^ «вася» «купил» «попить»)
Можно написать (нетривиальный) ридер-макрос, с которым получится и как в Tcl:
#^"$who $did $what"
Вот в чём прелесть конструкторов языков. ;)
> (^) ((^) «вася» «купил») «попить»
Если заменить ^ на ++, то получится Haskell, но там как-раз инфиксная запись есть, а (++) используется для превращения (на уровне синтаксиса) оператора в функцию:
«вася» ++ «купил» ++ «попить» или (++) ((++) «вася» «купил») «попить»
Про функции типа join/implode мы сейчас не говорим :)
Равно как и про подстановку переменных, которая есть в тех же пхп и перле.
Префиксная запись в окамле, что характерно, тоже есть, и точно так же оператор можно скормить параметром функции, но вся прелесть в том, что как раз и человеческую инфиксную запись они реализовали.
Равно как и про подстановку переменных, которая есть в тех же пхп и перле.
Префиксная запись в окамле, что характерно, тоже есть, и точно так же оператор можно скормить параметром функции, но вся прелесть в том, что как раз и человеческую инфиксную запись они реализовали.
>Я посмотрел на неё и понял, что в принципе её можно целиком решить на PHP, или написать, как я люблю, расширение PHP на C++, но функциональный язык подошёл бы гораздо больше.
А как примерно можно определить круг задач (подзадач, наверное, вернее будет), которые имеет смысл писать на функциональных языках?
Понятно, что практически любую задачу можно решить на практически любом вменяемом ЯП, но так же понятно, что большинство ЯП для конкретной задачи будут «не в масть» (грубо — не стоит писать CMS на ассемблере). Функциональные ЯП интересны, но «академический» метод изучения, как правильно замечено, — дело довольно глупое (ну, корректнее выражаясь, неэффективное). Решать одну и ту же задачу на двух принципиально разных ЯП, а потом профайлером вытаскивать наиболее эффективные куски, оглядываясь на количество и качество кода тоже как-то не хочется :)
А как примерно можно определить круг задач (подзадач, наверное, вернее будет), которые имеет смысл писать на функциональных языках?
Понятно, что практически любую задачу можно решить на практически любом вменяемом ЯП, но так же понятно, что большинство ЯП для конкретной задачи будут «не в масть» (грубо — не стоит писать CMS на ассемблере). Функциональные ЯП интересны, но «академический» метод изучения, как правильно замечено, — дело довольно глупое (ну, корректнее выражаясь, неэффективное). Решать одну и ту же задачу на двух принципиально разных ЯП, а потом профайлером вытаскивать наиболее эффективные куски, оглядываясь на количество и качество кода тоже как-то не хочется :)
Если честно, я не учился на IT-специальности, поэтому не могу с умным видом говорить о лямбда-исчислении или там функциональном программировании, в силу ограниченности моего кругозора в данной области, так что всё последующее является моим личным мнением, даже близко не претендующим на истинность. Заключается оно в том, что функциональные языки чудо как хороши там, где нужна работа с предсказуемыми данными, которые имеют некую структуру и логичность. То есть, грубо говоря, какой-нибудь интерпретатор кода — это то самое, что надо писать на функциональных языках. Или, например, какие-нибудь вычисления (которые в силу «чистоты» функциональщины еще и распараллелить легко), обработку данных. То есть места, где можно, в соответствии с принципами ФП, взять функцию, скормить ей заданный набор данных, и получить всегда один и тот же результат.
А что касается профилировщика, я натыкался где-то на упоминание того, что код на окамле в среднем колеблется от «в 2-3 раза медленнее» до «в 10 раз быстрее», по сравнению с аналогичным кодом на C.
А что касается профилировщика, я натыкался где-то на упоминание того, что код на окамле в среднем колеблется от «в 2-3 раза медленнее» до «в 10 раз быстрее», по сравнению с аналогичным кодом на C.
главная вещь, которой учит питон: it's not a big deal. Ну лямбда. Да. И что? Ну написал я map(int,mylist.split()) — и что из этого? Ну сделал я генератор вместо функции, возвращающей список?
Чем больше я смотрю на питон, тем больше мне нравится та казуальность, с которой там реализуются самые возвышенные парадигмы — от ООП до функциональных языков.
Чем больше я смотрю на питон, тем больше мне нравится та казуальность, с которой там реализуются самые возвышенные парадигмы — от ООП до функциональных языков.
То есть, грубо говоря ( я учился хоть и на ИТ-специальности, но с большим уклоном в «железо»), там где есть детерминированность функции/метода от его аргументов, но нет никакой зависимости от контекста (включая «снимок» БД) имеет смысл попробовать (чуть не написал «нужно» :) ) использовать ФП?
Сравнение с Си — это, имхо, серьезно, особенно когда в «10 раз быстрее» :) но, в принципе, я не удивлён, интересовало лишь есть ли набор признаков каких-то, что вычисление именно этой функции имеет смысл реализовать на ФП
Сравнение с Си — это, имхо, серьезно, особенно когда в «10 раз быстрее» :) но, в принципе, я не удивлён, интересовало лишь есть ли набор признаков каких-то, что вычисление именно этой функции имеет смысл реализовать на ФП
Насколько я знаю, самый яркий пример успешного функционального языка с обширной базой пользователей в продакте — make. Хотя он не внушает, но вполне работает.
А как примерно можно определить круг задач (подзадач, наверное, вернее будет), которые имеет смысл писать на функциональных языках?
Всё, что можно лаконично записать математически в виде отношений между исходными данными и целью. Я не говорю здесь о вычислительной математике, большинство функциональных языков плохо с ней справляется. Речь идёт скорее о формальной записи решения некоей задачи в терминах математики. В качестве примера можно привести различные задачи обработки текстов (Ocaml неплохо справляется с этим), списков (Lisp), лексический анализ и т.п.
С практической же точки зрения, функциональные языки сильны там, где требуется надёжность и параллелизм (серверы приложений, телекоммуникации). Формально разницы между подходами нет, любая разрешимая в принципе задача решаема как императивно, так и функционально.
Вот! Вот оно, то слово, которого мне так не хватало для характеристики языков, которые я осваиваю — маргинальные!
Феерично
интересно, с академической точки )
а вот это:
void init_ocaml ()
{
char *argv[1];
argv[0] = NULL;
не падало ещё?
а вот это:
void init_ocaml ()
{
char *argv[1];
argv[0] = NULL;
не падало ещё?
хардкорно однако, но что-то в этом есть
> if r.grouptype = OrgGroup then true else false
Блестяще.
Блестяще.
Sign up to leave a comment.
OCaml и PHP — эзотерика для вашего удобства