Комментарии 78
НЛО прилетело и опубликовало эту надпись здесь
Диплом у человека, вот и городит, добросовестно хочет написать.
НЛО прилетело и опубликовало эту надпись здесь
задания несколько разные. Кстати, вопрос к автору, на каком языке писать то будешь?
Все пишется на C/C++ под Unix.
НЛО прилетело и опубликовало эту надпись здесь
Не знаю почему, но ошибка в слове «проект » сильно раздражает.
>интерпретаторы пишутся на Асме(это конкрнетно увеличивает скорость обработки), остальное на Си.
Интерпритаторы как и компиляторы пишутся на чем угодно, даже на том языке который они интерпритируют(компилируют), просто в процесе происходит развертка и код превращается либо в машинные коды, либо в код на assembler.
Интерпритаторы как и компиляторы пишутся на чем угодно, даже на том языке который они интерпритируют(компилируют), просто в процесе происходит развертка и код превращается либо в машинные коды, либо в код на assembler.
Ну не скажите, пишется на чем угодно Мы на 3-ем курсе группой из 4-рех человек писали компилятор (разбор лексем, построение дерева разбора) паскаля на Delphi. Код компилировался в асм для процессоров i8080.
Гораздо сложнее придумать хороший синтаксис, в котором не было неоднозначностей и т.д., и который хорошо бы интерпритировался. Да, написание компиляторы для С++ — не тривиальное дело, к примеру один коммерческий компилятор проходит код два и более раз!
Гораздо сложнее придумать хороший синтаксис, в котором не было неоднозначностей и т.д., и который хорошо бы интерпритировался. Да, написание компиляторы для С++ — не тривиальное дело, к примеру один коммерческий компилятор проходит код два и более раз!
PHP, Perl, Pyton и т. д. тоже появились в результате того, что кому то не спалось! Да и не моя это прихоть, а задание такое, а вообще интересно попробовать.
Нифига себе вопрос :) Тут чтоб ответить нужно несколько дней писать надо.
Проект будет opensource? Будет ли дальнейшее развитие после сдачи диплома?
Как обычно надо ответить на следующие вопросы: какую проблему, которую нельзя решить на уровне библиотеки этот язык решает; почему это нельзя сделать на одном из следующих языков: PHP, Perl, Python, Ruby, Lua, Factor, Common Lisp, Scheme, Haskell, Io, Erlang, Ocaml, C, C++, Java, Groovy, Clojure, Scala, Arc, Oz, C#, F#, Nemerle, Qi; как он будет решать остальные проблемы, которые решают все перечисленные. Кстати классное задание: «написать абстрактный и никому не нужный язык» ;) мне кажется его как раз и стоит выполнять =)
Вы перечислили все языки, о которых слышали или ещё парочка в рукаве осталась? Ведь сказано же, что идея создать скриптовый, объектно-ориентированный язык. Более половины перечисленных Вами языков, не попадают в эти рамки.
Насчёт проблем, которые можно будет решать, используя этот язык. Вот совсем не обязательно предложить решать какие-то новые проблемы — достаточно сделать что-то лучше (удобнее для разработчика/скорость выполнения скрипта) и он уже может стать востребованным.
Ну а насчёт советов — лично мне нравится С-подобный синтаксис. Но тут конкурировать придётся с JavaScript-ом (если Вам это под силу, то вперёд!). На самом деле, в скриптовых языках главное — читабельность кода, быстрый интерпретатор, возможность широкого применения (примеры: JavaScript, VBScript, Perl). Вообще, пожалуй, в таком деле важно, чтобы у Вас была идея, от которой можно было бы отталкиваться и написать язык, а не задача написать язык, а потом попытки найти идею.
Насчёт проблем, которые можно будет решать, используя этот язык. Вот совсем не обязательно предложить решать какие-то новые проблемы — достаточно сделать что-то лучше (удобнее для разработчика/скорость выполнения скрипта) и он уже может стать востребованным.
Ну а насчёт советов — лично мне нравится С-подобный синтаксис. Но тут конкурировать придётся с JavaScript-ом (если Вам это под силу, то вперёд!). На самом деле, в скриптовых языках главное — читабельность кода, быстрый интерпретатор, возможность широкого применения (примеры: JavaScript, VBScript, Perl). Вообще, пожалуй, в таком деле важно, чтобы у Вас была идея, от которой можно было бы отталкиваться и написать язык, а не задача написать язык, а потом попытки найти идею.
Да пара осталась ;) Объекность и скриптовость понятия растяжимые. А вот решать проблемы все-таки обязательно. Не обязательно новые — можно старые. Скорость — это ответ на вопрос чем новый язык лучше, но не ответ чем он лучше другой реализации существующего, удобство тоже ответ, хотя не очень понятно как его определять. Если удобство — это возможность короче и понятнее записывать какие-то штуки, то значит проблема — это как делать эти штуки короче и понятнее чем у других и при этом не превратить в кашу все остальное.
Как ни растягивай, но C++ никак не скриптовый язык, а С не объектно-ориентированный. Всё же скриптовость (интерпретируемость) и ООП — достаточно(!) чёткие понятия. Решать проблемы обязательно — с этим спорить глупо, но я и не собирался. Скорость — не ответ, да и скорее всего не вопрос (сильно сомневаюсь, что автор сможет создать конкурента по этому параметру хотя бы тому же JavaScript). Удобство — вот как раз это понятие растяжимое. Я никогда, наверное, не смогу понять, почему считаю синтаксис Pascal-а приятным, а синтаксис VB (VB.NET/VBScript — не важно) — ужасным.
Понятия может и четкие, но надо сначала придумать зачем нам скриптовость и зачем ООП. Интерпретируемость — это ведь не фича языка, а особенность реализации. ООП — тоже в разных языках сильно различается и если придумывать новый, то надо сначала придумать зачем оно нужно и в каком именно виде оно будет.
Плюсы интерпретируемости:
1. Интерпретируемость помогает переносимости — для портирования достаточно реализовать интерпретатор для нужной системы.
2. Интерпретатор писать проще, чем компилятор.
3. Легче ограничить возможности программ (иногда нечего лишний раз процессы запускать) и уменьшить разрушительные последствия разного рода ошибок.
4. Ну, и главное преимущество:
1. Интерпретируемость помогает переносимости — для портирования достаточно реализовать интерпретатор для нужной системы.
2. Интерпретатор писать проще, чем компилятор.
3. Легче ограничить возможности программ (иногда нечего лишний раз процессы запускать) и уменьшить разрушительные последствия разного рода ошибок.
4. Ну, и главное преимущество:
Ладно, я согласен, интеретируемость — это не особенность реализации, а фича языка.
Ну, я такого не говорил :) В теории, любой язык можно как интерпретировать, так и компилировать, или и то и другое. Но, конечно, в суровой действительности языки не висят в воздухе — без платформы язык никому не нужен, а плодить платформы тоже мало толку. Вот и прирастают к языку такие свойства, как компилируемость или интерпретируемость.
надо сначала придумать зачем нам скриптовость и зачем ООП
По условиям дипломного проекта.
Внимательнее к посту надо быть. :)
По условиям дипломного проекта.
Внимательнее к посту надо быть. :)
По-моему, эта тема на кандидатскую диссертацию тянет.
Относительно простые трансляторы студенты за один-два семестра пишут на лабах. А уж на диплом наваять веб-язык вполне себе задание.
Хочется не просто наваять за неделю и забыть, а самому использовать в реальных проектах и не проклинать потом себя за создание этого чуда :-)
Мне кажется для возможности использования надо встраиваться в какие-то существующие платформы типа Java как это делают Scala, Groovy, Clojure или делать с помощью этого языка такие штуки, что бы платформа была не нужна — типа какого-нибудь хитрого DSL для описания данных, шаблонов html или чего-то такого.
Посмотрите Jetbrains MPS.
У вас не получится сделать что-либо более хорошего чем существующие решения, такие как php, perl и др.
Но если вы хотите сделать что-то действительно новое и интересное, порекомендую создать скриптовый язык, целиком основанный на АОП.
См. ru.wikipedia.org/wiki/Аспектно-ориентированное_программирование
Но если вы хотите сделать что-то действительно новое и интересное, порекомендую создать скриптовый язык, целиком основанный на АОП.
См. ru.wikipedia.org/wiki/Аспектно-ориентированное_программирование
Самая важная вещь в языке программирования — его имя. Язык не будет иметь успеха без хорошего имени. Я недавно придумал очень хорошее имя, теперь осталось изобрести подходящий язык. (Д. Кнут)
А если чуть-чуть серьезнее, то обратите внимания на проблемы существующих решений. Например: руби допускает такое свинство, как вызов приватных функций путем нехитрого хака; пхп провоцирует смешивать логику и представление, питон… ну, у него тоже есть недостатки :)
Раз уж хотите объектно-ориентированный язык, то делайте его полностью объектно-ориентированным, получится интереснее. Почитайте про io, на хабре была пара статей.
Подумайте, как вы собираетесь реализовать расхожие шаблоны проектирования, нужен ли вам, к примеру, MVC.
Неплохо бы, чтобы удобно было взаимодействовать с БД.
О синтаксисе: в питоне блоки определяются отступами. Это круто, можно смело тырить.
Подумайте о стандартных типах. Нужны ли типы «время», «деньги»? Наверное, да. А может тип «пользователь» или «изображение»? Раз уж язык для веба, может имеет смысл сущности HTML сделать стандартными типами?
Поддержка разных кодировок. Ограничиться UTF-8 или обеспечить поддержку строк в любых кодировках?
В общем, вопросов больше, чем предложений. Чтобы отсечь несущественное, попробуйте сформулировать назначение языка, очертить круг задач (программирование для веб — слишком широко, не успеете до сессии). Даже если он будет годиться только для дейтингов, но будет выполнять свою функцию хорошо, у него есть будущее. Не нужно пытаться отлить серебряную пулю, а то в объем курсовой не влезете и не успеете :)
Ну и, как заметили выше, опенсорс вам в помощь. Если хорошо продумаете и не забросите, единомышленники подтянутся.
А если чуть-чуть серьезнее, то обратите внимания на проблемы существующих решений. Например: руби допускает такое свинство, как вызов приватных функций путем нехитрого хака; пхп провоцирует смешивать логику и представление, питон… ну, у него тоже есть недостатки :)
Раз уж хотите объектно-ориентированный язык, то делайте его полностью объектно-ориентированным, получится интереснее. Почитайте про io, на хабре была пара статей.
Подумайте, как вы собираетесь реализовать расхожие шаблоны проектирования, нужен ли вам, к примеру, MVC.
Неплохо бы, чтобы удобно было взаимодействовать с БД.
О синтаксисе: в питоне блоки определяются отступами. Это круто, можно смело тырить.
Подумайте о стандартных типах. Нужны ли типы «время», «деньги»? Наверное, да. А может тип «пользователь» или «изображение»? Раз уж язык для веба, может имеет смысл сущности HTML сделать стандартными типами?
Поддержка разных кодировок. Ограничиться UTF-8 или обеспечить поддержку строк в любых кодировках?
В общем, вопросов больше, чем предложений. Чтобы отсечь несущественное, попробуйте сформулировать назначение языка, очертить круг задач (программирование для веб — слишком широко, не успеете до сессии). Даже если он будет годиться только для дейтингов, но будет выполнять свою функцию хорошо, у него есть будущее. Не нужно пытаться отлить серебряную пулю, а то в объем курсовой не влезете и не успеете :)
Ну и, как заметили выше, опенсорс вам в помощь. Если хорошо продумаете и не забросите, единомышленники подтянутся.
Чорт, извините, назвал диплом курсовиком.
Спасибо за комментарий, есть идея объеденения web сервера и интерпритатора в один «флакон» с возможностью маштабирования на несколько серверов, добавления HTML как часть языка, строгая типизация возможность создания собственных типов на основе существующих, автоматическую перекодировку в UTF-8, оптимизация и кэширование байт-кода, выполнение паралельных вычислений (для увеличения скорости выполнения), все остальное (работа с БД, XML и т. д) вынести в расширения.
> есть идея объеденения web сервера и интерпритатора в один «флакон» с возможностью маштабирования на несколько серверов
Для начала, наверное, можно реализовать в виде модуля для апача или нгинкса — а может, так и оставить. Ведь реализация сервера отберет много сил и затруднит перенос на другие платформы. Но предусмотреть масштабируемость сразу в языке — это круто.
> выполнение паралельных вычислений (для увеличения скорости выполнения)
Тоже здорово. Может это удастся совместить с масштабируемостью? Например, параллелить интерпретатор на процессы, общающиеся по TCP/IP. Или, более глобально (т. е. если время будет позволять), обратить взоры к грид-системам: там немало знаний накопилии и шишек набили, а осязаемое применение лично я видел только в IncrediBuild.
А на скорости выполнения не нужно зацикливаться. Через год процессоры станут ядренее и ядернее, а еще через год… Для начала скорость должна быть просто приемлимой, то есть без несуразных тормозов.
> (работа с БД, XML и т. д) вынести в расширения
Гм. Все-таки без БД далеко не уедешь, неплохо бы предусмотреть стандартный слой абстракции для работы с БД, хотя бы какие-нибудь data objects, чтобы с записями в базе работать как с объектами. Это — точно окупится.
Для начала, наверное, можно реализовать в виде модуля для апача или нгинкса — а может, так и оставить. Ведь реализация сервера отберет много сил и затруднит перенос на другие платформы. Но предусмотреть масштабируемость сразу в языке — это круто.
> выполнение паралельных вычислений (для увеличения скорости выполнения)
Тоже здорово. Может это удастся совместить с масштабируемостью? Например, параллелить интерпретатор на процессы, общающиеся по TCP/IP. Или, более глобально (т. е. если время будет позволять), обратить взоры к грид-системам: там немало знаний накопилии и шишек набили, а осязаемое применение лично я видел только в IncrediBuild.
А на скорости выполнения не нужно зацикливаться. Через год процессоры станут ядренее и ядернее, а еще через год… Для начала скорость должна быть просто приемлимой, то есть без несуразных тормозов.
> (работа с БД, XML и т. д) вынести в расширения
Гм. Все-таки без БД далеко не уедешь, неплохо бы предусмотреть стандартный слой абстракции для работы с БД, хотя бы какие-нибудь data objects, чтобы с записями в базе работать как с объектами. Это — точно окупится.
Маштабируемость сейчас очень актуальный вопрос, почему бы не заложить эту возможность сразу, думаю неплохо было бы использовать на полную возможности многоядерных процессоров вместе с возможностями распределеной системы можно было бы тяжелые вычисления распределять по серверам.
Для работы со всем остальным пишутся стандартные расширения идущие в комплекте и динамически подгружаемые по мере надобности, наверное стоит в синтаксисе внести в начале файла подключение необходимых модулей.
Для работы со всем остальным пишутся стандартные расширения идущие в комплекте и динамически подгружаемые по мере надобности, наверное стоит в синтаксисе внести в начале файла подключение необходимых модулей.
Кстати, надо не забыть отрастить бороду — это самое главное!
Сделайте макро-язык вроде лиспа, или на основе лиспа с похожим синтаксисом. Чтобы под каждый конкретный проект можно было написать свой диалект на основе вашего языка. Я думаю, это было бы круто.
НЛО прилетело и опубликовало эту надпись здесь
Имхо, в первую очередь стоило описать, что вы сами по этому поводу думаете, а потом спрашивать комментариев и дополнений.
может вам связку d+parser проталкнуть?
Мне кажется надо посмотреть на несколько известных/общеипринятых фреймворков и понять почему люди предпочитают их чистому PHP например. Очевидно, что ответ будет — они упрощают реализацию стандартных возможностей.
И вполне хорошим решением может быть создание продукта, который уже имеет наиболее востребованные в вэбе возможности. При этом скорость работы будет выше, так как это уже будет скомпилировано.
Второй момент, я бы сделал это не вместо PHP и прочих языков, а как раз ВМЕСТЕ. То есть сделать модуль, который будет иметь свою функциональность и при этом будет продолжать работать в известном языке, легко расширяясь.
Заодно не надо было бы уговаривать людей менять язык и все свои продукты переписывать заново, а просто они бы переложили какую-то часть на этот модуль.
По моему за таким решением вполне хорошее коммерческое будущее в том числе :-)
Ну а заодно и времени больше будет на написание супер-интересных решений типа работы с ДБ, кэширования, разделение логики и представления, шаблонизатор, хорошая поддержка кодировок, параллельные вычисления, масштабируемость и т. д. и т. п.
И вполне хорошим решением может быть создание продукта, который уже имеет наиболее востребованные в вэбе возможности. При этом скорость работы будет выше, так как это уже будет скомпилировано.
Второй момент, я бы сделал это не вместо PHP и прочих языков, а как раз ВМЕСТЕ. То есть сделать модуль, который будет иметь свою функциональность и при этом будет продолжать работать в известном языке, легко расширяясь.
Заодно не надо было бы уговаривать людей менять язык и все свои продукты переписывать заново, а просто они бы переложили какую-то часть на этот модуль.
По моему за таким решением вполне хорошее коммерческое будущее в том числе :-)
Ну а заодно и времени больше будет на написание супер-интересных решений типа работы с ДБ, кэширования, разделение логики и представления, шаблонизатор, хорошая поддержка кодировок, параллельные вычисления, масштабируемость и т. д. и т. п.
Тут разброс вообще огромный на самом деле, как и будущее.
Даже вопросы кропа и ресайза загружаемых изображений постоянно приходится решать.
Загрузка файлов, с последующими проверками размеров, типов, переноса, удаления временных…
Работа с юзером (его данными и статусами). Тоже постоянно приходится данные куда-то складывать, проверять авторизацию и т. д.
Даже вопросы кропа и ресайза загружаемых изображений постоянно приходится решать.
Загрузка файлов, с последующими проверками размеров, типов, переноса, удаления временных…
Работа с юзером (его данными и статусами). Тоже постоянно приходится данные куда-то складывать, проверять авторизацию и т. д.
<Второй момент, я бы сделал это не вместо PHP и прочих языков, а как раз ВМЕСТЕ. То есть сделать модуль, который будет иметь свою функциональность и при этом будет продолжать работать в известном языке, легко расширяясь.
Насколько я знаю некоторые языки создавались как надстройки к существующим добовляя или расширяя возможности, но при этом тянули и недостатки базового языка от которых невозможно избавиться, PHP например позволяет писать хорошо структурированный код, либо все сваливать в кучу и то и то работает, а если не будет возможности валить все в кучу, то код придется писать не абы как а раскладывать все по полочкам.
Насколько я знаю некоторые языки создавались как надстройки к существующим добовляя или расширяя возможности, но при этом тянули и недостатки базового языка от которых невозможно избавиться, PHP например позволяет писать хорошо структурированный код, либо все сваливать в кучу и то и то работает, а если не будет возможности валить все в кучу, то код придется писать не абы как а раскладывать все по полочкам.
Разумеется, я не собираюсь нападать на вашу идею. Если вы нацелены на свой язык, то определенно его нужно делать. Просто я задачу старался рассмотреть скорее в вашем контексте, что нужно сделать что-то как дипломную работу и заодно реально работающее.
И я предположил, что если вы совместите задачу с той, которая уже есть у людей, то вы сразу получите аудиторию и практические результаты (в том числе в рамках диплома можно будет похвастаться, что есть реализованные проекты и разработчики довольны). А потом посмотрев на результаты действительно можно уже сделать свой язык, но уже будет мостик для аудитории :-)
Это я с позиции и разработчика и заказчика. «Нехороший» язык с известными недостатками и наработками всегда лучше, чем гениальный с неизвестными. Вы должны представлять сколько усилий нужно, чтобы это все действительно пошло в реальную работу, а не тренировку.
И я предположил, что если вы совместите задачу с той, которая уже есть у людей, то вы сразу получите аудиторию и практические результаты (в том числе в рамках диплома можно будет похвастаться, что есть реализованные проекты и разработчики довольны). А потом посмотрев на результаты действительно можно уже сделать свой язык, но уже будет мостик для аудитории :-)
Это я с позиции и разработчика и заказчика. «Нехороший» язык с известными недостатками и наработками всегда лучше, чем гениальный с неизвестными. Вы должны представлять сколько усилий нужно, чтобы это все действительно пошло в реальную работу, а не тренировку.
Язык изначально задумывается расширяемым, поэтому можно дополнять и расширять постепенно. Сначала определить минимальную базу и написать рабочую версию, а потом по мере необходимости дополнять.
> Вы должны представлять сколько усилий нужно, чтобы это все действительно пошло в реальную работу, а не тренировку.
А не кто не говорит, что сразу все прибегут и начнут пользоваться, сначала проходит долгое тестирование, определение чего не хватает, а что лишнее и уже потом это можно будет предлагать для реальных проектов.
> Вы должны представлять сколько усилий нужно, чтобы это все действительно пошло в реальную работу, а не тренировку.
А не кто не говорит, что сразу все прибегут и начнут пользоваться, сначала проходит долгое тестирование, определение чего не хватает, а что лишнее и уже потом это можно будет предлагать для реальных проектов.
Мне не хватает TCL под dotnet/mono платформу и интеграции xotcl-объектов CRL-объектами.
Полезной будет интеграция в язык ORM (а-ля LINQ в .NET). Ну и соот-но надо продумать, как можно запросы на внутреннем языке мапить на различные СУБД без лишних проблем. Потому что SQL запросы в виде строк — не айс.
Возможно идея бредовая, сильно не бейте.
Мне кажется, что было бы здорово, если бы был язык, который понимал бы все предыдущие.
Но не начинайте говорить, что это не возможно.
Как сказал мой хороший друг в виртуальном мире нет границ,
есть только ограничения в нашем сознании и времени.
Мне кажется, что было бы здорово, если бы был язык, который понимал бы все предыдущие.
Но не начинайте говорить, что это не возможно.
Как сказал мой хороший друг в виртуальном мире нет границ,
есть только ограничения в нашем сознании и времени.
Сейчас не приведу примеры и ссылки, но попытки объединения нескольких языков есть и есть рабочие демки! Только работает это очень криво, может реализация подводит, может еще что-то.
я сам не очень программист, но с интересом наблюдал бы за развитием твоего проекта. приятно видеть, что сегодня есть еще кто-то, кто делает дипломный проект не только для того чтобы его защитить и забыть. в свое время пострадал за это дело :) пытался сделать редактор для сборки и расчета механизмов. грубо говоря не осилил.
насчет языка, тут уже писали о том, что интересна была бы поддержка уже стандартных и привычных элементов присутствующих на сайте на уровне базовых типов или классов. это может оптимизировать взаимодействие с некоторыми объектами: зарегистрированными пользователями и их параметрами. опять же взаимодействие с БД, с графикой.
насчет языка, тут уже писали о том, что интересна была бы поддержка уже стандартных и привычных элементов присутствующих на сайте на уровне базовых типов или классов. это может оптимизировать взаимодействие с некоторыми объектами: зарегистрированными пользователями и их параметрами. опять же взаимодействие с БД, с графикой.
groovy+grails?
Знаю многие это сочтут бредом, но напомню речь идет о свойствах в языке, которые хотелось бы увидеть конкретно мне.
Мне больше всего не нравится в существующих «веб-ориентированых» языках, заложеная в них избыточность. Нет сторого «идейно-ориентированых». Как пример, в PHP куча функций дублирующих назначение друг друга, причем эфективность реализаций каждой из них разная (что у непрофессионала приводит к каше в коде, а профессионал пользуется одним наиболее практично реализованым вариантом). Что обуславливается развитием языка шаблонов до стадии языка праграммирования и вследствии усложнившимся настольлко, что на нем уже пишутся языки шаблонов (Смарти шаблонизатор для ПХП, на заре развития бывшего шаблонизатором для Перла). Короче чтоб ни одной лишней каллории.
Хотелось бы как говорили выше, ориентированых именно на веб разработку типов данных (ознакомтесь какую гибкость в Луа дает наличие типа Таблица, косательно веба не помешал бы тип изображение)
В свое время очень позабавило, когда узнал что в 1C написание команд на русском языке. С тех пор болею идеей об интернационализации языка и вообще настраивоимости операторов. Тоесть к примеру есть интерпритатор, есть конфиг в котором каждой последовательности действий которые должен выполнить интерпритатор задается некая последовательность символов (причем любой языковой принадлежности). А скрипт самой программы на пример файла XML, либо с «доктайпом» либо с самим конфигом в хедере.
Советую присмотреться к ColdFusion. Вплане создания синтаксиса языка на основе XML (посредством XML описывать объекты и их взаимодействие, а на основе синтаксиса подобного CSS описывать методы и константы). На примере того же ColdFusion такой подход обладает большой перспективностью в вебе, как минимум в среде верстальщиков и дизайнеров, так как добавляет к HTML и SVG недостающую составляющую на стороне сервера. + распространенность повсеместная распространенность платформы XML и множество готовых и провереных временем парсеров. Что в рамках ограниченого времени делает идею еще более заманчивой.
Как-то так…
Мне больше всего не нравится в существующих «веб-ориентированых» языках, заложеная в них избыточность. Нет сторого «идейно-ориентированых». Как пример, в PHP куча функций дублирующих назначение друг друга, причем эфективность реализаций каждой из них разная (что у непрофессионала приводит к каше в коде, а профессионал пользуется одним наиболее практично реализованым вариантом). Что обуславливается развитием языка шаблонов до стадии языка праграммирования и вследствии усложнившимся настольлко, что на нем уже пишутся языки шаблонов (Смарти шаблонизатор для ПХП, на заре развития бывшего шаблонизатором для Перла). Короче чтоб ни одной лишней каллории.
Хотелось бы как говорили выше, ориентированых именно на веб разработку типов данных (ознакомтесь какую гибкость в Луа дает наличие типа Таблица, косательно веба не помешал бы тип изображение)
В свое время очень позабавило, когда узнал что в 1C написание команд на русском языке. С тех пор болею идеей об интернационализации языка и вообще настраивоимости операторов. Тоесть к примеру есть интерпритатор, есть конфиг в котором каждой последовательности действий которые должен выполнить интерпритатор задается некая последовательность символов (причем любой языковой принадлежности). А скрипт самой программы на пример файла XML, либо с «доктайпом» либо с самим конфигом в хедере.
Советую присмотреться к ColdFusion. Вплане создания синтаксиса языка на основе XML (посредством XML описывать объекты и их взаимодействие, а на основе синтаксиса подобного CSS описывать методы и константы). На примере того же ColdFusion такой подход обладает большой перспективностью в вебе, как минимум в среде верстальщиков и дизайнеров, так как добавляет к HTML и SVG недостающую составляющую на стороне сервера. + распространенность повсеместная распространенность платформы XML и множество готовых и провереных временем парсеров. Что в рамках ограниченого времени делает идею еще более заманчивой.
Как-то так…
Я с вами полностью согласен PHP например в процессе развития нахватался много однотипных функций, что заставляет новичков писать ужасный код потому, что они не знают что лучше использовать в данной ситуации.
Использование кириллицы (или смешивания разных языков) для языка программирования мне кажется не очень удачной идеей, та как возникает много проблем использования языка програмирования в международных проектах.
Использование кириллицы (или смешивания разных языков) для языка программирования мне кажется не очень удачной идеей, та как возникает много проблем использования языка програмирования в международных проектах.
Если это скриптовый язык для WEB, хотелось бы видеть:
1. нативную поддержку архитектуры MVC
2. (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces. Так порядка больше
3. нативную поддержку FastCGI и многопоточности
Понимаю, что в дипломном проекте все это нереализуемо. Более того, у вас просто не будет времени, чтобы как следует разобраться во всем. Но вы можете в своем дипломном проекте реализовать прочный фундамент, на котором вырастет «взрослый» скриптовый язык для веба.
1. нативную поддержку архитектуры MVC
2. (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces. Так порядка больше
3. нативную поддержку FastCGI и многопоточности
Понимаю, что в дипломном проекте все это нереализуемо. Более того, у вас просто не будет времени, чтобы как следует разобраться во всем. Но вы можете в своем дипломном проекте реализовать прочный фундамент, на котором вырастет «взрослый» скриптовый язык для веба.
>нативную поддержку архитектуры MVC
Я думаю проблем не будет, может будет расширение этой идеи.
> (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces.
Использование namespaces по их принадлежности к расширениям (например DB::connect(), NET::send_data() и т.д.), свой код относится к пространству имен по названию приложения (хотя тут тоже могут возникнуть проблемы)
>нативную поддержку FastCGI и многопоточности
Если я буду укладываться в сроки, то попробую написать web сервер (по типу nginx) и объеденить интерпритатор и web сервер, тогда поддержка FastCGI будет не нужна. Объединение web сервера и интерпритатора в теории должно повысить скорость работы всей системы, и позволит управлять web сервером из скриптов (возможность допустим ограничения скорости, переключения режимов работы web сервера)
Я думаю проблем не будет, может будет расширение этой идеи.
> (как уже было описано) любая функция — метод какого-то класса. Выделение namespaces.
Использование namespaces по их принадлежности к расширениям (например DB::connect(), NET::send_data() и т.д.), свой код относится к пространству имен по названию приложения (хотя тут тоже могут возникнуть проблемы)
>нативную поддержку FastCGI и многопоточности
Если я буду укладываться в сроки, то попробую написать web сервер (по типу nginx) и объеденить интерпритатор и web сервер, тогда поддержка FastCGI будет не нужна. Объединение web сервера и интерпритатора в теории должно повысить скорость работы всей системы, и позволит управлять web сервером из скриптов (возможность допустим ограничения скорости, переключения режимов работы web сервера)
Последнее совсем ни к чему. Веб-серверы — это отдельная (не спорю, увлекательная, но отдельная) огромная тема для исследования. Не распыляйтесь. Начните с языка, реализуйте минимум функционала и посмотрите, что получится.
А по поводу MVC — этот момент нужно очень хорошо продумать. Сама концепция вопросов не вызывает, а вот реализация…
А по поводу MVC — этот момент нужно очень хорошо продумать. Сама концепция вопросов не вызывает, а вот реализация…
Насчет объединения web сервера и интерпритатора у меня просто есть несколько перспективных задумок (есть опыт написания «небольших» web серверов), поэтому я и склоняюсь к этой модели, но в первую очередь дело конечно за интерпритатором.
Насчет MVC, то тут еще надо подумать, можно реализовать как абстрактные классы и потом наследовать и расширять до нужной функцианальности, допустим Model через расширение DB тянет данные, View работает через расширением HTML и генерит вывод HTML, а Controller работает через расширением к примеру USER и занимается обработкой запросов от пользователя и связывает Model и View.
Насчет MVC, то тут еще надо подумать, можно реализовать как абстрактные классы и потом наследовать и расширять до нужной функцианальности, допустим Model через расширение DB тянет данные, View работает через расширением HTML и генерит вывод HTML, а Controller работает через расширением к примеру USER и занимается обработкой запросов от пользователя и связывает Model и View.
Если вы controller упрячете вглубь языка, то сразу все станет просто и понятно. Останутся шаблоны и бизнес-логика. В шаблонах вы разрешите только использование данных, прокинутых через общие для конкретных модели и представления переменные, а также циклы и вызовы элементарных команд вроде конкатенации строк или вычисления хеша MD5.
В этом плане идею разделения можно решить на уровне интерфейсов. Т.е. сделать все примерно как в Java — объявить интерфейс Viewable и разрешать в шаблонах только те функции, namespace которых родственен интерфейсу. Т.е. например System:Hash сделать Viewable, чтобы прямо в шаблонах можно было вычислять хэши, а вот DB — никогда, никому и низачто не отдавать в отображение.
В этом плане идею разделения можно решить на уровне интерфейсов. Т.е. сделать все примерно как в Java — объявить интерфейс Viewable и разрешать в шаблонах только те функции, namespace которых родственен интерфейсу. Т.е. например System:Hash сделать Viewable, чтобы прямо в шаблонах можно было вычислять хэши, а вот DB — никогда, никому и низачто не отдавать в отображение.
Знаете, такой способ проектирования языка не будет успешным. Мы делаем языка не для WEB, а для системного программирования. И способ опростить заинтересованных ни к чему не привёл. Люди хотят совершенно разного, и при этом не всегда логичного, эффективного и удобного. А ещё чаще вам будут отвечать примерно следующее: так вот есть же C++, сделайте его.
Поэтому, не растрачивайте зря время на распросы. Сами придумайте язык, отточите его на моделях, на попытках переписать на нём уже написанные на другом языке работающие коды. Помедетируйте маленько. Выдайте готовое решение, а потом спрашивайте о его недостатках. Дело пойдёт гораздо быстрее и эффективнее. А потом те, кто говорил вам о существующем уже C++/Python, будут смотреть на код и говорить: 'вау, разве так можно делать? Это нереально круто'. Ну. А для вдохновения смотрите на изотерические языки: Oz, Haskell, Io, etc…
Поэтому, не растрачивайте зря время на распросы. Сами придумайте язык, отточите его на моделях, на попытках переписать на нём уже написанные на другом языке работающие коды. Помедетируйте маленько. Выдайте готовое решение, а потом спрашивайте о его недостатках. Дело пойдёт гораздо быстрее и эффективнее. А потом те, кто говорил вам о существующем уже C++/Python, будут смотреть на код и говорить: 'вау, разве так можно делать? Это нереально круто'. Ну. А для вдохновения смотрите на изотерические языки: Oz, Haskell, Io, etc…
Я ожидал комментариев типа «есть же PHP или Perl зачем изобретать велосипед» они неизбежны, поэтому я не обращаю на них особого внимания. Я надеюсь на то, что всегда найдутся адекватные люди и поделятся своими идеями на заданную тему.
Если бы люди не изобретали очередной велосипед, мы бы до сих пор жили бы в каменном веке.
Если бы люди не изобретали очередной велосипед, мы бы до сих пор жили бы в каменном веке.
>Мы делаем языка не для WEB, а для системного программирования.
Хотелось бы поподробней о процессе разработки.
Хотелось бы поподробней о процессе разработки.
Есть реальные идеи для такого языка (касающиеся дизайна языка, концепции, удобства программирования), правда, почти ничего не оформлено в виде понятного текста. Приглашаю вас к переписке по e-mail, где я вам об этом расскажу. В процессе, можно было бы сделать сайт о «идеальном» языке программирования для веба.
Попробуй придумать сервисно-ориентированный язык :)
Удаленные переменные и массивы, хранение деревьев и списков на уровне распределенной бд, также и создание типов на уровне создания таблиц в бд. При этом разработчик использует обычный синтаксис, а выполняются такие программы на уровне веб сервисов, rest запросами.
:)
Удаленные переменные и массивы, хранение деревьев и списков на уровне распределенной бд, также и создание типов на уровне создания таблиц в бд. При этом разработчик использует обычный синтаксис, а выполняются такие программы на уровне веб сервисов, rest запросами.
:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальный скриптовый язык для WEB.