Огромное спасибо за статью, я врубился:) Пишите еще на тему криптографии, очень интересно. Именно то, какие возможности в принципе предоставляет современная криптография, какие задачи решает а какие нет.
FAR как-бы консольный.
Если бы в Windows консоль была бы более развита, FAR мог бы стать аналогом линуксового MC. Но поскольку «из коробки» консоль весьма примитивна (даже размер окна динамически не изменить, не говоря уже об отсутствии ssh), то смысла в FAR по сравнению с TC особого нет. Консоль подразумевает консоль во всем, а например контекстное меню для файла (весьма часто используемый инструмент) — графическое, т.е. получается некая мешанина консоли и GUI. Иконки файлов — графические, FAR не отображает. Всякие табы, изменяемые ширины столбцов, тулбары с полезными программами (они опять же иконки) в концепцию FAR не вписываются.
Хотя вот если бы в винде была более развитая консоль, то FAR был бы практически обязательной программой, как MC в Linux:)
Ну я тоже не сторонник абсолютно жестких систем типизации — когда между int и bool заставляют явно преобразовывать. Формально они правы конечно… но соглашение ноль==false, не ноль==true кажется вполне однозначным.
Вариант С/С++ (впрочем с некоторыми улучшениями — что-то я бы усилил, что-то ослабил) мне нравится больше всего (хотя наверное здесь есть фактор привычки).
Да нисколько. В моем примере нет структур, а просто у каждого аргумента добавлен тип — можно рассматривать это как часть имени. Структуры это уже посерьезнее, когда понятно что код становится достаточно общим и универсальным, «закрепляется» в проекте как часть архитектуры.
Я тоже не люблю лишнюю писанину. Но только ли в этом вопрос?
Непонятно что вы имеете в виду с интерфейсами. Я бы просто написал (псеводкод на некотором типизированном языке, «void=>void» — тип для функции, не принимающей никаких параметров и не возвращающей никакого значения)
function createDialog(string title, string content, string footer, void=>void onSubmit, void=>void onDismiss) {
// do something
}
Меня вот просто выводила из себя (до желания стучаться головой о стенку) ситуация, когда я смотрю код на php или js, там какая-то функция с аргументами, или просто какие-то переменные, и я НЕ ПОНИМАЮ, каких они типов. Чего мне ждать — числа, строки, структуры (если структуры то какой, с какими полями каких типов), функции (опять же с каким списком аргументов)? Что я имею права с ними делать а что нет? Ну хорошо, что в вебе в основном строки. В основном — но не всегда. Вот честно, не представляю как вы с этим живете :)
А можно ли использовать последние версии ObjC не на MacOS?
Реализация Swift для Linux вроде есть (правда я не знаю, самая последняя или нет).
Какой-то ObjC входит в состав GCC, но вроде бы там нечто весьма древнее, и фичи, описываемые в данной статье, там скорее всего недоступны.
Я вот тоже сторонник статической типизации. И поскольку статью писал человек мыслящий также как я, то его точка зрения вполне понятна. Но крайне интересно было бы прочитать аналогичную статью, написанную разработчиком на JS. Именно с развернутой критикой статической типизации и демонстрацией преимуществ динамической, на реальных примерах. Ну или хотя-бы развернутый комментарий. Мне кажется, такое погружение в противоположную точку зрения здорово расширяет восприятие, ну и вообще интересно.
Это не динамическая типизация, а низвоуровневый доступ к памяти. Такой доступ нужно делать явно, и применяется он только в очень специальных ситуациях.
Возможно, рецензирование исследований должно быть государственным. Я например был бы только за, если бы часть моих налогов отправлялась на проверку научных публикаций и оплату труда ученых.
Но доступ к знаниям должен быть бесплатным, это совершенно однозначно. Знания генерируются учеными (как правило на государственные деньги), нужны они обычно другим ученым, зачем здесь какие-то коммерческие посредники?
Не, Total Commander самый лучший. Да, жалко что он не кроссплатформенный и с закрытым кодом… аналоги под линукс к сожалению не дотягивают.
Для работы с фотографиями, музыкой, видео, книгами и прочим медиаконтентом по идее нужны специальные менеджеры — просто потому что там слишком много специального функционала.
Есть еще проблема файловых систем, то что метаинформация хранится в самом файле а не в файловой системе в виде именно метаинформации. Т.е. чтобы отсортировать картинки по разрешению, нужно открыть каждую картинку и прочитать заголовок — что накладно, куда проще было бы стандартизировать несколько десятков тегов для всех основных типов контента и хранить это непосредственно в атрибутах файла. Но это проблемы файловых систем, а не файловых менеджеров…
Скорее ввести новый формат объектных файлов, ориентированных на модули и содержащих достаточно метаинформации. Заодно и реализовать компиляцию шаблонов в промежуточное двоичное представление.
Да, наверное вы правы, так еще больше неявности…
Тогда еще вариант: если функция может генерировать исключение, то компилятор должен убедиться, что оно где-то обрабатывается, иначе — ошибка компиляции. Можно ввести в прототип функции информацию об исключениях, которые она может сгенерировать.
Конечно, программист может влепить глобальный catch куда нибудь в main, и тогда никаких ошибок компиляции не будет… но я например ни в коем случае не буду так делать, а напротив — постараюсь перехватить исключения как можно раньше.
Еще мысль. Я как-то думал о том, какими должны быть исключения… и пришла в голову такая мысль (возможно странная): было бы хорошо, если бы функции были написаны некоторым универсальным образом, таким, что один и тот же оператор мог бы и генерировать исключение, и возвращать код возврата — в зависимости от того, как устроен вызывающий код. Т.е. объединить throw и return в специальный общий оператор.
Например, если выше в стеке вызовов явно были try{} catch{} — то генерируем исключение; если контекст вызовов такой, что исключений этого типа быть не должно (или например какой-нибудь блок noexcept{} ) — возвращаем код возврата. Это не исключает возможности всегда явно генерировать исключения или всегда явно возвращать код возврата.
Как такое сделать? Например, какой-то глобальной таблицей/стеком активных блоков try, т.е. при входе в блок try в этот глобальный стек заносится какой-то объект, при выходе — извлекается. При необходимости бросить исключение — проверяется, а нет ли в этом стеке объекта соответствующего типа. При нормальной (успешной) работе функций это вроде бы никаких накладных расходов не создает.
Зато это дает возможность использовать одни и те же функции и в коде без исключений, и в коде с исключениями, и никаких сюрпризов типа необработанных исключений не будет.
Добавлю, что такое наверное можно даже специальной библиотекой реализовать… Только нужно в точке «try {» знать какие будут «catch», можно сделать макрос и явно прописывать, но компилятор с этим справился бы лучше.
Даже не знаю. У меня неоднозначное отношение к исключениям. С одной стороны, это удобный механизм обработки ошибок. С другой — мне дико не нравится, что любая функция может выбросить исключение, это такой современный goto. Особенно по всякой фигне типа невозможности преобразовать строку в число потому что в строке попалась буква.
С одной стороны хочется чтобы все явно. С другой — писать для каждой функции какие исключения она может выбросить, будет сильно утомительно. Спецификатор try перед вызовом — с одной стороны хорошо что явно, с другой плохо что писанина. И еще груз совместимости со старыми исключениями… Просто не знаю:)
А если бы проектировать язык с нуля, с учетом ошибок дизайна предыдущих языков программирования, то какой бы вы видели идеальную систему исключений?
Ну что-ж… по моим скромным представлениям об этапах развития разных народов, в Китае сейчас что-то вроде 60-х годов в СССР. Старшее поколение — необразованные деревенские жители, наводнившие города, их дети — уже образованные и стремящиеся к городской жизни с соответствующими ценностями и мышлением. Пара десятков лет, и можно ждать социальных волнений. Думаю, этот рейтинг только подогреет почву для новой революции.
Что еще за конечность процесса сознания?
Некоторые скептики говорят «а вдруг память переполнится». Но это лишь профессиональное когнитивное искажение, вызванное современным цифровым миром. Память человека не цифровая, старая информация непрерывно компактифицируется в нейросети, так что вы например не помните что именно вы делали ровно 10 лет назад (вы можете это знать из общих соображений — это и есть компактификация, но вспомнить в точности и воспроизвести кратковременную память, то что вы непосредственно видели и слышали — не можете).
интереснее:)
По сути все идет к тому что в каждом компиляторе C++ будет встроенный интерпретатор C++. Интересный путь развития…
Если бы в Windows консоль была бы более развита, FAR мог бы стать аналогом линуксового MC. Но поскольку «из коробки» консоль весьма примитивна (даже размер окна динамически не изменить, не говоря уже об отсутствии ssh), то смысла в FAR по сравнению с TC особого нет. Консоль подразумевает консоль во всем, а например контекстное меню для файла (весьма часто используемый инструмент) — графическое, т.е. получается некая мешанина консоли и GUI. Иконки файлов — графические, FAR не отображает. Всякие табы, изменяемые ширины столбцов, тулбары с полезными программами (они опять же иконки) в концепцию FAR не вписываются.
Хотя вот если бы в винде была более развитая консоль, то FAR был бы практически обязательной программой, как MC в Linux:)
Вариант С/С++ (впрочем с некоторыми улучшениями — что-то я бы усилил, что-то ослабил) мне нравится больше всего (хотя наверное здесь есть фактор привычки).
Я тоже не люблю лишнюю писанину. Но только ли в этом вопрос?
Меня вот просто выводила из себя (до желания стучаться головой о стенку) ситуация, когда я смотрю код на php или js, там какая-то функция с аргументами, или просто какие-то переменные, и я НЕ ПОНИМАЮ, каких они типов. Чего мне ждать — числа, строки, структуры (если структуры то какой, с какими полями каких типов), функции (опять же с каким списком аргументов)? Что я имею права с ними делать а что нет? Ну хорошо, что в вебе в основном строки. В основном — но не всегда. Вот честно, не представляю как вы с этим живете :)
Реализация Swift для Linux вроде есть (правда я не знаю, самая последняя или нет).
Какой-то ObjC входит в состав GCC, но вроде бы там нечто весьма древнее, и фичи, описываемые в данной статье, там скорее всего недоступны.
Но доступ к знаниям должен быть бесплатным, это совершенно однозначно. Знания генерируются учеными (как правило на государственные деньги), нужны они обычно другим ученым, зачем здесь какие-то коммерческие посредники?
Для работы с фотографиями, музыкой, видео, книгами и прочим медиаконтентом по идее нужны специальные менеджеры — просто потому что там слишком много специального функционала.
Есть еще проблема файловых систем, то что метаинформация хранится в самом файле а не в файловой системе в виде именно метаинформации. Т.е. чтобы отсортировать картинки по разрешению, нужно открыть каждую картинку и прочитать заголовок — что накладно, куда проще было бы стандартизировать несколько десятков тегов для всех основных типов контента и хранить это непосредственно в атрибутах файла. Но это проблемы файловых систем, а не файловых менеджеров…
Тогда еще вариант: если функция может генерировать исключение, то компилятор должен убедиться, что оно где-то обрабатывается, иначе — ошибка компиляции. Можно ввести в прототип функции информацию об исключениях, которые она может сгенерировать.
Конечно, программист может влепить глобальный catch куда нибудь в main, и тогда никаких ошибок компиляции не будет… но я например ни в коем случае не буду так делать, а напротив — постараюсь перехватить исключения как можно раньше.
Например, если выше в стеке вызовов явно были try{} catch{} — то генерируем исключение; если контекст вызовов такой, что исключений этого типа быть не должно (или например какой-нибудь блок noexcept{} ) — возвращаем код возврата. Это не исключает возможности всегда явно генерировать исключения или всегда явно возвращать код возврата.
Как такое сделать? Например, какой-то глобальной таблицей/стеком активных блоков try, т.е. при входе в блок try в этот глобальный стек заносится какой-то объект, при выходе — извлекается. При необходимости бросить исключение — проверяется, а нет ли в этом стеке объекта соответствующего типа. При нормальной (успешной) работе функций это вроде бы никаких накладных расходов не создает.
Зато это дает возможность использовать одни и те же функции и в коде без исключений, и в коде с исключениями, и никаких сюрпризов типа необработанных исключений не будет.
Добавлю, что такое наверное можно даже специальной библиотекой реализовать… Только нужно в точке «try {» знать какие будут «catch», можно сделать макрос и явно прописывать, но компилятор с этим справился бы лучше.
С одной стороны хочется чтобы все явно. С другой — писать для каждой функции какие исключения она может выбросить, будет сильно утомительно. Спецификатор try перед вызовом — с одной стороны хорошо что явно, с другой плохо что писанина. И еще груз совместимости со старыми исключениями… Просто не знаю:)
А если бы проектировать язык с нуля, с учетом ошибок дизайна предыдущих языков программирования, то какой бы вы видели идеальную систему исключений?
Некоторые скептики говорят «а вдруг память переполнится». Но это лишь профессиональное когнитивное искажение, вызванное современным цифровым миром. Память человека не цифровая, старая информация непрерывно компактифицируется в нейросети, так что вы например не помните что именно вы делали ровно 10 лет назад (вы можете это знать из общих соображений — это и есть компактификация, но вспомнить в точности и воспроизвести кратковременную память, то что вы непосредственно видели и слышали — не можете).