Ceylon 1.0.0

С другой стороны...цейлон подрастет, если они смогут взаимодействовать с спрингом и прочим окружением, можно просто переехать на него. Сейчас цейлон собирает запросы на фичи в версии 1.2 так что можно попробовать продвинуть туда модификаторы доступа (rw ro wo) и модификатор класса friend (из С++) что бы DI пахало без геттеров сеттеров.

Spring & Hibernate - два главных тормоза в Java enterprise apps. Деплой по минуте - это всё благодаря этим проектам. Когда-то они были актуальны, но зачем сейчас эта «радость»? Что касается DI: зачем только из-за DI создавать мутабельные объекты? Посмотри подходы к DI на скале хотя бы тут. В сабже заявлены Mixins, я не вдавался в детали, но думаю, cake pattern реализуем на нём в нормальном виде.

Вам пришла ссылка, класс не известен, только интерфейс, как вызвать переопределенный метод из класса? А ведь вы его «переопределили». У какого наследника будет вызван метод у А или у интерфейса и какого из переопределивших метод множества интерфейсов? Если реализовано пять переопределяющих дефолтные методы интерфейсов, какой выбрать имея ссылку на один из них, тот на который ссылка, а если надо вызвать метод наследника или другого из группы интерфейсов?

Конечно все это решается приведением типов...это и есть стандартное решение при множественном наследовании. Но. Если решить так, то нам надо каждый раз приводить ссылку к тому классу, метод которого надо вызвать. В С++ если я помню верно, происходил спуск по цепочке наследования и вызов последнего, если нет явного приведения. Потому, что если у вас ссылка на интерфейс, скорее всего вы хотите вызвать метод реализации интерфейса (в случае с С++ это просто метод наследника). Как это будет «показано» в ява 8, я не нашел пока. Но, это именно та проблема от которой «ушли» выкинув множественное наследование поведения. Что бы никаких неоднозначностей не преодолевать больше.

Посмотрю.

Кстати, если не спринг с гибернейтом, то что?

Вам пришла ссылка, класс не известен, только интерфейс, как вызвать переопределенный метод из класса?

ссылка пришла на объект? link.foo(); и все у вас вызовется как надо.

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

Есть лямбды -> ненужно и в топку.

Думаю что не очень корректно сравнивать, т.к. у него же библиотека стандартная своя вроде, а не явовская...

Я не понял, у кого стандартная библиотека своя и у кого явовская?

Как минимум, чисто функциональная вещь типа расчета расстояния описана в императивном стиле. Это сразу же пахнет гнило.

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

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

Что касается DI: зачем только из-за DI создавать мутабельные объекты?

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

Если бы не читал Экклезиаста, ломал бы голову, как такая вот кривая библиотека стала мейнстримом.

Автоматическая верификация? Оптимизация раскладки структур данных по паттернам использования? Нет? Уносите.

Ну типа Ceylon'цы считают, что SDK Java (библиотеки) - «такое же древнее говно мамонта, как сама Java, и их срочно надо все переписать».

А авторы Scala, насколько я понимаю, всё переписывать не собираются :-)

Хотя вроде у неё тоже развесистая своя библиотека......

Это означает, что код на скале можно интегрировать с кодом на яве, а код на цейлоне нельзя. Ну и кто тут ССЗБ?

А к чему тут ССЗБ? Я тут вообще мимо крокодил. :-)

Но код на цейлоне-то тоже можно интегрировать с кодом на яве, насколько я понимаю...

Но код на цейлоне-то тоже можно интегрировать с кодом на яве, насколько я понимаю...

Каким образом, если явовская rt.jar недоступна? Остаются всякие веб сервисы и прочий RPC.

Задам неожиданный вопрос - чем оно лучше Scala что на нём написали или собираются написать?

// А еще слово «Eclipse» вызывает неприятные воспоминания.

Я вроде бы не писал, что проблема будет неразрешимой :) Вы правы, указать откуда брать и всего его делов. Но. Именно от этой необходимости указывать когда то пошел отказ от множественного наследования. Теперь же они же говорят, что для того что бы поддерживать расширение старого кода и не писать кучу имплантаций везде, где ни попадя, мы решили ввести дефолт методы в интерфейсы. Как по мне, так они пошли в обратную сторону от собственных принципов. С таким же спехом они могли сказать «С++ спроектирован лучше, так как там множественное наследование есть и оно помогает...». После чего спокойно делать свое черное дело :)

Хотя я не в претензиях, просто этот конкретный пример самое показательное (если не тыкать пальцем в дженерики-обобщения на уровне компиляции), что выдает трудность поддержания явы из за уже доставшей обратной совместимости с ява 1.2 или даже 1.0 :) Вся мысль состояла в том, что надо бы уже где то остановится и сказать «1.7 мы будем поддерживать еще десять лет, а дальше...» и понеслась. А то что то они совсем уже застабилизировались...аж мхом поросли.

Я цейлон просматривал и так и не понял пока как же там с перегруженными конструкторами быть. Неужели обходиться?

interface Writer {
 
    shared formal Formatter formatter;
 
    shared formal void write(String string);
 
    shared void writeLine(String string) {
        write(string);
        write("\n");
    }
 
    shared void writeFormattedLine(String format, Object* args) {
        writeLine( formatter.format(format, args) );
    }
 
}

class ConsoleWriter() satisfies Writer {
    formatter = StringFormatter();
    write(String string) => print(string);
}

Почти те же самые дефолтные методы в интерфейсах но в целоне :)

Зачем втискивать в конструкции языка то, что можно сделать при помощи библиотек?

PL/I (олдфаги меня поймут, а школоло - учить матчасть) в свое время на этом слил C.

Яйцеголовых это, правда, ничему не научило.

Автоматическая верификация?

Что ты здесь имеешь в виду?

Интересно, что Шапка делает такого на джаве, что им пришлось лепить свой язык?

JBoss

Согласен .Развелось их тут.

Однообразных.

opennet вещает, что это развивается компанией redhat. так что не удивительно, поттеринг там давно всех перекусал

Хм.
Думаете новый JBoss будет заязан на цейлон?

Зачем втискивать в конструкции языка то, что можно сделать при помощи библиотек?
PL/I (олдфаги меня поймут, а школоло - учить матчасть) в свое время на этом слил C.

Так языки высокого уровня уж лет 20 все расширяемые, с разморозкой.

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

А вот это тогда просто так написано что ли?

http://ceylon-lang.org/documentation/1.0/reference/interoperability/java-from...

поэтому умные люди множественное наследование щитают моветоном

PL/I (олдфаги меня поймут, а школоло - учить матчасть) в свое время на этом слил C.

Если ты такой олдфаг, то в курсе про CLOS. И про то, какая это радость, врубаться в сообщения об ошибках в системе, где то, что нормальные люди делают частью языков, было реализовано библиотекой. :-)

Честно говоря, при таком зоопарке языков возникает подсознательное желание привязаться к старому проверенному временем говну.

COBOLу?

Автоматическая верификация?

Ну кое-какая думаю есть. Не божественная, но по крайней мере не хуже чем в Java.

Оптимизация раскладки структур данных по паттернам использования?

Примеры в альтернативных языках можете предложить для оценки? Надеюсь, речь не идёт о чудовищах вроде GHC rewrite rules?

поэтому умные люди множественное наследование щитают моветоном

Я думал, они просто тихо и без напряга пользуются traits... Как бы тот же самый эффект, но только без кишек на гусеницах.

поэтому умные люди множественное наследование щитают моветоном

почему поэтому?

прямо из примера на глагне:

Html html = Html {

Facepalm facepalm = Facepalm :{

И чем оно лучше scala/groovy/kotlin?
scala/groovy/kotlin?
kotlin
kotlin
kotlin

Ты так говоришь, как будто Kotlin - состоятельный язык одного ранга с Scala и Groovy, а не наколенная поделка питерского кучерявого хипстера-жидка из JetBrains.

Что это?

Да видать Maven впилили в рантайм, чо.

Приличное решение вместо OSGi.

Что не так с OSGi?

а чего, с Хиндли — Милнером поссорились?

А вот это тогда просто так написано что ли?

Из того, что там написано следует, что ты изначально был неправ. Явовская стандартная библиотека там вполне доступна.

Осги велик и обширен...не то чтобы это плохо, но хочется проще...и видать не только мне :)

Скажите, а этот цейлон лучше скалы? И если да, то чем?

Про Kotlin этот вопрос регулярно задают на всех JavaOne'ах. Питерский кучерявый хипстер-жидок на это долго распинается, но суть в трёх словах - «мы её (скалку) ниасилили», когда выбирали новый модный язык для своих поделок вместо немодной мейнстримной Java. Вот и решили накостылить свой велосипед.

Полагаю, что с Цейлоном примерно та же история.

Spring & Hibernate - два главных тормоза в Java enterprise apps. Деплой по минуте - это всё благодаря этим проектам.

Spring - тормоз, говно и нинужен, при имеющихся JSF и CDI. А вот Hibernate не замай. Если JPA+Hibernate у тебя деплоятся по минуте, то это значит, что ты просто не умеешь их готовить.

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

Засуетился гугл, красношапка, мелкософт. Все выкатили свои решения с возможностями клиент-сервера на одном языке, так как зоопарк перестал влазить в головы одного программиста и один мелкий проект пишут по трое не считая «дезигнеров».

Да еще и ява обросла обратной совместимостью настолько, что оракл дал повод засуетится конкурентам...ведь все выкатываемые проекты говорят «мы похожи на яву и с ней совместимы»...по русски говоря «айда к нам, нафиг оракл».

В общем рынок делят перед смертью явы как языка и рождением новой платформы.

Есть лямбды -> ненужно и в топку.

Плюсую люто, бешено, яростно. Если кто зашкварился об функциональщину - то это с концами. Рак тот ещё. Как болезнь будет прогрессировать дальше - совершенно очевидно: попрут монадки, катаморфизмы, параморфизмы, зигоморфизмы, хистоморфизмы, препроморфизмы, анаморфизмы, апоморфизмы, футуморфизмы, постпроморфизмы, хиломорфизмы, крономорфизмы, синкрономорфизмы, экзоморфизмы, метаморфизмы, динаморфизмы, алгебра и коалгебра Калвина Элгота наконец.

Ну CDI ясно, а JSF то вам ем так нравится по сравнению...даже не знаю чем в спринге :)

Вообще, следующим стандартом станет то, что будет работать на стороне браузера и сервера.

Я знаю ответ. Это LISP. Он заменит все имеющиеся сейчас языки и технологии.

HTML -> S-выражения.
CSS -> S-выражения.
JavaScript -> LISP.
серверные языки -> LISP.
SQL -> LISP.

Разве не очевидно?

Ну CDI ясно, а JSF то вам ем так нравится по сравнению...даже не знаю чем в спринге :)

То есть как это «с чем»? Со Spring MVC же, юноша!

О, да...погоди, надо еще обмазаться :)

Странный вы человек, как можно сравнивать реализацию MVC для веба с внешними, прикручиваемыми шаблонами, причем с прикручиваемым jsf в том числе :) И генератор-шаблонизатор представлений. У меня своя классификация в которой jsf и gwt генераторы (за свой язык тегов и вообще способ описания генерируемого), а FreeMaker и прочая толпа, «шаблонизаторы» (за внедрение в html и прочее). Вероятно я действительно что то не понимаю в ваших рассуждениях.