Мьюзинг Морторей (Musing Mortoray), ведущий блог (http://mortoray.com/) о проблемах и дизайне современных языков программирования, после года разработки представил (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-November/067...) собственный язык Leaf (http://leaflang.org/), отвечающий его представлению об идеальном языке программирования. Leaf позиционируется (http://leaflang.org/goals.html) как простой и привычный язык программирования, вобравший в себя все лучшие возможности современных языков, нацеленный на решение реальных проблем, но не придерживающийся какой-либо определённой парадигмы разработки.
Реализация языка основана на наработках проекта LLVM и примечательна поддержкой разнородных методов выполнения кода (http://leaflang.org/features/execution_model.html), как традиционной предварительной компиляции в исполняемые файлы, так и использования JIT для компиляции во время выполнения. Среди возможностей (http://leaflang.org/features/index.html) языка: замыкания, автоматическое определение типов на основе инициализируемых значений, упорядоченные списки и хэши, защита от небезопасных преобразований типов, модификатор optional для определения (http://leaflang.org/features/conditionals.html) необязательных значений.
Разработка находится на стадии формирования начального прототипа, многие из возможностей пока не реализованы (http://leaflang.org/status.html) (в том числе недоступны модули, макросы, средства обработки ошибок, шаблоны и т.п.).
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-November/067...
Новость: https://www.opennet.ru/opennews/art.shtml?num=38394
Некоторые заявленные свойства довольно приятны, но не понятно, есть ли за этим адекватная теория. Как-то из дневника автора этого не видно. Не получится ли еще один руби?Картинка (узор) на заглавной странице сайта классная!
Ты прав, руби прекрасен, и второй руби просто не нужен
> и второй руби просто не нуженну да: хватит уже над смолтолком издеваться, смолтолк и без этого хороший.
>> и второй руби просто не нужен
> ну да: хватит уже над смолтолком издеваться, смолтолк и без этого хороший.There's a beautiful princess, prisoner in the highest tower of a castle, guarded by a mighty dragon, and a fearless knight must rescue her…
This is how each language would manage to rescue the princess from the hands of the dragon...
Ruby - Arrives with massive fame, saying he is the best at anything and when he faces the dragon, he shows a lame motion picture of himself killing a dragon… The dragon eats him out of boredom.
Smalltalk - Arrives, analyzes the dragon and princess, turns around and leaves, they are way too inferior.
Расписываюсь под каждым словом. А хейтеры будут сосать.
Господа, у вас бугурт. Вы с лошадей попадали, определенно.
Не обвиняй в баттхёрте да не обвинён будешь.
>Представлен новый язык программирования Leafи IDE для него: Leafpad.
У нас не приживётся. Программеров дудут лифчиками называть.
var a : integer = 10/5
var b : integer = 7.5/2.5
var c : float = 1/2
var d = 1e3
var create_adder = ( x : integer ) -> ( f : ( : integer ) -> ( :integer ) ) {
return (y :integer) -> ( :integer ) {
return x + y
}
}var add5 = create_adder(5)
//prints 7
trace( add5(2) )
---Мне одному Паскаль мерещится?
>[оверквотинг удален]
> ( : integer ) -> ( :integer ) ) {
> return (y :integer) -> ( :integer ) {
> return x + y
> }
> }
> var add5 = create_adder(5)
> //prints 7
> trace( add5(2) )
> ---
> Мне одному Паскаль мерещится?ты ещё go не видел?
> Мне одному Паскаль мерещится?нет, подозреваю, что есть и другие, у которых детские травмы.
тут и хаскель и скала и эф-шарп с паскалем
Да, исключительно органично сочетаются недостатки этих языков: птичий язык Хаскеля и отсутствие вывода типов паскаля.
> отсутствие вывода типов паскаля.э… у паскаля вывод типов? ты перегрелся, да?
Арису, включаем ЦНС и читаем мой коммент ещё раз. Если не понятно, скажи, я переформулирую.
фраза «отсутствие вывода типов паскаля» допускает двоякое толкование. можно понять и как «в паскале есть вывод типов, а тут нет». я её вполне серьёзно так и понял.
Ну, вот если бы ты не думал, что кругом одни идиоты, ты бы понял правильно.
> var create_adder = ( x : integer ) -> ( f :
> ( : integer ) -> ( :integer ) ) {
> return (y :integer) -> ( :integer ) {
> return x + y
> }
> }Сравним с
let adder x = fun y -> x + y;;
Или
let adder x = (+) x;;
> Сравним сне тупи: в твоём примере нет аннотации типов, поэтому сравнение некорректное. судя по намерениям автора, аннотации типов — strictly optional.
ну и да: твой код делает вовсе не то же самое, что код из примера. и не надо мне рассказывать, что «там, де, возможны только числа, потому что оператор '+' больше нигде не определён». спасибо. раньше я мог просто указать типы аргументов, а теперь я должен помнить, для каких же типов определён '+'.
>> Сравним с
> не тупи: в твоём примере нет аннотации типов, поэтому сравнение некорректное. судя
> по намерениям автора, аннотации типов — strictly optional.Объясни мне, на кой ляд она нужна?
> ну и да: твой код делает вовсе не то же самое, что
> код из примера.Увы, из-за отсутствия перегрузки в OCaml'е он делает ровно то же самое.
> и не надо мне рассказывать, что «там, де,
> возможны только числа, потому что оператор '+' больше нигде не определён».Это именно так, см. выше.
> спасибо. раньше я мог просто указать типы аргументов, а теперь я
> должен помнить, для каких же типов определён '+'.Можешь вставить int в Caml'евский код по вкусу. Но какой смысл в этом?
> Объясни мне, на кой ляд она нужна?чтобы туда double не пролез, например.
> Увы, из-за отсутствия перегрузки в OCaml'е он делает ровно то же самое.
то есть, складывать вещественные числа при помощи '+' в ocaml нельзя? O_O
>> и не надо мне рассказывать, что «там, де,
>> возможны только числа, потому что оператор '+' больше нигде не определён».
> Это именно так, см. выше.я сам окамля не знаю, но раз там нельзя при помощи '+' складывать вещественные числа, то я и рад, что не знаю.
>> спасибо. раньше я мог просто указать типы аргументов, а теперь я
>> должен помнить, для каких же типов определён '+'.
> Можешь вставить int в Caml'евский код по вкусу. Но какой смысл в
> этом?смысл — чёткое и наглядное задание области действия функции (с возможным сужением этой области, если задействованые операторы работают для нескольких возможных типов).
я не углублялся, возможно ли сейчас в сабже просто опустить указание типов в приведённом примере, но судя по общему дизайну — будет возможно.
> чтобы туда double не пролез, например.Если есть строгая статическая типизация, то не пролезет. Впрочем, можно, конечно, указать типы аргументов, но вот указывать тип результата - это абсолютно лишнее.
>> Увы, из-за отсутствия перегрузки в OCaml'е он делает ровно то же самое.
> то есть, складывать вещественные числа при помощи '+' в ocaml нельзя? O_OДа, к сожалению, нельзя. Для сложения вещественных чисел там используется оператор '+.'. На мой взгляд, это серьезнейший недостаток языка. Однако, в F# и в Haskell'е такого недостатка нет.
> я сам окамля не знаю, но раз там нельзя при помощи '+'
> складывать вещественные числа, то я и рад, что не знаю.Зря, кругозор никогда не вредит.
> смысл — чёткое и наглядное задание области действия функции (с возможным сужением
> этой области, если задействованые операторы работают для нескольких возможных типов).Пожалуйста, но при этом ты задаешь только типы аргументов, а не все, включая тип возвращаемого значения.
> я не углублялся, возможно ли сейчас в сабже просто опустить указание типов
> в приведённом примере, но судя по общему дизайну — будет возможно.Посмотрим.
> но вот указывать тип результата - это абсолютно лишнее.тут да, не спорю.
> Зря, кругозор никогда не вредит.нененене, я точно передумал его изучать. меня совершенно не радует перспектива запоминать то, что для сложения вещественных чисел надо писать вот эту вот — '+.' — бредятину. а почему не '.+'? а почему не 'add_reals'? нафиг-нафиг.
> Пожалуйста, но при этом ты задаешь только типы аргументов, а не все,
> включая тип возвращаемого значения.как уже написал — не спорю, тут компилятор должен бы и сам догадаться.
> надо писать вот эту вот — '+.' — бредятину. а почему не '.+'? а почему не 'add_reals'? нафиг-нафиг.Абсолютно справедливое возражение - ты апеллируешь к столетиям культуры, в которой употреблялся '+' в качестве знака сложения всех чисел, а не только целых.
Однако, и к Leaf'овскому if'у применимо ровно такое же возражение. Тоже есть культура ЯП, в которой для условных выражений использовались if и cond. Более того, do, традиционно, используется для циклов.
а я и сказал, что это чисто моя вкусовщина. извини, если не очень явно получилось.do, кстати, не везде для циклов, но это совсем другой разговор.
> нененене, я точно передумал его изучать. меня совершенно не радует перспектива запоминать
> то, что для сложения вещественных чисел надо писать вот эту вот
> — '+.' — бредятину. а почему не '.+'? а почему не
> 'add_reals'? нафиг-нафиг.Вам не нравится именно буковки для обозначения или сама идея не использовать + для сложения чисел с плавающей точкой (которые вещественными может обозвать только школьник)?
Буковки - дело соглашения. Просто типография с только ascii - уныла, существенно лучшего выбора нету. Зато Кнут вот использует плюсик в кружочке. А вот сама идея не использовать обычный плюсик - имеет вполне здравые математические корни: для чисел с плавающей точкой операции "умножить" и "сложить" не сохраняют "обычных" математических свойств (напр., ассоциативность). Это не поле, каким являются настоящие вещественные числа (или рациональные, к примеру).
> которые вещественными может обозвать только школьникбеседа закончена, не начавшись.
Rasch abkochen, dann Vormarsch nach Sokal.
>> которые вещественными может обозвать только школьник
> беседа закончена, не начавшись.Опять что-то не нравится... Ну пусть вы не школьник, будем считать что оговорились.
Исключая приаттаченый к замечанию эпитет - с сам замечанием согласны?
> с сам замечанием согласны?сложение целых чисел тоже ограничено разрядностью (если я верно помню, у окамля нет прозрачного «выпадения» в bignum'ы), и в этом случае использование '+' для сложения целых математически неверно. пусть уж выбирают там — трусы или крестик.
>> с сам замечанием согласны?
> сложение целых чисел тоже ограничено разрядностью (если я верно помню, у окамля
> нет прозрачного «выпадения» в bignum'ы)А тут все хорошо и без бигнумов. Покуда результат *всех* операций определен (не произошло переполнения) - с их алгеброй все тип-топ.
что-то я не помню у целых чисел математического понятия «переполнение». поэтому '+' для целых явно отличается от такового в математике. тогда какого чёрта? '+' для плавающих тоже отличается — объединяем и не имеем себе мозг лишней ерундой.да, с точки зрения «пытаемся быть святее папы римского» это неверно. вот потому мне и неинтересен язык, который свою святость (подпорченую, замечу) считает важнее моего удобства.
> что-то я не помню у целых чисел математического понятия «переполнение».Ну математическое или нет - каждый, кто считал на бумашке что-то чуть менее тривиальное чем 2x2 знаком с понятием "кончилась бумашка". Физических ограничений никто не отменял.
Проблема с float связана не с физическими ограничениями, а с самой моделью.
> поэтому '+' для целых явно отличается от такового в математике
Абсолютно ничем. Повторяю, физические ограничения тут не интересны. В одном случае (int) - результат операции неопределен. В другом (bigint) - все зависнет, программа завершится из-за нехватки памяти и т.п. В третьем - бумашка кончилась. И ладненько - возьмем *заранее* бумашку побольше.
> тогда какого
> чёрта? '+' для плавающих тоже отличается — объединяем и не имеем
> себе мозг лишней ерундой.Я пробовал вам объяснить какого. Для интов/бигинтов и т.п. - алгебраические свойства операций сохраняются полностью. Для float - нет.
Бумашка тут не кончается и запасаться ей бесполезно: результат операции может быть определен в конкретном примере для любой пары операндов. А вот некоторые привычные (для вещественных чисел) алгебраические свойства операций окажутся утраченными.
Так что эт вы зря. Математики используют специальную нотацию для float, чтобы отличать от операции над ними от операций над вещественными числами.
всё-таки раз послал в Сокаль — надо было и не возвращать. приходи, когда в математике появится понятие «результат сложения двух определённых целых чисел неопределён». до тех пор — игнор.
Мда. Мне жаль потраченного времени.
http://xkcd.com/927/
Язык обречен. У его создателя нет бороды http://www.borodawars.ru/news/1614/.
Высокоуровневые средства, позволяющие сделать свой язык с замыканиями и исключениями доросли до уровня, что теперь этих языков будет уже миллион через лет пять. Вопрос уже не в языках совсем, а в общей инфраструктуре, документации и прочем околоязыковом инструментарии.
>//if statement
>do x < y ? {Не, не взлетит.
> Не, не взлетит.среди тебя? пичалечка. автор бьётся в истерике от понимания того, что прожил жизнь зря.
> среди тебя? пичалечка. автор бьётся в истерике от понимания того, что прожил
> жизнь зря.Вопрос - зачем нужно изобретать новое название для оператора, когда в культуре устоялось if?
> Вопрос — зачем нужно изобретать новое название для оператора, когда в культуре
> устоялось if?а ты присмотрись внимательно. разницу между «устоявшимся if» и do совсем не видно? он немного более generalized, и назван — исходя из своей функции — вполне логично.
если везде таскать за собой «устоявшееся», то ничего нового не построишь. или — в лучшем случае — когда начнутся визги «а-а-а, название привычное, работа странная!», придётся всё равно вводить новый оператор, а старый будет чемоданом без ручки.
Все существующие языки (и новые в том числе) с его точки зрения имеют "фатальные недостатки"? А потом он обидится, что на его творении никто не пишет?
> Все существующие языки (и новые в том числе) с его точки зрения имеют "фатальные недостатки"?Так и есть. Кто пишет на идеальном языке программирования - пусть бросит в меня камень...
Другое дело, что любой новый ЯП также (по определению) обладает минимум одним недостатком - существующий код не может на него мигрировать валшебным образом.
> Кто пишет на идеальном языке программирования - пусть бросит в меня камень...Ну я пишу на идеальном языке программирования - С.
Где, когда и куда камень бросать?
> Ну я пишу на идеальном языке программирования - С.
> Где, когда и куда камень бросать?лучше лечиться, пока не поздно.
Вас это в первую очередь касается.
поздно
> Вас это в первую очередь касается.мне очень важно твоё мнение, высказывай его почаще.
Идеального языка не может существовать по одной простой причине: за всё нужно платить. В упомянутом вами Си отсутствие контроля памяти - серьёзная проблема, стоившая миру не одну тысячу человеко-лет, потраченных на борьбу с Segmentation Fault. Но это жертва, принесённая в угоду скорости и эффективности конечных программ. Статические анализаторы и кастомизация менеджера памяти помогает, но не на 100%.В Java же контроль памяти тотальный, что позволяет ликвидировать такие ошибки практически полностью, но платить за это приходится дополнительным расходом памяти и времени выполнения.
Так что свой камень оставьте при себе.
>Идеального языка не может существовать по одной простой причине: за всё нужно платить. В упомянутом вами Си отсутствие контроля памяти - серьёзная проблема, стоившая миру не одну тысячу человеко-лет, потраченных на борьбу с Segmentation Fault. Но это жертва, принесённая в угоду скорости и эффективности конечных программ. Статические анализаторы и кастомизация менеджера памяти помогает, но не на 100%.прямые руки откуда надо и голова чуть выше помогают в 99% случаев
>>Идеального языка не может существовать по одной простой причине: за всё нужно платить. В упомянутом вами Си отсутствие контроля памяти - серьёзная проблема, стоившая миру не одну тысячу человеко-лет, потраченных на борьбу с Segmentation Fault. Но это жертва, принесённая в угоду скорости и эффективности конечных программ. Статические анализаторы и кастомизация менеджера памяти помогает, но не на 100%.
> прямые руки откуда надо и голова чуть выше помогают в 99% случаевОбычно заявляторы о прямых руках сами не обладают оными. В тех самых 99%.
Такие дела. В статистику вас ткнули носом. А считать что вы один такой д'Артаньян... Ну, тут уже доктора советовали. Мания величия, все такое. Это еще в лучшем случае. Но боюсь, это просто глупость - и уже этот вариант, увы, не лечится.
Не нужен непредсказуемый язык, которым нельзя управлять. Пусть в Си нет сборщика мусора и всякой чепухи, зато, зато программист сам всё это делает и полностью может управлять своим кодом. Имея прямые руки на нем можно писать адекватный код, не только на прикладном уровне, но и на системной, на том, на котором Java со своим сборщиком без сильна.
>адекватный код, не только на прикладном уровне, но и на системной,
>на том, на котором Java со своим сборщиком без сильна.Давным давно, ещё в детстве папы всех учили - не ввёртывай гвоздь сынок и не забивай шуруп! Но дети выросли и пока не сломают своих 100500 шурупов и гвоздей - папино ученье не вспомнят :)
С из области системного программирование ничем выбить невозможно. Доказать не смогу, но есть такое OSчусчение :)
А вот с прикладухой ... тут всякого есть и ещё будет. Тут однозначно не скажешь. А потому - "пусть растут все цветы!"Как то так ... детишки :)
Может это разобьет твое сердце, но в плотное дерево шурупы намного эффективней забить на три четверти молотком и лишь на последнюю четверть докрутить отверткой. Ни один из тысяч шурупов, которые так были забиты не сломался, держат также как и закрученные целиком. Так что твой папа тебя учил излишне трудоемким методам. Ну а в области системного программирования С доминирующий, но отнюдь не единственный ЯП.
> А потому - "пусть растут все цветы!"Вот именно - цветы. А не гвидогрибы.
> Пусть в Си нет сборщика
> мусора и всякой чепухиСборщик мусора - это не чепуха. Это причина, почему мало-мальски интересные проекты пишут на всяких лиспах, питонах, явах и проч.
А C давно остался для оптимизации, для системного программирования и т.п. Клинические идиоты, которые на нем пишут всякие медиапроигрыватели (см. недавние новости) - не в счет.
> Имея прямые руки
Исходя из статистических данных - вы, вероятнее всего, такими руками не обладаете.
> Клинические идиоты, которые на нем пишут всякие медиапроигрыватели (см. недавние новости)
> — не в счет.то есть, медиапроигрыватель сложнее ядра, и в нём никак не обойтись без GC? круто ты сказал.
> то есть, медиапроигрыватель сложнее ядра, и в нём никак не обойтись без
> GC? круто ты сказал.Я сказал, что в нем глупо обходиться без GC. Но разве запретишь обезьянам орехи микроскопом колоть?
>> то есть, медиапроигрыватель сложнее ядра, и в нём никак не обойтись без
>> GC? круто ты сказал.
> Я сказал, что в нем глупо обходиться без GC.можно и не обходиться, библиотека есть. впрочем, компонентами и объектами glib/gtk управляют вполне неплохо. а остального не так много.
не идеал, конечно — но и не «ужас-ужас-ужас». если писать на gcc, то даже cleanup по выходу из области видимости есть. исключений нет, правда, и по longjmp() cleanup не делается.
> не идеал, конечно — но и не «ужас-ужас-ужас».И самое обидное, дурную репутацию хороший язык заслужил именно из-за подобных обезьян, пихающих C всюду, куда дотянутся шаловливые ручки студента.
> И самое обидное, дурную репутацию хороший язык заслужил именно из-за подобных обезьян,
> пихающих C всюду, куда дотянутся шаловливые ручки студента.ну, тут даже соглашусь — в принципе. «look ma i can into C too!» — и полетело.
то есть, «пихать си» можно, конечно. и я, в принципе, предпочту при прочих равных хорошую программу на си, а не хорошую программу на c++. но пихать тоже надо уметь. вот в данном случае си — это издевательство, конечно. потому что всё равно в итоге получается монстрик, где объекты кое-как пытаются эмулировать при помощи glib. не то, чтобы оно не получалось, но раз всё равно объекты — то и писали бы уже на Objective C, он красивей.
> я, в принципе, предпочту при
> прочих равных хорошую программу на си, а не хорошую программу на c++.Мне жаль ваши принципы. Видимо, они подразумевают что программы
для вас создает валшебная фея.Впрочем, c++ занимает ту же нишу, что и с: переносимый ассемблер (в случае крестов - "на стероидах", или даже укуренный вусмерть). Я подразумеваю, что вы хотели вместо c++ привести какой-то пример высокоуровневого языка.
> валшебнаянет, у меня феи без ошибок.
> подразумеваю, что вы хотели вместо c++ привести какой-то пример высокоуровневого языка.
я привёл именно тот пример, который и хотел привести. к сожалению, плохого кода на c++ я видел значительно больше, нежели плохого кода на c. отчасти потому, конечно, что плохие программисты из c и c++ выбирают c++ за «более высокую высокоуровневость» (пардон май фрэнч). при этом всенепременно суют туда какой-нибудь дебильный буст, какую-нибудь шаблонную абракадабру и прочую ненужную ерунду.
именно поэтому я бы предпочёл программу на си. без glib, само собой — glib тоже надо уметь готовить.
>Это причина, почему мало-мальски интересные проекты пишут на всяких лиспах, питонах, явах и проч.у вас весьма недостоверные данные.
>>Это причина, почему мало-мальски интересные проекты пишут на всяких лиспах, питонах, явах и проч.
> у вас весьма недостоверные данные.Вы можете привести примеры? И не коверкайте контекст, пожалуйста, если уж собрались цитировать.
>>без сильнаграммар-наци плачет кровавыми слезами
хм. выглядит интересно.
А компилятор он сразу в двоичном коде писал? А то ведь будет не православно/кошерно/халяльно - на ущербном-то языке да главную утилиту языка заделать. Или он вообще такой мелочью, как создание работающего компилятора не заморачивался, а просто придумал язык и всё?
а в чем проблема на самом листе и написать, когда заканчивал универ, то парниша в качестве диплома писал компилятор лиспа на лиспе и выглядел очень даже выигрышно по сравенинею с остальной серой массой...
> а в чем проблема на самом листе и написать, когда заканчивал универ, то парниша в качестве диплома писал компилятор лиспа на лиспе и выглядел очень даже выигрышно по сравенинею с остальной серой массой...это тот что в 15 строк помещается?
> это тот что в 15 строк помещается?сразу видно Знатока, йопт…
знаешь, есть на свете придурки, которые ничего не делают, а только идиотские вопросы задают. вот ты, например. а есть люди, которые просто берут рабочие инструменты и делают то, что им надо.а ты продолжай демонстрировать свой пригорающий зад: всё равно на большее ты не способен.
Где примеры, как выглядит хоть он ?
> Где примеры, как выглядит хоть он ?привет, дятел. за небольшую сумму в несколько тысяч USD я могу тебя научить пользоваться гиперссылками. а если приписать справа к сумме ноль, то даже читать научу.
> // a = 2
> var a : integer = 10/5
> // b = 3 (result is integral, so a safe assignment)
> var b : integer = 7.5/2.5
> // c = 0.5 (no accidental integer operations)
> var c : float = 1/2
> // d = 1000 (easy large numbers)
> var d = 1e3о ужас...
Согласен. Есть понимание того, что нужно улучшать имеющееся, но как улучшать - нет.
> о ужас…и что тут такого ужасного?
практически всё.
> практически всё.я смотрю, тут очень много людей, которых в детстве били паскалисты. конфеты отнимали. и теперь при виде чего-то, хоть немного похожего на паскаль, у них попеншмэрц.
ты как посмотришь, так сразу вспоминаешь своё трудное советское детство
> ты как посмотришь, так сразу вспоминаешь своё трудное советское детствосоветское детство у меня хорошее было. а вот дальше фигня какая-то началась.
А потом, после того, как создателю продукта просто тупо лень или мозгов не хватает работать со строго типизированными данными - высираются проекты, которые дружно ругаются за то что они даже на самой современной платформе еле шевелятся. Зато таких ремесленников Intel и компания видать любят.
это ты так признался, что нихрена не прочитал с сайта автора, зато имеешь Икспертное Мнение?