Программирование на Scala

>> Ява крута библиотеками, язык она в лучшем случае весьма средний (кто сказал почти провальный? :D).

>Мне почему то видится противоречие между почти провальностью языка и крутостью библиотеками

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

> Для брейнфака не наблюдается особенного потока библиотек.

Ему рекламы не хватает, ага.

Тогда не вижу смысла в краткости кода... Читать типа меньше? аргумент слабый - читаю быстро, да и выборочно...

Кстати, изначально спорили сколько нужно _написать_ вроде как.. =)

>Ему рекламы не хватает, ага.

Нифига бы не вышло... имя у него больно неитерпрайзное..

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

Насчёт кобола - я наверное просто не в курсе, но про открытые качественные библиотеки не слышал вообще. визивасик - здесь вообще сравнивать не получится, потому что он дотнет, и юзает дотнетную платформу. В общем читер.

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

> И если эта задача - написать макрос к .doc-у, осмелюсь предположить, что визувасик будет лучше лиспа.

Чем же? Какие именно свойства VB как языка делают его более пригодным для этой задачи?

>Только ни один геттер и сеттер я не пишу Alt+Shift+S r и вуаля! Так что...

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

Там выше есть интересная мысль: что узкое место большинства современных программ - это IO (абстрактные числодробилки щас уже никому не нужны), а это значит что это узкое место присутствует везде: файлы, соккеты, взаимодействие с какими-то устройствами. И по большому счету здесь уже не важно perl, ruby, python или быдложаба...

Что у великих программистов на питоне свои абстракции для работы с сетью, или там все-таки тоже соккеты (как в быдложабе)? Свои протоколы? Или они могут маппить файлы в память не расходуя эту самую память?

И в конечном счете решающую роль играет не то нужно ли объявлять геттеры/сеттеры, а такие вещи как надежность, защищенность, переносимость, производительность, и наличие средств позволяющих решать ту или иную задачу с приемлимым ущербом для этих понятий. Я предпочитаю чтобы они выносились в отдельные библиотеки (желательно реализующие какую-нибудь спецификацию со стандартным API) вместо того чтобы засирать язык. Любители питона/руби считают по другому - это их право. Но спорить о синтаксисе глупо.

P.S. А поводу скалы - даже одной книги будет вполне достачно, чтобы начать применять язык - тем более там есть вещи которые любителям питона и не снились - один паттерн-матчинг с поддержкой xml в выражениях (и на уровне языка вообще) чего стоит - уже одно это может похоронить XSLT. Обработка xml в скала исключительно приятное и простое занятие по сравнению с XSLT+активное использование расширений.

> Насчёт кобола - я наверное просто не в курсе, но про открытые качественные библиотеки не слышал вообще

Потому что тогда не было цели создать Кобол-платформу. Написали на нем очень много, а писать библиотеки или приложения - разницы нет.

> визивасик - здесь вообще сравнивать не получится, потому что он дотнет, и юзает дотнетную платформу.

Гы, сына, лол. Чтобы ты знал - первая успешная версия VB вышла в 1990 году. И опять же - не было цели строить VB-платформу.

> А как вообще сравниваются языки?

Дело сложное. Но, есть вполне "очевидно ублюдочные" языки. Кобол, VB - из этого ряда (VB по крайней мере до .NET - с версиями для .NET я не знаком).

> Поэтому джаву с пайтоном сравнивать осмысленно на том поле, где джава используется.

Я вообще не сравнивал Яву с Питоном - речь шла о _конкретном примере_, и всё. Мне лично Питон не особо нравится (хотя я им пользуюсь) - вообще не люблю динамические языки.

> Там выше есть интересная мысль: что узкое место большинства современных программ - это IO

Этой исключительно интересной и оригинальной мысли не помешали бы доказательства. Мне вот лично кажется, что узкое место - огромный объем программ, когда они перегружают и L1-, и L2-кэш.

То, что он вызывается из Word-а по какому то волшебному сочетанию клавиш Alt-F10 что ли, не помню. А лисп не вызывается. Да, как язык, он здесь не при чём. Зато здесь решающую роль играют другие вещи, вроде наличия биндингов и прочего. И в реальной жизни это другие вещи зачастую играют не меньшую роль, чем красота языка. Простейший пример - команда Java-разработчиков, не знающих пайтона, реализует проект мелкого - среднего размера на Java быстрее, чем на пайтоне, каким бы крутым он ни был.

> Тогда не вижу смысла в краткости кода...

Это типично для жавистов. Современной медициной это пока не лечится, поэтому и спорить не буду. ;) К счастью, прогресс даже в яве идет в сторону уменьшения кода - см. J2EE 4 и 5. Может и геттеры/сеттеры подуменьшат к 9-й яве.

Когда процессор 90% времени простаивает, в ожидании ответа от сервера БД, кэши явно не являются узким местом. В какой-нибудь числодробилке или игрушке - безусловно являются.

> (к слову сказать я пришел к жабе от перла, от которого сильно фанател, так что с рюшечками я уже наигрался)

А, так и запишем - перл надоедает, потому что там рюшечки ради рющечек ;)

> Но спорить о синтаксисе глупо.

Наоборот, умно. Иначе бы мы все использовали Фортран или Алгол, я уже забыл историю.

>> Но спорить о синтаксисе глупо.

> Наоборот, умно. Иначе бы мы все использовали Фортран или Алгол

Алгол68 рулит :)

> Зато здесь решающую роль играют другие вещи, вроде наличия биндингов и прочего.

У питона мало биндингов? O_O

Я понял бы, если бы возносилась слава JEE и/или Spring.

> Наоборот, умно. Иначе бы мы все использовали Фортран или Алгол

> Алгол68 рулит :)

Ну этот как раз есть следствие споров о синтаксисе, не тру.

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

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

>Простейший пример - команда Java-разработчиков, не знающих пайтона, реализует проект мелкого - среднего размера на Java быстрее, чем на пайтоне, каким бы крутым он ни был.

Вопрос можно повернуть и обратным боком, команда python-разработчиков, не знающих java ...

Да ёшкин кот. Какие мы аргументированные =) Я ж не против краткости. Я просто о том что она - далеко не главное.

>> Тогда не вижу смысла в краткости кода...

>Это типично для жавистов. Современной медициной это пока не лечится, поэтому и спорить не буду. ;) К счастью, прогресс даже в яве идет в сторону уменьшения кода - см. J2EE 4 и 5. Может и геттеры/сеттеры подуменьшат к 9-й яве.

Краткость кода не нужна, нужно столько кода писать, сколько понадобится компилятору, чтобы генерировать эффективный код без неоднозначностей. А то налепят динамического г-на, типа "на 2 строчки печатать мне меньше пришлось, лять", а потом в рантайме проц молотит вхолостую, разбираясь на каждый чих, какойже метод тут программист хотел вызвать? Как здесь http://en.wikipedia.org/?title=Multimethods . Хорошо если это скрипт написанный за 2 часа и которому суждено отработать 1 раз. А если это сайт 24х7?

Так что я согласен писать столько сколько процессору нужно, тем более что мне за программирование деньги платят

> Краткость кода не нужна

...если тебе платят построчно

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

Прикинь, для этого отнюдь не нужна многословная Ява - почитай хотя бы о type inference, о Haskell и OCaml.

> Так что я согласен писать столько сколько процессору нужно

А!!! Машины поработили человеков!

> Я ж не против краткости. Я просто о том что она - далеко не главное.

А 40 сгенерированных геттеров и сеттеров - главное? А что в них такого сакрального?

Не понял... Где я сказал что 40 гетеров и сетеров - это круто? я сказал что _мне их писать не надо_. Читать кстати тоже мне из не надо. Мне только их использовать. Главное - что бы писать было удобно. Мне - удобно писать на java, и не в последнюю очередь из-за отчлиное IDE.

>Прикинь, для этого отнюдь не нужна многословная Ява - почитай хотя бы о type inference, о Haskell и OCaml.

Прикинь, чтобы пользоваться type inference, нужно знать теорию категорий, а это 5 лет в ВУЗе учить только вышку, а не в ПТУ на программиста выучиться. После 5 лет математики тебе не захочется за $500/month программировать сайты,интернет-магазины, а пойдешь в финансисты. Так что вот так.

А без теории категорий от type inferencов с хаскелями толку как от болида Formula1 на посевной

Ну тут всё таки не совсем верно, функциональные языки кажутся сложными только потому что они другие, а не потому что они "для элиты". Мне кажется - будут обучать в ПТУ Haskell & OCaml & Lisp & etc - так и на них кодить будут. Какая разница?

> Прикинь, чтобы пользоваться type inference, нужно знать теорию категорий

Чтобы пользоваться - не надо. Так же, как для написания JVM нужно много лет, а для использования - 1 команда shell 8)

> Где я сказал что 40 гетеров и сетеров - это круто? я сказал что _мне их писать не надо_. Читать кстати тоже мне из не надо. Мне только их использовать.

Если немного подумать, то и использовать их тоже не надо. Нафиг, по существу, нужны someObj.setSomeField(fieldValue)? ;) > Главное - что бы писать было удобно. Мне - удобно писать на java, и не в последнюю очередь из-за отчлиное IDE.

Уже все сказали: http://www.lorquotes.ru/view-quote.php?id=2411

Зачем нужны? что бы не порождать новых сущностей. Что бы не замусоривать язык. Что бы D в частности не получился =) . А так выругаться можно на любой язык. Мне пофиг, что сложно писать на джаве без IDE - потому что она есть и мне _в ней_ писать _удобно_. Я не вижу смысла что то делать для блокнотовщиков. =)

> что бы не порождать новых сущностей. Что бы не замусоривать язык.

А нельзя было просто использовать public Field; если, по ощущениям, 99% getter/setter - парные и вырожденые?

> Мне пофиг, что сложно писать на джаве без IDE - потому что она есть и мне _в ней_ писать _удобно_

То вохзражений, что 500 строк ява кода (включая нагерененный), вполне могут быть заменены 100 строчками питоновского - нет? А о чем тогда спор?

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

Спор о том на чём быстрее(или удобнее) _написать_. И в _реальных_ а не синтетических примерах сомневаюсь что отношение числа строк именно такое. А что вы предпочитаете мерять пипи^Wколличеством строк? =)

> Можно.

Вобще-то "нельзя, потому что есть спецификация JavaBean", а вопрос был скорее к ее авторам, чем к вам :)

> благодоря современным иде перейти от обычного поля - к достопу гетерами и сетерами

Я в курсе о явовских IDE (о свободных), можете не рассказывать.

> Просто сторонники никогда не открывать полей.

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

> Спор о том на чём быстрее(или удобнее) _написать_. И в _реальных_ а не синтетических примерах сомневаюсь что отношение числа строк именно такое.

Сугубо зависит от. Есть реальные приммеры на Спринег, где целые файлы - пусты (с точки зрения питона). Бувает и наоборот, если скажем из питона использовать ActiveMQ - да, будет почти тот же код, что и на яве при использовании JMS.

> А что вы предпочитаете мерять пипи^Wколличеством строк? =)

1. А кто первый начал наежать, что 50 строк быть не может и т.д. и т.п, как не джависты?

2. Да, специфика текущей деятельности. При демонстрации слайдов, печати методичек и демосрации примеров краткость настолько помогает красиво оформит материал, что использовать для этих целей C#/Java - просто себя не любить.

>То вохзражений, что 500 строк ява кода (включая нагерененный), вполне могут быть заменены 100 строчками питоновского - нет? А о чем тогда спор?

Так когда ж сцуко Microsoft перепишет свой Office, SQL Server, Axapta и .NET Framework на Python, OCaml или Ruby? Что ж они с C++ ковыряются? У них же там штат R&D в сотни Ph.D и бюджет нескольких банановых республик на разработки? Чтож они, дураки такие, байты в C++ считают, когда можно одним махом MS Office в 100 строчек написать? Ась?

Ах, да, да, я забыл, у нас в Google Python используют. Вот только для прототипов, а для продакшен серверов эти прототипы перегоняют в C++ код.

1. Я не наезжал - просто выражал долю скепсиса =), что на питоне всё решается 40-50 строчками. А именно так написали, не поинтересовавшись даже особо, а что функционально надо то.

2. При демострации слайдов - да, тут питон получше наврено. Но я и не говорил что джава рулит везде.

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

> Так когда ж сцуко Microsoft перепишет свой Office, SQL Server, Axapta и .NET Framework на Python, OCaml или Ruby?

Денег, чтобы с нуля переписывать, ты им дашь?

> Что ж они с C++ ковыряются?

http://en.wikipedia.org/wiki/Legacy_system

> У них же там штат R&D в сотни Ph.D и бюджет нескольких банановых республик на разработки?

Ага, ага. и кнопку "Пуск" разрабатывали полторы сотни спецов по юзабилитям. Слышали.

P.S. Все-таки приплюснутый - - диагноз.

> Так когда ж сцуко Microsoft перепишет свой Office, SQL Server, Axapta и .NET Framework на Python, OCaml или Ruby? Что ж они с C++ ковыряются?

1. Ты действительно не знаешь ответов на эти вопросы? Ну, с дураками общаться не буду ;)

2. Кури IronPython/F#/Lisp.NET ;)

> . А именно так написали, не поинтересовавшись даже особо, а что функционально надо то.

Да, они гнали^W хотели щелкнуть по носу джависта.

> Да, многословность - плата за простоту языка. Вовсе не вся. Геттеры и сеттеры, обязательные throws и обязательное описание типа у переменных с инициализатором (см. C# 3.0), а так же концепт "один файл - один класс" - как-то влияют на слолжность языка? Я не уверен. А взять анонимные классы - я бы не сказал, что это простая концепция. Она кроме явы где еще есть-то?

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

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

>Ага, ага. и кнопку "Пуск" разрабатывали полторы сотни спецов по юзабилитям. Слышали.

Ну, в ХР она вполне себе нормальная.

> Да, многословность - плата за простоту языка.

Вобще надо взять как-нибудь грамматики языков, есть смутное подозрение, что у erlang'а она будет меньше, чем у явы. Ну а лисп-то наверняка выиграет. Так что придется какой-то хитрый критерий простоты выдумать.

1. То что хотели щёлкнуть - понял. Это всем охота. Я выражаю долю скепсиса что им так просто недотянуться =)

2.Она проста, а не тупа. И этим повёрнута к людям. В чём проблема?

1. У лиспа простой иснтаксис - но семантика не так уж и проста. Сколько у него там семантических конструкций?

2. erlang - многопарадигмный насолько я знаю, а это уже - изрядное усложнение. Хотя реально не кодил на нём, так что не знаю.

> 2.Она проста, а не тупа.

Проста она бы была, если бы простота языка порождала простоту кода. :)

> И этим повёрнута к людям. В чём проблема?

Э, не согласен. Сравним с ближайшим аналогом - C#. Близкий круг пользователей, близкое назначение, писать без IDE - на обоих трудно, C# 1.0 - клон жабы. Сравним C# 3.0 и 1.6?

PS Я не люблю C#/MS, если что.

> 1. У лиспа простой иснтаксис - но семантика не так уж и проста. Сколько у него там семантических конструкций?

Да, я согласен, тут надо хитро сравнивать, грамматику - бесполезно.

> 2. erlang - многопарадигмный насолько я знаю, а это уже - изрядное усложнение.

В последний раз он таким не был. Ну, некоторые считают, что concurent - это парадигма, но выглядит это как небольшое дополнение functional, добавляется две конструции - ! и receive, но ведь ими заменяется библиотека IPC, с другой стороны.

С# - сильно сложнее. Заметно болше сущностей и синтаксических конструкций => сложнее. За это я его и не люблю. Они убрали часть с++ бреда, зато добавили свой (один override, virtual, new - чего стоят!). Так что java6=java5 в смысле языка. java6 гораздо проще с# 3.0.

erlang - насколько я знаю он не чисто функциональный. Там и императивщина есть. А это уже 2 =). Этот язык нишевый, причём с джавой пересекающийся не так уж часто.

> java6 гораздо проще с# 3.0.

Как язык конечно проще, но я к тому, что код писать будет проще на C#. var, linq, etc.

var - это палка о двух концах. Ктомуже не так много времени пишу типы. Мало того я не так часто оъявляю переменные руками, во время использования о них догадывается IDE и сама их мне вставляет. Этот вариант мне нравится больше потому всё "перед глазами". linq - это конечно круто. я когда увидел - пропёрся. Но единственный язык в которм такое смотрится органично - lisp.(clsql). А в с# имхо выглядит искуственно.

> erlang - насколько я знаю он не чисто функциональный. Там и императивщина есть. А это уже 2 =).

Хмм... Что конкретно имеется в виду императивного, я в некоторых догадках. case дополнительно к where?

> Этот язык нишевый, причём с джавой пересекающийся не так уж часто.

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