Вышел Pharo 7.0

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

Очевидно, что не понятно.

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

А когда рефакторишь — она очень и очень нужна.

Ну так рефакторинг начинается задолго до того, как код готов.

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

Давно ознакомился.

А то уже детсад какой-то начался.

Ты его начал. А я всё жду ответа на вопрос: Вышел Pharo 7.0 (комментарий)

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

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

Конечно.

На подумать:

(defvar a 1)

(defvar b "2")

(+ a b)

$ sbcl --load test.lisp 
This is SBCL 1.4.10, 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.
While evaluating the form starting at line 5, column 0
  of #P"/tmp/test.lisp":

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {10005505B3}>:
  The value
    "2"
  is not of type
    NUMBER
  when binding SB-KERNEL::Y

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file "/tmp/test.lisp".
  2: [ABORT   ] Abort loading file "/tmp/test.lisp".
  3:            Ignore runtime option --load "test.lisp".
  4:            Skip rest of --eval and --load options.
  5:            Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT    ] Exit SBCL (calling #'EXIT, killing the process).

(SB-KERNEL:TWO-ARG-+ 1 "2") [external]
0] 

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

Да, так и есть. Но при этом они без труда могут гвоздь камнем забить.

SBCL

Дальше не читал.

Жаль раньше не посмотрел на твой аватар. :)

Или ты будешь отрицать, что Common Lisp динамически типизируемый язык?

Вышел Pharo 7.0 (комментарий)

Ну если ты такой упёртый, то что делать? Прямо говоришь, отрицаешь, приходится обходными путями тебе показывать. Или для тебя CL это статически типизируемый?

Ну если ты такой упёртый, то что делать?

Попробуй ответить на вопрос.

приходится обходными путями

Обходными путями у тебя не получается. Попробуй прямой.

Попробуй ответить на вопрос.

Я тебе твоё утверждение сломал, а ты про вопрос.

Я [...]

Ты можешь быть хоть Бэтменом, но меня интересует ответ.

Ну ты его как-то плохо видишь. В яве в рантайме проверяются аргументы метода. Значит, ява статически типизируемый язык. Хорошо. В CL тоже в рантайме проверяются аргументы метода. Значит, CL тоже статически типизируемый язык?

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

Попробуй прямой.

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

Ну, про «без труда» — это ты загнул. Собственно, именно потому и выбирают молоток, что «труда» будет поменьше.

про «без труда» — это ты загнул

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

Основная ошибка смолтокеров именно в этом — они считают, что код — это какая-то сложная древовидная структура с перекрёстными ссылками.
Реально же таковым является только законченный код, и то не вполне; в процессе написания код — это чистый текст.

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

Integer compile: 'test ^3'. Выполнение 3 test вернет 3.

Но даже имея шуруповёрт, у него остаётся отвёртка.

Ну да. Даже в Хаскеле остаются не-типобезопасные функции, которые когда-то да используют.

Просто на одном шурупе отвёртка даже интереснее, потому что меньше, легче. На 100 шурупах уже другой разговор.

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

REST API дно

Не совсем. В динамике тип проверяется при каждом использовании объекта.

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

лезть в работающую систему и изнутри её подкручивать — это признак полной безнадёги

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

Статика — это не только ценный мех способ ловить некоторые ошибки программиста, но и способ добится эффективности выполнения

Уже нет. Сейчас есть компиляторы которые умеют генерить С программу на выходе, например Lisp-->C. А С программа уже собирается gcc со всеми его оптимизациями. Разницы в эффективности выполнения практически нет.

Или так Clojure->java->GraalVM->native image.

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

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

Но динамические языки — это ещё и сборка мусора, как правило. Ну ок, с С (крестами, ржавым) тоже не всё так просто, и стратегия создал объект, отвёл память, удалил — освободил, по нынешним временам тоже отнюдь не самая быстрая, но тут есть свобода выбора стратегией управления памятью. Чего я о лиспе/смолтоке сказать не могу.

Не знаю про смолток, но лисп умеет «manipulate raw C data in Lisp through pointers to it. Provides support for stack and heap C memory allocation».

образчик «словарика с функциями», который хотя бы отдаленно походил на ООП, из 1960-х?

C++, правда он чутка позднее родился.

Симула

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

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

Но динамические языки — это ещё и сборка мусора, как правило.

Современные статические — тоже.

Правда, оверхед от сборки мусора обычно минимальный.

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

А код — это текст.

Когда я писал под Unreal Engine на блупринтах (в смеси с С++), я осознал всю крутость написания кода в виде текста. Но надеюсь проблемы, с которыми я столкнулся там - результат некомпетентости авторов конкретно движка, и подобных траблов в сабже нет. Надо кстати проверить, насколько в смолтолке удаление класса из цепочки наследования влияет на переопределенные методы, особенно если последние вызывают super. Ну типа рефакторинг упрощения иерархии наследования, который в Unreal превращается в переписывание кода с 0.

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

а у нас так мало языков инкрементальной разработки (и все родом из бородатых 80-х)?

Потому что чем меньше мутабельного состояния, тем проще. Пресловутая «среда» — это то самое мутабельное состояние.

Процесс разработки и есть постоянная мутация исходного кода. Зачем прятать то, без чего все равно не обойтись? И такое варварское поведение в процессе разработки никак не связано с чистотой получаемого кода.

В каком-нибудь космическом аппарате — тоже

Уже и там применяют? Про использование лиспа я знаю, про erlang никогда не слышал.

А где у Pharo референц книга? Конкретно как в нём биндить C либы?

Рефлексия есть, а динаимикки нет.

Жесть. У тебя наверно своя уличная рефлексия со статическими проверками через libastral. Хотел записать в блокнотик, но и так помню что ты альтернативно-одаренный.

Человек имел ввиду, что никакая рефлексия не вдолбит тупому компилятору джавы о том, что данный класс можно смело передать методу, который принимает уток, несмотря на то что getMethod(«кря») вернул не null.

https://www.slideshare.net/FASTPresentations/pharo-foreign-function-interface...

А референца на 300+ страниц, как у всех нормальных компиляторов значит нету?

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

Динамика, это runtime type checking. В сишке из подобного есть только dynamic_cast, но у него ограниченная область применения. А reinterpret_cast вообще из другой оперы. Это уже weak typing.

https://books.pharo.org/

Биндилось раньше через Native Boost, теперь есть какой-то FFI поновее (вроде).

Какой тебе нужен референс как у каких компиляторов? «Экзешник» ты с фарой не сделаешь (но есть метациклический Bee Smalltalk, который умеет)

А Bee Smalltalk он точно есть? А то и в домене .org, и на гитхабе есть только обещания что он скоро (когда-нибудь) будет.

Где-то в Аргентине точно есть :) на самом деле его релиз (или хотя бы опенсорс) прелюдно обещали ещё в сентябре, но я честно не проверял.

Динамика, это runtime type checking

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