Я не знал, извиняюсь. Я думал это уже официально текущая версия.  


Во-первых, топикстартер не делал акцент на веб.
Во-вторых, есть не малое число не "хомпагов" powered by RoR. И ничего, работают.


Тормоз!   Но и Python то не особо впереди.


Я и не говорю, что не помогает...

Это сообщение отредактировал(а) kemiisto - 28.12.2008, 19:28

 В десяток раз - это не особо впереди?)

 На скольки серверах?))

интересно, куда пропал топикстартер?

Добавлено через 18 секунд
и какие выводы он сделал?  

По паре синтетических тестов разве что, на деле максимум на 30%, да и то если звёзды сложатся наилучшим для Питона способом...

Hiden features of python

да, т. к умножение - это многократное сложение


ассемблер тоже синтаксический сахар

любой более высокий уровень является синтаксическим сахаром для более низкого

MAKCim, не любой. тот же питон - это далеко не сахар к паскалю, а нечто, совсем с ним не связанное.

и мешает  

Добавлено через 7 минут и 59 секунд

PVM на чем написана?   
можно ли ее на Pascal'е написать? можно

 А компилятор паскаля на питоне? Да тоже можно.
Следовательно паскаль - сахар к питону.

А компилятоор асма на пхп? Можно
Выходит, что асм - сахар для пхп?)

nerezus, 
неправильная логика
для того, чтобы написать компилятор паскаля на питоне, нужно сначала написать интерпретатор питона на паскале

Позиция «всё — синтаксический сахар к ассемблеру» заведомо неконструктивна, хотя и практически неопровержима за неимением сколько-нибудь строгого определения синтаксического сахара.
Абстрактные языки — сахар к машине Тьюринга или лямбда-исчислению, реальные системы — к машинному коду. А операция сложения, MAKCim, тоже «сахар» в аксиоматике Пеано.
Засим предлагаю считать упоминания синтаксического сахара демагогией, пока автор не показал, как та же операция в общем виде реализуется в синтаксисе другого языка в сопоставимом объёме кода. «Читаемость» кода за аргумент не считается, как весьма субъективный критерий. Либо необходимо показать, как та же задача решается в другом языке какими-то существенно отличными средствами, но опять-таки в сопоставимом объёме кода.

Это сообщение отредактировал(а) Void - 2.1.2009, 15:55

 С чего ты взял?
Чтобы написать интерпретатор питона на паскале, нужно сначала написать компилятор паскаля на питоне.
Тоже "верное" утверждение, как и твое.

а я про что?

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


если уж перешли на формализм, давайте уточнять, что есть "сопоставимый объем кода" и почему это есть объективный критерий, в отличие от субъективного "читаемсть"

nerezus, 
твоя предпосылка - _наличие_ и компилятора паскаля, и интерпретатора питона
на практике же из пустого места ничего не вознивает
есть причина - есть следствие

Может и про то же самое, но зачем вообще было начинать?

Мне тоже не нравится канцелярщина, но что ещё можно противопоставить, маханию флагом «всё сводится к маш. кодам» (или технологии N - 2 уровня по вкусу).
Определение сопоставимого объёма кода: число лексем отличается не более чем в N раз. Я предлагаю N = 2,71828... Голосование по уточнению константы или введению второго члена устраивать будем? 

Только не говори, что ты про раскрутку трансляторов не слышал.

Это сообщение отредактировал(а) Void - 2.1.2009, 17:25

ну уж точно не размер   
увеличение размера не всегда есть хуже
поэтому нужно уточнить, что мы хотим получить в итоге: меньший объем кода, большую производительность, реализация определенной функциональности и т. д



к сожалению, нет