Pull to refresh
1
Дмитрий Гарбузов@pureooplover

User

1
Subscribers
Send message

Ну, во первых надо учитывать - делать такие проекты - одно удовольствие (сам знаю опыт создания интерпретаторов и прочего),

во вторых - сам автор сказал что "Если не мы создаем - мы не понимаем" - а в случае вайб-кодинга создаем не мы а ИИ,

в третьих - ИИшный код часто бажный.

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

Наконец-то статья из моей ленты Гугла написана не ИИшкой...

Меньше 60 тыс строк?

Ну, я может не разбираюсь, но я думаю можно и по меньше, 20-10 тыс, я думаю.

Я тоже зашёл, подумал что тут будут все говорить про 666, а оказалось что нет(

Я тоже так накрыл два аккаунта когда увидел что мой проект на гитхабе скопировали и добавили некий zip-файл "Software-2.1-beta" и там в этом файле был обфусцированный код на Lua.

UPD: я эти аккаунты заметил в начале этого года.

"Когда хотел сделать СЛИШКОМ чисто"

x := 2 + 2. "MessageNotUnderstood: +, heh"
x := (2 + 2). "4!!!!"

Win+Ю вообще вроде на винде.

Почему бред?

Со стороны чистоты нет, но звучит так просто плохо.

Тут, конечно есть проблема — например, приоритет выполнения. И не факт, что одна. Но если уж мы пытаемся придумать чистый объектный язык, где "всё — объект", то и "переменная" — тоже объект.

Да пофиг на приоритеты, в принципе скобки же для того и существуют

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

  • для реализации необходимых примитивов — как от этого можно избавиться не вижу, так что это можно/нужно только минимизировать

  • когда нужная "функциональность" не ложится на "синтаксис" языка.

Согласен.

Собственно, синтаксическая конструкция "получитель сообщение" и лежит в основе синтаксиса Smalltalk-а. И мешается. Например, как в случае с возвратом из метода: кто является получателем сообщения "вернуть объект"?

Тот самый контекст наверно?

Что именно вызывает непонимание? Что и с какой целью нужно изменить?

Да ну вообще нечего...

у вас с ссылкой что-то не то, именно в статье.

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

Окей.

Поймите, что "машинные коды" отлаживал человек в 3 часа ночи и на них можно положиться.

А код ИИ (особенно когда просишь его сложнее чем Hello world) очень бажный.

То есть нельзя положиться на него.

Я кажись понял.

То есть x это сообщение в контекст выполнения.
Контекст думает: "хм, у меня нету переменной x, я её не вижу, значит надо инициализировать её и вернуть объект переменной".

Объект переменной - звучит бред, ну что-то типа... ладно, это надо продумать.

Потом этому объекту мы посылаем сообщение ":=" с аргументом 5, и объект сохраняет это значение себе (ну или по крайне мере куда то там где читают значения переменных).

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

что у вас означает assign — что-то типа примитивной операции

псевдокод)

  • В "среду"/контекст посылается сообщение x.

  • Контекст (например, метод, в котором данный код выполняется) получает это сообщение и создаёт у себя слот с именем х; этот слот становится контекстом.

  • Слот получает сообщение := 5 и кладёт в себя соответствующее значение.

Сложно понять, но подумаем.

Вы имеете ввиду чтобы даже x := 5 означал assign makeVar: #x value: 5?

Я правильно понял?

А как бы вы видели тот самый чистый ООП-язык?

Я вижу чистый ООП-язык так:

  1. Тотальная инкапсуляция.

  2. Наследование.

  3. Прототипы.

  4. Всё - есть объект (или прототип;))

  5. Всё - есть сообщение.

  6. Полиморфизм.

Акторы и процессы - это такие же объекты с методами по типу onWork который планировщик задач просто вызывает каждый раз.

"Класс" и "Объект (экземпляр) класса" - нету их.

Всё есть объект.

То есть если я создам объект то перед началом работы с ним мне не надо его копировать.

Ну и метапрограммирование по типу doesNotUnderstand:.

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

Но раз наши с вами интересы схожи... То мы как бы можем вместе что-то написать, я не против.

UPD: если что-то не понятно, спрашивайте.

UPD(2): Короче я клоню к Self с небольшими изменениями.

Ахах, да.

Но вообще признаю - я ленивый из-за чего мне лень бутстраппить.

А да... Что там с проектом? Ну, я пошёл на МК и там щас пишу образ системы чтобы он был что-то вроде в стиле Smalltalk-80.

В Squeak, Pharo щас Morphic юзают, а в Dolphin Smalltalk вроде бы нативное всё.

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

человеку не нужны.

отлаживать кто будет?

не кто что ли? ну мы же не отлаживаем ассемблер.

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

только если эти всякие машинные коды отлаживали в какой то конторе по 10 раз и решили ВСЕ проблемы.

то ИИ же уберет баг, и к примеру сделает 2 новых, так ещё и уберет одну фичу.

попросишь вернуть - вернёт и баг, и фичу, ещё и те двое бага оставит.

и так по циклу будет: "почини" - результат, но без фичи нужной - "верни" - вернёт и фичу, и баг - "почини" - ...

Довольно давно стоимость CPU стала настолько низкой, что дешевле купить CPU на 10 лет вперёд, чем оплатить разработчика на лишний месяц.

тогда один раз софт развалится потому что CPU не выдержит (или по другой причине) - и капут.

Для ИИ, кстати, думаю, победит тот язык, который помимо перфа имеет максимально большую и собранную в одном месте библиотеку "на все случаи жизни". Возможно, Rust здесь уделает остальные языки.

кстати... а у Python'а есть же такая библиотека.

конечно же это pip, но есть же.

1

Information

Rating
4,379-th
Location
Адыгейск, Адыгея, Россия
Registered
Activity

Specialization

Инженер встраиваемых систем, Архитектор программного обеспечения
ООП
Smalltalk
Lisp
Системное программирование
Программирование микроконтроллеров
Операционная система реального времени
Встраиваемая система