Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Несколько мыслей о будущем Java и не только (навеяно разными недавними обсуждениями)

63
26 января 2011 года
Zorkus
2.6K / / 04.11.2006
Захотелось сделать предварительный вброс для небольшого холивара.

Недавно обсуждались темы для будущих подкастов Радио-Т, кстати сами подкасты бывают иногда интересны, могу даже порекомендовать.

И среди прочих всплыла тема о будущем Java как языка, и как платформы.
Если вкратце - что могут сделать рулевые Java, чтобы удержать ее на плаву в течении долгого времени. Вот тут обсуждение пошло в сторону того, почему в лабораториях Microsoft Research более или менее активно разрабатываются альтернативные языки для платформы .NET (такие, например, как F#), а вот Sun/Oracle с такой поддержкой альтернативным языкам отстают.

А тут я сам написал небольшой пост по этому поводу.

Да и вообще, заметна разница в позиционировании платформ. .NET изначально позиционировался как платформа для скрещивания в рантайме многих языков (для начача это были C#, VB#, managed C++), а вот у маркетологов Java такого заметно не было. Всегда шло позиционирование немного другое - Java это такой универсальный язык, который работает на платформе Java, где есть платформенно-независимый байткод, нет работы с памятью и прочего. Но вот про то, что под JVM можно разрабатывать и портировать другие языки, и писать код на них - на это особого упора, сколько я помню, никогда не делалось.

Так кто все же что думает по этому поводу? Будущее - за языками, как таковыми, в их теперешнем понимании (включая такие языки как Lisp, Nemerle, Ruby...), или все же за платформами для хостинга рантайм-сервисов, с кучей компиляторов под них (которые по сути, парсеры грамматики и генераторы байкода в том или ином виде).
5
26 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Zorkus
Да и вообще, заметна разница в позиционировании платформ. .NET изначально позиционировался как платформа для скрещивания в рантайме многих языков (для начача это были C#, VB#, managed C++)

Я всегда с недоверием относился к этой позиции. Уж слишком похожими на C# выглядели все эти VB, Delphi и прочие порты на .NET. Хотя MC++ несколько выбивается из этого ряда своей шизофренической системой типов, но зато он такой один. :D

Цитата: Zorkus
Так кто все же что думает по этому поводу? Будущее - за языками, как таковыми, в их теперешнем понимании (включая такие языки как Lisp, Nemerle, Ruby...), или все же за платформами для хостинга рантайм-сервисов, с кучей компиляторов под них (которые по сути, парсеры грамматики и генераторы байкода в том или ином виде).


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


ПС. CLR ничем принципиально не лучше JVM. Микрософт сумел в нее пачку фундаментальных ошибок засадить, основные: ковариантность массивов (привет Java!), именованные функциональные типы (делегаты), CAS и т.д.

276
26 января 2011 года
Rebbit
1.1K / / 01.08.2005
Цитата: hardcase
ковариантность массивов (привет Java!)


Ето наезд?
Java в етом плане безопасна с точностю до неконтролированого ексепшена в момент присвоение значения елементу масива.

Код:
static class A
    {
   
    }
   
    static class B extends A
    {
   
    }
   
    public static void main(String[] args)
    {
    A[] a = new B[4];
    a[0] = new B();
    a[1] = new A(); // ошибка
    }
5
26 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Rebbit
Ето наезд?
Java в етом плане безопасна с точностю до неконтролированого ексепшена в момент присвоение значения елементу масива.[/code]

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

276
26 января 2011 года
Rebbit
1.1K / / 01.08.2005
Цитата: hardcase
Кто-то недавно говорил про "проверку типов ушедшую на мороз"...


И что. Я что говорил что ето плохо? Нет. Я вообще JS обожаю за отсутствие ограничений.

Цитата: hardcase
Ковариантные мутабельные структуры данных - это дебилизм, пример, демонстрирующий это, ты сам же и привел.


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

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

5
26 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Rebbit
Делайте так чтоб было удобно, а не "правильно".


Это вопрос здравого смысла. Зачем ковариантность мутабельной структуре данных. Объясни пожалуйста и обоснуй. В моей практике я не могу вспомнить ни единого случая, когда мне потребовалось бы сделать что-то вроде:

 
Код:
string[]  x = ...;
object[] y = x;
276
26 января 2011 года
Rebbit
1.1K / / 01.08.2005
Цитата: hardcase
Это вопрос здравого смысла. Зачем ковариантность мутабельной структуре данных. Объясни пожалуйста и обоснуй. В моей практике я не могу вспомнить ни единого случая, когда мне потребовалось бы сделать что-то вроде:
 
Код:
string[]  x = ...;
object[] y = x;


Функция сортирующая масив обектов по определенному компаратору

5
26 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Rebbit
Функция сортирующая масив обектов по определенному компаратору


Отлично, в .NET есть строго типизированное решение (в классе System.Array):

 
Код:
void Sort<T>(T[] array, Comparer<T> comparer);

Comparer<T> - делегат.

Это решение работает даже со структурами, для которых ковариантность не работает. Мысль на этот счет: Микрософт бездумно скопировал нехорошее решение из Java вселенной (CLR 1.0 в сущности и была клоном JVM, генерики они тогда не успели сделать).
276
26 января 2011 года
Rebbit
1.1K / / 01.08.2005
Ну и? Всеровно в момент компиляции будет массив базового типа. Единственное чем ето безопаснее - невозможно создать инстанс Т (почти невозможно).
А у дженериков есть своя почка подводних камней. И они ой как неприятны.
5
26 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Rebbit
Всеровно в момент компиляции будет массив базового типа

Нет. Будет тип массива заданный при его создании.

Цитата: Rebbit
Единственное чем ето безопаснее - невозможно создать инстанс Т (почти невозможно).


Создать можно. Как штатно, используя ограничение new(), так и нештатно (в обоих случаях используется класс Activator). И все же запретив ковариантность массивов мы избавляем CLR от необходимости проверять тип при присваивании значений элементам массивов (и следовательно от необходимости удалять эту проверку, где не требуется, при JIT-компиляции).

Цитата: Rebbit
А у дженериков есть своя почка подводних камней. И они ой как неприятны.

Давай, выкладывай :)

276
26 января 2011 года
Rebbit
1.1K / / 01.08.2005
Цитата: hardcase
Давай, выкладывай :)


Я про .НЕТ говорить не буду так как давно его в руках не держал да и когда держал то не сильно. Но вот на примере Джави

Перегрузка методов с Т параметром в иерархии (неявное создание нового метода и неявний кол).
Да воодще при наследовании чертичто творится будет (тоесть творится то оно не будет, но ограничения будут).

63
27 января 2011 года
Zorkus
2.6K / / 04.11.2006
Что там говорить, когда только пару недель назад в рассылки разработчиков Groovy, надо думать не самых убогих Java-разработчиков, недавно был коммент в духе - "эти чертовы генерики...понял кто-нибудь до конца, как они работают в Java !?!?"
5
27 января 2011 года
hardcase
4.5K / / 09.08.2005
Цитата: Zorkus
Что там говорить, когда только пару недель назад в рассылки разработчиков Groovy, надо думать не самых убогих Java-разработчиков, недавно был коммент в духе - "эти чертовы генерики...понял кто-нибудь до конца, как они работают в Java !?!?"


А с выводом типов все гораздо веселее получается, особенно когда имеется поддержка вариантности для интерфейсов и делегатов :) Nemerle, кстати, до сих пор имеет проблемы с обработкой некоторых случаев ограничений.

87
27 января 2011 года
Kogrom
2.7K / / 02.02.2008
Есть сайт со сравнительно интересными статьями на тему Java:
http://www.skipy.ru/

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

Другие идеи о будущем, о передачах на радио...

Возможно, надо следить за блогами авторов типа Кента Бека и Мартина Фаулера, т.е. за мыслителями, которые пропагандируют и Java. Первый - известный любитель SmallTalk, многое оттуда пытался перенести в Java, например, JUnit. Можно найти его рассуждения на счёт современных IDE для этого языка и проследить, что оттуда перенесено (будет перенесено) в IDE для Java. Второй пишет про Ruby (JRuby) и DSL. Где-то была его статья Groovy or JRuby (я её не осилил, но может пригодиться для передач).

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог