(no subject)

[beldmit]

Собственно, возвращаясь к посту про настоящего программиста. Там в комментах cmike высказал мнение, что Java - это такой нишевый язык.

Я задумался, и понял, что ниши для Java я не представляю. Возможно, сейчас не представляю - потому что уже есть C#.

Посему вопрос: какие задачи могут быть удачнее, чем на каком-либо другом языке, решены на чем-нибудь из списка: Java, Smalltalk, Haskell, Erlang? Меня устроит, если будет какой-то другой язык близкого класса, который это позволит сделать (кроме Java - там я хотел бы видеть четкие преимущества).

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

Comments

[beldmit.livejournal.com]

Тут обосновал.

Саппортить - зависит от архитектуры все-таки, а не от языка?

[vitus_wagner]

Язык накладывает очень сильные ограничения на пространство возможных архитектур. Вернее, разные языки накладывают разные ограничения. Perl и C++ - меньше, Java - больше. Common Lisp - еще меньше, чем Perl и C++.
Для некоторых программистов это ограничение хорошо. Для хороших программистов - скорее плохо. Хороший программист сам на себя ограничения наложит, и эти ограничения будут ближе к требованиям задачи, чем ограничения, заложенные в язык хоть самим Гослингом, хоть самим Кнутом, ежели те и не подозревали о том, что этим языком будут решать данную задачу.

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

Соответственно Java хороша там, где программист - расходный материал.

[dph.livejournal.com]

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

[city-rat.livejournal.com]

Тут несколько факторов:

1) говорить об архитектуре перловых решений вообще не имеет смысла. Понятно, что написать можно что угодно на чем угодно, но архитектура перлового решения заведомо будет в основном в голове ее создателя. А вот в яве многие архитектурные решения логично получаются из спецификаций самого языка, окружения и т.д. и т.п., не говоря уж о явно специфицированных вещах типа j2ee, JSR-168 и т.п., и дикого количества готовых платформ (именно платформ, со специфицированными интерфейсами и архитектурой, а не кучи скриптов и библиотек с каким-никаким API). Понятно, что все это все равно надо соблюдать и, среди прочего, ходить с кнутом среди разрабов, дабы не ваяли в стиле перл. Но есть существенная разница между кнутованием по схеме "делай, как я говорю" или "делай, как в спеке написано".

2) у явы синтаксис банально яснее. т.е. понятно, что и на яве можно написать нечитаемо, но если на яве для этого нужно прилагать специальные усилия, то на перле - ровно наоборот, специальные усилия нужно прилагать для обеспечения читаемости.

3) про развитость тулзов не говорю: взять автодоки. В перле тоже есть некие недавно появившиеся спеки на документирование кода, но до такого уровня, как банальный javadoc еще пахать и пахать (и вряд ли кто будет это делать, так как у перла как такового ниша изначально - написание скриптов уэб-мастерами-одиночками). Ну и вообще - ява сильно объектнее, ее автодокументировать по определению проще.

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

[beldmit.livejournal.com]

Да, согласен.

[arilou]

1) Тут, получается, выбор между "архитектура дана нам свыше, шаг влево, шаг вправо - попытка к бегству" и "архитектуру надо будет продумать, но за то под условия нашей конкретной задачи". Разумеется, если не расчитывать на то, что систему будут проектировать головой, да при том сначала, а не после написания половины системы, то Perl не годится.

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

3) Вообще-то, существует doxygen, на котором можно документировать хоть под C++, хоть под Perl, хоть под чем ещё. Что особенно приятно для тех, кто программист вообще, а не "программист на одном богизбранном языке".

[dph.livejournal.com]

1) Немножко не так. На java ты для почти всех "лучших практик" найдешь уже готовое и проверенное в production решение. На perl - увы.
Да, кстати, что-то не доводилось мне видеть спроектированных "с головой" систем на perl :( Отдельные модули - да. Системы - нет.

2) Требует, требует. Код, созданный двумя десятками разработчиков очень разного уровня за пять лет на perl - нечитаем. Так как не бывает команды без бардака, увы. Такова жизнь. Правда, быть может, у нас с тобой разные критерии читаемости....

[beldmit.livejournal.com]

Doxygen под Perl не работает. Во всяком случае, год назад не работал.