Разработка JDK 8 достигла стадии Developer Preview

Ура, jruby еще быстрее!)

Ога, язык в котором есть null, Nil, None, Nothing. Идеа стоит колом постоянно от скалы, набор программы == 100% загрузки одного ядра. А жирный почему-то я, ога ....

Очень скоро за нехваткой кейвордов добавят кириллицу и слова из русского языка. Тогда в шкале будут null, Nil, Nihilum, None, Nothing, Vacuum, Depression, Ничего, Ничто, Нечего и даже Ни**я.

(нет, щаз я говорю не именно про Java, а вообще про различный код который некоторые люди пишут в удобных IDE, пользуясь всякими там «удобными» функциями IDE :))

Так они удобные. То, что они неудобны луддитам, это уже другой вопрос. Луддиты должны страдать.

При установке на Windows XP оно уже предупреждает, что на дерьме мамонта не все может работать

Вот дерьмо. =(

Они практически одинаковые, вообще-то

Я только одного не понимаю. Сколько уже писали про открытие джавы 7, исходники вроде перелицензировали, все теперь базируется на openjdk7, а все равно дистрибутивная версия джавы глючит и косячит по страшному!

Как так? Будет нам уже когда нибудь счастье с джавой из коробки?

Ненужно

К логопеду, быдло.

различный код который некоторые люди пишут в удобных IDE

Гвидо предчувствовал всё это более 20-ти лет назад.

Я, например :) Для Android-разработки, если проект небольшой, не очень много RAM нужно.

что неосиляторы скалы думают насчет generics в джаве

он же compile-time only. Так, кусочек сахарку на зубик с пульпитом.

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

С этим у меня проблем нет, я не на джаве пишу.

У меня 6 ГБ ОЗУ, при этом запущен Eclipse с не маленьким Java проектом и в виртуалке с Win7 VS с C++ проектами. Вирт.машине отдал 2 ГБ из 6. Никакого дискомфорта не чувствую. А по поводу аппетитов программ, у меня Chrome кушает в разы больше.

не далее как вчера установил eclipse в свой уютный debian testing. прямо из репов. четыре раза запускал, четыре раза оно свалилось после попытки открыть html в браузере. казалось бы ынтерпрайз и хочет много рамы, а валится как худшие поделия на C++, даже без трейсов. нунафиг.

Эклипс такой эклипс.

это все от дистрибутивной жабы.

Если скалу выкинуть, откуда же в джаве будут появляться нововведения?

Не зря у тебя ник на fart заканчивается.

это все от дистрибутивной жабы.

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

Эти умники разрешили интерфесам иметь реализацию.

всего-то ? Ж) прогресс налицо, да... а шуму сколько...

Как switch по строкам. Удобно, да. Но в целом не стоит того, чтобы сильно отмечать.

Вот это от задач зависит. switch по строкам разработчики языка при желании могут оптимизировать. Навесить что-то типа движков регэкспов. Если это сделают, то множество задач с парсингом кода может значительно ускориться. И кстати, как насчет таких движков? Разрабатывают?

Тогда в шкале будут null, Nil, Nihilum, None, Nothing

нет, лучше как в жабе - только null. И попробуй догадайся из контекста откуда уши растут.

Зойчем этот сраненький недоязычок нужен?

Есть же лиспы, Perl, D, Ruby, и, прости ЛММ, питон с похапой.

не далее как вчера установил eclipse в свой уютный debian testing. прямо из репов. четыре раза запускал, четыре раза оно свалилось после попытки открыть html в браузере. казалось бы ынтерпрайз и хочет много рамы, а валится как худшие поделия на C++, даже без трейсов. нунафиг.

Была какая-то бага в swt-webkit, кажется. Или в gnome-webkit. Ввиду древности дебиана она там так и осталась, наверное. Короче, жаба ни при чем, да-да.

При установке на Windows XP...

Вот дерьмо. =(

Это про Windows XP?

Кстати, а что неосиляторы скалы думают насчет generics в джаве?

Что код наподобие этого

public static <T extends Comparable<? super T>> T max(List<? extends T> list)

ну, мне в во-первых удивительно - дистрибутивный эклипс собирается для недистрибутивной жабы?

Не совсем так. дистрибутивная жаба - говно и тут уж как ни собирай эклипс...

а во-вторых пофигу - жаба обещала пускаться всегда и везде. правила игры у неё такие

тоже неверно. На java.com есть jre и jdk, на котором обещалось, что быдет работать. Вот там оно и работает...

phoneme, нет?

Кажись таки есть проблемы. Ты ведь пишешь на языке с расширяемым синтаксисом. И доволен. Эти два утверждения естественно приводят к третьему - ты диванный теоретик и ничего не пишешь. Или работаешь не в команде

+1

А почему работа в команде на языке с расширяемым синтаксисом может быть проблемой? C++ - язык с расширяемым синтаксисом. На нем пишут команды в сотни, а то и в тысячи человек. Все довольны.

Ходят слухи, что в этих их америках все стартаперы и прогрессивные представители человечества, и стар и млад, тыкают скалу палочкой и даже пользуются, причем с удовольствием и профитом. => «смешная возня» - это авторитетные посты лоровских аналитиков :) (никого конкретно не имею в виду)

Ходят слухи, что Одерски закрыл проект «Скала» и ушёл программировать на Delphi 7.

Пишут, довольны. Синтаксис не расширяют

Кстати, а что осиляторы скалы думают насчет generics в джаве?

Generics в джаве на редкость убогое поделие. Оно просто не нужно. Вообще.

Что было нужно сделать - implicit кастинг из Object в любой класс.

    Map m = new HashMap();
    m.put("f", "F");
    String s = m.get("f");

А боксинг - не слишком сложно? ;)

Боксинг это не менее эталонное «ненужно».

Вот это от задач зависит. switch по строкам разработчики языка при желании могут оптимизировать. Навесить что-то типа движков регэкспов. Если это сделают, то множество задач с парсингом кода может значительно ускориться. И кстати, как насчет таких движков? Разрабатывают?

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

Пишут, довольны. Синтаксис не расширяют

Еще как расширяют. И Boost во все щели (где этого синтаксиса полно), и внешние препроцессоры (типа Tablegen).

У тебя религиозные предрассудки относительно расширения синтаксиса. Рациональных аргументов в пользу своей точки зрения ты не найдешь.

Что было нужно сделать - implicit кастинг из Object в любой класс.

ну да, действительно, к черту эту стогую типизацию, давайте стрелять друг другу в ноги.

Что было нужно сделать - implicit кастинг из Object в любой класс.

Хорошо, все-таки, что Java разрабатывают не ЛОРовские аналитики. Нет, не нужно, это противоречит идее статической типизации. И, в частности, ломало бы вот такое:

m.get("f").length()

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

Рациональных аргументов в пользу своей точки зрения ты не найдешь.

Не найду. Это вопрос больше не объективности моих аргументов, а в том что не получится достучаться до человека если он уверен в обратном. Пускай так и будет

это противоречит идее статической типизации

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

И, в частности, ломало бы вот такое:

Такое и не надо, оно тяжело читается. Что за length, откуда он взялся, чей это метод? Явный каст или объявление отдельной переменной сильно улучшат читаемость и поддерживаемость этого фрагмента кода. Заодно и документируемость хочешь-не хочешь появится в виде имени переменной. Спасибо за аргумент.

специфицировать HashMap ты как будешь?

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

Не понял вопроса.

Дело не только и не столько в читаемости кода. Да и то, что идея умеет красиво сворачивать, не означает, что этот код можно назвать читаемым.

твой код позволяет делать так

    Map hm = new HashMap();
    hm.put("char", 'c');//<-а что без боксинга делать? new Character('c') писать?
    hm.put("string", "String");
    hm.put("int", 1);
    hm.put("long",2147483648L);
    hm.put("lion", new Lion("Simba"));
    hm.put("dragon", new Dragon);

вот и как ограничить тип мапа? а ведь это я только со значениями побаловался, еще ключи есть.

Половина языков программирования противоречат

Важна последовательность. Либо язык следует статической типизации, либо нет.

Что за length, откуда он взялся, чей это метод?

Так надо называть не map переменную а, например, users и тогда вопросы отпадут.

Что важно (даже можно сказать самое важное) - так это то, что формализация типов служит документацией. Я по сигнатуре метода вижу, что они там ждут, не читая мутную документацию.

приложение на scala 2.7 разумеется, так как после этого сломали коллекции, а приложение к тому времени уже было большим и в продакшене.

Приложение на jdk 1.4 разумеется, так как после этого сломали enum, а приложение к тому времени уже было большим и в продакшене.
История на каждый день.

Про боксинг у меня ответа нет. Точнее есть - надо изначально было делать объектный язык, а не смешивать. Сейчас можно какой-то упрощённый синаксис ввести, например как в Objective C сделали, хотя ничего плохого в Character.valueOf не вижу.

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

Важна последовательность. Либо язык следует статической типизации, либо нет.

Джава не следует статической типизации во многих аспектах и библиотеках. Статическая типизация это к какому-нибудь хаскелю, а мы в джаве пишем List<?> results = query(«from users where id = ?», id).list() и не жалуемся.

Так надо называть не map переменную а, например, users и тогда вопросы отпадут.

Не факт.

Что важно (даже можно сказать самое важное) - так это то, что формализация типов служит документацией. Я по сигнатуре метода вижу, что они там ждут, не читая мутную документацию.

Документацию таки лучше читать.

Точнее есть - надо изначально было делать объектный язык, а не смешивать.

А где он настолько объектный? Те же .Net'чики там чего-то наваяли, в итоге у них value types не наследуются от object, а приводятся к нему. Ну и зачем весь сыр бор, если я не могу сделать генерикову функцию для всех классов+nullable value types, опять приходится с боксингом возиться. Зато быстро и лишнюю память не жрут, о как.

Ограничивать тип мапа не надо.

Ну кому не надо, а кому без этого код не пишется.