Ну да ну да. Физик - печник не в курсе про моделирование в термояде? Так на хабре как раз недавно была статья про то, как придумать стелларатор без Степаныча.
И да, про чудо печников это просто деревенские байки от непонимания физики процесса.
Вы путаете «вычисление» и «запрет на вычисление». А еще вы путаете идеальный мир и реальный.
Безосновательное утверждение.
Ей-богу, я в результате напишу текст, объясняющий на пальцах, что не так с конечными автоматами в ООП (и почему инкапсуляция в ООП в общем случае не работает).
Так вот: класть печь — это чистое искусство. Там нет инструкции, следуя которой ты сложишь артефакт, который не будет чадить, и не будет выпускать всё тепло за час. Вообще.
Вот токомаки там всякие со стеллараторами, в отличие от печи поддаются компьютерному моделированию. Печи - это другое, тут без Степаныча никак.
При чём здесь вообще недетерминированность КА, особенно с учётом того, что для любого недетерминированного можно составить аналогичный детерминированный?
невозможно построить на ООП без потери математического доказательства его консистентности.
Как известно, любая система, обладающая полнотой по Тьюрингу не имеет логических преимуществ перед другой, так как может вычислить любой алгоритм.
Никогда не читайте перед обедом книг по специальности
Плавно переходит в "Никогда не читайте книг по ООП". Видимо по другим парадигмам читать можно. Что касается паттернов, то считаю, что ознакомится с ними не вредно, тем более, что в ООП на 99,9% (и то только исходя из идеи никогда не говори никогда) все эти паттерны самоочевидны, но их повсеместное, практически насильственное применение - лютый сектантизм.
И да,
Да ты просто хейтишь ООП!
А в остальном (кроме идеи вообще сравнивать различные парадигмы в терминах хуже/лучше) полностью согласен
Думаю, Вы абсолютно правы. Просто к этой девайсине надо относится как к закрытому решению без излишних иллюзий и надежд на расширение. Такой себе чёрный ящик - числодробилка. Но, если по результатам тестирования будет достигнута хорошая производительность, может быть интересно.
Что значит «остановился в развитии»? Зачем и куда языку развиваться, если он сделан с умом?
А чем тогда соответствующему комитету заняться? О чём им заседать?
Признаюсь, что если я раньше считал, что неплохо знаю плюсы, то с внедрением новых стандартов точно уже нет.
Не, если ты только спустя 15 лет поддержки языка вдруг понимаешь, что «кооперативная многозадачность» и «язык, чтобы никто не мог напортачить» — парой не ходят,
Go мне нравится как раз интеграцией поддержки кооперативной многозадачности на уровень языка. Считаю, что это и есть очень неплохо реализованная киллер-фича Go.
а зашедшие не совсем неофиты все время бубнят про дженерики…
Это да. И то, как дженерики нынче в Go реализованы, вызывает некоторое недоумение. Ещё раздражает отсутствие полиморфизма параметров.
Но если язык нужно развивать (а не ускорять и оптимизировать) — это и есть первый звоночек, что с языком что-то не так.
Справедливости ради, никакой из языков не избежал внесения изменений. Или плодятся диалекты. Или в новую жизнь под новым именем
Есть тут у меня один молодой-талантливый. Пишет код с помощью chatGPT. Код выглядит как настоящий, компилируется и даже работает почти как надо. Но не совсем ...
«Я пишу не для славистов, я пишу для нормальных людей»
Эти методы противоречат классическому ООП: они не курочат receiver, но возвращают новый объект.
То что при "классическом ООП методы должны курочить receiver и не возвращать новый объект" даже для славистов перебор. Не думаю, что Гослинг говорил что-то в этом роде.
У Вас же огромный опыт в различных парадигмах, давайте вместе не будем называть собаку кошкой, и потом удивляться, что она лает будем настаивать на правильной терминологии. Занудность в этой области - есть гуд!
Эти методы противоречат классическому ООП: они не курочат receiver, но возвращают новый объект.
Никакому классическому ООП эти методы не противоречат. В стандартной библиотеке Smalltalk прекрасно существуют методы collect: и select: А уж более классического ООП, чем Smalltalk, придумать сложно
Кроме того, в конце формата кадра Ethernet также есть поле Frame Check Sequence, которое наряду с Cyclic Redundancy Check (CRC) используется для проверки целостности кадра.
FCS используется не "наряду с CRC" а содержит значение CRC фрейма, итп
совет - избегайте упоминания user и kernel spice вообще. К работе планировщика GO это не имеет отношения. Примените "исполнение планируется планировщиком GO или ОС"
В других материалах вы могли также видеть определения kernel space (пространство ядра) и user space (пространство пользователя). Так вот — горутины будут существовать в user space, то есть ими управляет планировщик Go (если точнее — Go Runtime), а треды в kernel space, то есть ими управляет ОС.
Упоминаемые треды существуют в user space и к kernel space не имеют отношения. И ещё много чего... Чтобы выпустить книгу потребуется хороший технический редактор.
Ну да ну да. Физик - печник не в курсе про моделирование в термояде? Так на хабре как раз недавно была статья про то, как придумать стелларатор без Степаныча.
И да, про чудо печников это просто деревенские байки от непонимания физики процесса.
Безосновательное утверждение.
С нетерпением жду
Вот токомаки там всякие со стеллараторами, в отличие от печи поддаются компьютерному моделированию. Печи - это другое, тут без Степаныча никак.
Это как вопрос художника - сколько надо добавить зелёного чтобы написать хорошую картину?
Ту только опыт и чувство прекрасного.
Последнее время всё больше склоняюсь к тому что всё-таки программирование это искусство
При чём здесь вообще недетерминированность КА, особенно с учётом того, что для любого недетерминированного можно составить аналогичный детерминированный?
Как известно, любая система, обладающая полнотой по Тьюрингу не имеет логических преимуществ перед другой, так как может вычислить любой алгоритм.
Плавно переходит в "Никогда не читайте книг по ООП". Видимо по другим парадигмам читать можно.
Что касается паттернов, то считаю, что ознакомится с ними не вредно, тем более, что в ООП на 99,9% (и то только исходя из идеи никогда не говори никогда) все эти паттерны самоочевидны, но их повсеместное, практически насильственное применение - лютый сектантизм.
И да,
А в остальном (кроме идеи вообще сравнивать различные парадигмы в терминах хуже/лучше) полностью согласен
Ага. Абсолютно. Люблю кооперативку и фулстек корутины.
А то что любой джун может отыквить , так лучше если это будет заметно сразу, ещё на тестах, чем тихо при вытесняющей будет отъедать ресурсы в проде.
На мой непросвещённый взгляд, Эликсир - логичное развитие Эрланга. И да, он клёвый.
Развитие языков это всегда про синтаксис
Думаю, Вы абсолютно правы. Просто к этой девайсине надо относится как к закрытому решению без излишних иллюзий и надежд на расширение. Такой себе чёрный ящик - числодробилка. Но, если по результатам тестирования будет достигнута хорошая производительность, может быть интересно.
"Круглое - таскаем, квадратное - катаем" а чё такого? Ну не правильные термины, делов то.
А чем тогда соответствующему комитету заняться? О чём им заседать?
Признаюсь, что если я раньше считал, что неплохо знаю плюсы, то с внедрением новых стандартов точно уже нет.
Go мне нравится как раз интеграцией поддержки кооперативной многозадачности на уровень языка. Считаю, что это и есть очень неплохо реализованная киллер-фича Go.
Это да. И то, как дженерики нынче в Go реализованы, вызывает некоторое недоумение. Ещё раздражает отсутствие полиморфизма параметров.
Справедливости ради, никакой из языков не избежал внесения изменений. Или плодятся диалекты. Или в новую жизнь под новым именем
Если раньше
требовал хоть какого-то, пусть минимального, но всё же осмысления копирования, то с LLM народ копипастит практически не читая и точно не вникая.
Вижу надвигающуюся катастрофу в индустрии ((
Да что Вы, разве маэстро мог обозвать go убогим?
Ага ага.
Есть тут у меня один молодой-талантливый. Пишет код с помощью chatGPT. Код выглядит как настоящий, компилируется и даже работает почти как надо. Но не совсем ...
Это какой такой самый убогий язык?
То что при "классическом ООП методы должны курочить receiver и не возвращать новый объект" даже для славистов перебор. Не думаю, что Гослинг говорил что-то в этом роде.
У Вас же огромный опыт в различных парадигмах, давайте вместе
не будем называть собаку кошкой, и потом удивляться, что она лаетбудем настаивать на правильной терминологии. Занудность в этой области - есть гуд!Никакому классическому ООП эти методы не противоречат.
В стандартной библиотеке Smalltalk прекрасно существуют методы collect: и select:
А уж более классического ООП, чем Smalltalk, придумать сложно
Однозначно полезный перевод.
Хотя есть некоторые неточности, например:
FCS используется не "наряду с CRC" а содержит значение CRC фрейма, итп
совет - избегайте упоминания user и kernel spice вообще. К работе планировщика GO это не имеет отношения. Примените "исполнение планируется планировщиком GO или ОС"
Упоминаемые треды существуют в user space и к kernel space не имеют отношения.
И ещё много чего... Чтобы выпустить книгу потребуется хороший технический редактор.