Вышел язык программирования Racket 7.0

На жабе пиши. На самом деле это не так сложно как кажется

Даже с учетом загрузок по требованию, пейджирования и прочих серверных оптимизаций там сотни мегабайтов информации в клиент прилетают, есичо.

Но как? В браузер при нормальной архитектуре не может прилетать больше, чем по VNC, например. А сотню мегабайтов по VNC разве что за час можно накрутить.

Для того, чтобы сделать другой набор вьюшек (считай, страничек)? Ну-ну.

@media screen and (max-width: 600px) {
  div.example {
    display: none;
  }
}

То есть а самим управлять куда котекст должен протекать а куда нет ты не хочешь?

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

Первый раз слышу про этот язык

Тогда плюсы тоже умеют: в чём проблема скомпилить код того же gcc в статик либу, и потом вызывать её функции напрямую? Кстати, gcc весит всего 570кб, ещё меньше чем ребол

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

https://github.com/archimag/cl-closure-template

Почему это считается лиспом я не пойму?

А это и не считается. Точнее, считается не больше, чем любой другой потомок Scheme. А считать ли схему лиспом — вопрос очень философский.

Из-за скобок чтоль?

Да.

Reader-то хоть есть как отдельная стадия?

Конечно. https://docs.racket-lang.org/guide/hash-reader.html

Аналог eval-when?

Есть. (define-for-syntax ...) и (begin-for-syntax). Причём в отличие от лиспа побочные эффекты со стадии компиляции не протекают в стадию выполнения. В лиспе такого можно достичь, если компилировать в отдельном образе.

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

Чего-то не понял. Как это? Можно пример?

Но как? В браузер при нормальной архитектуре не может прилетать больше, чем по VNC, например. А сотню мегабайтов по VNC разве что за час можно накрутить.

Хе-хе. Попробуйте поработать с картографией по VNC :)

А ведь мы не только карты операторам показываем :)

@media screen and (max-width: 600px) {

Чо-та я в тоске...

Говорю ж: мобильные устройства требуют немножко других данных, отправляемых в другое время.

с библиотеками?

Ну ок, даже допустим если в теории это возможно, остается проблема использования результата работы GCC внутри текущей программы.

Плюс вопрос практичности, в теории в плюсах это можно, а на практике скорее всего будет невероятно геморно. А в реболе встроено несколько DSL которые на этом уже работают.

Вобщем изначальный вопрос был - первая ли ракета с этими DSL - объективно нет, не первая. Но ребол не взлетел, и, скорее всего, рокетчики пришли к этой идее сами, так что можно считать что первая, ничего страшного.

Чего-то не понял. Как это? Можно пример?

Ну вот тот же aif должен наружу показать it. На Racket выглядит так:

(define-syntax (aif stx)
  (syntax-case stx ()
    [(aif cond then else)
     (with-syntax ([it (syntax-local-introduce #'it)])
       #'(let ([it cond]) (if it then else)))]))

Хе-хе. Попробуйте поработать с картографией по VNC :)

А чем это отличается от любых других изображений? На 3Мбит/с можно даже видео на удалённом компьютере смотреть.

Говорю ж: мобильные устройства требуют немножко других данных, отправляемых в другое время.

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

На 3Мбит/с можно даже видео на удалённом компьютере смотреть.

Ну, то есть, Вы осознаете, что Вы только что договорились до гигабайта — полутора гигабайтов данных в час? А с учетом того, что пользователей, напомню, многие десятки тысяч — до ширины серверного канала в несколько терабит.

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

У меня возникает обоснованное подозрение, что Вы отвечаете, не читая.

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

Аналог eval-when?

Есть. (define-for-syntax ...) и (begin-for-syntax). Причём в
отличие от лиспа побочные эффекты со стадии компиляции не
протекают в стадию выполнения. В лиспе такого можно достичь,
если компилировать в отдельном образе.

8-O

syntax?

Причём в отличие от лиспа

Вы это что - выдаете за плюс и фичу :)

Смысл-то, чтобы «протекало» пользуясь вашей терминологией. Например, предвычисление в compile-time. Штатный CL через штатный механизм eval-when (:compile-toplevel).

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

А для таких приложений зачем вообще браузер? Не проще давать нормального клиента и отдельное мобильное приложение. Даже Java на порядок эффективней будет чем браузерное приложение.

У меня возникает обоснованное подозрение, что Вы отвечаете, не читая.

Другой набор вьюшек делается через CSS. А логика бэкенда по-идее должна быть хотя бы на User-Agent завязана, а не на ширину экрана. А то сделав окошко поменьше можно получить вместо эксельки «совершенно посторонние сущности».

В чём отличие Racket от Minimal Racket?

Другое дело, теперь ты действительно всё обосновал.

C=A*B... где A, B, C — массивы

А что именно здесь должно произойти, поэлементное перемножение? Если опустить подобное, то всё остальное это про Go.

Потому что медленные

Опять же, очень спорно про скорость. У твоих учёных нет бюджета на железо? И что именно критично медленно работает в Nim? Я про него ничего не знаю, кроме того, что говорят сами авторы и того, что я видел в одном бенчмарке. Из того, что вижу, делаю вывод, ним как минимум не тормоз.

Ну это не серьёзно. Целая одна книжка. По другим языкам материалов столько, что не прочесть и за несколько жизней.

Wir müssen die JavaScripten ausrotten. Es ist Zeit für C!

А для таких приложений зачем вообще браузер? Не проще давать нормального клиента и отдельное мобильное приложение. Даже Java на порядок эффективней будет чем браузерное приложение.

Могу привести условия конкурса :-) Но, вообще-то, у браузерных приложений есть один неоспоримый плюс — почти что zero cost delivery и весьма невысокую в современных условиях цену переносимости (да, я помню про IE11 :)), так что, я вполне понимаю людей, это условие вписавших.

Насчет того, что джава будет на порядки эффективней — нет, не будет, стоимость разработки сопоставимая.

Верьте мне, джава-клиенты (андроидные приложения) у нас тоже есть. Но вот, например, попытка вписать в список требований удаленные обновления, принудительно проводимые с сервера, радости у нас не вызвала...

Другой набор вьюшек делается через CSS.

Под каждой вьюшкой есть презентационная логика и моделька с данными. Данные нужно грузить по-умному (см. выше про их количество), вариант с «загрузить все, показать только нужное» не канает.

Коли так, одного лишь CSS с display:none недостаточно, на фоне остальной презентационной логики эти CSS-ухищрения милы, но, в целом, выигрыша особого не дают.

Ну и про завязки на U-A. Не делайте так, не надо.

syntax?

Это (eval-when (:compile-toplevel) ...)

Смысл-то, чтобы «протекало» пользуясь вашей терминологией. Например, предвычисление в compile-time. Штатный CL через штатный механизм eval-when (:compile-toplevel).

Ну нет.

(eval-when (:compile-toplevel) 
  (defvar *foo* 5))

приведёт только к тому, что переменная *foo* будет определена там, где файл компилируется, а не там, где загружается. Но так как в CL данные протекают, то при первом вызове (asdf:load-system :foo) всё будет работать. До выхода из образа. А потом внезапно поломается. Пока не удалишь foo.fasl.

А предвычислять и в Racket можно

(define-syntax (consts stx)
  (syntax-local-introduce
   #`(begin
       (define x 1)
       (define y #,(compile-time-calculation)))))

(consts)

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

Расовую пригодность автора на вакансию фюрера опустим, а вот язык у него однозначно унтерменский.

И назвать экземпляр этого класса «class» уже нельзя.

По-моему, MOP позволяет это сделать в любой момент. В любом случае, проблема какая-то искуственная.

По-моему, MOP позволяет это сделать в любой момент

Я в том смысле, что (setf class (make-instance class)) затрёт библиотечную переменную, содержавшую информацию о классе.

В чём отличие Racket от Minimal Racket?

Minimal Racket включает только минимум, чтобы запустить raco pkg install. То, что в дистрибутивах линукса называют netinst.

Это каноническая книга, в которой есть всё, типа Страуструпа для С++. Естественно, есть и другие книги, для начинающих. Они не очень свежие, поскольку язык меняется медленно (где-то в начале этой темы ты сам писал что это неплохо). Есть свои форумы, есть раздел на stackoverflow и т.д.

По другому сообщению:

А что именно здесь должно произойти, поэлементное перемножение?

Да, я же написал, поэлементные операции.

Если опустить подобное

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

это про Go

Где бы ещё найти книжку типа Numerical recepies для Go... Может быть, напишут, тогда и поговорим. Ну и по гибкости операций с массивами он не дотягивает до Фортрана, потому что создавался не для этого.

Опять же, очень спорно про скорость. У твоих учёных нет бюджета на железо?

Всё, это уже несерьёзно, ты и сам, я думаю, понимаешь. Дело не в бюджете. Если вылизанная и оптимизированная программа на Фортране считает некоторую задачу на одном из мощнейших кластеров в Великобритании в течение суток, то сколько будет считать программа на Питоне (которая ещё не написана и не будет написана, ну ладно), страшно представить.

Nim

Ещё не стабилизировался. Не надо рассказывать, что на нём уже написали текстовый редактор, плеер, ОС и т.д. В науке разработка ведётся не постоянно, поэтому язык должен быть стабильным. Ещё были какие-то заморочки с ним, не могу вспомнить.

_________

Резюмируя, хочу сказать, что, конечно, новые языки — это замечательно, но часто нужно, чтобы была просто каменная стабильность и топорная простота без лишних замечательных функций. Фортран можно выучить за два часа, даже если ты физик и никогда не программировал. С другими языками такого не получится. Наверное, не надо пихать языки для системного программирования типа Rust и Go туда, где им не место. Nim — надо ждать. Язык с версией 0.18 не внушает доверия. Это не обязательно плохо. Я не люблю Фортран и стараюсь его обходить стороной, но понимаю, где и зачем он нужен и даже незаменим. Программы пишут разные люди, а не божественные программисты-гимнасты. Код в науке — не конечная цель, а промежуточный шаг, который желательно выполнять инстинктивно и не приходя в сознание.

Честно говоря, мне кажется, что мы достаточно замусорили тему про Racket Фортраном и прочим, поэтому если хочешь дальше спорить, то создай отдельную тему и вызови меня туда.

Плюс вопрос практичности, в теории в плюсах это можно, а на практике скорее всего будет невероятно геморно.

безусловно :)

А, ты об этом. В таком случае, если ты создаешь безымянный класс, чтобы потом обращаться к нему по имени переменной, то явно делаешь что-то неправильно.

и тех, что не вымирают только из-за упёртости их носителей.

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

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

будто они в фоне климат земли на сто лет вперёд общитывают.

Не обсчитывают, а создают

Вопрос не очень по адресу, случаи, когда я писал гуёвые приложения, можно пересчитать на пальцах одной руки. Но я бы выбирал не язык, а тулкит и готовый набор необходимых виджетов. Мб на джаве и можно приличный гуй писать, не знаю, но я не вижу чем бы она была лучше плюсов.

но это java. И программы получались несколько медленные

Ну с питоном сильно лучше-то не будет, однопоток же. Да и то, что я видел (в коде) на PyQt выглядело ещё хуже джавы.

Это про любой язык можно сказать

Не все языки нужно и можно выбросить. Попробуй выбросить JS из веба, например.

носители сишки перестанут упираться и перейдут на другой язык

А на что сишку поменять? На плюсы? На сишке всё самое важное написано, она будет последним языком среди кандидатов на забвение.

Фортран можно выучить за два часа

Можно за один. На экзамене. Сдавал Поттосину.

Сын сейчас перед экзаменами в магу МФТИ джаву учил за два дня. Сдал как-то :)

то сколько будет считать программа на Питоне

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

Nim
Ещё не стабилизировался

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

поэтому если хочешь дальше спорить

Нет, мне было нужно обоснование, ты его уже дал в предыдущем ответе.

Не все языки нужно и можно выбросить.

Ну так и выражайся точнее тогда. Потому что ранее ты сказал:

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

А под это подпадают практически все языки.

На самом-то деле, если начать раскапывать твоё утверждение, то наверняка окажется, что ты против тех языков, которые либо тебе лично не нравятся/не понятны, либо не нравятся/не понятны некоему абстрактному большинству (ты же не хочешь быть не таким как все). И никакой более объективной оценки ты дать не можешь. Prove me wrong.

языки для системного программирования типа Rust и Go

Го не системный.

Ну мне казалось, что он для systems programming, в том смысле, в котором Страуструп употребляет это выражение для С++. Но если это не так, то готов согласиться.

А под это подпадают практически все языки.
если начать раскапывать твоё утверждение

Не нужно ничего раскапывать, яснее было немного выше.

наверняка окажется, что ты против тех языков, которые либо тебе лично не нравятся/не понятны, либо не нравятся/не понятны некоему абстрактному большинству

Откуда взялись предпосылки для такого предубеждения?

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

UPD. Изначально вставил не ту ссылку, исправил.

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

Как-то ведь к нему нужно обращаться. Вся ветка началась из сравнения доступа к классу по имени/символу (lisp-n) или по значению из переменной (lisp-1).

Доступ по значению из переменной забирает имена из пространства имён переменных, зато позволяет работать с классами как с обычными значениями. Даже иметь классы, существующие только внутри отдельной функции.

Это определение очень сильно растянули в последнее время, так что возражать не стал, но плюсую.

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

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

На питоне с нужными либами, которые написаны профессионалами, небось ещё и сильно быстрее работать будет, чем наляпанный не профессионалами код на любом другом языке.

Посмотри, что лежит под тем же NumPy (спойлер: Фортран). И, пожалуйста, просто поверь, что не для всех задач есть готовые библиотеки, тем более на Питоне. Особенно, если задачу никто до тебя не решал (оказывается, в науке такое бывает).

Nim

Это я вообще зря написал, к нему претензии, действительно, не про скорость. Та же работа с массивами в нём более примитивная, чем в Фортране. Насколько я помню.

Нет, мне было нужно обоснование, ты его уже дал в предыдущем ответе.

Можно теперь не закапывать Фортран и позволить учёным писать на нём свои программы?

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

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

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

вся суть которых в большинстве случаев состоит в дополнительном сахарке

Если они полностью интероперабельны со старыми, то что в них плохого? А если не полностью, значит, наверное, там не только сахарок.

не для всех задач есть готовые библиотеки

И нет серебряной пули, которой ты выставляешь Фортран, среди языков. Mathematica, Матлаб, тот же NumPy (да, я знаю про лапак, но его же конечный юзер не видит) и чего только не нагородили уже, чтобы твоей пулей не пользоваться.

Можно теперь не закапывать Фортран и позволить учёным писать на нём свои программы?

Я понял твою позицию, но ты меня не убедил.

Откуда взялись предпосылки для такого предубеждения?

Из большого опыта пассивного и активного участия в интернет-дискуссиях. Тем более на лоре, были бы мы сейчас, например, на lambda-the-ultimate, я бы ещё задумался над твоими словами.

Живые устоявшиеся языки выполняют свою задачу и никому не мешают,

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

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

И кто же будет проводить экспертную оценку на предмет наличия истинных полезных инноваций в очередном «хипсто-язычке»?

Моя позиция заключается в то, что чем меньше языков, тем лучше. Старые и полумёртвые должны окончательно умереть, а сотни новых хипстерских, которые не решают никаких фундаментальных проблем и являются лишь следствием них-синдрома, не должны рождаться. Энтропия растёт феерически, пора тормозить.

Честно поискал, в чём я могу тут с тобой согласиться. Не нашёл.

Если на языке кто-то пишет — значит он кому-то полезен, с чего бы ему окончательно умирать.

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

Учиться надо больше, да. Причём фундаментальным концепциям. Тогда и новый язык не придётся изобретать из-за незнания, что уже существует нужный, хоть и под другим соусом. И выбрать язык под задачу тоже можно будет исходя из знаний, какой что умеет, а не из того, что нынче модно и мейнстримно.

Да, если ты сторонник того, что «всё нужное и полезное уже придумано, сейчас думать нечего, надо тупо работать», то скажи сразу. У меня тогда больше вопросов к тебе не будет.

Если они полностью интероперабельны со старыми, то что в них плохого?

Фрагментация это всегда плохо, тем более без веской причины. Он уже чудовищна, со временем будет только хуже.

там не только сахарок

Если оно решает какие-то фундаметальные проблемы, то да, а компилируемое под явамашину и в джаваскрипт — ничего не решает.