Кстати, исключительно логичная вещь, которая по идее должна быть во всех языках программирования (но увы, это не так). Скажем, число 0 - это что? int, float, double, байт, слово, двойное слово, четверное слово, знаковое, беззнаковое, или может какой нибудь объект "длинной арифметики"? В большинстве языков тип (скажем int32) сразу прибивается к константе гвоздями. И дальнейшее использование константы в выражениях с объектами других типов подразумевает приведение типа (или всякие постфиксы, типа 0ULL). А на самом деле 0 - это просто 0, математическая абстракция, которая по уму должна приводиться к наиболее удобному типу непосредственно в месте использования. Так что в Go все правильно сделали.
Проблема в том что "файл проекта" в существующих языках не является частью стандарта языка. Хотя казалось бы, почему не стандартизировать? Тогда заодно решилась бы и проблема совмесимости между разными компиляторами и IDE. Файл-то один, стандартный, работай в любой ОС, с любым компилятором и из любой IDE.
Кстати интересно, а если поставить на другой диск Linux, то можно ли из него запускать ранее установленную винду через виртуалку? По идее должно быть можно. И если отключить такой винде инет, то можно более-менее спокойно пользоваться уникальным виндовским софтом (фотошоп, видеоредакторы и т.п.) и не связвыаться с обновлениями?
Дело не в GUI. Я никогда толком не пользовался make-файлами и потому у меня глаз незамыленный. Прочитал первую попавшуюся статью на Хабре - в целом все понятно, но это же сплошной антипаттерн. Какой-то текстовый ассемблер или что-то типа того. Общая область видимости, глобальные и магические переменные, все недостатки bash-скриптов (строки не в кавычках и прочее)... Словно бы из мира современных языков тебя окунули в какой-то FORTRAN/ALGOL/COBOL. Неудивительно что люди в этом не хотят разбираться и относятся как к какому-то древнему legacy, которое "как-то работает и ладно".
При этом еще большой вопрос, а нужен ли именно такой подход для сборки проектов. Мне больше нравится подход не make-файлов, а файлов проекта: есть некий "файл проекта" на базе стандартного структурного формата (json, xml...), который содержит в отдельных секциях список всех исходников, опции компиляции, информацию о целях сборки, информацию о конфигурациях (Debug, Release и т.п.). Все остальное решает компилятор. В редких случаях, когда какой-то конкретный файл нужно собрать с особыми опциями, или вызвать внешнюю программу, к файлу добавляется информация PreBuild/PostBuild. Преимуществ у такого подхода масса: иерархическая структурированность, пригодность для автоматического изменения, в т.ч. с помощью GUI (это же структурный формат для которого есть масса парсеров), использование в качестве файла ассоциированного с IDE (щелкаешь по нему и проект загружается в IDE, с деревом исходников, со всеми настройками).
Согласен, за это я Питон не люблю (как уже отметил выше). Но в сравнении с bash у него хотя-бы частично классический синтаксис. Строки это строки, числа это числа, классически задаются списки, массивы и т.д.
Они свернули именно туда куда планировали (и скорее всего планировали задолго до 2012). А вот мы свернули не туда где-то в 1992-1993, когда, отвлекшись на чисто экономические трудности, спустили на тормозах идею люстрации сотрудников одной конкретной государственной организации...
У меня волосы шевелятся когда я вижу любой код на bash)) Как вообще на этом можно что-то писать? Хотя Питон я тоже не люблю, но он хотя-бы придерживается классического синтаксиса языков программирования.
Нет, вполне понятно что любые скрипты командной строки - это в каком-то смысле развитие самой идеи запуска программ в командной строке, а значит синтаксис путей, аргументов командной строки, пайплайнов и т.п. должен быть в скриптах без изменений. Это накладывает существенные ограничения на синтаксис скриптов - строки не в кавычках, пробелы вместо запятых и прочая муть, делающая bash очень сильно отличающимся от любого классического языка. Не знаю можно ли было пойти по другому пути в принципе... Я не пишу "скрипты" как таковые, но если мне нужна простая утилита командной строки - я пишут ее на Go.
Ну вот хочется чтобы делалось (может не в firefox, но хоть в каком-то браузере, их сейчас много). А вместо этого мы видим какие-то дизайнерские изыски, новые эмодзи и прочее.
Да так и делаю, но VPN влияет на всю систему (и потому приходится запускать VPN в виртуалке, такие вот костыли). Есть еще программы-проксификаторы, но они вообще что-то там подменяют в системных вызовах winsock32. И они точно не могут создать цепочку из прокси-расширений, потому что эти расширения работают внутри браузера.
А что в этом поведении неочевидного? Визуализация (в настройках) - простейший список, в котором элементы можно гонять вверх-вниз, и также включать/отключать чекбоксами. В списке - имена прокси (для человекочитаемости; если имени нет то оно генерируется как ip:port; но имя всегда можно задать вручную), в дополнительном столбце можно выводить сетевую статистику (чтобы понять где какая скорость, где тормозит/не работает и т.д.).
Вообще интересно, а есть неофициальные проекты "хакерских" клиентов для Телеграма, т.е. таких которые предоставляют пользователю гораздо больше функций - в частности сохранение всего контента независимо от наличия разрешений на сохранение и того что контент впоследствии может быть "удален" , глубокое исследование социальных графов, скачивание содержимого чатов и т.п.?
Мне интересно когда выпустят браузер, который из коробки будет поддерживать цепочки прокси. В частности, чтобы настройки прокси браузера не пересекались с прокси-расширениями. Т.е. если я в настройки прописал внешний прокси, и еще поставил расширение, то они бы работали одновременно в цепочке. А при установке нескольких прокси-расширений они должны уметь работать одновременно также в цепочке.
зачем-то выпилен старый добрый классический интерфейс, в результате пользователи вынуждены пользоваться новым вырвиглазным
добавлена система обновлений, которая постоянно что-то качает из инета и сливает в инет (или это система телеметрии?), в общем компьютер живет своей жизнью
Не самомодифицирующегося, а модифицируемого внешними средствами (которые как правило являются частью ОС или близкими к этому понятию системными программами - такими как CLR/JVM).
Из именно самомодифицирующегося (т.е. когда код модификации программы является частью программы и пишется разработчиком программы вместе с остальным кодом) приходит в голову разве что какие-нибудь полиморфные вирусы. Ах да, еще вроде бы в ATL/WTL для таблиц обработчиков событий применяется какой-то хитрый способ генерации кода под названием "thunks".
Термин "Статическая рефлексия " дан максимально непонятно.
Как я понял, статическая значит работает на этапе компиляции, а точнее на этапах когда во время компиляции выполняется пользовательский код (а это и constexpr/consteval, и шаблонное метапрограммирование). Здесь и генератором, и потребителем метаданных в конечном итоге оказывается компилятор. А в рантайм эти метаданные могут попасть только если их туда специально затолкать, т.е. например использовать для инициализации рантайм-объектов.
RTTI и C# Reflection работают во время выполнения - там компилятор просто подготавливает константные метаданные и сохраняет их в exe-шнике, эти данные используются в рантайме для инициализации всяких reflection-объектов, обращение к которым происходит также в рантайме.
Ну так генерация машинного кода с использованием AVX или без него и есть модификация поведения программы.
Но не самомодификация. Этими действиями занимается операционная система или другие программы (java и т.д.). В некотором смысле JIT-компиляция это следующий уровень загрузки exe-файлов (когда загрузчик перед передачей управления настраивает адреса по таблицам, хранящимся в заголовке exe-файла). Еще можно вспомнить программы-упаковщики, протекторы и т.п.
В прошлом компания избегала магнитных чехлов из-за возможных помех при работе с S Pen. В серии Galaxy S25, похоже, решили эту проблему, что позволило Samsung конкурировать с такими брендами, как OnePlus и Oppo.
Неужели конкурировать больше нечем кроме как всякими беспроводными зарядками?
Кстати, исключительно логичная вещь, которая по идее должна быть во всех языках программирования (но увы, это не так). Скажем, число 0 - это что? int, float, double, байт, слово, двойное слово, четверное слово, знаковое, беззнаковое, или может какой нибудь объект "длинной арифметики"? В большинстве языков тип (скажем int32) сразу прибивается к константе гвоздями. И дальнейшее использование константы в выражениях с объектами других типов подразумевает приведение типа (или всякие постфиксы, типа 0ULL). А на самом деле 0 - это просто 0, математическая абстракция, которая по уму должна приводиться к наиболее удобному типу непосредственно в месте использования. Так что в Go все правильно сделали.
Проблема в том что "файл проекта" в существующих языках не является частью стандарта языка. Хотя казалось бы, почему не стандартизировать? Тогда заодно решилась бы и проблема совмесимости между разными компиляторами и IDE. Файл-то один, стандартный, работай в любой ОС, с любым компилятором и из любой IDE.
Кстати интересно, а если поставить на другой диск Linux, то можно ли из него запускать ранее установленную винду через виртуалку? По идее должно быть можно. И если отключить такой винде инет, то можно более-менее спокойно пользоваться уникальным виндовским софтом (фотошоп, видеоредакторы и т.п.) и не связвыаться с обновлениями?
Дело не в GUI. Я никогда толком не пользовался make-файлами и потому у меня глаз незамыленный. Прочитал первую попавшуюся статью на Хабре - в целом все понятно, но это же сплошной антипаттерн. Какой-то текстовый ассемблер или что-то типа того. Общая область видимости, глобальные и магические переменные, все недостатки bash-скриптов (строки не в кавычках и прочее)... Словно бы из мира современных языков тебя окунули в какой-то FORTRAN/ALGOL/COBOL. Неудивительно что люди в этом не хотят разбираться и относятся как к какому-то древнему legacy, которое "как-то работает и ладно".
При этом еще большой вопрос, а нужен ли именно такой подход для сборки проектов. Мне больше нравится подход не make-файлов, а файлов проекта: есть некий "файл проекта" на базе стандартного структурного формата (json, xml...), который содержит в отдельных секциях список всех исходников, опции компиляции, информацию о целях сборки, информацию о конфигурациях (Debug, Release и т.п.). Все остальное решает компилятор. В редких случаях, когда какой-то конкретный файл нужно собрать с особыми опциями, или вызвать внешнюю программу, к файлу добавляется информация PreBuild/PostBuild. Преимуществ у такого подхода масса: иерархическая структурированность, пригодность для автоматического изменения, в т.ч. с помощью GUI (это же структурный формат для которого есть масса парсеров), использование в качестве файла ассоциированного с IDE (щелкаешь по нему и проект загружается в IDE, с деревом исходников, со всеми настройками).
Согласен, за это я Питон не люблю (как уже отметил выше). Но в сравнении с bash у него хотя-бы частично классический синтаксис. Строки это строки, числа это числа, классически задаются списки, массивы и т.д.
Они свернули именно туда куда планировали (и скорее всего планировали задолго до 2012). А вот мы свернули не туда где-то в 1992-1993, когда, отвлекшись на чисто экономические трудности, спустили на тормозах идею люстрации сотрудников одной конкретной государственной организации...
У меня волосы шевелятся когда я вижу любой код на bash)) Как вообще на этом можно что-то писать? Хотя Питон я тоже не люблю, но он хотя-бы придерживается классического синтаксиса языков программирования.
Нет, вполне понятно что любые скрипты командной строки - это в каком-то смысле развитие самой идеи запуска программ в командной строке, а значит синтаксис путей, аргументов командной строки, пайплайнов и т.п. должен быть в скриптах без изменений. Это накладывает существенные ограничения на синтаксис скриптов - строки не в кавычках, пробелы вместо запятых и прочая муть, делающая bash очень сильно отличающимся от любого классического языка. Не знаю можно ли было пойти по другому пути в принципе... Я не пишу "скрипты" как таковые, но если мне нужна простая утилита командной строки - я пишут ее на Go.
Ну вот хочется чтобы делалось (может не в firefox, но хоть в каком-то браузере, их сейчас много). А вместо этого мы видим какие-то дизайнерские изыски, новые эмодзи и прочее.
Да так и делаю, но VPN влияет на всю систему (и потому приходится запускать VPN в виртуалке, такие вот костыли). Есть еще программы-проксификаторы, но они вообще что-то там подменяют в системных вызовах winsock32. И они точно не могут создать цепочку из прокси-расширений, потому что эти расширения работают внутри браузера.
А что в этом поведении неочевидного? Визуализация (в настройках) - простейший список, в котором элементы можно гонять вверх-вниз, и также включать/отключать чекбоксами. В списке - имена прокси (для человекочитаемости; если имени нет то оно генерируется как ip:port; но имя всегда можно задать вручную), в дополнительном столбце можно выводить сетевую статистику (чтобы понять где какая скорость, где тормозит/не работает и т.д.).
Если столько опасностей поражения током, то почему вы не работаете в резиновых перчатках?
Вообще интересно, а есть неофициальные проекты "хакерских" клиентов для Телеграма, т.е. таких которые предоставляют пользователю гораздо больше функций - в частности сохранение всего контента независимо от наличия разрешений на сохранение и того что контент впоследствии может быть "удален" , глубокое исследование социальных графов, скачивание содержимого чатов и т.п.?
Почему бы и нет? Это в чистом виде расширения ОС. Как и драйверы. Только эти работают на другом уровне.
Они модифицируют себя? Нет, другой код. Вот если бы они модифицировали свой собственный код, то да. А так - нет.
Динамическая генерация шейдеров пожалуй подпадает под это понятие.
Обучение моделей? Ну не знаю. Это все-же данные а не код. Так можно сказать что и конфиги с настройками это самомодифицирующийся код:)
Мне интересно когда выпустят браузер, который из коробки будет поддерживать цепочки прокси. В частности, чтобы настройки прокси браузера не пересекались с прокси-расширениями. Т.е. если я в настройки прописал внешний прокси, и еще поставил расширение, то они бы работали одновременно в цепочке. А при установке нескольких прокси-расширений они должны уметь работать одновременно также в цепочке.
зачем-то выпилен старый добрый классический интерфейс, в результате пользователи вынуждены пользоваться новым вырвиглазным
добавлена система обновлений, которая постоянно что-то качает из инета и сливает в инет (или это система телеметрии?), в общем компьютер живет своей жизнью
Не самомодифицирующегося, а модифицируемого внешними средствами (которые как правило являются частью ОС или близкими к этому понятию системными программами - такими как CLR/JVM).
Из именно самомодифицирующегося (т.е. когда код модификации программы является частью программы и пишется разработчиком программы вместе с остальным кодом) приходит в голову разве что какие-нибудь полиморфные вирусы. Ах да, еще вроде бы в ATL/WTL для таблиц обработчиков событий применяется какой-то хитрый способ генерации кода под названием "thunks".
Как я понял, статическая значит работает на этапе компиляции, а точнее на этапах когда во время компиляции выполняется пользовательский код (а это и constexpr/consteval, и шаблонное метапрограммирование). Здесь и генератором, и потребителем метаданных в конечном итоге оказывается компилятор. А в рантайм эти метаданные могут попасть только если их туда специально затолкать, т.е. например использовать для инициализации рантайм-объектов.
RTTI и C# Reflection работают во время выполнения - там компилятор просто подготавливает константные метаданные и сохраняет их в exe-шнике, эти данные используются в рантайме для инициализации всяких reflection-объектов, обращение к которым происходит также в рантайме.
Вот здесь вроде бы какие-то мысли на этот счет
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3381r0.html#why-not-a-keyword
Но не самомодификация. Этими действиями занимается операционная система или другие программы (java и т.д.). В некотором смысле JIT-компиляция это следующий уровень загрузки exe-файлов (когда загрузчик перед передачей управления настраивает адреса по таблицам, хранящимся в заголовке exe-файла). Еще можно вспомнить программы-упаковщики, протекторы и т.п.
Неужели конкурировать больше нечем кроме как всякими беспроводными зарядками?
Никогда не знал TypeScript, но примеры кода чем-то напомнили C++ :)