Ceylon M6 «Virtual Boy»

Это уже что-то. Либ столько же как у python?

Все равно энтерпрайзные неосиляторы будут еще лет двадцать орать, что никуда не хотят переходить с java 1.4, потому что после нее все ломалют и ломают :(

когда один и тот же код можно написать семнадцатью способами, и это только на уровне синтаксиса

Это не недостаток, а преимущество.

Как минимум не меньше.

Я сам не мерял, но обычно у того что популярное либ таки больше. Python в 2013 популярен, Pascal - нет, хорошо это или плохо

4.2, Ceylon M6 ещё не вышел. Это всего лишь отчёт о прогрессе, к тому же датированный июлем.

slowpoke.jpg

Все эти Ceylon, Kotlin, Groovy - посредине между простотой Java и мощью Scala.

Из рассказов нашего скалиста я помню, что в Скале есть нормальные проперти класса. Тоесть нет необходимости писать кучу гетеров/сетеров к private полям, поскольку генерируются стандартные. А если понадобиться написать нестандартные, не нужно будет менять код, который к этим пропертям обращается, поскольку вызов метода без параметров синтаксически не отличается от обращения к поля (нет круглых скобок). Интересно есть ли такое в Цейлоне.

В downloads зайди.

В скале это называется unified access. Другими словами по дефолту поле - это не поле, а проперти уже с геттером и сеттером. Потому на уровне бинарной совместимости другой код использующий поле по настоящему вызывает методы. Потом их можно переопределить не ломая совместимости.

var x = 5

в классе уже property. Java поле пишется

private[this] var x = 5

и как мы раньше без лямбд то жили?

раньше и без компьютеров жили. Намёк понятен?

Так официальных release notes ещё не было.

Это не недостаток, а преимущество.

Нет. Смерть перла это доказала.

А их, скорее всего, и не будет.

В скале это называется unified access. Другими словами по дефолту поле - это не поле, а проперти уже с геттером и сеттером.

Да, именно это я и имел в виду. Вот интересно, есть ли такое в Цейлоне?

Из рассказов нашего скалиста я помню, что в Скале есть нормальные проперти класса. <...> Интересно есть ли такое в Цейлоне.

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

Молодцы, посоны. Зачем нам какой-то Цейлон, когда можно развести скаласрач?

Молодцы, посоны. Зачем нам какой-то Цейлон, когда можно развести скаласрач?

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

ещё чуть чуть и все перерейдут с Java

Для этого сначала всем нужно перейти на Java…

True operator overloading is not supported. Sorry, you can't define the pope operator <+|:-) in Ceylon.

ААААААААААА!!! Порвало на куски. Молодцы.

Это я к тому, что ЛОР по-прежнему торт )

Такіе когда появятся?

public void setMonitor(final Object monitor)
{
    if (monitor == null) {
        throw new NullPointerException("monitor");
    }
    this.monitor = monitor;
}

и как мы раньше без лямбд то жили?

Судя по java-сорцам различных опенсорсных проектов, во многих классах содержится пачка inner-классов и встречаются анонимные классы. И всё это выглядит очень плохочитаемо. С другой стороны, лямбды в жабе эмулируются через вложенные классы. С третьей стороны, писать асинхронный код без лямбд — это содомия.
Так что ответ простой: без лямбд почти не жили, а просто писали синхронный код, чтобы меньше писать. А когда было сильно надо, то имитировали лямбды через внутренние классы, и асинхронность через размашистые new Runnable/FutureTask {...}.

которые любят checked exception

чем тебе не нравятся они?

Следующий релиз наверное будет называться 32X или Jaguar.

думать надо что с німі делать.

а так есть такой тезис что они могут ломать абстракцию.

мое мнение:

1. Плохо совместимы с ситуацией когда исключения выбрасываются пользовательским кодом который вызывается из библиотеки — например всякие callback'и, custom реализации какого-нибудь внутреннего API и т.п. В итоге это заканчивается многократным оборачиванием исходной причины в исключения-обертки. Особенно забавно потом видеть код обратного разматывания этих исключений с if (ex.getCause() instanceof XXXException) { ... } else { ... }
2. Классификация checked/unchecked отдана автору API, а не пользователю. Хотя на практике критичность и возможность восстановления определяется пользователем, а не API. В качестве примера можно вспомнить unchecked NumberFormatException, который в 99.9% случаев перехватывается рядом с вызовом Integer.parseInt и, например, checked SQLException который чаще всего приводит завершению довольно большой секции кода (особенно с учетом отсутствия классификации этих самых SQLException'ов, но это уже другой разговор)

Сегодня нашёл в apache http resource leak: http://alvinalexander.com/java/jwarehouse/commons-httpclient-4.0.3/httpclient...

   56         public InputStream getContent()
   57             throws IOException, IllegalStateException {
   58   
   59             // the wrapped entity's getContent() decides about repeatability
   60             InputStream wrappedin = wrappedEntity.getContent();
   61   
   62             return new GZIPInputStream(wrappedin);
   63         }

new GZIPInputStream(wrappedin) нужно обернуть try/catch, чтобы закрывать wrappedin в случае exception.

С unchecked exceptions такого рода проблемы вознікалі б в каждом классе.

С unchecked exceptions такого рода проблемы вознікалі б в каждом классе.

Во-первых как видешь тут тебе checked exception и не помогли. Во вторых надо еще смотреть есть ли там leak или нет, возможно stream закрывается через wrappedEntity. И ссылку ты куда-то не туда дал.

Пардон, вот сcылка: http://www.docjar.com/html/api/org/apache/http/contrib/compress/GzipDecompres...

wrapped.getContent() создаёт ресурс, которому нужно сделать #close() (это не проісходіт). А потом это исключение ведёт к тому, что pooled connection через который прогоняется контент просто не релизится. :)

Тут IOException в throws - так что не помогло. Во многих других случаях ошибка компиляции подсказывает, что что-то не так.

Checked exceptions - создавались для ошибок, которые случаются в коде без багов. В принципе они помогают, хотя і навязчивые порой.

http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/httpclient/src/m...

в trunk эту часть проблемы ісправілі. (Что с BasicManagedEntity которая протекает в 4.2 - надо смотреть)

https://issues.apache.org/jira/browse/HTTPCLIENT-1281

Такіе когда появятся?

Когда понадобятся. А по умолчанию генерируются стандартные, без проверки на null.

Интересно есть ли такое в Цейлоне.

Есть.

Perl жив.

Ага, как Ленин.

Реквестирую пруф смерти Perl'а.

В этом смысле ей ещё далеко до Python. Core Python прекрасен и лаконичен. Но почему-то сейчас все увлеклись метапрограммированием. Типа стало модно. Хеллов ад.

+100500

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

Судя по java-сорцам различных опенсорсных проектов, во многих классах содержится пачка inner-классов и встречаются анонимные классы.

В опенсорсе много говнокода. Это нормально. Опенсорс голодная студентота пишет.

В приличном коде лямбдам не место.

ну дык як такіе уже пользую.

Принципиально новая джава написанная на джава которая тормозит в квадрате.

когда будешь писать софт сложнее laba2 и тебе код придётся показывать не только преподу, но ещё и команде своей, поймёшь, что

один и тот же код можно написать семнадцатью способами

это очень не удобно

Если я буду писать в команде «софт сложнее laba2», то я буду соблюдать стиль, заданный руководством/совместно выработанный командой.

В своих же проектах я буду писать так, как мне удобно.

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

соблюдать стиль, заданный руководством/совместно выработанный командой.

воот, отсюдова и следует, что стопицот возможностей написать факториал не нужно на самом деле

Ну, Python IMHO лучше во всех отношениях, чем PHP. А вот, например, Facebook - большой проект? а ведь PHP. Выбор языка для проекта - это сложнейшая задача, и, как правило, на стартапе она решается суммой скиллзов программистов, а вот когда проект начинает расти... Начинается ужас, как у твиттера. Лично я считаю оптимальной связкой groovy (прототипирование и тестирование компонента) с переходом на java в быстродействующих кусках. IMHO, это стало проще с появлением java8 и статической компиляции/типизации в groovy. Другое дело, когда Вы уже пришли в монстровый проект, и там всё давно спрототипировано и налажено. Вам остаётся кодировать на чистой Java, да иногда и на JDK меньше 1.5. но ведь надо отдавать себе отчёт, что Вы в этом случае не программист, а кодер. Потому что все суровые вещи в большом корп проекте (статика, тестирование фунциональное, компонентное, модульное етц) уводят вас от собственно программирования. Это другая профессия. Типа токаря.

а ведь PHP

ихний php компилируется ихним хипхопом, так что это не совсем php

Я уже поприходил в суровые тырпрайзные говно-монстро-проекты. Пожалуй хватит с меня ;) Слава богу у меня вполне есть возможность слать такие предложения лесом и достаточно опыта, чтобы заранее их распознавать и даже не соваться туда.

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

Это не недостаток, а преимущество.

Для опытных программистов, да.

А теперь берем новичка. Тут он одним способом написал, там - другим, тут скопипастил кусок и получается нестройная куча малочитабельного гуано.