Java вышла на первое место?

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

> Может тебе пора продать Целерон и взять нормальный проц?

Athlon 2500 512Mb - мало? сколько нужно, чтоб оно полетело быстрей гантели, брошенной дистрофиком?

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

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

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

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

> http://news.pravda.ru/science/2003/08/19/53677.html

Цитирую с данной ссылки:

Низкоквалифицированных программистов сменят бабуины и шимпанзе Ученые из США обнаружили у высших приматов недюжинные способности к работе с компьютером. Однако у большинства бабуинов и шимпанзе любые компоненты языка Java......

После простейшего курса по работе с Windows, бабуинам было предложено ознакомиться с новейшими достижениями в области программного обеспечения. Бабуины были потрясены и озадачены программами Java IDE, SunONE и Visual Age.

=)))

> что жабка сейчас по сути в той же нише, что и кобол когда-то: по всем параметрам ниже среднего

Ага, по всем, кроме одного - распространенности. Элита программистского мира не может с этим смириться.

> Пока еще... но что стало с коболом - я думаю, все в курсе.

Не уверен, что все в курсе.

http://www.infogoal.com/cbd/cbdhome.htm

http://www.csis.ul.ie/COBOL/

http://www.cobolportal.com/index.asp?bhcp=1

> Не уверен, что все в курсе.

Да, оно еще трепыхается. Однако ж посмотрите рейтинг кобола в том же TCPI по ссылке в новости, сравните с жабкой.

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

> Ага, по всем, кроме одного - распространенности. Элита программистского мира не может с этим смириться

А как можно смириться с распространенностью отстоя? Ну не хочу я есть ваши помои... а приходится. =/ Потому и матюгаюсь...

Это не только в программистском мире так, кстати.

> Да, оно еще трепыхается. Однако ж посмотрите рейтинг кобола в том же TCPI по ссылке в новости, сравните с жабкой.

Вот тут интересная статейка на эту тему:

http://www.itworld.com/Career/1944/ITW0319weinstein/

Люди, просто, живут немного в других областях применений.

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

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

Бедненький, некуда тебе податься.

> А как можно смириться с распространенностью отстоя? Ну не хочу я есть ваши помои... а приходится. =/ Потому и матюгаюсь...

Заметим, что никто сообществу Java не навязывал. Если бы этот язык был, как вы изволили выразиться, отстоем, то он бы не вышел за пределы сановских лабораторий. У Сана и ресурсов-то не было кому-то что-то навязывать, чай, не Microsoft.

> Я и говорю - почти труп, идут последние конвульсии (и еще лет так десять будут), но от капельницы пока не отключают.

Еще десять лет, то есть всего лет 50. Для IT-технологии это очень и очень неплохо. Если Java просуществует еще лет 30, что мне до пенсии хватит :)

>> потому что она просто напросто не для этого

>Java SE не для этого, но есть JSR-1 - Real-Time Java и вот это уже можно применять, если с умом делать. В том, что real-time до сих пор пишут, в основном, на C, значительная доля legacy. Столько уже понаписано, что просто так перейти на что-нибудь другое очень дорого и нетехнологично.

Да, есть такая штука. Но спор здесь несколько не об этом, а о том, что в тех областях, в которых применим питон, последний ее обруливает, почему - см. выше. А в тех областях где приминима Ада, жабу она еще больше обруливает тк (1) язык изначально разрабатывался под задачи РВ, (2) Ада строго стандартизована, (3): В Microsoft были вынуждены включить в лицензионные соглашения для своих операционных систем следующий пункт (www.microsoft.com/msdownload/ieplatform/ie/license.txt): "Замечание относительно поддержки языка Java... Технология Java не является устойчивой к сбоям и не предназначена... для использования в рамках управляющих систем реального времени..., в которых сбой языка Java может повлечь за собой смерть, увечье, или тяжелый урон инфраструктуре или окружающей среде. Компания Sun Microsystems, Inc. обязала компанию Microsoft разместить данное предупреждение".

и т.д., также см. http://www.adahome.com/History/Steelman/steeltab.htm и http://groups.yahoo.com/group/ada_ru/

P.S. Лично я пишу на Аде и встраиваю туда питон (через си), так что они друг друга дополняют ;)

> Заметим, что никто сообществу Java не навязывал.

Да? Активный сановский пиар в середине 90-х, с слоганами типа "Java made all other programming languages obsolete" - это, видимо, плод моего воображения?

> Если бы этот язык был, как вы изволили выразиться, отстоем, то он бы не вышел за пределы сановских лабораторий.

Я уже говорил: любая оценка здесь может быть только относительной. По сравнению с доминирующими тогда C и C++, Java действительно была шагом вперед - во всяком случае, для задач этой сферы. Но с тех пор прошло десять лет. Так какого #$% мы так и зависли на ней, кроме как по тупости менеджеров и маркетоидов?

> Еще десять лет, то есть всего лет 50. Для IT-технологии это очень и очень неплохо. Если Java просуществует еще лет 30, что мне до пенсии хватит :)

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

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

В-общем, товарищи, поднимем экономику планеты - все силы на скорейшую постройку биореактора!

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

Не будут. У языка, которому уже 45 лет или около того, как правильно замечено здесь http://www.jroller.com/comments/slava/Weblog/most_useless_book_in_computer#co... было достаточно времени, чтобы стать мэйнстримом. Не стал. И не станет

Знаешь, я сейчас написал это сообщение в Wordе, и подумал, Microsoft написал бы Офис в 96-м году на Java, если бы тогда у него была Java и если бы Javу сделали Микрософтовцы. И все бы сейчас тащились от немеренной крутизны и возможностей офиса, и думали бы, что MS Java- рулез. А пинают жабу сейчас только потому, что это не продукт Microsoft.

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

Угу пока они там будут питон доводить до ума и отуплять до уровня среднего кодера, жаба на месте стоять не будет, и на ней индусы с китайцами уже будут писать ПО для управления полетами на Луну и Марс.

Вот вот, питон вызрел и вышел на свет раньше, чем жаба, и коммьюнити могло понести его на плечах, встроить python1.0.o в kernel, в glibc, но почему-то этого не сделало. Почему?

> Да? Активный сановский пиар в середине 90-х, с слоганами типа "Java made all other programming languages obsolete" - это, видимо, плод моего воображения?

И что? Надо полагать, IBM остальные купились на PR, не подумавши? Вложились в инструментарий, переобучение персонала, раскрутили JCP? Вы в курсе, что в настоящее время в JCP Сан играет далеко не доминирующую роль? Сколько компаний входит в комьюнити, знаете? Полагаете, что это все результат исключительно PR? Тогда сановским маркетологам надо памятник ставить, не иначе. Даже у Microsoft так не получилось пока что.

> Но с тех пор прошло десять лет. Так какого #$% мы так и зависли на ней, кроме как по тупости менеджеров и маркетоидов?

Да такого, что Java - это не просто язык, а платформа. Платформа, которая развивается по установленным правилам и удовлетворяет большинство активных игроков в индустрии. Недаром, IBM продлил лицензию еще на 10 лет. Одно дело, мудрствовать в стеклянных лабораториях на тему, каким должен быть идеальный язык, и совсем другое дело - существовать в индустрии и производить реальные технологии.

>Не знаю, чем ява популярна, в своей (достаточно долгой) практике в ИТ, еще ни разу не видел нормальных, человеческих НАСТОЛЬНЫХ приложений

Вот краткий список ПО на Java, причем большинство из них - это ПО c открытым кодом.

JAVA Desktop software
Azureus - самый популярый BitTorrent client
RssOwl - IMHO лучший RSS reader
Подавляющее большинство UML редакторов написано на JAVA
Начиная с монстров Borland Together, IBM Rational,
продолжая середнячками Оmondo, Poseidon
закнчивая ArgoUML, Umllet
QNEXT - IM клиент c поддержкой Video Conferencing и Audio Chat работает с ICQ, AIM, MSN.
Eclipse - популярная IDE для C++, JAVA, Python, PHP c ОГРОМНЫМ количеством plugin'ов
JEdit- текстовых редакторов c большим количеством plugin'ов.
Runescape - сетевая RPG в которую играют 700тыс человек.
easyPhoto - простой, удобный редактор фотографий

JAVA Server Side Software

OpenExchange group ware
Orion, Tomcat - web servers
Derby, HSQL - data base servers
Jive - jabber server
JBoss, Jonas - application servers
James - mail server
JBPM, RUNA WFE - workflow management environment
Magnolia - CMS
LifeRay - Portal Server

> Не будут. У языка, которому уже 45 лет или около того, как правильно замечено здесь http://www.jroller.com/comments/slava/Weblog/most_useless_book_in_computer#co... было достаточно времени, чтобы стать мэйнстримом. Не стал. И не станет

Ты понимаешь разницу между подходом, и языком, его использующим? Algol-60 в свое время тоже не стал мэйнстримом, но структурированное процедурное программирование - стало. Simula не стала мэйнстримом, но ООП - стал.

> И все бы сейчас тащились от немеренной крутизны и возможностей офиса, и думали бы, что MS Java- рулез. А пинают жабу сейчас только потому, что это не продукт Microsoft.

Я ее пинаю не за это. За что - см. выше. Кстати, к C# и стандартной дотнетовской объектной модели у меня те же претензии. Другой вопрос, что под .NET есть F#, Nemerle, и много еще чего вкусного.

> Угу пока они там будут питон доводить до ума и отуплять до уровня среднего кодера, жаба на месте стоять не будет

Жаба именно что стоит на месте. Нам обещали столько всео в 1.5 - и что? Одни убогие generics чего стоят...

> Вот краткий список ПО на Java, причем большинство из них - это ПО c открытым кодом.

Обрати внимание, что очень многие пункты из твоего списка - это по сути ПО для разработки и деплоймента Java-софта. Всякие там IDE и UML-редакторы, JSP и J2EE серверы etc. Если выкинуть все это, то на десктопе мало что останется.

> жабка сейчас по сути в той же нише, что и кобол когда-то: по всем параметрам ниже среднего, но - "промышленный стандарт"

Это по каким пораметра java сейчас ниже среднего? (в новой зеландии случайно после сьемок LOR не разрешили курить траву?);-)
Список параметров приведите пожалуйста.

> И что? Надо полагать, IBM остальные купились на PR, не подумавши?

Решения принимали не те люди, которые могли подумать на эту тему. Решения принимает менеджмент - а это на 90% идиоты, которые разницу между C++ и Java знают только из рекламных материалов любимых контор.

> Вы в курсе, что в настоящее время в JCP Сан играет далеко не доминирующую роль? Сколько компаний входит в комьюнити, знаете? Полагаете, что это все результат исключительно PR? Тогда сановским маркетологам надо памятник ставить, не иначе.

Сначала PR, потом по инерции, а потом уже слишком много вложили, чтоб разворачивать оглобли. Типичная картина для этой индустрии, кстати. Аналогичная ситуация, например, с XML и веб-сервисами.

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

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

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

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

> Это по каким пораметра java сейчас ниже среднего?

Я уже давал список. Пожалуйста, дам еще раз: отсуствие полноценных generic-типов. Отсутствие замыканий (closures). Примитивная объектная модель: нет множественного наследования и multiple dispatch. Методы не являются first-class значениями (кстати, это уже давно есть в C# - это к вопросу о "Java не стоит на месте"). Вам хватит, или еще накидать?

Выдерну несколько цитат, уж больно типичные аргументы:

> Решения принимали не те люди, которые могли подумать на эту тему. > Решения принимает менеджмент - а это на 90% идиоты [...] > Ты считаешь, что давать дизайн языка на откуп неспециалистам - это нормальная ситуация?

То есть, список "неспециалистов", не умеющих "подумать ни эту тему", включает в себя Гослинга (Java), Страуструпа (C++), Хейльсберга (Delphi и .NET), не говоря уже о Кернигане (C) и Вирте (Pascal, Modula-2 и пр.) Ну, ладно, я готов поверить, что in19h гораздо умнее всех этих людей и знает, как надо. Как насчет убедить в этом других? ;)

>Количество книг об инструменте определяется количеством покупателей этих книг и ничем другим.

Именно. А чем определяется кол-во покупателей? Количеством непонятностей/несуразностей/неочевидностей/... Ибо зачем тогда еще одну книгу писать/читать?

>Нам обещали столько всео в 1.5 - и что? Одни убогие generics чего стоят...

"Вы не любите кошек? Может, вы просто не умеете их готовить?"

Чем это они убогие?

> Аналогичная ситуация, например, с XML и веб-сервисами.

Нука предложи альтернативу. Google вон, прикручивает Webservices к сайту, почему он не хочет PythonRMICalls прикрутить?

>нет множественного наследования

А говорят, что применение интерфейсов снижает число логических ошибок проектирования, а множественное наследование is evil и им еще C++ники наелись.

>Отсутствие замыканий (closures).

Ты еще добавь по старой памяти отсутствие хвостовой рекурсии лол, тогда останется только спросить, "vsl, а vsl, а не int19h твой новый ник?" ;-)

> То есть, список "неспециалистов", не умеющих "подумать ни эту тему", включает в себя Гослинга (Java), Страуструпа (C++), Хейльсберга (Delphi и .NET), не говоря уже о Кернигане (C) и Вирте (Pascal, Modula-2 и пр.)

Я не совсем понял, с какого бока тут Керниган и Вирт, но вот что касается остальных... вы считаете Delphi грамотно задизайненным языком? Или, может быть, Java? (в последнем случае рекомендую посмотреть списки deprecated классов и методов в базовой библиотеке классов - размер впечатляет...).

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

> отсуствие полноценных generic-типов

Тут, конечно, стоило бы спросить, что есть "полноценный". А вообще, в Java добавили generics для решений одной единственной проблемы - type cast в коллекциях.

> Примитивная объектная модель: нет множественного наследования и multiple dispatch.

Множественное наследование поведения решается через interface. Через него-же решается передача функций как параметров - вместо этого передается ссылка на интерфейс. Multiple dispatch нету, решается достаточно просто.

И вообще, был когда-то такой язык, где "все было" - PL/1. Судьба его печальна :)

Мдас, ты наверное думаешь, что поисковик google так часто упоминается в интернете потому, что им очень трудно пользоваться? А пользуется им более 70% не потому, что он лучший, а потому что распиарен так хорошо. Цирк.

То же относится и к жабе.

> "Вы не любите кошек? Может, вы просто не умеете их готовить?" Чем это они убогие?

Два слова: type erasure. Кроме мата здесь добавить больше нечего.

> Нука предложи альтернативу.

Чему, XML или сервисам? Если первому, то, очевидно, S-expressions. Если второму - ему не нужна альтернатива про причине изначальной бессмысленности затеи. Ну нарисовали они очередной протокол удаленного вызова функций с возможностью маршаллинга примитивных структур данных (об объектах там речь не идет даже!) посредством XML, и что? какие насущные проблемы это решило? зато если посмотреть на размер спецификации SOAP, или даже просто на исходник запроса при вызове простейшей функции... это же надо такого нагородить.

> Я не совсем понял, с какого бока тут Керниган и Вирт, > И кстати, я отнюдь не претендую что я "знаю как надо" - не я придумал Lisp =) но понять, что по семантике он намного продвинутей жабки, мне ума таки хватает.

Это был наезд не конкретно на тебя, а на общий стиль аргументов: "если я не согласен с решением, но оно принято, то принимали его идиоты" :)

А насчет Лиспа... Еще раз, с академической точки зрения он, возможно, намного продвинутей. А с точки зрения практического применения, как-то не срослось. Одно дело, защитить диссертацию, а другое дело - внедрить результаты в производство :)

> А говорят, что применение интерфейсов снижает число логических ошибок проектирования, а множественное наследование is evil и им еще C++ники наелись.

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

Да, а кто говорит-то? Гослинг? Ну вы его слушайте больше, как же... =)

А в плюсах нормальной реализации MI и не было никогда. Virtual base classes - как вспомню эту жуть... Кстати, практически все мифы о вреде MI основываются как раз на недостатках его примитивной реализации в плюсах. Если хочешь посмотреть, как это делается по уму: см. Eiffel и CLOS.

> Ты еще добавь по старой памяти отсутствие хвостовой рекурсии

Кстати да, спасибо, что напомнил

> тогда останется только спросить, "vsl, а vsl, а не int19h твой новый ник?" ;-)

Нет, я зарегился еще когда vsl нес свет в массы на ЛОРе. Спасибо ему за это, кстати - в свое время я тоже всерьез считал Java и C# вершиной language design. Пока не увидел Ruby, O'Caml, Haskell, Scheme, и наконец CL - причем последние три я начал ковырять именно с его подачи. С другой стороны, жестоко получается - жабка теперь вызывает патологическое отвращение, а писать хотя бы на окамле мне не дадут =)

>То же относится и к жабе.

Сколько ты прочел книг/статей об методах/паттернах использования поисковика google? Цирк.

> Сколько ты прочел книг/статей об методах/паттернах использования поисковика google? Цирк.

Все же, повторю свой вопрос про книги о Линуксе. Как там насчет "Linux for Dummies", "Redhat Bible" и так далее? Зайдите на Амазон, сделайте запрос по слову Linux и удивитесь.

> Тут, конечно, стоило бы спросить, что есть "полноценный". А вообще, в Java добавили generics для решений одной единственной проблемы - type cast в коллекциях.

Согласен. В чем и проявляется их убогость - generics могут (и должны) использоваться далеко не только для этого.

> Множественное наследование поведения решается через interface.

Не решается оно. Interface - это всего лишь очень частный (хотя и наиболее часто встречающийся) случай использования MI. Чтобы понять, о чем я говорю, советую для примера посмотреть на диаграмму классов стандартной библиотеки Eiffel - когда в языке есть полноценный MI, можно говорить о полноценном "code reuse".

Кстати, еще не самый плохой вариант - это mixins. Но всех проблем оно тоже не решает.

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

Угу. А потом городятся всякие монстры типа anonymous inner classes, чтобы на функцию-однострочник уходило не 10 строк кода, а всего лишь 5. В то время как в лиспе и Ruby это записывается в одну строку, которая начинается с lambda...

> Multiple dispatch нету, решается достаточно просто.

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

> какие насущные проблемы это решило?

Как это какие? У linux.org.ru нет интерфейса веб-сервиса поэтому никто не может до сих пор написать оффлайн клиента, хотя попыток только за прошедший год было 4 или 5. Знаешь почему не могут? Потому что на Лиспе написать такого клиента за приемлемое время невозможно. Если ты не согласен - докажи, напиши.

>зато если посмотреть на размер спецификации SOAP, или даже просто на исходник запроса при вызове простейшей функции... это же надо такого нагородить.

Ну EJB серверы тоже не детский объем памяти жрут, и что? Их же разворачивают не для вызова простейших функций из учебника?

> Это был наезд не конкретно на тебя, а на общий стиль аргументов: "если я не согласен с решением, но оно принято, то принимали его идиоты"

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

> А с точки зрения практического применения, как-то не срослось.

Вот! Именно "как-то". Так может, лучше, чтоб такие вещи делались не "как-то", а все-таки по уму?

> Одно дело, защитить диссертацию, а другое дело - внедрить результаты в производство :)

Что характерно, лисп внедряли в производство. См. про Yahoo! Stores выше. Очень даже хорошо работало.

>> Любой подход предполагает использования design patterns. Паттерны вовсе не ограничиваются GOF,GRASP,J2EE и т.д. Паттерн - это решение типичной проблемы.

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

У белых людей для этого есть библиотеки и хорошая IDE.
У все свои "типичные проблеммы". Все design patterns в язык не ввдедешь.
И в разных случаях реализация одно и того же паттернов выгодная разная.
Типичный пример State Machine, я их видел целый автопарк ;-)
и в кажбом случае выгоден был свой конкретный вариант.

>Те же factory и visitor, например.

какой factory ты имешь ввиду?
Factory method - и так одна строчка, Abstract factory - в нормальных IDE создается двумя щелчками мыши.

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

А реализация не страдает при этом подходе?
IMHO я бы хотел пример visitor'a в две строчки.


>> Можно пример?

>Любой factory-класс в жабке. Куча лишнего кода (собственно, сама необходимость задавать такой класс в явном виде - уже бяка)

давай в терминах GoF ок и с кодом.


>> Какие языки являются нормальными? Для меня Assembler,C,C++,perl, JAVA - нормальные языки.

>Обеспечивающие минимальный необходимый функционал. Как минимум - functions as first-class objects, closures. Далее в порядке убывания: возможность программно править AST во время компиляции (aka макры), multiple dispatch, pattern matching.

Ты забыл назвать языки ;-)
Из ходя из требований ты любишь List и Ruby ;-)))
Closures - любители их использовать как раз плодят copy paste software(c которым ты выше призывал бороться).
multiple dispatch - к java можно прикрутить на раз (ask google)
макрухи в java пруд пруди, а anatations - ещё больше
pattern matching - нет нет нет, и ещё раз нет. Для этого есть IDE. Не надо засорять язык.

И ещё давай исходить из проблем, опиши проблему, для решения которой тебе нужен этот zoo.

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


>> Зачем это было делать на С#? Можешь привести пример когда ты считаешь выгодно использовать мультиметоды?

>Это было реально нужно. В подробности вдаваться не буду, но именно нужно было описать некую операцию над двумя объектами, которая зависит от run-time типа обоих.

На java при помощи reflection в пару сток кода.

>Пришлось городить зоопарк интерфейсов и фреймворк, позволяющий - по сути - "регистрировать" мультиметоды для разных типов, и делать multiple dispatch.

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

> Каким нах нишевым языком? А на чем пишут расширения для gimp, blender, ...?

grep 'python' /etc/init.d и хрен вам.

bash и perl - рулят.

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

> Сначала PR, потом по инерции, а потом уже слишком много вложили, чтоб разворачивать оглобли. Типичная картина для этой индустрии, кстати. Аналогичная ситуация, например, с XML и веб-сервисами.

Чем плох XML, как формат обмена данными, когда скорость их обработки большой роли не играет? Особенно если написана толковая Schema? Может есть лучшая альтернатива XML-форматам оффисных документов? Не, может я дремуч, просвети.

P.S. Не, понимаю, есть места, где XML - зло. Например, писать код на нём (XSLT).

> Как это какие? У linux.org.ru нет интерфейса веб-сервиса поэтому никто не может до сих пор написать оффлайн клиента

Еще раз и внятно: единственную проблему, которую решают вебсервисы - это interoperability (и то до недавнего времени граблей хватало). Но для решения такой, по сути, простой проблемы, SOAP - это оверкилл. Зачем при тупейшем вызове метода гонять туда-сюда XML-запрос, в котором к тому же половина элементов играют роль бантиков?

> Знаешь почему не могут? Потому что на Лиспе написать такого клиента за приемлемое время невозможно. Если ты не согласен - докажи, напиши.

Гы =)

http://www.linux.org.ru/profile/int19h/view-message.jsp?msgid=833349

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

> Ну EJB серверы тоже не детский объем памяти жрут, и что? Их же разворачивают не для вызова простейших функций из учебника?

Приведи пример, где весь мусор SOAP-вызова - оправдан.

А никто и не говорит, что линукс - хороший язык программирования. Хотя, возможно и не хуже Явы с C++:-).

Вообще, интересно, чтобы доказать, как убог язык Java, приводятся примеры из нескольких принципиально разных языков - Eiffel, Ruby и Lisp. Как насчет одного единственного языка, который бы убил Яву в одиночку?

Я могу еще добавить - в Java нету механизма рандеву как в Аде, механизма COMMON-областей как в Фортране, сопрограмм как в Модуле-2, перегрузки операторов как в C++ и т.д. и т.п. Я не говорю уже о том, что ссылаться на механизмы функциональных языков, обсуждая язык нефункциональный, как-то некорректно.

<ШУТКА> И потом, я же могу задать и такой вопрос: как насчет написать обработчик прерывания на Лиспе? Трудно? Тогда, простите, Лисп - отстой, C - вот наш выбор. </ШУТКА>

> Ну если ты это так воспринимаешь - это твои проблемы.

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

А что уважаемые товарищи скажут про Ruby?
Я его в рейтинге не заметил,
значит ли это что он такой плохой и никому не нужный?

ой ой ой
прежде чем говорить надо подумать ..... полезно
может хватит на лоре идиотских сравнений Lisp еще с чем-то
все равно что Х.й с пальцем сравнивать
и доказывать преимущество одного перед другим
---
а устаревшие классы ....
возмем например ML очень бы хотелось что бы на всю его
стандартную библиотеку depricated поставили - редкостное дерьмо
а дизайн патернами в функциональных языках не пользуются
не потому что не надо а потомучто микроцефальской головки не хватает
посмотреть на все что там натворили - ну гадость, лучше бы они явой занимались
__
>>> не я придумал Lisp =) но понять, что по семантике он намного продвинутей жабки, мне ума таки хватает

вообще перл глупости

> У все свои "типичные проблеммы". Все design patterns в язык не ввдедешь.

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

Кстати, не только паттерны. Еще один наглядный пример - AspectJ. Сейчас вот умные дяди сидят и переписывают компиляторы под AOP. А были бы в жабке макры - все это дело можно бы нарисовать на них.

> У белых людей для этого есть библиотеки и хорошая IDE ... Abstract factory - в нормальных IDE создается двумя щелчками мыши.

Вот-вот. Автоматизация сopy&paste - куда мы катимся...

> IMHO я бы хотел пример visitor'a в две строчки.

Можно в одну. Visitor pattern - это как раз эмуляция multiple dispatch для двух аргументов средствами single-dispatch языка.

> давай в терминах GoF ок и с кодом.

Abstract factory. Код - см. здесь: http://norvig.com/design-patterns/ppframe.htm - там есть слайд "Pattern: Abstract Factory".

> Ты забыл назвать языки ;-) Из ходя из требований ты любишь List и Ruby ;-)))

Да. Еще Haskell.

> Closures - любители их использовать как раз плодят copy paste software(c которым ты выше призывал бороться).

Объясни, как замыкания провоцируют C&P.

Заодно можешь объяснить, чем жабские anonymous inner classes принципиально отличаются от кастрированных замыканий.

> multiple dispatch - к java можно прикрутить на раз (ask google)

Можно. Но я не этим должен заниматься. Мое дело - решать задачу, а не лепить ООП-фреймворк на основе goto, условно говоря.

> макрухи в java пруд пруди

Где? Покажи. Не C-style, а именно манипуляцию AST программы.

> pattern matching - нет нет нет, и ещё раз нет. Для этого есть IDE.

Не понял... при чем тут IDE?

> И ещё давай исходить из проблем, опиши проблему, для решения которой тебе нужен этот zoo.

Любое гуевое приложение сложнее хелловорлда. Нет, его можно написать и без всего этого, разумеется. Его можно написать и без ООП, и вообще без структурного, на одних goto. Но зачем это делать?

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

Ты подставляешься =) Для начала "define:нормальные программисты" и "define:приемлимое"

> На java при помощи reflection в пару сток кода.

Да? А dispatch-таблицу ты где хранить будешь? И ты выковыряешь из нее нужную функцию (то есть тьфу, интерфейс, функции же у вас значениями не являются - накидываем еще пару строк лишнего кода на описание класса вместо функции) в две строчки?

> Одно из двух, либо проблему ты описал плохо, либо плохо выучил язык, на котором писал. В приведенном выше описании проблемы такой zoo не нужен.

Я привел часть проблемы. В общем случае там речь могла идти о более чем двух объектах.

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