Интервью с Владимиром Кладовым, автором библиотеки KOL
Владимир
Кладов - автор библиотек KOL и MCK, о
которых "Компьютерные вести"
недавно уже рассказывали.
Этот человек широко известен среди
армии пользователей своих
библиотек, хотя и другим людям,
которые имеют представление о том,
что такое Delphi, его взгляд на этот
язык программирования, а также
связанные с ним вещи и их будущее,
будет небезынтересен. Так что не
буду затягивать и сразу начну
задавать Владимиру вопросы.
- Ну, во-первых, каковы, по-Вашему,
перспективы KOL?
- Перспективы KOL - хорошие. В долгосрочном плане есть реальная возможность поддержать и Linux/Unix, и любую другую платформу.
- Но в настоящий момент рабочая платформа KOL-приложений - Win32. И в недалёком будущем она, похоже, будет вытеснена, во-первых, 64-битными версиями Windows, а во-вторых, конкурирующими системами. Каково Ваше мнение по поводу будущего Win32?
- Платформа Win32 так просто не уйдёт, у неё большая инерция массы ПО. По крайней мере, ещё лет 10, а то и все 50 просуществует. Даже если железо станет совсем другим, оно всё равно будет иметь, как минимум, режим совместимости, чтобы и дальше можно было использовать тонны наработанного софта.
- Ну хорошо, тогда остаётся ещё один столп, на котором покоится библиотека KOL, - это Delphi. А будущее этих среды и языка программирования выглядит не таким уж и радужным, верно?
- Если даже что-то случится с Delphi, есть Free Pascal, а он более многоплатформенный, и это извиняет даже его неоптимальный код и некоторую сырость исполнения. Но Delphi тоже так просто не уйдёт. И, опять же, из-за огромной массы наработанного софта, БД, отчётов, всевозможных АСУ - на Delphi их лепить на порядок проще, чем на том же C++. А вот в его долгожительстве как раз стоит посомневаться, его как раз сама мама-Майкрософт очень даже пытается "подвинуть", заменяя на Delphi-подобный и VB-подобный C# и иже с ним. И "налеплено" на Delphi немало, всегда проще адаптировать старый код с прежнего Delphi на новый Delphi + новую ось, чем полностью переписать на тот же C#. Кстати, в реальном производстве (мне не повезло?) ни разу за последние 10 лет не было такого, чтобы производственные задачи делались на С++ или VB. Везде и всюду Delphi, доля рынка которого якобы "столь ничтожно мала", по сравнению с С++. Два раза видел использование С-подобных решений, но в одном случае речь шла о чуждой платформе (процессор на сканере штрих-кодов), и то - это была пара сотен строк кода, а остальные несколько тысяч снова на Delphi. А в другом случае - сопряжение с WinCC, который каким-то хитро закрученным образом куда-то, опять же, встроен и должен общаться с БД, ведомой, опять же, "всеми забытым" и "никому ненужным" Delphi.
- Раз уже разговор пошёл, так сказать, вширь, то давайте поговорим о перспективах всей IT-отрасли.
- Моё предположение такое, что если в ближайшие лет 15 не появится ИИ (искусственный интеллект), а он с огромной вероятностью не появится, по крайней мере, еще лет 50, то около половины работоспособного населения всего мира будут хоть как-то уметь программировать. То есть будут работниками этой самой IT. Даже если по должности будут ещё кем-то: агрономами, физиками, архитекторами дизайнерами, биологами... Это, опять же, плюс для Delphi, кстати, и его перспектив. Научиться работать в этой среде все-таки проще, и не надо себе забивать голову слишком большим количеством специальных знаний, касающихся исключительно программирования. Можно оставить больше места, то есть посвятить больше времени своей предметной области. Я даже подозреваю, что потенциально возможно появление "упрощённого" Delphi - упрощённого именно с целью облегчить его изучение и использование. Моё поверхностное знакомство с языком C#, кстати, не дало мне ощущения, что этот язык прост. А еще мне не понравилось и то, что он пока что привязан к некой платформе .NET, которая еще не доказала свою жизнеспособность на самом-то деле.
Кстати, насчёт цифр и вероятностей. Это не совсем мой прогноз. Есть такая теория, которая позволяет судить о наиболее вероятном ответе на вопрос о том, сколько времени просуществует некоторое явление или событие, на основании известных данных о том, сколько времени это явление уже существует. Теория утверждает, что, с огромной вероятностью, мы наблюдаем как раз половину времени существования явления. Т.е. если 50 лет назад мы полетели в космос и до сих пор не достигли Луны, то с огромной вероятностью не достигнем еще 50 лет. И, что удивительно, до сих пор эта теория оказывалась очень даже совпадающей с реальными фактами, т.е. она действительно работает:). Так что KOL + MCK с огромной вероятностью просуществуют еще 10 лет, и, согласно этой же теории, через 10 лет они будут находиться всё еще где-то посередине своего времени существования :)).
- Если так, то что нового в последнее время произошло в мире KOL и MCK?
- В конце октября - начале ноября добавилась поддержка MCK для BDS 2005-2007, возможно, Turbo-Delphi. Но я не проверял Turbo, у меня её нет, я вообще консерватор и предпочитаю до последней возможности использовать старое. Например, сейчас использую Delphi6 и не испытываю никакой потребности в BDS или Turbo. Я бы и Delphi5 обошёлся, если бы в нем была поддержка MMX-инструкций.
- Хотелось бы ещё узнать Ваше мнение по поводу потенциала использования KOL для, так сказать, отраслевого программирования (АСУ и прочее), а также узнать мысли по поводу сравнения в этой области KOL+MCK с VCL.
- Люди делают на нём работу с БД. Мне только не очень понятно, зачем. Для этих-то задач компактность вообще не требуется. Компонент KOLOdbc, который я сделал для KOL, - это вообще-то практически тот же, которым я с успехом пользуюсь в VCL, и он годится для работы с любой БД. Отчёты KOLReport - тот же NormalReport для VCL. Гридами и DB-контролами я не пользуюсь ни в KOL, ни в VCL. Это избавляет от очень многих непонятных проблем с их кривостью, которая обнаруживается в совершенно ненужных местах и только тормозит работу. Так что, в принципе, всё один в один.
- Нет ли планов сделать IDE для KOL, чтобы не было необходимости использовать MCK, а можно было напрямую взаимодействовать с KOL-компонентами?
- Нет, IDE делать не собираюсь. Народ, связанный с Free Pascal (Юрий Сидоров), участвует и в разработке Лазаруса. Так что "наши" пожелания по поддержке KOL в этом компиляторе и в этом IDE постоянно приемлются и совместимость обеспечивается и MCK в нём работает. IDE - это, прежде всего, отладчик на уровне исходного кода. Иначе это не IDE, а текстовый редактор с вызовом внешнего компилятора, не более. А отладчик - это очень серьёзная задача.
- Спасибо. Думаю, читатели присоединятся к моим пожеланиям всяческих успехов.
Интервью провёл Вадим СТАНКЕВИЧ
Версия для печати
Комментарии
Страницы
Все хорошо сказали! Единственное, в C# множественное наследования реализуется как и в Object Pascal - с помощью интерфейсов, а не как в C++.
19 ноября 2007 года, 20:06
>>2 Настоящий Полковник:
>>Все хорошо сказали! Единственное, в C# множественное наследования реализуется как и в Object Pascal - с помощью интерфейсов, а не как в C++.
Спасибо за поддержку и поправку. Еще не знакомился с C#, поэтому рассчитывал, что там так же, как в C++. А там все как в Java. ;)
19 ноября 2007 года, 19:55
>>>тема хороша для RSDN.ru, а не для КВ.
>>М.б. Просто я, рангутан эдакий, ламер-самоучка, иногда думаю - а что же это такое - репликатор БД? Да что там репликатор! Что такое код репликации? Вообщем, я рад за комповый народ: баранов вроде меня мало, и писать для них нефиг.
Ну, Майк, молодец. Смешно. ;)
>>Во-первых, CORBA - не майкрософтовская технология. Учите матчасть.
НП, где я писал, что CORBA это микрософтовская технология? Не надо мне приписывать того, что я не говорил, это вы сами приплели, фраза относилась к COM, DCOM, .Net и пр. Мне не нравится MS Way, что касается технологий разработки ПО и маркетинговой политики, слишком они замкнуты на себе.
>Во-вторых, ушли и куда пришли? ;)
Java, еще планирую опробовать его в связке с динамическими языками, почти всем доволен.
>>Слишком большие издержки получаются, а выхлоп - минимальный.
На Java лучше? ;)
Лучше!
>>Ну, если у вас 11мб кода получается генерацией всяких хидеров и стабов, то понятно откуда файлы по 50к :-) Если же ручками в файле 50к писано, за такое надо бить ремнем.
>Один зpas-файл (Remote Data Module) "весит" 1,5Мбайта. И что?
Вы очевидно не так поняли, генерируемые файлы могут быть любого размера, это влияет только на время компиляции, и как правило туда ручками не лезут. В остальном, большие файлы это bad practice: копаться в таких файлах удовольствия мало, даже в продвинутой IDE.
>А ремнем своих приятелей отхаживайте.
Скорее нерадивых программеров, которые неумеют или не хотят писать структурированный и легко-воспринимаемый код.
>>>>Кстати, пришлось вот свой репликатор базы сделать, чтобы не привязываться к определенной используемой СУБД. А использоваться может и Oracle, и MSSQL, и Sybase. Без перепрограммрования. ;)
>>У меня вообще все приложения не зависят от вендора БД,
Мне смешно. Одна табличка и использование select, insert, update, delete? Тогда действительно не зависит. ;););)
А бизнес-логика на хранимках так вообще зло (но это лишь мое мнение), а все остальное можно подкрутить для эффективности без необходимости менять BL или модель данных.
>>хотя предпочитаю использовать более продвинутые чем MySQL:
>О да! MySQL - это круто. ;)
Я разве говорил, что круто?
Использовать оракл или mssql для небольших проектов глупость, так что mysql может быть вполне подходящим под требования. Но если вы не обратили внимание, то как раз MySQL меня и не устраивает, поэтому я с него и мигрировал на Posqtgres.
>>PostgreSQL, Oracle.
>Особенно сравнение MySQL и Oracle. ;) Да и последняя тоже монстроидальная сиситема. Зато хватстаться можно. ;)
Хвастаться, тем что я их использую в своей работе? У вас богатая фантазия, и вы видите то чего нет.
>>Там хоть deffered constraints check есть и транзакции отродясь были.
В MySQL начиная с 4-й версии, кажется, уже есть транзакции. Вы не слышали? ;)
ага, а в 5-ой наконец появились хранимки. Создатели mysql всегда сравнивали производительность для mysisam (нетранзакционных), а не для innodb таблиц, и раньше говорили: зачем эти транзакции ведь они никому не нужны. Потом начали их прикручивать, а если они изначально не планировались, то прикрутка скорее всего на костылях, DCС нет до сих пор насколько мне известно.
>>За три недели (по 2-3 часа в день) написал достаточно гибкий импорт из тектовых tabular files (csv) в БД
[skipped]
>Круто! ;) Большое "достижение".
Это было больше к сравнительной оценке трудозатрат. А вы тут, между прочим, первым начали похваляться своим репликатором, однако так и не рассказали, чего же там крутого и что он собственно умеет реплицировать. Выкладывайте ТТХ.
>А для этого головой думать надо. А не в тупую на Garbage Collector надеяться. ;)
Можно еще на asm'e писать и думать, как там информация из памяти в регистры записывается и что с ней дальше происходит. Я слишком ценю свое время, чтобы работать на низком уровне: копаться в указателях, смартпоинтерах, воевать с корректным освобожением памяти при исключениях - драйверов и системное ПО я не пишу.
Только не надо мне еще про asm рассказывать, дескать я ничего не знаю про него и ставить свои глупые смайлы после каждой своей "умной" фразы.
А DDL-ки - на дельфях...
Майк, это несколько другая тема. Вы предлагали, если я правильно помню, что-то вроде "как написать универсальный репликатор", а не "что такое репликация". Вторая тема вполне для КВ.
(а) разговор асимптотически сходится к перепалке и переходу на личности, с выяснением "кто круче"
(б) коллеги от "баз данных" и близкой им тематики живут в своем, "параллельном мире", говорят на своем языке, и вполне возможно полагают, что вся индустрия программирования только в этом и заключается.
К сожалению, "родственных душ" из области распознавания образов и т.п. тематики так ни разу тут и не встретил...
PS. Предложение умерить использование смайликов поддерживаю. Лучше, наверное, оставить это для тинейджеровских форумов про любовь и дружбу.
19 ноября 2007 года, 21:28
>>>>Не понравилось, не использую, ушел и от C++ и от Microsoft-овских технологий.
>>>>Во-первых, CORBA - не майкрософтовская технология. Учите матчасть.
>>НП, где я писал, что CORBA это микрософтовская технология? Не надо мне приписывать того, что я не говорил, это вы сами приплели, фраза относилась к COM, DCOM, .Net и пр.
Не говорили? А цитату вашу хотите? ;)
"Реальный Пацан
19 ноября 2007 года, 14:14
про Remote Data Module не в курсе, имел опыт работы на VC с COM (лет 7 назад), про DCOM и Корбу имею самое общее представление. Не понравилось, не использую, ушел и от C++ и от Microsoft-овских технологий."
Вот это как понимать?
"про DCOM и Корбу имею самое общее представление. Не понравилось, не использую"
>>Мне не нравится MS Way, что касается технологий разработки ПО и маркетинговой политики, слишком они замкнуты на себе.
"На вкус и цвет товарищей нет" (c) народная мудрость.
>>>Во-вторых, ушли и куда пришли? ;)
>>Java, еще планирую опробовать его в связке с динамическими языками, почти всем доволен.
Наконец сознались. Да я и сам догадался. ;)
>>>>Слишком большие издержки получаются, а выхлоп - минимальный.
>>>>На Java лучше? ;)
>>Лучше!
Чем лучше? Тем, что к Microsoft никак не относится? ;) Хотя смотря что писать.
>>>>Ну, если у вас 11мб кода получается генерацией всяких хидеров и стабов, то понятно откуда файлы по 50к :-) Если же ручками в файле 50к писано, за такое надо бить ремнем.
>>>>Один зpas-файл (Remote Data Module) "весит" 1,5Мбайта. И что?
>>Вы очевидно не так поняли,
генерируемые файлы могут быть любого размера, это влияет только на время компиляции, и как правило туда ручками не лезут.
Это вы не поняли. Я говорил об исходном тексте.
>>В остальном, большие файлы это bad practice: копаться в таких файлах удовольствия мало, даже в продвинутой IDE.
Все нормально. Все четко структурировано, четко именовано. Не первый год, чай, занмаюсь. ;)
>>>А ремнем своих приятелей отхаживайте.
>>Скорее нерадивых программеров, которые неумеют или не хотят писать структурированный и легко-воспринимаемый код.
Тогда в чем проблема? Вы сначала суть поймите, а потом оценивайте - почему так, а не иначе сделано. ;)
>>>>Кстати, пришлось вот свой репликатор базы сделать, чтобы не привязываться к определенной используемой СУБД. А использоваться может и Oracle, и MSSQL, и Sybase. Без перепрограммрования. ;)
>>>>У меня вообще все приложения не зависят от вендора БД,
>>>Мне смешно. Одна табличка и использование select, insert, update, delete? Тогда действительно не зависит. ;););)
>>А бизнес-логика на хранимках так вообще зло (но это лишь мое мнение),
И почему?
>>а все остальное можно подкрутить для эффективности без необходимости менять BL или модель данных.
Паттерны, там MVC и прочие модные штучки? ;) Не так все просто. Это не панацея. Model говорите легко поменять? А SQL кто будет переписывать? А, пардон, у вас же EJB. Которая глючная, неудобная и страшно медленная.
>>>>>>хотя предпочитаю использовать более продвинутые чем MySQL:
>>>>О да! MySQL - это круто. ;)
>>Я разве говорил, что круто?
Я бы вообще промолчал, если бы использовал MySQL. ;)
>>Использовать оракл или mssql для небольших проектов глупость,
С этого и начинали бы - мол, маленькие проекты. ;)
>>так что mysql может быть вполне подходящим под требования.
Безусловно. Только не надо его перечислять в списке с тем же Oracle. ;) Несолидно выглядит.
>>Но если вы не обратили внимание, то как раз MySQL меня и не устраивает, поэтому я с него и мигрировал на Posqtgres.
Удачи.
>>>>PostgreSQL, Oracle.
>>>Особенно сравнение MySQL и Oracle. ;) Да и последняя тоже монстроидальная сиситема. Зато хватстаться можно. ;)
>>Хвастаться, тем что я их использую в своей работе?
Нет, просто эти СУБД в один ряд НЕ СТАВЯТСЯ. ;)
>>У вас богатая фантазия, и вы видите то чего нет.
Я все очень хорошо вижу. Благо опыта на несколько таких как вы хватает. ;)
>>>>Там хоть deffered constraints check есть и транзакции отродясь были.
>>>>В MySQL начиная с 4-й версии, кажется, уже есть транзакции. Вы не слышали? ;)
>>ага, а в 5-ой наконец появились хранимки. Создатели mysql всегда сравнивали производительность для mysisam (нетранзакционных), а не для innodb таблиц, и раньше говорили: зачем эти транзакции ведь они никому не нужны. Потом начали их прикручивать, а если они изначально не планировались, то прикрутка скорее всего на костылях, DCС нет до сих пор насколько мне известно.
Давайте не будем ликбез устраивать. Тем более для меня. ;)
>>>>>За три недели (по 2-3 часа в день) написал достаточно гибкий импорт из тектовых tabular files (csv) в БД
>>>[skipped]
>>>>>Круто! ;) Большое "достижение".
>>Это было больше к сравнительной оценке трудозатрат. А вы тут, между прочим, первым начали похваляться своим репликатором, однако так и не рассказали, чего же там крутого и что он собственно умеет реплицировать. Выкладывайте ТТХ.
А вам зачем? Пользуйтесь встроенными средствами того же Oracle. А у меня так - поделка. ;)
>>>А для этого головой думать надо. А не в тупую на Garbage Collector надеяться. ;)
>>Можно еще на asm'e писать и думать, как там информация из памяти в регистры записывается и что с ней дальше происходит.
В крайности не бросайтесь.
>>Я слишком ценю свое время, чтобы работать на низком уровне: копаться в указателях, смартпоинтерах, воевать с корректным освобожением памяти при исключениях - драйверов и системное ПО я не пишу.
>>Только не надо мне еще про asm рассказывать, дескать я ничего не знаю про него и ставить свои глупые смайлы после каждой своей "умной" фразы.
Memory Leak даже с Garbage Collector'ом никто не отменял. Или у вас такая фанатичная вера в продукты Sun? ;)
19 ноября 2007 года, 22:22
>>А у меня драйвера на C++ :)) С наследованием и перегрузкой - для разного железа.
>>А DDL-ки - на дельфях...
И нормально. И memory leaks, я думаю, у вас отсутствуют. Так?
--------------------------------------------------------------------------------
>>Котт (Гомель)
19 ноября 2007 года, 23:56
>>Внимательно прочитал все последние посты. Мое личное (т.е. никому не навязываемое и совсем необязательно верное) мнение такое, что здесь, как, впрочем, и во многих других дискуссиях:
(а) разговор асимптотически сходится к перепалке и переходу на личности, с выяснением "кто круче"
Нет, вы ошибаетесь. Мой "разговор" направлен на то, чтобы умерить пыл некоторых начинающих товарищей. И чтоб других в заблуждение не вводили. А то, что я умею и чего стою - сам прекрасно знаю без посторонней помощи и оценки. ;)
>>(б) коллеги от "баз данных" и близкой им тематики живут в своем, "параллельном мире", говорят на своем языке, и вполне возможно полагают, что вся индустрия программирования только в этом и заключается.
Смешно. Перечислите, пожалуйста, всех "коллег". Очень интересно.
>>К сожалению, "родственных душ" из области распознавания образов и т.п. тематики так ни разу тут и не встретил...
Почему же? ;) Что вы хотите обсудить? Что распознавание нельзя делать на Delphi? И база не нужна к такой системе? Вы ошибаетесь. И не советую со мной спорить, поскольку прямо касаюсь данной тематики. ;)
>>PS. Предложение умерить использование смайликов поддерживаю.
Почему же? Надо же как-то выражать эмоциональную составляющую в постах. А то многие очень серьезно ко всему, что говорю, относятся.
>>Лучше, наверное, оставить это для тинейджеровских форумов про любовь и дружбу.
Понятно. Вы даже без смайлика обошлись, пытаясь меня уколоть. Пожалуйста, продолжайте. Только простите, но на тинейджера я уже давно-давно не тяну. Очень давно. А вот здесь некоторые еще пылают юношеским задором. ;) Ой, пардон за смайлик.
"Реальный Пацан
19 ноября 2007 года, 14:14
про Remote Data Module не в курсе, имел опыт работы на VC с COM (лет 7 назад), про DCOM и Корбу имею самое общее представление. Не понравилось, не использую, ушел и от C++ и от Microsoft-овских технологий."
НП>Вот это как понимать?
Повторяю еще раз: фраза про микросовтовские технологии относилась к COM, DCOM. Или мне надо было специально для вас в скобочках это указать после микросовтовских технологий, а корбу отдельно указать? Зачем МС будь корба ее технологией еще и DCOM? Я даже не думал, что можно на этом пытаться "поймать" собеседника.
>>>>На Java лучше? ;)
>>Лучше!
НП>Чем лучше? Тем, что к Microsoft никак не относится? ;) Хотя смотря что писать.
Тем, что ей уже 10 лет, и она развивается эволюционно. А МС постоянно изобретает новые технологии выкидывая старые на помойку (обесценивая знания программеров), разрабатывает несовместимые версии (камень в сторону .Net). Развитие это никак разработчиками не контролируется и не направляется, в отличие от Java, где движущей силой является community, которое реально участвует в разработке стандартов, а не Sun, IBM и кто либо еще.
Java и многие разработки с ее использованием открыты и не принадлежат кому-то конкретно, что для меня очень важно так как избавляет от такой неприятной вещи как vendor locking. В конце концов java реально кроссплатформена и мне все равно на чем развертывать приложение линус сервер или виндовс.
>>А бизнес-логика на хранимках так вообще зло (но это лишь мое мнение),
НП>И почему?
Для начала:
1. Сложность поддержки: найти программиста на general-purpose язык проще, чем спеца разбирающегося в особенностях работы конкретной базы и синтаксисе ее хранимок. Такая вот проза жизни.
2. Сложность тестирования кода. Как вы решаете задачу удаленного дебага хранимых процедур и unit-тестирование процедур?
3. SQL изначально разрабатывался для выборки данных, и движок хранимок очень ограничен в конструкциях языка и не всегда эффективен, поскольку заточен на обработку весьма специфичных по структуре данных.
4. Написание BL на хранимках, гарантированный vendor locking (хотя это иногда неизбежное зло).
5. Не развитые возможности рефакторинга кода.
>>а все остальное можно подкрутить для эффективности без необходимости менять BL или модель данных.
НП>Паттерны, там MVC и прочие модные штучки? ;) Не так все просто. Это не панацея. Model говорите легко поменять? А SQL кто будет переписывать? А, пардон, у вас же EJB. Которая глючная, неудобная и страшно медленная.
Именно, паттерны и разделение ответственности по слоям, глупо пренебрегать чужим опытом. В простых случаях, не приходится даже SQL писать, вообще.
Не понятно о каком именно из видов EJB вы говорите, о каких глюках и тормозах?
Из вашей фразы могу следать вывод, что у вас знания о Java и EJB 5-летней давности, т.к. никому сейчас не придет в голову связывать SQL, доменную модель и EJB чуть ли не в одном предложении.
Entity Beans уже года так 3 deprecated, технология оказалась слишком сложной и не оправдала себя, поэтому ее и убрали из последней версии спецификации найдя подходящую замену на основе альтернативных проверенных практикой решений. Остальные EJB продолжают жить и здравствовать, т.к. им практически нет альтернативы при построении распределенных приложений с распределенными же транзакциями. Вижу, что миф о тормознутости java продолжает жить, странно, что на ней все еще пишут :)
>>Использовать оракл или mssql для небольших проектов глупость,
НП>С этого и начинали бы - мол, маленькие проекты. ;)
Вы, наверное, со студенческой скамьи писали только приложения межгалактического масштаба с использованием MSSQL. Проекты разные и маленькие и большие, я всегда выбираю средства в соответствии с размером решаемой задачи и требованиями, а не крутостью той или иной БД.
НП>Давайте не будем ликбез устраивать. Тем более для меня. ;)
А почему вы считаете нужным устраивать его мне, объясняя что CORBA это оказывается не микрософтовская технология? Или вы считаете себя непререкаемым авторитетом, гуру, снизошедшим до простых смертных, чтобы поведать истину? Истина как известно рождается в споре :)
НП>Memory Leak даже с Garbage Collector'ом никто не отменял. Или у вас такая фанатичная вера в продукты Sun? ;)
У вас есть какие-нибудь доказательства проблем у GC, связанных с утечкой памяти? Или только голословные утверждения?
GC не избавляет от необходимости включать мозг (особенно что касается кэширования), но избавляет от большой головной боли. Вероятность создать ошибку в С++ коде при работе с указателями и смартпоинтерами куда выше, чем найти оную в отлаженном и оттестированном механизме GC.
Страницы