./ncc.exe a8.n
* Assertion at sre-encode.c:290, condition `count > 0' not met
=================================================================
Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Linux
noname@linux:~/Nemerle$ uname -a
Linux linux 5.0.0-29-generic #31~18.04.1-Ubuntu SMP Thu Sep 12 18:29:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
#lang racket
(define (fact ac n)
(if (= n 1) ac
(fact (* ac n) (- n 1))))
(fact 1 100)
Result
Добро пожаловать в DrRacket, версия 6.11 [3m].
Язык: racket, with debugging; memory limit: 128 MB.
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
В статье четко оформлена мысль которая витала у меня в голове
последнии дни и оформилась когда я увидел анонс C# 8.
Боже как убого смотрится паттернматчинг( символ => стыдливо скрывает под собой банальный statement(инструкция) return).
Они не осилили блок конструкций в матчинге! И даже нельзя более одного условия использовать в обработчике.
В противовес этому такие языки как Nemerle или Racket представляют собой живое существо построенное из выражений(expression).
Вот чего фатально не хватает C# — выражений! Отсюда и необходимость натирать мозоли на пальцах.
И ожидание в течении нескольких лет такой простой вещи как записи.
Ну почему люди цепляются за старое? Ведь эволюция это единственный путь к улучшению.
Every expression is either a single value or a list.
PS Печально, что поддержка Nemerle так слаба несмотря на такие крутые вещи как Nitra или http://www.ammyui.com/.
При том что в репозитории встречаются документы с грифом права MS. Вероятно у кого-то была мысль заменить C# Nemerle, такая замена прошла бы очень гладко, но кто-то испугался перемен...
Здравствуйте, varenikAA, Вы писали:
AA>В противовес этому такие языки как Nemerle или Racket представляют собой живое существо построенное из выражений(expression). AA>Вот чего фатально не хватает C# — выражений! Отсюда и необходимость натирать мозоли на пальцах.
Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально.
AA>Ну почему люди цепляются за старое? Ведь эволюция это единственный путь к улучшению.
Действительно, почему люди цепляются за такое старье, как лисп? Уже давно пора эволюционировать.
AA>Every expression is either a single value or a list.
В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.
AA>Вероятно у кого-то была мысль заменить C# Nemerle, такая замена прошла бы очень гладко, но кто-то испугался перемен...
Если такое и произойдет, то точно не в обозримом будущем. В C# вложены огромные ресурсы и просто так заменять его не будут.
Здравствуйте, AlexRK, Вы писали:
ARK>Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально.
Я и не жду что ему конец, инерция мышления заставляет человечество топтаться на месте.
ARK>Действительно, почему люди цепляются за такое старье, как лисп? Уже давно пора эволюционировать.
Лисп отличает от C# в первую очередь открытость к изменениям, поэтому он жив(не благодаря финансовой поддержке). И да, он постоянно эволюционирует.
Причем, гораздо раньше большинства других языков. А вот "промышленные" языки плетуться в хвосте.
Кстати, интересный факт, Пол Грэм создал свой вариант лиспа на ракете, который в свою очередь лиспо-схема.
ARK>В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.
Если есть выражения, то мы вместо присваивания используем связывание, ведь больше нет значений, но есть выражения.
ARK>Если такое и произойдет, то точно не в обозримом будущем. В C# вложены огромные ресурсы и просто так заменять его не будут.
Так и не надо было, есть же модель использования F# в качестве альтернативы.
Что же в Lisp'е такого прекрасного?
Если он такой замечательный, почему его не используют все?
Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы.
Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии,
но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
Здравствуйте, AlexRK, Вы писали:
AA>>Every expression is either a single value or a list.
ARK>В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.
В функциональщине давно придумали специальный тип (например в OCaml тип unit имеющий только одно значение ()) чтобы возвращать ничего.
Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.
Здравствуйте, FR, Вы писали:
FR>В функциональщине давно придумали специальный тип (например в OCaml тип unit имеющий только одно значение ()) чтобы возвращать ничего.
Я в курсе.
FR>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.
В rust не всё есть выражение.
fn main() {
let a = fn Test () {
println!("Hello, world!");
}
Test();
}
Здравствуйте, varenikAA, Вы писали:
AA>Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих. AA>И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, AA>но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
Тем не менее, язык Ц появился через 15 лет после появления лиспа, и мир завоевал именно он и его потомки.
Гораздо интереснее парадокс парадокса Блаба — люди, который согласны с парадоксом Блаба не понимают социальных и экономических причин, стоящих за популярностью языков программирования.
Например, уверовавшему в парадокс Блаба нет смысла приводить аргументы про рынок труда. Последние лет 50 сложность задач в мейнстриме постояно снижается, а соответственно снижается и сложность языков программирования.
Еще 20 лет назад в норме для какой нибудь софтины надо было пилить механизмы по сложности сравнимые с компонентами операционки. Сейчас же основной код, который пишется, это тривиальная логика обработки юзер-инпута и натягивания стилей.
Соответсвенно востребован CSS, а в качестве ЯП общего назначения сгодится любой язык, который под силу людям без образования. Исторически сложилось, что такой язык уже есть в браузере искаропки. А вот другие языки, которые были в браузере — vbscript, Perl, Python, Rexx не прижились. Ха-ха.
С другой стороны, часть задач вне мейнстрима довольно сложные и становятся все сложнее. Но вот парадокс, здесь то работают матёрые разработчики, которые новый язык учат за день.
Какая здесь реальность ? Дома спецы балуются с Хаскелем, а на работе пилят числодробилки на С++, ML на питоне, тренируют сети или колупают клауд на джаве, от силы — на скале.
ARK>>Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально. AA>Я и не жду что ему конец, инерция мышления заставляет человечество топтаться на месте.
Инерция мышления только в головах тех, кто любит направо-налево блабами кидаться. Языки постепенно всасывают в себя прагматичные и практические решения, а не бездумно кидаются на все, что понапридумывали академики от хаскеля за последние 30 лет.
В действительно используемых языках (те же Java/C#) приходится считаться с наследием: от дизайнов VM/байткода/JIT'а/да чего угодно, на что может быть завязано очень многое, до каких-нибудь вполне прагматичных вещей типа «да нахер никому не сдались ваши liquid types и lenses в реальном мире».
В новых языках, которые не обременены ни наследием ни проблемами обратной совместимости, могут позволить себе вводить все, что угодно. Паттерн-матчинг, о котором ты ноешь, прекрасно есть в Расте, например.
FR>>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.
ARK>В rust не всё есть выражение.
Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими
заморочками. Это и в функциональщине также, в том же OCaml это
let f = let f x = x + 1;;
тоже будет ошибкой.
Ну и в том же rust функция вполне значение:
fn main() {
let a = {
fn test() {
println!("Hello, world!");
};
test
};
a();
}
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, AlexRK, Вы писали:
FR>>>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.
ARK>>В rust не всё есть выражение.
FR>Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими FR>заморочками. Это и в функциональщине также, в том же OCaml это FR>
FR>let f = let f x = x + 1;;
FR>
FR>тоже будет ошибкой. FR>Ну и в том же rust функция вполне значение: FR>
FR>fn main() {
FR> let a = {
FR> fn test() {
FR> println!("Hello, world!");
FR> };
FR> test
FR> };
FR> a();
FR>}
FR>
Здравствуйте, FR, Вы писали:
FR>Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими FR>заморочками.
А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО.
FR>Ну и в том же rust функция вполне значение:
А как выразить тип "функция с любым входом и/или любым выходом"?
Здравствуйте, AlexRK, Вы писали:
ARK>А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО.
Ну это же для блоков кода имеется в виду. "Все есть объект" тоже даже для Smalltalk не верно
если так рассматривать.
Хотя модули в том же OCaml (и других ML) тоже первоклассные сущности, их можно например
параметризовать https://dev.realworldocaml.org/first-class-modules.html
rust это не перенял, но некоторые забавные вещи оттуда все-равно перешли, например
модуль вложенный в функцию :
FR>>Ну и в том же rust функция вполне значение:
ARK>А как выразить тип "функция с любым входом и/или любым выходом"?
А такое выражается хоть в каком-то строго статически типизированном языке,
без применения средств макропрограммирования, только типами?
Хотелось бы посмотреть пример, и как можно использовать.
Здравствуйте, FR, Вы писали:
ARK>>А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО. FR>Ну это же для блоков кода имеется в виду. "Все есть объект" тоже даже для Smalltalk не верно FR>если так рассматривать.
Ну а почему собственно, скажем, объявление типа не может быть блоком кода? Вопрос риторический. Вполне даже может. Просто в rust это не так.
FR>rust это не перенял, но некоторые забавные вещи оттуда все-равно перешли, например FR>модуль вложенный в функцию
Маразм, ИМХО.
ARK>>А как выразить тип "функция с любым входом и/или любым выходом"? FR>А такое выражается хоть в каком-то строго статически типизированном языке, FR>без применения средств макропрограммирования, только типами?
Хрен знает, может в Scala есть, хотя не уверен.
FR>Хотелось бы посмотреть пример, и как можно использовать.
Даже если использовать никак нельзя, возможность такая должна быть. Должны быть top type и bottom type для функций. Иначе функция не будет полноценным значением (и в rust это именно так).
Хотя и использовать можно — в качестве генерик констраинтов. "Любая функция, возвращающая целое число и принимающая некое T, где T — генерик-параметр типа кортеж".
Здравствуйте, FR, Вы писали:
FR>А такое выражается хоть в каком-то строго статически типизированном языке, FR>без применения средств макропрограммирования, только типами? FR>Хотелось бы посмотреть пример, и как можно использовать.
Увы, это не "любая функция". У "любой функции" (top) вход должен быть максимально узким, а выход — максимально широким. А у "никакой функции" (bottom) наоборот — вход самый широкий, а выход самый узкий. Кроме того, количество аргументов должно быть произвольным, как минимум на входе (а если язык поддерживает множественные выходные аргументы — то и на выходе тоже).
UPD. Ах да, изначально я сказал не про "любую функцию", а про "функцию с любым входом и/или выходом", что, конечно, не одно и то же (хотя в голове я имел в виду именно первый вариант). Но возражение про количество аргументов все равно остается в силе.
Разумеется. Это, как и запрашивалось, "функция с любым входом и/или любым выходом". Туда можно передать хоть что угодно, хоть ничего, и получить хоть что угодно, хоть ничего.
Re[10]: Сплошное расстройство (Nemerle or Racket?)
Здравствуйте, Ikemefula, Вы писали:
ARK>>Увы, это не "любая функция".
I>Разумеется. Это, как и запрашивалось, "функция с любым входом и/или любым выходом". Туда можно передать хоть что угодно, хоть ничего, и получить хоть что угодно, хоть ничего.
Да, я сам уже заметил свою ошибку и поправился (см. апдейт поста). Но здесь таки не любой вход — здесь ровно один аргумент. Я не прав?
Re[11]: Сплошное расстройство (Nemerle or Racket?)
Здравствуйте, AlexRK, Вы писали:
ARK>Да, я сам уже заметил свою ошибку и поправился (см. апдейт поста). Но здесь таки не любой вход — здесь ровно один аргумент. Я не прав?
const f:(...a:any[])=>any = (a:string) => 5
Re[12]: Сплошное расстройство (Nemerle or Racket?)
ARK>>Увы, это не "любая функция".
I>Разумеется. Это, как и запрашивалось, "функция с любым входом и/или любым выходом". Туда можно передать хоть что угодно, хоть ничего, и получить хоть что угодно, хоть ничего.
Все равно типизацию же сломали.
Насколько я понял это TypeScript и any динамический тип.
В динамике никаких проблем такие функции сделать.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, varenikAA, Вы писали:
AA>>Парадокс Блаба
I>Гораздо интереснее парадокс парадокса Блаба — люди, который согласны с парадоксом Блаба не понимают социальных и экономических причин, стоящих за популярностью языков программирования.
I>Например, уверовавшему в парадокс Блаба нет смысла приводить аргументы про рынок труда.
Речь не о зарабатывании денег на жизнь, а об эффективном инструменте.
Понятно, что хочешь жить умей вертеться. Но для быстрого написания надежного кода(корректного с точки зрения логики) требуется ЯП, который форсит программиста
делать все правильно. Например, вместо интов использовать алгебраические типы, сравнивать записи по значению, а не по ссылке.
В качестве примера такой ошибки, есть две DTO(C#) которые сравнивались по Id : int, после рефакторинга код остался нетронутым, но логика была нарушена.
ЯП типа F# форсит использовать PersonId of int и ManagerId of int и в случае рефакторинга мы бы обязаны были этот код проверить.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, varenikAA, Вы писали:
AA>>Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих. AA>>И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, AA>>но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
ARK>Тем не менее, язык Ц появился через 15 лет после появления лиспа, и мир завоевал именно он и его потомки.
Там где требуется высокая надежность уже давно используют другие ЯП. Например oberon, elixir и т.п.
Как вы правильно заметили "завоевал", просто у других ЯП не было достаточно ресурсов для подобной "войны".
Здравствуйте, varenikAA, Вы писали:
I>>Гораздо интереснее парадокс парадокса Блаба — люди, который согласны с парадоксом Блаба не понимают социальных и экономических причин, стоящих за популярностью языков программирования.
I>>Например, уверовавшему в парадокс Блаба нет смысла приводить аргументы про рынок труда.
AA>Речь не о зарабатывании денег на жизнь, а об эффективном инструменте.
Каким это образом можно игнорировать зарабатывание денех ?
Не желаешь посоревноваться? У меня есть задачка и рукастый фронтенд, пишет на крайне неэффективном, убогом языке, безо всяких алгебраических типов и тд и тд — жээсе и еще более убогом CSS "учится за пару часов". Есть задача, которая должна быть сделана и будет оплачена.
Одно условие — деньги получит только тот, кто сделает первым. В задание входит: функциональные требования, качество, сложность майнтенанса(майнтейнить — дописывать, дофикшивать будет студент, которые почти что программировать не умеет, при чем в фоне, изредка отвлекаясь от основной работы).
Берешься ?
AA>Понятно, что хочешь жить умей вертеться. Но для быстрого написания надежного кода(корректного с точки зрения логики) требуется ЯП, который форсит программиста AA>делать все правильно. Например, вместо интов использовать алгебраические типы, сравнивать записи по значению, а не по ссылке.
Об чем я и говорю — ты в очередной раз проигнорировал все, что я сказал. Это и есть парадокс парадокса Блаба.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, varenikAA, Вы писали:
I>>>Гораздо интереснее парадокс парадокса Блаба — люди, который согласны с парадоксом Блаба не понимают социальных и экономических причин, стоящих за популярностью языков программирования.
I>>>Например, уверовавшему в парадокс Блаба нет смысла приводить аргументы про рынок труда.
AA>>Речь не о зарабатывании денег на жизнь, а об эффективном инструменте.
I>Каким это образом можно игнорировать зарабатывание денех ?
бывает, что что-то просто нравится.
I>Не желаешь посоревноваться? Не, возраст не тот уже. На работе хватает задач.
I>Берешься ?
Здравствуйте, varenikAA, Вы писали:
AA>>>Речь не о зарабатывании денег на жизнь, а об эффективном инструменте.
I>>Каким это образом можно игнорировать зарабатывание денех ? AA>бывает, что что-то просто нравится.
Это единичные случаи. Остальные ходят на работу, что бы зарабатывать деньги. Закрыть потребности индустрии единичными фанатиками не представляется возможным.
:
А "любую функцию" можно? 
