Увидел свет (http://ceylon-lang.org/blog/2013/11/12/ceylon-1/) язык программирования Ceylon 1.0.0 (http://ceylon-lang.org/), первый стабильный релиз, пригодный для промышленного применения. Ceylon развивается компанией Red Hat как язык общего назначения, претендующий на роль замены Java. Лидером разработки является Гэвин Кинг (Gavin King), основатель проектов Hibernate (http://www.hibernate.org/) и Seam (http://seamframework.org/). Код связанных с языком компонентов распространяется (https://github.com/ceylon) под лицензией GPLv2, а код среды разработки под лицензией EPL. Бинарные пакеты можно загрузить (http://ceylon-lang.org/download/) в форматах deb и rpm.
В состав выпуска входят:
- Спецификации (http://ceylon-lang.org/documentation/1.0/spec), определяющие синтаксис и семантику языка;
- Инструментарий (http://ceylon-lang.org/documentation/1.0/reference/tool/ceyl... работающий в режиме командной строки. В том числе, компилятор в Java и JavaScript, а также компоненты для запуска приложений под управлением JVM и Node.js;
- Компоненты модульной архитектуры с поддержкой управления зависимостями, изоляции модулей и логического разбиения кода;
- Базовый модуль (http://modules.ceylon-lang.org/modules/ceylon.language) языка и набор вспомогательных модулей, формирующих Ceylon SDK (https://modules.ceylon-lang.org/categories/SDK);
- Интегрированная среда разработки Ceylon IDE (http://ceylon-lang.org/documentation/1.0/ide/features/), построенная на основе платформы Eclipse.<center><a href="http://ceylon-lang.org/images/screenshots/1.0.0/ide.png"... src="http://www.opennet.me/opennews/pics_base/0_1384369567.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Целью создания Ceylon было избавление от устаревших концепций и подходов, которые мешают дальнейшей эволюции языка Java и достижению более высокого уровня эффективности. Кроме реализации лучших возможностей Java, в Ceylon заимствованы некоторые дополнительные конструкции из языков Smalltalk, Python и ML. Написанные на языке Ceylon программы и модули могут выполняться в стандартной виртуальной машине Java (JVM) или компилироваться в JavaScript (поддерживается выполнение в браузере или под управлением Node.js).
Поддерживается бесшовная интеграция с другими языками, базирующимися на JVM, например, модули на языке Ceylon можно использовать в программах на Java и наоборот. Подобная возможность доступна и для JavaScript, но число реализованных для JavaScript модулей ограничено. Язык использует статическую типизацию и спроектирован с оглядкой на простоту изучения, лёгкость восприятия кода и разработку больших проектов, в которых участвует большое число программистов. Синтаксис Ceylon во многом напоминает Си, Java и C#.Отмечается, что при помощи Ceylon значительно проще создавать фреймворки и библиотеки классов, а также естественно описывать древовидные структуры (в частности, формировать пользовательский интерфейс). В язык добавлены элементы, упрощающие написание кода, который можно использовать повторно в других проектах. Модули на языке Ceylon упаковываются в архивы .car и помещаются в специальные репозитории. В процессе выполнения приложения нужные модули загружаются сразу из внешнего или локального репозитория, не требуя предварительной установки. Язык поддерживает архитектуру модульной "peer-to-peer" загрузки классов, обладающую такими возможностями как учет требований приложения к версиям модулей и поддержку работы сразу с несколькими репозиториями модулей, как локальными, так и внешними (http://modules.ceylon-lang.org/).
Некоторые (http://ceylon-lang.org/features/) особенности (http://ceylon-lang.org/documentation/1.0/introduction/) Ceylon:
- Статическая типизация (тип любого значения любого выражения может быть определён без исполнения программы), позволяющая выявлять ошибки на этапе компиляции, а не в процессе исполнения;- Отсутствие специальных типов, всё реализовано в виде объектов;
- Именованные и опциональные параметры;
- Nullable-типы (http://en.wikipedia.org/wiki/Nullable_type) (кроме значений базового типа, допускается использование состояний NULL);
- Отсутствие необходимости явного указания геттеров/сеттеров (getter/setters);
- Определение типов для локальных блоков (через ключевое слово "local");
- Удобная организация работы с последовательностями (массивами);
- Реализация функций высшего порядка, аргументом или возвращаемым результатом в которых выступают другие функции;
- Использование для присвоения первоначальных значений (инициализации переменных) оператора ":=";
- Новый синтаксис интерполяции строк;
- Новые типы: Natural, Numeric и т.п.
- Классы, методы и атрибуты выглядят одинаково;
- Использование для определения существующих языковых концепций новых ключевых слов: shared, satisfies, assign, variable, local;
- Упрощение уровней public, protected, private access, visibility;
- Определение inline-функций в стиле Smalltalk.
URL: http://ceylon-lang.org/blog/2013/11/12/ceylon-1/
Новость: http://www.opennet.me/opennews/art.shtml?num=38422
они свою 7-ку на Ceylon собрались переписать, поэтому и не релизят ??
Потом будет аналогом Firefox OS
Не имею ничего против этого языка и даже рад что его создали. Приятно осознавать что такие замечательные платформы доступны в исходных кодах, это в любом случае хорошо.Сравните с недо-dot-net - бинарный блоб под 1.5 ОС - просто смешно считать это серьезной платформой.
> Написанные на языке Ceylon программы и модули могут выполняться в стандартной виртуальной машине Java (JVM) или компилироваться в JavaScript (поддерживается выполнение в браузере или под управлением Node.js).
Айс ^_^
Сразу чувствуется мнение специалиста...
Господин хороший, растолкуй Христа ради чего тут написано:> Классы, методы и атрибуты выглядят одинаково;
>> Классы, методы и атрибуты выглядят одинаково;Шта? О_о
Опоздали. Есть Kotlin.
А Тасмании нет? Или Мадагаскара?
Нету Kotlin, нету. Есть только попытка его создать.
В каком смысле?
> В каком смысле?В прямом, ёбта. Что тебе непонятно?
Есть scala и groovy
В java действительно есть проблема унаследованного и обратно совместимого мусора. Я давно хотел чего то, что было бы явой, без обратной совместимости с технологиями десятилетней давности. Те же обобщения в яве просто набор обратно совместимых костылей (сделать их элементом компиляции...и только что бы в jvm не вносить новых команд), не говоря уже о спецификациях фреймворков в инфраструктуре вокруг явы. Развитие язков вроде груви,скала и цейлона всего лишь ответ на действительно существующую проблему. Ораклу стоит подумать о том что бы очистить яву от старого хлама, сделав новую ветку или что то подобное...лично я уже поглядываю в сторону новых решений...но пока рановато.
Кстати, при беглом осмотре целон показался более приятным чем скала и груви. Не стали огород городить, а взяли яву и доделали как хотели....и мне нравится как именно. Но, то первый взгляд.
Немного пробежав по цейлону я понял, что надо пробежать побольше...нравится, блин :) Если он сумеет со спрингом работать, то наверное присмотрюся :) Как то давно забил на java.next со свистоперделками...а тут, вполне чебе ничего. Лидер проекта вырос из JCP и начал свое делать именно из за сложностей в дальнейшем развитии java. В общем гляну поподробнее :)
Хотя java 8 во многом перекроет самые вкусные возможности цейлона. В нее бы еще get set поля добавили что бы не генерить бесконечные методы доступа...и пока ничего и не надо :)
Не холивара ради, что мешает вместо get/set сделать полям public visibility?
> Не холивара ради, что мешает вместо get/set сделать полям public visibility?get/set могут делать дополнительные проверки и кидать исключения, например.
Но вообще, get/set - очень порочная практика, по-моему, она идет наперекор идее инкапсуляции. В идеале программист, использующий класс, не должен знать о полях внутри вообще ничего.
Хмм, мне кажется наоборот, get/set является как раз инструментом инкапсуляции. Если у тебя есть private поле, то ты скрываешь его от посторонних глаз и не обязан делать методы доступа к нему (или например сделать только get). Если есть и get и set, которые не выполняют никаких проверок, делай поле публичным. Если есть проверки, то их в любом случае писать ручками, по этому в любом случае писанина будет.
>Хмм, мне кажется наоборот, get/set является как раз инструментом инкапсуляции.Нет. Это просто надстройки над полем. Никакого сокрытия по сути не происходит, программист продолжает работать с внутренностями реализации класса.
>Если есть проверки, то их в любом случае писать ручками, по этому в любом случае писанина будет.
Одно дело написать их один раз в get/set и совсем другое - каждый раз в коде.
С инкапсуляцией я то же когда то размышлял. Доразмышлялся до того, что пришел к выводу, что в рамки языка надо внести некоторый новый элемент для DI спецом...то есть friend (что то похожее на С++ друзей). Что бы можно было разрешить контейнеру иметь доступ к полю, а остальным что бы поле было по прежнему private. Это не нарушает инкапсуляции и при этом дает возможность быть DI и AOP...что вообще то чистейшее ООП если подумать получше...так как выгребает из объекта все, кроме его непосредственной задачи.
Кстати. В цейлоне я так понял защищенных и дефолт полей нету, они все видны внутри области видимости класса (пакет, модуль), если их открыть, либо внутри класса. Вот такие пироги.
Методы наследуются, поля - нет.
> Методы наследуются, private поля - нет.obvious fix
Прошу продемонстрировать наследование public полей
public class PublicPropertyInheritance {
static class A {
public String anyoneCanInheritMe = "i'm willing to share this :)";
private String noOneCanInheritMe = "make your own property, sucker!";
}static class B extends A {
}public static void main(String args) {
A a = new A();
System.out.println(a.anyoneCanInheritMe);
System.out.println(a.noOneCanInheritMe);B b = new B();
System.out.println(b.anyoneCanInheritMe);
// System.out.println(b.noOneCanInhertMe); // compilation error!
}
}
А где пример с наследованием полей? Этот был про области видимости.
> А где пример с наследованием полей? Этот был про области видимости.http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.h...
> Методы наследуются, поля - нет.А нужно ли наследование? Многие высказывают мысли по поводу того, что наследование и есть основной враг инкапсуляции, что, мол, лучше использовать композицию вместо наследования там, где это действительно нужно. ;)
Ну я и не давал качественной оценки. Только бить тех, кто наследуется от твоих классов и норовит скрыть поля тоже не выход.
Ну что за мода все усложнять? Написано же - private, а не uninherited - зачем же домысливать?Они точно так же наследуются, но к ним нету доступа. Если бы они не наследовались, то вызов родительского метода (который обращается к такому полю) на объекте потомке приводил бы к мусору.
Так не я же усложняю. private - к наследованию перпендикулярен. Ладно, вот простой пример.
class A {
public final String foo = "foo";
}
class B extends A {
public String foo = "bar";
}
class A1 {
public final String foo(){
return "foo";
}
}
class B1 extends A1 {
public String foo(){//тут кстати будет ошибка
return "bar";
}
}
Ну и наконец
((A)new A()).foo == ((A)new B()).foo
((A)new A()).foo() != ((A)new B()).foo()Короче если поля ведут себя так, как будто они не наследуются не вижу причин считать иначе
Этот код не должен компилироваться и не компилируется. Ибо "overridden method is final".
Короче, нельзя перегружать финализированные методы/функции.
Спасибо, Кэп. Но к final полю претензий таки нет.
А к чему тогда вообще претензии? Если они относятся не к языку, а к неким своим собственным интерпретациям языка?Либо давай корректный пример, подтверждающий свои слова, либо иди учить язык.
>[оверквотинг удален]
> class B1 extends A1 {
> public String foo(){//тут кстати будет ошибка
> return "bar";
> }
> }
> Ну и наконец
> ((A)new A()).foo == ((A)new B()).foo
> ((A)new A()).foo() != ((A)new B()).foo()
> Короче если поля ведут себя так, как будто они не наследуются не
> вижу причин считать иначеТы либо глуп, либо упорот, либо жирнющий тролль.
Читай до просветления
http://docs.oracle.com/javase/specs/jls/se5.0/html/classes.h...
> Не холивара ради, что мешает вместо get/set сделать полям public visibility?Искренняя и несовратимая убеждённость в том, что это плохо.
интересно, если оно действительно будет быстрей, то мб гугл заберёт это на ведроид, тем более, что по обещаниям работает на той-же JVM...
у гугла не жвм, а дальвик
> у гугла не жвм, а дальвикНе далеко ушел )
>> у гугла не жвм, а дальвик
> Не далеко ушел )Далеко.
>>> у гугла не жвм, а дальвик
>> Не далеко ушел )
> Далеко.Не. Те же яйца, вид сбоку.
Ололо. JVM - стековая, в то время как Dalvik - регистровая. (рукалицо)
> Ололо. JVM - стековая, в то время как Dalvik - регистровая. (рукалицо)Ой, дети.. (рукалицо), C++ компилятор тоже может создавать бинарный код как для RISC так и для CISC платформ.
В KitKat альтернатива появилась. Пока экспериментальная
IDE на скриншоте одна из самых отвратительных, что я видел. Такое чувство, что у них в качестве шрифтов Comic Sans, ну или что-то подобное.
> DE на скриншоте одна из самых отвратительных, что я видел.Ты еще IDE Visual C++ не видел...
Опачки! уже и на Эклипс гонят =о
После php-блокнотика всё кажется конфеткой?
Да, на мак её собирают левой задней пяткой, но кто в здравом уме кодит на мак?
> Да, на мак её собирают левой задней пяткой, но кто в здравом
> уме кодит на мак?да вот как раз всякие грувисты, скакальщики и прочая…
> Да, на мак её собирают левой задней пяткой, но кто в здравом
> уме кодит на винде?Пофиксил, не благодари
>> Да, на мак её собирают левой задней пяткой, но кто в здравом
>> уме кодит на винде?
> Пофиксил, не благодариНа скриншоте мак.
И.О.К.О.
>Да, на мак её собирают левой задней пяткой, но кто в здравом уме кодит на мак?А есть какие-то ограничения? Или может программы под МасОS X нужно писать не под MacOS X ?
программы под макость просто не нужно писать.
> IDE на скриншоте одна из самых отвратительных, что я видел. Такое чувство,
> что у них в качестве шрифтов Comic Sans, ну или что-то подобное.На скриншоте типичная Eclipse. В ней, кстати, и шрифт хорошо настраивается (в одном месте задаётся базовый шрифт, от которого все остальные шрифтовые оформления наследуются с теми или иными аберрациями). Да и вкладки вместо конфетно-карамельных можно задать плоско-стандартные легко.
Минус Eclipse в том, что интерфейс на базе тулкита SWT, который использует нативные виджеты, не всегда совпадающие с пользовательскими (у кого KDE, те поймут). Ограниченная переносимость среды (для каждой операционки нужна своя сборка) тоже не делает её успешной.
> Ну какой админ, такой и результат. Я о твоих высказываниях много читал.
> Я вообще удивляюсь, как у тебя чтото работает? :) Или человечеству
> повезло и ты не админ?Какой он админ? Ему бы школу закончить.
о, ещё один считает, что Чёрная Админская Магия ВНИЗАПНА! отучит эклипс тормозить и жрать память. жабисты такие жабисты: «чо? наша софтина тормозит? память жрёт? йо, чуваки, вы же не нищеброды, купите компьютер помощней и докиньте туда ещё восемь гигов памяти! что? оптимизации? слышали один раз: фигня какая-то бесполезная. и вообще: вы что, хотите параллельно с нашей Великолепной Программой что-то ещё запустить? не, так не пойдёт, на это никто не рассчитывал.»
> Это ты IDEA не видел.видел, но весьма давно. был в молодости грешок с java me.
> у кого KDE, те поймутЧего поймут то? У меня Эклипс почти как остальные KDE-шные программы выглядит
У каждого производителя свой велосипед.
Java штопают-штопают, еще это будут штопать. библиотек наверно кот наплакал.
Библиотеки годятся от Java. Зачем переписывать то, что работает?
Хм, а сахар то на порядок лучше и грамотнее чем в шарпе.
> Использование для присвоения первоначальных значений (инициализации переменных) оператора ":=";а смысл?
В Scala декларация переменной как в паскале через двоеточие и типом справа, а тут будет присвоение в стиле паскаля :-)))
> html html = html {Отличная читаемость!
а так:
html page_1=html{?
Накуа все это? О_о В Java фатальный недостаток?
потому что Java контролирует не redhat :-)
> потому что Java контролирует не redhat :-)Почему? И она в том числе.
07.03.2013 23:18 Компания Red Hat возглавила разработку OpenJDK 6: http://www.opennet.me/opennews/art.shtml?num=36332
рассуждения жабоидов об объектном программировании несколькими ветками выше неимоверно доставили.
-"Целью создания Ceylon было избавление от устаревших концепций и подходов, которые мешают дальнейшей эволюции языка Java и достижению более высокого уровня эффективности."
ДА УЖ!! До эффективности явы этим "поделкам из песочницы" еще ползти и ползти...
-"Кроме реализации лучших возможностей Java, в Ceylon заимствованы некоторые дополнительные конструкции из языков Smalltalk, Python и ML."
И от стройных абстракций явы выползает покореженный мутант. 10 рук 10 ног пришитых, только голова как и было по 2 ноги и руки обслуживает. Зачем остальные? - А остальные этож Smalltalk Python и ML :)
> стройных абстракций явыспасибо, посмеялся.
>> стройных абстракций явы
> спасибо, посмеялся.Вероятно, имелась ввиду простая и понятная парадигма. И это правда. Многие особенности языка можно правильно определить путем лишь логических рассуждений, зная некоторые другие особенности.
Этого нельзя сказать о скале, груви и пр. жвм-бейсед языках.
Ты не обижайся, но в тебе юношеский максимализм говорит
Рекомендую классиков вспоминать иногда
-"Все гениальное - просто"
Цейлон, дарт... Шапки с гулом сговорились?
Джависты такие джависты... "А давайте возьмем что-то хорошее из других языков, но назовем по другому и сделаем посложнее - раз уж нам было тяжело придумать, пускай остальные помучаются, пока поймут". Как было, например, с дженериками.given вместо where из дотнета, alias вместо typedef из С, value вместо var из дотнета или auto из плюсов (тоже, блять, красавчики - на целую букву больше набирать, и при дальнейшем ифе синтаксис плывет).
Хорошо хоть function из жабоскрипта взяли не изменив на какое-нибудь "subproc".Зачем, ЗАЧЕМ переименовывать заимствованные устоявшиеся названия фич из других языков??? Это что, какая-то ненависть к прикладным программистам - вместе с концепцией языка заодно пусть и наборы ключевых слов в голове переключают? Или синдром своей гениальности и исключительности? Дык тогда давайте вместо for введем iter, вместо switch - select, вместо if - choice... Выйдет действительно _новый_ язык, доселе никем не придуманный.
Дальше больше. Зачем-то удалили перегрузку функций, заменив ее параметрами по-умолчанию и переменным количеством аргументов. Ах да, добавили возможность эмулировать перегрузку функций специализацией дженериков (sic!)! Полный звездец.И это я пока только 1/10 спецификации осилил. Дальше там такой бред начинается... [facepalm]
Впрочем, щас попробую что-нибудь посложнее HelloWorld написать - пощупаем как оно на самом деле. Может все не так страшно )
