Я думаю проблем не будет, может будет расширение этой идеи.
> (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces.
Использование namespaces по их принадлежности к расширениям (например DB::connect(), NET::send_data() и т.д.), свой код относится к пространству имен по названию приложения (хотя тут тоже могут возникнуть проблемы)
>нативную поддержку FastCGI и многопоточности
Если я буду укладываться в сроки, то попробую написать web сервер (по типу nginx) и объеденить интерпритатор и web сервер, тогда поддержка FastCGI будет не нужна. Объединение web сервера и интерпритатора в теории должно повысить скорость работы всей системы, и позволит управлять web сервером из скриптов (возможность допустим ограничения скорости, переключения режимов работы web сервера)
Я с вами полностью согласен PHP например в процессе развития нахватался много однотипных функций, что заставляет новичков писать ужасный код потому, что они не знают что лучше использовать в данной ситуации.
Использование кириллицы (или смешивания разных языков) для языка программирования мне кажется не очень удачной идеей, та как возникает много проблем использования языка програмирования в международных проектах.
>интерпретаторы пишутся на Асме(это конкрнетно увеличивает скорость обработки), остальное на Си.
Интерпритаторы как и компиляторы пишутся на чем угодно, даже на том языке который они интерпритируют(компилируют), просто в процесе происходит развертка и код превращается либо в машинные коды, либо в код на assembler.
Сейчас не приведу примеры и ссылки, но попытки объединения нескольких языков есть и есть рабочие демки! Только работает это очень криво, может реализация подводит, может еще что-то.
<Второй момент, я бы сделал это не вместо PHP и прочих языков, а как раз ВМЕСТЕ. То есть сделать модуль, который будет иметь свою функциональность и при этом будет продолжать работать в известном языке, легко расширяясь.
Насколько я знаю некоторые языки создавались как надстройки к существующим добовляя или расширяя возможности, но при этом тянули и недостатки базового языка от которых невозможно избавиться, PHP например позволяет писать хорошо структурированный код, либо все сваливать в кучу и то и то работает, а если не будет возможности валить все в кучу, то код придется писать не абы как а раскладывать все по полочкам.
Маштабируемость сейчас очень актуальный вопрос, почему бы не заложить эту возможность сразу, думаю неплохо было бы использовать на полную возможности многоядерных процессоров вместе с возможностями распределеной системы можно было бы тяжелые вычисления распределять по серверам.
Для работы со всем остальным пишутся стандартные расширения идущие в комплекте и динамически подгружаемые по мере надобности, наверное стоит в синтаксисе внести в начале файла подключение необходимых модулей.
PHP допустим не поддерживает паралельного выполнения (хоть и есть варианты обхода этого), PERL не очень хорош для WEB и т. д. Сразу конечно не возможно сделать язык который будет конкурировать на равных с тем же PHP, но главное скорость и удобство разработки и последующего сопровождения.
Спасибо за комментарий, есть идея объеденения web сервера и интерпритатора в один «флакон» с возможностью маштабирования на несколько серверов, добавления HTML как часть языка, строгая типизация возможность создания собственных типов на основе существующих, автоматическую перекодировку в UTF-8, оптимизация и кэширование байт-кода, выполнение паралельных вычислений (для увеличения скорости выполнения), все остальное (работа с БД, XML и т. д) вынести в расширения.
PHP, Perl, Pyton и т. д. тоже появились в результате того, что кому то не спалось! Да и не моя это прихоть, а задание такое, а вообще интересно попробовать.
Если проект сдам на отлично тогда имеет смысл развивать дальше, просто если изначально заложить в язык потенциал и грамотно спроектировать API, то проблем с развитием я думаю не возникнет.
Электронная версия должна идти в дополнение к бумажной, я некоторые сложные моменты читаю несколько раз чтобы разобраться полностью, а с монитора несколько раз перечитывать не очень хорошо!
На мой взгляд если вы хотите одни и те же данные отображать на разных устройствах и в разных браузерах, то тут лучше подойдет XSLT. Определяете возможности браузера и трансформируете данные нужным шаблоном!
Я думаю проблем не будет, может будет расширение этой идеи.
> (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces.
Использование namespaces по их принадлежности к расширениям (например DB::connect(), NET::send_data() и т.д.), свой код относится к пространству имен по названию приложения (хотя тут тоже могут возникнуть проблемы)
>нативную поддержку FastCGI и многопоточности
Если я буду укладываться в сроки, то попробую написать web сервер (по типу nginx) и объеденить интерпритатор и web сервер, тогда поддержка FastCGI будет не нужна. Объединение web сервера и интерпритатора в теории должно повысить скорость работы всей системы, и позволит управлять web сервером из скриптов (возможность допустим ограничения скорости, переключения режимов работы web сервера)
Использование кириллицы (или смешивания разных языков) для языка программирования мне кажется не очень удачной идеей, та как возникает много проблем использования языка програмирования в международных проектах.
Интерпритаторы как и компиляторы пишутся на чем угодно, даже на том языке который они интерпритируют(компилируют), просто в процесе происходит развертка и код превращается либо в машинные коды, либо в код на assembler.
Насколько я знаю некоторые языки создавались как надстройки к существующим добовляя или расширяя возможности, но при этом тянули и недостатки базового языка от которых невозможно избавиться, PHP например позволяет писать хорошо структурированный код, либо все сваливать в кучу и то и то работает, а если не будет возможности валить все в кучу, то код придется писать не абы как а раскладывать все по полочкам.
Для работы со всем остальным пишутся стандартные расширения идущие в комплекте и динамически подгружаемые по мере надобности, наверное стоит в синтаксисе внести в начале файла подключение необходимых модулей.
Для PHP number_favorite_news
Будем ждать выхода.