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

Я это делал для весьма разнообразной категории численных методов (и не только численных). Задача тривиальная, если целевой код - Фортран + MPI.

Сдаётся мне, что ты или говно, или тролль.

>Template Haskell, допустим. Не так они часто и нужны, эти ваши DSL

какое отношение TH имеет к DSL'ям? eDSL'и на Haskell и без него пишутся на ура, TH там только для оптимизации применяется. для DSL он вообще нафиг не нужен: есть Parsec, Alex/Happy и иже с ними

>Допустим, оно не очень-то применимо на практике

вполне он применим. и достаточно удобен

>Преимущества Лиспа проявляются как раз таки только на больших задачах. Там, где есть смысл в разработке DSLей. В общем, Лиспа ты просто не понял...

DSL и rule-engines я как-раз и пишу, но парсинг я стараюсь делать сам, всё контролируя. Для DSL есть ANTLRы и прочие. И могу сказать что руль-енджин над большим количеством правил, даже с рете-алгоритмами - намного медленнее (тестировался jboss-rule-engine), чем написанный на Ц, строго под задачу кастом-руль-енджин (знающий бизнес-логику, структуру данных итд). А главное - намного более предсказуемый (любой black-box непредсказуем).

anonymous, what are you doing here? go fuck your language of choice. Don't mess with us, lispers. We are celebrating and having fun down here.

> Чувак ты удивишься, в лиспе тоже есть профайлеры, а коммерческие компиляторы генерят бинарный код такой же быстрый как и С.

на искуственных или отдельных задачах.

> Для DSL есть ANTLRы и прочие.

Язык - это далеко не только парсер.

> И могу сказать что руль-енджин над большим количеством правил, даже с рете-алгоритмами - намного медленнее (тестировался jboss-rule-engine), чем написанный на Ц, строго под задачу кастом-руль-енджин (знающий бизнес-логику, структуру данных итд).

Когда ты говоришь, мне кажется, что ты бредишь. Сравниваешь жабку с Си, а мы тут про Лисп говорим. Лисп, в отличии от двух других, даёт одно важное преимущество - компилятор на халяву. Транслируешь свой DSL в Лисп, а об остальном можно не заботиться.

> А главное - намного более предсказуемый (любой black-box непредсказуем).

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

> Deep Space 1 launched from Cape Canaveral on October 24, 1998. During a highly successful primary mission, it tested 12 advanced, high-risk technologies in space. In an extremely successful extended mission, it encountered Comet Borrelly and returned the best images and other science data ever from a comet. During its fully successful hyperextended mission, it conducted further technology tests. The spacecraft was retired on December 18, 2001.

всё остальное написано на Ц ;)

Я уже могу в нём синтаксически не различать макры и функции?

Я уже могу внутри макры вставить что либо отличное по синтаксису от Хаскелля?

Если на оба вопроса ответы "нет" (я знаю ответы - сам TH активно использую), то он пока ещё и близко не может сравниваться с Лиспом.

> DSL и rule-engines я как-раз и пишу, но парсинг я стараюсь делать сам, всё контролируя. Для DSL есть ANTLRы и прочие. И могу сказать что руль-енджин над большим количеством правил, даже с рете-алгоритмами - намного медленнее (тестировался jboss-rule-engine), чем написанный на Ц, строго под задачу кастом-руль-енджин (знающий бизнес-логику, структуру данных итд). А главное - намного более предсказуемый (любой black-box непредсказуем).

Пишете на С - чудесно, вам платят за это деньги - еще лучше!

Только не надо говорить, что у вас конфетка, а у других ...

К сведению в Lisp DSL копилируется, что весьма проблематично реализовать на C или Java.

>Я уже могу в нём синтаксически не различать макры и функции?

поясни, будь добр, что ты тут имеешь в виду. макр в хаскеле вообще нет, TH оперирует обыкновенными функциями в соответствующей монаде

>Я уже могу внутри макры вставить что либо отличное по синтаксису от Хаскелля?

ещё раз, какие к чёрту макры и при чём тут синтаксис?

>я знаю ответы - сам TH активно использую

извини, не верю

я тот анонимус - который такого и говорит. я - за процедуральное программирование, в отличие от декларативного (для сложныз задач).

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

> поясни, будь добр, что ты тут имеешь в виду. макр в хаскеле вообще нет, TH оперирует обыкновенными функциями в соответствующей монаде

Нет, это именно макры. Макры в лиспе, знаешь ли, тоже "обыкновенные функции", вот только выполняются они, как и в TH, во время компиляции.

Я говорю про $( ... ), и вот как раз это уродство средствами самого TH спрятать нельзя.

> ещё раз, какие к чёрту макры и при чём тут синтаксис?

При том, что в Лиспе макра может оперировать любым S-выражением внутри. Это весьма большая степень свободы. Тогда как внутри $( ... ) должен быть всё тот же самый Хаскелль, что ограничивает существенно класс встраиваемых языков.

> извини, не верю

А вот это зря.

> я - за процедуральное программирование,

Нет такого термина, деточка.

> в отличие от декларативного

Ты бы сначала узнал, что такое декларативное программирование, ага.

спасибо за линк, почитаю

>Если я не ошибаюсь, амерские военные за все это время, сертифицировали только 2 языка - лисп и аду.

Неужели Jovial http://ru.wikipedia.org/wiki/JOVIAL не сертифицировали? Как же их самолёты летают? :)

P.S. Кстати в январе 2009г. Jovial тоже отметит 50-летие.

>Нет, это именно макры

макры в CL, насколько я знаю, не совсем обычные функции - хотя бы из-за аппликативности параметров. в Haskell'е же они действительно ничем не отличаются от всех остальных функций

>Я говорю про $( ... ), и вот как раз это уродство средствами самого TH спрятать нельзя

а зачем его прятать? macroexpand, хорошо читаемый, в чём уродство-то?

>При том, что в Лиспе макра может оперировать любым S-выражением внутри. Это весьма большая степень свободы. Тогда как внутри $( ... ) должен быть всё тот же самый Хаскелль, что ограничивает существенно класс встраиваемых языков

офигенная аргументация. всё равно что сказать "в LISP'е макра оперирует самим LISP'ом внутри, а в TH всего лишь Haskell'ем". проблемы тут не от ограничений языка, а от кривости рук. имхо

>А вот это зря

сам виноват :) теперь верю, однако судя по всему использование оставляет желать лучшего - тебе нужен CL, а его в TH, естественно, нет

да конечно, хочешь сказать, что стандартная библиотека С верх совершенства, достало ламерье, честное слово.

50 лет со дня фактической смерти может.

кстати да, протестую - LISP был всегда, 50 лет назад его просто открыли :)

> макры в CL, насколько я знаю, не совсем обычные функции - хотя бы из-за аппликативности параметров.

В CL макра - это функция (sexpr -> sexpr), то бишь, с одним параметром.

defmacro - это просто синтаксический сахар.

> а зачем его прятать? macroexpand, хорошо читаемый, в чём уродство-то?

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

> офигенная аргументация. всё равно что сказать "в LISP'е макра оперирует самим LISP'ом внутри, а в TH всего лишь Haskell'ем".

Да, именно это я и сказал. А теперь сравни сложность СИНТАКСИСА Лиспа и Хаскелля. В синтаксис Лиспа легко можно воткнуть очень много всякого, что Лиспом ни разу не является. В Хаскелль же - тоже можно, но это будет очень костылисто и коряво, просто от того, что синтаксис сложный.

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

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

> тебе нужен CL, а его в TH, естественно, нет

Мне не нужен CL. Мне надо писать eDSL-и. С как можно более произвольным синтаксисом.

> Если я не ошибаюсь, амерские военные за все это время, сертифицировали только 2 языка - лисп и аду.

Ты ошибаешься :D

>> я - за процедуральное программирование, >Нет такого термина, деточка.

а нас, дедуля, учили что есть. И что SQL, PROLOG и LISP к ним не относятся.

>> в отличие от декларативного >Ты бы сначала узнал, что такое декларативное программирование, ага.

да пошёл ты. На таком уровне общаться не интересно. Выучи и поработай на языках 8-10 сначала, потом учить будешь. happy hacking lisp ;)

> а нас, дедуля, учили что есть. И что SQL, PROLOG и LISP к ним не относятся.

Убей то ничтожество, которое тебя учило. За издевательство над родным языком и за нелепые кальки надо убивать.

Кроме того, дебильная деточка, Лисп - 100% императивный язык. Но ты, деточка, по причине крайне низкого IQ и слишком высокого самомнения, этого то и не знаешь. Больной ты, деточка, на всю головушку больной.

> Выучи и поработай на языках 8-10 сначала, потом учить будешь.

Я реализовал больше языков, чем ты, деточка, знаешь.

У тебя нет ни малейшего представления о том, что такое декларативные языки. Тот же Antlr, ранее тобой помянутый, это декларативный язык. Make - декларативный язык. Препроцессор Си - декларативный язык. Продолжать список?

>Личные предпочтения

ключевая фраза обсуждения. один только вопрос: зачем ты тогда TH используешь, если нужен тебе именно CL?

>Да, именно это я и сказал. А теперь сравни сложность СИНТАКСИСА Лиспа и Хаскелля. В синтаксис Лиспа легко можно воткнуть очень много всякого, что Лиспом ни разу не является. В Хаскелль же - тоже можно, но это будет очень костылисто и коряво, просто от того, что синтаксис сложный

то, что в синтаксис Haskell'я втыкается хорошо - реализуется как eDSL (прекрасные примеры - Parsec и Yampa, легли как так и надо); то, что втыкается плохо - реализуется как DSL, на Haskell'е пишется транслятор (хоть в тот же CL, хоть в .Net IL, да хоть и компиляцию в ассемблерные инструкции). в конце-концов, "синтаксис - ничто, семантика - всё". возможно тому виной мой малый опыт в этой области, но я пока не сталкивался с задачами, для решения которых мне бы пришлось отказаться от Haskell'я в пользу CL в вопросах DSL-ориентированного проектирования. если у тебя есть примеры задач, в которых описанные преимущества CL критичны - прошу приведи их, с удовольствием поломаю над ними мозг

>Просто результат для TH будет сильно более корявым и костыльным, в силу вышеизложенных ограничений языка

TH это в любом случае костыль - так же, как и Meta OCaml; так же, как и шаблонное метапрограммирование в C++. просто в CL проектирование на основе DSL'ей завязано на макрах, и на трансляции иерархий DSL'ей в компайл-тайм; в Haskell'е не эти механизмы являются основными

>Мне не нужен CL. Мне надо писать eDSL-и. С как можно более произвольным синтаксисом

вопрос номер один: почему именно embedded? вопрос номер два: чем, в таком случае, тебя не устраивает CL? писал бы на нём...

> ключевая фраза обсуждения. один только вопрос: зачем ты тогда TH используешь, если нужен тебе именно CL?

Haskell хорош. Во многом очень хорош. Часто именно на нём задача решается наиболее адекватным способом. И обидно, когда в той же задаче необходима реализация eDSL, и ограничения TH портят жизнь.

Кроме того, ты же сам не далее как несколько мессаг назад позиционировал TH как полноценную альтернативу CL?

> то, что втыкается плохо - реализуется как DSL

На каждое маленькое выражение eDSL - отдельный файл или текстовая константа? Не очень то весело.

> но я пока не сталкивался с задачами, для решения которых мне бы пришлось отказаться от Haskell'я в пользу CL в вопросах DSL-ориентированного проектирования

Эффективность - не самая сильная сторона Haskell. Про синтаксические проблемы я уже говорил. Так же, сложно (хоть и возможно) реализовывать eDSLи с существенно отличной от Хаскеллевой системой типов.

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

Например, встраиваемый декларативный язык для описания формата двоичных файлов и протоколов. Должен транслироваться в максимально эффективный код, синтаксис желательно как можно более похожий на ASN.1. На CL весьма легко, на TH уже не так просто.

> в Haskell'е не эти механизмы являются основными

А другие механизмы неэффективны, и потому не всегда практичны, увы.

> вопрос номер один: почему именно embedded?

Выражения на eDSL коротенькие. Отдельный файл для них держать неудобно.

> вопрос номер два: чем, в таком случае, тебя не устраивает CL? писал бы на нём...

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

> Про свои задачи не буду, укажу лучше на известные и крупные: та же неоднократно тут упоминавшаяся Maxima, например. Очень типичный пример заточенного сугубо под задачу DSL. Лиспа там ровно столько, сколько надо для реализации DSL, всё остальное реализовано уже на нём.

Максима не интересно. И Mathematica и Maple ее заруливают. А вот сколько на чем написано в них знаешь? Почему?

> Максима не интересно. И Mathematica и Maple ее заруливают.

В моих задачах не заруливают ни разу.

> А вот сколько на чем написано в них знаешь? Почему?

У них точно такая же архитектура - DSL, вокруг которого уже выстраивается вся основная логика.

Вот и vsl подтянулся... ща холиварить будут.

>Кроме того, ты же сам не далее как несколько мессаг назад позиционировал TH как полноценную альтернативу CL?

нет. это ты меня с кем-то спутал. мои тезисы: TH не обязателен для DSL-ориентированного проектирования вообще, TH пригоден для использования. сравнения с CL не было

>На каждое маленькое выражение eDSL - отдельный файл или текстовая константа? Не очень то весело

странная архитектура получается. зачем заводить eDSL для семантики, встрачающейся в маленьких выражениях? даже если они маленькие, но их много - уже повод вынести её в отдельный полноценный язык. если их мало - то какая разница, какой там будет синтаксис? да и вообще, чем так существеннен синтаксис для eDSL? я понимаю DSL, которым будет пользоватся непрограммист (ну или специалист смежной области), но тут?

>Так же, сложно (хоть и возможно) реализовывать eDSLи с существенно отличной от Хаскеллевой системой типов

ну, с этим в любом статически типизированном языке приходится мириться. за всё надо платить

>Например, встраиваемый декларативный язык для описания формата двоичных файлов и протоколов. Должен транслироваться в максимально эффективный код, синтаксис желательно как можно более похожий на ASN.1. На CL весьма легко, на TH уже не так просто

спасибо, буду подумать

поздравления

> Лисп идеально подходит как раз для оптимизации численного алгоритма аналитическими методами и генерации оптимального кода (хоть даже и на ассемблере, если не на Фортране) из него для дальнейших численных рассчётов.

Не поделитесь ссылками на примеры?

Поздравления лисперам!

Думаю, чего реально не хватает старым языкам так это их полного пересмотрения. Не нужно ИМХО плодить новые языки (разве что - для новых парадигм), а лучше пересмотреть стандарты, подправить, сделать логичнее, добавить то, чего не хватало, переосмыслить и переписать библиотеки соответственно теперишним возможностям. Чисто ИМХО

Re

1. 50 лет = не хухры. +1 к поздравлениям...

2. В принципе, в Лисп можно было бы добавить альфа-конверсию лямбда-исчисления... Но зачем такое большое изменение? ;-) Уж лучше маленький парсер грамматик 1 класса )))

>>Например, встраиваемый декларативный язык для описания формата двоичных файлов и протоколов. Должен транслироваться в максимально эффективный код, синтаксис желательно как можно более похожий на ASN.1. На CL весьма легко, на TH уже не так просто
>спасибо, буду подумать

на форте тоже относительно просто http://savingtheinternetwithhate.com/stackish.html
//другой anonymous

; The Lisp defined in McCarthy's 1960 paper, translated into CL.
; Assumes only quote, atom, eq, cons, car, cdr, cond.
; Bug reports to lispcode@paulgraham.com.

(defun null. (x)
(eq x '()))

(defun and. (x y)
(cond (x (cond (y 't) ('t '())))
('t '())))

(defun not. (x)
(cond (x '())
('t 't)))

(defun append. (x y)
(cond ((null. x) y)
('t (cons (car x) (append. (cdr x) y)))))

(defun list. (x y)
(cons x (cons y '())))

(defun pair. (x y)
(cond ((and. (null. x) (null. y)) '())
((and. (not. (atom x)) (not. (atom y)))
(cons (list. (car x) (car y))
(pair. (cdr x) (cdr y))))))

(defun assoc. (x y)
(cond ((eq (caar y) x) (cadar y))
('t (assoc. x (cdr y)))))

(defun eval. (e a)
(cond
((atom e) (assoc. e a))
((atom (car e))
(cond
((eq (car e) 'quote) (cadr e))
((eq (car e) 'atom) (atom (eval. (cadr e) a)))
((eq (car e) 'eq) (eq (eval. (cadr e) a)
(eval. (caddr e) a)))
((eq (car e) 'car) (car (eval. (cadr e) a)))
((eq (car e) 'cdr) (cdr (eval. (cadr e) a)))
((eq (car e) 'cons) (cons (eval. (cadr e) a)
(eval. (caddr e) a)))
((eq (car e) 'cond) (evcon. (cdr e) a))
('t (eval. (cons (assoc. (car e) a)
(cdr e))
a))))
((eq (caar e) 'label)
(eval. (cons (caddar e) (cdr e))
(cons (list. (cadar e) (car e)) a)))
((eq (caar e) 'lambda)
(eval. (caddar e)
(append. (pair. (cadar e) (evlis. (cdr e) a))
a)))))

(defun evcon. (c a)
(cond ((eval. (caar c) a)
(eval. (cadar c) a))
('t (evcon. (cdr c) a))))

(defun evlis. (m a)
(cond ((null. m) '())
('t (cons (eval. (car m) a)
(evlis. (cdr m) a)))))

; The Lisp defined in McCarthy's 1960 paper, translated into CL.
; Assumes only quote, atom, eq, cons, car, cdr, cond.
; Bug reports to lispcode@paulgraham.com.

(defun null. (x)
  (eq x '()))

(defun and. (x y)
  (cond (x (cond (y 't) ('t '())))
        ('t '())))

(defun not. (x)
  (cond (x '())
        ('t 't)))

(defun append. (x y)
  (cond ((null. x) y)
        ('t (cons (car x) (append. (cdr x) y)))))

(defun list. (x y)
  (cons x (cons y '())))

(defun pair. (x y)
  (cond ((and. (null. x) (null. y)) '())
        ((and. (not. (atom x)) (not. (atom y)))
         (cons (list. (car x) (car y))
               (pair. (cdr x) (cdr y))))))

(defun assoc. (x y)
  (cond ((eq (caar y) x) (cadar y))
        ('t (assoc. x (cdr y)))))

(defun eval. (e a)
  (cond
    ((atom e) (assoc. e a))
    ((atom (car e))
     (cond
       ((eq (car e) 'quote) (cadr e))
       ((eq (car e) 'atom)  (atom   (eval. (cadr e) a)))
       ((eq (car e) 'eq)    (eq     (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'car)   (car    (eval. (cadr e) a)))
       ((eq (car e) 'cdr)   (cdr    (eval. (cadr e) a)))
       ((eq (car e) 'cons)  (cons   (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'cond)  (evcon. (cdr e) a))
       ('t (eval. (cons (assoc. (car e) a)
                        (cdr e))
                  a))))
    ((eq (caar e) 'label)
     (eval. (cons (caddar e) (cdr e))
            (cons (list. (cadar e) (car e)) a)))
    ((eq (caar e) 'lambda)
     (eval. (caddar e)
            (append. (pair. (cadar e) (evlis. (cdr e) a))
                     a)))))

(defun evcon. (c a)
  (cond ((eval. (caar c) a)
         (eval. (cadar c) a))
        ('t (evcon. (cdr c) a))))

(defun evlis. (m a)
  (cond ((null. m) '())
        ('t (cons (eval.  (car m) a)
                  (evlis. (cdr m) a)))))

посмотрел дёмку с http://subtextual.org/ и подумал: было бы неплохо такой режим к емаксу прикрутить, эти schematic table

Что это за крокозябры ? Дружище у тя что то с кодировкой ? Что то я кода не вижу :)

Юбилей, можно сказать.. Снимаем шляпы..

> посмотрел дёмку с http://subtextual.org/ и подумал: было бы неплохо такой режим к емаксу прикрутить, эти schematic table

Я тоже немного посмотрел и так и не понял в чем profit. По моему все это быстрее и понятнее текстом написать, а так мышевазюканье какое-то.

И то!!!

Уж и не знаю... Почти 20 лет пописываю на Lisp (то, что для других ЯП не очень или не совсем... э-э-э... благополучно), и? Lisp - наше всё, как здесь принято говорить! ;-)

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

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

Например на лисп не пишут корпоративные информационные системы (КИС) - их пишут на Java.
На лисп не пишут операционные системы - их пишут на Си.
На лисп не пишут компиляторы Си++, Фортран и Ада - их пишут на си.
На лисп не пишут игры - их пишут на Си и Си++.
На лисп не пишут десктопные приложения - их пишут на Си, Си++, Python, Java, C#/Mono.
На лисп не пишут вебсайты - их пишут на PHP, Perl, Python и Ruby.
На лисп не делают параллельные вычисления на кластерах - их пишут на Фортране и Си, с использованием MPI.

Складывается впечатление что лисп сегодня - это встроенный скриптовой микроязычок для автокада, емакса и максимы, и еще для каких-то абсолютно нишевых решений (типа какой-то мелочевки для самолетов, что процитировал Sun-ch). По крайней мере хваленые "аналитики ЛОР" ничего вразумительного привести не смогли.

Предвосхищая ответы в духе "миллионы мух выбирают..." и "на лисп не программируют боги, а не быдлокодеры" замечу. Так называемые "миллионы мух" (в данном случае - разработчики, архитекторы и технологи) делают выбор инструмента руководствуясь чисто экономическими принципами. Инструмент должен решать задачу, минимизируя отношение цена/качество. Можно даже так сказать, технолог не выбирает инструмент сам, за него это как бы делает окружающая его экономика, большой и мудрый макроорганизм. Давайте ради интереса посчитаем, сколько (по времени и по затратам) займет разработка типовых проектов (из вышеперечисленного) на лисп и на традиционном для задачи языке. А потом сравним.

Результат будет весьма недвусмысленным. Лисп как промышленная технология для широкой области применения - экономически несостоятелен. Его удел - чисто академические проекты и узкие нишевые решения. Вы согласны с этим? Спасибо.

Наконец-то, а то я тут один пока вахту держу и не справляюсь :)

2 anonymous (*) (21.10.2008 0:58:20)

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

Эх-х... Каждый ЯП преднзазначался для определённой (причём, вполне) области его, языка, применения. Ну, не надо искать язык, способный Вас выручить во всех случаях жизни... :-)

> anonymous (*) (21.10.2008 1:01:30)

Обогнал, однако. :-)))

Поздравляем всех математиков и профессоров компьютерных наук с их языком!
И их студентов, конечно-же!

Как Вы помните, камрад Бэкус, "отец", что-ли, императивного стиля программирования ("слово-за-шаг") на вручении премии Тьюринга очень горевал, что создавал Фортран (читать: Си + его отродья, Джабу + ее отродья, Паскаль+отродья, ПХП, Тикль, Ейфель, Перл итд). Наверное ж неспроста, а? Ну, понятное дело, этот красноглазик-ботаник не просекал всю мощь будущих С++/Java...

>Почему лисп при всем его заявляемом превосходстве занимает такую узкую нишу.

потому что поддерживать нельзя. Завязанность всего бизнеса на гения, который налабал 4-этажную функцию, а потом сам запутался (при рефакторинге).
Вместо того - чтобы нанять пару индусов и с дебаггером вперёд. До вечера или следующего четверга - баг можно найти и залатать.