ненужный велосипед

Каждому девелоперу - по велосипеду с 8-угольными колесами и по собственному языку !

Как только не изворачиваются чтобы не писать на лиспе...

>>статической типизацией и компилируемый в java-байткод

Гм. Не понял: что бы скомпилить в байт-код нужна статическая типизация? Или это ограничение жаба-платформы?

....В любом случае, я думаю, «статическая типизация в Ruby» звучит довольно нелепо.

Зачем оно нужно если есть Scala?

web-фигня начнет просто летать.

Причем, не на сервлетах :)

p.s. Фиговый глобус. В виде куба и ненужный.

Динамические петушки как только не изворачиваются, чтоб прорекламировать никому не нужные скобки.

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

а зачем? У языков разные задачи и принципы. Это как делать вариант php-интерпретатора для python^^

>а зачем?

в отличие от статически типизированного Руби, я бы мог очень быстро портировать пару старых алгоритмов с Delphi и прилинковать к основному проекту на яве, ну и просто потому что Паскаль мне нравиться больше чем Руби

У языков разные задачи ...

да ну)) и какая задача у Явы?

> да ну)) и какая задача у Явы?

Поработить весь мир.

ты просто завидуешь

быстро портировать пару старых алгоритмов с Delphi

Тут уже искали программу для конвертации исходников с паскаля в жабу, мож уже нашли?

> в отличие от статически типизированного Руби, я бы мог очень быстро портировать пару старых алгоритмов с Delphi и прилинковать к основному проекту на яве, ну и просто потому что Паскаль мне нравиться больше чем Руби

каких только извращенцев в жизни не встретишь )

> яванский велосипедист Попов изобрел «принципиально-новый» язык

//fixed

p.s. И да, Java не нужна.

ненужно, есть groovy++

Пускай пилят, питоноклоны под .net со статической типизацией выглядят хорошо. Правда пользовать всё равно все будут жаву и сишарп.

Все правильно сделал. Статическая типизация рулит и педалит.

А про Бритву Оккама изобретатели велосипедов как-то, видать, забыли.

Эти поделия используются только закомплексованными кульхацкерами, которые так самоутверждаются. Что бы бесцельность своего существования скрыть. Типа тоталитарных сект.

неистово жду няшный обьектно-ориентированный Perl++ на жава-машине.

> неистово жду няшный обьектно-ориентированный Perl++ на жава-машине.

и объектно-ориентированный brainfuck+++ на jvm

>Эти поделия используются только закомплексованными кульхацкерами, которые так самоутверждаются. Что бы бесцельность своего существования скрыть. Типа тоталитарных сект.

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

poprobuy Eclipse - XTEXT

midlet pascal

неистово жду няшный обьектно-ориентированный C++ на чем-нибудь.

fixed

Ну если из mirah выкинули эти все кашеобразные перловкообразные $xx, то я только «за».

ПС Хотя, вижу что выкинули покамест только скобки. Зря, имхо.

>Не понял: что бы скомпилить в байт-код нужна статическая типизация?

Нет, емнип. Для Ruby 1.9 есть байткод-компилятор.

>Динамические петушки как только не изворачиваются, чтоб прорекламировать никому не нужные скобки.

Какую только чушь не порят анонимусы, использующие в не меньшем количестве >9000 видов скобок вместо одного вида в своих убогих программах.

Блин, вообще-то это был риторический вопрос. Понятно что и ruby и python нативно в байт-код компиляют. Просто новость так составлена, что можно сделать заключение, что без статической типизации в байт-код компилежка невозможна в принципе. А на самом деле это жаба такая жаба.

А толку от того байт кода? Тут и ребенку понятно, что имеется в виду, что будет возможна компиляция в типизированный же байт код, пригодный для jit компиляции.

>midlet pascal

сдохло же (всмысле j2me сдохло и Pascal, который не Object сдох)

что будет возможна компиляция в типизированный же байт код, пригодный для jit компиляции.

Любой байткод пригоден для jit компиляции, но не любой jit компилятор пригоден для этого (с)

А на самом деле это жаба такая жаба.

Жаба невиновна. «компилежка» возможна

> язык «практически не отличающийся от Ruby», но при этом со статической типизацией

Это квак?

А хз. Цитата «wanted to create a language that essentially looked like Ruby, but was statically typed and compiled to fast JVM bytecode»

Если я правильно помню, то по этому принципу любое явление объясняется божьей волей, и ни чем иным.

Вы бы с ним того, поаккуратнее.

> ... я бы мог очень быстро портировать пару старых алгоритмов с Delphi и прилинковать к основному проекту на яве, ну и ...

меня конешно забанят за такие слова, но не могу не высказаться :-)

вот что за люди! с одного говноязыка на другой говноязык!

и почему нельзя просто перескочить этот Java/PHP-этап и сразу пересесть на Python/Ruby %-) . нет же, нада обязательно сначало написать побольше говнокода на говноязыках!

# p.s.: понятно что всем C/Pascal программистам внушали с детства о том как хорошо что когда в языках есть ";" и «{..}»(«BEGIN..END»). что якобы именно это отличает Pascal от Basic . но поверьте(!) от Basic отличает совсем не это

> Просто новость так составлена, что можно сделать заключение, что без статической типизации в байт-код компилежка невозможна в принципе. А на самом деле это жаба такая жаба.

А на самом деле это жаба такая жаба.<<<

динамическую типезацию можно рассматривать как частный случай статический типизации. (все динамические объекты будут одного и того-же статическаого типа <Variant>)

такчто если НЕТ возможности скомпилировать Ruby в Java-Байткод — то это всеголишь недостаток JRuby-компилятора (но не языка Ruby)

(понятное дело что в полученной [гипотетической] скомпилированной прогремме нельзя будет пользоваться методами объектов <Variant> как обычно напрямую:
d = my_var.myMethod(b, c);
но Java-ограничения на d = my_var.callMethod('myMethod', String[]{a, b}) НЕТУ!!!
)

>вот что за люди! с одного говноязыка на другой говноязык!

без аргументов эти твои слова всё равно что пустой выхлоп, а так как аргументов у тебя нет, то я просто сочту, что ты неасилил ни Java ни Object Pascal и потому брызжеш тут слюной)) не в обиду Python/Ruby программистам, я и сам частенько программировал плагины для того и сего на Питоне и прсто утилитки, он мне очень нра..

Любой байткод пригоден для jit компиляции, но не любой jit компилятор пригоден для этого (с)

В топку такие компиляторы. Читал как-то, что для smalltalk такое делали. Оно там и правда нативный Си почти догнало. Только памяти кушало... Блин все равно type-хинтинг это круто. В clojure такое есть, и в common lisp вроде тоже.

Оно там и правда нативный Си почти догнало. Только памяти кушало..

Размен памяти на процессор

А разве Smalltalk не жрет память больше жабы?

Java позицианирует себя как язык для быстрой разработки

но, извените, конструкции типа:

Path file = "путь/к/файлу";
InputStream in = null;

try {
    in = file.newInputStream();
    BufferedReader reader = new BufferedReader(new InputStreamReader(in));
    String line = null;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
} finally {
    if (in != null) in.close();
}

-- совсем не ускоряют скорость-разработки своей грамоздкостью.

в то время как в Python этиже действия --занимают вот сколько строчек/символов:

file = "путь/к.файлу"

with open(file) as fd:
    for line in fd:
        print(line)

конешно из Java-кода можно выбросить <Try-Finally>-обработку и код укоротится. но тогда это будет НЕ аналог приведёному выше Python-коду (так как Python-конструкция-<with> — неявно содержит в себе Try-Finally)

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

про итераторы , замыкания и декораторы (ой! вспомнил и про перегрузку операторов!) — даже и говорить нехочется. если уж такой элементарной вещи как показано выше — нет в Java . разводить тома «Война и Мир» о том зачем нужны декораторы и аспектно-ориентированный подход — здесь думаю это плохая идея.

(но вкрадце поясню) вот например блок кода на Python для работы с Django:

from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote')
def my_view(request):
    // функция отрисовки Www-страницы
    ... 

здесь мы через декоратор задекларировали что функция отрисовки стрианццы (my_view) будет рисовать Www-страниццу только тем Www-пользователям кто залогинен и у кого есть привелегии «polls.can_vote», а иначе она будет переадресовываться на другую страниццу

и этот простейшый API-интерфейс полностью импортируется из стороннего Django движка.

а на Java для точно такойже функциональности — пришлосьбы гододить Framework на каждый из Www-проектов — индивидуально

так как java не будучи функциональным языком — он не способен чотко разделять управляющщие инструкции одного типа от управляющих инструкций другого типа . в случае если они работают на одном и томже функциональном уровне

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

(конешно не нужен функциональноый подход чтобы отделить управляющие инструкции разных уровней (один уровень поверх другого). но когда уровень один и тот же — Java будет смешивать логический код внутри уровня)

впрочем объектно-ориентированный полиморфизм — тут немного выручает (это касается и Java и object Pascal, ... и C++) . но наследование интерфейсов (интерфейсов в терминологии Java) и абстрактных классов, а затем перегрузка callback-функций — это громоздко и ни сколько не ускоряет разработку (в то время как послать указатель на нужную функцию, что можно сделать в Python — и то намного быстрее. хотя речь даже об Python-декораторах, а не об этом).

тоесть опять-таки мы приходим к выводу что чтобы добиться той же функциональности что и на Python — Java-программа должна разбухнуть раз в 5~10 (по сравнению с Python)

ни Java ни Object Pascal

вобщем — яву конешно же я осилил, и прищёл к выводу что философия разработки на Java заключается в то что можно писать обычный (некачетвенный) код, а можно писать точно такой же но с учотом обработки исключительных ситуаций (в этом случае Java-код увеличивается в 2~3 раза и многократно усложняется)

в следсивии чего — песйать некачественнй код становитсья намного соблазнительнее. а особенно когда начинают поджимать сроки :-)

что касается Object Pascal — то это тоже самое что C++ . только операторы называются подругому (конструкции подругому записываются) . ну и конешно в C++ получше будет с <template> .

однако C++ не позиционирует себя как язык для быстрой разработки — поэтому к нему притензий нет :-)

>в то время как в Python этиже действия --занимают вот сколько строчек/символов:

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

С Django не работал, но, думаю, это же можно отнести и к нему.

+1

А то что в яве сделан уклон именно на использование классов везде где можно, так это принцип такой и он мне очень нравиться ввиду того что он идёт парралельно с принципом KISS - в отличие от перенасыщенных всякими выкрутасами Python программах в аналогичной Ява программе почти стороннему разработчику разобраться легче (не забываем что Ява во многом расчитан на тот же Ынтырпрайз, а тут это важно).

вобщем — яву конешно же я осилил, и прищёл к выводу что философия разработки на Java заключается в то что можно писать обычный (некачетвенный) код, а можно писать точно такой же но с учотом обработки исключительных ситуаций (в этом случае Java-код увеличивается в 2~3 раза и многократно усложняется)

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

По поводу Object Pascal - так он гораздо удобней чем C++ (хотябы тем что в нём не надо писать угрёбищьные заголовочные файлы) и намного надёжней (хотябы потому что в нём нет множественного наследования и прочего ++ мусора делающего код гомном). И того Object Pascal не позиционирует себя как язык для быстрой разработки - если вы о Delphi - так это сейчас считай тулза для создания софта работающего с БД, а если о Free Pascal то он никогда не позиционировался как средство для быстрой разработки, хотя в купе с Lazarus - да более мощного средства для создания маленьких кроссплатформенных и быстрых тулзовинок я не встречал. Разве что QtCreator, но он не всчёт - он для отстойного C++ и к тому же по скорости и удобству всёже не дотягивает до Lazarus.

(но вкрадце поясню) вот например блок кода на Python для работы с Django:

здесь мы через декоратор задекларировали что функция отрисовки стрианццы (my_view) будет рисовать Www-страниццу только тем Www-пользователям кто залогинен и у кого есть привелегии «polls.can_vote»

Туфта, я уверен что знающие какой-нибудь Guice или Spring легко сделают подобные однострочники и в жабе, либ для этого предостаточно