Ceylon 1.0.0

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

Ну, попробуй реализуй скобочный веб, чо. Только сперва тебе придется написать свой валидирующий 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-выражениях.

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

Я бьюся в экстазе :) Даже обмазаться не успел :)

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

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

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

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

А, ну ок. :-)

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

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

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

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

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

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

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

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

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

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

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

скорее всего

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

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

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

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

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

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

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

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

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

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

Годно, чо

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

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

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

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

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

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

скорее всего

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. пост выше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You made my day! :) Знатные вещества.

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

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

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

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

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

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

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

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

Нинужна.

var borsch = new Borsch();

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

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

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

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

Лол.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо за Gliese 581. Почитал с интересом.

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

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

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

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

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

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

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

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

Кстати...

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

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

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

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