Не играй в меня, C++ для Web уже есть.

Я правильно понял, что ты изобрёл… интерпретатор?

> Кто сказал, что компилируемые языки не подходят для Web?

И правда, кто?

Поподробней, пожалуйста.

А теперь посчитай, сколько программистов на С++ ты сможешь нанять за те деньги, на которые вкалывает целый отдел веб-кодеров.

А где ты видел в Веб _не_ компилируемые языки?

Где изъян в моей конгениальной идеи, которая может положить конец тормозам интерпретаторов?

Ты путаешь интерпретатор есть у кучи компилируемых языков. Если для тебя «компилируемый» значит «компилируемый в нативный код», то просто напиши компилятор похапе в натив.

> то просто напиши компилятор похапе в натив.

Zend вроде как предлагает что-то ънтерпрайзное из этой серии.

почему интерпретатор? Есть демон SCGI, который по сокету слушает соединение. Шаблонизатор CTPP - компилируемый, т.е., при запуске он один раз компилирует шаблон в [байт]код, благодаря чему чрезвычайно быстрый.

Его уже написали.

> Я правильно понял, что ты изобрёл… интерпретатор?

Скорее, простенький xml-парсер. Вёрстка на шаблонах - стандартная для веба практика. Чтобы дизайнеры не занимались кодом и наоборот.

> Поподробней, пожалуйста.

http://www.webtoolkit.eu

hiphop php compiler, например.

Таки да, в компилируемый в нативный.

компилятор похапе в натив.

Ну зачем? Зачем это непотребство улучшать? (кстати, компиляторы PHP давно есть. Один из них сделал Facebook).

Где я ошибаюсь?

CPU на фронтэндах наименее узкое место нагруженных проектов и самое масштабируемое. Такие дела.

Я лет 10-12 назад делал что-то похожее.
Приложение генерировало XML а UI делеся с помощью XSLT.
При этом если браузер поддерживал XSLT в полном объёме то рендеринг можно было отдавать клиенту а иначе всё рендерилось на сервере.

Бонусо было то, что можно было без изменения приложения сделат страницы для мобильников, что сейчас ещё более актуально.

Но трудоёмкость всё-же выше чем при использовании специализированных средств для вэба.

Не знаю как в пхп, а пейтон точно умеет вызывать сишные функции. Это для участков, где производительность ну очень критично. А С++ и Qt лучше бы выкинуть.

Есть Morfik в 3-х вариантах: FX (Pascal), BX (Basic), CX (C#).

ах да...

> Не играй в меня

Не понял юмора.

Не нужно. Т.к если скрипт генерит пользовательскую страничку, то тут всё упирается в пропускную способность канала, а не скорость работы скрипта. А там где надо гонять большие куски данных, никто и так ими не пользуется.

> Не понял юмора.

Да меня тут некоторые осуждают за то, что у меня бывают идеи, которые не соответствуют их мироустройству «всё украдено до нас». Не обращай внимания.

всё украдено до нас

«большая часть в этой области украдена до нас и не с твоей квалификацией сюда соваться»

fixed.

> А С++ и Qt лучше бы выкинуть.

Почему? Уж не из-за мифа ли, что Qt сильно толстое?

> Да меня тут некоторые осуждают за то, что у меня бывают идеи, которые не соответствуют их мироустройству «всё украдено до нас». Не обращай внимания.

Обычно осуждают за гениальные идеи, украденные и обкатанные десять лет как уже.

> fixed.

Точно. Ну, сути не меняет.

Уже сейчас можно написать http-демон, который будет сразу отдавать контент. Например, делаем GET /, на выходе получаем index.html и отдаем клиенту. Как сформировать index.html ? Да просто, пишем алгоритм выдерания данных прямо из БД (неважно какой, хоть с файла из ФС). Почему так никто не делает? Фиг знает, но сделать обертку под БД, чтобы редактировать данные html, имхо, не сложнее чем написать PHP. Хм.. будет время попробую реализивать каркас в libev/perl/postgres.

Брехня. На посещаемых ресурсах как раз уже загибаются интерпретаторы, которые генерируют контент, особенно, если последний почти без статики, прежде чем всё упрётся в канал.

>кто пробовал на C++ генерировать хотя бы HTML-отчёты - меня поймут что, за 20 лет никто не удосужился написать библиотеку для этого? что как бы намекает на применимость языка к данной задаче.

Честно говоря, я не до конца понял этот поток сознания...

> Почему? Уж не из-за мифа ли, что Qt сильно толстое?

А такой лихой замес плюсов и пейтона ничего не даст. Там всё равно общение на уровне вызова си-стайл функций.

Для этого и придумали шаблонизаторы.

Почему так никто не делает?

Хоть бы немного с матчастью ознакомился бы чтоле. Как будто кроме апача и энжинкса больше http серверов нет.

>Не знаю как в пхп, а пейтон точно умеет вызывать сишные функции. Это для участков, где производительность ну очень критично. А С++ и Qt лучше бы выкинуть.

Почти все известные интерпретаторы умеют работать с кодом на Asm/C/C++. Как просто это сделать google:/swig

> Есть Morfik в 3-х вариантах: FX (Pascal), BX (Basic), CX (C#).

Ты же сам понимаешь, что два варианта как минимум смешны, а второй - тогда уж лучше Яву.

Кому то в вебе не хватает скорости выполнения кода? Я думал проблема в масштабируемости архитектуры, оптимизации БД и кластеризации всего приложения.

А вот если действительно нужно считать например 2 часа что-то, то все это асинхронным сообщением инициируется на отдельной машине. Приложение может быть нативным.

>Хоть бы немного с матчастью ознакомился бы чтоле. Как будто кроме апача и энжинкса больше http серверов нет.

Подробнее, желательно опенсорс и на не на интерпретируемых языках :) Типа, запустил я демон, он берет контент из БД и сразу отдает клиенту. Без всяких обвесок вроде php/perl/asp/etc.

Если можно что-что сделать быстрее без особых усилий - то почему бы и не сделать этого?

Производительность непосредственно байткода — самое незначительная вещь на сервере. Использование памяти более заметно, но она настолько дешевая, что об этом можно не думать.
Самое важное — стабильность, легкая разработка, легкая отладка, качество кода.

А если так - то чем так удобные PHP/Python/Perl для чисто логической части приложения

Они управляемые.

> Они управляемые

В смысле?

А я и не думал, что кроме С в вебе что-то еще можно использовать...

google://embedded http server.

А потом начинаем оптимизировать, прикручиваем libevent, кэширование, пул потоков и получаем nginx с впаяной логикой.

Слишком толсто :3

Дело в том, что в этой самой БД данные например в 3 нормальной форме. Сущность нужно собрать. Это как раз делает бизнес логика. Если сущности упростить, то по идее можно их вывалить в канал как-то в чистом виде. Но я тебе гарантирую что будет нужна кастомизация в 99% случаев. Кастомизацию нужно как-то делать. Что и делается на каком-то ЯП. А поскольку это хорошее решение, которое всех устраивает, то все прекрасно. Такой как вы говорите демон не нужен

>Использование памяти более заметно, но она настолько дешевая, что об этом можно не думать.

Ага, apache и овер 2к fork'ов каждый по 5мб ~ 10Гб. И это только средней нагруженности, по нынешним меркам, сервак. Зачем думаешь всякие nginx придумали ? :)

Если можно что-что сделать быстрее без особых усилий

Могу поспорить, что на своей связке ты потратишь на порядок больше времени.

Особые усилия - это писать нативный код, его отлаживать. А в больших проектах просто получить неуправляемую непонятную текучую кучу кода

Ничего подобного. У меня абсолютно все CGI написаны на сях. И я, кстати, себе еще и библиотечку написал для аутентификации/авторизации и работы с файлами. Хотел еще туда добавить вебсокеты, но что-то влом - пока это не стандартизировано.

Managed в смысле. Не дадут внести трудноуловимые баги прямой работы с памятью, например.

Зачем думаешь всякие nginx придумали

Очевидно, чтобы снизить context switching.

> Почти все известные интерпретаторы умеют работать с кодом на Asm/C/C++. Как просто это сделать google:/swig

Да я и не спорю. Просто я в пхп не видел, вот и не стал утверждать.