языки (программ.)

[avva]

Я задумался недавно - как часто задумываюсь наедине с собой, бессонной ночью, ворочаясь на кровати, в те часы, когда все наносное, вся суета существования растворяется в темноте и на поверхность выходят самые беспощадные вопросы, самые жестокие дилеммы и все нескончаемые споры - о Джаве. Как все же она умудрилась из интересного и многообещающего языка так быстро превратиться в неподъемное чудовище, обросшее сотней неповоротливых фреймворков и чудовищных аббревиатур?

Так и не решив этот вопрос, моя измученная душа нашла, наконец, свой упокой в объятиях Морфея.

А сегодня я подумал: почему, собственно, "так быстро"? Джаву придумали в 93-м, а всерьёз обсуждать стали в 94-м. Это 13 лет назад. Как по-разному воспринимается время "до нас" и "при нас"! В 93-м году, будучи первокурсником, я воспринимал C++ как давно существующий, совершенно стандартный язык; казалось, что он был всегда (я знал, когда его придумали, но я говорю об ощущениях). А C++ тогда существовал в более-менее современном виде 10-11 лет. Меньше, чем возраст Джавы сейчас; но Джава и сейчас кажется недавним новшеством.

Интересно, те, кто сейчас начинают учиться программированию - им тоже Джава кажется чем-то незыблемым и всегда существовавшим, как мне казался C++?

Comments

[raindog-2.livejournal.com]

Думаю, причина в идеологической подоплеке.

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

А поскольку С++ ужасен, то, хрен редьки не слаще. То есть будем радоваться тому, что есть.

Тебя не было, когда к нам приходил Walter Bright? Язык D - вот оно, фьюдущее ;)

[alexclear.livejournal.com]

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

Классические паттерны, как я помню, описаны с примерами на Smalltalk, при чем тут слабости языка Java?

[bortengineer.livejournal.com]

Ну, ведь так и было сказано: "отдельная тема", т.е. речь, видимо, шла не конкретно о Java. А вообще - идея паттернов действительно идёт от слабостей языка. Ведь было бы здорово, если бы мы смогли просто сказать: "Хочу синглетон" и тут же получить оный. Отсюда и родился LOP и ему подобные...

[raindog-2.livejournal.com]

:) впервые на правтике встречаю ситуацию, когда артикль был бы полезен в русском. Имелось в виде, не языка Java, а просто языка. Не the language, а a language. Любого языка.

Ну, например паттерны "цикл" или "присвоение" мы не называем паттернами, птотму что они поддерживаются, как примитивы, большинством императивных языков. Это позволяет нам a) думать в терминах "циклов" b) иметь стандарнтый и очень reusable метод имплементации.

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

Пример1: Visitor pattern. Решает он проблему, специфичную для single-dispatch OOP. В языке с multiple-dispatch механизмом нет изначальной проблемы, соответственно, и о Visitor pattern'е говорить не приходится. На практике, кстати, часто Java-программисты режут угол и используют хак с typeof оператором, чтобы в очередной раз не имплементировать красивый, но многословный Visitor pattern.

Пример2: Observer pattern. Библиотека Qt расширяет (с помощью препроцессора) стандартный C++ и добавляет slots & signals. Получается поддержка Observer pattern, как бы, на уровне языка. И использовать эту возможность очень просто. Если бы эта возможность была естественной и встроенной в большинства языков, никакой идеи об "Observer pattern" не возникло бы. Как не говорим мы о "Virtual Method Call", и пр. встроенных возможностях языка, как о паттернах.

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

[alexshubert.livejournal.com]

"В отличие от С или Perl, которые были созданы с целью решения конкретных программистских задач "
на одной из конференций Вол говорил, что Perl - вовсе не должен был быть языком программирования . Он писал самый обычный макро-язык для разбора текста.
Ставить в один ряд С и Perl вообще очень некорректно.

Паттерны пришли из SmallTalk.

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

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

Удивлен.

[raindog-2.livejournal.com]

на одной из конференций Вол говорил, что Perl - вовсе не должен был быть языком программирования . Он писал самый обычный макро-язык для разбора текста.

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

A, хороший пример еще - Lua. Это был вообще не язык, а формат конфигурационного файла. А развился в один из самых практически полезных скриптовых языков.

Ставить в один ряд С и Perl вообще очень некорректно.

Почему?

Паттерны пришли из SmallTalk.

См. про паттерны выше.

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

Ой, нет, тут misunderstanding. Я как раз за штатные средства языка + стандарные библиотеки. By contrary, когда говорят о фреймворке, то имеется в виду как раз нештатное решение. Первое - лучше, на мой взгляд.

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

Ну меня-то волнует не реализация, а собственная продуктивность. Я пишу массу практически полезных one-liner'ов на Perl, каждый из которых занял бы сотню линий (это не преувеличение) на Java.

[alexshubert.livejournal.com]

С проектировался именно как общий язык. В том-то и дело. Макросы вообще сложно называть языками. Поэтому сравнивать именно язык с макросом некорректно, мне кажется.

Вот тут немного спорно, мне кажется. Фреймворком сейчас называют все и вся, что может быть выделено в пакет или технологию. AJAX вон уже тоже фреймворком звать начали. НО идея я понял, здраво.

Любопытство взыграло. А вам не будет сложно привести пример? Я очень плохо знаком с Perl и мне интересно, что именно вы имеете в виду. Если не сложно, был бы благодарен.

[raindog-2.livejournal.com]

Любопытство взыграло. А вам не будет сложно привести пример? Я очень плохо знаком с Perl и мне интересно, что именно вы имеете в виду. Если не сложно, был бы благодарен.

Конкретный пример, на который я ссылался - у нас 2 линии perl заменили три здоровенных Java-класса. Это было на прошлой работе, полный код я привести не могу - он proprietary, но могу подробно описать. Речь шла о протоколе связанном с цифровыми камерами, серверная часть. Так получилось, что еам нужно было срочно (за несколько часов) протестировать новый протокол и задача была - прочесть данные в текстовом формате, отпарсить это, немного заменить кое-что, затем перекодировать в бинарный протокол и послать по TCP/IP по определенному адресу. Perl позволяет очень эффективно такие задачи благодаря
- regular expressions на уровне языка
- встроенный функции pack и unpack. Они очень удобны для сериализации - десериализации данных, т.е. бинарных протоколов
- операторы map{} и grep{} которые позводяют удобно работать с массивами
- и пр.

Этот пример, конечно, андекдотичский, обычно речь не о сотне линий vs. 1 линия, но просто о существенно более коротком коде.

Обычные операции, для которых (лично мне) удобен Perl - прочесть файл, что-то поменять или посчитать статистику, сгенерировать какие-нибудь тестовые данные, и пр.

Особая ценность Perl - в библитотеке CPAN. Это единая распределенная библиотека Perl, с некоторой автоматизацией доступа. Аналоги для других языков имеются, но по широте покрытия CPAN уникален. Пожалуй, это самый яркий пример code reusability, который я видел.

***

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

[alexshubert.livejournal.com]

В любом случае, послушав вас, я заинтересовался Perl и в ближайшее время полезу смотреть. Как только EJB дочитаю :)

[alexshubert.livejournal.com]

В любом случае, послушав вас, я заинтересовался Perl и в ближайшее время полезу смотреть. Как только EJB дочитаю :)
Спасибо.