Еще немножко флуда на тему "каким должен быть следующий самый крутой в мире язык программирования". Статья некоего Ola Bini (такой довольно известный рубист) под названием Dark Ages of Programming Languages. Он постулирует, что
а) идеальных языков программирования (пока не существует)
б) ближе всего к идеалу Ruby, Lisp, OCaml, Erlang
в) но у каждого из них свои недостатки.
Но интересно не это (то есть это не флейм на тему, "какой язык лучший") — интересно то, что дальше он пишет "каким может быть путь к идеалу".
Дальше — мой сокращенный перевод этого куска.

Все существующие сегодня варианты недостаточно хороши. Я вижу два пути вперед. Два пути, которые могут привести к "языку на 100 лет".

Первый путь — один новый язык. Этот язык будет основан на всех лучших фичах сегодняшних языков, плюс результаты исследований. У меня есть небольшой список того, что должно быть в этом языке для успеха:
* Он должен быть мультипарадигменным. Я не говорю, что нельзя выбрать одну парадигму как базовую, но должно быть возможно программировать функционально, объектно, аспектно, императивно. Должно быть возможно построить декларативную библиотеку, чтобы заниматься логическим программированием в рамках языка.
* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.
* Нужны все феньки функциональных языков: замыкания, first-order functions, лямбды. Иначе язык будет тупиковой ветвью эволюции.
* Нужен сборщик мусора. Возможно, несколько конкурирующих реализаций GC, использующих эволюционирующие алгоритмы, чтобы понять какой из них лучше годиться для длительных процессов.
* JIT VM. Кажется доказанным, что виртуальные машины — большое преимущество. Кроме того, они могут обеспечить великолепную скорость.
* Еще одна JIT VM.
* Реализация без виртуальной машины. Несколько конкурирующих реализаций для разных целей важны для соревновательности и экспериментов с новыми фичами реализации.
* Отличная интеграция со "старыми" языками (Java, Ruby, Cobol). Это очевидно. Слишком много уже создано, от чего мы никогда не избавимся.
* Язык и хотя бы одна реализация промышленного качества обязаны быть с открытыми исходниками. Замкнутость языка должна быть невозможна.
* Тем не менее, хорошая поддержка компаниями важна. Языку нужны деньги, чтобы развиваться.
* Централизованный репозиторий кода/библиотек. Это одна из крупнейших ошибок Java. Установка новой Java-библиотеки болезненно. Нужно что-то вроде CPAN, ASDF, RubyGems.
* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.
* Конкуррентность должна быть встроена в сам язык (как Erlang или Gambit Scheme).
* Мета-программирование должно быть естественным (примерно как в Ruby).
* Должно быть естественным решение проблем снизу вверх, реализуя DSL'и внутри или вне языка.
* В языке должны быть мощные макро-возможности, которые несложно использовать.
* Важно для макро-воззможностей: язык дожен иметь строго определенное синтаксическое дерево простейшего возможно вида, тем не менее синтаксис должен быть ортогональным.

Вот что я считаю необходимым (но, возможно, не достаточным) для действительно полезного, хорошего, долгоиграющего языка программирования. Когда я перечитываю список, мне не кажется, что такой язык скоро появится. Честно говоря, это сдается маловероятным.

Может быть, другой путь — правильный? Другой путь, который я вижу — языки становится все легче создавать, и каждый силен в своей области. [...] Чтобы эта стратегия работала, в каждом языке должна быть в первую очередь возможность интеграции с остальными. Возможно, это будет действительно хороший "язык-клей" [glue-language] (не такой, как Perl или Ruby, но язык, который служит только для склейки других языков), а все остальные языки реализуют хорошую поддержку этого языка. К примеру, можно будет сделать базовый конкурентный фреймворк на Erlang, который использует G (язык-клей) чтобы реализовать некоторую enterprise функциональность в Java sandboxes, а в некоторых местах будут использоваться (через G) DSL, реализованные на Ruby, где через G будут использоваться движки знаний Prolog.

Как-то так.

Здравствуйте, Зверёк Харьковский

ЗХ>Но интересно не это (то есть это не флейм на тему, "какой язык лучший") — интересно то, что дальше он пишет "каким может быть путь к идеалу".

Наивно, имхо, в вотчине VladD2 упоминать, что идеальный язык еще не изобретен.

Здравствуйте, eao197, Вы писали:

ЗХ>>Но интересно не это (то есть это не флейм на тему, "какой язык лучший") — интересно то, что дальше он пишет "каким может быть путь к идеалу".
E>Наивно, имхо, в вотчине VladD2 упоминать, что идеальный язык еще не изобретен.

Ну дык:

Первый путь — один новый язык. Этот язык будет основан на всех лучших фичах сегодняшних языков, плюс результаты исследований. У меня есть небольшой список того, что должно быть в этом языке для успеха:
* Он должен быть мультипарадигменным. Я не говорю, что нельзя выбрать одну парадигму как базовую, но должно быть возможно программировать функционально, объектно, аспектно, императивно. Должно быть возможно построить декларативную библиотеку, чтобы заниматься логическим программированием в рамках языка.

Все есть, италик сделать возможность есть.

* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.

Есть.

* Нужны все феньки функциональных языков: замыкания, first-order functions, лямбды. Иначе язык будет тупиковой ветвью эволюции.

Есть.

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

Есть.

* JIT VM. Кажется доказанным, что виртуальные машины — большое преимущество. Кроме того, они могут обеспечить великолепную скорость.

Есть.

* Еще одна JIT VM.

Не понял, что значит еще одна.

* Реализация без виртуальной машины. Несколько конкурирующих реализаций для разных целей важны для соревновательности и экспериментов с новыми фичами реализации.

Чего нет, того нет.

* Отличная интеграция со "старыми" языками (Java, Ruby, Cobol). Это очевидно. Слишком много уже создано, от чего мы никогда не избавимся.

В каком-то виде есть.

* Язык и хотя бы одна реализация промышленного качества обязаны быть с открытыми исходниками. Замкнутость языка должна быть невозможна.

Есть.

* Тем не менее, хорошая поддержка компаниями важна. Языку нужны деньги, чтобы развиваться.

Есть.

* Централизованный репозиторий кода/библиотек. Это одна из крупнейших ошибок Java. Установка новой Java-библиотеки болезненно. Нужно что-то вроде CPAN, ASDF, RubyGems.

Пока нет.

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

Пока нет.

* Конкуррентность должна быть встроена в сам язык (как Erlang или Gambit Scheme).

Какие-то зачатки уже есть.

* Мета-программирование должно быть естественным (примерно как в Ruby).

Есть.

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

Есть.

* В языке должны быть мощные макро-возможности, которые несложно использовать.

Есть.

* Важно для макро-воззможностей: язык дожен иметь строго определенное синтаксическое дерево простейшего возможно вида, тем не менее синтаксис должен быть ортогональным.

Есть.

Так что, делайте выводы

Здравствуйте, ie, Вы писали:

ie>Ну дык:

Вообще-то, в этом контексте "7 из 10" не канает — ибо это список необходимых свойств языка. Языков, которые наберут много баллов из этого списка — далеко не один; языков, которые наберут все — нету. О чем и речь.

ie>* Еще одна JIT VM.
ie>Не понял, что значит еще одна.

Имеется в виду то же, что было сказано про GC — их должно быть несколько, для конкуренции и постоянного улучшения. Например, рубисты, как известно, страдают от невеликой скорости интерпретатора — а авторы языка в неофициальных беседах зачастую утверждают, что "и так сойдет" (хотя и работают над эффективной виртуальной машиной). А вот если бы была альтернативная реализация, которая бы работала в 20 раз быстрее (но при этом, к примеру, реализовывала бы только 80% языка) — то основная реализация быстро бы подтянулась по скорости (а альтернативная — стала бы подтягиваться по фичам). Это Ола Бини так думает. Я, например, считаю, что если бы был человек, достаточно крутой, чтобы сделать быструю реализацию, и достаточно в этом заинтересованный — он бы присоединился к развитию основной ветви Собственно, это УЖЕ произошло — Сасада Коичи начала разработку Yet Another Ruby VM (YARV), сейчас YARV является официальной виртуальной машиной для следующей версии Руби (Руби 2).

ie>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.
ie>Пока нет.

Здесь, кстати, может всплыть проблема "курицы и яйца" — пока нет хорошего набора библиотек для GUI, сети, БД, и т.п. — не будет большого сообщества; пока не будет сообщества — количество библиотек будет рости медленно.

ie>* Мета-программирование должно быть естественным (примерно как в Ruby).
ie>Есть.

ie>* В языке должны быть мощные макро-возможности, которые несложно использовать.
ie>Есть.

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

Здравствуйте, ie, Вы писали:

ie>Ну дык:
Дык эта:

ie>* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.

ie>Есть.
Есть.

ie>* Нужны все феньки функциональных языков: замыкания, first-order functions, лямбды. Иначе язык будет тупиковой ветвью эволюции.

ie>Есть.
Есть.

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

ie>Есть.
Есть.

ie>* JIT VM. Кажется доказанным, что виртуальные машины — большое преимущество. Кроме того, они могут обеспечить великолепную скорость.

ie>Есть.
Есть.

ie>* Еще одна JIT VM.
Есть.

ie>Не понял, что значит еще одна.
(Чтобы на одной не висеть, как на крючке).

ie>* Реализация без виртуальной машины. Несколько конкурирующих реализаций для разных целей важны для соревновательности и экспериментов с новыми фичами реализации.

ie>Чего нет, того нет.
В принципе, есть (GCJ, хотя пока не работает на нем, но пытаются запустить).

ie>* Отличная интеграция со "старыми" языками (Java, Ruby, Cobol). Это очевидно. Слишком много уже создано, от чего мы никогда не избавимся.

ie>В каком-то виде есть.
Есть.

ie>* Язык и хотя бы одна реализация промышленного качества обязаны быть с открытыми исходниками. Замкнутость языка должна быть невозможна.

ie>Есть.
Есть.

ie>* Тем не менее, хорошая поддержка компаниями важна. Языку нужны деньги, чтобы развиваться.

ie>Есть.
Такая же

ie>* Централизованный репозиторий кода/библиотек. Это одна из крупнейших ошибок Java. Установка новой Java-библиотеки болезненно. Нужно что-то вроде CPAN, ASDF, RubyGems.

ie>Пока нет.
Есть.

ie>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.

ie>Пока нет.
Намечается

ie>* Конкуррентность должна быть встроена в сам язык (как Erlang или Gambit Scheme).

ie>Какие-то зачатки уже есть.
Аналогично

Автор: Курилка
Дата: 15.07.06

(хотя производительность, конечно, швах).

ie>* Мета-программирование должно быть естественным (примерно как в Ruby).

ie>Есть.
Пока нет, но см. вопрос нашего общего знакомого и ответ на него

ie>* Должно быть естественным решение проблем снизу вверх, реализуя DSL'и внутри или вне языка.

ie>Есть.
См. выше.

ie>* В языке должны быть мощные макро-возможности, которые несложно использовать.

ie>Есть.
См. выше.

ie>* Важно для макро-воззможностей: язык дожен иметь строго определенное синтаксическое дерево простейшего возможно вида, тем не менее синтаксис должен быть ортогональным.

ie>Есть.
См. выше.

ie>Так что, делайте выводы

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

ЗХ>Здесь, кстати, может всплыть проблема "курицы и яйца" — пока нет хорошего набора библиотек для GUI, сети, БД, и т.п. — не будет большого сообщества; пока не будет сообщества — количество библиотек будет рости медленно.

Проблема Эрланга, кстати. Правда, Yariv, судя по всему, решил вытянуть Эрланг в одиночку

Здравствуйте, eao197, Вы писали:

ie>>* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.

E>Есть.

Статический вывод типов? В каком виде?

Здравствуйте, Дарней, Вы писали:

ie>>>* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.

E>>Есть.

Д>Статический вывод типов? В каком виде?

RTFM: http://www.rsdn.ru/article/philosophy/Scala.xml

Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.

// Scala 
object PrintOptions
{
  def main(args: Array[String]) : unit =
  {
    System.out.println("Options selected:");

    for (val arg <- args)
      if (arg.startsWith("-"))
        System.out.println(" "+arg.substring(1));
  }
}

Здравствуйте, Зверёк Харьковский, Вы писали:

ie>>* Еще одна JIT VM.
ie>>Не понял, что значит еще одна.

ЗХ>Имеется в виду то же, что было сказано про GC — их должно быть несколько ... Собственно, это УЖЕ произошло — Сасада Коичи начала разработку Yet Another Ruby VM (YARV), сейчас YARV является официальной виртуальной машиной для следующей версии Руби (Руби 2).

Mono прокатит?

ie>>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.
ie>>Пока нет.

ЗХ>Здесь, кстати, может всплыть проблема "курицы и яйца" — пока нет хорошего набора библиотек для GUI, сети, БД, и т.п. — не будет большого сообщества; пока не будет сообщества — количество библиотек будет рости медленно.

В принципе есть FCL, но как-то не тянет на роль "хорошего набора библиотек", то и дело тут и там всплывают все новые и новые библиотеки.

ie>>* Мета-программирование должно быть естественным (примерно как в Ruby).
ie>>Есть.

ie>>* В языке должны быть мощные макро-возможности, которые несложно использовать.
ie>>Есть.

ЗХ>Кстати, в Nemerle есть отдельно мета- и отдельно макро- программирование? Или вы в обоих случаях подразумевали одну и ту же фичу?

На самом деле, разработчики Немерла все время говорят о метапрограммировании. На самом же деле и мета- и макро- там в куче. Единственное, чего там не хватает, так это выполнение выражений в рантайме, как это сделано в MetaML.
Т.е. ничего такого нету:

def expr = <[ 5 + 5 ]>;
def res = expr.Run();

Но опять же, это, как мне кажется, реализуемо.

Здравствуйте, eao197, Вы писали:

ie>>Ну дык:
E>Дык эта:

Ну так Scala отличный язык! Коль макросы добавят, то цены ему не будет, зато будет больше шансов, что одним отличным языком в мэйнстриме станет больше.

ie>>Так что, делайте выводы

E>Мир не может быть однополярным.
E>И предела совершенству нет. Поэтому идеального языка не может быть в принципе. Даже если кому-то кажется, что таковой есть, и он им даже пользуется. Скорее это просто от недостатка информации.

Вот с этим полностью согласен, как в прочем и с Ola Bini:

а) идеальных языков программирования (пока не существует)
б) ближе всего к идеалу Ruby, Lisp, OCaml, Erlang
в) но у каждого из них свои недостатки.

Только вот Scala и Nemerle бы в его списочек добавил

Здравствуйте, ie, Вы писали:

ie>На самом деле, разработчики Немерла все время говорят о метапрограммировании. На самом же деле и мета- и макро- там в куче.

Макро-программирование — это один из вариантов реализации метапрограммирования, так что всё верно. А чего тебе не хватает в макросах?

Здравствуйте, Зверёк Харьковский, Вы писали:

Я бы добавил в список еще один пункт.
* Микроядерная реализация языка.
То бишь — минимально возможный набор команд реализуется в компиляторе, всё остальное — расширение средствами самого языка.

Здравствуйте, Дарней, Вы писали:

Д>А чего тебе не хватает в макросах?

А кто сказал что мне что-то не хватает?

Здравствуйте, ie, Вы писали:

ie>А кто сказал что мне что-то не хватает?

Это я просто предположил
А какие есть еще варианты реализации метапрограммирования, помимо макросов? graph rewriting или что-то подобное?

Здравствуйте, ie, Вы писали:

Дополню про Nemerle:

ie>* Еще одна JIT VM.

ie>Не понял, что значит еще одна.
Ну альтернативная реализация. В данном случае сойдет Mono.

ie>* Реализация без виртуальной машины. Несколько конкурирующих реализаций для разных целей важны для соревновательности и экспериментов с новыми фичами реализации.

ie>Чего нет, того нет.
Да можно я думаю сделать. Есть же эксперименты с прикручиванием back-end от GCC к Mono,
ну и MS делает там всякие Bartok и Phoenix (последний кстати можно скачать для некомм использования).

Ну и в конце концов сам компилятор Nemerle распространяется по BSD-лицензии, так что если кому надо, то надо только
вместо System.Reflection.Emit альтернативный backend прикрутить.

ie>* Отличная интеграция со "старыми" языками (Java, Ruby, Cobol). Это очевидно. Слишком много уже создано, от чего мы никогда не избавимся.

ie>В каком-то виде есть.
Ну да через стандартные средства .NET (PInvoke и т.д.).

ie>* Тем не менее, хорошая поддержка компаниями важна. Языку нужны деньги, чтобы развиваться.

ie>Есть.
Ну пока нет. MS почему-то предпочитает F# вместо этого использовать (и то же метапрограммирование к нему прикручивать).
Хотя по мне так Nemerle намного лучше. Наверное все от незнания о Nemerle.

ie>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.

ie>Пока нет.
А .NET овские библиотеки как же?

ie>Так что, делайте выводы
Ага

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Первый путь — один новый язык. Этот язык будет основан на всех лучших фичах сегодняшних языков, плюс результаты исследований. У меня есть небольшой список того, что должно быть в этом языке для успеха:
ЗХ>* Он должен быть мультипарадигменным. Я не говорю, что нельзя выбрать одну парадигму как базовую, но должно быть возможно программировать функционально, объектно, аспектно, императивно. Должно быть возможно построить декларативную библиотеку, чтобы заниматься логическим программированием в рамках языка.
+1

ЗХ>* В нем должен быть статический вывод типов, где возможно. Он должен также позволять опциональные type hints. Это очень важно для создания хороших реализаций, а так же в некоторых случаях улучшает читабельность.
+1

ЗХ>* Нужны все феньки функциональных языков: замыкания, first-order functions, лямбды. Иначе язык будет тупиковой ветвью эволюции.
+1

ЗХ>* Нужен сборщик мусора. Возможно, несколько конкурирующих реализаций GC, использующих эволюционирующие алгоритмы, чтобы понять какой из них лучше годиться для длительных процессов.
+1

ЗХ>* JIT VM. Кажется доказанным, что виртуальные машины — большое преимущество. Кроме того, они могут обеспечить великолепную скорость.
Виртуальные машины дают преимущество в плане динамической генерации, загрузки (и выгрузки) кода и обеспечивают интроспективные возможности.
А вот откуда взялась "великолепная скорость" я не понял. По-любому не быстрее полностью оптимизирующего компилятора.
Видимо "великолепная скорость" только по сравнению с Ruby . Ну с такой точки зрения любой язык кроме PHP обеспечит "великолепную скорость".

ЗХ>* Еще одна JIT VM.
ЗХ>* Реализация без виртуальной машины. Несколько конкурирующих реализаций для разных целей важны для соревновательности и экспериментов с новыми фичами реализации.
Не всегда возможно, т.к. динамические языки как правило предполагают наличие VM хотя бы для генерации кода на лету.

ЗХ>* Отличная интеграция со "старыми" языками (Java, Ruby, Cobol). Это очевидно. Слишком много уже создано, от чего мы никогда не избавимся.
Отличная вряд ли получится (т.к. разные парадигмы (например язык с GC и без)), но неплохую можно.

ЗХ>* Язык и хотя бы одна реализация промышленного качества обязаны быть с открытыми исходниками. Замкнутость языка должна быть невозможна.
+1

ЗХ>* Тем не менее, хорошая поддержка компаниями важна. Языку нужны деньги, чтобы развиваться.
А не знаю. Perl, PHP и Python обошлись как то без этого.

ЗХ>* Централизованный репозиторий кода/библиотек. Это одна из крупнейших ошибок Java. Установка новой Java-библиотеки болезненно. Нужно что-то вроде CPAN, ASDF, RubyGems.
Не знаю, это уже скорее вопрос инфраструктуры и утилит.
Для того же Eclipse плагины совершенно безболезненно устанавливаются.

ЗХ>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки. Библиотеки поставляемые вместе с языком должны быть прекрасны, невелики и тем не менее содержать большую часть необходимой функциональности.
Прекрасны понятие субъективное.

ЗХ>* Конкуррентность должна быть встроена в сам язык (как Erlang или Gambit Scheme).
+1

ЗХ>* Мета-программирование должно быть естественным (примерно как в Ruby).
+1

ЗХ>* Должно быть естественным решение проблем снизу вверх, реализуя DSL'и внутри или вне языка.
Я за внутри.

ЗХ>* В языке должны быть мощные макро-возможности, которые несложно использовать.
+1

ЗХ>* Важно для макро-воззможностей: язык дожен иметь строго определенное синтаксическое дерево простейшего возможно вида, тем не менее синтаксис должен быть ортогональным.
+1

ЗХ>Вот что я считаю необходимым (но, возможно, не достаточным) для действительно полезного, хорошего, долгоиграющего языка программирования. Когда я перечитываю список, мне не кажется, что такой язык скоро появится. Честно говоря, это сдается маловероятным.
-1. Смотри Nemerle и Scala. Да и Boo возможно.

ЗХ>Может быть, другой путь — правильный? Другой путь, который я вижу — языки становится все легче создавать, и каждый силен в своей области. [...]
Нееет! Учить 100 языков а потом путаться в разном синтаксисе . Just say No.

ЗХ> Чтобы эта стратегия работала, в каждом языке должна быть в первую очередь возможность интеграции с остальными.
Это в любом случае не помешает. Собственно это то, для чего был создан .NET framework.

ЗХ> Возможно, это будет действительно хороший "язык-клей" [glue-language] (не такой, как Perl или Ruby, но язык, который служит только для склейки других языков), а все остальные языки реализуют хорошую поддержку этого языка. К примеру, можно будет сделать базовый конкурентный фреймворк на Erlang, который использует G (язык-клей) чтобы реализовать некоторую enterprise функциональность в Java sandboxes, а в некоторых местах будут использоваться (через G) DSL, реализованные на Ruby, где через G будут использоваться движки знаний Prolog.
ЗХ>[/q]
Жуть. А как вы этот зоопарк будете поддерживать? А отлаживать?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Имеется в виду то же, что было сказано про GC — их должно быть несколько, для конкуренции и постоянного улучшения. Например, рубисты, как известно, страдают от невеликой скорости интерпретатора — а авторы языка в неофициальных беседах зачастую утверждают, что "и так сойдет" (хотя и работают над эффективной виртуальной машиной). А вот если бы была альтернативная реализация, которая бы работала в 20 раз быстрее (но при этом, к примеру, реализовывала бы только 80% языка) — то основная реализация быстро бы подтянулась по скорости (а альтернативная — стала бы подтягиваться по фичам). Это Ола Бини так думает. Я, например, считаю, что если бы был человек, достаточно крутой, чтобы сделать быструю реализацию, и достаточно в этом заинтересованный — он бы присоединился к развитию основной ветви Собственно, это УЖЕ произошло — Сасада Коичи начала разработку Yet Another Ruby VM (YARV), сейчас YARV является официальной виртуальной машиной для следующей версии Руби (Руби 2).

Ну насчет того что YARV так уж быстра не сказал бы (медленнее той же Скалы раз в 10-15): здесь.
Но так конечно побыстрее старой раза в 2-3.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Ну насчет того что YARV так уж быстра не сказал бы (медленнее той же Скалы раз в 10-15): здесь.
АХ>Но так конечно побыстрее старой раза в 2-3.

Святая правда. Меня самого ужасно удручает, когда какие-то алгоритмы/тесты, которые на Питоне работают в 10-20 раз быстрее, ускоряются при помощи YARV всего в 2-3 раза (оставаясь в 3-5 раз медленнее Питона) — и все считают это нормальным

Здравствуйте, Андрей Хропов, Вы писали:

АХ>А вот откуда взялась "великолепная скорость" я не понял. По-любому не быстрее полностью оптимизирующего компилятора.
АХ>Видимо "великолепная скорость" только по сравнению с Ruby . Ну с такой точки зрения любой язык кроме PHP обеспечит "великолепную скорость".

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

Здравствуйте, Дарней, Вы писали:
Д>нативный код надо создавать или для "наименьшего общего подмножества" команд процессора (что заведомо уменьшает ффективность), или создавать отдельный образ для каждой возможной модели процессора, на которой будет запускаться прога (что нехило раздувает размер программы)
Д>наличие расширенных наборов команд, размер кэша, структура конвейера — это всё имеет очень большое значение на производительность кода
Д>виртуальная машина может, хотя бы теоретически, всегда использовать особенности процессора для повышения производительности — достаточно перегенерировать нативный код под нужный процессор
А также выполнять hot-spotting чтобы использовать реальную статистику вызовов. Хотя наиболее современный подход вроде бы в том, что статистику вызовов лучше получать на стороне разработчика путем тестовых прогонов, т.к. это теоретически позволяет получать больше времени для глобальных оптимизаций. А статистика вызовов ожидается более зависящей от приложения, нежели от конкретного окружения.