Если переписать обычную программу с использованием ООП, она станет занимать в 2 раза больше места. Автор неизвестен |
К Java есть множество обоснованных нареканий, в частности, низкая скорость работы и большое потребление памяти, не говоря уже о других недостатках. Однако в наше время это не столь критично, а гораздо более важной считается производительность труда программиста (проекты нынче большие и сложные, на разработку следует тратить времени меньше). И здесь, как утверждается, Java должна давать большой выигрыш - легкий в изучении язык, на котором можно быстро разрабатывать программы (сравнительно с предыдущими языками, конечно).
Вот это утверждение я и решил проверить. Способ простой - ставим задачу, и реализуем её на двух языках, замеряя затраченное на разработку и отладку время, а заодно и размер результирующего исходного кода (памятуя о том, что производительность труда программиста в строках в час в промышленных условиях достаточно постоянна и почти не зависит от языка программирования). Причем реализовывать должны два разных человека, чтобы при повторной реализации на дргуом языке не получилось простого портирования алгоритма (что будет быстрее разработки с нуля) с влиянием другого языка.
Итак, взял я задачу, которую сделал незадолго до того (время было известно), нашел программиста на Java, которому было нечего делать, так что он согласился поучаствовать в эксперименте, дал ему условие задачи, и началось.
( И что же из этого вышло? )
( Приложение 1. Исходный текст на Java. )
( Приложение 2. Исходный текст на Паскале (BP 7.0). )
( Приложение 3. Тесты к задаче. )
( Приложение 4. Иллюстративный материал: решения на других языках. )
Ссылки по теме:
- DNS Message Decoding: A Case Study Comparing Java and Common Lisp
- Peter Norvig: Lisp as an Alternative to Java
- Erann Gat: Lisp vs Java
- Lutz Prechelt. An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program.
- Африканец. Заметки про Жабу. Часть 1. (критика языка Java)
- Африканец. Заметки про Жабу. Часть 2. (критика Java как явления)