Нужен ли нам Java++?

Ответ 1

Идти, чтобы получить downvoted фанатами Java для этого, но как кто-то, кто пишет как Java, так и С#, я бы сказал, что С# близок к Java++, как вы собираетесь получить.

От C до С++ был сдвиг парадигмы, от процедурного к объектно-ориентированному, единственная причина, по которой они сохраняют имя, - это заставить программистов C думать, что это был тот же самый язык, который привел к загрузке действительно плохого кода C, маскирующегося под С++.

Java постоянно расширяется, и Sun быстро включает все больше и больше функций, поэтому вполне возможно, что Java 7 или 8 - это ваш Java++

Ответ 2

Как, скажем, Scala или еще лучше Groovy, который выставляет себя как динамическую версию java?

Ответ 3

Я думаю, что ответ на вопрос: "Нужен ли нам Java++?" зависит от того, кто "мы" (и я не уверен, что "мы" - это все экземпляры одного класса;-). Этот вопрос обсуждался не один раз Java Posse.

Крупные корпоративные пользователи Java имеют тенденцию быть более консервативными. Они имеют большой штат развития и крупные органы существующего кода. Как следствие, существует высокая воспринимаемая стоимость и риск изменения языка или библиотек (обучение, обслуживание, поломка существующего кода и т.д.).

С другой стороны, существует множество небольших команд с подсветкой на ногах (с открытым исходным кодом или иначе), которые всегда готовы зацепиться за Программу Next Great Idea. Мне непонятно, что один ответ оставит всех удовлетворенными.

Я предлагаю, чтобы растущая экосистема языков на основе JVM могла помочь устранить эту напряженность. Если более новые языки (Scala, Fan, JRuby, JavaFxScript и т.д.) Предоставляют нотные функции (и новизну), которые желает вторая группа, сохраняя совместимость с существующей Java (которая может двигаться более спокойным образом), возможно, оба группы могут иметь свой выбранный аромат торта.

Я немного озадачен степенью, в которой некоторые люди, кажется, хотят One True Language. В тот же день было довольно распространено мнение о том, что каждый язык (обозначение) имеет "сладкое пятно" применимости; иногда правильным решением было написать каждую часть системы на соответствующем языке и связать их вместе.

Назад в будущее, кто-нибудь?

Ответ 4

Вопрос в том, как вы решаете, что происходит на "следующем языке". Простое добавление/удаление элементов по частям приведет к кучке дерьма. Гораздо лучше подумать о том, как добавление или удаление этих функций (часто работающих в комбинации) меняет способ программирования в соответствии с новыми принципами. Например, я думал, что было интересно, что предложения о закрытии Java по-прежнему страдают от необходимости иметь дело со статической типизацией без вывода типа богатого типа. Имеются обширные примеры динамических языков с хорошими замыканиями - они хорошо сочетаются. И Scala и другие языки показали, что статическая типизация плюс вывод на основе богатого типа также могут сделать закрытие довольно красивым. Я хочу сказать, что использование языка X и создание языка X ++, вероятно, не так интересно. Интереснее видеть проблемы в X и сделать новый язык Y.

Конечно, ничто не мешает вам разворачивать Java сейчас и превращать ее в то, что вы хотите (до тех пор, пока вы не называете ее Java или хотите передать тестовый пакет). Как уже упоминалось выше, уже существует набор захватывающих высококачественных языков, которые делают именно это и поддерживают совместимость с Java. Я думаю в первую очередь о Groovy, Scala, Clojure, а Fan и меньше портов предыдущих языков для JVM, таких как JRuby, Jython и Rhino, которые, как правило, имеют более сложное время для реализации чистой интеграции Java.

Весьма вероятно, что JSR 292 показывает, входящий в JVM в Java 7 обеспечит еще более богатую площадку для развития языка на уже превосходной базе JVM. И CLR + DLR также вызывают множество интересных границ.

Все больше и больше, я думаю, что будущее будет направлено на выбор правильного языка для работы. Это произойдет либо на языках со смешанной традицией (Scala является хорошим примером FP ​​/OO, например), либо в виртуальных машинах (JVM, CLR, BEAM, Parrot, что угодно), которые способствуют чистой интеграции между несколькими языками. Или, скорее всего, оба. Я думаю, что мы НЕ стремимся к любому следующему большому языку, который является производным от Java (или чего-то еще).

Ответ 5

В настоящее время в Java существуют обходные пути для многих из них, что затрудняет введение более естественных способов выполнения этих действий.

• Функции первого класса, делегаты.

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

0,4. Структурирует как типы значений, отличные от классов, например С# и D.

Я согласен с этим.

0,5. Свойства.

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

0,6. Возможность игнорировать проверенные исключения.

Вы можете сделать это сейчас, но это взломать. Примечание: проверенные исключения - это функция времени компиляции.

Я довольно скептически отношусь к тому, что это действительно хорошая идея, если люди действительно не понимают исключения. Часто люди, которые предлагают это, не любят заставлять думать об условиях ошибки, документировать или обрабатывать их.

0,7. Возможность объявлять более одного класса в файле.

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

0,8. Более мощные встроенные массивы, которые позволяют такие вещи, как добавление.

См. Commons ArrayUtils. Массив, который имеет правильную команду toString(), будет запущен.

0,9. Лучшие дженерики/реальные шаблоны.

Я согласен, в зависимости от того, что вы имеете в виду. Я думаю, что они должны сначала использовать текущую имплиментацию, прежде чем улучшать ее. например Поэтому API-интерфейсы Java могут быть скомпилированы без предупреждений.

0,10. Что-то вроде динамического ключевого слова для С# 4.0, которое позволяет печатать на утине, когда это необходимо, в общем статическом языке.

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

0,11. Поскольку Java - это прежде всего язык VM, возможно, некоторые хардкорные функции метапрограммирования, такие как генерация кода "на лету" для определенных вещей.

Как JavaCompiler (в java 6), поддержка сценариев (в java 6), JCI или BeanShell.

Ответ 6

Если вы собираетесь внести большие изменения, не хотите ли вы начать заново? Там много вещей, которые можно было бы сделать с исправлением/удалением на Java. Вы не можете рассматривать функции индивидуально - они взаимодействуют неожиданными способами. Большой и сложный язык, вероятно, плохой язык (см. С++).

Ответ 7

Java++ уже здесь...: D

Ответ 8

Эти вещи в основном пух.

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

Ответ 9

Большинство функций уже существует.

Этот язык:

_{(источник: codehaus.org)}

знак равно

Что касается:

Возможность объявить более одного класса в файле.

Он присутствует в Java с самого начала.

Ответ 10

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

На мой взгляд, незначительные корректировки синтаксиса не оправдывают оптовый переход на новый язык, особенно если это означает выбросить большие инвестиции на платформы, базы кода и навыки разработчиков.

Небольшие изменения могут быть добавлены на язык Java с течением времени (в Java 7, 8, 9...), если есть достаточный спрос. Однако существует реальный вопрос о том, оправданы ли они, поскольку такое изменение делает язык более сложным и, следовательно, сложнее изучать и поддерживать базы кода, поскольку разные разработчики начинают использовать другой поднабор функций.

Возьмем, к примеру, С++: теоретически это удивительный язык, позволяющий вам программировать на любом возможном уровне абстракции, сохраняя при этом производительность машинного кода в оптимизированном коде. На практике сложность всей этой языковой функциональности означает, что очень немногие смертные могут надеяться понять, что на самом деле происходит, а большие базы кода становятся почти недостижимыми.

На мой взгляд, единственными изменениями, которые оправдывали бы оптовую "Java++", были бы фундаментальные сдвиги парадигмы, которые меняют способ разработки программного обеспечения к лучшему. Основные изменения, которые сделали Java успешной (более С++ и т.д. В 1995-2000 годах), были на мой взгляд:

• Выполнение байт-кода в переносной, стандартной межплатформенной среде выполнения (JVM/JRE) без необходимости перекомпиляции
• Большая, надежная библиотека стандартных классов (включая потоки, сети, графический интерфейс и т.д.) - то есть признание того, что платформа намного больше, чем просто язык
• Сбор мусора, сделанный обязательным

Примерами следующего этапа фундаментальных сдвигов были бы:

• Отбросить ориентацию объекта в пользу функционального программирования
• Устранить блокировку в пользу Программной транзакционной памяти, чтобы обеспечить высокую производительность, потокобезопасную concurrency для массивно-многоядерных архитектур
• Замените изменяемые переменные неизменяемые значения на всех языках и библиотеках классов (чтобы можно было рассуждать о параллельном состоянии)
• Выполнять метапрограммирование макросов компиляции времени в виде общего решения любого желания добавить новый синтаксис в langauge или создать DSL

О да, и есть язык JVM, который делает все это - Clojure

Ответ 11

Не будет ли такое усилие Sun просто называться Java 7 (или 1.7 или 2.0)? Разве такое усилие какого-либо другого человека/группы не будет называться чем-то другим, кроме Java?

Ответ 12

Если вы добавите поддержку этих структур в JVM (при необходимости, например, закрытие), а затем создайте необходимый синтаксический сахар на письменном языке и компиляторе. Конечно, если вы хотите сохранить обратную совместимость, тогда у вас есть проектные решения, поэтому Java Generics не так хороши, как могли бы быть. Вы бы хотели освободиться от этого, чтобы получить более совершенную Java, я думаю, но спрос будет очень низким, поскольку совместимость там, где она находится.

И 7 можно сразу поехать. Мы не работаем с файловыми ограничениями FAT12 на дискете.

Ответ 13

Поскольку java становится открытым исходным кодом, вы можете взять исходный код (если он доступен) и создать собственную версию java. Если это становится широкомасштабным принятием, тогда здорово, если нет, то это может быть не набор необходимых функций.

Ответ 14

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

Многие программисты просто ленивы и не хотят изучать новые вещи. Они скорее придерживаются одного языка, который они использовали в течение последних 10 лет.

Если вам нужна скорость и больший контроль над аппаратными средствами, можно использовать что-то вроде C. Если вам нужны задачи системного администрирования, вы probabely в конечном итоге с помощью скриптов оболочки или языка сценариев, как Perl, Python или Ruby. Если вы делаете много математического материала, Matlab - хороший выбор. И т.д. стр.

Используйте лучший инструмент для задачи, независимо от того, какой язык он может быть. Хороший программист должен иметь возможность работать с любым языком (что касается меня, я все еще работаю над этим).

Ответ 15

Предлагаю взглянуть на Beyond Java.

Там хороший обзор на Joel on Software.

Ответ 16

Ознакомьтесь с информацией, доступной на Java 7. Я думаю, вы обнаружите, что планируется добавить несколько функций, которые все запрашивают, особенно закрытие.

Ответ 17

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

В принципе, вы можете написать свой собственный javac, который работает для этого, и использует существующую Hotspot JRE. Однако вы действительно не можете сделать это без помощи Солнца.

Проблема действительно двоякая: 1) подход Sun заключается в поддержке "платформы Java" и устойчив к новому стандарту, даже надмножеству и 2), чтобы получить какие-либо изменения на Java, вы должны получить выпущенный JSR - - и это обычно требует корпоративных спонсоров. У корпораций есть другие приоритеты.

И снова я хотел бы настоятельно призвать вас к этому. В конце концов, до 2007 года многие умные люди почти переделали Java с нуля = путь к GNU classpath. Таким образом, существует необходимый талант для "второго первоклассного JVM-языка".

Ответ 18

Насколько я чувствую, что Java устарела, правда в том, что мы все знаем, что в качестве языка она все еще работает очень хорошо. Конечно, многие новые вещи, которые мы можем найти на других языках, не существуют, но они все еще работают! Вы все еще можете делать все, это просто занимает больше времени и требует больше работы. Я определенно с нетерпением жду того дня, когда он завершился, но я просто думаю, что со всем существующим кодом и приложениями, написанными на Java, в данный момент просто нет способа (почти) никто не сделает переход на Java++. Я думаю, что мы ждем реального сдвига парадигмы, например, С++ для C. Возможно, функциональное программирование может стать следующей большой вещью, а Scala станет следующей Java.

Ответ 19

С++ является объектно-ориентированным C. Java уже ориентирована на объекты, поэтому как бы мы перешли к другому сдвигу парадигмы, сделав его Java++?

В некотором смысле, я думаю, что это наоборот. Java опережает С++. Java имеет библиотеки и фреймворки высокого уровня, тогда как С++ очень часто все еще является низкоуровневым и смешивается с ansi C (потому что мы можем).

Java имеет хорошие возможности для объединения и большие сообщества, которые все направлены в одном направлении.

Наличие более "функций" не улучшает язык. Я думаю, что это возможно сделать хуже.

В конце концов, поставить один язык "перед" другим не поможет. Выберите лучший инструмент для задания. Я думаю, что Java как язык довольно хорошо, как есть. С++, однако, может использовать некоторые более совершенные библиотеки, например порт Spring.