Для тех, кто не читает новости на OpenNet.ru: Компания Red Hat представила язык программирования Ceylon, призванный заменить Java.
Мопед не мой :) Сам пока на Ceylon не смотрел.
Update: Ссылочки на OpenNet.ru какие-то левые. Поэтому можно заглянуть на Wikipedia, там даны ссылки н оригинальную презентацию и вторую pdf-ку (правда грузится все весьма медлено)
28 комментариев:
http://stackoverflow.com/questions/5645700/whats-the-difference-between-scala-and-red-hats-ceylon-language
@Left:
спасибо за ссылку
Вспоминается анекдот про медведя "Ну а я-то куда полез! Я ведь и читать-то не умею..." - в смысле нафига это RedHat? Поставить галочку в графе "свой язык программирования"? Я кстати не понял - под капотом у него будет JVM или что-то своё (если своё, то это вообще кидание понтов на ровном месте)
@Left:
ЕМНИП, RedHat уже давно лезет в нишу системной интеграции и разработки больших решений для больших заказчиков. Где он пытается конкурировать с IBM-ом.
Видимо, хотят заиметь более удобный для этих целей язык, чем Java.
А компилироваться Ceylon планирует в Java-байт код и работать будет на JVM. Если будет :)
> Видимо, хотят заиметь более удобный для этих целей язык, чем Java.
Сам язык нынче лабается толковым студентом в виде дипломной работы. А вот сделать язык столь же популярным в энтерпрайзе как джава - это нужны миллиарды долларов, сотни программистов и десяток лет. У редхэт завалялось и то и другое и третье?
> А компилироваться Ceylon планирует в Java-байт код и работать будет на JVM. Если будет :)
Чего б тогда не взять лучшее что есть на данный момент и не довести до ума его? Скала прямой конкурент и кроет это Ceylon как бык овцу. Вот и вкладывали б деньги в её развитие, благо там есть чего развивать
@Left:
>А вот сделать язык столь же популярным в энтерпрайзе как джава - это нужны миллиарды долларов, сотни программистов и десяток лет. У редхэт завалялось и то и другое и третье?
Вроде бы главной причиной снятия завесы секретности с разработки является желание RedHat разделить расходы по его разработки с кем-нибудь еще.
>Скала прямой конкурент и кроет это Ceylon как бык овцу. Вот и вкладывали б деньги в её развитие, благо там есть чего развивать
У Скала есть фатальный недостаток -- ее писали не мы :)))
Если же серьезно, то против Scala работает то, что ее создают ученые, а не программисты (в отличии от C, C++, Java и C#). Посему получается, может быть и стройный, и красивый язык. Но какой-то замороченный. С довольно высоким порогом вхождения. Не для быдлокодинга.
Так что это решение я понимаю. Более того, сам бы решил не вкладываться в доработку Scala :)
> Если же серьезно, то против Scala работает то, что ее создают ученые, а не программисты (в отличии от C, C++, Java и C#).
Ну уж нет. Тут не соглашусь ни капли. Переписывать несколько раз коллекции пытаясь сделать результат лучшим среди языков со статической типизацией - этого б учёные не сделали никогда.
А порог вхождения в скалу кстати невысок - просто нет книжек "учим быдлокодинг на скале за 3 дня". Если не лазить в дебри - язык получается даже проще чем джава.
Лучший комментарий про Ceylon:
> Business oriented? Easy to learn, easy to read? Funky syntax, weird keywords? They've invented VB!
@Left:
>Тут не соглашусь ни капли. Переписывать несколько раз коллекции пытаясь сделать результат лучшим среди языков со статической типизацией - этого б учёные не сделали никогда.
Ну а по мне, так это типично академический подход -- найти N+1 решение какой-то проблемы.
Практики делают как с STL-ем в C++: один чувак (точнее три) написал что-то работающее, остальные просто взяли и стандартизировали. И никого с тех пор не волнует, что можно было бы и получше. Просто пользуются и все.
>Если не лазить в дебри - язык получается даже проще чем джава.
Не, не соглашусь. В Java что хорошо -- нужно тебе сделать что-нибудь заумное -- не получится это сделать заумным. Придется все писать просто. Поскольку средств достаточной выразительности нет.
А вот в Scala есть. Но осваивать их непросто. Даже по книгам, блин.
> Ну а по мне, так это типично академический подход -- найти N+1 решение какой-то проблемы.
Нет. Это подход человека который делает что-то ответственно - вылизывает чтобы блестело как у кота яйцы.
> Практики делают как с STL-ем в C++: один чувак (точнее три) написал что-то работающее, остальные просто взяли и стандартизировали. И никого с тех пор не волнует, что можно было бы и получше. Просто пользуются и все.
Да ну ладно - не волнует. STL повсеместно используется только потому что он стандартен, и то многие дрыгаются в сторону велосипедов. Но что-то не видно кардинальных улучшений в STL за все годы его существования.
> Не, не соглашусь. В Java что хорошо -- нужно тебе сделать что-нибудь заумное -- не получится это сделать заумным. Придется все писать просто. Поскольку средств достаточной выразительности нет.
Иная простота - она хуже воровства ;)
Частенько "простые" решения выливаются в велосипеды с квадратными колёсами именно из-за отсутствия нормальных средств с нормальной выразительностью.
>Это подход человека который делает что-то ответственно - вылизывает чтобы блестело как у кота яйцы.
Имхо, это как раз непозволительная роскошь в обычном инженерном деле.
> Но что-то не видно кардинальных улучшений в STL за все годы его существования.
Ну дык и не получиться. Большинство устраивает то, что есть, а остальные могут на собственных велосипедах ездить. Главное, что раз в пять лет никто "новый, теперь с малиновым вкусом" STL не предлагает. Поскольку совместимость важнее.
А вот Александреску в D нашел возможность заниматься переписыванием контейнеров (с интерфейсом на основе range-й, а не интераторов). Поскольку то, что он делает в своей песочнице мало кого волнует.
>Частенько "простые" решения выливаются в велосипеды с квадратными колёсами именно из-за отсутствия нормальных средств с нормальной выразительностью.
Популярность и востребованность языка -- это такая многофакторная и непредсказуемая вешь... Выразительность там точно не на первом месте. А то бы всякие ML-и, Ocaml-ы и Haskell-и для C++ и Java/C# давно места под солнцем не оставили :)
http://in.relation.to/Bloggers/Ceylon
Nevertheless, I should make a few comments. First, I never billed this as a Java Killer or the next generation of the Java language. Not my words. Ceylon isn't Java, it's a new language that's deeply influenced by Java, designed by people who are unapologetic fans of Java. Java's not dying anytime soon, so nothing's killing it.
So why a new language? Well, we've been designing and building frameworks and libraries for Java for ten years, and we know its limitations intimately. And we're frustrated. I'm not going to recap all the frustrations here. (I've listed some of them in the first presentation.) But I guess I should mention that the number one technical problem that we simply can't solve to our satisfaction in Java - or in any other existing JVM language - is the problem of defining user interfaces and structured data using a typesafe, hierarchical syntax. Without a solution to this problem, Java remains joined at the hip to XML.
But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project.
On Slashdot, several commenters argue that creating a whole language and SDK from scratch is an enormous undertaking. Well, we're really not starting from scratch: we can reuse an enormous amount of code that is already available under open source licenses in the Java ecosystem. Just think of what's reusable from Open JDK, JBoss, and Eclipse! It's not a requirement that the entire SDK, compiler, and IDE be implemented in Ceylon. And it's not an enormous undertaking for a company of Red Hat's size. And, of course, we don't want to do this on our own. A project like this isn't even interesting unless it's a community effort.
Короче, похоже что журналисты как обычно "перераздули" новость.
@Left:
ну а я именно так и понял. Создается не совершенно новый язык, а новый язык, который сможет переиспользовать имеющийся Java-код. Типа Scala, но попроще и практичнее.
Раз уж вспомнили о скале:
http://greedy.github.com/scala/
Вот это имхо очень правильное и годное направление развития.
@Left:
>Вот это имхо очень правильное и годное направление развития.
Чесно говоря, не могу себе представить, зачем нужна Scala без Java SDK и всего огромного Java-наследия...
Вот таким вот лёгким полувывертом мы получаем возможность писать код который может работать как с так и без JVM, читай - единый язык для клиентских и серверных приложений (что-то типа того ради чего сейчас пилят Node.JS). Особенно если учесть что Google Native Client тоже поддерживает LLVM - всё это выглядит очень перспективно.
А, ну и да - сама скала как язык очень неплоха, иметь возможность писАть на ней легковесные клиентские приложения это тоже неплохо.
@Left:
А какая runtime-библиотека будет доступна из такой Scala на стороне клиента? Регулярные выражения, например. Математика. Не STL же там будет.
Хм. А скаловского рантайма мало?
@Left:
>А скаловского рантайма мало?
Да сколько там того рантайма? :) Плюс, не понятно, насколько можно его от JRE отвязать -- мож это всего лишь хорошие обертки вокруг стандартных JRE-шных средств.
Мне кажется, единственной правильной реакцией со стороны программистов должен быть безоговорочный байкот. Ибо стопятьсот по сути одинаковых языков - это ни разу не комильфо.
@NightmareZ:
Как-то разработчики не спешат объявлять бойкот Ruby из-за существования Rexx, Tcl, Perl и Python :)
Тем более, что программист -- скотина подневольная. Если выбор стоит между программированием на Ceylon-е за 2K или на VB за 1.5K, то почему бы и нет? :)
> Практики делают как с STL-ем в C++: один чувак (точнее три) написал что-то работающее, остальные просто взяли и стандартизировали.
бу-га-га (насчет чего-то работающего)
алекс степанов вначале делал STL на схеме (это явное проявление академических наколонностей) и аде, а затем понял, что действительно хорошо это можно сделать только на плюсах (это уже проявление здорового практицизма)
и он ЗНАЛ, что хотел; концепты (планировавшиеся, но не принятые в с++0х) это то, что не очень явно используется в STL-е
его идеи на эту тему продумывались чуть ли не с 70-х годов
слегка утрируя, STL не шедевр только по причине ограниченности с++
З.Ы. впрочем, параметрический полиморфизм и имплициты скалы представляют интересный альтернативный подход (однако, оставляющий у меня чувство пережевывания уже жеванного, когда одерский на их основе делает что-то похожее на компайл-тайм вычисления в плюсовых шаблонах)
З.Ы.Ы. и да, поздравляю с хорошим местом в первенстве Беларуси по дартсу (мне влом завести тут блог, посему у меня просят капчу и я комменты в блог-стопе пишу редко)
@имя:
В данном случае не суть сколько времени Степанов рожал STL. Когда в 1993 собирались принимать первый стандарт Страуструп переживал, что в стандартной библиотеки нет никаких готовых контейнеров. А почти каждый производитель компиляторов снабжал пользователей своими нестандартными решениями. Но тут подворачивается Степанов с STL и вместо того, чтобы делать на основе всего существующего какую-то консолидированную библиотеку просто взяли STL и все. Правда после этого еще 5 лет допиливали и сам стандарт, и STL.
Хотя могли бы попробовать взять какие-то вещи из STL, какие-то из Zortech C++, какие-то от других производителей. Но поступили прагматичнее.
основной пойнт моего выступления -- то, что STL не былa стандартизирована типа как (аналогия) куплен коробок спичек -- зайдя в первый ближайжий магазин, и говорить "И никого с тех пор не волнует, что можно было бы и получше." -- тоже не надо, волнует, и в т.ч. ради этого улучшения и затевались концепты (но при этом общая ИДЕЯ, стоящая за STL, остается ПРЕЖНЕЙ)
(другое дело, что в с++ очень много чего просто тупо не сделано)
вопрос -- так ли качественно одерски вылизывает свою библиотеку, как была вылизана STL -- остается открытым
с одной стороны, у одерски имеются более современные идеи типа ...-вариантности и немутабельные контейнеры, с другой -- я отнюдь не уверен в его бескомпромиссном подходе к скоросте и расходу памяти
тот же вопрос будет и к библиотекам цейлона
Отправить комментарий