Bruce Eckel, The State of The Java Union
Материал из eSyr's wiki.
Содержание |
Open-Space style events
Новый способ проведения научных встреч и конференций, получающий распространение в Java сообществе. Основная идея — отсутствие деления «лектор-аудитория», когда один о чем-то рассказывает многим достаточно долгое время, в официальной обстановке и практически без обратной связи. Такой способ изжил себя, потому что то же самое фактически можно организовать и без личного присутствия, например посредством записи лекции и распространения её в интернете. Популярность приобретают способы организации общения, при котором все являются активными участниками, каждый делится информацией и каждый узнает что-то новое. Пример подобной организации: все приходят в комнату, на стенках повешены листы бумаги, на листе можно написать какую-либо тему, и все кому эта тема интересна собираются рядом и делятся мнениями. Или другой способ — каждый участник должен сказать что-то по интересующему его вопросу ровно за 5 минут. У этого способа есть два преимущества — если тема скучная, то слушать её надо только 5 минут, а если тема интересная — то от такого сжатого изложения она становится ещё интересней.
Прошедшая конференция
Generics в Java не полностью оправдывают своё название. То что в ней на данный момент реализовано скорее можно назвать overcasting. Раньше БЭ думал, что он один так считает, но на недавней конферении выяснилось что таких людей достаточно много.
Opensourcing of Java было защитной мерой, против действий IBM по созданию аналогичного опенсорсного проекта.
С большим энтузиазмом на недавней конференции обсуждалась идея реализации трансляторов с различных языков на JVM. Например, для python и ruby. IBM выделило деньги и наняло разработчиков Ruby для создания транслятора Ruby → JVM.Развивается поддержка трансляции в byte-code для динамических языков программирования.
Официальной темой конференции было Java on server. Сейчас в основном Java используется именно на серверах. Но обсуждалось и много неофициального. Надо признать, что позиции Java на десктопах не очень сильны. SUN пытается что-то с этим сделать, но пока явных результатов нет .Сказываются принятые ранее решения.
Также обсуждались слабые места современной Java.
Например, нет до сих пор такой простой вещи, как поддержка USB. А ведь если уж можем запускать программу где угодно, хотелось бы что бы и с железом проблем переносимости не было.
Обсуждалось введение в язык closure. По мнению Брюса, собственно в Java они будут полноценно включены вряд ли, скорее на JVM будет запускаться какой-нибудь из языков, в котором они уже есть. Например, очень интересен язык SCALA. Он был разработан человеком, участвовавшим в создании компилятора Java 5. SCALA — по мнению БЭ — язык нового поколения, который очень вероятно станет первым представителем направления из ему подобных. Ещё один интересный язык, который БЭ вспомнил в связи с SCALA, — NICE (разработчик один француз, правда сейчас он куда-то исчез — может быть, на работу наняли)
Кусок про то как удобны надстройки (видимо компиляторы других языков в байткод) над jvm. Ранее узкие места переписывались на С, С++. <...> При компиляции в байткод то что было написано на изначально медленных динамических и/или функциональных языках неплохо оптимизируется. Так же теперь вместо переписывания библиотек, можно будет просто писать bridges позволяющие использовать библиотеки напрямую.
Распараллеливание. В последних версиях распараллеливание намного улучшилось. Появилась поддержка работы с кэшем при распараллеливании. Стало понятно, что те подходы, которые применялись раньше в этой области были не совсем верными и приводили к появлению редко проявляющихся и очень трудноуловимых багов. Но в последнее время появились свежие идеи в этой области, которые позволили значительно улучшить ситуацию. О них можно почитать в «Java concurrency in practice». Параллелизм весьма сложная вещь. БЭ неоднократно казалось, что вот вроде бы все он понимает, и вдруг выяснялось что на самом деле все не так (Это вообще часто случается в CS). В общем счёте он занимался этой проблемой 2,5 года(правда, не непрерывно, но если сложить время которое занимался — получится 2,5 года). Он может сказать, что является экспертом в этой области. Но не может сказать что однозначно до конца её понимает. Вообще параллелизм — весьма насущная проблема. Уже сейчас на большинстве десктопов 2 ядра, а в недалеком будущем будет по 8. И это нельзя игнорировать — на одном ядре и на двух поведение программы может быть совершенно различно. На 2 могут появляться неожиданные баги, невозможные на одном (в оригинале — которые невозможно отловить запуская программу на одном ядре/проце). Но при этом людей, действительно разбирающихся в распараллеливании в мире можно пересчитать по пальцам. Про параллельную программу невозможно доказать её правильность — только показать неправильность. Появляется вопрос — как же дать возможностям людям писать распараллеливающиеся приложения не затрачивая при этом чуть ли не всю жизнь на то что бы разобраться в этой непростой области. В SCALA для решения этой проблемы введена концепция Active Object (Actor, АО). В обычной модели ООП объекты пассивны. Мы можем вызвать их методы, но сами они ничего делать не начинают. В отличие от них каждому AO сопоставлена своя нить (thread).
При вызове метода объект не начинает сразу его выполнять, а помещает вызов в свою внутреннюю очередь, которую выполняет строго последовательно(пока предыдущий метод не завершится новый из очереди не берётся). Такой подход несколько ограничивает параллелизм, но позволяет избежать очень многих ошибок и потому оправдывает себя. В SCALA концепция АО поддерживается на уровне языка. Так же там то ли собираются реализовать, то ли реализовали, но ещё не полностью агентов (agent) — дальнейшую эволюцию идеи АО, в которой объекты могут перемещаться между физическими потоками — например, ездить с машины на машину, с процессора на процессор. Пример, где такой подход очень выгоден: Однажды БЭ пригласили в качестве консультанта в проект, основной целью которого было моделирование перемещения людей по городу и между городами. Причём модель была очень низкоуровневая и подробная, и требовала большого количества вычислений. БЭ просили дать рекомендаии по её распараллеливанию. Эта задача — одна из тех, к которым естественно и удобно применить концепцию агентов. Также SCALA поддерживает многое от функциональной парадигмы. Более подробно об этом можно прочитать в книге "SCALA by example". Из фич можно назвать, помимо прочего:
- замыкания
- functions as first class-objects
- поддержку кортежей (tuples) в языке
- хороший pattern matching
- component support (причём на более высоком уровне абстракции, чем java beans).
Синтаксис. Синтаксис имеет значение! То что в Java программы объёмные – не есть хорошо. Многие говорят, что это не проблема, потому что всяческие IDE позволяют быстро набирать код даже на Java, но ведь программы чаще читают, чем пишут, поэтому о читабельности тоже надо заботиться, а огромная по размерам программа не читабельна.
В отличие от с#. в java нет abstract mechanism for events.
Последняя конференция оставила многих в ужасе. На ней была сделана попытка честно оценить проблемы Java.
Должен ли java script соревноваться с флэшем или скорее интегрироваться с ним?
В последенее врмя крупные заказчики все больше склоняются в сторону использования flash на своих сайтах – оно красивое и легко в устновке. Да, в ajax можно сделать некоторые оригинальные интересные вещи, но у jscript есть свои проблемы:
- под разные браузеры надо фактически писать разный код, от чего программеры с криками ужаса разбегаются.
- инсталляция jvm сложнее инсталляции flash media player. Для продвинутых пользователей это возможно не имеет значения, но для большинства — весьма актуально. К примеру отец БЭ flash media player поставил сам, даже толком не зная, что это такое, а вот с jvm возникли сложности(например, непонятно какую версию устанавливать, итп). Проблема упрощения процесса инсталляции серьёзно обсуждается.
В итоге на появившейся вопрос — должен ли jscript конкурировать с flash или интегрироваться? С точки зрения БЭ ответом будет скорее второе, потому что первое слабо реализуемо на практике. Обещают, что следующая версия jscript будет много лучше, но это только обещания.
How to move OS forward
К примеру, было обнаружено, что хардварная реализация трансцендентных математических функций не всегда соответствует стандарт IEEE (в последних знаках иногда возникает погрешность), и было принято решение реализовывать все такие функции программно. Это обеспечило идентичность работы программ в любой среде, но очень сильно замедлило выполнение. Причем отключить эту функциональность весьма сложно. Это можно пофиксить, но это весьма сложно. К тому же этому противодействуют некоторые организации. Тем не менее, проблему надо решать. Для этого возможно придется создавать какие-нибудь фонды, организации.
Q&A
Q: Возможно ли проводить openspace конференции в России?
A: Да, конечно, но поначалу это не просто, так как надо приучить людей к мысли что можно собраться и для этого нет необходимости в организационном комитете или чем-то подобном. Когда БЭ начинал делать подобные конференции, то собрать людей вместе у него получилось далеко не сразу. Зато, после того как такие конференции всё-таки проходят участники заявляют, что это были лучшие конференции из всех, в которых им доводилось участвовать.
Q: Когда появятся реализации других языков на jvm умрет ли с++?
A: Область применения с++ будет постепенно сужаться. Это вообще естественный процесс для языков программирования. До сих пор есть люди пишущие на коболе. There are people programming in FORTRAN out there.
Вы интересуетесь потому что хотите узнать что лучше учить? Учить надо в любом случае несколько языков. С каждым новым выученным языком начинаешь видеть новые приёмы в тех языках, которые знал раньше. Надо знать как минимум два языка программирования. На конференции меня много спрашивали — стоит ли использовать тот или иной специфический инструмент. На самом деле ответ на все подобные вопросы — It depends. Вполне возможно существуют задачи, которые оптимально решать на VB. Правда знать только VB — это мрак. БЭ много видел людей с зашоренным, узким мышлением, и ничего хорошего в этом нет.
Q: Что Вы думаете о WEB 2.0 и об идее контента пополняемого пользователями?
А: Википедия — это, безусловно, отличная вещь, хотя её и становится всё труднее защищать от вандализма и предвзятости, и необходимость такой защиты накладывает некоторые ограничения на свободу модификации информации. Но всё же у пользователей должна быть какая-нибудь мотивация, иначе качество их работы будет оставлять желать лучшего — пример tagging.
Q: Почему люди пишут опенсорс?
А: Потому что получают выгоду, но не денежно-материальную, а эмоциональную, сродни удовольствию от участия в многопользовательской on-line игре.
Q: Что Вы думаете о изучении Java как первого языка программирования?
A: Java — плохой первый язык. Как и C++. Чтобы написать на Java Hello world, надо объяснить void, public, class, static… Поэтому увлекает не сразу. У того же Python более gentle learning curve. Но у Python другая проблема. К примеру, какие-то знакомые БЭ начали изучать Python, но вскоре им под руку подвернулся VB и они увлеклись им, потому что начинающим всегда хочется видеть как что-то меняется на экране, картинку. Но если сравнивать Java и C++, то даже C++ лучше как первый язык — hello world написать проще.
Q: При написании транслятора C → JVM не возникнут ли слишком большие сложности из-за больших различий в дизайне, и не придётся ли изменять JVM для поддержки трансляторов с других языков?
A: Да, это проблема. Но она не столь критична. Сейчас пишутся трансляторы для языков типа SCALA и с ними таких проблем не возникает. Но ваш скептицизм понятен. Возможно, именно эту задачу удастся решить благодаря открытию исходного кода JVM.
