(no subject)

[beldmit]

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

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

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

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

Comments

[dph.livejournal.com]

Без специальных усилий написанный код на Java будет гораздо читаемее, нежели такой же на perl.
Если прикладывать усилия, можно написать нечитаемый код на Java и читаемый - на perl. Но нужно делать это специально, что встречается не часто. И, в любом случае, на Java будет проще разобрать даже специально нечитаемый код - благодаря хорошим IDE.

Плюсы Java:
минимальность концепций и парадигм (на дает разработчику делать одно и то же тремя разными способами);
плохочитаемые вещи требуют больше усилий (тот же reflection для простых задач проще не делать, чем делать);
качественные IDE, упрощающие большую часть анализа и рефакторинга кода.
более-менее стройные библиотеки, приучающие (и позволяющие) пристойный стиль разработки;
community, озадаченное проблемой читаемости кода;
создатели языка, понимающие необходимость простоты языка и API;
куча разумных библиотек.

Может, что-нибудь я еще не заметил.

Ну а на perl нужно прикладывать специальные и нетривиальные усилия для написания поддерживаемого кода, увы. И, в среднем, код, написанный очень средним программистом, будет не слишком удобен. Вообще, сейчас среднему программисту проще жить внутри ООП (который в perl сомнителен), нежели в ФП или в процедурном.

[shaplov.livejournal.com]

Ну а на perl нужно прикладывать специальные и нетривиальные усилия для написания поддерживаемого кода, увы. И, в среднем, код, написанный очень средним программистом, будет не слишком удобен. Вообще, сейчас среднему программисту проще жить внутри ООП (который в perl сомнителен), нежели в ФП или в процедурном.
Может быть я слишком долго пишу на перле, но это утверждение кажется мне неубедительным.

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

[solom.livejournal.com]

ЧО вы все так перла боитесь/ненавидите? Да всё там читаемо, ёлы-палы. Императивщина - она и в африке императивщина.

[dph.livejournal.com]

Вот-вот. Где-это вы видели читаемую императивщину...
Впрочем, если бы под perl была только императивщина...

[arilou]

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

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

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

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

Впрочем "код, написанный очень средним программистом" - боюсь, уже не совсем то, о чём стоит так сильно беспокоиться. Хотя, может быть, это и есть ниша для Java - "язык для очень средних программистов"?

[dph.livejournal.com]

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

Собственно, у нас с тобой очень разные позиции. Ты исходишь с позиции разработчика - тебе нужно, что бы на языке было просто выражать свои мысли. Я уже давно - с позиции team lead и мне важнее читаемость плохого кода, простота интеграции разных модулей и т.п. Т.е. для меня простота, многословность, излишний контроль и т.п. - гораздо важнее гибкости и лаконичности.
Поэтому и говорю, что из моей позиции (а я склонен думать, что она гораздо ближе к массовому производству) java - гораздо лучше, нежели perl.

[beldmit.livejournal.com]

Ну, неподдерживаемый код на Java в Мастерхосте был. Что и привело, в частности, к прекращению существования проекта на Java.

[dph.livejournal.com]

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

[dph.livejournal.com]

"Хотя, может быть, это и есть ниша для Java - "язык для очень средних программистов"?"

Хм. Хороший программист выберет себе язык под конкретную задачу - и поэтому говорить о языке для хорошего программиста не имеет смысла. Java - очень хороший язык для тех случаев, когда нужно выбрать один и только один язык для проекта.
Увы, команды, позволяющая использовать эффективно много разных языков встречаются крайне редко (я, например, не видел именно команды, все сотрудники которой могли бы легко переключаться между erlang, c, java, lisp - а это, наверно, минимальный набор "классов языков" для сложного проекта).

[arilou]

Только сейчас прочёл, на что это было ответом. :)
Извини, но та и не увидел ответа на вопрос, за счёт чего возникает поддерживаемость.
Ну кроме тезиса про минимальность концепций и парадигм. Хотя это как раз "прокрустово ложе". С тем же успехом можно утверждать, что было бу куда лучше, если бы в мире был только один язык программирования. :)
В остальном же получается что-то вроде "поддерживаемость возникает из поддерживаемости и стремления к поддерживаемости". Примеров можно? Конкретных достоинств и недостатков?

[dph.livejournal.com]

Э, тебе точно нужно описать, почему код на языке со строгой типизацией, без макросов и со сборкой мусора гораздо легче читается и гораздо эффективнее статически анализируется в ide, нежели без указанных особенностей?

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

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

[arilou]

Ну поскольку я сравнивал с перлом, то не надо про макросы и не надо про сборку мусора. :)
А строгая типизация - палка о двух концах всё же. Не отрицаю её достоинств, но иногда от неё удобства - как от латных доспехов на балу.