Неосилятор ищет язык.

> Совершенно не очевидно. Пруф в студию.

Например, SBCL. Но, кстати, очевидно.

Ну вот, есть люди, которые с этим не согласны. С нетерпением ждём аргументации и запасаемся попкорном.

> Торвальдс хорошо по этому поводу высказался

Торвальдсу хорошо, у него там армия.

> Ну вот, есть люди, которые с этим не согласны.

Кто? Под аргументы Торвальдся идеально подходит Python, одна беда - на Python нельзя писать ядро. Хватит тупить уже.

> Например, SBCL

Ок, принято. Еще?

Но, кстати, очевидно.

Нет же.

> Кто?

Ты. Сюрприз-сюрприз!

> Я с этим нисколько не спорю. Вопрос только в том, когда именно эти затраты производятся - до коммита, или после.

Ну и что что они производятся после коммита?

> Под аргументы Торвальдся идеально подходит Python

«the choice of C is the only sane choice.» (c) Torvalds :)

> «the choice of C is the only sane choice.» (c) Torvalds :)

Вместо Torvalds вполне можно было поставить К.О.

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

> Ну и что что они производятся после коммита?

Т.е. такого персонажа как «пользователь» ты применительно к ПО в расчет не берешь? Может всё таки подумаешь головой, в чём разница?

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

громкое заявление, но пока такие фанатики пишут лучшие решения для того же линукса( ОС в целом ) - в программировании им определенно есть место

В любом случае подобные «ошибки» доходят до коммита чрезвычайно редко и на 1 такую придется сотня ошибок в логике, которые статическая типизация не отловят. Если бы статическая типизация ничего не стоила - тут конечно другой разговор, но за нее ведь приходится расплачиваться. И тут уже встает вопрос что ценнее.

> громкое заявление, но пока такие фанатики пишут лучшие решения для того же линукса( ОС в целом ) - в программировании им определенно есть место

Можно несколько примеров написанного на макроассемблере прикладного софта за последние 10 лет?

> на 1 такую придется сотня ошибок в логике

Верно.

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

Тоже верно.

Мой поинт в том, что судя по индустрии ПО в целом на большинстве задач общего характера динамика обходится дороже. Исключение пока что только веб малого и среднего размера.

> Можно несколько примеров написанного на макроассемблере прикладного софта за последние 10 лет?

thunderbird, transmission, SQLite, AbiWord, GNOME( лет 10 назад и «начался» ), pulseaudio, unity и т.д. и т.п., в принципе за примерами далеко ходить не надо - можно посмотреть список пакетов

> Мой поинт в том, что судя по индустрии ПО в целом на большинстве задач общего характера динамика обходится дороже.

Индустрия непоказательна, т.к. динамика относительно недавно достигла достаточной производительности, чтобы на ней можно было писать что-то кроме факториалов. + есть же soft typing (обычная статика работает по принципу «ошибка, если не могу доказать корректность», а soft typing - «ошибка, если не могу доказать некорректность» и он применим к любому динамическому языку) с полным выводом типов легко отловят почти все подобные ошибки, и останется только жалкий процент из разряда «после дождичка в четверг», на который уж точно можно будет не обращать внимания.

А ты уверен что это все написано на чистом си? Разве что sqlite с gnome. Но gnome вроде не только на си.

> «ошибка, если не могу доказать некорректность»

«могу доказать некорректность» selffix

> это все написано на чистом си? Разве что sqlite с gnome. Но gnome вроде не только на си.

не 100%, в том же thunderbird C++ используется рядом с С, abiword на С, pulseaudio на С, дальше не стал смотреть - но в принципе там, если и не целиком на С, то с использованием разве-что С++, а он по-сути такой же макроассемблер

Питух, показывай код, который ты писал, показывай свои крупные проекты.
Или не крути жопкой как tia.

>И какой профит в возможности написания заведомо некорректного кода?

Что в нем некорректного? То, что в шарпе так нельзя и средством реализации параметрического полиморфизма выступает копипаст? Если тебя именно синус беспокоит тут, я тебе другой пример приведу. Косяки шарпа так просто не замазать.

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

Если бы ты за лисп агитировал, я бы смиренно принял упреки по поводу метапрограммирования. Но от апологета шарпа, в котором метапрограммирование отсутствует как класс и чуть что - рефлекшеном надо обмазываться, все это звучит неубедительно.

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

Ты тоже посмотри код с линиями и точками выше. Там полноценность во всей красе.

>Тебе 2 рубля жалко?

Чтобы поставить нескучный калькулятор на WPF, пользователь должен будет в предельном случае еще 2Гб докачать. Расскажи ему о 2-ух рублях.

>Можно.

class SomeName<T> where T : struct {}

VS2010 не дает так сделать. Это моновская фича? Заодно поясню, что просто ValueType для галочки не нужен. Я хочу иметь возможность написать класс куба данных, который потом буду параметризовать int, long, float, double. Внутри должна быть всякая математика, но я даже сложить или умножить элементы шаблона не могу. Или там Math.sqrt использовать. Какие я должен наложить ограничения или мне надо копипастить код?

Невозможно передать число

Это уже метапрограммирование.

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

Да, generic'и для них не предназначены, есть более другие средства.

Какие в C# есть средства для метапрограммирования?

> Что в нем некорректного?

То, что он некорректный. С какого хера ты применяешь sin к объекту, для которого этот sin возможно не определен?

То, что в шарпе так нельзя и средством реализации параметрического полиморфизма выступает копипаст?

Именно потому, что в шарпе так нельзя, говорит о том, что данная реализация - НЕ копипаст. Именно потому, что в с++ так можно, говорит о том, что в с++ - это копипаст. И что параметрический полиморфизм на темплейтах сделать невозможно.

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

То есть объективные факты меняются в зависимости от того, какой язык я предпочитаю? Если я лиспер - темплейты убого средство метапрограммирования, если я люблю сишарп - ВНЕЗАПНО отличное, так что ли?

Но от апологета шарпа, в котором метапрограммирование отсутствует как класс

В .net есть немерле, и f# (по части который комментарии не требуются, я полагаю), в самом сишарпе есть linq, который основан на метапрограммировании, и возможность работы с синтаксическим деревом. В с++ есть только убогие темплейты, которые называть полноценной возможностью метапрограммирования может только упоротый фанбой с промытыми Александреской мозгами.

Ты тоже посмотри код с линиями и точками выше. Там полноценность во всей красе.

Где именно? Когда чекер плюсов научится проверять тип темплейтов, выводить нормально полиморфный аргумент, когда можно будет делать аналог полиморфных лямбды - тогда и поговорим.

> 2Гб докачать.

У тебя платный трафик?

>Рефлексия. Так что ничего удивительного, что компилятор пропустил.

Так меня сам компилятор и вынудил рефлексию использовать, я не специально вредил. Он не дает никакой возможности создания объектов с нетривиальными конструкторами внутри дженериков. Если я хочу напрямую передать параметры в конструктор создаваемых объектов и предпочитаю immutable-объекты, то я не знаю возможности _не_ использовать активатор со всеми его граблями. Научи как.

Что-то не понял. Можешь пояснить свой код? С твоими изменениями проблема продолжает проявляться:

Извиняюсь, говорю об одном, пишу другое. Но принцип тот же сохраняется: затруднить работу с методом, чтобы случайно нельзя его было использовать. Такой код не скомпилится: http://codepad.org/3FRoGqT0

Не удивительно, ибо int? — value-type. А для них для каждого создается отдельный instance (по понятным, думаю, причинам).

int? - reference-type. Но выражение в силе.

Для каких типов в C++ создается 1 инстанс?

Для указателей (мы про инстанс метода? типы-то в общем случае не кладутся в нативный код).

Сорцы в руки и вперед. Если это реализовано в MS CLR, можно сделать и в Mono. Не так там все страшно, в конце-концов.

Ну так реализовал кто-нибудь уже? С введения дженериков годы прошли.

По сравнению с чем?

Ну шутауте можно ознакомиться со списком. Выбери «which fastest». Его делают не только «переносимые ассемблеры», но и более высокоуровневые языки.

Прошу ссылку на описание утечек.

http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html

> Какие в C# есть средства для метапрограммирования?

Expressions.

>VS2010 не дает так сделать. Это моновская фича?

Нет, .NET'овская. http://msdn.microsoft.com/en-us/library/d5x73970.aspx Правда внезапно она не работает с Nullable<T>.

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

Ладно, засчитываем в недостатки generics (я бы даже сказал «недоработки»)

Какие в C# есть средства для метапрограммирования?

Expressions есть. Ну и System.Reflection.Emit никто не отменял.

>Так меня сам компилятор и вынудил рефлексию использовать, я не специально вредил. Он не дает никакой возможности создания объектов с нетривиальными конструкторами внутри дженериков. Если я хочу напрямую передать параметры в конструктор создаваемых объектов и предпочитаю immutable-объекты, то я не знаю возможности _не_ использовать активатор со всеми его граблями. Научи как.

Я писал, что решения пока не знаю. Буду над ним думать)

int? - reference-type. Но выражение в силе.

Нет. Это value-type. http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx

Такой код не скомпилится: http://codepad.org/3FRoGqT0

Ад какой. Как фикс для небольшого примера сойдет, но делать шаблонами _все_ методы... Имхо это оверхед.

http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html

Boehm GC. Уже не актуально (начиная с 2.10). Надо провести тесты снова.

Ну шутауте можно ознакомиться со списком. Выбери «which fastest». Его делают не только «переносимые ассемблеры», но и более высокоуровневые языки.

Судя по http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest... он не такой уже и тормоз. Между 2.53   и 1.71 (Java -server) не такая и большая разница. А задачи где важен каждый такт никто на нем решать не будет.

Ну так реализовал кто-нибудь уже?

Не смотрел еще.

С введения дженериков годы прошли.

С введения C99 прошло еще больше, а его полностью так нигде и не реализовали ЕМНИП.

[quote]То, что он некорректный. С какого хера ты применяешь sin к объекту, для которого этот sin возможно не определен?[/quote] В нормальных языках, если он не определен, то компилятор об этом скажет. [quote]Именно потому, что в шарпе так нельзя, говорит о том, что данная реализация - НЕ копипаст. Именно потому, что в с++ так можно, говорит о том, что в с++ - это копипаст. И что параметрический полиморфизм на темплейтах сделать невозможно.[/quote] Не жонглируй словами, они стоят дешево. Покажи код, как надо, я же тебя за руки не держу. Мне нужна параметризуемая функция, которая вычислит sin для типа, если он для него определен, а нет - компилятор выдаст ошибку. [quote]То есть объективные факты меняются в зависимости от того, какой язык я предпочитаю? Если я лиспер - темплейты убого средство метапрограммирования, если я люблю сишарп - ВНЕЗАПНО отличное, так что ли?[/quote] Людям с бинарным взглядом на мир сложно что-то объяснить. Но я не сдамся и дам хинт на понятия «лучше»/«хуже». Научить применять их вместо ярлыков «убогий»/«отличный» и все станет намного проще. [quote]В .net есть немерле, и f# (по части который комментарии не требуются, я полагаю), в самом сишарпе есть linq, который основан на метапрограммировании, и возможность работы с синтаксическим деревом.[/quote] Ты просто взял, признал фейл шарпа, как языка, и спрятался за платформу и другие языки. Что касается linq. Как будет выглядеть вычисление чисел фибоначи на линке?

Где именно?

http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6021395

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

Приводи примеры, когда это не дает нормально работать.

Для указателей (мы про инстанс метода? типы-то в общем случае не кладутся в нативный код).

Не обязательно метода. Ну да ладно, начнем с методов:

struct A {};
struct B {};

template <typename T>
T * f(T * value)
{
}

int main()
{
  A a;
  B b;
  
  f(&a);
  f(&b);
  
  return 0;
}

sectoid@nyarly ~ $ g++ tmp.cpp -o tmp-instances
sectoid@nyarly ~ $ nm -C --defined-only tmp-instances 
08049f08 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
08048594 R _IO_stdin_used
080484bc W A* f<A>(A*)
080484c1 W B* f<B>(B*)
08049f00 D __DTOR_END__
0804a014 A __bss_start
0804a00c D __data_start
0804a010 D __dso_handle
08049ef4 d __init_array_end
08049ef4 d __init_array_start
080484d0 T __libc_csu_fini
080484e0 T __libc_csu_init
0804a014 A _edata
0804a01c A _end
08048574 T _fini
08048590 R _fp_hw
08048364 T _init
080483c0 T _start
0804a00c W data_start
08048494 T main

Правда, если собирать с -O2, то компилятор это дело просто проинлайнит. А писать пример, мешающий инлайнить мне лениво.

С классами аналогичная чепуха:

template <typename T>
struct Proof
{
  void ofConcept() 
  {}
};

struct A {};
struct B {};

int main()
{
  Proof<A *> a;
  Proof<B *> b;

  a.ofConcept();
  b.ofConcept();
  return 0;
}

sectoid@nyarly ~ $ g++ tmp.cpp -o tmp-instances
sectoid@nyarly ~ $ nm -C --defined-only tmp-instances 
08049f08 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
08048594 R _IO_stdin_used
080484bc W Proof<A*>::ofConcept()
080484c2 W Proof<B*>::ofConcept()
08049f00 D __DTOR_END__
0804a014 A __bss_start
0804a00c D __data_start
0804a010 D __dso_handle
08049ef4 d __init_array_end
08049ef4 d __init_array_start
080484d0 T __libc_csu_fini
080484e0 T __libc_csu_init
0804a014 A _edata
0804a01c A _end
08048574 T _fini
08048590 R _fp_hw
08048364 T _init
080483c0 T _start
0804a00c W data_start
08048494 T main

>То, что он некорректный. С какого хера ты применяешь sin к объекту, для которого этот sin возможно не определен?

Если он не определен, то компилятор об этом скажет, в чем проблема-то.

Именно потому, что в шарпе так нельзя, говорит о том, что данная реализация - НЕ копипаст. Именно потому, что в с++ так можно, говорит о том, что в с++ - это копипаст. И что параметрический полиморфизм на темплейтах сделать невозможно.

Не жонглируй словами, они стоят дешево. Покажи код, как надо, я же тебя за руки не держу. Мне нужна параметризуемая функция, которая вычислит sin для типа, если он для него определен, а нет - компилятор выдаст ошибку.

То есть объективные факты меняются в зависимости от того, какой язык я предпочитаю? Если я лиспер - темплейты убого средство метапрограммирования, если я люблю сишарп - ВНЕЗАПНО отличное, так что ли?

Людям с бинарным взглядом на мир сложно что-то объяснить. Но я не сдамся и дам хинт на понятия «лучше»/«хуже». Научить применять их вместо ярлыков «убогий»/«отличный» и все станет намного проще.

В .net есть немерле, и f# (по части который комментарии не требуются, я полагаю), в самом сишарпе есть linq, который основан на метапрограммировании, и возможность работы с синтаксическим деревом.

Ты просто взял, признал фейл шарпа, как языка, и спрятался за платформу и другие языки. Что касается linq. Как будет выглядеть вычисление чисел фибоначи на линке?

Где именно?

http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6021395

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

Приводи примеры, когда это не дает нормально работать.

>Нет, .NET'овская. http://msdn.microsoft.com/en-us/library/d5x73970.aspx Правда внезапно она не работает с Nullable<T>.

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

Expressions есть. Ну и System.Reflection.Emit никто не отменял.

Рантайм не интересен, там и так можно что угодно делать, на что хватит фантазии, но там ты типизацию теряешь (см. пример с активатором). Про Expressions не знаю ничего. Можно на нем написать генерацию чисел фибоначи во время компиляции, чтобы представлять, как это выглядит. И входит ли он в моно или это фича фреймворка?

>Nullable не работает, потому что ссылочный тип.

Нет, он не ссылочный. http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx Не работает он потому, что там в M$ решили (ХЗ почему). Ну и можно сделать свой struct Maybe<T>.

Про Expressions не знаю ничего. Можно на нем написать генерацию чисел фибоначи во время компиляции, чтобы представлять, как это выглядит.

В момент компиляции — врядли. А зачем они тебе именно в момент компиляции?

using System;
using System.Linq.Expressions;

public static class Test
{
  public static int Main(string[] argv)
  {
    Expression<Func<int, int, int>> e = (x, y) => x + y;

    // Теперь в e у нас лежит AST этой лябмды (x, y) => x + y;

    // ... Тут делаем с ним что хотим

    var f = e.Compile(); // Компилируем

    Console.WriteLine("RetVal: {0}", f(1, 2)); // ...и вызываем
    return 0;
  }
}

Как-то так.

И входит ли он в моно или это фича фреймворка?

Входит. Вышеприведенный пример у меня работает:

sectoid@nyarly ~ $ dmcs test.cs
sectoid@nyarly ~ $ mono test.exe 
RetVal: 3
sectoid@nyarly ~ $ dmcs --version
Mono C# compiler version 2.10.1.0

> В нормальных языках, если он не определен, то компилятор об этом скажет.

То есть с++ не нормальный язык, раз там об этом не говорят? Какбе что и требовалось доказать, ок.

Мне нужна параметризуемая функция, которая вычислит sin для типа, если он для него определен, а нет - компилятор выдаст ошибку.

Зачем? Нормальный компилятор делает лучше - он сразу дает ошибку, при написании такой функции, а не при ее инстанцировании. Это расширение системы типов - не просто полиморфизм, а полиморфизм с ограниченной квантификацией. Дело все в том, что в этом контексте (если считать темплейты параметрическим полиморфизмом) с++ НЕ является статически типизуремым языком, т.к. полиморфный тип типизируется динамически...

Но я не сдамся и дам хинт на понятия «лучше»/«хуже».

Извини, но темплейты в качестве программирование - не хуже. Они именно что _убоги_. Что значит - огромный разрыв по сравнению с челвовеческими системами метапрограммирования.

Ты просто взял, признал фейл шарпа, как языка, и спрятался за платформу и другие языки.

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

Как будет выглядеть вычисление чисел фибоначи на линке?

Не понял при чем тут факториалы на linq. Ты спросил где метапрограммирования в сишарпе, я привел в пример linq - дсл, написанный при помощи метапрограммирования в сишарпе. Для вычисления факториалов этот дсл не особо предназначен.

http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6021395

Ах, так это был сарказм! Ну надо ставить пометку же. Претензии по этому посту непонятны - сам обошел систему типов, а потом вопит, что она не дала по лбу. Это примерно как написать кусок unmanaged-кода с сегфолтом, а потом кричать «вот какой у вас плохой gc».

Приводи примеры, когда это не дает нормально работать.

«Нормально работать» можно и на брейнфаке, только вот приятнее работать всегда с языком, который предоставляет более широкие возможности, который органично вписываются в язык, а не прилеплены к нему сбоку костылем.

> Можно на нем написать генерацию чисел фибоначи во время компиляции

Зачем во время компиляции вычислять числа Фиббоначчи? И уж точно не следует делать это темплейтами - лучше посчитать самому и подставить в константы, всяко будет быстрее, проще и понятнее. А вообще, все что можно вычислить до рантайма, компилятор и так должен предвычислять во время компиляции, это простейшая оптимизации еще на уровне АСТ.

> Входит. Вышеприведенный пример у меня работает:

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

>Я писал, что решения пока не знаю. Буду над ним думать)

Решение - не передавать параметры напрямую. Т.е. не Line(x1,y1,x2,y2), а Line(a,b). Но это не от красоты и мощи, а от безысходности.

Нет. Это value-type.

Правда. Все позабывал.

Ад какой. Как фикс для небольшого примера сойдет, но делать шаблонами _все_ методы... Имхо это оверхед.

Я это не в качестве универсального решения, а в качестве примера того, что и к неестественным для себя требованиям C++ относится терпимо. Вообще же утиная типизация - фича и ее не надо избегать.

Между 2.53 и 1.71 (Java -server) не такая и большая разница. А задачи где важен каждый такт никто на нем решать не будет.

Ты же в процентах смотри. Он чуть ли не на 50% медленнее джавы. Даже паскаль и луа его обогнали.

С введения C99 прошло еще больше, а его полностью так нигде и не реализовали ЕМНИП.

Что не реализовали?

> Вообще же утиная типизация - фича и ее не надо избегать.

Это _не_ утиная типизация. Это динамическая типизация.

>Решение - не передавать параметры напрямую. Т.е. не Line(x1,y1,x2,y2), а Line(a,b). Но это не от красоты и мощи, а от безысходности.

Это решение очевидно, потому не интересно.

Что не реализовали?

Пардон, ориентировался на gcc. В Sun Studio и в IBM Rational logiscope уже полная.

Текущее состояние для gcc — http://gcc.gnu.org/c99status.html

Ты же в процентах смотри. Он чуть ли не на 50% медленнее джавы.

И что это показывает? Только то, что бенчмарки Mono C# на 50% медленее жабы. Кстати, они время на стартап учитывают? О_о

Отдельный интересный вопрос: включен ли у них LLVM-backend.

Даже паскаль

А он когда-то был особо тормозным? Чему там тормозить-то?

и луа его обогнали.

LuaJIT. Это достижение Lua.

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

О, а это я прозевал. Линк можно?

Вот: http://tirania.org/blog/archive/2010/Apr-27.html

>Вот: http://tirania.org/blog/archive/2010/Apr-27.html

Спасибо

> Это решение очевидно, потому не интересно.

В самом классе Line надо оставить конструктор по умолчанию (потребовать, чтобы он был и у P) и добавить ф-ю Initialize. Потом Line<Point<double>, double>().Initialize(x1, x2, y1, y2), например.

>Не обязательно метода. Ну да ладно, начнем с методов:

С классами аналогичная чепуха:

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

>Это _не_ утиная типизация. Это динамическая типизация.

Расскажи, что такое, по-твоему мнению, динамическая типизация.

>И что это показывает? Только то, что бенчмарки Mono C# на 50% медленее жабы.

Ну, если тебе сложно сделать какой-то вывод из этого, то остановись и не думай дальше.

Кстати, они время на стартап учитывают?

http://shootout.alioth.debian.org/help.php

А он когда-то был особо тормозным? Чему там тормозить-то?
LuaJIT. Это достижение Lua.

Это было бы все очень убедительно, если бы не джава.

> Расскажи, что такое, по-твоему мнению, динамическая типизация.

Это когда тип аргументов проверяется во время вычисления ф-и, а не во время ее определения. То есть в данном случае, если мы пишем (LAMBDA X.lambda x:X.f(x)) и тут же происходит тайпчек, то значит функция чекается статически и будет ошибка, если f неприменима к любому х. А вот если тайпчек произошел во время (LAMBDA X.lambda x:X.f(x))(sometype), то ф-я типизирована динамически, т.к. тайпчек происходит время вычисления.