Node.js Kernel Module

У всех статических языков.

У всех статических языков.

Поехавший что-ли? Покажи мне язык, у которого система типов основана на ТК.

Я ждал это.... Я рад

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

А от жаваскрипта кому стало бы лучше? Имелось ввиду «вместо того чтобы засовывать javascript в ядро, лучше б туда засунули Lisp». Почему лисп лучше javacript - потому что гомоиконность, макросы, наличие нормальных интов (в жавасрипте https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje... интов в нормальном виде нет, там корячатся с флоатами), метапрограммирование, DSL. Какой именно - ну scheme например. Или Common Lisp. Но все это естественно нафик в ядре не нужно. Так, на правах бреда

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

А от жаваскрипта кому стало бы лучше?

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

Какой именно - ну scheme например. Или Common Lisp.

Мде. Впрочем, Racket в ядре - это интересно.

Жабаскрипт отличается от Лиспов в лучшую сторону только одним - он, кажется, движется в сторону статической типизации (TypedScript, ES*).

Лисп тоже, например вот http://fprog.ru/2010/issue4/vitaly-mayatskikh-lisp-abstractions-on-steroids/

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

(defun sum (a b)
  (declare (type (integer 0 1000) a b))
  (+ a b))

SBCL сгенерировал более оптимальное сложение с использованием одной единственной команды Load Effective Address (данная техника описана в официальном документе по оптимизации кода от Intel):

; disassembly for SUM
; 02EB06DB: 488D143B LEA RDX, [RBX+RDI] ; no-arg-parsing entry point
;       DF: 488BE5   MOV RSP, RBP
;       E2: F8       CLC
;       E3: 5D       POP RBP
;       E4: C3       RET

Все перечисленное вами есть в js. Вы просто не умеете его готовить. И гомоиконность (toString \ eval ) и макросы, если хотите (sweetjs) и нормальные инты TypedArray на здоровье, а еще DataView для C-compatibility, и метапрограммирование Proxy.

NodeOS - это initrd с Docker и Node.js + shell на JS
А тут вообще экзоядро, неправильно как-то сравнивать

Жабаскрипт отличается от Лиспов в лучшую сторону только одним - он, кажется, движется в сторону статической типизации (TypedScript, ES*).

Лисп тоже, например вот http://fprog.ru/2010/issue4/vitaly-mayatskikh-lisp-abstractions-on-steroids/

А. Так ты просто не понимаешь, что такое статическая типизация.

This way we can re-create Node.js standard library whose only dependency will be the system call function. We would remove all native dependencies from Node.js, including Node.js itself, libuv, libc and even V8.

То, за счет чего тащит нода, он хочет выпилить
Ненужно

И гомоиконность (toString \ eval )

И это гомоиконность? Давайте я тогда программой на С буду в рантайме генерировать куски сишного кода, потом дергать компилятор, создавая .so, и потом dlopen-ом его, С - гомоиконен. Хотя зачем С, я это и на ассемблере могу, через mremap или mmap сделать rwx кусок в адресном пространстве процесса, позаписывать в него опкодов, и сделать jmp туда, вот и гомоиконность.

и макросы

Те ли это макросы, которые в лиспе? С AST можно работать? Или просто манипуляции с текстовым представлением кода?

TypedArray

TypedArray не умеет в Uint64 и Int64 (как раз таки по причине этого «генетического» дефекта с флоатами). Я не понимаю этого восхищения жаваскриптом. Как по мне, это довольно убогий и примитивный язык, который на скорую руку склепали за десять дней https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/

Ten days to implement the lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per our over-optimistic agreement, cloned java.util.Date — Y2K bugs and all! Gosling...).

DataView для C-compatibility

А bitfield из коробки там есть? Или только через костыли https://github.com/fb55/bitfield

А. Так ты просто не понимаешь, что такое статическая типизация.

А разве добавление подобных «аннотаций» переменным, принимаемым функцией, не означает статическую типизацию?

А разве добавление подобных «аннотаций» переменным, принимаемым функцией, не означает статическую типизацию?

Нет.

А разве добавление подобных «аннотаций» переменным, принимаемым функцией, не означает статическую типизацию?

Скомпилируется ли тот пример CL с аннотациями, если в коде будет вызов функции sum с нечисловым аргументом (например, строкой), или это будет runtime-ошибка?

This is SBCL 1.1.14.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (defun foo (n)
  (declare (type fixnum n))
  (+ n 42))

FOO
* (foo 10) 

52
* (foo 1.1)

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002A8AFC3}>:
  The value 1.1 is not of type FIXNUM.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

Оно даже с флоатами не хочет, не говоря уж о строках

http://www.sbcl.org/manual/#Getting-Existing-Programs-to-Run вот нашел

Может не совсем в тему, но мне и правда интересно. Чем так крут JS? Последнее время то и дело о нём слышу. Я не программист ни разу, конечно. Но понимаю плюсы C, C++, Java, Python, но не понимаю чем берёт JS.

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

λ nameless@laptop cl → cat test.lisp
(defun test (arg)
  (declare (type fixnum arg))
  (format t "I've got a value of type ~a" (type-of arg)))

(test "static typing, my ass")
λ nameless@laptop cl → sbcl --noinform --eval '(compile-file "test.lisp")' --quit
; compiling file "/tmp/cl/test.lisp" (written 02 JUL 2016 04:45:52 PM):
; compiling (DEFUN TEST ...)
; compiling (TEST "static typing, my ass")

; /tmp/cl/test.fasl written
; compilation finished in 0:00:00.017

.

(declare (type ...)) даёт только оптимизацию и runtime asserts.

Просто очень узкая ниша. Для быстрого прототипироаания легче lua с нет перенести.

На задачах асинхронщины+переносимости+не типизированного прототипного ООП+простыни данных в json (куда конвертятся объекты ООП) он великолепен. Только эти задачи в одном месте сразу мало кому нужны, а большинство погромистов не умеют прпвильно на нем писать (на Си легче не отстрелить себе ногу, чем на js - члнн). Армия фронтендеров по бракзеры в основном не умеют нормально.

Я сказал, что динамическое говно (кроме Python)

Ты САМ признал что питон говно :) ?

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

Знаешь, у тебя фантазии не просто смелые, они прям отважные и героические :)

Статика не гарантирует того, что данные будут верными.

А ещё не решает арабо-израильский конфликт и не похмеляет с утра. Вот только это не делает динамику более нужной.

Еще раз. Вся история статических языков это как заставить функцию сложения складывать числа, строки, массивы.... Сначала мы вкорячили статическую типизацию, а потом начинаем плодить интерфейсы, шаблоны и прочее чтоб не думать что с чем мы складываем.... Прикольно делать callback когда мы не знаем что ему передать или число или вообще объект с соединением к БД. При этом был пример когда народ пользуясь стандартной сериализацией python за неделю написали код который на Java писали год потому, что надо было проверить тип потом вызвать для него сериализатор и везде это Object который ПОТОМ приводили к типу....

Да и вообще я как, то больше верю Алану Кею чем тебе.

Ты САМ признал что питон говно :) ?

Вся динамика - говно. Но Python из всего этого - наиболее юзабельный.

Тогда и Ruby хотя я сам его не люблю, но справедливости ради.... Два брата акробата.

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

P.S. Термин «сложение» к строкам применяют только мудаки, поскольку строки со сложением не образуют абелеву группу. Для строк и конкатенации лучше запилить полугруппу и моноид.

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

У меня такое было когда я изучал сложные вещи. Или ты поймешь или ты безнадежен.

У меня такое было когда я изучал сложные вещи

Прости, под сложными вещами ты подразумеваешь «я учился читать»?

(declare (type ...)) даёт только оптимизацию и runtime asserts.

Почитай http://www.sbcl.org/manual/#Getting-Existing-Programs-to-Run по ссылке. Стандарт Common Lisp предусматривает декларации типов, которые некоторые реализации могут использовать также для статической проверки типов еще на этапе компиляции. Делать это или не делать - решают создатели конкретной реализации

Since SBCL’s compiler does much more comprehensive type checking than most Lisp compilers, SBCL may detect type errors in programs that have been debugged using other compilers. These errors are mostly incorrect declarations, although compile-time type errors can find actual bugs if parts of the program have never been tested.

Some incorrect declarations can only be detected by run-time type checking. It is very important to initially compile a program with full type checks (high safety optimization) and then test this safe version. After the checking version has been tested, then you can consider weakening or eliminating type checks. This applies even to previously debugged programs, because the SBCL compiler does much more type inference than other Common Lisp compilers, so an incorrect declaration can do more damage.

The most common problem is with variables whose constant initial value doesn’t match the type declaration. Incorrect constant initial values will always be flagged by a compile-time type error, and they are simple to fix once located. Consider this code fragment:

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

И чо, используют?

Отличный комментарий от товарища Сталина.

(defun test (arg)
  (declare (type fixnum arg))
  (setq arg 3.14)
  (format t "I've got a value of type ~a" (type-of arg)))

; ==>
;   (THE FIXNUM 3.14)
; 
; caught WARNING:
;   Constant 3.14 conflicts with its asserted type FIXNUM.
;   See also:
;     The SBCL Manual, Node "Handling of Types"

Так что какие-то проверки типов там есть