DotGNU - Making the Web Work for You!

Правильная весчь, однако. Особенно интересна суперкомпиляция - до сих пор ничего подобного для других языков сделать не смогли.

>олько C++, на мой взгляд, намного более трудный и "тяжелый".
C++, конечно, тяжелый и трудный. Загадочно, что он пришел к такому состоянию, хотя основным девизом Строуструпа было не перетяжелять язык, и не втаскивать на уровень языка средства, без которых трудно обойтись.
Однако, имхо, вся тяжесть C++ -- в неочевидных правилах name resolution и множественного наследования. Но с другой стороны, если над языковыми механизмами подумать, _почему_ было сделано так, а не иначе, понять логику авторов и реализации -- то весь язык становится абсолютно прозрачным.

>Мне так кажется, что если C++ не развивался, а родился сразу такой какой он есть, то его бы изучать никто не стал.
А вот с этим я абсолютно согласен.

>Сейчас в учебных заведениях, бывает, отказываются изучать C++ в пользу Java.
А это со зла... Все-таки это принципиально разные языки для разных задач.

>Ну и тормознутостью, конечно же.
Antichrist, интересно, как можно быстрее сворачивать стек (это касательно только C++)? В принципе, исключение, при правильной реализации, не столь уж дороги. Неслучившееся исключение почти ничего не стоит, а если уж оно произошло -- вилы уже случились, и скорость реакции и обработки, имхо, уже не имеет большого значения. Imho, использовать исключения просто как механизм управления логикой -- вредно и неправильно, а быстро обрабатывать "исключительные ситуации" в большинстве случаев ни к чему.

абсолютно согласен с AC про "_почему_ было сделано так, а не иначе, понять логику авторов и реализации -- то весь язык становится абсолютно прозрачным."

"Мне так кажется, что если C++ не развивался, а родился сразу такой какой он есть, то его бы изучать никто не стал." ну мля любой из современных языков 30 лет назад никто не стал бы изучать :)

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

по поводу первого пункта очень рекомендую всем книжку "дизайн и эволюция С++" :)

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

Антик а вроде у них проект есть. суперкомпиляция под яву? Там вроде тоже примерно все делается как в РЕФАЛЕ. Кстати а почему они тогда свой язык не доразвивают, чтобы он был покруче всяких окамелов?

Кстати, суперкомпилятор Java они пишут на SML (используют MoscowML), но, возможно, скоро перейдут на OCaml, так как он значительно шустрее. Я сам чуть не попал в их команду, но вовремя понял, что тогда про физику придётся забыть, а на енто я пойтить не могу. ;)

Ну а сам по себе РЕФАЛ - язык мощный и интересный, но имеет очень узкую область применения - обработку текстов. Пытаться заточить его под что-либо другое - значит просто безнадёжно испортить язык.

>Реально же на исключениях часто можно красивую логику реализовывать
Можно, не вопрос. Но это уже "теологический" вопрос:) imho, такой механизм, о котором ты говоришь, не должен называться exception. В С++ такого механизма быстрого "дальнего возврата" нет -- и это надо принимать как есть:) У меня вообще есть сомнения в самой возможности реализации такого механизма в плюц-плюце.

Ну дык извращаются же с longjump-ами...

ключевое слово -- извращаются. про longjump я в курсе, да разве ж это жизнь?:)

Кстати, я не понял почему от web языка требуется какая то мифическая производительность? Мне вот, например, надо строить большой статический сайт из БД - несколько десятков тысяч файлов. Почему статический? Потому что должен даже с компакт диска работать :)

Так вот, у меня ожидание ответа от БД занимает 90% времени. Тут хот на чем пиши, все равно время ВЫПОЛНЕНИЯ не изменится, а вот время НАПИСАНИЯ очень даже меняется.

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

$templ2 =~ s/__LINK__/$key/ig; $templ2 =~ s/__TITLE__/$nameslong{$key}/ig; open (FILE, ">$struct/$key" . "t.htm"); print FILE $body2; close FILE;

Все, вот и все мои темплейты и прчие регэкспы не показываю, чтобы вам дурно не стало :) Почти любое измудохивание шаблона выполняется одним перловым регекспом в 50 символов.

В вашей джаве имя какого нибудь переменной столько букв займет, а C# мне нахер не уперся, т.к. мой перд везде работает.

It looks like many of respected participants bash the wrong door when criticize C#, CLR, and .GNU implementation in particular. We need to understand that the *real* issue with .NET is not CLR, not 'innovative C#', but (rarely mentioned) Microsoft's Passport authentication system. If .NET platform will gain a decent share of Web servers, then Passport will quickly become dominating solution for authentication and electronic transactions, and who controls them, controls e-commerce (and respectively major profitable market on the Internet). Guess who is going to control it?

Thus .GNU is a vital project if we purport to have alternative, independent authentication system. Clearly, it have to re-create all the supporting infrastructure as well. So wonder you not why FSF hosts such a 'hostile' project.

Above is not just my own opinion; several other compiler writers who've considered .NET platform are quite aware of this issue and believe that that's a major drive behind all the fuss.

http://www.gnu.org/projects/dotgnu/auth.html

P.S: I apologize for English, posting this from a public terminal.

> Кстати, я не понял почему от web языка требуется какая то
> мифическая производительность?
Сеть --- это не только сайты. И не только БД.