Я извиняюсь если вопрос покажется некорректным. Но мне правда интересно. Вы бы стали писать на Golang если бы за ним не стоял Гугл? И что произойдёт если гипотетически Гугл скажет "голанг неудачен, пилим всё на тайпскрипт"?
Озвученная вами проблема — извечная проблема курицы и яйца. Никто не хочет писать на новом языке т.к. на нём не пишут толстые корпорации — которые на нём не пишут т.к. пишет мало кто, goto 1. Почти гарантирую, что если бы С++ был создан сейчас в текущем виде, он бы помер не родившись — но его держат мегатонны легаси.
Проблема в том, что в ответ на почти любые претензии о косяках или явном примитивизме получаешь ответ "Ты ничего не понимаешь, малыш! Так надо!". Помню как на вопрос почему вообще допустили такой косяк как non-nil nil interfaces, я получил ответ именно в таком стиле, с жонглированием значения термина "указатель". Ссылку, к сожалению, уже не найду. Ответ был не от Пайка если что.
Там таки есть вполне валидные замечания. Для меня лично — переиспользование структур и поля в трэйтах, в качестве требований. Первую проблему можно было бы решить как в Go — alias член автоматом торчит из структуры всеми своими трейтами. Вторая ЕМНИП решена в Scala — но не в близких к системным языках. Могу конечно ошибаться.
Моё скромное мнение — серьёзный продакшен GUI подался в web или electron. Там уже не ролляет, на чём писать бизнес-логику. А старые крупные проекты просто не имеют желания шевелиться куда-то.
Мне кажется, тут идёт вопрос разграничения между "клиентским" и "библиотечным" кодом. Названия условные. "Клиентский код" — условно тот, который решает вашу задачу. "Библиотечный" — набор базовых строительных кирпичиков. Так вот. Односвязный список, граф и т.п. для меня — как раз такие кирпичики. И при их реализации вы будете использовать техники, которые в нормальном коде не будете. К примеру unsafe. Который не является Exterminatus Incoming, а всего лишь возможностью обойти некоторые ограничения — если вы знаете что делаете. Вы пишете в основном на Java, поэтому просто для справки — в С++, к примеру, unsafe у вас по факту везде.
Это всего лишь перенос ручной конфигурации в другое место. Сравните с CMake target_include_directories. Вы задаёте "публичные" и "приватные" пути у самого таргета. Далее, при подключении этого таргета как зависимости все его публичные include paths, а также include paths от всех его публичных зависимостей (в т.ч. транзитивных) автоматом попадают в ваш зависимый таргет. Таким же образом это работает для libraries, definitions etc.
Наследуемые include пути добавили? Чтобы не прописывать в зависимом проекте include paths зависимостей руками. Или для полноценной работы по-прежнему нужен CMake?
Поддержка CMake по-прежнему требует Tools for Linux? Или эту странную зависимость (при этом неявную) всё-таки убрали?
Не знаю насчёт SJW, но на npmjs.org (если вы о нём) хотя бы вменяемые переходы цвета. Белый-голубой-синий-голубой-белый. А не малиновый-зелёный-чёрный-канареечный...
Новый дизайн откровенно ужасен. Такое впечатление, что авторов покусали бешеные маркетоиды, ментально доминируемые инвесторами, уж извините за прямоту.
В последней MacOS выпилили возможность использовать Cmd+Space для переключения раскладки в угоду абсолютно убогой комбинации Ctrl+Space. При этом даже первая проигрывает в удобстве Alt+Shift в Win.
Я вас огорчу. В Windows теперь каноничная комба — Win+Space. Старое доброе окошко настройки раскладок тщательно закопано.
Я так и не увидел, какие проблемы должен решать новый язык.
Касательно же предложений из статьи
Долой синтаксис
А как автор планирует добавлять новые конструкции? Каждой функции по отдельному синтаксису? И всё впихнуть в стандарт? И, главное, как это потом читать? Формальный синтаксис имеет ту же цель, что и математические знаки — стандартизировать элементы и упростить чтение.
Долой встроенные типы
BigInt, Decimal, Rational etc. — уже давно придуманы. Просто использовать бесконечную точность везде крайне неэффективно.
Долой практику метаязыков
Так и не понял. Сначала автор против метапрограммирования. Потом автор против больших стандартов, которые закрывают эту проблему. При том, что оба постулата напрямую противоречат постулату "Долой синтаксис", который будет провоцировать свой синтаксис на каждый чих.
Да написать-то так можно. но получается потом не по фэншую. Дальше придётся писать проверки типов
В динамике вам точно так же придётся писать проверки для обработки собственно значений
У нас получается не статическая типизация, а кустарная (вручную написанная) динамическая типизация.
Типы-суммы это очень даже статическая типизация. Вы статически знаете, что значение внутри или типа А, или Б. Назвать её динамической — примерно как назвать int динамически типизированным, просто потому что там могут лежать разные числа.
Самая большая неоднозначность — парадигма полностью ручного ресурс менеджмента. Т.е. при отсутствии GC они не предоставляют ничего кроме куцего defer.
Не обязательно — если у человека стойкая ассоциация "рекламируемая вещь == шлак". Как с рекламой лутбокс-шопов, мобильных гриндилок и т.п.
Многим авторам и сейчас ничто не мешает так делать. Или ставьте либу мохнатой версии — или крутитесь как хотите.
Я извиняюсь если вопрос покажется некорректным. Но мне правда интересно. Вы бы стали писать на Golang если бы за ним не стоял Гугл? И что произойдёт если гипотетически Гугл скажет "голанг неудачен, пилим всё на тайпскрипт"?
Озвученная вами проблема — извечная проблема курицы и яйца. Никто не хочет писать на новом языке т.к. на нём не пишут толстые корпорации — которые на нём не пишут т.к. пишет мало кто, goto 1. Почти гарантирую, что если бы С++ был создан сейчас в текущем виде, он бы помер не родившись — но его держат мегатонны легаси.
Проблема в том, что в ответ на почти любые претензии о косяках или явном примитивизме получаешь ответ "Ты ничего не понимаешь, малыш! Так надо!". Помню как на вопрос почему вообще допустили такой косяк как non-nil nil interfaces, я получил ответ именно в таком стиле, с жонглированием значения термина "указатель". Ссылку, к сожалению, уже не найду. Ответ был не от Пайка если что.
Там таки есть вполне валидные замечания. Для меня лично — переиспользование структур и поля в трэйтах, в качестве требований. Первую проблему можно было бы решить как в Go — alias член автоматом торчит из структуры всеми своими трейтами. Вторая ЕМНИП решена в Scala — но не в близких к системным языках. Могу конечно ошибаться.
Моё скромное мнение — серьёзный продакшен GUI подался в web или electron. Там уже не ролляет, на чём писать бизнес-логику. А старые крупные проекты просто не имеют желания шевелиться куда-то.
А Rust — как системный. И Go, вследствие наличия GC, для GUI и граф-подобных структур, должен подходить сильно больше. Но поди ж ты.
Не факт. Контрпример — назовите пример хорошего GUI фреймворка для Golang. Который на порядок проще.
Мне кажется, тут идёт вопрос разграничения между "клиентским" и "библиотечным" кодом. Названия условные. "Клиентский код" — условно тот, который решает вашу задачу. "Библиотечный" — набор базовых строительных кирпичиков. Так вот. Односвязный список, граф и т.п. для меня — как раз такие кирпичики. И при их реализации вы будете использовать техники, которые в нормальном коде не будете. К примеру unsafe. Который не является Exterminatus Incoming, а всего лишь возможностью обойти некоторые ограничения — если вы знаете что делаете. Вы пишете в основном на Java, поэтому просто для справки — в С++, к примеру, unsafe у вас по факту везде.
GUI фреймворк это как правило всё же дерево, причём готовое.
Это всего лишь перенос ручной конфигурации в другое место. Сравните с CMake target_include_directories. Вы задаёте "публичные" и "приватные" пути у самого таргета. Далее, при подключении этого таргета как зависимости все его публичные include paths, а также include paths от всех его публичных зависимостей (в т.ч. транзитивных) автоматом попадают в ваш зависимый таргет. Таким же образом это работает для libraries, definitions etc.
Несколько скромных вопросов от С++ разработчика.
Не совсем понятно, как это защитит от eval. Или если плохой пакет будет воровать чужие импорты.
Не знаю насчёт SJW, но на npmjs.org (если вы о нём) хотя бы вменяемые переходы цвета. Белый-голубой-синий-голубой-белый. А не малиновый-зелёный-чёрный-канареечный...
Новый дизайн откровенно ужасен. Такое впечатление, что авторов покусали бешеные маркетоиды, ментально доминируемые инвесторами, уж извините за прямоту.
Прочитал. Со статьёй он то ли не связан, то ли противоположен ей. Или это как в байке про Ландау:
Я вас огорчу. В Windows теперь каноничная комба — Win+Space. Старое доброе окошко настройки раскладок тщательно закопано.
Я так и не увидел, какие проблемы должен решать новый язык.
Касательно же предложений из статьи
А как автор планирует добавлять новые конструкции? Каждой функции по отдельному синтаксису? И всё впихнуть в стандарт? И, главное, как это потом читать? Формальный синтаксис имеет ту же цель, что и математические знаки — стандартизировать элементы и упростить чтение.
BigInt, Decimal, Rational etc. — уже давно придуманы. Просто использовать бесконечную точность везде крайне неэффективно.
Так и не понял. Сначала автор против метапрограммирования. Потом автор против больших стандартов, которые закрывают эту проблему. При том, что оба постулата напрямую противоречат постулату "Долой синтаксис", который будет провоцировать свой синтаксис на каждый чих.
В динамике вам точно так же придётся писать проверки для обработки собственно значений
Типы-суммы это очень даже статическая типизация. Вы статически знаете, что значение внутри или типа А, или Б. Назвать её динамической — примерно как назвать int динамически типизированным, просто потому что там могут лежать разные числа.