Разработчики JRuby переходят на работу в Sun

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

Слава богу. Ruby будет поглощен джавой и умрет. Впрочем, туда ему и дорога; больше нормальным языкам вроде Java достанется. А питон пусть идет в биореактор.

Пыхтон поел моск ананимусов :))

это видимо мантра.

там IronPython лепят, тут jRuby

Зачем коверкать языки?

Sun стремится доказать, что java быстрее C.
Приглашая к себе разработчика JRuby они вкладывают деньги в создание аргумента в пользу Java, дабы потом сей факт громко пиарить. И говорит это о том, что с точки зрения аналитоков Sun язык Ruby имеет достаточную популярность (привлекательность), иначе смысла в "соревновании" не имелось бы.

Посмотрим, хватит ли мощностей Sun победить свободную и, as far as i know, никем не спонсируемую разработку на C.

>Sun стремится доказать, что java быстрее C.

Ага ... вот когда JVM на Java напишут ... а поверх ещё Ruby on Rails и всё это на CLI водрузят .. вот это будет соляночка ... Вопрос, кто согласится сие кушать ...

>Sun стремится доказать, что java быстрее C. >Приглашая к себе разработчика JRuby они вкладывают деньги в создание аргумента в пользу Java, дабы потом сей факт громко пиарить. И говорит это о том, что с точки зрения аналитоков Sun язык Ruby имеет достаточную популярность (привлекательность), иначе смысла в "соревновании" не имелось бы.

>Посмотрим, хватит ли мощностей Sun победить свободную и, as far as i know, никем не спонсируемую разработку на C.

смешной вы. Вот уж думаю, что о дурацких спорах о производительности сановцы думали в последнюю очередь.

Динамические языки это сейчас модно. Многие кричат, что за ними будущее - вот сан и старается показать, что держит руку на пульсе. Собственно это не первая попытка сделать динамический язык на ява платформе. Взять тот же groovy. А тут и язык набирающий популярность и решение почти готовое. Ну что для сан нанаять двух программеров ? Это ведь не СЕО майкрософта переманить.

Еще соображение - многие рубиисты это бывшие/нынешние явовцы, которым не нравится технологии, которые ява предлагает для web. Они впольне могут с удовольствием начать пользоваться таким гибридом.

Да и рубиистам jruby дает много чего вкусного. Возможность пользовать явовские либы, возможность пускать рельсы в J2EE контейнере, да и вообще выводит рельсы на энтерпрайз уровень.

Короче пусть плодятся и размножаются ^)

>Зачем коверкать языки?

Каким образом написание собственного интерпретатора совместимого с последней версией оригинального можно назвать коверканьем языка? Обьясните плиз

> смешной вы. спасибо! ))

> Вот уж думаю, что о дурацких спорах о производительности сановцы думали в последнюю очередь. > Динамические языки это сейчас модно. Многие кричат, что за ними будущее - вот сан и старается показать, что держит руку на пульсе.

чтобы держать руку на пульсе, надо написать свое! а если они переделывают уже созданное на другой технологии, то это, в первую очередь, стремление подчеркнуть преимущества своей, sun-ой, технологии.

в принципе, возможны оба варианта.. и даже другие! в зависимости от достигнутых успехов и конъюнктуры Sun будет по-разному расставлять акценты в своем PR-e... делов-то ))

"JRuby - интерпретатор языка Ruby написанный на java." - это не дибилизм? дестять интерпретаторов в квадрате?

> JRuby - интерпретатор языка Ruby написанный на java. я боюсь недалекого будущего, хоть щас вешайся...

жду ответа: "Так и сделай!" :)

> смешной вы. спасибо! ))

Простите. Я не хотел вас обидеть )

Ну а зачем писать свое ? ) Если есть вот, готовое с коммьюнити, либами, проталкивателями и прочим. Тем более, что среди агитаторов половина своих - явщиков. )

Что значит переделывают? Они просто пытаются интегрировать руби/рор в свою платформу. Если бы можно было интегрировать оригинальный руби интерпретатор, они бы с удовольствием это сделали безо всякого переписывания.

Смысл совсем не в том, чтобы доказать что руби на яве быстрее, смысл в том, чтобы заполнить в ява платформе нишу - изящное создание вебприложений, скриптовые языки, метапрограмминг, glue coding. Руби для этого отлично подходит.

>Sun стремится доказать, что java быстрее C. Приглашая к себе разработчика JRuby они вкладывают деньги в создание аргумента в пользу Java, дабы потом сей факт громко пиарить. И говорит это о том, что с точки зрения аналитоков Sun язык Ruby имеет достаточную популярность (привлекательность), иначе смысла в "соревновании" не имелось бы.

>Посмотрим, хватит ли мощностей Sun победить свободную и, as far as i know, никем не спонсируемую разработку на C.

Думаю, что смогут. Уже сегодня JRuby пользует очень хороший GC от JVM. Т.е. в одной области JRuby уже сильней чем родная реализация. Учитывая что Sun объявил курс на родную поддержку динамически типизированных языков, то думаю лет через 5 у них будет и JIT для Ruby. А если еще и JVM откроют в следующем году как обещают, то будет вообще великолепно.

P.S. Сторонники питона, php и perl сравнивая реализации этих языков с реализацией ruby, забывают очень немаловажный факт - все их любимые питоны, пхп и перлы (в отличие от "reference" реализации Ruby) НЕ ИМЕЮТ полноценного GC, а пользуют примитивный подсчет ссылок, что на мало-мальски нетривиальных структурах данных приводит к утечкам памяти.

> P.S. Сторонники питона, php и perl сравнивая реализации этих языков с реализацией ruby, забывают очень немаловажный факт - все их любимые питоны, пхп и перлы (в отличие от "reference" реализации Ruby) НЕ ИМЕЮТ полноценного GC, а пользуют примитивный подсчет ссылок, что на мало-мальски нетривиальных структурах данных приводит к утечкам памяти.

Я поражаюсь. Вы стоите на самой низшей ступени развития, вы еще только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии людей с университетским образованием позволяете себе с развязностью совершенно невыносимой делать какие-то заявления космического масштаба и космической же глупости! А теперь запускаем питон, делаем import gc, потом gc.enable(), и скорее в кроватку, пока мама не заругала, за то что так поздно сидите на взрослых сайтах!

Если хочешь что-то развалить - возглавь это. Санки, похоже, прочитали недавно пролетавшую здесь статейку о том, что ruby скоро заменит java. И решили предотвратить эти поползновения :)

> "JRuby - интерпретатор языка Ruby написанный на java." - это не дибилизм? дестять интерпретаторов в квадрате?

Это не дебилизм, а пеар жабы.

> import gc, потом gc.enable()

Уточнение: в Питоне уборка мусора и так включена по умолчанию, и специально делать ничего не надо. Разве что import gc; gc.disable(), если сильно захочется. :) Впрочем, в Руби всё абсолютно так же, только include вместо import, и GC пишется большими буквами. :D

Sun просто втаптывает в грязь .Net, который им как бы "конкурент". Единственным плюсом .Net является возможность кодить на разных языках, а Java это Java. Сейчаc Sun делает именно то, что позволит .Net находится в тени Java еще 10 лет.

> Java это Java

Аргумент на пять. А БЕЙСИК это БЕЙСИК, а Лисп это Лисп. И чо? Кончилася жабкина бл%цкая молодость, пришла убогая старость, песок из жопы сыплется, и каждый мечтает поссать на могилу. Тебе жалко быдлозавра, друк? А я знаю, что это карма. И против неё не попрёшь. (с).

e-max закросспостил сюда http://rsdn.ru/Forum/Message.aspx?mid=2099277&all=1

>Если хочешь что-то развалить - возглавь это. Санки, похоже, прочитали недавно пролетавшую здесь статейку о том, что ruby скоро заменит java. И решили предотвратить эти поползновения :)

По етому поводу анонимусы могут не беспокоиться - статейка гамвно.

+1 Это однозначно дебилизм. Лучше бы компилятор пыжились написать :)

>JRuby - интерпретатор языка Ruby написанный на java." - это не дибилизм?дестять интерпретаторов в квадрате?

Интересно, а сколько ещё мутантов не знает, что java - не интерпретатор? ;-)

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

Жаль, много комментов потерли.

Но все таки мне хотелось бы уточнить один момент. Все любители Питона
 утверждают, что анонимные функции не нужны, потому что так сказал 
мудрый Гвидо.

Я не опираюсь на слова авторитетов, у меня есть свой опыт, который я 
приобрел программируя. Это не слова авторитетного перца, а то что 
пришло из практики. Оставим красноглазые дебаты. Давайте по фактам. 
На практике.

1) Простой скрипт. Нужно перейти в некую директорию, выполнить там 
ряд операций и вернуться назад. Реализация в Руби выглядит следующим 
образом:

Dir.chdir ("testdir/") do
  File.read ...
end

Таким образом методу chdir передается блок кода анонимной фунции do
 ... end, который выполняется в каталоге testdir. После завершения 
выполнения метод chdir возвращает в предыдущий каталог.
Теперь вопрос, мне что, для очевидной обертки давать имя? И какое? 
def goto_dir_testdir ???

Если ответ да, то почему тогда вы при вызове for не даете телу 
итератора имя и не передаете его непосредственно? Ведь в теле цикла может
быть не одна строка кода? Где последовательность во взглядах?

Очевидно, что данный прием можно использовать для операций открытия/закрытия 
файла, базы данных. Или например  для формирования древовидной структуры аля html.

Tag.table {
  Tag.tr {
    Tag.td {
      puts "some text"
      puts "..."
    }
  }
}

Так что, вы и для этого случая будете создавать целую охапку def-ов?

Если я ошибаюсь и мудрый Гвидо уже придумал способ, как действовать в 
таких ситуациях, напишите.

"IronPython дерьмо еще то"

http://www.linux.org.ru/jump-message.jsp?msgid=1566976

Ну если же оставить фонатегов в стороне, то в Питоне есть элементы функционального программирования (конструкции lambda, map, reduce).

http://zope.net.ru/text/Python/Intro/Oleg_Broytmann/perl.html

"Краткое введение в Питон (для людей, ушибленных перлом)"

Относительно юзабельности этих метод как в Питоне, так и Ruby... Трудно сказать. Я бы назвал использование таких "изйопов" дурным стилем программирования в Питоне, ибо код становится менее прозрачным; да и наверняка IDE типа Wing не распарсят достаточно сложные извраты, что усложняет работу с кодом, особенно рефакторинг чужого кода. Вообще-то Питон объектно-ориентированный и для решения таких вещей проще юзать объекты (может вкупе с ламбдой, смотря какую задачу решаешь). Что же касается полноценной работы с DOM-моделью, если вы юзаете для этого функции... Сорри, за такое можно и редирект в Бабруйск получить ;) Кстати, Ruby (ща глянул в гугле) тоже типа весь из себя OO, так что вам стоит подумать по расширение экспириенса.

Интересно, в Sun хватит ваканский для всех разработчиков языков из этого http://www.robert-tolksdorf.de/vmlanguages.html списка?

>Ruby будет поглощен джавой и умрет. Впрочем, туда ему и дорога; больше нормальным языкам вроде питона достанется.

Питон, говоришь? А ты про Jython слышал когда-нибудь? Про то, где и как он используется? Когда ожидать "поглощения"?

А ты серьезно думаешь, что Жопитоном в работе кто-то пользуется? ;) Вот так вот жабодевелопер с перепугу откажется от IDEA или Eclipse и начнет в нотпаде на Жопитоне струячить? :)) Ты хоть представляешь, как упадет скорость разработки и насколько багливым будет результат? Тут скорее не "поглощение" а отправка в Бабруйск на ПМЖ.

> Относительно юзабельности этих метод как в Питоне, так и Ruby...

Юзабельность в Питоне близка к нулю, потому как анонимная функция кастрирована.

В Руби использование блоков (ака анонимных функций) является стандартом де-факто. Все итераторы, методы для работы с массивами и хешами (map, sort, each, select) работают через блоки.

> Трудно сказать.

Поэтому сказать легко: они нужны и эффективно используются в Руби. Примеры выше я привел.

Ответ по поводу открытия/закрытия баз данных я так и не увидел. Насчет дом-модели замечание неуместно. Это пример, который показывает возможность. Таким образом можно выводить вложенные виджеты в Tk и является возможностью. Которой по понятным причинам в Питоне нет. Если вы этого не осилили, вам стоит самим пройтись в направлении Бабруйска.

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

>> Таким образом можно выводить вложенные виджеты в Tk и является возможностью.

А вот с этого места поподробнее. Ибо мне, как аффтару sK1 (http://sk1.sf.net) крайне любопытно, чем вы в Руби собрались Tkinter заменять. Ну или улучшать. ;)

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

Я понимаю, что вы не знаете Руби и поэтому считаете, что анонимные функции прерогатива функционального программирования. Если бы вы 
прочитали хотя бы первую часть классического Programming Ruby (второй 
эдишн), то увидели бы, как без оператора for(Python), foreach 
(PHP,Perl) можно писать итераторы и другие вещи для работы с 
массивами, хешами и другими структурами.

Все это нормально уживается с ООП, который в Руби на порядок лучше 
реализован, чем в Питоне.

> А вот с этого места поподробнее. Ибо мне, как аффтару sK1 (http://sk1.sf.net) 
> крайне любопытно, чем вы в Руби собрались Tkinter заменять. Ну или 
> улучшать. ;)

Я не понял, что вы имеете в виду под Tkinter, но ниже приводится 
пример(взятый из выше упомянутой книжки), в котором показывается, как 
можно использовать древовидную структуру(которая строится на основе анонимных функций), которую вы выше уже успели 
обосрать (имеется ввиду пример с Tag.table, Tag.tr и т.п.):


require 'tk'
include Math
TkRoot.new do |root|
  title "Curves"
  geometry "400x400"
 TkCanvas.new(root) do |canvas|
  width 400
  height 400
  pack('side'=>'top', 'fill'=>'both', 'expand'=>'yes')
    points = [ ]
    10.upto(30) do |scale|
      (0.0).step(2*PI,0.1) do |i|
        new_x = 5*scale*sin(i) + 200   + scale*sin(i*2)
        new_y = 5*scale*cos(i) + 200   + scale*cos(i*6)
        points << [ new_x, new_y ]
        f = scale/5.0
        r = (Math.sin(f)+1)*127.0
            (Math.cos(2*f)+1)*127.0
        g =
            (Math.sin(3*f)+1)*127.0
        b =
        col = sprintf("#%02x%02x%02x", r.to_i, g.to_i, b.to_i)
        if points.size == 3
          TkcLine.new(canvas,
                       points[0][0], points[0][1],
                       points[1][0], points[1][1],
                       points[2][0], points[2][1],
                       'smooth'=>'on',
                       'width'=> 7,
                       'fill'     => col,
                       'capstyle' => 'round')
          points.shift
        end
      end
    end
  end
end
Tk.mainloop

Я думаю, это уже нельзя считать "сферическим конем" и просьба привести
реализацию аналогичного на Питоне, ведь "Бох Гвидо" всем питонистам сказал что анонимные ф-ции
не нужны. Ну раз не нужны, покажите реализацию без них.

> end end end end end

ГАГАГА!!! И такой макаронный код с пятью уровнями вложенностями ты нам суёшь как образец красоты твоего раби? Да если за такое не убивать, тогда за что вообще убивать?

>> end end end end end

>ГАГАГА!!! И такой макаронный код с пятью уровнями вложенностями ты нам суёшь как образец красоты твоего раби? Да если за такое не убивать, тогда за что вообще убивать?

Приведи лучший пример.

P.S. Кстати, что касается открытия-закрытия соединений/PreparedStatment/{Input,Output}Stream, то даже в Java для этого есть более-менее адекватный вариант - анонимные классы.
В принципе, анонимные классы это почти аналог lisp'овского lambda (и, соответсвенно, Ruby'евских блоков) для многих случаев вполне достаточный.

Код на Питоне собсно говоря вот:

import Tkinter
tk=Tkinter

mw = tk.Tk()
mw.geometry('400x400+0+0')
mw.title('Curves')

canvas = tk.Canvas(master=mw, width=400, height=400)
canvas.pack(side=tk.TOP, fill=tk.BOTH, expand=1)
points=[]
for i in range(...blabla...):
	#....blabla some calcs
	if len(points) == 3:
		canvas.create_line(...blabla all options...)
mw.mainloop()

Я не углублялся в математику (сорри, времени маловато) поэтому вычисления просто пропустил, но поверьте они не сложные для Питона. :) что же касается самого примера - то он явно невдалый, ибо контент Тк канвы - это не виджеты в строгом смысле слова. Возможно, я пропустил "что-то" из синтаксиса Руби, в чем и заключался прикол? Ну не знаю. Единственное, что пример показывает, так это непрозрачность синтаксиса. Кстати, если вот таки вот образом баловаться с реальными виджетами - из этого ничего хорошего не выйдет. Для нормальной и полноценной проги, легко дополняемой и доступной рефакторингу, виджеты должны быть организованы в строгую объектную структуру, а не вываливаться гамузом в итерайшине. И это не прикол Питона, а требование ОО.

Насчот "Бох Гвидо" - явно перебор :) Среди питонщиков не встречал фонатегов, типа слаковых. Что касается меня, то на работе я педалю на джаве, а дома стараюсь заюзать положительный опыт джавы (ну не будете вы же отрицать, что армия джавистов накопила массу экспириенса и паттернов в OO) в переложении на Питон, с учетом возможностей последнего (множественное наследование и т.п.).

#!/usr/bin/env python

import Tkinter
from math import pi, sin, cos

def frange(i, end, step=1):
    while i <= end:
        yield i
        i += step

root = Tkinter.Tk()
root.title('Curves')
root.geometry('400x400')
canvas = Tkinter.Canvas(root)
canvas.pack(side='top', fill='both', expand='yes')
points = []
for scale in frange(10, 30):
    for i in frange(0, 2 * pi, 0.1):
        new_x = 5 * scale * sin(i) + 200 + scale * sin(i * 2)
        new_y = 5 * scale * cos(i) + 200 + scale * cos(i * 6)
        points.append((new_x, new_y))
        f = scale / 5.0
        r = (sin(f) + 1) * 127.0
        g = (cos(2 * f) + 1) * 127.0
        b = (sin(3 * f) + 1) * 127.0
        col = '#%02x%02x%02x' % (r, g, b)
        if len(points) == 3:
            canvas.create_line(
                    points[0][0], points[0][1],
                    points[1][0], points[1][1],
                    points[2][0], points[2][1],
                    smooth='on',
                    width=7,
                    fill=col,
                    capstyle='round'
                    )
            del points[0]
Tkinter.mainloop()

В чём глубокий смысл конструкций типа a.do |foo| {bar}, я не понимаю. Зато недостатки сразу бросаются в глаза: они порождают лишние уровни вложенности и затрудняют рефакторинг. Я понимаю и разделяю вашу любовь к ФП, но совать его везде - фонатство и луговщина. :D И что забавно, код на Питоне выглядит более декларативно, чем ваша лапша на Руби. :P

РЕШПЕКТ за конечное решение! :) А код явно читабельнее и понятнее чем рубивский ;)

>ООП, который в Руби на порядок лучше реализован, чем в Питоне.

А ну позорище на рельсах, раскрой тему "паршивости OO" в Пистоне :D Чем же тебе Змей не угодил? Рельсов не хватает?

> РЕШПЕКТ за конечное решение! :) А код явно читабельнее и понятнее чем рубивский ;)

Явно читабельней для _питониста_... Я нормально читаю оба синтаксиса(когда-то учил Питон).

Но ответ я понял, Питон _не_позволяет_ формировать древовидных структур, что и нужно было показать. Вопрос о том, насколько это удобно в каждом конкретном случае и стоит ли это делать не стоит. Я спрашиваю о _возможности_, которой как видно в Питоне НЕТ. (кстати, вам стоит написать создателям в W3C, что они сделали мешанину из открывающих закрывающих тегов в XML/HTML...)

Второе, на вопрос о парных операциях открытия/закрытия файла, базы данных и т.п. я ответа не получил. Эта часть просто игнорируется. Соответственно вывод прост - мозг питониста видит очевидную полезность данной фичи, но не осилив дать достойный ответ просто умалчивает. Ну что же, слив защитан.

Ниже предлагаю разобрать ООПешные возможности Питона. Присоединяйтесь.

> В чём глубокий смысл конструкций типа a.do |foo| {bar}, я не понимаю.

Ты и не можешь их понимать, потому что для понимания нужно прочитать четвертую главу первой части книги "Programming Ruby". Все братва, которая тут мне отписывает, знает только Питон и вообще не знает Руби. Я не являюсь большим знатоком Питона, но классический "Dive in Python" осилил. Вот если бы люди, которые здесь уже проехались по Руби ознакомились бы с хотя бы частью возможностей языка, красноглазия было бы поменьше.

> Зато недостатки сразу бросаются в глаза: они порождают лишние уровни вложенности и затрудняют рефакторинг.

Ты вообще на HTML-е что-то писал? Ты же не говорил, что лишние уровни <div>-ов мешают рефакторингу? Когда нужен еще один уровень, он используется. Когда не нужен, не используется. Не нравится такая вложенность (которая отображает структуру), передавай объекты, чисто в оопе-шном стиле.

Блин, ну почему очевидные вещи не понятны? Руби позволяет сделать аналог HTML-я без дополнительного синтаксиса. Я понимаю, что в примере выше логика смешана с представлением. Это можно и нужно разделить. Но главная суть в том, что это есть маленький DSL. И для него не нужно тянуть внешних парсеров и прочей хрени.

> А ну позорище на рельсах

позорищем можно назвать реализацию ActiveRecord(ORM) в Джанго. Если есть знаток данного фреймворка, с ним и поговорим, а ты видимо таким не являешься.

> раскрой тему "паршивости OO" в Пистоне

1) Нет протектед переменных. 2) Приватные образуются путем подчеркивания переменной 3) Раньше (не знаю, может сейчас пофиксили) при объявлении метода первым атрибутов должне идти self:

def some_method(self, par1, ...):

4) Необходимость делать функции сеттеры/геттеры для доступа к приватным переменным.

Есть класс Test. У него есть приватный атрибут name (тут все я вижу очень ООПэшные, ну так в ООП первым делом считается что паблик атрибуты есть зло). Напиши мне как будет выглядеть класс Test с возможностью чтения/записи атрибутов. Ниже код на Руби:

class Test

attr_accessor :name

end

После _внятного_ (без пропускания пунктов) ответа на все пункты перейду дальше.

Респект. Cris - супербизон. Питон лучше прочих P, но видать Ruby заменит их всех. кстати и буква следующая :) А вы кстати не занимались Eiffel'ем? я вот уже стал подумывать о его использовании вместо Сей...

> Напиши мне как будет выглядеть класс Test с возможностью
чтения/записи атрибутов.

Опять подставился! :P На питоне это выглядит так:

class Test:
    pass

:D

> Опять подставился! :P На питоне это выглядит так:

> class Test:
>    pass

Ага, так и запишем, pass в Питоне объявляет _приватную_ переменную name. И создает для нее сеттеры/геттеры. Ниче так роздал.

> А вы кстати не занимались Eiffel'ем? я вот уже стал подумывать о его использовании вместо Сей

Не :), Eiffel не использовал, я больше по скриптовым языкам.

> Ага, так и запишем, pass в Питоне объявляет _приватную_ переменную name.

Не юродствуй. Приватная переменная с пустым сеттером и пустым геттером - редкостный цирк. Ты сейчас будешь говорить что это тру ООП, а я говорю, что в таких случаях тебе просто нужна _публичная_ переменная без лишней шелухи. А если тебе потом надо будет сделать её приватной и обернуть сеттерами-геттерами, property тебе в помощь (за деталями - в мануал). Всё-то вы любите ставить с ног на голову, фонатеги.

> Питон лучше прочих P, но видать Ruby заменит их всех.

Ne zamenit. Slishkom musora v nem mnogo uzhe sejchas, a k versii 3-4 eto budet nastoyashij INTERCAL. :)