Нужна ли Java для перезагрузки?
Яве сейчас почти 14 лет, и возраст начинает показывать. В моей индустрии (банковском деле) мы шутим, что Ява - это Кобол 21-го века; за исключением того, что это не большая шутка, это печальная реальность.
У Java много "багажа", который сохраняется для обратной совместимости - именно тот тип вещей, который важен для таких клиентов, как банки. Но я часто думаю, что пришло время перезагрузки. Просто прочитайте "Java Puzzlers", чтобы найти список болевых точек в дизайне языка. Я не виню дизайнеров языка - за последние 14 лет было извлечено много уроков! Тем не менее, мне бы очень хотелось, чтобы произошли некоторые серьезные изменения, которые, к счастью, сломают обратную совместимость, делая язык намного лучше.
Вот (очень частичный) список вещей, которые я бы изменил на языке:
- Отбросьте все устаревшие предметы. Пора Thread.stop и друзья, например, умрут.
- Запретить перегрузку. Это было ошибкой. (Я знаю, что это немного противоречиво, и все же...)
- Конструкторы должны быть только частными. Статические методы должны использоваться как фабричные методы для получения экземпляров. Это учитывает главные и важные оптимизации. (Опять же, противоречиво, но академическое сообщество, похоже, согласится. См. Также пункт 1 в Эффективной Java.)
- Офигительные / неправильно спроектированные части API. В частности, исправьте класс Date.
- Брось "доработать".
- Отбросьте поддержку "сырых" вариантов родовых классов. Больше не надо
List; должно бытьList<Something>, - Свойства. И никаких непубличных полей, пока вы на нем.
- Обеспечить реализацию по умолчанию "equals", которая перебирает поля и вызывает их "equals"; разрешить некоторую аннотацию ("@NonState") для пометки полей, которые не являются частью теста на равенство.
- "==" должен вызывать equals(); добавьте новый оператор "is" для идентификации.
- Удалить "клон" из объекта; только объекты, которые реализуют Cloneable, должны иметь этот метод.
- Разрешить специальную аннотацию для тестовых классов; тестовые классы должны иметь доступ к закрытым членам всех классов в одном пакете.
- Хорошо используйте Enums в библиотеке - конечно, многие старые классы вместо этого используют int-константы.
- Удалить "Thread.run"; Thread.start должен принимать объект Runnable (вы будете поражены количеством ошибок, которые я видел, когда вызывается Thread.run вместо Thread.start).
Это только в макушке моей головы... Итак, я хотел бы услышать:
- Согласны ли вы, что перезагрузка Java (новая версия, нарушающая совместимость со старым кодом) будет хорошей вещью?
- Каковы ваши любимые мозоли, вещи, которые, по вашему мнению, нуждаются в исправлении на языке? Мои собственные примеры были сосредоточены на элементах, нарушающих совместимость - вещи, которые вы просто не можете сделать в текущей Java, не нарушая существующий код. Но другие идеи также приветствуются.
Уточнение: я не ищу новый язык (например, Scala или C#). Я ищу что-то, что явно является Java - но требует определенных усилий для переноса существующего кода. Обратите внимание, что для многих предложенных изменений код может быть перенесен автоматически или полуавтоматически. Я знаю, что банки не примут его в ближайшее время (эй, я там работаю), но я также знаю, что банки часто запускают новые проекты и хотели бы воспользоваться знаниями существующих программистов, наслаждаясь лучшим языком.
Всем, кто утверждает, что по многим моим предложениям команда может просто применять свои собственные правила (например, не перегружать): достаточно верно, но мы сильно зависим от стороннего кода. Не все?
14 ответов
Я не думаю, что языки когда-либо получат такой экстремальный облик, особенно такой, который не нарушит обратную совместимость миллионами разных способов, как ваши предложения. Вместо этого вы получаете новый язык.
Что ж, я должен сказать, что независимо от того, хотели бы согласиться фанаты C#, Scala или Groovy, я думаю, что некоторые из предложений здесь совершенно глупы.
1) Тот, кто совершает ошибку, вызывая Thread.run вместо Thread.start, НЕ должен программировать. Здесь виноват не программист, а язык.
2) Запретить перегрузку? Почему, с какой стати ты это сделал? Опять же это не имеет смысла, какие проблемы это вызывает? Я считаю перегрузку очень очень полезной в любом количестве сценариев.
3) В чем реальная разница между фабричными методами и конструкторами. Вот что такое конструкторы, это фабричные методы, которые создают экземпляры объекта. Если вы хотите или предпочитаете заводские методы, то ИХ РЕАЛИЗУЙ... не сложно
4) == вызывая equals(), перегрузка операторов является одной из худших идей, когда-либо возникающих в области объектной ориентации. Вы понимаете, как сложные программы на C++ могут стать массивом перегруженных операторов. Это не очевидно, и требует трудоемкого анализа.
5) Java полностью умрет, если устаревшие методы будут удалены. Почему бы просто не игнорировать их? Каждый язык движется в этом направлении, ни один язык не идеален, и ошибки могут быть исключены только в том случае, если разработчики продолжат работу над ним и обновят его.
Хотя некоторые из ваших комментариев имеют смысл, я нахожу, что неопытность склоняет людей к тому, чтобы руководствоваться принципами и идеалами, и с опытом вы понимаете, что прагматизм - вот что важно. Почему делает Java идеальным, что важно, а не то, что вы можете с ним сделать. Я вижу замыкания, расширенные дженерики и свойства в качестве единственного необходимого фундаментального улучшения.
Ява не игрушка для отдыха, она здесь и популярна, потому что бизнес опирается на нее и полагается на нее.
Есть больше людей, работающих над тем, чтобы выжать из Java, чем большинство других языков. Вы можете сосредоточиться на плохих вещах, и J2EE был печальной частью жизни языка.
Java-код, который я пишу сегодня, не имеет ничего общего с Java-кодом, который я написал 5 лет назад. Я не верю, что использую одну библиотеку, которую использовал 5 лет назад. Перезагрузка произошла.
И хотя я также программист на C#, я думаю, что очень важно двигаться медленно. Просто безумное добавление функций - не обязательно хорошая вещь.
Я не знаю, видели ли вы Scala, новый язык, созданный одним из первоначальных авторов Java, который работает на JVM.
Языки очень редко получают вид "перезагрузки", который вы описываете, обычно вы просто получаете новые языки. VB - единственное исключение, о котором я могу думать.
Разрушение устаревшего кода даст крупным предприятиям только повод рассмотреть другие платформы. Эра C 1970-х годов все еще компилируется в современных компиляторах... хотя некоторые функции могут быть помечены как устаревшие (что является лучшим решением, IMO). Я был бы в ярости, если бы большие части корпоративного приложения просто не скомпилировались, потому что моя команда обновилась до более новой версии Java.
Запретить перегрузку. Это было ошибкой. (Я знаю, что это немного противоречиво, и все же...)
Не использовать перегрузку - это большая ошибка IMO, которая приводит к уменьшению объема поддерживаемого кода. Например, взгляните на эту страницу из OpenGL API. (Язык C, без перегрузки) glColor
Хорошо используйте Enums в библиотеке - конечно, многие старые классы вместо этого используют int-константы.
Что-то сломано из-за констант int?
Не обижайся, но этот и большинство твоих высказываний звучат лишь навязчиво навязчиво вместо практического использования времени кодирования. Хороший разработчик уже может обойти эти вещи или воздержаться от использования функции, которая не считается хорошей. Также, если библиотека уже работает, нет смысла менять ее просто на "использование перечислений" и т. Д. Удалять хороший отлаженный код - огромная трата.
Рассматривая "перезагрузки", вот ссылка на текст Joel of Software о переписываниях с нуля. Не на 100% релевантно, но все равно немного:) Вещи, которые вы никогда не должны делать, часть I
Большая часть того, что вы просите, - это изменение API вместо самого языка. Вы всегда можете создать свою собственную библиотеку базовых классов и начать с нее, если вас не устраивает текущая библиотека.
Вместо того, чтобы говорить вам об этом, но вы всегда можете искать альтернативы, прежде чем пытаться исправить текущие проблемы, есть также.NET, которая имеет множество функций того, о чем вы просите.
Я согласен, что критическая редакция - хорошая идея. Из вашего списка мне особенно нравятся свойства - возможно, аналогичные реализации C#. Огромное количество шаблонов "получить / установить" ошеломляет, и нет никаких причин для этого.
Согласны ли вы, что перезагрузка Java (новая версия, нарушающая совместимость со старым кодом) будет хорошей вещью?
Нет, по крайней мере, без пути миграции. Оставлять своих клиентов в море - действительно плохая идея. Важное значение имеет их информирование (особенно об устаревании и о том, что это значит) и побуждение их перейти к новым методам (например, предлагая кодовые клиники). Другой пример (возможно, более эффективный) - продолжать поддерживать унаследованный код с помощью контракта на обслуживание (что, по-моему, Sun все равно делал).
Каковы ваши любимые мозоли, вещи, которые, по вашему мнению, нуждаются в исправлении на языке? Мои собственные примеры были сосредоточены на элементах, нарушающих совместимость - вещи, которые вы просто не можете сделать в текущей Java, не нарушая существующий код. Но другие идеи также приветствуются.
Стив Йегге однажды назвал Яву "царством существительных", и я должен согласиться с ним. Я понимаю причину этого, но с годами необходимость вызывать "сеттеры" и "геттеры" и тому подобное делала код громоздким и шумным. Я также думаю, что литералы для списков, карт, регулярных выражений и XML давно назрели. Все может быть намного более громоздким -Java можно было бы развернуть без строковых литералов. Подумайте, на что это будет похоже.
Я не верю, что язык нуждается в новых конструкциях, таких как замыкания. Некоторые утверждают, что в Java это уже есть с анонимными внутренними классами. Это "существительные" замыкания. Было бы лучше, если бы платформа Java (JVM) была исправлена так, чтобы другие языки, работающие на ней, могли двигаться в этом направлении.
Я не думаю, что Java должна (и не будет) перезагружаться. У каждого языка есть свои проблемы, и теперь, когда Java достаточно развит, чтобы его проблемы были хорошо известны (и хорошие разработчики могут их учитывать), язык должен быть изменен?? Ни за что.
Конечно, новый язык, основанный на уроках Java, может быть запущен. На самом деле это уже здесь, его зовут C#. Жаль, что на практике это проприетарный продукт MS.
Банки обычно не заинтересованы в передовых технологиях. Банку нужны зрелые, стабильные технологии с проверенной репутацией. Популярные языки, которые используются всего несколько лет назад, используются очень редко, поэтому, изобретая новый, вы увидите, что он будет использоваться в банковской сфере, пока он не станет круглым и в нем будет примерно такой же багаж.
Большинство головоломок Java уже давно используются в языках программирования и до сих пор существуют в новых языках. Это головоломки программирования, написанные на Java.
Я думаю, что большинство людей не согласятся с большинством ваших мнений, даже с теми, с которыми я согласен. Это проблема с запуском нового языка.
Яве сейчас почти 14 лет, и возраст начинает показывать.
Это просто язык. Если вы внесли все изменения, которые вы предлагаете, я не верю, что это сработает - java потребовалось 5 лет, чтобы найти свое место, и "перезагрузка" вызовет проблемы с обратной вычислимостью.
Это может показаться не слишком серьезной проблемой, но это означает, что во многих компаниях затраты на перенастройку во всем мире составляют миллиарды долларов.
Кроме того, у вас будет возможность запустить старую и более новую версии на одних и тех же серверах с интересными результатами или сложными конфигурациями.
Эти проблемы мешают вам делать то, что вам нужно сделать? Тогда не беспокойся об этом.
Хранители Java знают, что если они не будут обновлять его, люди со временем перейдут на один из более новых языков, и они изменят его для адаптации.
Но имейте в виду, что хорошо, когда старые языки умирают, а новые языки достигают совершеннолетия. Не всегда лучше поддерживать язык в активном использовании и развитии по мере изменения компьютеров или реанимировать его с помощью какого-нибудь обратно совместимого ломающего, но омолаживающего зелья.
-Адам
Большинство элементов, которые вы упомянули, легко контролируются разработчиком, что я считаю хорошим.
Мы можем пройти полный список, но я думаю, что первые пункты подойдут.
Отбросьте все устаревшие предметы. Пора Thread.stop и друзья, например, умрут.
Просто не используйте их.
Запретить перегрузку. Это было ошибкой. (Я знаю, что это немного противоречиво, и все же...)
Не перегружайте
Конструкторы должны быть только частными. Статические методы должны использоваться как заводские....
Сделайте все ваши конструкторы частными.
И т. Д.
Хорошим моментом является то, что у большинства из вас есть выбор принудительно применять все эти элементы внутри себя (с каждой командой разработчиков), а не менять весь язык и не прерывать его.
Я думаю, что хорошее обновление необходимо, но по разным причинам, ни одна из которых не находится в вашем списке (например, замыкания).
Вероятно, не изменяя язык Java, но поддерживая все новые и новые языки, такие как Groovy, Ruby, Python ( JRuby или XRuby, Jython и т. Д.) И улучшая JVM каждый раз.
Я чрезвычайно доволен тем, что обновил устаревшую систему веб-приложений и увеличил производительность только за счет изменения JRE с Java 1.2 на 1.3 и 1.4.
Я оторвался от Явы 12 лет назад. 12! В то время я не был согласен с приближающимся изменением J2EE.
Мне нравятся многие концепции языка, но он не помогает поддерживать Sun (гадость), и его нужно в основном перестраивать с нуля.
Что-то новое, "как Java".
И, в моем (маленьком) сообществе, все разработчики Java, к сожалению, называются "динозаврами", поскольку они ведут себя так, как это делали разработчики на языке COBOL… погруженные в свой мир, не подозревая, что что-то происходит, в основном без них.