Обратную совместимость я бы лучше заменил банальным словом «лень»…
Обратная совместимость — продукт нежелания миллионов программистов переписывать миллиарды строк кода(знаменитое Java-вское «написано однажды — работает всегда»). Каждому из нас не хочется этого делать… Но проблема тут не в программисте, а в языке, на котором написан код.
Язык С, как и все его компилируемые наследники(C++, Java, ..., но не Python, хотя там свои проблемы) в нынешние дни имеют ряд коренных недостатков, которые были не видны людям из далеких 70-x. Например, в С/C++ нельзя просто взять и написать ассемблерные вставки или функции. Это просто отсутствует в стандарте. И что прикажете с этим делать? А ведь даже такая малая стандартизируемая возможность в корне может ускорить выполнение кода…
А если предположить, что ОС и язык программирования будут предоставлять такие возможности, что только совсем гуманитарий не сможет написать нужную ему программу с его функционалом...(В качестве совсем утрированного примера можно взять MS-Dos и Python.)
Я готов поверить, что линукс 90-х был «той самой» системой, но сейчас я больше даже поверю винде… Половина пакетов написана на python, потребление памяти выше, никаких пояснений.
Разве можно назвать сейчас этого бесповоротного монстра хорошей системой?
Я был бы рад поучаствовать в этом, но сначала хочу выразить свою позицию по этому поводу…
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C. То есть все современное ПО держится сейчас по сути на одном языке(даже Python в него транслируется). Но этот язык был написан 40 с лишком лет назад, и, следовательно, безбожно устарел под требования современных задач(ведь сейчас 3 идиом, включая кроссплатформенность уже не хватает; им параллелизм подавай)… Поэтому, по-моему сугубо личному мнению, прежде чем писать ОС нужно написать компилятор языка программирования, который будет лучше С под современные задачи, при этом полностью транслирующийся в код ассемблера, и еще поддерживающий ассемблерные вставки(вспомните молодость и TurboC30, хотя я и не застал те времена, но предпочту работу с ним, чем с современной IDE по типу codeblocks)
Во-вторых, написание OC требует времени и денег, если ты, конечно, не работаешь на энтузиазме. Но уже довольно давно появился механизм «Pay what you want», который, возможно, сделает, в теории, твой энтузиазм поощряемым и будет стимулировать тебя на написание хорошего кода.(Но как известно это не очень распространенный метод, да и современный мир погряз в получении «выгоды», поэтому время и затраты на написание продукта стараются по максимуму сократить, что приводит к некачественному(небыстрому) коду)
В-третьих, насколько я понял эмпирическим путем, твоя ОС сможет «просуществовать» до новой ветки устаревающих технологий не более 20 лет, при умном проектрировании, поэтому ее разработка должна быть достаточно быстрой, что повлечет работу в огромной команде людей, что вновь приводит нас к предыдущим пунктам, но также создаст кучу ошибок совмещения, что, в свою очередь, будет влиять на доверие пользователей к ОС из-за проблем безопасности...(может этот пункт и не возникнет, если остановиться на системе уровня MS-Dos c небольшими дополнениями)
В-общем(еще я мог что-нибудь забыть, но это уже потом), я готов помочь, но мне важно выполнение первого пункта(над которым я работаю, но пока не хватает знаний в реализации компиляторов и потребностей современного рынка).
Я думаю, что небольшие страницы по прежнему будут писать на JS, но когда дело будет доходить до крупных сайтов с тысячами посетителей в день, там уже будет использоваться другие языки(хотя мне до сих пор не понятно, как они собираются взамодействовать с html). Это как сравнивать python и С… У каждого есть свои преимущества и недостатки…
Есть же даже теория о том, что чем проще(для написания сложных вещей) язык, тем проще на нем писать короткие программы, но при разрастании кода, простота играет злую шутку…
Во времена создания JavaScript и С системы были не слишком новороченными, поэтому создатели не подумали о том, что произойдет с их детищем в будущем.
Он не говорит, что for — это ошибка. Он утверждает, что for для JS перешел в разряд deprecated… Да и в С++, использование for является вынужденной мерой, т.к. конструкции for_each и (…: ...) появились в нем совсем недавно и не позваляют разгуляться в полной мере…
Почему не спасет? Я уверен, что в любых вычислениях мы заранее можем задать требуемую точность(никому ведь, кроме совсем неадекватных, не потребуется вычислить 1 млн или сразу бесконечность знаков числа pi), а если можно задать точность, то становятся применимы и стандартные алгоритмы нахождения корней, логарифмов и т.д. Единственное, что от этого пострадает — это скорость вычислений, но как говорится за все нужно платить…
Вообще, я впервые вижу, чтобы автор поднимал в своей статье те же проблемы, что появились в виде вопросов и у меня в голове пару месяцев назад. Правда жаль, что между нами более 20 лет разницы…
Нет тут вы не правы. Замена основания экспоненты с 2 на 10 действительно поможет исправить часть проблем связанных с операциями над вещественными числами, да и вывод их существенно упроститься… Но автор, к сожалению, не учел, что делать с такими обыкновенными дробями, как 1/3. Так что мне кажется, что будущее будет за типом fraction(дробь)
Так нет же, эмулятор должен гарантировать правильное исполнение, а не Сasm. А если компилировать под другую платформу, то получится и другой код…
По сути меня вполне устроят интринзики, если компилятор умеет их превращать в одну инструкцию на поддерживающих платформах и в несколько на не поддерживающих. Также я хочу знать где они хранятся.
Поэтому давайте закончим бессмысленную переписку… Оставьте пару ссылок на материалы по интринзикам для других интересующихся и придем к соглашению, что Casm их эквивалент в упрощенной форме…
Я их также изучу(код реализации) и посмотрю, какие у меня к ним появятся замечания
Вообще современный С++ в сравнении с ассемблером мне все больше напоминает недо-python(CPython) в сравнении с языком С. Да, безусловно, тебе не нужно волноваться о совместимости со всем, стандартная библиотека шаблонов предоставляет высокий уровень абстракции и т.д. Но везде нужен некий баланс, и программист сам должен решать, пожертвовать ли совместимостью с кофемолкой в угоду ускорению некоторой функции на несколько десятков процентов. А когда язык не предоставляет такой свободы выбора, это меня сильно печалит(и немного раздрожает).
Эмулятор на то и эмулятор… Он гарантирует правильное исполнение, но не гарантирует скорости. Об этих интструкциях, ксати, и писал человек в предложении к стандарту.
Я отталкивался от кода автора статьи и идеи для стандарта 21 года, которую также мне он прислал. Про интринзики не знал, и поэтому буду рад если вы назовете библиотеку(и) (желательно еще код реализации), где можно найти их.
Обратная совместимость — продукт нежелания миллионов программистов переписывать миллиарды строк кода(знаменитое Java-вское «написано однажды — работает всегда»). Каждому из нас не хочется этого делать… Но проблема тут не в программисте, а в языке, на котором написан код.
Язык С, как и все его компилируемые наследники(C++, Java, ..., но не Python, хотя там свои проблемы) в нынешние дни имеют ряд коренных недостатков, которые были не видны людям из далеких 70-x. Например, в С/C++ нельзя просто взять и написать ассемблерные вставки или функции. Это просто отсутствует в стандарте. И что прикажете с этим делать? А ведь даже такая малая стандартизируемая возможность в корне может ускорить выполнение кода…
www.youtube.com/watch?v=e_Pt9iJSOmY (1 часть)
www.youtube.com/watch?v=ezDDABD4lxk (2 часть)
Разве можно назвать сейчас этого бесповоротного монстра хорошей системой?
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C. То есть все современное ПО держится сейчас по сути на одном языке(даже Python в него транслируется). Но этот язык был написан 40 с лишком лет назад, и, следовательно, безбожно устарел под требования современных задач(ведь сейчас 3 идиом, включая кроссплатформенность уже не хватает; им параллелизм подавай)… Поэтому, по-моему сугубо личному мнению, прежде чем писать ОС нужно написать компилятор языка программирования, который будет лучше С под современные задачи, при этом полностью транслирующийся в код ассемблера, и еще поддерживающий ассемблерные вставки(вспомните молодость и TurboC30, хотя я и не застал те времена, но предпочту работу с ним, чем с современной IDE по типу codeblocks)
Во-вторых, написание OC требует времени и денег, если ты, конечно, не работаешь на энтузиазме. Но уже довольно давно появился механизм «Pay what you want», который, возможно, сделает, в теории, твой энтузиазм поощряемым и будет стимулировать тебя на написание хорошего кода.(Но как известно это не очень распространенный метод, да и современный мир погряз в получении «выгоды», поэтому время и затраты на написание продукта стараются по максимуму сократить, что приводит к некачественному(небыстрому) коду)
В-третьих, насколько я понял эмпирическим путем, твоя ОС сможет «просуществовать» до новой ветки устаревающих технологий не более 20 лет, при умном проектрировании, поэтому ее разработка должна быть достаточно быстрой, что повлечет работу в огромной команде людей, что вновь приводит нас к предыдущим пунктам, но также создаст кучу ошибок совмещения, что, в свою очередь, будет влиять на доверие пользователей к ОС из-за проблем безопасности...(может этот пункт и не возникнет, если остановиться на системе уровня MS-Dos c небольшими дополнениями)
В-общем(еще я мог что-нибудь забыть, но это уже потом), я готов помочь, но мне важно выполнение первого пункта(над которым я работаю, но пока не хватает знаний в реализации компиляторов и потребностей современного рынка).
Во времена создания JavaScript и С системы были не слишком новороченными, поэтому создатели не подумали о том, что произойдет с их детищем в будущем.
По сути меня вполне устроят интринзики, если компилятор умеет их превращать в одну инструкцию на поддерживающих платформах и в несколько на не поддерживающих. Также я хочу знать где они хранятся.
Поэтому давайте закончим бессмысленную переписку… Оставьте пару ссылок на материалы по интринзикам для других интересующихся и придем к соглашению, что Casm их эквивалент в упрощенной форме…
Я их также изучу(код реализации) и посмотрю, какие у меня к ним появятся замечания