Вы предлагаете обобщить базовый синтаксис, но он и не является проблемой. Выучить ключевые слова и общие правила расстановки скобок и отступов в новом языке можно за день, а то и вовсе автоматически преобразовать имеющийся код к новым требованиям. Примерно тем же самым, только внутри одного языка, уже занимаются программы для автоформатирования кода. Условному astyle достаточно передать ровно 1 аргумент, чтоб привести код к одному из стандартных стилей. Даже если условные JS и Go требуют разного синтаксиса, то их по большей части можно преобразовать друг в друга, что даже сработает для простых случаев типа школьных заданий по информатике (вроде "Пользователь вводит 2 числа, программа должна вывести большее из них, или же написать что они равны").
Настоящая же сложность в том, что разные языки имеют разные библиотеки ( = разные имена системных констант, функций, классов, модулей, ит.д.), а самое главное - зачастую и разные идеи. В браузерном JS нет тредов, в лучшем случае service worker'ы, значит горутины не получится "просто переименовать". А прямого доступа к TCP/UDP нет вообще, только HTTP(S), WebSocket и RTP DataChannel, значит никакую программу, использующую другие сетевые протоколы вы в принципе не можете портировать без значительных изменений. А ни в JS, ни в Go нет поддержки настоящих, системных тредов, которая есть в Rust (и условный tokio позволяет очень легко запускать и таски = гринтреды = горутины). А паттерн-матчинг из того же Rust (match) чем заменять, switch-case ведь даже близко не подходит - цепочками if-ов?
Ибо генераторы абстрактных фабрик конфигураторов скриптов сборки нужного тебе проекта порой генерят не саму сборку а скрипт сборки в 40 тыщь раз больше чем сама прошивка.
Ох уж этот дивный мир сборки C, где сначала придумали make чтобы не писать shell-скрипты для сборки, а потом придумали automake чтоб не писать и тем более не шаблонизировать Makefile-ы вручную... В итоге генерируются configure-скрипты на 30 тысяч строк, которые затем (через пару минут работы) превращаются в Makefile на 5 тысяч строк.
Я бы сказал, что нужность / оправданность комментариев сильно зависит от самих комментариев и как они используются.
Например, комментарии к модулям, классам и заголовкам функций (типа JSDoc / Doxygen / Rustdoc / etc.) часто используются IDE для показа подсказок при автодополнении или для автогенерации онлайн-документации - их определённо стоит поддерживать, хоть это и дополнительная работа.
С другой же стороны, что-то вроде
// convert inches to millimeters
length *= 25.4;
действительно лучше было бы выделить в функцию с говорящим названием, тогда и комментарий стал бы не нужен.
Очень интересный функциональный стиль, когда почти все функции мутируют подаваемые на вход данные вместо создания новых...
Да и выполняться это должно в строго фиксированном порядке (если, конечно, вы не хотите иметь сырые овощи поверх коробки, или разогревать печь уже после "выпекания"), что подразумевает сайд-эффекты / монады, которые... ах да, которые позволяют в функциональщину добавить императивщину.
В комментариях пишут, что код слева/справа легче читается, но как будто никто не прочитал код полностью И слева, и справа написано по 28 строк, но слева на "обёртки" (заголовок + фигурные скобки - границы блока) функции ушло ровно 2 строки, а справа - 11 (немногим меньше половины, Карл!), причём по меньшей мере 3 функции там объявлены, но не реализованы.
Я понимаю, почему некоторые считают правый вариант более удобным/понятным, но есть же граница, когда дробление кода приносит больше синтаксического мусора, чем пользы. Тем более, очень это странное дробление:bake() создаёт oven с параметрами по умолчанию, но настройка = разогрев вынесен в отдельную функцию? Вы уж или factory / builder используйте, или настраивайте в этом же месте, а то ни туда, ни сюда. И почемуpizza инициализируется нужными значениями Base, Order и Cheese сразу, а не в 3 отдельных функциях?
Проблемы нет, просто хотелось напомнить, что если переменная (точнее, её тип) допускает значение, равное "ничего", то без проверки на это самое "ничего" не обойтись, независимо от языка и строгости/мощности его системы типов.
Кстати, очень интересно наблюдать за С-программистами, которые изучают алгебраические типы, и осознают, что type* - это фактически сумма NULL и non_null_ptr<type*>.
P.S. Зачем в JS, в отличие от большинства других языков, есть аж два разных "ничего" ( "ничего потому что ничего" =undefined и "ничего потому что так надо" =null) - отдельный интересный разговор.
Как будто в базовом JS не надо проверять на undefined...
Да и TS не один такой, где переменную с типом, аналогичным any, надо проверять на пустое значение: в C это проверка указателей на NULL (а потом ещё и приведение к ожидаемому, а не фактическому типу), в C++ - на nullptr, в Python - проверка на None, в Go - на nil, и так далее. Даже с более мощными, полноценными алгебраическими системами типов, всё равно надо проверять Option на Some(x) / None в случае Rust или Maybe на Just x / Nothing в случае Haskell, хоть там это и зачастую удобнее, чем может предложить if.
Нормальная рекомендация, учитывая что WordPad - это лютый огрызок по сравнению с Word.
Как используют Блокнот - видел (как встроенный в Windows, так и более мощные варианты типа Notepad++), редактор Markdown (в лице VS Code и Obsidian) - видел, Word - видел, LibreOffice Writer - видел (сам использую), а WordPad - разве что на занятиях/курсах, но не для каких-то реальных задач.
Очень важно, что на графике видно, что оно действительно падает до нуля.
Нет, не видно. Масштаб там такой, что меньше примерно ом см не разглядеть, слишком близко к оси X. При этом резистивность банальной, вовсе не сверхпроводящей меди - ом см, то есть если бы она была на графике (ну, для сравнения, как это по-хорошему и должно быть), то её сопротивление тоже было бы "действительно равно нулю".
Скорее, ФВ не имеет одного универсального алгоритма для проверки любой программы, это лишь набор методов/приёмов/техник, которые применяются в каждом случае по-своему. А в частных случаях и проблема останова разрешима.
Так что вся эта "портируемость" - миф, который разбивается когда начинаешь работать с разными системами. Хотите эффективное решение без костылей - делейте под конкретную платформу с использованием ее возможностей и особенностей.
Тот же условный C позволяет одинаково открывать файлы в разных системах только благодаря тому, что систмено-зависимый код сокрыт в недрах stdlib. Если ваша программа была написана, скажем, с использованием pthreadов - она не соберётся в MS VC, потому что нет в Win тредов по-POSIXовски. А в MinGW/Cygwin - соберётся, потому что там pthread.h - это обёртка на Win-реализацией. А можно с самого начала использовать треды из какой-нибудь GLib, которая тоже обёртка над POSIX/Win-тредами.
Если фича конкретной платформы очень удобная, то обычно какой-нибудь энтузиаст делает библиотеку, которая на изначальной платформе - тонкая обёртка, а на других лишь эмулирует аналогичное поведение (иногда частично). Например, условная libnicequeue может напрямую использовать MessageQueue на AS/400, и быть толстой обвязкой поверх какой-нибудь ZeroMQ для Win/Linux.
Не знаю в чём отличие, вы же начали с аргумента о работе в (не) админских учётках... Но давайте продолжим.
вы не ставите пиратский софт с левых сайтов. А что мешает так же поступать на винде?
Например, то что многие проекты с открытым кодом есть в оф. репах, а на Винде вам придётся собирать вручную (это не задача для обычного пользователя), либо искать сборки от сообщества. Например, сколько доверия у вас вызывает домен gyan.dev? А ведь на него ссылается оф. сайт FFMpeg как на место, где можно найти сборку для Windows.
Малвари не нужны права админа.
Руткитам, например, этого мало, обычный пользователь не залезет в загрузочную область. Какой-нибудь криптомайнер может хотеть зарегистрироваться в автозапуске всей системы, на случай если пользователь, например, на ночь компьютер не выключает, но из системы выходит. Прогрессивный похититель данных вообще может захотеть работать на уровне ядра, чтоб похищать всё, что только можно похитить. А так да, если малварь лишь портит жизнь одному конкретному пользователю - то достаточно его личной учётки. Впрочем, если поторопиться, то можно и собственными руками Ctrl+A Shift+Del Enter - и привет.
Вы хоть раз в винде работали на учетке без прав Администратора? Вероятно - нет. А в Линуксе почему-то работаете.
Отчасти это проблема самой Винды, а точнее её дружелюбия к пользователю-раздолбаю, который может не осилить, если не сможет делать всё сразу "из коробки" (а таких пользователей очень много).
Например, сколько учётных записей создаёт Винда, когда вы её устанавливаете? Одну, админскую - можно сразу брать и делать что угодно. А если вы потом создадите другую, то чтоб вам запустить нечто из-под админа, нужно вводить пароль админской. А сколько учётных записей создаёт Линукс при установке? Тоже одну, но пользовательскую, а также либо надо задать рутовый пароль, либо добавить этого одного пользователя в wheel (иногда и то, и другое). Просто так "всё сделать из-под своей учётки" нельзя, но чтоб сделать рутовое действие (sudo make me a sandwich), вы вводите свой пароль.
Двух обычных (но различимых) игральных кубиков достаточно, чтоб выбрать случайный символ из 36. Другими словами, чтоб сгенерировать случайную последовательность символов нужно лишь 1 коробочка с прозрачной стенкой и двумя кубиками внутри (ну и памятки-наклейки) - не выглядит как нечто сложное или дорогое, особенно сравнивая с самой "Энигмой". При желании можно было бы хоть в основной корпус встроить, даже с какой-нибудь прижимной пластиной, чтоб кубики не гремели при переноске.
Это типичный приём, хотя чаще он используется в виде "Ускоряем код на Python/JS в стотыщмильёнов раз", а в самой статье описывается создание нативного модуля на C/C++/Rust.
Ну да, действительно каких-то сверх-инноваций не случилось (квантовые компьютеры всё ещё не стоят в каждом утюге). Но тогда и качественных отличий в требуемых ресурсах тоже нет - побольше частоты, побольше объёмы, но в целом то же самое.
С другой стороны - простите, но вот уж "так же рисовал треугольнички" - это, мягко говоря, введение в заблуждение. В несколько раз выросло разрешение экрана и частота обновления, появились HDR режимы, количество этих самых треугольничков выросло на несколько порядков, на эти треугольнички натягиваются текстуры, которые тоже выросли на порядки, "модные шейдеры 6 версии" не бесплатно работают, появилась трассировка лучей в реальном времени, и так далее. Но да, что PlayStation 1 (как раз времён Win 95), что PS 5 "рисуют треугольнички".
На современных телефонах, как Android, так и iPhone, нельзя просто программировать приложения
...
Чтобы запустить Linux в 2023 году, требуется немного повозиться.
...
Для разработки ПО Linux — обязательное требование. Чтобы разрабатывать для Windows CE, необходим PC с Visual Studio — та же проблема, что и у современного iPhone.
То есть на этом устройстве тоже "нельзя просто программировать приложения", а чтоб таки программировать - "требуется немного повозиться". Что-то не сходится, ведь с аналогичным успехом можно "немного повозиться" и накатить на (подходящий) современный Android-смартфон Linux и "просто" программировать. Ещё и комфортнее - с адекватным разрешением экрана, с адекватным объёмом ОЗУ, с адекватной частотой процессора, с поддержкой современных сетевых протоколов и т.д. и т.п.
Не припомню чтоб в C был reinterpret_cast , это же C++ное. Но и в C++ нельзя разыменовывать указатели после reinterpret_cast (кроме очень отдельных случаев).
Если вы хотите сделать не-UB-шно, то в C надо использовать union, а в C++ - std::bit_cast
Вы предлагаете обобщить базовый синтаксис, но он и не является проблемой. Выучить ключевые слова и общие правила расстановки скобок и отступов в новом языке можно за день, а то и вовсе автоматически преобразовать имеющийся код к новым требованиям. Примерно тем же самым, только внутри одного языка, уже занимаются программы для автоформатирования кода. Условному astyle достаточно передать ровно 1 аргумент, чтоб привести код к одному из стандартных стилей. Даже если условные JS и Go требуют разного синтаксиса, то их по большей части можно преобразовать друг в друга, что даже сработает для простых случаев типа школьных заданий по информатике (вроде "Пользователь вводит 2 числа, программа должна вывести большее из них, или же написать что они равны").
Настоящая же сложность в том, что разные языки имеют разные библиотеки ( = разные имена системных констант, функций, классов, модулей, ит.д.), а самое главное - зачастую и разные идеи. В браузерном JS нет тредов, в лучшем случае service worker'ы, значит горутины не получится "просто переименовать". А прямого доступа к TCP/UDP нет вообще, только HTTP(S), WebSocket и RTP DataChannel, значит никакую программу, использующую другие сетевые протоколы вы в принципе не можете портировать без значительных изменений. А ни в JS, ни в Go нет поддержки настоящих, системных тредов, которая есть в Rust (и условный tokio позволяет очень легко запускать и таски = гринтреды = горутины). А паттерн-матчинг из того же Rust (
match) чем заменять,switch-caseведь даже близко не подходит - цепочкамиif-ов?Ох уж этот дивный мир сборки C, где сначала придумали
makeчтобы не писать shell-скрипты для сборки, а потом придумалиautomakeчтоб не писать и тем более не шаблонизироватьMakefile-ы вручную... В итоге генерируютсяconfigure-скрипты на 30 тысяч строк, которые затем (через пару минут работы) превращаются вMakefileна 5 тысяч строк.Я бы сказал, что нужность / оправданность комментариев сильно зависит от самих комментариев и как они используются.
Например, комментарии к модулям, классам и заголовкам функций (типа JSDoc / Doxygen / Rustdoc / etc.) часто используются IDE для показа подсказок при автодополнении или для автогенерации онлайн-документации - их определённо стоит поддерживать, хоть это и дополнительная работа.
С другой же стороны, что-то вроде
действительно лучше было бы выделить в функцию с говорящим названием, тогда и комментарий стал бы не нужен.
Очень интересный функциональный стиль, когда почти все функции мутируют подаваемые на вход данные вместо создания новых...
Да и выполняться это должно в строго фиксированном порядке (если, конечно, вы не хотите иметь сырые овощи поверх коробки, или разогревать печь уже после "выпекания"), что подразумевает сайд-эффекты / монады, которые... ах да, которые позволяют в функциональщину добавить императивщину.
В комментариях пишут, что код слева/справа легче читается, но как будто никто не прочитал код полностью И слева, и справа написано по 28 строк, но слева на "обёртки" (заголовок + фигурные скобки - границы блока) функции ушло ровно 2 строки, а справа - 11 (немногим меньше половины, Карл!), причём по меньшей мере 3 функции там объявлены, но не реализованы.
Я понимаю, почему некоторые считают правый вариант более удобным/понятным, но есть же граница, когда дробление кода приносит больше синтаксического мусора, чем пользы. Тем более, очень это странное дробление:
bake()создаётovenс параметрами по умолчанию, но настройка = разогрев вынесен в отдельную функцию? Вы уж или factory / builder используйте, или настраивайте в этом же месте, а то ни туда, ни сюда. И почемуpizzaинициализируется нужными значениями Base, Order и Cheese сразу, а не в 3 отдельных функциях?Проблемы нет, просто хотелось напомнить, что если переменная (точнее, её тип) допускает значение, равное "ничего", то без проверки на это самое "ничего" не обойтись, независимо от языка и строгости/мощности его системы типов.
Кстати, очень интересно наблюдать за С-программистами, которые изучают алгебраические типы, и осознают, что
type*- это фактически суммаNULLиnon_null_ptr<type*>.P.S. Зачем в JS, в отличие от большинства других языков, есть аж два разных "ничего" ( "ничего потому что ничего" =
undefinedи "ничего потому что так надо" =null) - отдельный интересный разговор.Например, сортировку массива чисел по значению, а не лексикографчески :)
Как будто в базовом JS не надо проверять на
undefined...Да и TS не один такой, где переменную с типом, аналогичным
any, надо проверять на пустое значение: в C это проверка указателей наNULL(а потом ещё и приведение к ожидаемому, а не фактическому типу), в C++ - наnullptr, в Python - проверка наNone, в Go - наnil, и так далее. Даже с более мощными, полноценными алгебраическими системами типов, всё равно надо проверятьOptionнаSome(x)/Noneв случае Rust илиMaybeнаJust x/Nothingв случае Haskell, хоть там это и зачастую удобнее, чем может предложитьif.Нормальная рекомендация, учитывая что WordPad - это лютый огрызок по сравнению с Word.
Как используют Блокнот - видел (как встроенный в Windows, так и более мощные варианты типа Notepad++), редактор Markdown (в лице VS Code и Obsidian) - видел, Word - видел, LibreOffice Writer - видел (сам использую), а WordPad - разве что на занятиях/курсах, но не для каких-то реальных задач.
Нет, не видно. Масштаб там такой, что меньше примерно
ом см не разглядеть, слишком близко к оси X. При этом резистивность банальной, вовсе не сверхпроводящей меди - 
ом см, то есть если бы она была на графике (ну, для сравнения, как это по-хорошему и должно быть), то её сопротивление тоже было бы "действительно равно нулю".
Скорее, ФВ не имеет одного универсального алгоритма для проверки любой программы, это лишь набор методов/приёмов/техник, которые применяются в каждом случае по-своему. А в частных случаях и проблема останова разрешима.
Тот же условный C позволяет одинаково открывать файлы в разных системах только благодаря тому, что систмено-зависимый код сокрыт в недрах stdlib. Если ваша программа была написана, скажем, с использованием
pthreadов - она не соберётся в MS VC, потому что нет в Win тредов по-POSIXовски. А в MinGW/Cygwin - соберётся, потому что там pthread.h - это обёртка на Win-реализацией. А можно с самого начала использовать треды из какой-нибудь GLib, которая тоже обёртка над POSIX/Win-тредами.Если фича конкретной платформы очень удобная, то обычно какой-нибудь энтузиаст делает библиотеку, которая на изначальной платформе - тонкая обёртка, а на других лишь эмулирует аналогичное поведение (иногда частично). Например, условная libnicequeue может напрямую использовать MessageQueue на AS/400, и быть толстой обвязкой поверх какой-нибудь ZeroMQ для Win/Linux.
В некоторых (многих?) дистрибутивах для root выключен вход из коробки, в /etc/shadow там что-то подобное:
То есть ни напрямую рутом зайти, ни
suне работают, толькоsudo. Можно, конечно, сделатьsudo passwd, но это уже не "из коробки".Не знаю в чём отличие, вы же начали с аргумента о работе в (не) админских учётках... Но давайте продолжим.
Например, то что многие проекты с открытым кодом есть в оф. репах, а на Винде вам придётся собирать вручную (это не задача для обычного пользователя), либо искать сборки от сообщества. Например, сколько доверия у вас вызывает домен gyan.dev? А ведь на него ссылается оф. сайт FFMpeg как на место, где можно найти сборку для Windows.
Руткитам, например, этого мало, обычный пользователь не залезет в загрузочную область. Какой-нибудь криптомайнер может хотеть зарегистрироваться в автозапуске всей системы, на случай если пользователь, например, на ночь компьютер не выключает, но из системы выходит. Прогрессивный похититель данных вообще может захотеть работать на уровне ядра, чтоб похищать всё, что только можно похитить.
А так да, если малварь лишь портит жизнь одному конкретному пользователю - то достаточно его личной учётки. Впрочем, если поторопиться, то можно и собственными руками Ctrl+A Shift+Del Enter - и привет.
Отчасти это проблема самой Винды, а точнее её дружелюбия к пользователю-раздолбаю, который может не осилить, если не сможет делать всё сразу "из коробки" (а таких пользователей очень много).
Например, сколько учётных записей создаёт Винда, когда вы её устанавливаете? Одну, админскую - можно сразу брать и делать что угодно. А если вы потом создадите другую, то чтоб вам запустить нечто из-под админа, нужно вводить пароль админской. А сколько учётных записей создаёт Линукс при установке? Тоже одну, но пользовательскую, а также либо надо задать рутовый пароль, либо добавить этого одного пользователя в wheel (иногда и то, и другое). Просто так "всё сделать из-под своей учётки" нельзя, но чтоб сделать рутовое действие (
sudo make me a sandwich), вы вводите свой пароль.Двух обычных (но различимых) игральных кубиков достаточно, чтоб выбрать случайный символ из 36. Другими словами, чтоб сгенерировать случайную последовательность символов нужно лишь 1 коробочка с прозрачной стенкой и двумя кубиками внутри (ну и памятки-наклейки) - не выглядит как нечто сложное или дорогое, особенно сравнивая с самой "Энигмой". При желании можно было бы хоть в основной корпус встроить, даже с какой-нибудь прижимной пластиной, чтоб кубики не гремели при переноске.
Это типичный приём, хотя чаще он используется в виде "Ускоряем код на Python/JS в стотыщмильёнов раз", а в самой статье описывается создание нативного модуля на C/C++/Rust.
Ну да, действительно каких-то сверх-инноваций не случилось (квантовые компьютеры всё ещё не стоят в каждом утюге). Но тогда и качественных отличий в требуемых ресурсах тоже нет - побольше частоты, побольше объёмы, но в целом то же самое.
С другой стороны - простите, но вот уж "так же рисовал треугольнички" - это, мягко говоря, введение в заблуждение. В несколько раз выросло разрешение экрана и частота обновления, появились HDR режимы, количество этих самых треугольничков выросло на несколько порядков, на эти треугольнички натягиваются текстуры, которые тоже выросли на порядки, "модные шейдеры 6 версии" не бесплатно работают, появилась трассировка лучей в реальном времени, и так далее. Но да, что PlayStation 1 (как раз времён Win 95), что PS 5 "рисуют треугольнички".
То есть на этом устройстве тоже "нельзя просто программировать приложения", а чтоб таки программировать - "требуется немного повозиться". Что-то не сходится, ведь с аналогичным успехом можно "немного повозиться" и накатить на (подходящий) современный Android-смартфон Linux и "просто" программировать. Ещё и комфортнее - с адекватным разрешением экрана, с адекватным объёмом ОЗУ, с адекватной частотой процессора, с поддержкой современных сетевых протоколов и т.д. и т.п.
Не припомню чтоб в C был
reinterpret_cast, это же C++ное. Но и в C++ нельзя разыменовывать указатели послеreinterpret_cast(кроме очень отдельных случаев).Если вы хотите сделать не-UB-шно, то в C надо использовать
union, а в C++ -std::bit_cast