Я натолкнулся на сравнение языков (которое я хотел бы найти), где автор представил пример кода на разных языках. В качестве примера он выбрал вычисление дайджеста строки MD5. Он показал подробную версию Java, немного Python и т. Д. Наконец php:
md5("Hello World");
Этот пример, утверждал автор, показал, что PHP- кодеры могут сделать с одной строкой столько же, сколько Java-кодер может сделать за 20. Конечно, любая проблема проста на любом языке, если есть доступный вызов библиотеки, который является правильным.
Когда мне нужно написать программу для работы со строками текста, я обычно обращаюсь к Ruby или, возможно, к Groovy (извините, Perl — я больше туда не иду). Такие языки сценариев обычно ориентированы на обработку текста, а встроенные в них библиотеки облегчают выполнение этих задач. Я бы не стал прыгать на Java, потому что делать такие вещи — такая боль.
Рубин
File.open("myfile.txt").each { |line|
puts line if line =~ /blue/
}
какой-то стандартный Java, чтобы сделать то же самое
import java.io.*;
public class ProcessWords {
public static void main(String [] args) throws IOException {
BufferedReader input = new BufferedReader(
new FileReader("myfile.txt"));
String line;
while ((line = input.readLine()) != null)
if (line.indexOf("blue") != -1)
System.out.println(line);
input.close();
}
}
Код Java явно более многословен и уродлив, что соответствует мнению многих людей о Java в целом. Но это из-за языка или API ? Все API Java очень общие и дают вам полный контроль над всем, что вы делаете. API Ruby облегчают выполнение этой общей задачи.
Вы можете легко создать TextFile
класс в Java с помощью linesMatching
возвращаемого метода, Iterable<String>
позволяющего перебирать строки, соответствующие регулярному выражению. Теперь задача проста:
public class ProcessWords {
public static void main(String [] args) throws IOException {
for (String line : new TextFile("myfile.txt").linesMatching("blue")) {
System.out.println(line);
}
}
}
Дизайнеры Ant решили, что программисты любят писать на XML . Но я не Я бы лучше написал на Java, чем на XML . Будут ли скрипты сборки ant лучше выражаться на Java?
Мой гипотетический перевод на Java.
public class Ant implements ProjectDefinition {
void targets(Project project) {
project
.add(new Target("clean") {
void execute(Tasks tasks) {
tasks.delete("build");
}
})
.add(new Target("compile") {
void execute(Tasks tasks) {
tasks.mkdir("build/classes");
tasks.javac("src").destdir("build/classes");
}
});
}
}
Оба определения имеют примерно одинаковый размер. Гипотетическая версия Java определенно имеет некоторую хитрость, но достаточно компактна. Как и Rake , версия Java позволит вам использовать возможности реального языка в вашем скрипте сборки — условные циклы, динамические цели, переменные. Java-версия обеспечит вам мгновенную поддержку IDE , отладку и профилирование.
Примеры итерации строки и определения проекта ant показывают языки, специфичные для внутреннего домена. Первый домен — обработка текста. Языки сценариев конкурируют в этом пространстве, но я бы сказал, что он имеет гораздо больше общего с предоставляемыми ими библиотеками, чем синтаксис языка. Второй домен — это конфигурации сборки. При правильном API Java также отлично справится с этой задачей.
Конечно, у Java есть несколько препятствий, когда вы действительно рассматриваете его использование для скриптинга:
- Вы должны скомпилировать все файлы, которые отключают некоторых людей. Вы можете легко написать ClassLoader для компиляции кода на лету.
- Java запускается медленно, что снижает производительность очень быстрых скриптов, если это имеет значение.
- У Java нет метапрограммирования. Это, вероятно, самая большая проблема, хотя рефлексия и генерация кода могут помочь здесь. (Вы можете сгенерировать API задачи Ant для моего примера скрипта сборки).
Я думаю, что для Java могли бы быть написаны более удобные API для таких областей, как обработка текста, синтаксический анализ и создание XML , многопоточность (даже проще, чем java.util.concurrent) и файловые операции. Joda Time — отличный пример библиотеки, которая явно превосходит Java в этом отношении.
Когда я пишу API (на любом языке), я стараюсь думать о том, что сделало бы пользователя более счастливым при его кодировании, а не то, что обязательно соответствует реализации. Например, цепные вызовы методов вообще не помогают в реализации класса, но возврат this
из каждого метода может помочь вызывающим в некоторых случаях и достаточно прост для обоснования. В некоторых случаях предоставление небольшого внутреннего DSL вместо набора методов получения / установки и несвязанных методов делает код намного более читабельным и помогает сосредоточиться на вызывающей стороне, а не на реализации.