LINUX.ORG.RU

Вышел Ceylon M5 «Nesa Pong»

 ,


0

3

Вышла очередная версия Ceylon - языка программирования со статической типизацией для платформ JVM и JavaScript, разрабатываемого Red Hat.

Основные новые возможности этой версии:

  • Типизация параметров на этапе выполнения (реификация) для generic-типов. Эта возможность давно поддерживается в .NET, но не в Java.
  • Прямое взаимодействие с JavaScript-кодом, с поддержкой динамической типизации, с помощью блока dynamic.
  • Кортежи (tuples).
  • Множество мелких изменений и добавлений синтаксиса, в основном относящихся к категории синтаксического сахара.
  • API даты/времени на основе JSR-310 (javax.time).
  • HTTP-сервер.

Из спецификации языка пока остаются нереализованными:

  • Типобезопасная метамодель.
  • Аннотации, определённые пользователем.
  • Сериализация.

Вместе с самой платформой, как всегда, вышла новая версия Ceylon IDE - плагина для Eclipse. Инструкции по установке находятся здесь.

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



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 2)

языка программирования со статической типизацией

оно будет меньше тормозить и жрать памяти? или это просто чтобы быдло-индусов на цепь посадить?

anonymous
()

еще один мертворожденный язык

umren ★★★★★
()

не нужно, есть kotlin^W scala, java. Этим кто-то кроме красношапок пользуется?

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

Для бэкенда JavaScript можно включить и динамическую, с помощью блока dynamic, и для JVM хотят реализовать то же самое.

Другой вопрос, что тогда теряются те преимущества статической типизации, ради которых язык и разрабатывается.

reserved
() автор топика

Потом они перепишут на нем pulseaudio и systemd, и всем придется писать на этом языке все...

jackill ★★★★★
()

use clojure, Luke

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

anonymous
()

Типизация параметров на этапе выполнения (реификация) для generic-типов. Эта возможность давно поддерживается в .NET, но не в Java.

А это разве не фича (или отсутствие оной) в JVM?

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

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

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

Называется type erasure. И как мне кажется, для некоторых языков типа Scala это не просто фича, а механизм реализации всяких вещей типа higher kind и variance. Полагаю, что одной из главных причин того, что Scala не пошла на .NET стало то, что в .NET нет type erasure, а есть честные генерики, но с довольно узкими возможностями, недостаточными для Scala. Могу и ошибаться. В общем, недостаток превращается в достоинство, и наоборот.

dave ★★★★★
()

Чем оно лучше скалы?

anonymous
()

оказывается, эта штука еще и поверх JavaScript работать может... люблю я такие языки, мне нравится сама идея универсальности платформ, на которых может работать код

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от dave

Ну так можно при компиляции в CLR вообще же эти дженерики на низком уровне не использовать, а хуячить проедурной лапшой, разве нет?

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

Если бы там еще численные типы по спецификации не были ограничены только 64х-битной плавучкой, только хардкором, то платформа была бы еще более универсальной. А так и корпоративны е приложения идут мимо, так как никому не нужно, чтобы копейки/центы при расчете больших сумм терялись, да и на слабых устройствах гонять всю арифметику на FPU тоже медленно выходит.

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

как мне кажется, для некоторых языков типа Scala это не просто фича, а механизм реализации всяких вещей типа higher kind и variance

как type erasure этому помогает?

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

Потом они перепишут на нем pulseaudio и systemd, и всем придется писать на этом языке все...

Угу, встроенный HTTP-сервер уже есть, осталось добавить бинарные сообщения об ошибках и генератор QR-кода. )

sleepflint ★★★
()

И ведь никто не удосужился поздравить GNU/Столлмана.

anonymous
()

"Frustra fit per plura quod potest fieri per pauciora"(с)

То, что можно объяснить посредством меньшего, не следует выражать посредством большего.

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

Нативщина нинужна, нативщина должна остоваться в JITе виртуальной машины.

Что ты имеешь против AOT? :) ну ты еще скажи что AOT не нужен в Mono/Android, насмеши меня

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: use clojure, Luke от anonymous

Gavin King - быдлокодер же, он в хибернейте сделал все ошибки неопытного программиста, какие возможно

А вот здесь подробнее, что в нём не так?

Хоть мне и побоку на нативный хибернейтовский API, я пользуюсь JPA.

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

HTTP-сервер встроен в язык или как понимать написанное?

Нет, просто добавился ещё один модуль стандартной библиотеки.

reserved
() автор топика

Симпатичный и разумный язык - можно сказать глядя на синтаксис и обсуждение в reddit.

kristall ★★
()

Сколько уже можно плодить языки?

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

По-моему в .NET есть type erasure (вспоминаю это в доке по F#).

Нет. Там можно объявить IEnumerable и IEnumerable<T>. Это будут два разных типа.

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

как type erasure этому помогает?

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

Я думаю, что главная проблема в интероперабельности. Язык должен как-то взаимодействовать с окружающей средой, в данном случае c .NET. На модель генериков .NET язык Scala точно не ложится - последняя явно богаче. Представим, что генерики Scala реализованы без генериков .NET, имитируя type erasure. И как после этого код на Scala будет выглядеть из обычного C#? Например, код на F# из C# выглядит вполне неплохо, особенно если добавить атрибут CompiledName.

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

Первый раз слышу про «type erasure», хотя писать на цэшарпе с генериками это никак не мешает.
Да и в целом, кто пишет под дотнет, какать хотел на всякие скалы и уж тем более на Целофаны из ортогонального мира красноглазых шапок.

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

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

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

а, так мы про компиляцию динамического языка

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

то пишет под дотнет, какать хотел

Логический вывод - все кто пишет под дотнет - засранцы. Да мартышка?

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

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

вот поэтому то в scala type erasure. Кстати там же есть Manifest, вполне себе решение для житья-бытья в .Net

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

Ты тупой. Фича JVM - отсутствие низкоуровневой поддержки джинериков. Type erasure - фича компилятора Жабы. Никто не мешает убивать джинерики во время компиляции в любой другой рантайм.

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

вот поэтому то в scala type erasure. Кстати там же есть Manifest, вполне себе решение для житья-бытья в .Net

Type erasure происходит и в Java, и в Scala потому, что в байт-коде нет параметрических типов. Наприме, запусти к примеру jad - там все будет видно.

Попробую повторить еще раз свою мысль. Модель генериков .NET слаба для представления генериков Scala. В то же время, убогая модель генериков Java оказалась в самый раз для генериков Scala, потому что в этом случае не возникает (больших?) проблем с интероперабельностью с Java. Парадокса здесь нет. В .NET могут быть проблемы с интероперабельностью Scala и C#.

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

Еще я хочу сказать, что дизайн Scala привязан к Java, так же как дизайн F# - к C# и .NET. Дело и в модели генериков на самих хостовых платформах, да и в том, что модель генериков Scala слишком богата для них (variance, к примеру), но в случае Java это не так заметно.

Манифест тут с боку-припеку, да и у него есть ограничения.

dave ★★★★★
()

Типизация параметров на этапе выполнения (реификация) для generic-типов.
Типобезопасная метамодель.
Аннотации, определённые пользователем.

Взаимоисключающие фичи.

Сериализация.

До сих пор нет!?!? Как с этим работать???

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

Ты тупой. Убогая модель Java - подмножество убогой модели .NET. Тебя, лошара, никто не заставляет использовать нативные джинерики в .NET. Вбейся в стеночку, убогий.

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

Обоснуй, отродье свиньи. Кто тебя ЗАСТАВЛЯЕТ использовать нативные джинерики в .NET?

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