LINUX.ORG.RU

DrRacket and elisp окончательно запутался

 ,


0

3

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

#lang racket
(define *distance-lst* (list 1 2 3 4 5 6))

(define *A-distance* 3)
(define *left-A-lst* '())

(define d-lst (length *distance-lst*))
(define *output-lst* '())
(define (slice input-lst a output-lst)
  (if (< (first input-lst) a)
      (slice (cons (first input-lst) output-lst)
             a
             (set! input-lst (rest input-lst)))
      output-lst))
     
;;(define (split-lst lst-input a lst-output)
;  (if (< (first lst-input) a)
 ;     (split-lst (set! lst-input (rest lst-input))
  ;                     a
   ;                    (set! lst-output
    ;                         (cons
     ;                         (first lst-input) lst-output)))
 ; lst-output))

(slice *distance-lst* *A-distance* *left-A-lst*)

и вот на elisp и работает как надо, задолбало, что не так не могу понять эту ракету

(defun slice (input-lst a output-lst)
(if (< (car input-lst) a)
(slice (cdr input-lst) a (push (car input-lst) output-lst))
output-lst))

(nreverse (slice '(1 2 3 4 5 6) 5 '()))
Ответ на: комментарий от DarkEld3r

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

В некоторых реализациях, например СБЦЛ, ты имеешь настолько полный доступ к внутренностям, что можешь переопределять вообще всё. ВООБЩЕ ВСЕ! Есть возможность определять, скажем так, «протокоманды» в терминах ассемблера, То есть, на уровне команд процессора.

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

anonymous
()
Ответ на: комментарий от no-such-file

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

Лет 8-10 назад, был здесь один «лиспер» (хотя он больше тусовался на джаббер.ру и на хабре). Начинал он с клепания сайтов ПХПшником-самоучкой. Начитавшись Архимага (нифига не лиспер, хоть и активнейший популяризатор лиспа), и нескольких (настоящих) лисперов в ЖЖ, решил, что смена языка выведет его в элиту программистов. Видел я его код… (дальше 15Мб нецензурной лексики) Динамическое переопределение слотов объекта функцией, генерируемой их макроса, генерируемого из макроса. Просто потому, что МОП позволяет подобные расширения, а в конференции нашлись пару реально крутых лисперов, набросавших ему решение, по его идиотскому вопросу: «а возможно ли в лиспе…»

Радоваться надо, что лисп ограниченно популярен.)))))

anonymous
()
Ответ на: комментарий от anonymous

Я извиняюсь, а ты, анонимус, кто? Интересно. Мне известно, что лавсан: а.) долго знаком с лиспом; б.) хоть что-то на нем писал; в.) имеет какой-никакой кругозор относительно других ЯП, а значит, может сравнивать.

Ты бы еше Дена73 лиспером назвал. ЛОЛ

Назвал бы. Сомнительно, что

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

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

И коли на то пошло, ты сам считаешь работу в образе единственной реальной киллер-фичей лиспа? Не никому не нужная пое*ень вроде переопределения ридер-макры, которой никто не пользуется (кроме den73), и всех остальных цацок, а разработку и отладку живой программы.

Virtuos86 ★★★★★
()
Ответ на: комментарий от no-such-file

Потенциал для создания проблем конечно есть, но проблемы пока нет.

Кто-то мне уже пытался доказать несколько лет назад, что библиотеки hu.dwim.* использовать нельзя, так как это «неправильный лисп» и писать в стиле

(def special-variable *make-persistent-instances* #t
  "True means make-instance will make the new instance persistent by default.")

(def (macro e) with-making-persistent-instances (&body forms)
  `(let ((*make-persistent-instances* #t))
     ,@forms))

ни в коем случае нельзя.

я просто пытаюсь объяснить (себе в т.ч.) почему они не вполне успешны

Э??? Количество программистов на расте и даже хаскеле гораздо больше, чем на Common Lisp.

Эту неуспешность я вижу в том, что сложность их абстракций не востребована.

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

есть ли такие задачи в принципе, пусть не массово, а вообще

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

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

Дескать, сбкл ноне в отстающих, ибо в гцц/шланг какую-то фичу прикрутили, которой в лисповом компиляторе нет.

Тут как вопрос про «глобальное потепление» или «глобально похолодание». Ответ от масштаба зависит.

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

конечно, тот же хаскель сам выведет тип

У хаскеля свои тараканы типизации: zip2, zip3, …, curry2, curry3, …

monk ★★★★★
()
Ответ на: комментарий от anonymous

на примере loop-а ты объяснишь что такое монада вообще

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

loop – просто наглядный пример для работы с монадами-последовательностями.

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

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

Где-то я уже это слышал. Только там было про идеи коммунизма…

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от monk

Мозилловцы выяснили, что подавляющая доля ошибок - работа с памятью

Ну и как, они переписали свой браузер на расте? Стал ли он качественно лучше чем хром?

Нынче для успешного языка нужна корпорация за ним

Нужен большой коллектив. А уж как этот коллектив образуется, по корпоративному принципу (по экономическим причинам), или по желанию (по эстетическим причинам) - дело десятое.

Количество программистов на расте и даже хаскеле гораздо больше, чем на Common Lisp.

А если посчитать с 58 года?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

Так с тем что есть всё так, только непривычно. Всё равно, что с Бейсика на Си переходить (а зачем типы описывать? а зачем обязательно переменные объявлять, а зачем всякие скобочки/звёздочки/прочая псевдографика? это же так неудобно!).

Возможно придумают более лаконичный метод описания времён жизни. Например, в стиле вывода типов Haskell: если существует непротиворечивое решение по неуказанным временам жизни, значит оно верное.

monk ★★★★★
()
Ответ на: комментарий от no-such-file

Ну и как, они переписали свой браузер на расте?

Пишут.

Стал ли он качественно лучше чем хром?

Конечно. Быстрее и с меньшим количеством ошибок.

А если посчитать с 58 года?

Так в 58 году Rust’а не было. Выбирать было не из чего. :-)

monk ★★★★★
()
Ответ на: комментарий от monk

Всё равно, что с Бейсика на Си переходить

Ну всё опять по кругу. Зачем переходить с Бейсика на Си я могу понять, потому что это сразу даёт очевидный прирост скорости исполнения. Т.е. это с одной стороны даёт желаемые результаты, а с другой стороны является для достижения этих результатов абсолютно необходимым, неизбежным. А зачем переходить на раст непонятно, потому что очевидных изменений нет, но новый «неудобный матан» применять заставляют. Ещё раз повторить мои вопросы что ли?

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от no-such-file

У меня другая информация

До перехода было ещё медленнее. Я дал замер по компоненту, который уже полностью переписали (quantum css).

А не долго ли?

С++ версию писали дольше.

monk ★★★★★
()
Ответ на: комментарий от no-such-file

А зачем переходить на раст непонятно

Уменьшается в 2-4 раза количество ошибок.

За всё время в CSS-компоненте Firefox обнаружено 69 ошибок безопасности. Если бы у нас была машина времени и мы могли с самого начала написать его Rust, то 51 (73,9%) ошибка стала бы невозможной. (c) Mozilla

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

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

monk ★★★★★
()
Ответ на: комментарий от monk

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

Тут конечно можно возразить, что не совсем понятна причина эффекта. Если бы эту часть полностью переписали на том же C++, не было ли бы такого же эффекта просто из-за выкидывания древнего говнокода?

С++ версию писали дольше.

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

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

Уменьшается в 2-4 раза количество ошибок.

Спорное утверждение. Во-первых новые принципы приносят свои, новые ошибки. Пока что непонятно что лучше старые ошибки, или новые. Во-вторых есть другие способы ловли ошибок - линтеры, анализаторы кода, организация разработки через тестирование и т.д. В третьих не совсем корректно заявлять только об ошибках в конечном продукте. Т.е. если ошибка не проходит в конечный продукт, но на её выявление и исправление в процессе разработки нужно много времени, то от этого лучше не становится. Иначе говоря если бы «51 (73,9%) ошибка стала бы невозможной», но при этом «модуль CSS» так и не был бы выпущен всё это время по причине наличия известных ошибок, то это было бы даже хуже.

тем более сложные системы на нём пишут

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Если бы эту часть полностью переписали на том же C++

Дважды пытались. Не получилось. https://habr.com/ru/post/445670/

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

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

Во-первых новые принципы приносят свои, новые ошибки.

Класса ошибок, которые проявлялись бы в Rust, но не проявлялись в C++ пока не обнаружено.

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

Это всё использовалось. При этом 51 из 69 ошибок можно было бы избежать, если бы использовался Rust.

но на её выявление и исправление в процессе разработки нужно много времени

Она проявляется при компиляции. И сразу видно место ошибки.

Т.е. на крестах писали условно 1000 человек, кое как справлялись, переписали на расте, теперь нормально справляются 500.

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

Кстати, раньше с той же мотивацией переходили на Java/C#. Тоже получалось безопаснее. Можно было тем же количеством программистов писать более сложные системы. Но с потерей производительности.

monk ★★★★★
()
Ответ на: комментарий от no-such-file

Вот у monk пример на лиспе

(def special-variable *make-persistent-instances* #t
  "True means make-instance will make the new instance persistent by default.")

(def (macro e) with-making-persistent-instances (&body forms)
  `(let ((*make-persistent-instances* #t))
     ,@forms))
И я не понимаю, что за `(let ... или ,@forms? В лиспе даже типы не обязательно проставлять, откуда этот ужас? Запятая и @, «`» перед круглой скобкой (кстати, я забыл, как называется «`», и яндекс мне выдал «Синтаксическая ошибка», лол; гугл справился) — это нормальный синтаксис для динамического ЯП? Закапывайте, не нужно.

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

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от anonymous

а ты, анонимус, кто?

Пук? Кек.

Что за агрессия?

Ну, ты сказанул))) Ты бы еше Дена73 лиспером назвал. ЛОЛ

Лавсан - крестовик. Или шарпер. Но никак не лиспер - он не чувствует язык, не умеет писать идиоматический код. Хотя, знает гиперспеку и внутренности СБЦЛ.

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от monk

сразу видно место ошибки

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

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

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

Гугл как-то справляется без раста выпуская аналогичный продукт (ИМХО лучший, но это уже вкусовщина). Если бы эффективность разработки у мозиллы была реально выше, то во-первых эту практику тут же переняли бы другие, а во-вторых в мозиллу рекой полились бы инвестиции.

no-such-file ★★★★★
()
Ответ на: комментарий от Virtuos86

не понимаю, что за

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

забыл, как называется «`»,

Это quasiquote, а ,@ это unquote-splicing

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от Virtuos86

определение «костыля» дай

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

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

забыл, как называется «`»,

Это quasiquote, а ,@ это unquote-splicing

Неважно, как называются эти костыли, неужели нельзя было обойтись без них? В пуфоне ничего такого нет, все довольны.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Неважно, как называются эти костыли, неужели нельзя было обойтись без них?

Было бы намного многословнее

В пуфоне ничего такого нет, все довольны.

Там и макросов нет. А в rust есть. Используется $ и *.

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

В пуфоне ничего такого нет, все довольны.

Там и макросов нет. И все довольны.

неужели нельзя было обойтись без них

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

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

Понимаешь, на любой объект в расте в каждый момент времени можно иметь либо одну мутабельную ссылку, либо несколько иммутабельных. Поэтому можно одну иммутабельную ссылку отправить в split, а другими пользоваться. А с мутабельной ссылкой так не выйдет. Запулил в функцию и жди возврата. Какой обобщенный split ты тут предложишь? Это относится к концепции borrowing, заимствования. И нет, это не костыль, это превентивная мера безопасности, проявляющаяся при многопоточном программировании.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)
Ответ на: комментарий от no-such-file

хотим сделать «безопасный язык», …, но при этом добавляем в язык unsafe.

unsafe есть во всех безопасных языках. Как минимум, потому что необходим FFI.

пишем функции отдельно для мутабельных и иммутабельных типов

они отличаются только возвращаемыми значениями. Вот в лиспе ведь тоже все функции обрабатывают произвольные значения. Но сделаны отдельные функции mapcar и mapc.

monk ★★★★★
()
Ответ на: комментарий от monk

Неважно, как называются эти костыли, неужели нельзя было обойтись без них?


Было бы намного многословнее

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

В пуфоне ничего такого нет, все довольны.


Там и макросов нет. А в rust есть. Используется $ и *.

И это ровно та вещь в себе, которая в расте реально ужасна, если заглянуть в потроха.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Общие слова. Намного насколько?

(def (macro e) with-making-persistent-instances (&body forms)
  `(let ((*make-persistent-instances* #t))
     ,@forms))

=>

(def (macro e) with-making-persistent-instances (&body forms)
  (quasiquote 
    (let ((*make-persistent-instances* #t))
      (unquote-splicing forms))))

В Racket можно прямо так и писать.

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

в расте ансейф изначально есть

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

Понимаешь

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

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

Здрастье, приехали. А разве раст не ради этого сделан? Разве необходимость unsafe возникла не потому что нужно взаимодействовать в внешним, небезопасным кодом, а внутри раста всё можно сделать безопасно? @monk по-моему совершенно справедливо отметил, что ffi это тоже самое, ну и наоборот unsafe это такой ffi.

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от Virtuos86

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

Так и было. В 58 как-то некомфортно было на пишмашинке ремингтон в качестве терминала настукивать столько буков.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Ага, ясно.

@monk по-моему совершенно справедливо отметил, что ffi это тоже самое, ну и наоборот unsafe это такой ffi

Он и монаду на примере loop объяснял, а потом оказалось, что демонстрировал, что list comprehensions это такая специальная форма do-нотации для списков, потому что список это моноид. В общем, я бы уточнил, что он имел в виду. Кстати, его аргумент о FFI как о минимум одном применении ансейфа ты что-то проигнорил.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)
Ответ на: комментарий от no-such-file

И что? До сих пор настукивают? А типичные борщелисповские километровые идентификаторы with-making-persistent-instances не устают набирать?

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Не сказал бы, что стало хуже.

Справедливости ради, видел макросы на Scheme которые именно в таком стиле и написаны:

(define-syntax swap!
  (lambda (e)
    (syntax-case e ()
      ((_ a b)
       (let ((a (syntax a))
             (b (syntax b)))
         (quasisyntax
          (let ((temp (unsyntax a)))
            (set! (unsyntax a) (unsyntax b))
            (set! (unsyntax b) temp))))))))
monk ★★★★★
()
Ответ на: комментарий от no-such-file

Это проблема системщины. Раст тут не при чём.

RazrFalcon ★★★★★
()
Ответ на: комментарий от monk

Идиоматический аналог:

let path = std::env::args().nth(1)?;
let contents = std::fs::read_to_string(&path).ok()?;
let words: usize = contents.lines().map(|line| line.split_whitespace().count()).sum();
println!("{} words found", words);
RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Идиоматический аналог

Как бы и то было не аналог, потому что оригинал принимал опции и считал строки/слова/символы (в зависимости от опций), а также позволял читать stdin либо по-умолчанию, либо если указан файл -.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

потому что оригинал принимал опции и считал строки/слова/символы

Ух ты! Ты его всё-таки прочитал!

monk ★★★★★
()
Ответ на: комментарий от Virtuos86

про растовую версию

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Корявость синтаксиса на хеловордах не очень заметна.

Ну лисп справляется.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Virtuos86

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от mv

который позволит писать код, не отстающий по производительности от Си

Только если писать в стиле Си: не использовать списки (только simple-array), типизировать все переменные, defstruct вместо классов.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.