Обновить
46

Типострадалец

12
Подписчики
Отправить сообщение
Первая — вынести и переиспользовать часть кода классов кодирующих схожие объекты.

Это вполне реализуется композицией, которую вполне можно было бы использовать ещё в C.


Вторая — идея интерфейса — использовать родительский тип как интерфейс к многим разным вариантам имплементации.

Это вполне решается классами типов в Haskell (1990). Или, если копнуть глубже, модулями в Standard ML (1983).


Так что здоровые альтернативы наследованию существуют уже достаточно давно.

Просто тот же numpy по факту не на Python написан. И это добавляет головной боли с компиляцией нативного кода

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

Что-то я не понимаю, каким образом в этом списке оказалось наследование. Оно же, наоборот, очень сильную связь создаёт.

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

А что вы будете делать, если вы добавили в структуру новое поле и нужно отследить, что это поле правильно везде инициализируется?

Если у человека нет чувства юмора, он станет обижаться на безобидные фразы (я даже не упоминаю дружеские подколки) в код ревью

Я бы сказал, что степень безобидности фразы — очень субъективная оценка.

аудио и видео звонков

Конкретно это в Telegram вполне есть.

А что, вы на слух ощущаете разницу между lossless и, скажем, MP3? Правда интересно.

Go имеет value типы, поэтому писать без аллокаций там проще простого.

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

Даёшь Хабр-факс одной строкой!

А вообще-то неплохая идея.

При всей моей любви к Rust: это не так. Сообщения от компилятора, конечно, сильно помогают, но писать код всё же надо самому. Вот где действительно то, что можно назвать compiler-driven development — так это в Idris

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

Угу, все возможные GC, с которыми приложение может работать. И со всеми возможными настройками.


На том же Go можно при желании писать код, который практически не будет вызывать аллокаций в рантайме и всё равно это будет проще чем раст или плюсы. Со сравнимой производительностью.

А можно привести пример? Обычно Go без аллокаций выглядит как мешанина из unsafe.Pointer, в которой за деревьями сложно разглядеть лес.

Попыток сделать графический язык программирования было немало. Всякий раз реализация упирается в то, что сколько-нибудь серьёзные программы не умещаются на экране и потому совершенно теряют в наглядности (не говоря уже о отсутствии нормального тулинга).
12 ...
78

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность