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

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

Наивно, имхо, в вотчине 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'и внутри или вне языка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 сказать (дать людям возможность сделать на нем реальный проект).

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

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

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

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

Как-то так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AVC>>Известно,

AVK>Кому известно?

AVC>> что виртовские компиляторы Модулы-2 и Оберона тщательно изучались в Sun (об этом и Вирт говорил;

AVK>Вирт в Sun работал? Ссылки на точные цитаты Вирта в студию.

Вот что пишут по указанной мной сылке:

in Prof. Wirth's festschrift "The School of Niklaus Wirth — The Art of
Simplicity" there is an essay by Robert Griesemer and Srdjan Mirovic
of Sun Microsystems called "A Compiler for the Java HotSpot Virtual
Machine". The abstract includes the following "Its code generator was
strongly influenced by the design of Niklaus Wirth's Modula-2 and
Oberon compilers" and goes on to mention that the compiler is part of
the standard Java 2 RTE. There is more along the same lines in the
paper.

Ясно сказано, что статья написана сотрудниками Sun Microsystems.
AFAIK, один из них (Robert Griesemer) бывший аспирант Вирта, защитивший в ETH диссертацию на тему "A Programming Language for Vector Computers".
Прошлой осенью Вирт приезжал в Россию (довольно надолго — был здесь больше месяца).
Во время этого пребывания он читал в разных местах лекции (в принципе, одну и ту же лекцию, с вариациями, некий прообраз "Хороших идей"

Автор(ы): Никлаус Вирт
Дата: 23.05.2006
Уважаемые читатели! Один из наиболее известных, авторитетных и заслуженных деятелей в области программирования профессор Никлаус Вирт опубликовал в январском номере журнал Computer очень интересную, по моему мнению, статью. Я не мог отказать себе в удовольствии пересказать ее, чтобы предложить получившийся текст вашему вниманию.

).
Вот что он примерно сказал в Москве:

Компания Sun, как и другие, купила исходные коды. За очень недорого, кстати. Они очень серьезно исследовали этот код, я знаю это. Через семь лет после выхода ОБЕРОНА они выпустили Java. В Java заимствовано несколько идей из ОБЕРОНА, но они коррумпировали его синтаксисом языка "С". С точки зрения продавцов это был достаточно умный ход.

А вот из рассказа о его выступлении в Нижнем Новгороде:

Один молодой человек задал вопрос о том, что Вирт думает о Java и C#, акцентируя особое внимание на то, что в них есть сборщик мусора и всё такое, и что вообще писать программы на них гораздо лучше. Он говорил на очень хорошем английском языке, так что переводчик не потребовался. Интонация вопроса была таковой, что, как я понял, задававший вопрос молодой человек был абсолютно не в курсе относительно Оберонов и Оберон-систем (видимо знал только Паскаль 1970 года) и поэтому сделал такой сильный акцент на том, что вот мол, хе-хе, в Java и C# есть сборщики мусора, прогрессивные языки-то, не то, что там какой-то допотопный Паскаль!!! Вирт попросил разрешения сначала ответить на второй вопрос — про сборщики мусора. Он сказал, что сборщики мусора — это, конечно, хорошо, и программисты о них, конечно, должны знать. Но не стоит их так вот сильно выпячивать. Дескать, что тут такого-то? Ну, обычный сборщик мусора, кого этим можно удивить? Далее ответил про Java. Вирт очень спокойно так рассказал, что создатели Java за семь лет до ее создания очень подробно изучили исходные коды Оберона и, в частности, исходные коды оберонистых сборщиков мусора они тоже очень хорошо изучили. Далее испортили (corrupted) Оберон сишным синтаксисом и обозвали получившееся словом Java. Кстати, заметил Вирт, то, что они испортили его сишным синтаксисом, был хороший маркетинговый ход с их стороны. Что касается .Net, то она появилась в результате конкуренции, и в принципе они (Java и .Net) более-менее одинаковые.

Хотя информация попала из разных мест и от разных людей, совпадение достаточно полное, чтобы сомневаться в том, что именно Вирт сказал о Java.
Обращаю внимание на то, что в обоих случаях это был ответ на вопрос из зала.

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

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

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

ЗЫ

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

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


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

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

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

_>>из той же серии: является ли женщина человеком, если была сделана по образу и подобию человека?

VD>Это, прости, просто блед и демагогия.

женоненависник!

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

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

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

Д>А Objective-C был реализован, если верить википедии, еще в 1980 году. Вот так то.

Вообще-то, там написано, что он был разработан в начале 80-х (и не только там, например еще на сайте GNUStep). Более точная дата указана на Cetus-Links.org:

Objective-C is an extension of the C language, developed around 1982-1983 by Brad Cox and Tom Love.

что более правдоподобно, т.к. врядли в 80-м году мог быть реализован язык, берущий многое из Smalltalk-80.

Кстати, по ходу дела обнаружился интересный факт: оказывается, на Java влиял не C++ и даже не Oberon, а Objective-C.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Ну дык:
Дык эта:

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>Так что, делайте выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ie>Пока нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AVC>Я не поленился заглянуть в литературу по Objective C и не нашел там таких замечательных свойств.
AVC>Также как не нашел апплетов, байткода и т.д.
AVC>Именно безопасность типов, сбока мусора ,апплеты и принцип WORA сделали Java популярной и "отличной от других" (в том числе от Objective C, но не... ).
AVC>Меня интересует не поверхностное сходство, а глубинное техническое решение.

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

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

AVC>Я не любитель "теории заговора".
AVC>Однако, заговоры, тем не менее, бывают.
AVC>Или ты будешь это отрицать?

"Я ненавижу две вещи: расизм и негров".

Здравствуйте, VladD2, Вы писали:
ANS>>Кстати, реализаций от сантехников несколько.

VD>Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ. Это как я уже сказал одна реализация двух алогритмов заточенных под разные условия использования.

Вот есть операция деления. Но есть разные реализации. Так же есть "tracing" и "copying" GC. И есть разные реализации, которые имеют те или иные выгоды.

ANS>> При том, некоторые появившиеся раньше — "устаревшие". То биш жизнь идёт.

VD>Это прошлые версии. Они, кстати, мало чем отличаются. Нормальная эволюция.

Фига се мало. Ознакомся с материалом для начала.

ANS>> Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.

VD>ЖЦ дотнета на сегодня во многом лучше Сановского.

Трындеть — не мешки ворочать. Как на счет привести доказательства. Только умоляю — не нужно этих "Мамой клянусь".

VD>Особенно если речь вести о клиенстком ЖЦ.

Не нужно нам военных песен, нам факты давай!

VD>Более того потенциально он даже сменный. Вот только вдяд ли кто-то осилит создать полноценный ЖЦ вне стен МС, так как он слишком сильно завязан с джитом, а инофрмации крайне мало.

Угу. У сантехников информации как кот наплакал, но и её в сотни раз больше чем у МС. Эти вообще всё просто решили: есть серверный GC — юзайте его на серверах. А то что этот GC весь сервер колом ставит — так это пофиг. В результате если хип занимает пару гиг, то полный GC, даже на нескольких процах, занимает несколько десятков секунд. За это время набирается очередь запросов и сервер колбасит потом еще долго. Такое ощущение, что кроме как на замену PHP никто .Net на серверах не использует.

Здравствуйте, 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 были устранены небезопасные (в особенности, вариантные записи) и просто необязательные конструкции, введено расширение типов (практически ООП).
Были введены поддержка динамической модульности, дескрипторы типов и сборка мусора.
Сборка мусора была введена не из пустопорожнего подражания ФЯ, а в связи с другой мотивировкой (если состав модулей заранее неизвестен и переменчив, мы не можем обеспечить корректность "ручного" освобождения памяти).
Вот эта совокупность технических решений и составляет сейчас ядро КОП.
Я и имею в виду конкретные технические решения, а не что-то "отдаленно похожее", и уж тем более не простое созвучие (сказал кто-то "компонент", все — он "автор идеи").
Патенты выдают на реальные изобретения, а не простые благие пожелания.

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

PD>>>И дети их в Линуксовые игры играют ? Сомневаюсь...
АХ>>Дети их играют в PlayStation. А PlayStation 3 будет с Linuxом.

M>Он не будет с Линухом. Сони выпустит Линух для Playstation. А это — две большие разницы. Просто для предыдущих Сони в качестве эксперимента выпускала Линукс. Для третьей Сони тоже выпустит — это просто своего рода тоже PR

Нет.

Linux will be pre-installed on the PS3 hard drive.

Because we have plans for having Linux on board the PS3, we also recognize Linux programming activities… Other than game studios tied to official developer licenses, we'd like to see various individuals participate in content creation for the PS3.

Izumi Kawanishi on the presence of the Linux in the PS3.

(отсюда)

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

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

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

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

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

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

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

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

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

ГВ>Ну...

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

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

Д>КОП появился задолго до оберона. Так что находить здесь связь .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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C>Вот один процесс захочет послать 10000 сообщений другим процессам — и
C>тоже кирдык будет, так как каналы будут забиты 10000ми одинаковых сообщений.
Что-то я не вижу реальной необходимости в таких фичах.

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

L>А почему это в COM нет типобезопасности??

Потому что это универсальная компонентная модель для разных языков. В том числе для не типобезопасного С++. Соотвественно КОМ подразумевает ручной контроль за приведением ссылок и контроль времени жизни объектов.

L>Да и сборка мусора — для компонентной системы важно скорее наличие управления временем жизни обьектов, а не конкретный алгоритм. Худо-бедно reference counting c этим справляется.

Да, да, худо и бедно.

L>Да, мы ещё Corba забыли — там примерно то же самое...

Корба вообще не компонентная система. Это средство организации сетевого взаимодействия.

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

AVC>Что касается Явы, то ее рекламная компания велась в духе "нигде кроме, как в Моссельпроме".

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

AVC>Очень уж не вязалось бы с этим "победным духом" (Sun использовала даже немецкие военные марши ) скромное признание, что вот "мы взяли основную идею у ETH, а теперь рекламируем ее вам как свою".

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

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

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

WH>>А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения. А в подавляющем большинстве случаев все банально сводится к запрос/ответ.
AVC>Вопрос: в большинстве случаев или всегда?
Приведи хоть один реальный протокол в котором есть рекурсия.

AVC>А какая альтернатива у EBNF в данном случае?
В данном случае он не нужен.
Кстати на твой EBNF я могу сказать что контекстно свободных грамматик мне не хватает и мне нужны контекстно зависимые... А это совсем тушите свет.

AVC>Мне показалось, что буквально несколькими строчками ранее ты обосновывал, что с помощью EBNF только LL(1) можно разобрать эффективно.
AVC>Это не читабельность?
Чего обосновывал? Ты не путай эффективную реализацию для машины и читабельность для человека. Это совершенно разные вещи. И одно от другого никак не зависит.
Взять теже регулярные выриажения... ну совершенно не читаемая штука но компом парсится на раз, а C# человеком читается легко но компу его разобрать не просто. А языки с выводом типов типа немерле для компа вобще задачка на гране возможного но вот человеком они читаются очень легко.
Так что не нужно из раза в раз повторять эту Виртувскую глупость что читабельность LL(1) грамматик лучше чем у грамматик которые в LL(1) не укладываются.

AndrewVK wrote:
> C>, так как у МТ может быть бесконечно много
> C>состояний.
> Ага. Другое дело, что для любой существующей реализации МТ это не так.
Ну так весь мир — это один большой КА

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

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

Что задержки именно от сборки мусора, а не от того, тчо программа такая это ты инфу из астрала получил?

VD>Привести тебя цифры даже не прошу. Ты же у нас производительность ЖЦ по документации изучаешь

Автор: Andrei N.Sobchuck
Дата: 21.10.06

.

Именно по цифрам. Вот лог от сборки в Эдэме (молодом поколении):

Desired survivor size 41464624 bytes, new threshold 4 (max 6)
— age 1: 25402832 bytes, 25402832 total
— age 2: 13157352 bytes, 38560184 total
— age 3: 1943640 bytes, 40503824 total
— age 4: 1154792 bytes, 41658616 total
— age 5: 1800272 bytes, 43458888 total
: 469376K->42624K(469376K), 0.2825171 secs] 908653K->498107K(8345984K), 0.2832459 secs]

ANS>>Для понимания GC в .Net сырцы ротора представляет такую же ценность как и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.

VD>Может тебе ссылку на гугль дать?

То есть нету. Я так и думал.

VD>>>У нас вот 500 мег не превышает (к сожалению).
VD>>>И сборки идут со скоростью сотен в секудну.

ANS>>Это на "сотни в секунду" не тянет

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

:
ANS>>

Сборка мусора нулевого поколения просходит раз 1-4 секунды. Раз в 10 секунд просходит сборка второго поколения. Где-то так же первого.

.

VD>И? Ты вообще знаешь чем скорость от частоты отличается?

Со скоростью "сотен в секунду" чего? Сотен объектов? Единица измерения какая?

VD>Спустись на пару веток ниже Re[10]: GC в .NET

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

и почитай.

Могу предположить, что этот "явный глюк" был сборкой 2-го поколения.

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

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

E>А подробнее тему раскрыть можно? Буду очень признателен. Или здесь, или в приват по почте, или на SourceForge-вский форум.
E>Буду очень-очень признателен
Лично мне нужно очень много мелких процессов порядка нескольких тысяч на одной машине которые стоят в кластере состоящим из десятков машин.
broadcast в таких условиях это кирдык всему. Болие того даже поддержка модели в которой в принципе возможен broadcast ничего хорошего не даст.
Также мне очень важно знать что процесс с которым идет общение умер. Это нужно для убивания зомбей (процессы которые уже не смогут завершить свою работу ибо партнеры подохли) чтобы память не жрали.
Еще нужна возможность прокачки большого потока данных с некоторой обработкой не поднимая их все в память.

Короче модель сингулярити очень близка к тому что мне надо.

AVC>На случай злобного хакера, можно подумать о технологии "тонких бинарников".
AVC>Модуль попадает в систему в полукомпилированном виде, докомпилируется при загрузке.
AVC>В принципе, можно докомпилировать один раз, потом грузить бинарник.
Именно так предполагается делать в Singlularity.

WolfHound wrote:
> AVC>Вопрос: в большинстве случаев или *всегда*?
> Приведи хоть один реальный протокол в котором есть рекурсия.
Передача древесных данных?

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


AVC>А какая ОС (в смысле эффективности переключения контекстов) не из каменного века?

Можно быстро переключать контексты и на существующих OS, нужна только небольшая аппаратная подержка Singularity? Прошлый век!

Автор: Cyberax
Дата: 31.05.06

Дарней 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-анализатор в
этом случае просто перкомпилирует код под изменившиеся условия.

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

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

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

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

VladD2 wrote:
> C>Что значит "partition"? Размер swap-файла или swap-раздела?
> Незнаю как сейчас. А тогда в Линуксе понятия swap-файл просто не было.
> Предлагалось создать отдельный раздел (причем если не ошибаюсь специальный).
Линукс может использовать для swap'а любое блочное устройство или файл —
можно при желании своп через сеть подмонтировать, а еще я как-то ради
шутки сделал swap на ramdisk'е.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Одна реализация разных алгоритмов? Расшифруй.

Алгоритмы используются в рамках одной реализации ЖЦ. Вот IBM, например, предоставляет свою реализацию. Еще кто-то может быть. А у Сана реализация одна.
Точно так же и у МС. Алноритмов Х, а реализация одна.

VD>>Доказательства тут баральные качаешь JEdit открываешь в нем файлик в несколкь мег и колдишь как ЖЦ дает о себе знать невооруженному взгляду. А потом качаешь мой Rsdn.Editor и убеждаешься, что ЖЦ вообще не заметен на глаз.

ANS>То есть цифр не будет, ибо для тебя доказательство — это "на глаз"?

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

Привести тебя цифры даже не прошу. Ты же у нас производительность ЖЦ по документации изучаешь

Автор: Andrei N.Sobchuck
Дата: 21.10.06

.

ANS>Для понимания GC в .Net сырцы ротора представляет такую же ценность как и сырцы gc в jvm. Что касается книжек, то давай ссылку на amazon.

Может тебе ссылку на гугль дать?

VD>>У нас вот 500 мег не превышает (к сожалению).
VD>>И сборки идут со скоростью сотен в секудну.

ANS>Это на "сотни в секунду" не тянет

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

:
ANS>

Сборка мусора нулевого поколения просходит раз 1-4 секунды. Раз в 10 секунд просходит сборка второго поколения. Где-то так же первого.

.

И? Ты вообще знаешь чем скорость от частоты отличается? И за одно чем отличается "в среднем" от "в пиковые моменты"?

VD>>Что мы не так делаем?

ANS>Ты просто не умееш читать. Смотрим

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

:

ANS>Поколение 0: 37М
ANS>Поколение 2: 26М

ANS>На таком крохотном хипе даже счетчик ссылок будет работать без проблем.

ANS>% Time in GC: 78%

ANS>И так: 500М нетути, но картина уже грустновата. А если хип увеличиться в 10 раз, то клиенты вообще ответа от него не дождутся.

Слушай откровенно говоря я сейчас скачусть на нелестные отзывы о твоей личности, так как твоя изберательность в цитировании и понимании чужих слов никак окромя демагогии назвать нельзя.
Спустись на пару веток ниже Re[10]: GC в .NET

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

и почитай.

В общем, твой трындеж мне надоел. Завязываю общение с тобой в однсотороннем порядке.

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

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

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

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

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

Здравствуйте, 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>Так что, делайте выводы
Ага

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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. Естественно, ничего личного. Речь идет о твоем однофамильце и тезке, не более

Здравствуйте, 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. Естественно, ничего личного. Речь идет о твоем однофамильце и тезке, не более

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 wrote:
> ИМХО, я уже показал здесь
> <http://rsdn.ru/Forum/Message.aspx?mid=2151343&amp;only=1&gt;

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

, что эта ссылка
> как раз *подтверждает* точку зрения о приоритете Оберона.
> Обрати внимание, что это та же самая ссылка.
До Оберона был еще, как минимум, Objective C. Тоже вполне себе
компонентыный. А еще был Cedar Mesa, в котором была одна из первых
реализаций компонентного пользовательского интерфейса.

Так что Оберон — это один из первых представителей компонентных
языков, но уж точное не самый первый.

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

>> ИМХО, я уже показал здесь
>> <http://rsdn.ru/Forum/Message.aspx?mid=2151343&amp;only=1&gt;

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

, что эта ссылка
>> как раз *подтверждает* точку зрения о приоритете Оберона.
>> Обрати внимание, что это та же самая ссылка.
C>До Оберона был еще, как минимум, Objective C. Тоже вполне себе
C>компонентыный. А еще был Cedar Mesa, в котором была одна из первых
C>реализаций компонентного пользовательского интерфейса.

C>Так что Оберон — это один из первых представителей компонентных
C>языков, но уж точное не самый первый.

Насколько я понимаю, Objective C был языком объектно-ориентированного, но не компонентного программирования.
Заявленная Коксом цель (программные аналоги интегральных схем) замечательна (впервые я прочитал о Коксе в "детской" книжке Тимоти Бадда "Introduction to Object-Oriented Programming" и пришел в полный восторг от одной только идеи); единственно, ИМХО, он переоценил возможности ООП как такового.
Вместе с тем, сама идея некой родственности программного обеспечения и аппаратуры до сих пор мне близка, что можно даже подтвердить (бессознательно!) выбираемой терминологией.
Например, применительно к Оберону, я предпочитаю выражение "программная шина" (software bus) более официальному "generic message interface".
Отчасти это потому, что когда-то я читал о Бреде Коксе, только сейчас дошло, честное слово!

Что касается языков, разработанных в исследовательской лаборатории Xerox, то тут отдельная песня.
Известно, что Mesa не только повлияла на виртовскую Модулу-2, но и рассматривалась как возможный вариант "Железного Человека".
Т.е. "доработанная" Меза могла быть на месте Ады!
В итоге же, Адой стал вариант, разработанный прежними создателями компилятора Симулы-67 (вдруг, кто не знает об этой интересной связке?).
Но Меза определенно еще не была языком компонентно-ориентированного программирования, не созрело тогда еще все для этого.
Cedar (я так понимаю — потомок или даже вариант языка Mesa) действительно повлиял на проект Оберон (совместно с Модулой-2, Адой и Смоллтоком).
Но каково конкретно это влияние, мне сказать трудно, информации о языке у меня что-то маловато.

Если я узнаю, что техническое решение, предложенное Обероном, заимствовано им из Седара, я буду считать Седар первым языком КОП.
Но это вряд ли.
Вернувшись из Ксерокса, Вирт прекрасно знал о Седаре, но собирался использовать для проекта Оберон Модулу-2 (что, в принципе, достаточно естественно ).
И только в ходе работы, убедившись, что Модула-2 не вполне подходит для выбранной цели, Вирт преобразовал Модулу-2 в язык Оберон.

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

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

Д>а какой именно конкретики тебе не хватает?

Паролей, явок, имен, дат.

Ссылки на МакИлроя и каналы в Unix-е не прокатывают:
* во-первых, это только идея. Как известно, от любой идеи до практического применения проходит изрядное время;
* во-вторых, каналы были только первым шагом к созданию инфраструктуры поддержки КОП. До реального КОП было еще как до Луны;
* в-третьих, каналы позволяют организовывать комплексы программ, в которых отдельные самостоятельные программы играют роль компонентов. Современный же КОП, если не ошибаюсь, подразумевает построение одной программы из разных компонент (т.е. компоненты (или их части, стабы) оказываются в одном адресном пространстве).

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

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

Ну да, это как объектно-ориентированное программирование на C -- через структуры, которые содержат указатели на функции.

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

Д>А мне без разницы, есть поддерка КОП непосредственно в языке или нет. Если она есть, это просто немного упрощает жизнь.

А вот разработчикам Oberon и C# было не без разницы.

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

E>Тогда C++, да что C++, ассемблер -- это язык компонентного-ориентированного программирования.

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

E>Шутку оценил, не смотря на ее плоскоту.

зато, если сложить две плоские шутки, получится одна тонкая.

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

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

Не в ту сторону?
Ну-ну.
Просто стали делать упор на промежуточный язык (байт-код для JVM, IL — для дотнета).
Потому что язык фиксирует определенные соглашения, без которых нормальное КОП возможно, разве что, через задницу.

Д>Археоптерикс — он тоже, в принципе, летал. Но первой птицей его все равно не называют.

Правильно.
Вот COM и есть такой запоздалый археоптерикс.
Надо же было куда-то впихнуть кучу софта, уже написанного на Си++.

Д>зато, если сложить две плоские шутки, получится одна тонкая.

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

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

AVC>>Однако, и этот источник не относит пайпы к КОП.

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

Вот что там написано.

Technologies

Pipes and Filters

• Unix operating system

Component-oriented programming

• Fractal component model from ObjectWeb
  
• 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

Достаточно ясно, что пайпы и КОП — разные технологии.

AVC>>Тем не менее, он там есть, и ничего более раннего не указано.

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

Хронологию сам подставь.
К 1989 году не только ОС Оберон (100% компонентная) была написана, но и по ней в ETH читался учебный курс.

Д>В любом случае, оберон — это явная неудача.

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

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


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

Сомневаюсь. Дело в том, что я заложил одну мину в свое предложение. Я тебе предложил провести спецкурс. А спецкурс — это такая штука у нас, когда студенты ходят или нет по своему усмотрению. Заставить ходить их никто не может. Они обязаны за 5 лет набрать столько-то спецкурсов, но выбирать их могут сами. На мой спецкурс (не по Win32) , на первую лекцию, приходит обычно человек 20-25, а зачет сдает половина, и это нормально.
Так что на первое занятие к тебе, скорее всего, из любопытства пришли бы. Но первый вопрос, который бы задали — где это можно сейчас употребить и чем это лучше, чем все остальное. Ну а получив от тебя ответ в стиле твоих лучших высказываний здесь — на второе занятие скорее всего бы не пришли.

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

PD>>А про Linux — каково соотношение машин с Linux и машин с Windows в бизнесе или на домашних ПК ? Вот то-то и оно. А то, что его любителей среди профессионалов, полупрофессионалов и их знакомых не так уж мало — ничего не значит. Для индустрии.

E>Ну посмотри на соотношение в сегменте x86 серверов

Так я и говорю — в среде профессионалов. Там совсем другие законы действуют. Ну и учти все же, что доля Unix там была когда-то почти 100% — до появления Windows NT. Кстати, при ее появлении многие сомневались, что она вообще сможет Unix там потеснить...


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

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

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

PD>>И дети их в Линуксовые игры играют ? Сомневаюсь...
АХ>Дети их играют в PlayStation. А PlayStation 3 будет с Linuxом.

Он не будет с Линухом. Сони выпустит Линух для Playstation. А это — две большие разницы. Просто для предыдущих Сони в качестве эксперимента выпускала Линукс. Для третьей Сони тоже выпустит — это просто своего рода тоже PR

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

АХ>Че-то мы в Win vs Linux скатились. Предлагаю закончить .


Согласен.

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

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

FR>Скорее всего какое-то отношение он к этому имеет, но очень маленькое.

Наверное, примерно то же самое думают бизнесмены об изобретателе.

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

AVC>>Что касается Явы, то ее рекламная компания велась в духе "нигде кроме, как в Моссельпроме".

AVK>Что не мешало им в 5 версии потырить некоторые особенности из шарпа, ничуть при том не скрывая, откуда растут концы.

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

AVC>>Очень уж не вязалось бы с этим "победным духом" (Sun использовала даже немецкие военные марши ) скромное признание, что вот "мы взяли основную идею у ETH, а теперь рекламируем ее вам как свою".

AVK>Но при этом, по твоим же утверждениям, другие источники для Java они указывать не стеснялись.

Я и не думаю отрицать другие источники как таковые: ни Смоллток, ни Обджектив Си, ни др.
Вместе с тем, ИМХО, видно невооруженным глазом, что Ява в самом главном не похожа на оба этих замечательных языка.
(Я назвал Обджектив Си "смесью бульдога с носорогом" не потому, что это плохой язык, а потому что это смесь двух совершенно разных языков и подходов, нечто, далекое от той целостности, что необходима для КОП.)

AVK>Видишь ли, то что в Обероне были определенные идеи еще ничего не доказывает. Есть такое понятие, как идеи носящиеся в воздухе. КОП одна из них. И в этой ситуации найти единоличного автора идей КОП сродни попыткам найти единоличного автора, к примеру, коммунизма или либерализма.

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

"Хозяйка, сапоги свистели над головой!" (c) м/ф про поросенка Фунтика

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

AVK>>Тебе сказать, где yacc найти?

Д>ты хочешь сказать, что yacc — чистый КА безо всяких надстроек?

Не просто КА, ДКА. Другое дело что реальные парсеры конечно почти никогда вчистую в LR(1) не укладываются.
Если же говорить о просто КА, то в его рамки укладывается абсолютно любой детерминированный алгоритм. Доказать просто — машина Тьюринга реализуется без проблем ввиде КА.

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

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

L>Извините, а что в виндоус сделано такого что она постоянно требует обновления железа? То есть, Win 98 поставленная на Celeron 333 через какое-то время потребует апгрейта до P4?

Согласен. Это натуральные инсунуации. Это новые версии ОС рассчитаны на новое железо. И потребляют они больше именно из-за этого. Так же Виста в режиме без Аэро и другой хрени мало чем отличается от W2k. И линукс образца 1997-го года потреблял ресурсов куда меньше чем образца 2006-го. Вот только Линукс 1997-го года выпуска вообще на современном железе будет вести себя весма странно. Помнится у них таогда даже такие простые вещи как объем раздела отводимый для виртуалной памяти был огрничен где-то 128 метрами. На сегодня это просто смешно.

Виста на современной машине летает как трофейный мессер. Это я говорю по собственному опыту. А на машины класса Pentium 90 она банально не рассчитана. Windows 95 же будет прекрасно работать на этом самом Pentium 90 до тех пор пока железо не загнется от времени. А на современную машину ставить Windows 95 — это маразм.

VladD2 wrote:
> Согласен. Это натуральные инсунуации. Это новые версии ОС рассчитаны на
> новое железо. И потребляют они больше именно из-за этого. Так же Виста в
> режиме без Аэро и другой хрени мало чем отличается от W2k. И линукс
> образца 1997-го года потреблял ресурсов куда меньше чем образца 2006-го.
Неправда. Линукс образца 2006 года можно сконфигурировать для работы на
машинах 1997 года — энтузиасты его на чистый 386 спортировали.

> Вот только Линукс 1997-го года выпуска вообще на современном железе
> будет вести себя весма странно. Помнится у них таогда даже такие простые
> вещи как объем раздела отводимый для виртуалной памяти был огрничен
> где-то 128 метрами. На сегодня это просто смешно.
В 97 году этого уже не было.

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

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

У машины Тьюринга лента бесконечна. Если ленту ограничить то получим конечный автомат.

Дарней wrote:
> AVK>Но размер этого самого числа не лимитирован и может быть сколь
> угодно большим (хотя и не бесконечным).
> Если /чисто теоретически/, то МТ наверно можно эмулировать при помощи
> КА, если предположить что он может быть бесконечного размера.
КА — он по определению конечный

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

C>Передача древесных данных?

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

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

AVK>>SOAP, к примеру, вполне себе может быть рекурсивным. Но описывается он не EBNF, а XSD.
GZ>А что такое рекурсивная грамматика? Такое бывает?

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

WolfHound wrote:
> AVC>А какая ОС (в смысле эффективности переключения контекстов) не из
> каменного века?
> Singularity
Ага, конечно:
1. Невозможность динамической подгрузки кода.
2. Отсутствие аппаратной защиты (и невозможность нормально использовать
unmanaged).
3. Опять же, нет системный поддержки для nccNUMA.
4. Ориентированость на старое поколение железа.

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

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

FR>>У них не было из-за этого проблем и потери приличного куска рынка?

AF>У тебя есть точные данные, что причина финансовых потерь — это именно выпуск новой ОСи?

нет конечно

FR>>Ну и какова цена внедрения 64 разрядности в x86?

AF>За такую информацию вообще-то немаленькие деньги аналитикам платят

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

А не надо настолько обобщать.
Заменить OS гораздо дороже чем внести пару не таких уж и больших изменений в процессоры.

FR>>При просадке на порядок (для обыкновенного эмулятора без jit и тех оптимизации которые будут невозможны на управляемой OS без потери контроля над безопасностью выполнения кода) закон Мура слабое утешение.

AF>Всё зависит от степени различия у исходной и целевой платформ. Делать какие-то догадки даже о величине порядка — брать цифры просто с потолка.

Угу, только управляющие OS вносят дополнительные тормоза.

AVC wrote:
> Если он в принципе в состоянии обеспечить надежность, зачем требовать
> дополнительного усложнения аппаратуры?
Потому как он заставит ВСЕ писать на своем собственном языке. А это
нереально.

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


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

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

Здравствуйте, vdimas, Вы писали:
V>Угу, пока речь не пойдет об GUI. Тут и настанет сказочке конец. Покажи сегодня хоть одну большую прогу с богатым GUI, которая не на плагинной системе сделана. Под тысячу переданных сообщений GUI м/у процессами в секунду? Это круто.
Это детский лепет. На сингулярити стоимость обмена сообщениями в 6 раз ниже, чем в Windows: http://rsdn.ru/article/singularity/singularity.xml#EIIAE

Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, реализаций от сантехников несколько.

Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ. Это как я уже сказал одна реализация двух алогритмов заточенных под разные условия использования.

ANS> При том, некоторые появившиеся раньше — "устаревшие". То биш жизнь идёт.

Это прошлые версии. Они, кстати, мало чем отличаются. Нормальная эволюция.

ANS>Если бы "всем хватало", то не появлялось бы там ничего нового.

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

ANS> Что касается дот-нета, то судя по тем крохам, что есть я видел в документации, то отстают они от сан-техников.

ЖЦ дотнета на сегодня во многом лучше Сановского. Особенно если речь вести о клиенстком ЖЦ. Более того потенциально он даже сменный. Вот только вдяд ли кто-то осилит создать полноценный ЖЦ вне стен МС, так как он слишком сильно завязан с джитом, а инофрмации крайне мало.

ЗЫ

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

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

VladD2 wrote:
> ANS>Кстати, реализаций от сантехников несколько.
> Озвучь, плиз список. Толко не надо говорить о серверном и клиентском ЖЦ.
> Это как я уже сказал одна реализация двух алогритмов заточенных под
> разные условия использования.
Не совсем.

Ну ладно, вот весь список:
1. Serial Generational GC (обычный последовательный GC).
2. Parallel Generational GC (тоже самое, что и последовательный, но во
время сборки мусора его собирают сразу все процессоры).
3. Concurrent Mark&Sweep GC, a.k.a. Tricolor GC (инкрементальный
параллельный GC).
4. Mostly-Concurrent Generational GC (Generational GC, который работает
почти параллельно с мутатором).

Причем они могут настраиваться и комбинироваться. Например, у
generational'ов можно включать или выключать компактификацию поколений,
менять trigger policies. Mark&Sweep можно сочетать с generational'ами и т.п.

У меня лежит незаконченая статья, все дописать никак не могу.

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

C>Сырцы в JVM вполне, кстати, помогают понять как JVM работает. Особенно
C>тонкие его детали, типа используемого write barrier.

Тьфу-тьфу-тьфу. До копания сырцов gc в java для оптимизации приложения дело не дошло. К счастью, на их форуме по jvm отвечают на вопросы и разработчики. Из которых вполне можно вытащить ответы, при наличии терпения Найденную багу в инкрементальном конкурентном GC при работе со слабыми ссылками они пофиксили, кстати, в несколько дней. А вот общение на форуме по коллекциям никакого удовольствия не приносит Там багу в сырцах AbstractMap не хотят даже признавать

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Что задержки именно от сборки мусора, а не от того, тчо программа такая это ты инфу из астрала получил?

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

VD>>Привести тебя цифры даже не прошу. Ты же у нас производительность ЖЦ по документации изучаешь

Автор: Andrei N.Sobchuck
Дата: 21.10.06

.

ANS>Именно по цифрам. Вот лог от сборки в Эдэме (молодом поколении):
ANS>

ANS>Desired survivor size 41464624 bytes, new threshold 4 (max 6)
ANS>- age 1: 25402832 bytes, 25402832 total
ANS>- age 2: 13157352 bytes, 38560184 total
ANS>- age 3: 1943640 bytes, 40503824 total
ANS>- age 4: 1154792 bytes, 41658616 total
ANS>- age 5: 1800272 bytes, 43458888 total
ANS>: 469376K->42624K(469376K), 0.2825171 secs] 908653K->498107K(8345984K), 0.2832459 secs]

Назовц фиры! 1, 295, 18, 4! Это реальны цыфры!!!
Ты делал заявления по повду ЖЦ дотнета в сравнении с Явой. Вот по этому поводу цифры и проводи, а какю-то фигню.

ANS>То есть нету. Я так и думал.

Ну, почему же? http://www.google.ru/
Дальше справишся?

ANS>Со скоростью "сотен в секунду" чего? Сотен объектов? Единица измерения какая?

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

ANS>Могу предположить, что этот "явный глюк" был сборкой 2-го поколения.

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

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

C>Вообще-то, внутри JDK алгоритмы GC находятся в раздельных модулях и
C>вполне себе автономны.

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

Вот же, сила воли у тебя: не хотел со мной общаться, общаешся.

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

VD>Отрисовка там не тормозит. Там случаются приодические задержки в сдествии активизации ЖЦ и плохого алогоритма инкрементальной сборки. Это признают все с кем я это в свое время обсуждал. Да и есть разные профйлеры.

Профайлеры тут нафиг не упали. Есть опция командной строки, которая выводит время работы GC. Это объективный показатель. А на глаз определять тормоза GC — дурость неимоверная.

VD>Собственно выявилось это когда я услышал совершенно дурацкий на мой взгляд совет по отимизации работы со строками. Для дотнета он был совершенно бессмысленным. Меж тем на Яве он говоря помогает.


Не будь таким скрытным, приведи этот совет.

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

AVC>>Думается, для того же, для чего нужны безопасные языки и сборка мусора, — для надежности.
AVC>>Активные объекты — развитие мониторов Хансена и Хоара, а мониторы всяко надежнее бессистемного управления потоками.
AVC>>В каком-то смысле — это та же инкапсуляция (данных, потоков и блокировок).
WH>А теперь попробуй объяснить чем синхронизация на активнах объектах лучше чем синхронизации на каналах?

Очень поверхностно ознакомился с идеями Сигулярити — прочел (пока) один обзор.
Во-первых, мне Сигулярити нравится.
Уже хотя бы из-за SIP аббревиатуры (Software Isolated Process).
Ты уж извини, но здесь я опять-таки вижу аналогию с Обероном (если взять слово Software).
Насколько я понял, основное различие в том, что Сингулярити (программно) поддерживает несколько процессов.
В принципе, это должно быть хорошо.
В первоначальном Обероне был только один поток, в Aos (BlueBottle) — многопоточность, а вот процессов в их традиционном для ОС понимании не было.
Вполне возможно, что это шаг вперед (и серьезный).
Вместе с тем, разделение (пусть и программное) процессов все-таки накладывает некоторые ограничения.
Например, процессы не могут обмениваться между собой объектами.
Что, ИМХО, можно считать ограничением, т.к. современные программные системы во многом строятся из объектов.

Здравствуйте, 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 есть отдельно мета- и отдельно макро- программирование? Или вы в обоих случаях подразумевали одну и ту же фичу?