Почему не любят С#?

За микрософт.

за рантайм, микрософт

Шарпы — отличнейший язык, ява-подобный но со «своей атмосферой». Губит его только анальная привязка к мелкософту.

Слишком много сахара.

Кстати, Java в 1.5 как раз кучу всего «натырила» и шарпов (теже дженерики, если не ошибаюсь). И вообще, слово «тырить» — здесь недопустимо.

Что вы тогда скажете о Ruby..., который есть сплошной сахарный сироп.

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

За .NET и моно. Разводить очередной спор про недостатки сабжа влом, один хрен фанатиков не переубедить, кто адекват сами всё видят.

За GNOME

За микрософт.

Кстати, кто-нибудь может подсказать самый простой способ чуток поменять синтаксис JAVA? Интересует добавление ключевых слов, допустим. Уже посмотрел на википедии список виртуальных машин в сырцах.

Кстати

Ну-ну

Groovy. Поддерживает обычную Java, но при этом есть возможности к DSL

ниасилили, очевидно же (%

Конкретно хотелось бы иметь нечто в виде:

ShortMessage msg = new ShortMessage();
msg.setMessage(ShortMessage.NOTE_ON, note, vel);
receiver.send(msg, -1) -> MidiDataExceptionCatcher,UnknownExceptionCatcher;

1. .NET, который проприетарен и не может в кроссплатформенность (inb4: mono)
2. Ещё один плюсоподобный huge'n'bloated язык.

Кстати, кто-нибудь может подсказать самый простой способ чуток поменять синтаксис JAVA?

Изменять компилятор, больше никак. А зачем, если не секрет?

А зачем, если не секрет?

Хочу свою яву, с блэкджеком. Выше привёл пример.

за мелкософт

Хочу свою яву, с блэкджеком. Выше привёл пример

Ради небольшого сахарка делать непереносимый код?

Ради небольшого сахарка делать непереносимый код?

Ну да, что-то вроде. Меня не интересует, выполнится ли код где-то, кроме моей машины, я хочу язык для своих каждодневных нужд.

за плохую и отстающую реализацию на Linux

А что такое эти catchers? Они вообще как обьявлены, откуда берут данные? Может можно через AOP?

Что такое MidiDataExceptionCatcher?

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

А мне шарп нравится больше, чем питон. Я не понимаю тех, кто любит питон и ненавидит шарп.

А что такое эти catchers? Они вообще как обьявлены, откуда берут данные?

Думаю, можно реализовать просто как отдельные классы с абстрактным методом, обрабатывающим исключения. Таким образом можно избавиться от множества try catch finally, которые весьма громоздки с т.з. читаемости + унифицировать обработку исключений.

И давить исключения тоже весьма красиво получится:

myMethod() -> nullCatcher;

Или даже

myMethod() -> null;

Непереносимый код, чтобы приблизить тепловую смерть вселенной. По делу: добавлением ключевых слов в Java занимаются большие конторы вроде redhat, jetbrains и oracle. И университетские группы, у которые делают scala. Наиболее годным вариантом пока является scala, и на каждый день пойдет, и в java-окружении можно использовать.

Наиболее годным вариантом пока является scala, и на каждый день пойдет, и в java-окружении можно использовать.

ОК, посмотрю эту вашу скалу.

А как они работают вне контекста? Тоесть у вас ошибка в одном месте и ошибка в другом. Оно тогда ведь будет обрабатывать одинаково?

Но вообщем всякие Groovy и Scala, во-первых не заморачиваются checked exceptions, во-вторых можно просто сделать функцию, в которую передается lambda

nullCatcher{
     myMethod();
}

Но если выпить упорину, то по крайне мере в Scala думаю можно написать то что вам надо непосредственно и еще с контролем типов

Тоесть у вас ошибка в одном месте и ошибка в другом. Оно тогда ведь будет обрабатывать одинаково?

Ну да, в том и суть, реализовать однотипные обработчики в виде отдельных классов и удобно их вызывать (без лишнего нагромождения скобочек).

try catch finally можно не писать уже сегодня, прямо сейчас. Достаточно определить MyException, который планируется выкидывать, как наследник от RuntimeException. Ловить можно где-нибудь в финальном обработчике, который оборачивает основной код в потоке. Кстати, как там у catchers с потоками?

Зачем тебе множество try-catch-finally? В 7-й джаве finally вообще не нужен почти никогда, хватает try-with-resources почти на все случаи жизни. catch расставляешь, чтобы ловить checked exceptions и не плодить throws у каждого метода? Если да, то достаточно изолировать кривое api и перекидывать его checked exceptions как unchecked. Вот от чего я бы не отказался, это от патча, который переводит нарушение соглашения о checked exceptions из ошибки компиляции в опционально отключаемый warning. По-хорошему давно пора это сделать.

Изза того что его разработала МС

IMHO самый удачный ЯП общего назначения.

Перефразирую вопрос. Согласно вашей идее реакция на NPE в совершенно одинаковая где бы она не была. Если catcher онинаковый. И если вы их будет делать много для каждого случая, то окажется что почти все используются только один раз. Wait a minute... OSHI

Так оно же откатит весь стек, а ему локально надо

Достаточно определить MyException, который планируется выкидывать, как наследник от RuntimeException.

Как быть с чужими исключениями? Всё throw-ать до main'а ? :)

Губит его только анальная привязка к мелкософту.

Стандарт на язык открыт и за его реализацию МС не будет судить.
Это вам не Oracle.

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

grim, ваша позиция всем на ЛОРе известна. С ней все не согласны. Зачем начинать этот спор опять?

Там же особый случай, там маппинг ошибкок Java на статусы HTTP

Потому что говно, очевидно.

Вот от чего я бы не отказался, это от патча, который переводит нарушение соглашения о checked exceptions из ошибки компиляции в опционально отключаемый warning. По-хорошему давно пора это сделать.

Java ведь сделана так, чтобы нельзя было выстрелить себе в ногу. А отключение error при checked exceptions породит Delphi-style код, когда можно вообще не обрабатывать исключения, и приложение будет тихо-мирно разваливаться в фоне, продолжая как-то работать.

Потому что это типичный образчик «vendor lock-in».

А где это самое «локально» находится? Вообще подозреваю, что нужны именно catchers, именно в таком синтаксисе, а локально или нет - не так уж важно. Главное, не как у всех ;)

grim, ваша позиция всем на ЛОРе известна. С ней все не согласны. Зачем начинать этот спор опять?

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

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

Вам уже много раз писали о mono но что-то результата никакого :(
продолжаете писать глупости о «майкрософт-only инструментах»

Угу, особенно checked exception для connection.close(). Вообще во времена hello worldов те случаи когда exception проверяемый в JDK был сильным источником ошибок, то тогда казалось что это поможет. Потом правда оказалось что методы выстрелить себе в ногу есть поизощреннее. Они действительно больше мешают и загрязняют код спагетти чем помогают. Любой уважающий себя фреймворк пытается их заткнуть и превратить в runtime

Язык без рантайма и библиотек никому не нужны. И так уже больше 9000 языков. А вот рантайм и библиотеки есть только у MS. Поэтому mono != .net, или информация устарела? Сейчас уже можно без опаски писать софт без использования неймспейсов Microsoft.* ? Оракел, а до этого Sun, тратит много усилий на всякие Compatibility Tests, про такое в мире .net не слышал.

Но ведь правда, почти все написано на майкрософт driven экосистеме. Почити любой проект ASP.NET, Entity Framework, WCF. И сидят, молятся на новую версию, ведь объективно реализация только одна для каждой технологии разработки системы

grim, ваша позиция всем на ЛОРе известна. С ней все не согласны.

Вы - не значит все.

Оракл судился изза Java патентов причём неоднократно, в то время как МС гарантировала открытость C# и .Net технологий.

Я что-то не так описал?

Но ведь правда

Нет.
Неправда.
Есть mono и им активно пользуются.