LINUX.ORG.RU

Ceylon 1.0.0

 ,


0

3

Gavin King, главный разработчик языка программирования Ceylon, объявил о выходе первой стабильной версии — 1.0.0.

Ceylon — это новый язык со статической типизацией для платформы Java Virtual Machine, также поддерживающий компиляцию в JavaScript. Основные возможности языка:

  • Фокус на читаемости кода и отказ от «вредных» конструкций, затрудняющих понимание логики.
  • Развитая система типизации, включающая автоматическое выведение типов, алгебраические типы (объединение и пересечение) и уточнение типов на основе проверок на стадии компиляции.
  • Поддержка функций как объектов (лямбд) и кортежей (tuples).
  • Поддержка модулей, зависимостей между модулями и репозиториев на уровне языка.
  • Generic-типы с сохранением типизации во время выполнения (reified generics).
  • Типобезопасная метамодель с полной информацией обо всех структурах языка во время выполнения.
  • Списковые выражения (list comprehensions) и декларативное описание древовидных структур (в стиле JSON).
  • Новый SDK, свободный от исторического наследия JDK, при этом не исключающий прямое использование JDK и Java-библиотек

Одновременно вышла новая версия Ceylon IDE — плагина для Eclipse. По сравнению с предыдущей бета-версией в Ceylon IDE добавлены новые возможности:

  • панель иерархии типов;
  • панель документации (аналог Javadoc);
  • новое окно свойств модуля и возможность управления зависимостями модуля через GUI;
  • улучшения панели поиска;
  • улучшения подсветки синтаксиса;
  • улучшенный мастер импорта Java-архивов в репозитории модулей Ceylon.

>>> Подробности

Ответ на: комментарий от anonymous

О, очередной пылкий вьюноша со «скобочным вебом»!

Ну, попробуй реализуй скобочный веб, чо. Только сперва тебе придется написать свой валидирующий pull-парсер для S-выражений. Стандартный лисповый ридер не вернет AST, пока не распарсит все до последней скобки, а в вебе надо начинать интерпретировать по возможности сразу же.

Затем ты напишешь разборщик и валидатор своих DSL-аналогов HTML и CSS и начнешь реализовывать рендерер. В этот момент обнаружится, что для лиспа нет качественных биндингов к современным GUI-тулкитам. Сперва ты возьмешься за cffi-cairo и cl-cairo2, но выяснится, что они заточены под старые версии Cairo и не работают.

Ты станешь допиливать Cairo-биндинги, но однажды решишь, что Cairo семантически чужд лисп-парадигме и возьмешься писать свою кросс-платформенную библиотеку для поддержки высокопроизводительной векторной графики. Затем ты реализуешь аналог протокола HTTP, только на S-выражениях (назовем его SXTP), потому что HTTP с его убогими URL'ами и методами семантически чужд лисп-парадигме.

После этого встанет вопрос о написании веб-сервера, поддерживающего SXTP. Попутно ты напишешь template engine, аналоги XPath, XSLT, а также ORM и MVC-фреймворк. В этот момент выяснится, что традиционные SQL-базы данных семантически чужды лисп-парадигме, и ты начнешь разрабатывать собственную лисп-ориентированную БД.

В этот момент ты поймешь, что Common Lisp перегружен и недостаточно выразителен, его стандарт раздут, а макросы негигиеничны; что Scheme слишком минималистична и академична; что остальные диалекты лиспа либо маргинальны, либо требуют .NET/JVM. Тут тебе в голову придет идея создать собственный лисп. Ты потратишь несколько лет на разработку стандарта, реализацию языка и переписывание всего вышеперечисленного на твоем новом языке. После этого окажется, что все ужасно тормозит. И это, разумеется, исключительно по той причине, что операционные системы стандарта POSIX семантически чужды лисп-парадигме. Ты начнешь разрабатывать LISP OS.

В процессе разработки выяснится, что эффективная LISP OS для x86/ARM/MIPS не может быть создана в принципе, так как их семантика чужда лисп-парадигме. Ты возьмешься за изучение System C, Verilog, VHDL и в один прекрасный день создашь лисп-машину на FPGA.

В этот момент мозаика чудесным образом сложится. У тебя будут лисп-машина, лисп-OS, лисп-сервер и лисп-браузер. Ты восторженно оглянешься вокруг, и обнаружишь, что половина человечества уже переселилась на Gliese 581, а оставшаяся половина забыла про HTML/CSS/etc., как про страшный сон, и давно пользуется квантовыми компьютерами и квантовыми сетями. Но все это уже будет не важно. У тебя ведь будет лисп-браузер и полноценная замена HTML/CSS на S-выражениях.

Да и жить тебе останется не так и долго, потому что к этому моменту ты уже будешь дряхлым стариком.

anonymous ()
Ответ на: комментарий от anonymous

Сделал мою рабочую ночь, добра, с хорошим настроением пойду жабапроект дособирать.

По сабжу: чтобы понять что из себя представляет этот Dalvik Clang, рекомендую почитать исходники hibernate, на ночь только не читайте.

anonymous ()
Ответ на: комментарий от RedPossum

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

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

BambarbiyaKirgudu ()
Ответ на: комментарий от bbk123

А, ну ок. :-)

Просто тут jetbrains'овцы рассказывали про своё творение (ещё один jvm выкидыш - язык kotlin) и почему-то делали акцент на том, что типа они в kotlin'е полагаются на стандартную библиотеку java, а redhat со своим ceylon'ом полагается на стандартную библиотеку свою, а не java'вскую.

Видимо имели ввиду, что именно как основные рассматриваются не библиотеки java, а собственные. Но так видимо и scala делает, так что ну и ок, пофиг.

vitalif ★★★★ ()
Последнее исправление: vitalif (всего исправлений: 1)
Ответ на: комментарий от RedPossum

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

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

Csandriel ()
Ответ на: комментарий от i3draven

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

Лол. Так ведь жава изначально работала с обеих сторон. Я собсно поэтому ее и выбрал: клиент+сервер+любая платформа. Ибо нюх подсказал что лень будет учить что-то еще ^_^ Стандартом это ее не сделало. Хотя здесь многое маркетинг и копирастия попутали.

Csandriel ()
Ответ на: комментарий от Csandriel

Хотя здесь многое маркетинг и копирастия попутали.

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

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

Csandriel ()
Ответ на: комментарий от Csandriel

может я нихера не понимаю

скорее всего

отсутствие дескриптора уровня доступа: минус к безопасности

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

отсутствие разницы между статическим и динамическим контекстом

все по той же причине, это static, потому как тут не может быть объекта

отсутствие типизаци

Man вывод типов.

RedPossum ★★★★★ ()
Ответ на: комментарий от vitalif

Очевидно, что очень толсто.

А что не так-то?

anonymous ()
Ответ на: комментарий от Csandriel

Вспоминая эту драму, эту подлость, я испытываю оргазмический позыв от каждой конвульсвии макрософта

молодой человек, как вы таки это вспоминаете, если в ту пору максимум вложенные квадраты черепашкой рисовали?

RedPossum ★★★★★ ()
Ответ на: комментарий от RedPossum

какой безопасности?

на сколько мне известно, идея маркеров package|private|public состоит в обеспечении невозможности обойти ответственные методы обращением напрямую к «тонкой» <s>душевной</s> внутренней реализации какого-либо класса. Здесь речь не только о явном наследовании/переопределении, а о возможности залезть в потроха класса вообще как угодно, - при условии упразднения разделения доступа.

все по той же причине, это static,

и откуда это видно? Вообще, откуда паста?

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

может я нихера не понимаю

скорее всего

Я не претендовал на роль эксперта. Тем более я не считаю себя умнее создателей Java. Был бы умнее, сделал бы лучше. Сильно сомневаюсь, что в ней есть что-то лишнее. Скорее чего-то нехватает, судя по характеру недовольства кодеров-многоборцев.

Man вывод типов.

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

Csandriel ()
Ответ на: комментарий от RedPossum

Я не был свидетелем WWII, но это не значит, что равнодушен к тем событиям. Когда я читал историю java, так же сердце кровью обливалось. V_v

Csandriel ()
Ответ на: комментарий от Csandriel

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

В современной Java очень много чего лишнего, что добавили в угоду ущербной публике. Java была идеальной в версии 1.5 - было все, что надо, и совершенно ничего лишнего.

anonymous ()
Ответ на: комментарий от anonymous

идеальной в версии 1.5

лол. На ней и остановился. Решил «мне с головой хватит».

что добавили в угоду ущербной публике

Обычная картина. Слава дает кумиру поклонников, рабами которого и делает.

Csandriel ()
Ответ на: комментарий от i3draven

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

Я бы сказал они берут лучшее от множественного наследования, избегая его граблей.

Они вводят множественное наследование поведения, без наследования состояния

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

Csandriel ()
Ответ на: комментарий от Csandriel

Поясню что меня смущает, в моем представлении о множественном наследовании: А наследует B и C. Что будет, если в B и C совпадают названия и типы некоторых полей, которыми распоряжаются совершенно разные методы? Что будет, если методы из B зависимы от методов C или наоборот? Ну в общем мне очень сложно представить всю гамму возможных последствий скрещивания классов, без их тщательного предварительного изучения. А не легче ли самому написать класс с нужным функционалом, не полагаясь на совместимость бульдога с носорогом? Собственно жава это и предлагает. По моему это очень разумно.

Csandriel ()

алгебраические типы (объединение и пересечение)

То что в скобках к тому что за скобками отношения не имеет никакого.

r ★★★★★ ()
Ответ на: комментарий от i3draven

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

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

Csandriel ()
Ответ на: комментарий от i3draven

Надо отдать должное ораклу, они отделили jvm от языка

Расскажи подробнее, или ткни что почитать, - что ты под этим подразумеваешь. В смысле, разрешили компилить в байткод под JVM хоть суахили? Или с самой машинкой что-то сделали? Последний раз я интересовался программированием еще до продажи ораклу. Думал возобновить хобби. А ты меня печалишь дальше-больше.

Csandriel ()
Ответ на: комментарий от Bohtvaroh

Spring & Hibernate - два главных тормоза в Java enterprise apps.

И самое главное, непонятно зачем.

Spring DI заменяется на Guice, Hibernate - на любую другую реализацию JPA, включая EclipseLink и OpenJPA.

reserved ()
Ответ на: комментарий от i3draven

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

См. пост выше

reserved ()

ЕМНИП жаба тоже с того же начинала, что убирала «вредные» конструкции С++. История показала, что вредными они не были и потом в жабу ввели те же множественные наследования (в виде интерфейсов), то же обобщенное программирование (в виде женериков), вот только до переопределения типов не дошли руки еще.

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

dr_dobermann ()
Ответ на: комментарий от dr_dobermann

те же множественные наследования (в виде интерфейсов), то же обобщенное программирование (в виде женериков)

Не сравнивайте тёплое с мягким.

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

А ввели их потому, что практика показала, что они таки нужны. Когда создавалась Java 1.0, этого нельзя было предугадать.

reserved ()
Ответ на: комментарий от asaw

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

GWT не закопан. Они пилят 2.6 и 3.0. Просто развивается медленно, потому что Гугл на него положил, отдал сообществу и стал пилить Dart.

Ceylon с компиляцией в JS - это что-то ближе к Dart/TypeScript/CoffeeScript, чем к GWT. У GWT огромная стандартная библиотека, которая пытается абстрагироваться от браузера и сделать вид, что никакого HTML и CSS у нас вообще нет, приблизив создание веб-клиентов к десктопной гуйне на всяких свингах. Ceylon на платформе JS - это, по сути, просто новый синтаксис для того же JS. Чтобы что-то сделать со страницей, нужно дёргать старый добрый DOM.

reserved ()
Ответ на: комментарий от i3draven

так как зоопарк перестал влазить в головы одного программиста

Не в этом же дело. Просто людям не хочется писать одно и тоже сначала для сервера, а потом для клиента. Будет один язык - писанины сократится в два раза.

anonymous ()
Ответ на: комментарий от anonymous

Еще 40 лет назад стало понятно, что фон-Неймановская архитектура ущербна, и плохо масштабируется.

anonymous ()
Ответ на: комментарий от anonymous

Kotlin я вообще не щупал, хотя слушал доклад одной девочки из jetbrains, увлечённо рассказывала. На тот момент возник в голове вопрос - чем оно лучше scala/groovy (и кто-то его даже задавал вслух), но ответа на него внятного так и не помню.

А цейлон одного ранга или тоже наколенная поделка?

BattleCoder ★★★★★ ()
Ответ на: комментарий от reserved

Spring DI заменяется на Guice, Hibernate - на любую другую реализацию JPA, включая EclipseLink и OpenJPA.

И чем же мелкий и кастрированный guice лучше спринга? Ну и да, ORM в том виде, что есть в hibernate/jpa, со всеми этими lazy loading и автогенерацией сложного sql не нужен.

Nagwal ★★★★ ()
Ответ на: комментарий от Csandriel

идея маркеров package|private|public состоит в обеспечении невозможности обойти ответственные методы

а потом мы берем рефлексию и вся невозможность исчезает. Это маркеры, не более, если надо - можно.

RedPossum ★★★★★ ()
Последнее исправление: RedPossum (всего исправлений: 1)
Ответ на: комментарий от Csandriel

и откуда это видно? Вообще, откуда паста?

да с главной их.

и откуда это видно?

класса вокруг function нет? Вот и хорошо.

Нинужна.

var borsch = new Borsch();

ну и где ты потом тут ошибиться сможешь?

RedPossum ★★★★★ ()
Ответ на: комментарий от Csandriel

Раскрасив осьмерку спецом как для геев

Ты всё время о них думаешь? Давно это началось? Стальные трусы прикупил уже?

anonymous ()
Ответ на: комментарий от anonymous

одно и тоже
для сервера, а потом для клиента

Лол.

anonymous ()
Ответ на: комментарий от i3draven

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

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

kto_tama ★★★★★ ()
Ответ на: комментарий от Nagwal

И чем же мелкий и кастрированный guice лучше спринга?

Он легче и компактнее, решает одну задачу и решает её хорошо, в отличие от вашего раздутого монстра.

Ну и да, ORM в том виде, что есть в hibernate/jpa, со всеми этими lazy loading и автогенерацией сложного sql не нужен.

А в каком нужен? Есть ли для Java такой ORM, который вам нравится, о великий гуру?

reserved ()
Ответ на: комментарий от reserved

Он легче и компактнее, решает одну задачу и решает её хорошо, в отличие от вашего раздутого монстра.

1 - чем спринг не хорошо решает задачу DI?

2 - если тебе нужен _только_ DI, никто не заставляет тащить все, что есть в спринге, он уже сто лет как модульный.

А в каком нужен? Есть ли для Java такой ORM, который вам нравится, о великий гуру?

Что-то типа iBatis. Т.е. простой мэппинг запроса на сущность. Хотя мне обычно голого jdbc-template хватает. В случае nosql хорошим примером может быть spring-data-mongo

Nagwal ★★★★ ()
Ответ на: комментарий от Bohtvaroh

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

А можно сделать DI без мутабельности?

Если нет, то придется работать с мутью. DI слишком удобная концепция, чтобы от нее отказываться.

PS Когда нет Спринга использую самописную фабирку для реализации принципов DI.

VoDA ★★ ()
Ответ на: комментарий от reserved

Больше контроля за хождением к БД нужно. Проблемы с хибернейтом отлаживать - это страх и ужас. Batch операции с хибернейтом - проще застрелиться. DDL в ходе работы приложения (а не при старте) - от этого хибернейту также плохеет. Вообще за идею lazy коллекций убивать надо, слишком просто с ними накосячить.

У ibatis были идеи правильные, но он устарел 10 лет назад. Лучше всего взять обертку над JDBC нетолстую (spring-jdbc например) и добавить нужную декларативность (маппинг запросов на классы/интерфейсы). В начале проекта работы больше, зато поддержка в разы проще. Скажите, чего вам будет в первую очередь не хватать без хибернейта?

Да, не генерите пожалуйста доменные классы. Никогда. Генерите интерфесы для них, если уж очень сильно нужно. Спасибо.

anonymous ()
Ответ на: комментарий от VoDA

А можно сделать DI без мутабельности?

@Inject на конструктор. Guice, кстати, такой подход и рекомендует.

reserved ()
Ответ на: комментарий от anonymous

У ibatis были идеи правильные, но он устарел 10 лет назад. Лучше всего взять обертку над JDBC нетолстую (spring-jdbc например) и добавить нужную декларативность (маппинг запросов на классы/интерфейсы). В начале проекта работы больше, зато поддержка в разы проще.

Можно посмотреть в сторону querydsl-sql. Типобезопасная генерация запросов с отображением на POJO, безо всяких закидонов с EntityManager, @Id и так далее.

Скажите, чего вам будет в первую очередь не хватать без хибернейта?

Я им не пользуюсь. Я пользуюсь OpenJPA.

В первую очередь мне будет не хватать разрешения зависимостей. Во вторую - отслеживания изменений и сохранения только изменившихся свойств объекта. В третью - оптимистической блокировки с полем версии.

Detached objects и merge - не смертельно, по мне, так это вообще порочная практика, которую проблематично отлаживать. Лучше договориться раз и навсегда, что detached objects не будет вообще.

reserved ()
Ответ на: комментарий от reserved

Старый злой DOM, я б сказал. Был бы он добрым, не нужно было бы городить GWT. Но, видно, не взлетает ни так, ни эдак. Я бы не сказал, что GWT-приятная штука, но всяко лучше помойки HTML/CSS/JS.

asaw ★★★★★ ()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от metrokto

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

ООП головного мозга. Опять читал Гради Буча после обеда?

pitekantrop ★★★ ()
Ответ на: комментарий от asaw

Разработка сколько-нибудь большого проекта на GWT ужасна.

  • Внести изменения в код
  • Запустить тяжеленный сервер с devmode, еле ворочающийся с -Xmx512m
  • Дождаться запуска
  • Перезагрузить страницу
  • Дождаться, пока тормозной компилятор распарсит ВЕСЬ клиентский Java-код, игнорируя слайсы и runAsync
  • Выругаться на ошибки deferred binding, вылезающие в зависимости от погоды на Марсе
  • Перезагрузить страницу
  • Перезагрузить страницу
  • Выругаться на OutOfMemoryError из-за текучего и тормозного браузерного плагина
  • Перезапустить сервер, повторить шаги 2-5
  • Наконец дождаться загрузки формы логина
  • Залогиниться
  • Подождать, пока компилятор подгрузит всё остальное…

После этого разработка на чистом JS просто раем кажется, особенно при нормальной архитектуре (я использую require.js и backbone для модульности).

reserved ()
Ответ на: комментарий от Csandriel

Поясню что меня смущает, в моем представлении о множественном наследовании: А наследует B и C. Что будет, если в B и C совпадают названия и типы некоторых полей, которыми распоряжаются совершенно разные методы? Что будет, если методы из B зависимы от методов C или наоборот?

В том же Eiffel-е все это успешно разрешили еще в конце 80-х прошлого века. Если интересно, почитайте описание языка (хотя бы краткую выжимку на русском: http://eao197.narod.ru/better_language/languages/eiffel/0_overview.html)

eao197 ★★★★★ ()
Ответ на: комментарий от anonymous

Кстати...

DDL в ходе работы приложения (а не при старте) - от этого хибернейту также плохеет.

В нормальном приложении DDL не должно быть ни при старте, ни в ходе работы. Зачем оно? Изменение структуры базы должно производиться на стадии деплоя, а не выполнения.

reserved ()
Ответ на: комментарий от anonymous

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

А что не так с Kotlin? (Не знаю про него ничего.)

reserved ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.