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

Фундаментальными являются проблемы реального мира, те, что не решаются или не решаются достаточно эффективно применением определённого набора практинк и инструментов.

Твоё определение настолько неопределённо (pun intended), что сводится к абсурду в одно движение.

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

Я пытаюсь понять, может быть критерий так называемой тобой «фундаментальности» проблемы действительно существует в твоей голове, и ты просто затрудняешься его выразить. Тогда мои вопросы могут помочь.

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

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

Унификация.

Это не ответ на вопрос, а повторение утверждения из которого он и возник.

стандартизированные винтики-функционалы единой системы? а причём здесь цивилизованность?

это одно из необходимых свойств для цивилизованности

В этом треде WitcherGeralt уже был замечен в склонности к технофашизму.

буллшит

нет, конечно, возможен подход «мы самое цивилизованное общество, потому что про другие мы ничего не знаем и знать не хотим»

«и нечего тут нам скрепы расшатывать»

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

WitcherGeralt, ЛОР должен умереть?

Вот вам смешно, а вчера мне начальник (далекий от it человек) пытался объяснить какой рапорт хочет, сначала на человечьем, я не понял, он написал «group by ...» и все сразу стало ясно :)

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

От науки у меня выходной вчера был :)

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

Либо просто ты тормозишь. Я не затрудняюсь его выразить, я его уже выразил. Затрудняюсь я только понять троллишь ты или тупишь. В каком виде определение тебя устроит? Сформулируй требования.

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

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

Являются ли проблемы сложности языка и дефицита кадров проблемам жавы? Не являются.

Нет. Цивилизация открывает границы, сглаживает разницу между народами и объединяет их. А ценность разрозненности (разных языков и культур) как раз таки и следует обосновать.

Цивилизация открывает границы, сглаживает разницу между народами

Мы тут мультикультурное общество строим, знаете ли.

ну это такой подход к понятию «цивилизация» в духе Гитлера или наполеона

как раз-таки цивилизационной ценности моноязычной изоляции примеров нет, как и экспансионного насаждения одного языка.

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

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

Как раз к теме моего предыдущего комментария. Чуть что и фошист. Мб это всё же проблемы восприятия?

Языки работают по разному, в плане того, что думать приходится по другому. Говорить на флективном (русский), аналитическом (английский) и агглютинативном (венгерский, турецкий) — это три совсем разных процесса. Ещё до кучи, буквально (слово в слово) непереводимые идиомы, которые выглядят гармонично в одном языке и полностью рафинируются при переводе. В этом и ценность. Поэтому бесят всякие фашиствующие ушлёпки, которые заявляют, что, например, только русский язык богат, а остальные бедные. Разнообразие порождает новое разнообразие, новые неизвестные формы, которые, как может оказаться, гораздо более подходящи под возникшие условия и требования. Унификация его уничтожает; хотя понятно, что она необходима в меру, чтобы не было разброда как в Линуксах, или кучи проприетарных разъёмов вместо нормального microUSB или type-c, что ещё лучше.

Чуть что и фошист.

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

Затрудняюсь я только понять троллишь ты или тупишь.

Обещаю тебе, что я не троллю и не туплю. Я лишь пытаюсь вытащить из тебя объективный критерий, которым ты пользуешься для определения нужности/ненужности языка. Либо увидеть, что такого критерия нет и это просто твой субъективный вкус. Для этого я указываю тебе на недостатки твоих определений, чтобы ты их мог уточнить.

В каком виде определение тебя устроит? Сформулируй требования.

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

Если брать фундаментальную проблему ассемблера из той же плоскости, то это будет не капризный разработчик, а сложность языка

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

Являются ли проблемы сложности языка и дефицита кадров проблемам жавы? Не являются.

Являются ли проблемы сложности языка и дефицита кадров проблемами ассемблера?

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

Да уж было бы не плохо. Пока производительность у Racket выглядит очень бледно.

Я для интереса решил сделать простейшую проверку производительности: вычислять значение некой точки множества Мандельброта и посмотреть зависимость времени исполнения от числа итераций.

В соревновании участвовали Racket, Guile, Python3, SBCL и Scala как представитель компилируемых языков.

Результат в виде графика: https://i.imgur.com/BRmsKkX.png

В виде таблицы:

       GUILE      SBCL      PYTHON3   RACKET    SCALA
 10^0:  0.01      0.00      0.02      0.18      3.94
 10^1:  0.01      0.00      0.01      0.16      1.14
 10^2:  0.01      0.00      0.01      0.16      0.92
 10^3:  0.01      0.00      0.01      0.16      0.86
 10^4:  0.01      0.00      0.02      0.16      1.15
 10^5:  0.02      0.00      0.03      0.17      1.11
 10^6:  0.12      0.00      0.12      0.33      0.89
 10^7:  1.14      0.07      0.98      2.29      1.94
 10^8:  12.29     0.70      11.21     22.71     12.10
 10^9:  119.39    6.92      103.17    161.20    137.79
 10^10: 1377.09   72.89     1160.76   1830.31   1454.14
 10^11:           753.88    10050.11
 10^12:           7874.07
 

P.S. Результаты немного разнятся от запуска к запуску, поэтому цифры в таблице и графике слегка разные. Но порядок соблюдён.

Однако, SBCL выглядит на фоне остальных очень хорошо (хотя, конечно, (safety 0), вот это вот всё). Добавь в табличку, пожалуйста, другие схемки: Chicken и Gambit. Если тебе не сложно, конечно.

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

на столько богат
на столько

Настолько* же, ну.

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

Богатство языка зависит не от его национальной принадлежности, а от его носителя. Например, язык Пушкина или Шекспира богат, а язык рандомного русского или британского гопника беден.

PS. «настолько» в данном случае пишется слитно.

поправь звезды же есть

это специально для усиления эффекта

Я в шоке от результата, показанного Scala. Gambit и Chicken можно будет добавить позже. Никогда с ними дела не имел, нужно проверить.

на некоторых задачах старые ракетки шустрее шевелятся, чем Chez,

Возможно для этого нужны задачки посложнее простой арифметики.

все должны знать и учить английский и сишечку

Это ты придумал.

то есть, фортран и паскали пусть живут, а понимание важности английского не является критерием определяющим цивилизованность?

замены текущей системы времени выполнения и поддержки множества систем времени выполнения

Очень круто (потому что ННП :))) )

замены текущей системы времени выполнения и поддержки множества систем времени выполнения

Очень круто (потому что ННП :))) )

replacing Racket’s current runtime system and supporting multiple runtime systems

Так яснее?

Gambit и Chicken можно будет добавить позже. Никогда с ними дела не имел, нужно проверить.

Я тоже не имел. Сейчас вот разобрался (не без труда) как скомпилировать нативный бинарник Chicken'ом. Результат удручает: Chicken в твоём тесте намного медленнее Guile. Нативный код быстрее, чем исполнение в интерпретаторе, но не радикально. Может быть, конечно, там есть какие-то трюки компиляции (типа (safety 0) у SBCL), о которых я не знаю.

строго на два подмножества

Это бред, так не бывает, и ты это знаешь. Следовательно, ты — тролль, лжец и, вероятно, девственник. Можешь считать это сливом, но никакой «чёткой однозначности», которую признает каждый, всё равно никогда не будет. Применять критерии будет человек, а разные люди дадут разные оценки, применяя даже самые чёткие критерии. Даже изначально соглашаясь с критеями, применив их, человек может испытать невыносимую боль пониже спины из-за того, что результаты не вписались в его картину мира. Есть далеко не нулевая вероятность, что человек попытается устранить эту боль, оспорив критерии, либо извратив их, подменяя понятия, или применяя другие приёмы демагогии, а в крайнем случае он притворится идиотом. В качестве примеров могу порекомендовать дебаты Лоуренса Краусса, Билла Ная и Кристофера Хитченса с креационистами.

Но ради всеобщего фана я поиграю в твою игру.

Обойдёмся всего тремя критериями из того, что я уже назвал:

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

Тест-кейсы из уже названного же:

Питон. Медленный, однопоточный, и хрен бы с ней с медленностью, но на однопотоке точно далеко не уедешь. На серверах решается мультипроцессингом и прочими сельдереями, биндингами (т.е. применением других языков, а значит уже вне рамок питона), а также докупкой самих серверов. Эффективно ли решение? Кому как, но в целом сомнительно, учитывая миллион статей с success story о том, как кто-то, переписав сервис на Go, выкинул 9000 серверов, оставив всего 3. А ещё на питоне умудряются писать десктопные приложения, там эта проблема (если она вообще встаёт) решается примерно никак.

А — ограничивает область применения питона там, где важна производительность, и особенно там, где ограничены ресурсы; Б — решается не эффективно.

Фундаментальненько? Считаю, что да.

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

Ты ок с этим

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

Являются ли проблемы сложности языка и дефицита кадров проблемами ассемблера?

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

А — область применения ужасно ограничена; Б — это не решаемо.

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

Ситхи в треде, абсолютно всё нужно возвести в абсолют.

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

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

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

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

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

Собственно, ты об этом уже писал

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

Да, это проблема разработчика. И это проблема реального мира, поскольку разработчик вполне реален. A решает он эту проблему так, как ему кажется эффективнее. Например, выбирая более удобный инструмент.

Но это же и есть слабое место твоих критериев

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

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

Нет. Сравнивая джаву и асм мы сравниваем вещи разного порядка сложности применения. Сравнивая джаву с котлином мы сравниваем вещи одного порядка.

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

P.S. Забавно, что ни ты, ни я, не подумали о том, что мало самих критериев, нужно описывать ещё и алгоритм их применения.

Либо ты не понял как их применять

Ты не написал, как их применять, а сам я посчитал их отдельными.

Нет. Сравнивая джаву и асм мы сравниваем вещи разного порядка сложности применения. Сравнивая джаву с котлином мы сравниваем вещи одного порядка.

Чтобы не путаться, давай сравнивать переходы асм->си и джава->скала.

Не знаю, как именно ты определяешь здесь «порядок», но я здесь вижу один и тот же эволюционный процесс: переход от менее высокоуровнего языка к более высокоуровнему с целью повысить удобство и эффективность работы. Почему ты считаешь переход асм->си приемлемым, а джава->скала нет, мне по-прежнему не понятно. Между ними может быть есть количественная разница (это не тот ли «порядок», который ты как-то меряешь?), но принципиальной, качественной разницы нет. Может быть первый переход тебя не волнует только потому, что он уже давно завершился?

Я вполне верю, что на скале некоторые люди пишут лучше чем на джаве (при этом ещё и найдутся те, у которых ровно наоборот), но это не проблема джавы, а проблема этих некоторых разработчиков

Замечу, что это и не проблема скалы. В обоих случаях это проблема разработчиков.

Я вполне верю, что на скале некоторые люди пишут лучше чем на джаве

Так и почему ж ты хочешь отнять у них этот удобный им инструмент и всучить неудобный? Чтобы больше работали и не выёживались? Тут мне опять начинают мерещиться лозунги вроде «аrbeit macht frei».

На обработке чисел chez быстрее. Думаю, на обработке комплексных чисел радикально быстрее. Кстати, на этом примере удивлён отставанием скалы.

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

С чего это? Веб-форум: https://asm32.info/fossil/repo/asmbb/index написан за месяц.

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

Настолько же, насколько им является фортран или си.

На моём компьютере (Racket 6.11, Python 3.5.1+) твои примеры:

$ time racket mand.rkt 10000000 1

real    0m6,321s
user    0m6,108s
sys     0m0,224s

$ time python3 mand.py 10000000 1

real    0m4,887s
user    0m4,820s
sys     0m0,020s

Если проставить типы для Racket (иначе он комплексную арифметику делает в предположении, что там могут быть числа произвольной точности), тогда

$ time racket mand2.rkt 10000000 1

real    0m1,733s
user    0m1,636s
sys     0m0,100s

$ cat mand2.rkt
#lang racket/base
(require racket/unsafe/ops)

(struct complex (r i))

(define c (complex 0.04 0.01))

(define (complex+ a b)
  (complex (unsafe-fl+ (complex-r a) (complex-r b))
           (unsafe-fl+ (complex-i a) (complex-i b))))

(define (complex* a b)
  (complex (unsafe-fl- (unsafe-fl* (complex-r a) (complex-r b))
                       (unsafe-fl* (complex-i a) (complex-i a)))
           (unsafe-fl+ (unsafe-fl* (complex-r a) (complex-i b))
                       (unsafe-fl* (complex-i a) (complex-r b)))))

(define (mandelbrot n z)
  (if (unsafe-fx= n 0) z
      (mandelbrot (unsafe-fx- n 1) (complex+ (complex* z z) c))))

(let*
    ((n (string->number (vector-ref (current-command-line-arguments) 0)))
     (debug (string=? "debug" (vector-ref (current-command-line-arguments) 1)))
     (z0 (complex 0.0 0.0))
     (z (mandelbrot n z0)))
  (when debug (printf (number->string (unsafe-make-flrectangular (complex-r z) (complex-i z))))))

До sbcl, конечно, далеко, но хотя бы быстрее питона.

На Racket 7.0:

$ time /usr/racket/bin/racket mand.rkt 10000000 1

real    0m5,692s
user    0m5,600s
sys     0m0,104s
$ time /usr/racket/bin/racket mand2.rkt 10000000 1

real    0m1,790s
user    0m1,740s
sys     0m0,060s

Неоптимизированный стал лучше, оптимизированный — хуже.

Добавьте java в тест.

OpenJDK 11:

$ time java Mandelbrot 10000000 1

real    0m0,447s
user    0m0,508s
sys     0m0,044s

В 3 раза быстрее, чем Racket.