Сегодня пока искал в интернетах материал никак не связанный с обероном, внезапно наткнулся на ЭТО:
http://incoder.tumblr.com/post/7380052577Это ж надо как у человека в черепушке насрано… Похоже серия статей на хабре про Оберон все же нужна. Нормальная серия статей не рекламного характера, где объективно и интересно было бы описана история Оберона, а также его преимущества и недостатки, без фанатизма.
На всякий случай продублирую текст что был выше по ссылке:
Долой виртуальные машины
Я думаю что виртуальные машины типа Simula 67, Oberon (Black Box), Java и .NET плохая идея. Они были разработаны чтобы избежать ошибок возникающих при ручном управлении памятью и адресной арифметикой. Т.е. идея создать язык который сможет ограничить программиста от допущения ошибок, хотя бы от типичных. Т.е. снизить требования к квалификации программиста, времени потребной на его подготовку и как следствие цену полученного ПО.
Что получили в итоге - Simula67 и Oberon изначально выдавали низко производительные программы которые медленно работали и потребляли много памяти. На момент их создания компьютер занимал отдельное помещение типа цеха, и машинное время стоило очень дорого. Итог языки в промышленном масштабе не применялись. И дело не в маркетинговой составляющей, да языки изобретены в Европе - а компьютеры делали в Америке. Паскаль создан Никлаусом Виртом - он же создал и Oberon, но этот язык нашел широкое применение в том числе и в США.
На производительность программ Java долгое время не обращали внимание, потому что в 1995-м задержка в линиях передачи данных с лихвой перекрывали время потребное для работы сервелета. Апплеты и прикладные приложения написанные на Java так и не получили большого распространения, исключения оставляют только IDE все для той-же Java и Vuze. К тому же нагрузки на сервера были во множество раз ниже современных.
Что имеем сейчас - проблемы с производительностью Java программ. При современной скорости передачи данных задержка на сервере имеет значение. К тому-же нагрузки увеличились многократно. Особенно остро они стоят с программами написанными начинающими программистами из индии. Следствие - или потери клиентов, не желающих мерится с низкой производительность - или огромная стоимость серверов потребных для работы таких программ. Конечно хорошие программисты все равно стоят дороже чем хорошие серверы, но обслуживание хороших серверов (админы, и датацентры) стоит дороже чем хорошие программисты. Т.е. JVM решительно не удешевляет разработку ПО, а только создает дополнительные проблемы. Проще говоря не сработало.
Для любителей подискутировать на тему - “ну вот больше я не вижу 0x000005 общая защита памяти”. Чем NullPointerException от этого отличается? Это все та же общая защита памяти, но только не средствами операционной системы - а средствами интерпретатора виртуальной машины. Какая разница пользователю по какой причине программа отказала?
У .NET дела конечно обстоят много лучше, технология была разработана спустя пять лет после выхода Java с учетом всех ошибок допущенных в Java т.е. JIT, Security Management и JNI. Система отлично подходит для прикладных программ, но не очень для серверных. Ядро Windows NT в принципе разработано для персональных компьютеров, а не для серверов к тому-же стоит больших денег. Т.е. тоже не работает, цена на софт с лихвой перекрывает все выгоды.
Вывод - виртуальные машины плохая идея. Он ни в коей мере ничего не удешевляют, а наоборот требуют дополнительных затрат.
Что делать ? Пока что я вижу выход в Fast CGI и С++/Objective C. Возможно на их смену может прийти Google Go или D-2.
