Ага, или как вариант, Bigloo — более матёрый компилятор/интерпретатор, и коммьюнити поболее будет. Правда уже сам компилятор нативный, а не под jvm. Но как бы здесь уже нужно смотреть на задачу.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
CU>>Есть ещё kawa...
LCR>Ага, или как вариант, Bigloo — более матёрый компилятор/интерпретатор, и коммьюнити поболее будет. Правда уже сам компилятор нативный, а не под jvm. Но как бы здесь уже нужно смотреть на задачу.
"JVM-нативность" как и скромный размер (даже вместе с JEmacs-ом) подкупают...
cl-user,
CU>И кто в этом виноват? Если бы javac был открыт и документирован вместе со своим AST-ом с самого начала и "торчал этими потрохам наружу", кто бы стал изобретать велосипеды? Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
Да, а как? Generalized common compiler?
M>>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
CU>И нафиг новый "булшит", если есть AST?
Присоединяюсь к вопросу, ибо по мне стандартизация же должна выполняться в каких-то терминах. Рано или поздно мы должны будем упереться в нечто, что придётся взять за основу и это и будет Самый Базовый Язык. Берём и его стандартизируем (вместе с синтаксисом (пусть он у нас будет чисто числовой) и семантикой, да). И назовём его Java Byte Code. Или BEAM Code. Или MSIL, если угодно. И все компиляторы отныне будут просто преобразователями в этот язык. И сделаем мегакомпилятор этого языка под все платформы, и назовём его JIT compiler.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
M>>>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
CU>>И нафиг новый "булшит", если есть AST?
А AST стандартизирован?
LCR>Присоединяюсь к вопросу, ибо по мне стандартизация же должна выполняться в каких-то терминах. Рано или поздно мы должны будем упереться в нечто, что придётся взять за основу и это и будет Самый Базовый Язык. Берём и его стандартизируем (вместе с синтаксисом (пусть он у нас будет чисто числовой) и семантикой, да). И назовём его Java Byte Code. Или BEAM Code. Или MSIL, если угодно. И все компиляторы отныне будут просто преобразователями в этот язык. И сделаем мегакомпилятор этого языка под все платформы, и назовём его JIT compiler.
Не понял вопроса.
Самый Базовый Язык может быть разным. Трансляция из одного языка в другой. Другой может быть C, может MSIL, может ява байткод, или некий абстрактный Самый Базовый Язык. Которых, самых базовых, может быть сколько угодно. И занимается трансляцией backend. А компилятор имеет у себя набор узлов, и может заниматься tree transformation как ему захочется. Он "думает" в этих терминах. А с человеком обменивается информацией через текст, через UML диаграмы, через визуальное представление диалогов и т.п. Ты, наверное, путаешь концепцию представления программы в виде дерева с концепцией компилятора с множеством backend-ов. У такого компилятора есть некое "стандартное" внутреннее представление, в которое преобразуют frontend-ы, и из которого генерируют программы backend-ы. А разница в том, что у GCC и подобных — внутренне представление фиксированное, а при подходе о котором я говорю — это расширяемый набор узлов/понятий.
Например, мы вводим понятие closure. Оно самостоятельное понятие. Но оно может быть преобразовано в другие. Для Java некий плагин/backend к компилятору его преобразует в inner class, для .NET в делегат, для OCaml-овской машины оставит как есть и т.п. Нет некоего стандартного представления в которое преобразует код frontend-ы. Эти определяемые семантические понятия/узлы используются компилятором "как есть", они равноправны. Как человек — у него там сформировано понятие о чём-то (скажем, из области геометрии — точка, линия, фигура) и он его может выразить и на русском, и на английском, и на китайском. Но это понятие не привязано к русскому, английскому или китайскому.
LCR>Короче, какой-то боян. Или нет?
Здравствуйте, LeonidV, Вы писали:
R>>В Java очень много недостатков, <...> LV>Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться. Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык. LV>Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать. И что получилось? Да ничего хорошего, на мой взгляд, не получилось. Хотя уверен, что супер профессионалы на этом языке могут писать супер профессионально. Только вот подавляющие большинстов, это программисты, которые могут дров наломать так, что потом эти дрова не в поленницу сложить, не печь засунуть.
LV>Кстати, для меня Java первую очередь элегантный язык. Куда как элегантнее Pascal, Basic, Ruby.
LV>PS Если верить Фаулеру, элегантный и, по сути, мертвый язык — Smalltalk.
Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это.
Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык.
Думаю, что j2ee еще продержится не один год, слишком много уже на этой платформе сделано и продолжают делать. Люди готовы платить за яву. Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо.
Здравствуйте, RI, Вы писали:
RI>Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это. RI>Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык.
Выше по теме заговорили про Scala: в курсе, что он компилируется в байт-код Java и в MSIL-код .NET? То есть при более выразительном синтаксисе получаем практически тот же байт-код. С учетом того, что платформы многоязыковые, ваш аргумент... сильно ни о чем.
RI>Думаю, что j2ee еще продержится не один год, слишком много уже на этой платформе сделано и продолжают делать. Люди готовы платить за яву.
Опять же синтаксис языка Java и платформа Java — как говорится, найди 10 отличий.
RI>Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо.
Только в C# их исправляют, а в Java пока не заметно... это и расстраивает.
Здравствуйте, rsn81, Вы писали:
RI>>Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо. R>Только в C# их исправляют, а в Java пока не заметно... это и расстраивает.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Исправляют. А потом появляются такие посты:
[skipped]
Читал все эти темы. Все это говорит о том, что C# становится все более и более сложным инструментом, который, с одной стороны, опасен для ньюби, но с другой стороны, предоставляет профессионалам инструмент с более тонкой настройкой, который позволяет делать все намного проще, лаконичнее, интуитивно понятнее. То есть о чем собственно писал по ссылке, которую давал в своем сообщении выше (про сравнение C# и Java): профи хотят инструмент похитрее-поудобнее — если этого не даст язык Java, неминуем отток в сторону той же Scala — разумеется, незначительный, только на основе энтузиазма: постоянного желания повысить производительность своего труда, адекватный интерес к новым веяниям в ИТ.
ANS>По, например, вопросам добавления лямбд у Блоха адекватная позиция — типа решите, вы хотите пофиксить "синтаксический оверхед" или новых фич напихать.
Хм...
Re: На Java можно ставить крест
От:
Аноним
Дата:
11.01.08 09:27
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Но ниче жива еще . И даст бог протянет ще не один десяток .
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
CU>>Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
LCR>Да, а как? Generalized common compiler?
Здравствуйте, mkizub, Вы писали:
CU>>>И нафиг новый "булшит", если есть AST?
M>А AST стандартизирован?
Я не про стандарт AST-а говорю, я про "мыло для идиотов": `некоего "внутреннего представления"`. Пишите на более менее строгом техническом языке, а не для детсада...
M>Самый Базовый Язык может быть разным. Трансляция из одного языка в другой. Другой может быть C, может MSIL, может ява байткод, или некий абстрактный Самый Базовый Язык. Которых, самых базовых, может быть сколько угодно. И занимается трансляцией backend. А компилятор имеет у себя набор узлов, и может заниматься tree transformation как ему захочется.
А почему эту tree transformation никак нельзя однозначно выразить в тексте и это и сделать "самым базовым языком".
В принципе я не про "базовость", я про необходимость знания что скрывается в том или ином языке за той или иной инструкцией/набором инструкций (в тех случаях, когда определённая "трансформация" не может быть "переведена" в одну инструкцию в выбранном языке). Т.е. я _всё равно_ хочу а-ля ASM (текстовый) для всех этих деревьев.
M>Он "думает" в этих терминах. А с человеком обменивается информацией через текст, через UML диаграмы, через визуальное представление диалогов и т.п. Ты, наверное, путаешь концепцию представления программы в виде дерева с концепцией компилятора с множеством backend-ов. У такого компилятора есть некое "стандартное" внутреннее представление, в которое преобразуют frontend-ы, и из которого генерируют программы backend-ы. А разница в том, что у GCC и подобных — внутренне представление фиксированное, а при подходе о котором я говорю — это расширяемый набор узлов/понятий.
Менять поведения компилятора по мере компиляции? Отлично! Давно хочу. Только хоть прибейте меня — не пойму почему это нельзя выражать текстом.
M>Например, мы вводим понятие closure. Оно самостоятельное понятие. Но оно может быть преобразовано в другие. Для Java некий плагин/backend к компилятору его преобразует в inner class,...
Вот за это "расстрел на месте". Т.е. смотреть в текст Java и догадываться, что вот эти 10 строк кода являются "одним узлом"? Нафиг здесь тогда Java? "Универсальные" программы будут получаться "экстремально" не эффективными. Ибо кодируя на Java ты знаешь цену тех или иных подходов, а в вашем случае?
Здравствуйте, rsn81, Вы писали:
RI>>Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это. RI>>Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык. R>Выше по теме заговорили про Scala: в курсе, что он компилируется в байт-код Java и в MSIL-код .NET? То есть при более выразительном синтаксисе получаем практически тот же байт-код.
Есть некоторые подозрения, что "джависты" будут писать на Scala код "оптимальный" для JVM, а "дотнетчики" — для .NET
Здравствуйте, cl-user, Вы писали:
CU>Есть некоторые подозрения, что "джависты" будут писать на Scala код "оптимальный" для JVM, а "дотнетчики" — для .NET
Оптимальный Java байт-код на Scala — вряд ли, посмотрите байт-код который генерирует Scala-компилятор... А у .NET-программистов есть уже, в принципе, своя религия — Nemerle.
R> R>Читал все эти темы. Все это говорит о том, что C# становится все более и более сложным инструментом, который, с одной стороны, опасен для ньюби, но с другой стороны, предоставляет профессионалам инструмент с более тонкой настройкой, который позволяет делать все намного проще, лаконичнее, интуитивно понятнее.
Чем более сложный язык, тем проще одному опытному программисту написать так, что другой опытный программист его не поймет. В результате получаем developer-locking :)
А "интуитивно-понятней" в данном контексте для меня "хрен-знает-как-но-работает". Я сторонник простых языков. И вещей в целом. И привязанность к как можно более простым вещам у меня идет после книг Раскина, Купера и других. В часности, Купера пишет о любви программистов к сложным вещам. И откуда эта любовь берется. И почему это плохо, тоже пишет.
Здравствуйте, <Аноним>, Вы писали:
А>Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Вы о MS JVM? Насмешили...
А>Но ниче жива еще . И даст бог протянет ще не один десяток .
Десяток — вряд ли.
Здравствуйте, LeonidV, Вы писали:
LV>Чем более сложный язык, тем проще одному опытному программисту написать так, что другой опытный программист его не поймет. В результате получаем developer-locking
Разумеется, только выше уже приводили достаточно серьезный аргумент против этой точки зрения... точнее взгляда на данный вопрос только под этим углом.
LV>А "интуитивно-понятней" в данном контексте для меня "хрен-знает-как-но-работает". Я сторонник простых языков. И вещей в целом. И привязанность к как можно более простым вещам у меня идет после книг Раскина, Купера и других. В часности, Купера пишет о любви программистов к сложным вещам. И откуда эта любовь берется. И почему это плохо, тоже пишет.
Даст бог, дойдут руки и до этих авторов, пока на года вперед книги расписаны.
Простые вещи хороши "в данном контексте" до поры до времени, пока они хорошо справляются с поставленными задачами. Когда же назревает явный и ощущаемый (хотя бы некоторым значительным количеством) сведующими в теме недостаток, бывает проще отказаться от простого инструмента, который попросту не может объять слишком сложную сущность, в сторону некоторого относительно более сложного инструмента, который справится с этой задачей с меньшими трудозатратами, то есть трудозатраты на изучение и использование нового инструмента будут меньше, чем без него. Как пример, когда-то концептуальную сущность программ можно было описать блок-схемой алгоритма, теперь уже чаще UML, да и то... спорный инструмент. Не говорю, что Java сильно не справляется с текущими задачи, вовсе нет, но ощущается, что это может стать реальностью через несколько лет такого упорного консерватизма.
Здравствуйте, Аноним, Вы писали:
А>Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Во-во. Помню как кричали что Яве конец, когда C#.NET появился.
Здравствуйте, Kisloid, Вы писали:
ANS>>Ходить туда лень. Но что-то мне помниться, что связано со словом "collection"
K>Угу, GNU Compiler Collection, но раньше оно расшифровывалось как GNU C Compiler.
[joke]
Это при царе-горохе^W^W когда его RMS писал что-ли?
[/joke]
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.
