Еще немножко флуда на тему "каким должен быть следующий самый крутой в мире язык программирования". Статья некоего 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 чтобы использовать реальную статистику вызовов. Хотя наиболее современный подход вроде бы в том, что статистику вызовов лучше получать на стороне разработчика путем тестовых прогонов, т.к. это теоретически позволяет получать больше времени для глобальных оптимизаций. А статистика вызовов ожидается более зависящей от приложения, нежели от конкретного окружения.

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

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

Упаси нас бог от языка на 100 лет. Только представить себе — идет 10-й год от момента создания этого языка. И на всякие рассуждения о новых языках тебе отвечают — приходите через 90 лет

А если серьезнее — сколько вы, господа, тут не обсуждайте, а кончится тем, что программировать будете на языке, который некая серьезная фирма (Microsoft, Sun,...) вам предложит и будет поддерживать. Как миленькие. Никуда не денетесь. А все остальное — периферия IT.

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

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

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

Дарней wrote:
> Я думаю, выгоднее использовать статический анализ путей исполнения и
> тестовые прогоны, чтобы собирать такую информацию. Главный недостаток
> хотспота в том, что он сам отъедает ресурсы во время исполнения.
Статический анализ поможет, но не сильно. Дело в том, что на протяжении
жизни приложения горячие точки могут перемещаться в коде и иногда наша
оптимизация может стать пессимизацией.

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

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

PD>А если серьезнее — сколько вы, господа, тут не обсуждайте, а кончится тем, что программировать будете на языке, который некая серьезная фирма (Microsoft, Sun,...) вам предложит и будет поддерживать. Как миленькие. Никуда не денетесь. А все остальное — периферия IT.

А, ну-ну. Вот Пол Грехем заработал на Лиспе че-то в районе 20 млн долларов. Уж лучше я буду на такой "периферии" .

А если серьезно, то пусть люди создают новые языки, проекты, а потом лучшие из них будут поддержаны индустрией.
Примеры тому есть, те же Perl, Python, PHP, Ruby и т.д.
И теперь уже Sun нанимает создателей JRuby, а MS — IronPython.

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

АХ>А, ну-ну. Вот Пол Грехем заработал на Лиспе че-то в районе 20 млн долларов.

Ну-ну... Я не о создателях и разработчиках языков говорю, а о большинстве обычных программистов. Дай объявление о себе как о Лисп-программисте, а когда найдешь работу и заработаешь на ней 20 млн — тогда и поговорим . И даже тогда это не будет серьезным аргументом — единичный случай не аргумент. Вот если найдется язык, который никакая серьезная фирма не поддерживает, а он востребован на уровне C++, Java. C# и т.д. — вот это будет аргументом.

АХ>А если серьезно, то пусть люди создают новые языки, проекты, а потом лучшие из них будут поддержаны индустрией.
АХ>Примеры тому есть, те же Perl, Python, PHP, Ruby и т.д.
АХ> И теперь уже Sun нанимает создателей JRuby, а MS — IronPython.

Да бога ради. Это и есть тот самый аргумент, который я привожу — только то, за что серьезные фирмы возьмутся, то и будет. В конце концов и С энтузиасты создали...

Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

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

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

АХ>>А, ну-ну. Вот Пол Грехем заработал на Лиспе че-то в районе 20 млн долларов.

PD>Ну-ну... Я не о создателях и разработчиках языков говорю, а о большинстве обычных программистов. Дай объявление о себе как о Лисп-программисте, а когда найдешь работу и заработаешь на ней 20 млн — тогда и поговорим . И даже тогда это не будет серьезным аргументом — единичный случай не аргумент. Вот если найдется язык, который никакая серьезная фирма не поддерживает, а он востребован на уровне C++, Java. C# и т.д. — вот это будет аргументом.

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

АХ>>А если серьезно, то пусть люди создают новые языки, проекты, а потом лучшие из них будут поддержаны индустрией.
АХ>>Примеры тому есть, те же Perl, Python, PHP, Ruby и т.д.
АХ>> И теперь уже Sun нанимает создателей JRuby, а MS — IronPython.

PD>Да бога ради. Это и есть тот самый аргумент, который я привожу — только то, за что серьезные фирмы возьмутся, то и будет. В конце концов и С энтузиасты создали...

Не, C был создан для Unix и это было в Bell Labs, так что это было по заказу.

PD>Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

Что значит серьезное? Perl, PHP, Python серьезно? А сама разработка этих языков не поддерживается корпорациями.

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

PD>Да бога ради. Это и есть тот самый аргумент, который я привожу — только то, за что серьезные фирмы возьмутся, то и будет. В конце концов и С энтузиасты создали...

PD>Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

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

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

АХ>Я к тому, что для того чтобы успешно разрабатывать программы не обязательно пользоваться самым мейнстримным языком, достаточно возможности нормальной интеграции с ними.

Что такое "успешно разрабатывать программы" ? Можно создать фирму, которая успешно разработает новую игру и сумеет ее продвинуть на рынок (не сама, конечно). При этом на чем игра написана — не так важно, хоть на ассемблере. Можно просто писать что-то в свое удовольствие на чем угодно, если вопрос денег не стоит. Более того, из этого иногда потрясающие результаты получаются. Но — один на тысячу. А я говорю об обычных программистах, которые работают на кого-то и за это деньги получают. Именно о них.


АХ>Пользуясь языком, который позволит писать более продуктивно, можно получить конкурентное преимущество. Собственно пример Пола Грехема это и показал.

Да ничего он не показал. Я про Лисп слышал еще на заре своей карьеры, в 80-е годы, и книги тогда издавались. И как он тогда был периферией IT, так и остался. Я же не говорю, что его нет. Просто сравнить число программирующих на Лиспе и на C++, C#. Java, VB — ну несерьезно.

АХ>Не, C был создан для Unix и это было в Bell Labs, так что это было по заказу.

Да, ты прав. Формально по заказу. Но по существу — именно энтузиастами, у которых были идеи. Большой разницы не вижу.

PD>>Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

АХ>Что значит серьезное? Perl, PHP, Python серьезно? А сама разработка этих языков не поддерживается корпорациями.

OK. Сколько в мире программистов на С++, C# или Java и сколько — на Python или Perl ?

PHP — да, посерьезнее. Но заметь, насколько сильно его теснит ASP.NET.

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

E>Ruby сейчас не продвигает ни одна серьезная фирма. Мне пофигу Грэхем с его заработанными на Лиспе миллионами. Но сейчас моя зарплата во многом зависит от работы написанных мной на Ruby программ. Так что миллионы следующих за мейнстримом программистов, как и тысячи подобных мне маргиналов -- это все абстрактые понятия, а вот конкретное -- это булка с маслом в моих руках. Которая у меня есть благодоря языку, не поддерживаемому крупными корпорациями. И что-либо серьезнее этого факта нужно ее поискать.

Еще раз объясняю свою позицию — я говорю только о массовом программисте. Если пойдешь игры писать — получишь хлеб с маслом за знание ассемблера. Если в научные исследования пойдешь — может быть, за Фортран. И за Аду тоже платят — в Министерстве обороны США. И, может быть, даже за Немерле тоже уже где-то платят. А массовый программист будет иметь дело с индустриальными средствами, а не пионерскими (или, наоборот, устаревшими) разработками.

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

PD>Еще раз объясняю свою позицию — я говорю только о массовом программисте. Если пойдешь игры писать — получишь хлеб с маслом за знание ассемблера. Если в научные исследования пойдешь — может быть, за Фортран. И за Аду тоже платят — в Министерстве обороны США. И, может быть, даже за Немерле тоже уже где-то платят. А массовый программист будет иметь дело с индустриальными средствами, а не пионерскими (или, наоборот, устаревшими) разработками.

А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

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

E>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

Нет, не абстракция. Это те программисты, которых большинство.

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

PD>А если серьезнее — сколько вы, господа, тут не обсуждайте, а кончится тем, что программировать будете на языке, который некая серьезная фирма (Microsoft, Sun,...) вам предложит и будет поддерживать. Как миленькие. Никуда не денетесь. А все остальное — периферия IT.

Что-то я ни фига не пойму. Сначала вы утверждаете, что то что [b]нам[b] предложит корпорация — на том, мол и будем программировать. Когда появляется толпа "нас", которые программируют на языках, не поддерживаемых корпорациями — разговор пошел о некоем "массовом программисте" (он случайно не сферический, кстати?). Я никогда не могу понять этого логического перехода в спорах о языках — мол, что массовое (вечное слово "промышленный"), то и благо. Что же теперь, вообще не говорить об эффективности и красоте языков? Ну, давайте будем биржевыми сводками обмениваться — у какой корпорации сегодня индекс вверх пошел, тот язык весь РСДН и любит — так, что ли?

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

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

E>>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

PD>Нет, не абстракция. Это те программисты, которых большинство.

Статистика есть?
Какой процент в мире веб-программистов (на PHP, Python, Ruby, whatever — ни одной корпорации, увы)?
Какой процент шароварщиков (которые пишут на чем бог на душу положит)?
Какой процент игроделов?
Какой процент исследователей?
Какой процент занимается внутрифирменным софтом (опять же на чем попало)?
Юниксоидов (где, как правило, негусто "языков, поддерживаемых корпорациями")?

Из того, что знаю я лично — одних рубистов в мире столько, что "маргиналами, которым работы не найти" их назвать очень тяжело.

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

E>>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

PD>Нет, не абстракция. Это те программисты, которых большинство.

Павел, возможно я нашел причину нашего противоречия. Дело в том, что термин "серьезный" из фразы:

Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

может быть употреблен как персонально к конкретному программисту, так и к "индустрии". Вот я как раз и говорил о том, что для конкретного человека "серьезность" определяется тем, чем он в данный момент зарабатывает себе на жизнь. Это настолько серьезно, что более серьезные вещи еще нужно поискать (и найдены они, скорее всего, будут вне области программирования, как то: здоровье близких людей, семья, ремонт в квартире и пр.). Поэтому даже очень значимые вещи (например, такие как появление платформы .NET) для конкретного разработчика может совершенно спокойно пройти мимо и не вызвать никаких изменений в его благосостоянии

Ты же, скорее всего, подразумевал серьезность воздействия на "индустрию". Хотя и "индустрия" здесь не очень удачный термин, поскольку производство ПО уже сильно фрагментированно (встроенные системы и научные расчеты, например, вообще на разных полюсах находятся). Скорее речь нужно вести о массовом производстве. О тех 20% инструментов/технологий, которые покроют потребности 80% разработчиков и заказчиков ПО. С этим я спорить не буду, хотя можно было бы повспоминать какие-нибудь технологические прорывы или то, что в разных сферах есть свои лидеры и, например, где-то WindRiver гораздо круче M$.

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

E>Здравствуйте, Pavel Dvorkin, Вы писали:

E>>>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

PD>>Нет, не абстракция. Это те программисты, которых большинство.

E>Павел, возможно я нашел причину нашего противоречия. Дело в том, что термин "серьезный" из фразы:

<skipped>

Вполне согласен.

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

ЗХ>Здравствуйте, Pavel Dvorkin, Вы писали:

E>>>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

PD>>Нет, не абстракция. Это те программисты, которых большинство.

ЗХ>Статистика есть?

Наверное, есть, но у меня лично нет. Но нужна ли здесь точная статистика ? Зайди на любые сайты, где предлагают/ищут работу, и посмотри. Согласен, это не будет статистически репрезентативно в строгом смысле слова, но не будешь же ты в конце концов спорить, что программистов на Java/C++/C# требуется больше, чем на Ruby или Python ? И не в 2 раза больше, а как бы не на 2 порядка.


ЗХ>Из того, что знаю я лично — одних рубистов в мире столько, что "маргиналами, которым работы не найти" их назвать очень тяжело.

Стоп, Зверек, не надо передергивать. Никого маргиналом я не называл, периферия — еще не маргинальность. И про то, трудно или нет им найти работу, я и не заикался. Я просто одно утверждаю : это — периферия. Потому что если это приносит серьезный доход, то это подхватит серьезная фирма. Вот и все.

Периферия — не есть плохо. Вообще-то новые идеи часто приходят с периферии. Более того, они скорее всего оттуда и приходят. Хороший паровозник тепловоз не придумает. Но кустарные тепловозы тоже не есть серьезное дело, даже если они ездят. Одно из двух — либо эти тепловозы подхватит серьезная фирма и они серьезно потеснят паровозы, либо они заглохнут, а на сцену выйдет что-то иное. Электровозы, к примеру, или вообще самолеты. Но не собранные в КБ Жуковского в единственном экземпляре, а Боинги или хотя бы ТУ

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

ЗХ>Здравствуйте, Pavel Dvorkin, Вы писали:

ЗХ>Что-то я ни фига не пойму. Сначала вы утверждаете, что то что нам[b] предложит корпорация — на том, мол и будем программировать. Когда появляется толпа "нас", которые программируют на языках, не поддерживаемых корпорациями — разговор пошел о некоем "массовом программисте" (он случайно не сферический, кстати?).

Голова ближе к сферической, туловище продолговатое, еще ноги и руки есть, неправильной формы


>Я никогда не могу понять этого логического перехода в спорах о языках — мол, что массовое (вечное слово "промышленный"), то и благо.

А разве я утверждал, что это благо ? Ссылку, плиз! Я утверждаю лишь, что это то, чем заниаются [b]большинство в индустрии


>Что же теперь, вообще не говорить об эффективности и красоте языков?

Да бога ради, говорите, я что, запретить пытаюсь, что ли ? Я просто фиксирую факт — есть состояние индустрии, а есть периферия ее. И большинство работают в индустрии, а не на периферии.


>Ну, давайте будем биржевыми сводками обмениваться — у какой корпорации сегодня индекс вверх пошел, тот язык весь РСДН и любит — так, что ли?

Сорри, не улавливаю ни юмора, ни смысла.

Зверёк Харьковский wrote:

> вперед. Два пути, которые могут привести к "языку на 100 лет".
В поисках Cвятого Грааля? Элексира Бессмертия?

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

PD>А если серьезнее — сколько вы, господа, тут не обсуждайте, а кончится тем, что программировать будете на языке, который некая серьезная фирма (Microsoft, Sun,...) вам предложит и будет поддерживать. Как миленькие. Никуда не денетесь. А все остальное — периферия IT.

Фигня, прорвёмся.

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

C>Статический анализ поможет, но не сильно. Дело в том, что на протяжении
C>жизни приложения горячие точки могут перемещаться в коде и иногда наша
C>оптимизация может стать пессимизацией.

Ты можешь уточнить на примере, как это может произойти?

Дарней wrote:
> C>Статический анализ поможет, но не сильно. Дело в том, что на протяжении
> C>жизни приложения горячие точки могут перемещаться в коде и иногда наша
> C>оптимизация может стать пессимизацией.
> Ты можешь уточнить на примере, как это может произойти?
Стандартный пример, вот у нас есть код, который ищет нужных учеников:

void processPupils()
{
    for(int f=0;f<pupilNum;f++)
    {
        if (pupilIsGood(pupil[f]))
        {
            ...
            pupil[f].giveIceCream();
            ...
        } else
        {
            ...
            pupil[f].punish();
            ...
        }
    }
}

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

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

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

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

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

АХ>>Я к тому, что для того чтобы успешно разрабатывать программы не обязательно пользоваться самым мейнстримным языком, достаточно возможности нормальной интеграции с ними.

PD>Что такое "успешно разрабатывать программы" ? Можно создать фирму, которая успешно разработает новую игру и сумеет ее продвинуть на рынок (не сама, конечно). При этом на чем игра написана — не так важно, хоть на ассемблере. Можно просто писать что-то в свое удовольствие на чем угодно, если вопрос денег не стоит. Более того, из этого иногда потрясающие результаты получаются. Но — один на тысячу. А я говорю об обычных программистах, которые работают на кого-то и за это деньги получают. Именно о них.

Хорошо, вот недавний пример из российской практики:
Re[7]: Практическое применение

Автор: Alex EXO
Дата: 07.09.06

Путем использования "маргинального" Erlang получено сокращение сроков разработки и увеличение производительности.
Приложение вполне практическое. Это серьезно?

АХ>>Пользуясь языком, который позволит писать более продуктивно, можно получить конкурентное преимущество. Собственно пример Пола Грехема это и показал.

PD>Да ничего он не показал. Я про Лисп слышал еще на заре своей карьеры, в 80-е годы, и книги тогда издавались. И как он тогда был периферией IT, так и остался. Я же не говорю, что его нет. Просто сравнить число программирующих на Лиспе и на C++, C#. Java, VB — ну несерьезно.

Ну и ладно. Вон на 1С многие пишут. А мне то что с этого ?

PD>>>Но будет что-то серьезное не раньше, чем серьезные фирмы это поддержат. Не раньше!

АХ>>Что значит серьезное? Perl, PHP, Python серьезно? А сама разработка этих языков не поддерживается корпорациями.

PD>OK. Сколько в мире программистов на С++, C# или Java и сколько — на Python или Perl ?
Цифр не знаю, но знаю что Python используется в крупных компаниях (Google,ILM,Яндекс...)
Да и Perl там же и еще много где.

PD>PHP — да, посерьезнее. Но заметь, насколько сильно его теснит ASP.NET.

Не знаю, я не проф в веб-разработке.

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

E>Наивно, имхо, в вотчине VladD2

Это чего это тут вотчина VladD2?

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

ЗХ>а) идеальных языков программирования (пока не существует)

Для мэйнстрима идеалом вполне можно считать C#.

ЗХ>б) ближе всего к идеалу Ruby, Lisp, OCaml, Erlang

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


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

"Язык на 100 лет" описан только первым вариантом, второй подразумевает существование всего сегодняшнего зоопарка + "Момент".


ЗХ>Первый путь — один новый язык.

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

ЗХ>* Он должен быть мультипарадигменным.

Классический павлино-утко-ёж — бесхвостое, лысое чудовище, тонущее в воде. Вы не ошиблись, это действительно "известный рубист" или пи%добол-теоретик?

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

Но тогда идёт лесом любая попытка "динамического" программинга! Мечтать-то не вредно, но надо ещё думать.

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

И как же мы 30 лет программили и всё никак не вымрем как мамонты?
А что интересно, что как раз функциональные языки живут где-то сбоку-припёку, а мэйнстрим прекрасно обходится императивными/ООП языками.


ЗХ>* Нужен сборщик мусора.

Менеджер памяти — точно нужен, а вот что подразумевается под GC — ещё желательно бы точно сформулировать! Только, причём тут ЯЗЫК?

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

Это выдача желаемого за действительное. Пока только одна единственная ВМ показала приемлемую скорость исполнения некритичных приложений, а остальные "преимущества" ещё нуждаются во всеплатформенных доказательствах.

ЗХ>* Кроме того, они могут обеспечить великолепную скорость.

Пустослов.

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

Да хоть десяток их напиши! Опять же, каким боком это относится к языку?

ЗХ>* Реализация без виртуальной машины.

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

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

Ерунда. Всё что надо, напишут заново (Це-шарпу это не помешало), а устаревшие системы... жлобы их будут использовать ещё лет 200, НАМ это зачем?
Уж с чем нужна интеграция, так это с библиотеками (.so, .dll). А что особенно интересно, как это автор собирается интегрировать мультипарадигменную кашу языков, когда даже между однопарадигменными языками такое не всегда возможно!

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

Мечты юного пингвиноида. Создание качественного языка — вещь настолько трудоёмкая, что отбивать бабки придётся ещё очень долго.

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

А главное — в тему про "язык на 100 лет"! Буржуй-маркетолог прёт изо всех щелей...

ЗХ>* Централизованный репозиторий кода/библиотек.

Опять про что-угодно, кроме ЯЗЫКА.

ЗХ>* Языку нужны, хорошие, маленькие и очень ортогональные библиотеки.

OFFTOPIC.

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

Можно подумать, что под DOS это кому-то помогло бы... Парень просто не понимает что такое ОС и язык.

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

Ну короче, Рыбы — наше всё. Чего было слюни развозить?
Всё это "мета-" очень забавно, но для досуга. Мэйнстрим не выдержит такого наплыва программ-извращенцев.

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

Кто про что, но только дайте в компиляторе покопаться! Мальчишеские радости...

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

Понятие "мощные" — это в отдел маркетинга, нам пожалуйста конкретные описания и их жизненную необходимость.

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

Опять копания в кишках. И чего человеку неймётся?... Наверное, слишком много свободного времени.

ЗХ>Когда я перечитываю список, мне не кажется, что такой язык скоро появится.

Зачем тогда писать эту чушь? Брось косяк, да иди читать мат.часть!

ЗХ>Может быть, другой путь — правильный?

Т.е. предыдущий — был неправильный? Ты не уверен? Ты сочинил всё это "по ходу дела"? Тогда зачем это вообще писать?

ЗХ> Другой путь, который я вижу — языки становится все легче создавать

Нуёпыть! ПЛОХИЕ языки — легче создавать. Или мультипарадигменные с поддержкой "языка черепашки".

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

Да-да. Нужно "всего лишь" изменить пару мильёнов строк кода во всех компиляторах и все они склеются во всеобщем оргазме! Мечтатель...

Вобщем, полный бред и дилетантство. Незачёт.

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

ЗХ>массовое (вечное слово "промышленный")

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

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

Q>пи%добол-теоретик?

Q>Незачёт.

Чувак, ты ошибся форумом. Доказывают друг другу собственную крутизну — тут.
Натренируешься вести дискуссию, как умный человек, а не гопота из подворотни — welcome back!

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

ЗХ>Чувак, ты ошибся форумом. Доказывают друг другу собственную крутизну — тут.
ЗХ>Натренируешься вести дискуссию, как умный человек, а не гопота из подворотни — welcome back!

Ты меня конечно извини, но модератор здесь я.

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

Че-то ты как-то слабо критику навел. Неопытный ты еще тролль.

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

PD>Еще раз объясняю свою позицию — я говорю только о массовом программисте.
Зачем говорить за всех?

PD>Если пойдешь игры писать — получишь хлеб с маслом за знание ассемблера. Если в научные исследования пойдешь — может быть, за Фортран. И за Аду тоже платят — в Министерстве обороны США. И, может быть, даже за Немерле тоже уже где-то платят. А массовый программист будет иметь дело с индустриальными средствами, а не пионерскими (или, наоборот, устаревшими) разработками.
Не уверен, что платят за технологии. Платят за эффективные решения, а технологии -- это всего лишь способ реализации этих решений. Докажите Министерству обороны США, что решения на Немерле будут для них выгодней чем на Аде и вам станут платить на Немерле

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

>Докажите Министерству обороны США, что решения на Немерле будут для них выгодней чем на Аде и вам станут платить на Немерле

Черта с два. Тут еще 1000 прочих факторов присутствует. Корпоративные стандарты. Затраты на переобучение персонала и неизбежно связанные с этим потери в качестве на первых порах. Наработанное ПО, от которого никто не будет отказываться. Предпочтения топ-менеджера и мнение об этом его жены . И т.д.

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

АХ>Путем использования "маргинального" Erlang получено сокращение сроков разработки и увеличение производительности.
АХ>Приложение вполне практическое. Это серьезно?

У меня такое впечатление, что ты меня не хочешь понять. Ладно, доведу до абсурда.

В 2007 году разработан новый язык для не знаю уж чего, который позволяет увеличить быстродействие в 5 раз, а сроки разработки сократить в 10 раз. Это серьезно ?

Ответ : как новое слово ИТ — это серьезно. Как пионерские исследования в этой области и даже пилотные проекты — это серьезно.Как технология — пока нет. До тех пор пока этот язык не будет принят индустрией, т.е разработаны для него промышленные (а не кустарные) компиляторы, IDE, ,библиотеки, средства сопряжения с унаследованным ПО и т.д.

И поэтому MS-DOS — это серьезно для индустрии того времени. А всякие самопальные ОС того времени — нет. Хотя среди них, возможно, была и лучшая, чем MS-DOS. И если сейчас создать новую ОС, лучшую, чем Windows и даже 100% совместимую с ней , иными словами, переписать Windows более эффективно (а это в принципе можно сделать), то это все равно для индустрии серьезно не будет. Пока Вы не найдете фирму с капиталом, позволяющим им выдвинуть этот продукт на рынок и создать конкуренцию MS.

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

Большая часть истории ВТ прошла на моих глазах. И всяких р-р-революционных изменений, претендующих в момент их появленияна то, чтобы ниспровергнуть все и вся , а через 2-3 года прочно забытых, я видел не так уж мало.

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

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

Вот простой пример. Алгол-60, безусловно, был во всех отношениях лучше Фортрана. Но тогдашний законодатель мод — фирма ИБМ — Фортран возлюбила, а Алгол — нет. В результате, несмотря на все его преимущества, Алгол помер (правда, породив наследника в виде Паскаля), а Фортран еще долго царствовал, да и ныне не мертв.

Другой пример. Модула-2 лучше Паскаля, наверное. Но Паскаль поддержала Борланд, а Модуле такая поддержка не была обеспечена. В ДОС еще какой-то компилятор был, а для Windows, может быть, он и существует (наверное существует), но о серьезной роли Модулы говорить не приходится.

Да и OS/2 по своим идеям была намного лучше Windows 3.x. Но Windows царствует, а где OS/2 ?

И уж совсем показательный пример. Где бы был Бейсик без Микрософт (или лично Б. Гейтса) ? . А что, Бейсик — это хорошо ? Это новые идеи ?


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

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

Возвращаясь к языкам программирования, выскажу мысль, с которой многие, может быть, не согласятся. Единственное серьезное нововведение, принятое промышленностью с 80-х годов — это объектно-ориентированное программирование. Как и положено тому, что побеждает, его победа была внушительной и быстрой. Оно действительно существенно изменило подход к разработке ПО. А все остальное- так, мелочи. И за исключением ООП С, а то и С#, не очень отличаются от Фортрана. Только ради бога, не надо подозревать меня в незнании последнего и напоминать мне об отсутвтвии в нем порядочного цикла, указателей и динамического выделения памяти. Мелочи все это...

Разумеется, пионерскими исследованиями и разработками заниматься надо, в конце концов именно из них и выходит то, что впоследствии будет принято индустрией. Но бросаться на каждую новую штучку и объявлять ее р-р-революцтонным нововведением — простите, смешно.

Лично мое отношение ко всем этим нововведениям — скептическое. В конце концов язык — это 1% от того, что должен знать программист. И освоить новый язык — не бог весть какой сложности задача. Освоили же ООП те, кто начинал до его промышленного появления, и ничего! Так что поживем — увидим. Если это действительно будет принято индустрией — освоим и будем употреблять. А если нет — значит, не судьба, и не стоит тратить на это время.

Так что если бы VladD2 (пофантазируем) захотел бы прочитать спецкурс по Немерле для студентов моего университета, я был бы только за и сделал бы все от меня зависящее, чтобы он состоялся ( Правда, не уверен, что его лично можно к студентам подпускать ). Но если бы кто-то предложил вместо существующей учебной практики на Паскале, С++, C# поставить Немерле — только через мой труп.

Здравствуйте, Pavel Dvorkin

Позволю себе парочку ремарок

PD>Другой пример. Модула-2 лучше Паскаля, наверное. Но Паскаль поддержала Борланд, а Модуле такая поддержка не была обеспечена. В ДОС еще какой-то компилятор был, а для Windows, может быть, он и существует (наверное существует), но о серьезной роли Модулы говорить не приходится.

На момент, когда Borlad выпустил Turbo Pascal, это была маленькая, мало кому вообще известная комания (см., например, Wikipedia). И поднялись они из-за того, что предложили самый лучший на тот момент компилятор Паскаля. Но Паскаль к тому времени уже был восстребован, что и позволило Turbo Pascal-ю стать успешно продаваемым продуктом (т.е. Borland продавал то, что было нужно покупателям, он не мог тогда навязать Паскаль тем, кому Паскаль не был нужен).

PD>Лично мое отношение ко всем этим нововведениям — скептическое. В конце концов язык — это 1% от того, что должен знать программист. И освоить новый язык — не бог весть какой сложности задача.

Может быть среди "знаний" знание языка -- это 1%. А вот среди "умений" владение языком занимает гораздо больший процент. Поскольку на основе "знаний" легко пытаться писать на C++, как на Smalltalk, на Ruby как на C++, а на Java -- как на C++. Только программы получаются такими, что сопровождать их не хочется.
К сожалению, впитывание идиом языка, освоение его best practices, требует гораздо больше времени и сил, чем простое ознакомление с синтаксисом, библиотеками и средствами разработки. И здесь нужен личный опыт, который можно приобрести только программируя на языке, а не "зная" его.

PD>Так что если бы VladD2 (пофантазируем) захотел бы прочитать спецкурс по Немерле для студентов моего университета, я был бы только за и сделал бы все от меня зависящее, чтобы он состоялся ( Правда, не уверен, что его лично можно к студентам подпускать ). Но если бы кто-то предложил вместо существующей учебной практики на Паскале, С++, C# поставить Немерле — только через мой труп.

Когда я учился в университете, я видел один очень большой недостаток в подготовке программистов -- никто не учил работать в команде. Сейчас виден и еще один -- никто не учит пользоваться языками программирования для написания больших программ. Отчитают семестр по C++, сделают десять лабораторных, по сто строк в каждой и все, галочка поставлена, язык освоен. Хотя реальная оценка и понимание того же C++ приходит только тогда, когда потребуется посопровождать тысяч эдак 20-30 строк кода. Вот так же и с Немере -- ну прочитают студентом спецкурс, что останется в сухом остатке, если они на собственной шкуре не усвоят, чем же 20K строк на Немерле лучше (хуже) аналогичного объема на C++? Так что, если уж говорить A (слушать курс по Немерле), то нужно уж и B сказать (дать людям возможность сделать на нем реальный проект).

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

> В следующий раз будет бан.

Был не прав, вспылил. Извиняюсь, конечно.

Но на своей точке зрения настаиваю: просто глупые мечты какие-то, а не повод для обсуждения.
Как правильно ПД далее указывает, даже если язык позволяет в 10 раз быстрее программить, от этого он не становится более "промышленным". А всяких маргинальных языков и так сейчас полно.
Спрашивается, чего людям нехватает? Есть С++, C#, Java... этого хватает за глаза.

E>Когда я учился в университете, я видел один очень большой недостаток в подготовке программистов -- никто не учил работать в команде.
Вот тут ты, имхо, точно подметил. Реально очень большая проблема, конечно, наверное, где-то уже обучают, но далеко не везде. Еще сейчас, по ходу работы, сталкиваюсь c софтом который написан "на коленке", потом дописан еще кем-то, потом еще кем-то... и опа.. поддерживать нереально... при том софт разный и коммерческий, и для бюджетной сферы... во втором случае все гораздо хуже...

E> Сейчас виден и еще один -- никто не учит пользоваться языками программирования для написания больших программ. Отчитают семестр по C++, сделают десять лабораторных, по сто строк в каждой и все, галочка поставлена, язык освоен. Хотя реальная оценка и понимание того же C++ приходит только тогда, когда потребуется посопровождать тысяч эдак 20-30 строк кода.
Наверно в этом и вопрос — как перейти от разработки кода в 100 строк к коду 20к-30к строк.

E>Вот так же и с Немере -- ну прочитают студентом спецкурс, что останется в сухом остатке, если они на собственной шкуре не усвоят, чем же 20K строк на Немерле лучше (хуже) аналогичного объема на C++? Так что, если уж говорить A (слушать курс по Немерле), то нужно уж и B сказать (дать людям возможность сделать на нем реальный проект).
Думаю, было бы лучше дать возможность сделать проект на любом из изучаемых языков. А кто и что выберет, имхо, его право. Тем более какой-то язык может подойди лучше, банально из-за существующих сторонних библиотек и т.п.

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

E>>Когда я учился в университете, я видел один очень большой недостаток в подготовке программистов -- никто не учил работать в команде.
P>Вот тут ты, имхо, точно подметил. Реально очень большая проблема, конечно, наверное, где-то уже обучают, но далеко не везде. Еще сейчас, по ходу работы, сталкиваюсь c софтом который написан "на коленке", потом дописан еще кем-то, потом еще кем-то... и опа.. поддерживать нереально... при том софт разный и коммерческий, и для бюджетной сферы... во втором случае все гораздо хуже...

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

E>> Сейчас виден и еще один -- никто не учит пользоваться языками программирования для написания больших программ. Отчитают семестр по C++, сделают десять лабораторных, по сто строк в каждой и все, галочка поставлена, язык освоен. Хотя реальная оценка и понимание того же C++ приходит только тогда, когда потребуется посопровождать тысяч эдак 20-30 строк кода.
P>Наверно в этом и вопрос — как перейти от разработки кода в 100 строк к коду 20к-30к строк.

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

E>>Вот так же и с Немере -- ну прочитают студентом спецкурс, что останется в сухом остатке, если они на собственной шкуре не усвоят, чем же 20K строк на Немерле лучше (хуже) аналогичного объема на C++? Так что, если уж говорить A (слушать курс по Немерле), то нужно уж и B сказать (дать людям возможность сделать на нем реальный проект).
P>Думаю, было бы лучше дать возможность сделать проект на любом из изучаемых языков. А кто и что выберет, имхо, его право. Тем более какой-то язык может подойди лучше, банально из-за существующих сторонних библиотек и т.п.

Так и я о том -- нашел проект (тем более если это часть производственной практике) для которого требуется Немерле -- делай его на Немерле. Не должно быть догматических ограничений, вроде "в мире правят C++, Java и C#", поэтому на Немерле ничего нельзя делать на производственной практике, пока он в этот список не войдет.

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

E>На момент, когда Borlad выпустил Turbo Pascal, это была маленькая, мало кому вообще известная комания

Как, впрочем, и Микрософт . В те времена в области персональных машин крупных компаний и не было. Тогда можно было нескольким фирмам делать компиляторы с С (MS, Borland, Watcom, Zortech..). Попробуйте сейчас


E>Может быть среди "знаний" знание языка -- это 1%. А вот среди "умений" владение языком занимает гораздо больший процент. Поскольку на основе "знаний" легко пытаться писать на C++, как на Smalltalk, на Ruby как на C++, а на Java -- как на C++. Только программы получаются такими, что сопровождать их не хочется.

И что ? Я по первому языку фортранщик (был и Алгол, но недолго). И цикл с GOTO назад для меня был привычкой и нормой. Но не помню, чтобы я хоть раз впоследствии такое написал на Паскале или С. Это все очень быстро усваивается.

E>К сожалению, впитывание идиом языка, освоение его best practices, требует гораздо больше времени и сил, чем простое ознакомление с синтаксисом, библиотеками и средствами разработки. И здесь нужен личный опыт, который можно приобрести только программируя на языке, а не "зная" его.

+1


E>Когда я учился в университете, я видел один очень большой недостаток в подготовке программистов -- никто не учил работать в команде. Сейчас виден и еще один -- никто не учит пользоваться языками программирования для написания больших программ. Отчитают семестр по C++, сделают десять лабораторных, по сто строк в каждой и все, галочка поставлена, язык освоен. Хотя реальная оценка и понимание того же C++ приходит только тогда, когда потребуется посопровождать тысяч эдак 20-30 строк кода.

Больной вопрос. В общем, согласен. Практически же это связано с таким количеством прочих факторов, что их обсуждение займет десятки страниц. Учебный график и его выполнение. Разный уровень студентов. Наличие серьезной задачи. Прочие дисциплины (от них же никто не освободит, а у студентов 30-35 часов в неделю, и только 4 из них — у меня). И т.д. И т.п.
То, что ты хочешь — в теории верно и разумно, а на практике порой просто неосуществимо. То , что ты хочешь, можно бы реализовать в виде неких курсов, когда учащиеся готовы на это тратить по 8 часов в неделю на протяжении месяца и более. Увы, это очень далеко от вузовской реальности.


>Вот так же и с Немере -- ну прочитают студентом спецкурс, что останется в сухом остатке, если они на собственной шкуре не усвоят, чем же 20K строк на Немерле лучше (хуже) аналогичного объема на C++? Так что, если уж говорить A (слушать курс по Немерле), то нужно уж и B сказать (дать людям возможность сделать на нем реальный проект).

Роль спецкурса не в этом. Его назначение — ознакомить с тем, что есть, дать направление, а там уж пусть сами вникают в глубину, если им надо. Спецкурс полугодовой у нас — 36 часов, годовой — 72 часа. Никаких серьезных программных продуктов за такое время не делают, а ведь большая часть спецкурса или вообще весь — это лекции.

Но, похоже, модератор выделит нас в отдельную ветку в "Образование и наука"

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

PD>И что ? Я по первому языку фортранщик (был и Алгол, но недолго). И цикл с GOTO назад для меня был привычкой и нормой. Но не помню, чтобы я хоть раз впоследствии такое написал на Паскале или С. Это все очень быстро усваивается.

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

PD>Больной вопрос. В общем, согласен. Практически же это связано с таким количеством прочих факторов, что их обсуждение займет десятки страниц. Учебный график и его выполнение. Разный уровень студентов. Наличие серьезной задачи. Прочие дисциплины (от них же никто не освободит, а у студентов 30-35 часов в неделю, и только 4 из них — у меня). И т.д. И т.п.
PD>То, что ты хочешь — в теории верно и разумно, а на практике порой просто неосуществимо. То , что ты хочешь, можно бы реализовать в виде неких курсов, когда учащиеся готовы на это тратить по 8 часов в неделю на протяжении месяца и более. Увы, это очень далеко от вузовской реальности.

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

>>Вот так же и с Немере -- ну прочитают студентом спецкурс, что останется в сухом остатке, если они на собственной шкуре не усвоят, чем же 20K строк на Немерле лучше (хуже) аналогичного объема на C++? Так что, если уж говорить A (слушать курс по Немерле), то нужно уж и B сказать (дать людям возможность сделать на нем реальный проект).

PD>Роль спецкурса не в этом. Его назначение — ознакомить с тем, что есть, дать направление, а там уж пусть сами вникают в глубину, если им надо. Спецкурс полугодовой у нас — 36 часов, годовой — 72 часа. Никаких серьезных программных продуктов за такое время не делают, а ведь большая часть спецкурса или вообще весь — это лекции.

Я против того, чтобы на каком-то этапе запретить пользоваться языком только из-за того, что он не в мейнстриме.

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

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

Как же? А Руби?

ЗЫ

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

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

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

ie>Пока нет.

Это почему это нет? У языка как раз есть маленькая классная библиотечка. Плюс огромная классная библиотека дотнета. По-моему, это то что нужно. По крайней мере другие языки даже мечтать об этом не могут.

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

На самом деле с точки зрения фичь все как раз в порядке. Только список этот можно смело отправить в помойку так как он не учитывает важных вещей. 1. Косность мышления людей. 2. Привязанность их к своим привычкам. 3. Простоту вхождения (а тут, книги, IDE, примеры...). 4. Пиар и другую рекламу.

Фактически без поддержки (причем прямой и мощьной, а не в рамках какого-нить Ротора) поддержки мегамонстра вроде MS, IBM или Sun путь к массовому потребителю будет долог и тернист.

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

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

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

АХ>>Путем использования "маргинального" Erlang получено сокращение сроков разработки и увеличение производительности.
АХ>>Приложение вполне практическое. Это серьезно?

PD>У меня такое впечатление, что ты меня не хочешь понять. Ладно, доведу до абсурда.

PD>В 2007 году разработан новый язык для не знаю уж чего, который позволяет увеличить быстродействие в 5 раз, а сроки разработки сократить в 10 раз. Это серьезно ?

PD>Ответ : как новое слово ИТ — это серьезно. Как пионерские исследования в этой области и даже пилотные проекты — это серьезно.Как технология — пока нет. До тех пор пока этот язык не будет принят индустрией,

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

PD>т.е разработаны для него промышленные (а не кустарные) компиляторы, IDE, ,библиотеки, средства сопряжения с унаследованным ПО и т.д.
Сейчас с этим стало проще. Достаточно написать биндинги для существующих библиотек промышленного качества.

Я уж не говорю, что если вы пишите язык для .NET/JVM, то сразу на халяву имеете библиотеки, run-time и back-end промышленного уровня.

Ну и тот же Linux. Создан вполне кустарно, тем не менее сейчас вполне принят индустрией.

Я считаю, что нужно выбирать язык и средства разработки под задачу.

А не "ну сейчас C# принят индустрией, будем писать на C#".
Причем в 80% случаях C# может быть действительно лучшим выбором. Но есть и еще 20%!

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

Q>Спрашивается, чего людям нехватает? Есть С++, C#, Java... этого хватает за глаза.
Мне нет.

Таблица сранения языкво от создателей D поправленная мной

Автор: VladD2
Дата: 18.05.06

Как думаете что мне больше всего нехватает в C# из Nemerle?

Автор: VladD2
Дата: 12.03.06

Паттерны суть слабости языков программирования

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

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

АХ>Вот с точки зрения бизнеса, почему бы мне не предпочесть эту технологию, если она позволяет (уже, а не в теории) мне работать более эффективно, а значит увеличить прибыль. Пусть даже она периферийная и для нее может быть меньше библиотек и IDE и они не вылизаны до блеска, но тем не менее достаточно для моих задач.

Кому именно — тебе ?
Если лично Андрею Хропову — бога ради, ни малейших возражений.
Но Андрей Хропов, руководитель софтверной фирмы с персоналом в 100-200 или более человек и разработками, требующими десятков и более человеко-лет, еще 100 раз подумает, стоит ли это делать. По причинам, о которых я уже писал и с которыми ты согласен, судя по плюсу.


АХ>Ну и тот же Linux. Создан вполне кустарно, тем не менее сейчас вполне принят индустрией.

Хм... Для индустрии персональной вычислительной техники Linux (и Unix вообще) именно типичная периферия. Вот у OS/2 могли быть шансы, если бы иначе сложилось... Могла быть неплохая конкуренция между ней и Windows, и это пошло бы на пользу отрасли, как и всякая конкуренция.
А про Linux — каково соотношение машин с Linux и машин с Windows в бизнесе или на домашних ПК ? Вот то-то и оно. А то, что его любителей среди профессионалов, полупрофессионалов и их знакомых не так уж мало — ничего не значит. Для индустрии.


АХ>Я считаю, что нужно выбирать язык и средства разработки под задачу.

Бога ради. Но см выше про двух А. Хроповых

P.S. Естественно, ничего личного. Речь идет о твоем однофамильце и тезке, не более

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

PD>Хм... Для индустрии персональной вычислительной техники Linux (и Unix вообще) именно типичная периферия. Вот у OS/2 могли быть шансы, если бы иначе сложилось... Могла быть неплохая конкуренция между ней и Windows, и это пошло бы на пользу отрасли, как и всякая конкуренция.
PD>А про Linux — каково соотношение машин с Linux и машин с Windows в бизнесе или на домашних ПК ? Вот то-то и оно. А то, что его любителей среди профессионалов, полупрофессионалов и их знакомых не так уж мало — ничего не значит. Для индустрии.

Ну посмотри на соотношение в сегменте x86 серверов
А если не только x86 серверов, то вообще
А ведь самый, что ни есть бизнес, требовательный весьма (решения 24x7 и с пятью девятками норовит требовать постоянно )

Кстати, если бы в России за ПО приходилось бы деньги платить, каково бы было соотношение Windows и Linux на домашних ПК?

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

E>Ну посмотри на соотношение в сегменте x86 серверов
E>А если не только x86 серверов, то вообще
E>А ведь самый, что ни есть бизнес, требовательный весьма (решения 24x7 и с пятью девятками норовит требовать постоянно )
Единственный способ обеспечить отказоустойчивость это кластер.
А уж какая ОСЬ стоит на этом кластере дело десятое.

E>Кстати, если бы в России за ПО приходилось бы деньги платить, каково бы было соотношение Windows и Linux на домашних ПК?
Такимже. Подавляющие большинство берет комп для того чтобы играть...

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

PD>И поэтому MS-DOS — это серьезно для индустрии того времени. А всякие самопальные ОС того времени — нет. Хотя среди них, возможно, была и лучшая, чем MS-DOS. И если сейчас создать новую ОС, лучшую, чем Windows и даже 100% совместимую с ней , иными словами, переписать Windows более эффективно (а это в принципе можно сделать), то это все равно для индустрии серьезно не будет. Пока Вы не найдете фирму с капиталом, позволяющим им выдвинуть этот продукт на рынок и создать конкуренцию MS.
Уже все есть: и система, и фирма...
Полуось и IBM...
Полуось — гораздо лучше форточек написана...

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

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

Ну-ка, ну-ка, раскажи нам по больше про эти языки? Это не Руби случаем? Он с трудом 3 из 10 наберет. А вещи вроде вывода итпов вообще входят в конфлик с сутью его основ (того же метапрогарммирования).

ЗХ>Имеется в виду то же, что было сказано про GC — их должно быть несколько, для конкуренции и постоянного улучшения.

Конкурируютя алгоритмы. Вот для того же дотнета и Явы есть 2-4 алгоритма для каждой из платформ.
И Ява и дотнет жувут с одной реализацией и являются лидерами. Тут даже обсуждать нечего.

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

Интересно как? Без того самого вывода типов тут ничего не будет. А с ним не будет Руби.

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

С этим только у Руби проблемы и есть. В Яве есть Свинг. В дотнете есть ВыньФормс, ГТК и WPF (бывший Avalon). Остальные тут просто вне конкуренции.

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

Мета — это "что делается". Макро — это "как делается". Макросы и есть средвство метапрограммирования. Просто взяли терминалогию из Лиспа.

ЗЫ

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

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

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

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

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

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

Вывод типом там похож на Немерловый. Для выражений (т.е. не для топ-левел-конструкция). Но алгоритм слабее.

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

ie>б) ближе всего к идеалу Ruby, Lisp, OCaml, Erlang
ie>в) но у каждого из них свои недостатки.
ie>[/q]
ie>Только вот Scala и Nemerle бы в его списочек добавил

Ага, а Ruby, Lisp, OCaml, Erlang выкинуть как не удовлетворяющие критериям.

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

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

Далего не только. Кобол, Руби и уж темболее Ява можно просто хостить на том же рантайме. Версии для дотнет и Явы у этих язков есть. Только Руби здесь конечно приплетен в виду собвственных предпочтений. Реально достаточно Кобла и Явы. Причем Кобол тоже под большим вопросом. Но раз уж есе это есть...

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

ie>>Есть.
АХ>Ну пока нет.

Согласен. И это самое грусное.

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

Где? F# такой же проект только ведется чуть ближе к МС (в МС Ресерче). Но перспектив у него почти нет.

АХ>Хотя по мне так Nemerle намного лучше. Наверное все от незнания о Nemerle.

Дык F# это пакрически смесь ОКамла с МЛ-ем срощенная с дотнетом. Все МЛ-подобные языки и ОКамл в частности очень своеобразны и практически не вероятно, что они станут популяры. А Немерле спокойно можно рассматривать как развитие C#.

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

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

+1 плюс еще своя Nemerle.dll.

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

AVK>Это чего это тут вотчина VladD2?

Дык в соседа не плюнешь и весь день на смарку.

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

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

Дык он же не фортрановый человек, а рубиновый. А в Руби тормоза — это главная беда. Так что по сравнению с ним любой Джит — это трофейный мессер.

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

C>Статический анализ поможет, но не сильно. Дело в том, что на протяжении
C>жизни приложения горячие точки могут перемещаться в коде и иногда наша
C>оптимизация может стать пессимизацией.

+1

C>Так что за HotSpot — будущее. Кстати, на многопроцессорных системах
C>можно анализатор HotSpot запускать на выделенном ядре.

Не-а. Будущее за гибридом время от вермени собирающим информацию о приложении и использующем простои процессора (или работу в бэкграунде) для перестройки оптимизированного кода.

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

E>А я говорю о людях. Понятие 'массового' программиста -- это абстракция.

Да, да. Поняите люди конечно более абстракно.

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

PD>Так что если бы VladD2 (пофантазируем) захотел бы прочитать спецкурс по Немерле для студентов моего университета, я был бы только за и сделал бы все от меня зависящее, чтобы он состоялся ( Правда, не уверен, что его лично можно к студентам подпускать ). Но если бы кто-то предложил вместо существующей учебной практики на Паскале, С++, C# поставить Немерле — только через мой труп.

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

Кстати, поляки делают очень подлый и хитрый ход. Не надеясь на быструю популяризацию своего языка учат своих студентов именно на Немерле. А надо учитывать, что они вступили в евросоюз. Это значит, что их студенты в ближайшее время начнут пополнять кадры европейских компаний (не в польше же им работать?). А это значит, что ползучая зараза начнет проникать по всюду.

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

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

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

VladD2 wrote:
> C>Так что за HotSpot — будущее. Кстати, на многопроцессорных системах
> C>можно анализатор HotSpot запускать на выделенном ядре.
> Не-а. Будущее за гибридом время от вермени собирающим информацию о
> приложении и использующем простои процессора (или работу в бэкграунде)
> для перестройки оптимизированного кода.
Ты только что описал механизм работы HotSpot

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

PD>Большая часть истории ВТ прошла на моих глазах. И всяких р-р-революционных изменений, претендующих в момент их появленияна то, чтобы ниспровергнуть все и вся , а через 2-3 года прочно забытых, я видел не так уж мало.

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

PD>Лично мое отношение ко всем этим нововведениям — скептическое. В конце концов язык — это 1% от того, что должен знать программист. И освоить новый язык — не бог весть какой сложности задача.

Очень спорное утверждение. К тому же опасное.

PD>Так что если бы VladD2 (пофантазируем) захотел бы прочитать спецкурс по Немерле для студентов моего университета, я был бы только за и сделал бы все от меня зависящее, чтобы он состоялся ( Правда, не уверен, что его лично можно к студентам подпускать ). Но если бы кто-то предложил вместо существующей учебной практики на Паскале, С++, C# поставить Немерле — только через мой труп.

И совершенно напрасно. Если уж 1% про язык сказано не ради красного словца, то как раз на Немерле и надо учить студентов. В Немерле в одном языке собрано практически всё стоящее, что известно на сегодняшний день. Всё в одном флаконе. Следовательно, студентов можно не парить целым языковым зверинцем, Вот вам деточки Немерле и на его основе ООП, компонентный подход, аспекты, функциональщина, метапрограммирование. Не надо забивать голову разными синтаксисами, можно приводить примеры разных подходов и сравнивать их на одном и том же языке.

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

AVK>Это чего это тут вотчина VladD2?

Ну...

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

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

АХ>>Вот с точки зрения бизнеса, почему бы мне не предпочесть эту технологию, если она позволяет (уже, а не в теории) мне работать более эффективно, а значит увеличить прибыль. Пусть даже она периферийная и для нее может быть меньше библиотек и IDE и они не вылизаны до блеска, но тем не менее достаточно для моих задач.

PD>Кому именно — тебе ?
PD>Если лично Андрею Хропову — бога ради, ни малейших возражений.
PD>Но Андрей Хропов, руководитель софтверной фирмы с персоналом в 100-200 или более человек и разработками, требующими десятков и более человеко-лет, еще 100 раз подумает, стоит ли это делать. По причинам, о которых я уже писал и с которыми ты согласен, судя по плюсу.
где плюс?

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

Ну и вообще у меня нет пиитета перед большими проектами. Там, как правило и задачи типовые, и код не слишком высокого качества, посколько нанимать много квалифиц. спецов — дорого.
Чаще в Индию отдают.

А так любимая тобой индустрия включает в себя и Google и Яндекс, где используют Python, и множество сайтов на Linux+Apache+MySQL+PHP/Perl и конторы где используют AutoCAD с Lisp.

И это реальный бизнес, который приносит доход. Может быть не такой как у MS или Oracle, но тем не менее вполне ощутимо.

АХ>>Ну и тот же Linux. Создан вполне кустарно, тем не менее сейчас вполне принят индустрией.

PD>Хм... Для индустрии персональной вычислительной техники Linux (и Unix вообще) именно типичная периферия.
Для десктопов — да, но еще посмотрим что дальше будет.

Но основные деньги то на серверном рынке.

Вот статистика по сайтам за Сентябрь:

Apache 59699872 сайтов — 61.64 %
Microsoft IIS 30272249 сайтов — 31.26 %
... (другие)
(отсюда)
Как видно сайтов на Апаче больше в 2 раза.

Вот исследование доходов на серверном рынке:

здесь
Как видно доля дохода по Windows серверам — 37%, а по Linux — 12%.
Но разница в 3 раза — не так уж много, это не периферия, тем более что самые крупный игрок — IBM сейчас поддерживает Linux.
И те 33% которые сейчас все еще на Unix вероятнее переползут на Linux.
(да твоя фраза про "Unix вообще" — здесь у них суммарно 45%, что больше 37% Windows )

Ну и надо заметить что на рынке встроенных систем у Linux весьма неплохие позиции.

Тем более, что Playstation 3 будет поставляться с предустановленным Linux.

Я совсем не фанат Linux, но это уже далеко не периферия.

PD> Вот у OS/2 могли быть шансы, если бы иначе сложилось... Могла быть неплохая конкуренция между ней и Windows, и это пошло бы на пользу отрасли, как и всякая конкуренция.
PD>А про Linux — каково соотношение машин с Linux и машин с Windows в бизнесе или на домашних ПК ? Вот то-то и оно. А то, что его любителей среди профессионалов, полупрофессионалов и их знакомых не так уж мало — ничего не значит. Для индустрии.
Это справедливо только для России.
И то во-многом по тому, что так как пиратская Windows и софт к ней фактически бесплатен. И к ней (ну и Офису естественно ) многие привыкают.

Хотя с точки зрения бизнеса важнее TCO, и в этом случае все неоднозначно.

С другой стороны, если вы работаете с Windows постоянно приходится обновлять дорогое ПО и Железо (вон чтобы Висту установить нехилая система будет нужна!),
для Linux это не обязательно, поскольку основные стандарты не меняются и многое ПО там бесплатно.

PD>P.S. Естественно, ничего личного. Речь идет о твоем однофамильце и тезке, не более

Да, есть такие.

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

LVV>Полуось — гораздо лучше форточек написана...
Не уверен. Да, архитектура у Win 9x была плоха.
А вот Win NT-XP-2003 куда лучше.
Бывшие разработчики из DEC разрабатывали.

А так OS/2 ек: здесь.

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

[skip]

>Темные века программирования
че топик-то такой мрачный? (или поэтический)
где темнота, где века?

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

>>Темные века программирования
RA>че топик-то такой мрачный? (или поэтический)
RA>где темнота, где века?

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

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


VD>Кстати, поляки делают очень подлый и хитрый ход. Не надеясь на быструю популяризацию своего языка учат своих студентов именно на Немерле. А надо учитывать, что они вступили в евросоюз. Это значит, что их студенты в ближайшее время начнут пополнять кадры европейских компаний (не в польше же им работать?). А это значит, что ползучая зараза начнет проникать по всюду.

вставай, страна огромная, вставай на смертный бой

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

C>Ты только что описал механизм работы HotSpot

Описать механизм торговой марки вообще нельзя.

Но пока что по этому принципу не работает ни один JIT. Они все или полностью живут в рантайме или наоборот в компайлтайме.

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

PD>>Так что если бы VladD2 (пофантазируем) захотел бы прочитать спецкурс по Немерле для студентов моего университета, я был бы только за и сделал бы все от меня зависящее, чтобы он состоялся ( Правда, не уверен, что его лично можно к студентам подпускать ). Но если бы кто-то предложил вместо существующей учебной практики на Паскале, С++, C# поставить Немерле — только через мой труп.

IT>И совершенно напрасно. Если уж 1% про язык сказано не ради красного словца, то как раз на Немерле и надо учить студентов. В Немерле в одном языке собрано практически всё стоящее, что известно на сегодняшний день. Всё в одном флаконе. Следовательно, студентов можно не парить целым языковым зверинцем, Вот вам деточки Немерле и на его основе ООП, компонентный подход, аспекты, функциональщина, метапрограммирование. Не надо забивать голову разными синтаксисами, можно приводить примеры разных подходов и сравнивать их на одном и том же языке.

Мнение, конечно, имеет право на существование...
Но вы очень уж "далеки от народа"... Как препод могу совершенно определенно сказать. что первый язык выучивается "наизусть"... Практически студентам-первачкам требуется директивным образом давать указания: вот это, деточки, делается таким способом, а это — вот таким...
Это потом уже, курсе на третьем, студент начинает осознанно пользоваться языком... А до того — большинство учит как иностранный язык... Тем более, что у нас в универ очень многие приходят фактически за профессией программера, а не за высшим образованием как таковым. Хотя небольшая группа очень толковых ребят у нас есть почти всегда... Вот им немерля — очень интересен... А большинству — не-а...
Последнее время с все больше склоняюсь к мысли, что первачкам нужно начинать на додиезе... Благо — техника стала позволять, и дотнет лицензионный... А потом С++... Паскаль — только как чисто практическую технологию Дельфи...
Немерлю можно давать тоже, но курсе на третьем или даже 4-м -как достижение в области программерства...

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

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

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

Можно подробней? Про quatations видал, даже баловался с ними маленько, но про что-то аля Немерл-макросы

АХ>Хотя по мне так Nemerle намного лучше. Наверное все от незнания о Nemerle.

+1

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

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

С одной стороны согласен, а с другой, постоянно чего-то нехватает и пришодится искать на sourceforge'ах

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

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

Так одно из вышеприведенных условий — хорошее финансирование. Кто мешает при хорошем финансировании создать большой базовый набор для старта?

VladD2 wrote:
> C>Ты только что описал механизм работы HotSpot
> Описать механизм торговой марки вообще нельзя.
HotSpot compiler — это уже скорее термин. Даже сама солнцевская братва
употребляет его как термин, а не как HotSpot (tm).

> Но пока что по этому принципу не работает ни один JIT. Они все или
> полностью живут в рантайме или наоборот в компайлтайме.
Явавский HotSpot так уже много лет работает — в фоне (а в 1.6 еще и по
возможности на другом процессоре) собирает статистику и оптимизирует код
по этой статистике. Оптимизированный код, при желании, может
кэшироваться в одном большом изображении (что используется для ускорения
запуска JVM).

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

LVV>Немерлю можно давать тоже, но курсе на третьем или даже 4-м -как достижение в области программерства...

А в чем, на Ваш взгляд (как преподавателя), заключается это достижение?

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

LVV>Немерлю можно давать тоже, но курсе на третьем или даже 4-м -как достижение в области программерства...

На самом деле Немерле можно давать по началу как подмножество Шарпа. Так что если считаете, что можно начинать с Шарпа, то можно начинать и с Немерла. Разницы почти не будет.

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

LVV>>Немерлю можно давать тоже, но курсе на третьем или даже 4-м -как достижение в области программерства...
AVC>А в чем, на Ваш взгляд (как преподавателя), заключается это достижение?

В непохожести на Оберон.

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

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

LVV>>>Немерлю можно давать тоже, но курсе на третьем или даже 4-м -как достижение в области программерства...
AVC>>А в чем, на Ваш взгляд (как преподавателя), заключается это достижение?

VD>В непохожести на Оберон.

Ну, видимо, это уже само по себе большое достижение.
Так что — достойно, достойно.
Правда, я слыхал, что Немерле живет пока только под дотнетом (правильно?), а там, если посмотреть, есть-таки что-то общее с Обероном, тут никуда не денешься.
А если посмотреть на синтаксические изыски (макросы, то да се), то, ИМХО, трудно не признать брата Васю — реинкарнацию старой идеи расширяемых языков.
Я о похожих изысках еще в детской книжке Вирта "Алгоритмы + структуры данных = программы" читал.
Пока что впечатление такое, что нашли еще один способ реализовать старую и сомнительную, в принципе, идею.

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

AVC>Ну, видимо, это уже само по себе большое достижение.
AVC>Так что — достойно, достойно.
AVC>Правда, я слыхал, что Немерле живет пока только под дотнетом (правильно?), а там, если посмотреть, есть-таки что-то общее с Обероном, тут никуда не денешься.

Кроме ЖЦ общего там не много. Хотя Немерле неплохо живет и под Моно.

AVC>А если посмотреть на синтаксические изыски (макросы, то да се), то, ИМХО, трудно не признать брата Васю — реинкарнацию старой идеи расширяемых языков.

Это и признавать нет смысла. Это факт. Разработчики об этом говорят на первой же странице сайта. Только это еще одна непохожесть на Оберон.

AVC>Я о похожих изысках еще в детской книжке Вирта "Алгоритмы + структуры данных = программы" читал.
AVC>Пока что впечатление такое, что нашли еще один способ реализовать старую и сомнительную, в принципе, идею.

Лично у меня сомнения только в одном. В том что Вирт прав в своих рассуждениях.
Мноие его мысле интересны и правильны, но его кругозор явно ограничен, в ледствии чего мнение предвзято.

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

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

AVC>>Правда, я слыхал, что Немерле живет пока только под дотнетом (правильно?), а там, если посмотреть, есть-таки что-то общее с Обероном, тут никуда не денешься.

VD>Кроме ЖЦ общего там не много. Хотя Немерле неплохо живет и под Моно.

Как мне кажется, таких общих черт может быть еще несколько, например:

• динамическая модульность и расширяемость программной системы (в этом была цель дизайна)
  
• type-safety с контролем типов через границы модулей (а это, вкупе со сборкой мусора, главный инструмент достижения цели)
  
• аплеты (последнее больше к Java; появились в Обероне в начале 90-х при портировании Оберона на MacOS, "сидевшей" на нескольких аппаратных платформах)

AVC>>Я о похожих изысках еще в детской книжке Вирта "Алгоритмы + структуры данных = программы" читал.
AVC>>Пока что впечатление такое, что нашли еще один способ реализовать старую и сомнительную, в принципе, идею.

VD>Лично у меня сомнения только в одном. В том что Вирт прав в своих рассуждениях.
VD>Мноие его мысле интересны и правильны, но его кругозор явно ограничен, в ледствии чего мнение предвзято.

VD>В принципе у меня была идея предложить ему развернутое интервью (переписку мы с ним уже Вели, так что это в принципе возможно). Только нужно хорошенько сформулировать вопросы и качественно перевести их на английский чтобы он не начал отвечать на собственные вопросы.

Это очень хорошая идея.
В свое время у меня были вопросы к Вирту (как раз по поводу невключения некоторых конструкций в язык).
После визита Вирта в Россию осенью 2005 года было предложено сформулировать вопросы, чтобы Вирт впоследствии на них ответил (видимо, письменно).
Я отправил свой вопрос.
Но то ли это интервью не состоялось, то ли мой вопрос затерялся среди сотен других, ответа я, к сожалению, не получил.
Меня, собственно, интересовал вопрос о том, почему не получила развития идея Роу и Шиперского о "облегченном" полиморфизме для Оберона, предложенная ими в статье
http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz
в 90-х гг.
Если все-таки дело дойдет до интервью, то, если будет возможность, спроси его, пожалуйста.
Меня интересует: дело в каких-то технических трудностях, или это принципиальная позиция (мол, ну его нафиг, этот параметрический полиморфизм)?
Ведь даже в Зонноне (а это уже далеко не такой простой язык, как оригинальный Оберон) эта идея не прижилась.
Собственно, Оберону, ИМХО, не хватает только параметрического полиморфизма для (моего ) полного счастья, но его-то как раз там и нет (не считая отдельных реализаций)...

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


AVC>Как мне кажется, таких общих черт может быть еще несколько, например:
AVC>

AVC>
• динамическая модульность и расширяемость программной системы (в этом была цель дизайна)
  AVC>
• type-safety с контролем типов через границы модулей (а это, вкупе со сборкой мусора, главный инструмент достижения цели)
  AVC>
• аплеты (последнее больше к Java; появились в Обероне в начале 90-х при портировании Оберона на MacOS, "сидевшей" на нескольких аппаратных платформах)
  AVC>

Такие общие черты можно найти в большинстве современных языков. Кстати, я не сказал бы, что Оберон типобезопасный. Я уже слышал как минимум вариант с возвратом ссылки на локальные данные извне метода. Это противоречит приципам типобезопасности.

Аплетов же в дотнете не было от родясь. Так что модульность, а точнее компонентность главная общая особенность. Не много, по-моему.

VD>>В принципе у меня была идея предложить ему развернутое интервью (переписку мы с ним уже Вели, так что это в принципе возможно). Только нужно хорошенько сформулировать вопросы и качественно перевести их на английский чтобы он не начал отвечать на собственные вопросы.

AVC>Если все-таки дело дойдет до интервью, то, если будет возможность, спроси его, пожалуйста.

Можно попробовать набрасать список вопросов и потом мы попробуем связаться с ним и задать их ему, так сказать от всего русского комьюнити.

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

AVC>>Как мне кажется, таких общих черт может быть еще несколько, например:
AVC>>

AVC>>
• динамическая модульность и расширяемость программной системы (в этом была цель дизайна)
  AVC>>
• type-safety с контролем типов через границы модулей (а это, вкупе со сборкой мусора, главный инструмент достижения цели)
  AVC>>
• аплеты (последнее больше к Java; появились в Обероне в начале 90-х при портировании Оберона на MacOS, "сидевшей" на нескольких аппаратных платформах)
  AVC>>

VD>Такие общие черты можно найти в большинстве современных языков. Кстати, я не сказал бы, что Оберон типобезопасный. Я уже слышал как минимум вариант с возвратом ссылки на локальные данные извне метода. Это противоречит приципам типобезопасности.

Несомненно, противоречит.
Именно поэтому в Обероне нет такой замечательной возможности.
Я догадываюсь, что ты имеешь в виду мое короткое препирательство с FR и Курилкой на тему (псевдо)замыканий в Паскале.
Я там в посте
http://www.rsdn.ru/Forum/Message.aspx?mid=2133481&amp;only=1

Автор: AVC
Дата: 27.09.06

как раз распространялся на тему, почему (псевдо)замыкания были в старом Паскале, и почему их совсем нет в Обероне.
Предположительно, причина в том, что в Обероне есть процедурные переменные (указатели на функции в терминологии Си), которых не было в Паскале.
Я предположил, что Оберон запрещает присваивать локальную процедуру процедурной переменной именно по причине небезопасности такой операции.
Т.о. в Обероне замыканий нет, что, ИМХО, компенсируется наличием в нем объектов (которых, наоборот, не было в Паскале).

VD>Аплетов же в дотнете не было от родясь. Так что модульность, а точнее компонентность главная общая особенность. Не много, по-моему.

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

VD>Можно попробовать набрасать список вопросов и потом мы попробуем связаться с ним и задать их ему, так сказать от всего русского комьюнити.

Возможно, имеет смысл организовать ветку "Какой вопрос ты бы хотел задать Никлаусу Вирту".
Затем отобрать в пределах десятка лучших (наиболее принципиальных) вопросов и попросить его ответить.
(Думаю, что полноценно ответить на большее их количество уже довольно трудно.)

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

AVC>По моему, ты прав: не просто модульность, а именно компонентность объединяет (как пуповина) дотнет с Обероном.

КОП появился задолго до оберона. Так что находить здесь связь .net именно с обероном — это явно предвзятая идея.

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

Д>КОП появился задолго до оберона.

Хотя бы приблизительную дату можешь назвать?

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

E>Хотя бы приблизительную дату можешь назвать?

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

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

E>>Хотя бы приблизительную дату можешь назвать?

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

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

Но сделаем еще один шаг -- может быть ты перечислишь хотя бы несколько первых языков, получивших серьезное распространение (хотя бы на уровне Modula-2, Eiffel, Ada или Oberon), которые непосредственно поддерживали КОП. Только дай, пожалуйста, четкий ответ.

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

E>>Кстати, если бы в России за ПО приходилось бы деньги платить, каково бы было соотношение Windows и Linux на домашних ПК?
WH>Такимже. Подавляющие большинство берет комп для того чтобы играть...

это конечно больше из СВ, но "подовляюее большинство, берущее комп чтобы играть" элементарно разорилось бы, если бы "за ПО приходилось бы платить" .

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

Д>КОП появился задолго до оберона. Так что находить здесь связь .net именно с обероном — это явно предвзятая идея.

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

"Я так думаю..." (с) "Мимино"

Найди мне, пожалуйста, хоть один источник, относящий пайпы к КОП.
Возьмем, к примеру, статью из Википедии о компонентности:
http://en.wikipedia.org/wiki/Software_componentry
Там раздел Pipes and Filters четко отделен от Component-oriented programming.
А что относится к Component-oriented programming?
Вот приведенный там список:

• Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
  
• XPCOM from Mozilla Foundation
  
• VCL and CLX from Borland and similar free LCL library.
  
• Enterprise Java Beans from Sun Microsystems
  
• UNO from the OpenOffice.org office suite
  
• Eiffel programming language
  
• Oberon programming language and BlackBox
  
• Z++ programming language
  
• Bundles as defined by the OSGi Service Platform
  
• NexWave Software Infrastructure (NSI)
  
• The System.ComponentModel namespace in Microsoft .NET

И Оберон, и дотнет есть в этом списке.
Если учесть возраст элементов в списке, то, кажется, остаются только Эйфель и Оберон.
Как минимум, уже очевидно, что КОП не "появился задолго до Оберона".
Эйфель — интересный (но большой и сложный) язык, мейеровский принцип "программирования по контракту" — очень хорошая идея.
Но Оберон — не только язык. С 1986 по 1989 был создан не только (и не столько) типо-безопасный язык со сборкой мусора, и даже не только целая ОС, основанная на динамически загружаемых модулях, а именно определенная компонентная технология, которая, с минимальными поправками, и стала впоследствии называться КОП.
Не удивительно, что одну из самых (если не самую) известных книг по КОП написал "оберонщик" Шиперски; не удивительно и то, что впоследствии он был одним из архитекторов .NET.

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

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

E>>>Кстати, если бы в России за ПО приходилось бы деньги платить, каково бы было соотношение Windows и Linux на домашних ПК?
WH>>Такимже. Подавляющие большинство берет комп для того чтобы играть...

_>это конечно больше из СВ, но "подовляюее большинство, берущее комп чтобы играть" элементарно разорилось бы, если бы "за ПО приходилось бы платить" .
Не думаю, сейчас доходы населения растут, все джипы покупают, так что и на игры деньги уж наскребут как-нибудь.
Ну и приставки же покупают, а там игры в основном не пиратские.

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

Немного добавлю.
Заглянем в Википедию:
http://en.wikipedia.org/wiki/Oberon_programming_language
Там есть одио очень интересное утверждение.

Classes and Type extension

In contrast to Object-Oriented programming languages, Oberon-2 belongs to the Component-Oriented family. Programs are written as a collection of related service modules, each of which provides a number of publically accessible procedures and variables. Classes are represented by data records, which are interconnected by pointer variables (see example above). The declaring module may provide type-bound procedures (see example above) so that a given name refers to different procedures according to the type of the record.

Интересно, какой другой современный Оберону язык можно было бы отнести к "компонентно-ориентированному семейству"?
Видимо, отличие от компонентно-ориентированного подхода от других менее бросается в глаза, не так выделяется синтаксически, по сравнению с ФЯ или Смоллтоком.
Поэтому самая настоящая компонентная "революция" Оберона прошла в свое почти незаметно, пока те же самые идеи не стала продвигать Sun.
Приписав все новаторство себе, разумеется.

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

_>>это конечно больше из СВ, но "подовляюее большинство, берущее комп чтобы играть" элементарно разорилось бы, если бы "за ПО приходилось бы платить" .
АХ>Не думаю, сейчас доходы населения растут,

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

АХ>все джипы покупают, так что и на игры деньги уж наскребут как-нибудь.

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

АХ>Ну и приставки же покупают, а там игры в основном не пиратские.

чесслово давно не встречал приставок. и в магазинах не видел.

зы. в "не в москве" были? если нет, то рекомендую взглянуть что там и как.

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

ГВ>Ну...

Это не показатель.

eao197 wrote:
> Д>КОП появился задолго до оберона.
> Хотя бы приблизительную дату можешь назвать?
Где-то 60-е годы

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

>> Д>КОП появился задолго до оберона.
>> Хотя бы приблизительную дату можешь назвать?
C>Где-то 60-е годы

где-то... кто-то... когда-то...
Короче — лишь бы не...


Впрочем, оно (то самое) все же попадается:
http://www.enlight.ru/ib/news/21.07.2003_27.07.2003.html

Компонентно-ориентированное программирование было предложено Hиклаусом
Виртом году эдак в 1987.

AVC wrote:
> Компонентно-ориентированное программирование было предложено Hиклаусом
> Виртом году эдак в 1987.

The idea that software should be componentized, built from prefabricated
components, was first published in Douglas McIlroy's address at the NATO
conference on software engineering in Garmisch, Germany, 1968 titled
Mass Produced Software Components. This conference set out to
counter the so-called software crisis. His subsequent inclusion of pipes
and filters into the Unix operating system was the first implementation
of an infrastructure for this idea.

The modern concept of a software component was largely defined by
Brad Cox of Stepstone, who called them Software ICs and set out to
create an infrastructure and market for these components by inventing
the Objective-C programming language. (He summarizes this view in
his book Object-Oriented Programming — An Evolutionary Approach 1986.)

Так что идеи были задолго до Оберона. А еще был язык Cedar, с которого
брали пример Страуструп для С++ и Вирт для Модула-2

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

>> Компонентно-ориентированное программирование было предложено Hиклаусом
>> Виртом году эдак в 1987.
C>

C>The idea that software should be componentized, built from prefabricated
C>components, was first published in Douglas McIlroy's address at the NATO
C>conference on software engineering in Garmisch, Germany, 1968 titled
C>Mass Produced Software Components. This conference set out to
C>counter the so-called software crisis. His subsequent inclusion of pipes
C>and filters into the Unix operating system was the first implementation
C>of an infrastructure for this idea.

C>The modern concept of a software component was largely defined by
C>Brad Cox of Stepstone, who called them Software ICs and set out to
C>create an infrastructure and market for these components by inventing
C>the Objective-C programming language. (He summarizes this view in
C>his book Object-Oriented Programming — An Evolutionary Approach 1986.)

C>Так что идеи были задолго до Оберона. А еще был язык Cedar, с которого
C>брали пример Страуструп для С++ и Вирт для Модула-2

Все это было.
И у МакИлроя (собственно создавшего штамп "кризис программного обеспечения"), и у Кокса были замечательные идеи.
Идеи первого привели к созданию пайпов и фильтров.
Второй полагал, что объекты (сами по себе) и суть те самые ICs.

Но совсем не пайпы составляют основу компонентного подхода, роднящего дотнет и Оберон.
Идея Бреда Кокса об объектах как аналогах интегральных схем (он воплощал ее виде Си со смоллтоковскими вставками) не удалась.
Так что это шаги в правильном направлении, но совсем не идентичные КОП.
КОП стало впервые возможным только в сообществе, занимающемся модульными языками.
Тот же Шиперски написал не одну статью, разжевывая, почему недостаточно одних классов, а нужны еще и модули.
Модули языка Модула-2 уже в 1970-е были близки к компонентам (легко видеть, насколько Оберон близок Модуле-2).
Чтобы создать динамическую расширяемую модульную систему, не хватало типо-безопасности и сборки мусора.
Из языка Модула-2 были устранены небезопасные (в особенности, вариантные записи) и просто необязательные конструкции, введено расширение типов (практически ООП).
Были введены поддержка динамической модульности, дескрипторы типов и сборка мусора.
Сборка мусора была введена не из пустопорожнего подражания ФЯ, а в связи с другой мотивировкой (если состав модулей заранее неизвестен и переменчив, мы не можем обеспечить корректность "ручного" освобождения памяти).
Вот эта совокупность технических решений и составляет сейчас ядро КОП.
Я и имею в виду конкретные технические решения, а не что-то "отдаленно похожее", и уж тем более не простое созвучие (сказал кто-то "компонент", все — он "автор идеи").
Патенты выдают на реальные изобретения, а не простые благие пожелания.

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

AVC>Т.о. в Обероне замыканий нет, что, ИМХО, компенсируется наличием в нем объектов (которых, наоборот, не было в Паскале).


ОК, но это еще одно различие, так как в C# (дотнет не язык чтобы обладать языковыми конструкциями) замыкания таки есть. И это очень удобно во многих случаях.

AVC>По моему, ты прав: не просто модульность, а именно компонентность объединяет (как пуповина) дотнет с Обероном.

Ага.

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

Не-а. Не вытикают. Примеры? Их есть у меня... COM! И этим все сказано. В нем нет ни сборки мусора, ни безопасности. Но он является одной из первый промышленных компонентных систем.

AVC>Если ты считаешь, что это "немного", то мне интересно, что же для тебя "много"?

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

VD>>Можно попробовать набрасать список вопросов и потом мы попробуем связаться с ним и задать их ему, так сказать от всего русского комьюнити.

AVC>Возможно, имеет смысл организовать ветку "Какой вопрос ты бы хотел задать Никлаусу Вирту".

Возможно. Но боюсь, что в этом форуме это превраится в очередной флэйм.

AVC>Затем отобрать в пределах десятка лучших (наиболее принципиальных) вопросов и попросить его ответить.

Мне кажется вопросы должны иметь общую линию. Иначе это будет очерденое пустословие с общими и мало что говорящими ответами. Я бы даже хотел видеть дисскусию в какмо-то смысле. Чтобы на ответ "ля-ля-ля" можно было бы уточнить "а почему собственно?".

AVC>(Думаю, что полноценно ответить на большее их количество уже довольно трудно.)

Именно потому и хочется чтобы вопросы имели общую канву.

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

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

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

1968 год если верить http://en.wikipedia.org/wiki/Component-oriented_programming