Ceylon 1.0.0

Неужели теперь расставлять кнопочки на Java будет легче?

а что там с совместимостью с жабой на уровне исходников ?

Необычные решения там встречаются:

the return type of a void function is considered to be Anything.

Разработчика ceylon зовут Dalvik Clang.

Фокус на читаемости кода и отказ от «вредных» конструкций, затрудняющих понимание логики

Ещё один язык со встроенным фашизмом.

Горшочек, не вари!

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

Ceylon — это новый язык со статической типизацией для платформы Java Virtual Machine

опять?!

также поддерживающий компиляцию в JavaScript

оно чем-то лучше GWT или так же закопают со временем?

Имя им Легион.

Эталонное bloatware

рукалицо! Gavik Kang! может Gavin King все-таки? а то вон правда сверху хороший вариант предложили уже

Тем, что это все недалеко от явы отошло. Лидер проекта вырос из JCP и начал свое потому, что обратная совместимость не давала сделать многого. Те же обобщения в яве, просто дикий костыль в угоду обратной совместимости. Так же java 8 тащит «изящные решения» типа функциональных интерфейсов вместо нормальных решений только потому, что обратная совместимость...и еще куча примеров.

Потому, лично я давно хочу яву без обратной совместимости с говоном мамонта.

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

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

function distance(Point from, Point to) {
    return ((from.x-to.x)^2 + (from.y-to.y)^2)^0.5;
}

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

Что это?

Ваш сарказм напоролся на вполне себе читаемость

можно узнать какой язык/языки программрования вы используете? пример вполне читаемый

функциональных интерфейсов вместо нормальных решений

Хе-хе, о небо, что же мы все будем делать с этими ужасными функциональными интерфейсами

Интересно, что Шапка делает такого на джаве

Тонны либ из JBoss Community

что им пришлось лепить свой язык?

А вот это загадка

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

Выглядит вкусно, я б поюзал (мечты).

Ха. Когда в язык добавляют фичу только для того что бы один новый класс (Stream) пахал удобно и везде без модификации кучи обратно совместимого старья...это наводит на размышления о том откуда растут ноги у функциональных интерфейсов. Какая там разница, что лично вы будете с ними делать, не для вас добавлялось.

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

Потому, цейлон я посмотрел...не понравилось. Не люблю java.next типа скалы, далеко отходят от ява архитектуры, а тут, вроде бы все разумно. Ява с человеческим лицом и никаких мамонтов.

Пардон, цейлон мне понравился. «мне понравилось». Опечатка.

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

Ceylon

Фокус

логики

/

Фактически, внедрением функциональных интерфейсов ява авторы нарушают свое же нежелание реализовать множественное наследование.

А ты не перепутал случаем с default методами?

• Прочитать то можно, сказать, что в этом примере сделан фокус на читаемость будет преувеличением.
• Функция, работающая только с данными класса и не инкапсулированя в него, явно не облегчает понимание логики.

Так можно на любом написать, но зачем?

цейлон я посмотрел...не понравилось

тут, вроде бы все разумно. Ява с человеческим лицом и никаких мамонтов.

Где «тут»?

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

Привыкли все такое читать, у этих без public static double, так что полегче стало

Да, перепутал. Бывает.

там нет никакого множественного наследования. Компилятор ругается страшными словами и не дает ничего отнаследовать.

Это как? Теперь нельзя реализовывать множество интерфейсов с дефолт методом?

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

Ну так речь ведь не о перегрузке или переопределении. Речь о самом факте возможности сделать множественное наследование поведения. В одном интерфейса берем метода А, во втором метод Б. Множественное наследование поведения на лицо. Что бы не совсем уж отойти от собственных принципов они конечно запретили наследовать состояние, но суть вопроса в том, что они уже ради обратной совместимости вынуждены вот такие танцы вводить потому, что поддерживать надо много всего.

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

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

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

В одном интерфейса берем метода А, во втором метод Б.

Приехали, а раньше значит такого не было?

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

Было, но реализаций методов не было...теперь есть. Отсюда возникла эта «возможность» указывать откуда брать реализацию метода...стандартная проблема множественного наследования.

Ладно, от моих воплей караван не остановится :) Будем посмотреть на новые фичи ява 8 подробнее. один черт с ней работать скорее всего :)

Функция, работающая только с данными класса и не инкапсулированя в него, явно не облегчает понимание логики.

И в какой класс ты предлагаешь определить функцию вычисления расстояния между точкой и прямой например?

Отсюда возникла эта «возможность» указывать откуда брать реализацию метода...стандартная проблема множественного наследования.

Где там такая проблема то?

Например. Есть дефолт метод в интерфейсе и метод в классе реализующем интерфейс. Какой выбрать?

Это не проблема, ты его переопределил.

Что только не делают люди, лишь бы не признавать очевидное: Python3 - лучший!

Давай еще раз, есть проблема ромба

class A {foo(){..}}
class B extends A {foo(){..}}
class C extends A {}
class D extends C,D {}

Вот тут есть проблема, тому що метод foo, зараза, один и тот же. А в яве8:

interface A {foo(){..}}
interface B {foo(){..}}
class C implements A,B {foo() default A.foo()} 

такой проблемы нет, потому что foo у тебя суть абсолютно разные. И ты просто решаешь чем это переопределить, своим, или имеющимся.

default методы сделаны для реализации типовых _простых_ методов. Это избавление от copy&paste при множественной имлементации базовых интерфейсов и порождения кучи примитивных AbstractXXX. Это не множественное наследование поведения и слава богу. Хотите геморроя? для вас уже сделали инструмент для отстрела ног, рук и яиц - плюсы.

по сабж
без возможности запуска java как есть, оно будет никому ненужный инструмент на поиграться. груви наше всё :)