Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
ООП для меня это только сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего
Мне кажется, как раз к лучшему, что его идею перевернули иначе. Я не думаю, что без наследования и полиморфизма было бы возможным вывести софт на новый уровень сложности в 1990-е.
Let the holy war begin!
Полиморфизм его идеей подразумевается by design. Вот наследование в Smalltalk возможно было деталью реализации для DRY
Что в наследовании нет необходимости — показывал VB6.0. А JS показывает, что нет необходимости в классах (и то они оказались полезны).
Я к JavaScript отношусь достаточно скептично. Он вообще является инструментом, который случайно оказался в нужном месте. Он больше показывает, что даже язык, при создании которого не думали ни про эффективность, ни про контроль ошибок разработчика, ни про продуктивность, а лишь про то, как можно было бы быстро на коленке что-то написать, может стать инструментом для разработки крупных проектов.
В JavaScript наследование было изначально. Прототипное. Недвно добавили сахар для возможности его использования как классового.
Большие вопросы скорее вызывает то что Smalltalk не пошел в mainstream.
Его модель с передачей сообщений очень масштабируема не только в смысле параллельных вычислений, но и программирования для распределенных систем.
Даже самые примитивные операции выполняются только на сообщениях, и эта точка потенциального взрыва использования языка если думать про параллелизацию и distributed computing (микросервисы и вот это вот все).
И тем не менее, Smalltalk почти умер (несколько десятков энтузиастов и группа Pharo это не жизнь языка программирования), в чем же причины?
Его модель с передачей сообщений очень масштабируема не только в смысле параллельных вычислений, но и программирования для распределенных систем.
Даже самые примитивные операции выполняются только на сообщениях, и эта точка потенциального взрыва использования языка если думать про параллелизацию и distributed computing (микросервисы и вот это вот все).
И тем не менее, Smalltalk почти умер (несколько десятков энтузиастов и группа Pharo это не жизнь языка программирования), в чем же причины?
А есть ли будущее у технологии, если пойти дальше Smalltalk, и заменить модель сообщений запрос/ответ на чистую асинхронку и акторное программирование? Думаю такой язык был бы крайне интересен для современных задач по облачному программированию, GRID, микросервисов и т.п., если реализовать его как расширение для mainstream технологий поверх той же JVM.
Сейчас идет большой хайп про IoT, а как бы это не область где такой язык принципиально необходим, в виде полноценного LLVM-кросскомпилятора для встраиваемых систем. Go делает слишком жирные бинарники, минимум на порядок толще чем это оправдано на железе типа RT5350. И решилась бы проблема с интероперабельностью межде системами разных архитектур — сейчас передача данных по MQTT вызывает головную боль с выбором методов сериализации, пакеты длиной от 50 байт (LoRa), на принимающей стороне IoT платформ зоопарк библиотек и протоколов декодирования.
Сейчас идет большой хайп про IoT, а как бы это не область где такой язык принципиально необходим, в виде полноценного LLVM-кросскомпилятора для встраиваемых систем. Go делает слишком жирные бинарники, минимум на порядок толще чем это оправдано на железе типа RT5350. И решилась бы проблема с интероперабельностью межде системами разных архитектур — сейчас передача данных по MQTT вызывает головную боль с выбором методов сериализации, пакеты длиной от 50 байт (LoRa), на принимающей стороне IoT платформ зоопарк библиотек и протоколов декодирования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алан Кэй не изобретал объекты