Scala: A Scalable Language

>stream is automatically closed on exit from with-open-stream, no matter whether the exit is normal or abnormal.

Если бы не закрывал - вообще идиотизмом бы было - тут все ясно. В наружу исключение вылетит?

>Если бы не закрывал - вообще идиотизмом бы было - тут все ясно. В наружу исключение вылетит?

Естественно, ибо "вообще идиотизмом бы было" :)

>Естественно, ибо "вообще идиотизмом бы было" :)

А следовательно и естественно код превращается в аналогичный жабскому с точностью до синтаксиса по обработке IO исключений. Но анонимусу можно не беспокоиться он все на readable? прверит и с отвагой настоящего рубиста накодит замыкание в параметр к open которое будет работоспособно только в идеальном случае, а про все ошибки завалившие процесс нахрен прочитает в логе монгреля.

> В наружу исключение вылетит?

Нет. Для перехвата исключения внутрь можно положить (catch ....) и извращаться как душа пожелает, плюс можно передать флаги что делать в случае если файл есть/нет - типа :append :overwrite :new-version :error

>Для перехвата исключения внутрь можно положить (catch ....) и извращаться как душа пожелает

И извращения будут выглядеть так же как на жабе. Естессно. ЧИТД.

> И извращения будут выглядеть так же как на жабе. Естессно. ЧИТД.

Туплю. Был неправ. Только что проверил - исключения наружу вылазят - перехватывай их себе (catch ...) или (unwind-protect ...) с уже закрытым файлом.

> А следовательно и естественно код превращается в аналогичный жабскому с точностью до синтаксиса по обработке IO исключений.

Не аналогичный - закрывать файл самому не надо ни при каких обстоятельствах.

Вот даже пример кода:


(handler-case (with-open-file (f "aaaa" :direction :input)
                  (read f))
    (error (condition)
	(print "ERROR, but file closed"))
    (:no-error ()
	 (print "no error")))

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

Ну и что? Конкретизирую - я не против лямбд и замыканий - я против аргументов "а вы посмотрите сколько тут try..catch в жабе а в руби их нету" - их там ровно столько же.

> Конкретизирую - я не против лямбд и замыканий - я против аргументов "а вы посмотрите сколько тут try..catch в жабе а в руби их нету" - их там ровно столько же.

Ну я собственно не на руби отозвался... ;)

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

А я и не говорил что исключений не будет. Я говорил что лямбда мне даёт новый строительный блок, который сильно удобен в данном случае, ибо можно один раз написать код для работы с закрываемыми ресурсами и соответствующей обработки исключений, а не плодить каждый раз этот finally { close }.

Очень понравился пример с поиском заглавных букв:

  // this is Java
  boolean nameHasUpperCase = false;
  for (int i = 0; i < name.length(); ++i) {
      if (Character.isUpperCase(name.charAt(i))) {
          nameHasUpperCase = true;
          break;
      }
  }

Whereas in Scala, you could write this:

  val nameHasUpperCase = name.exists(_.isUpperCase) 

А нормальный программер (и не важно Java или C++) напишет это в одну строку:

  boolean nameHasUpperCase = name.eqials(name.toLowerCase()) 

Учите мат часть, господа. Хороший программист напишет программу на фортране на любом языке.

>А нормальный программер (и не важно Java или C++) напишет это в одну строку:

>boolean nameHasUpperCase = name.eqials(name.toLowerCase())

Ассимптотика разная. Плюс по два раза по строке пробегаемся :) Но обычно на это пофиг, конечно.

Асимптотика, конечно.

>Ассимптотика разная

Это гон, разумеется :) В обоих случаях O(N)

>Учите мат часть, господа. Хороший программист напишет программу на фортране на любом языке.

Суть примера не в поиске заглавных букв - и нормальный программер это понимает.

>То есть это ТЕОРЕТИК. Который ни разу не принимал участия в коммерческом проекте! :)))) В отличие от Tim Lindholm и Frank Yellin из SUN.

Для воинствующего невежества ссылки: http://www.google.ru/search?q=javac+Martin+Odersky http://java.sun.com/docs/books/jls/third_edition/html/j.preface3.html

Martin Odersky implemented the GJ compiler, and his implementation became the basis for javac (starting with JDK 1.3, even though generics were disabled until 1.5).

http://people.epfl.ch/martin.odersky ...the original author of the current javac reference compiler.

http://www.nabble.com/-ANN--lift-developers-abandon-Scala-in-favor-of-Cobol-t... Martin Odersky wrote javac 1.1-1.4 and designed the good parts of Java Generics

Таким теоретикам я доверяю больше, чем LorCertifiedAnalysts и практикамслора.

А вот история откуда вообще есть пошла Scala http://www.artima.com/forums/flat.jsp?forum=106&thread=163733 и зачем она понадобилась.

Поучительное чтиво для тех, кто превозносит хвостовую рекурсию в C# и на каждый комп норовит установить Mono и считает что Python и бэйсик это разные языки

>А нормальный программер (и не важно Java или C++) напишет это в одну строку:

> boolean nameHasUpperCase = name.eqials(name.toLowerCase())

>Учите мат часть, господа. Хороший программист напишет программу на фортране на любом языке.

Вот те, кто учат матчасть, сидят в профессуре в Берне, и разрабатывают компиляторы, а те, кто не учит, пишут boolean nameHasUpperCase = name.eqials(name.toLowerCase()) на любом языке, чаще всего на PHP, и говнокодят в задрищенске за 15тыр.

Если name состоит из 31999 char, то в коде val nameHasUpperCase = name.exists(_.isUpperCase) ты пробегаешься по этим 31999 1 раз, а в коде

boolean nameHasUpperCase = name.eqials(name.toLowerCase())

сначала 1 раз в методе name.toLowerCase(), чтобы получить x, а потом 2-й раз в коде name.eqials(x) . Налицо замедление работы программы в 2 раза. И чтобы поделки таких ухарей работали хоть как-то приходится покупать 8-процессорные системы. Кандидат в www.wtf.com

>Это гон, разумеется :) В обоих случаях O(N)

>WFrag (*) (19.05.2008 20:08:52)

Да нет, в первом случае O(N), во втором O(2*N)

>>Учите мат часть, господа. Хороший программист напишет программу на фортране на любом языке.

>Суть примера не в поиске заглавных букв - и нормальный программер это понимает.

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

public void deleteReport(Report report)
{
  sessionFactory.getCurrentSession().delete(report);
  log.debug("Report " + report.getId() + " has been deleted");
}

а это - конфигурация к инфраструктуре (Spring) для всех классов и методов.

<bean id="serviceTemplateBean" abstract="true" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"

>
  <property name="transactionManager" ref="transactionManagerBean"/>
  <property name="transactionAttributes">
    <props>
      <prop key="delete*">PROPAGATION_REQUIRED</prop>
      <prop key="save*">PROPAGATION_REQUIRED</prop>
      <prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
    </props>
  </property>
</bean>
<bean id="persistenceManagerImplBean" class="com......persistence.PersistenceManager">
  <property name="sessionFactory" ref="sessionFactoryBean" />
  <property name="supportUserName" value="${supportUserName}"/>
</bean>

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

> Если name состоит из 31999 char, то в коде val nameHasUpperCase = name.exists(_.isUpperCase) ты пробегаешься по этим 31999 1 раз

Естественно, если строка будет очень длинной то toUpperCase не подойдет. Но так обосрать моьно любой алгоритм, добавив граничное условие, которое поломает алгоритм. Та же самая строка на Скале сломается если сделать строку 100МБ. Мой пример был рассчитан на короткие строки. А для обрабатки таких длинных строк всегда есть более эффективные алгоритмы.

>Естественно, если строка будет очень длинной то toUpperCase не подойдет. Но так обосрать моьно любой алгоритм, добавив граничное условие, которое поломает алгоритм. Та же самая строка на Скале сломается если сделать строку 100МБ. Мой пример был рассчитан на короткие строки. А для обрабатки таких длинных строк всегда есть более эффективные алгоритмы.

>dimag * (*) (19.05.2008 22:14:01)

Проблема то в общем подходе. PHP программиста и профессора из Берна. Есть разница. И она принципиальная. Профессор понимает чем он занимается, он программирует вычислитель. PHP программист не понимает чем он занимается. А потом появляются фееричные перлы разошедшиеся по всему рунету а-ля ЕГАИС и http://rizhikov.habrahabr.ru/blog/33728.html Взяли Тьюринг язык программирования и пишут "Как не стараются РАЗРАБОТЧИКИ, производительность XML/XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей структуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных, получая на выходе опять же текст, который занимает память" Ну и как это называть? А может лучше пока разработчикам поработать в гардеробе и попринимать пальто с соответствующей оплатой, а на досуге почитать книжек о программировании?

А откуда ты узнаешь, какой длины тебе в коде попадется строка, длинная или в 10 чар? А если у тебя в коде сотни таких участков, в которых код имеет оверхед в 2-4-8 раз, то не тормозит ли в целом твоя прога в 2...8 раз по сравнению с написанной изначально правильно? А если ты так пишешь либу, которую потом дергаешь из сотен методов своего кода? А потом говорят, что индусы живут в Бангалоре, а в Битриксах и Парусах работают только грамотных ученые архитекторы

> Та же самая строка на Скале сломается если сделать строку 100МБ.

Если сделать строку 100Мб, то сломается даже хвостовая рекурсия в любимом vsl .NET

> Да нет, в первом случае O(N), во втором O(2*N)

Ууу.. Вы, прежде чем умничать, прочитали бы что символ "О" обозначает.

>Ууу.. Вы, прежде чем умничать, прочитали бы что символ "О" обозначает.

Нууу, ладно, хорошо, уломал. Пусть их сложность линейная у обоих, а как тогда записать то, что один алгоритм требует РОВНО в 2 раза больше времени и памяти для обработки одного и того же объема данных, чем второй?

>Проблема то в общем подходе. PHP программиста и профессора из Берна. Есть разница. И она принципиальная. Профессор понимает чем он занимается, он программирует вычислитель. PHP программист не понимает чем он занимается. А потом появляются фееричные перлы разошедшиеся по всему рунету а-ля ЕГАИС и http://rizhikov.habrahabr.ru/blog/33728.html Взяли Тьюринг язык программирования и пишут "Как не стараются РАЗРАБОТЧИКИ

Вот представь себе, что в 99% случаев, я знаю, какого размера будут объекты в моих программах. И если системе не критично время выполнения задачи, то мне без разницы, как написан алгоритм. Другое дело, если участок кода критичен, то тогда можно и на ассемблере извратится. А огульно говорить, что ЯП говно, из за того, что в нем нет хвостовой рекурсии или нужно на несколько строк кода больше напечатать, это только говорит о полной проф. непригодности.

А с перлами ХСЛТ и ХМЛ я сейчас разгребаюсь. Убрав ХСЛТ из десятка мест в системе и заменив его на более подходящие технологии, я увеличил быстродействие системы в 36 раз.

>Нууу, ладно, хорошо, уломал. Пусть их сложность линейная у обоих, а как тогда записать то, что один алгоритм требует РОВНО в 2 раза больше времени и памяти для обработки одного и того же объема данных, чем второй?

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

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

Да блин достали, ну написал не очень эффективную строку, так напишите лучше. Нет, будут философствовать. Вот пример который делает то же что и Скала и так же эффективно

a.matches(".*?[A-Z].*")

starting with JDK 1.3

wrote javac 1.1-1.4

нестыковочка. :))

http://sensualjava.blogspot.com/2007/12/past-forward.html

Интересно, анонимус понимает, что речь идет о дженериках. (причем JSR-14 реализовывали минимум 4 (четыре) человека). Повторяю по слогам "ge-ne-rics" :)

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

> я увеличил быстродействие системы в 36 раз.
уверен, что оставив XML можно было достичь увеличения быстродействия :). Правда не в 36 раз.

> Да блин достали, ну написал не очень эффективную строку, так напишите лучше
Дык уже написана. Собственно на нее ты и писал свой код :)

> a.matches(".*?[A-Z].*")
С каких это пор регулярка быстрее посимвольного перебора? Особенно при таком условии.

>Да блин достали, ну написал не очень эффективную строку, так напишите лучше. Нет, будут философствовать. Вот пример который делает то же что и Скала и так же эффективно

Это не к тебе претензии. А к тому, кто O(2*N) пишет.

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

>А вообще, у твоего примера ещё и читабельность хуже.

Субъективная характеристика - "не катит".

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

Это характеризует только тебя, но ни как не код.

>a.matches(".*?[A-Z].*")

Ты серьезно считаешь что один цикл пробегания по строке равен по эффективности регекспу?

>Субъективная характеристика - "не катит".

Именно так. Пример на Scala четко выражает мысль, этот — нет.

>Это характеризует только тебя, но ни как не код.

Ну-ну.

>Ты серьезно считаешь что один цикл пробегания по строке равен по эффективности регекспу?

Не. Ну ведь буковок в коде меньше! Значит и работать будет быстрее!!!
А че, не так что-ли?

>Не. Ну ведь буковок в коде меньше! Значит и работать будет быстрее!!! А че, не так что-ли?

Пример был на тему КОМПАКТНОСТИ кода, а не быстродействия или других оптимизаций, что и было показано. Я абсолютно уверен, что можно найти кучу примеров, где Java код будет более компактен, чем код написанный на Scala.

>Пример был на тему КОМПАКТНОСТИ кода, а не быстродействия или других оптимизаций, что и было показано. Я абсолютно уверен, что можно найти кучу примеров, где Java код будет более компактен, чем код написанный на Scala.

Вряд ли. Подозреваю, что твой компактный код является валидным кодом на Scala :) Или около того.

>Пример был на тему КОМПАКТНОСТИ кода

Еще раз - там была демонстрация не реализации компактности поиска заглавных букв.