Сообщение Re[7]: Какие слабые места у Delphi (вообще) ? от 12.02.2015 6:39
Изменено 12.02.2015 6:40 kaa.python
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>То есть даже если отбросить подход "сделать как можно больше абстракций и фабрик", то всё равно будет тормозить. Быстрый код получается посредством отказа от полиморфизма, отказа от GC и эмуляцией структур — в результате остаётся крайне ограниченное и неудобное подмножество языка (на котором писать в "C++ стиле" уж точно никак не получится).
Отказа от классических Java практик поусложнению написанию идеально расширяемого решение уже будет достаточно, проверено. Скорость получается очень приличная, расход памяти в рамках разумного (в крайнем случае на 500 MHz MIPS с полугигом памяти на вообще все, крутилась куча логики поверх OSGi оставаясь более чем отзывчивой. Еще и куча свободной памяти была и проц далеко не на 100% загружен). До этого опыта я был на 100% уверен в том, что вся проблема в Java как таковой, сейчас я так же на 100% уверен что дело в концепциях (память/процессор не ресурс), которые считает основная масса Java программистов правильными.
EP>То есть даже если отбросить подход "сделать как можно больше абстракций и фабрик", то всё равно будет тормозить. Быстрый код получается посредством отказа от полиморфизма, отказа от GC и эмуляцией структур — в результате остаётся крайне ограниченное и неудобное подмножество языка (на котором писать в "C++ стиле" уж точно никак не получится).
Отказа от классических Java практик по
Re[7]: Какие слабые места у Delphi (вообще) ?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>То есть даже если отбросить подход "сделать как можно больше абстракций и фабрик", то всё равно будет тормозить. Быстрый код получается посредством отказа от полиморфизма, отказа от GC и эмуляцией структур — в результате остаётся крайне ограниченное и неудобное подмножество языка (на котором писать в "C++ стиле" уж точно никак не получится).
Отказа от классических Java практик поусложнению написанию идеально расширяемого решение уже будет достаточно, проверено. Скорость получается очень приличная, расход памяти в рамках разумного (в крайнем случае на 500 MHz MIPS с полугигом памяти на вообще все, крутилась куча логики, включая обработку изображений и базовую криптографию, поверх OSGi оставаясь более чем отзывчивой. Еще и куча свободной памяти была и проц далеко не на 100% загружен). До этого опыта я был на 100% уверен в том, что вся проблема в Java как таковой, сейчас я так же на 100% уверен что дело в концепциях (память/процессор не ресурс), которые считает основная масса Java программистов правильными.
EP>То есть даже если отбросить подход "сделать как можно больше абстракций и фабрик", то всё равно будет тормозить. Быстрый код получается посредством отказа от полиморфизма, отказа от GC и эмуляцией структур — в результате остаётся крайне ограниченное и неудобное подмножество языка (на котором писать в "C++ стиле" уж точно никак не получится).
Отказа от классических Java практик по