среда, 3 ноября 2010 г.

[prog.flame] Отказ от .NET разработчиков Evernote

Сегодня во время обеда встретился с давним приятелем по универу, с которым не виделся уже очень много лет. В разговоре он спросил, на чем я сейчас программирую и был очень удивлен, узнав, что до сих пор на C++. Похоже я, действительно, могу остаться одним из последних могикан, т.к. даже бывшие хардкорные сиплюсплюсники уже удивляются, что кто-то на плюсах еще программирует :)

Когда он меня спросил, почему же не Java, не .NET, я ответил что-то вроде: “Не смотря на все свои вкусности, если Java или .NET попадет не в те руки, то получатся такие тормоза, что их уже ничем не исправишь”.

Не успел я придти на работу, как обнаружил в RSS-ленте обсуждение того, что разработчики 4-й версии программулины Evernote написали эту версию с нуля на C++, отказавшись от .NET и его WPFвот здесь некто пытается защищать .NET и WPF и советует использовать вместо WPF Silverlight). Программистов задолбали как баги WPF, так и медленный старт, и большое потребление памяти у .NET-овской версии. Поэтому написали на C++. В итоге программа стартует в пять раз быстрее и потребляет в два раза меньше памяти.

Конечно, по сравнению с громким отказом от .NET на Лондонской фондовой бирже эта новость просто пустяковая. Но все равно приятно. Long Live C++!!! :)

На самом деле я думаю вот что: C++ – плохой язык (практичный, зараза, однако), разработка на нем обходится слишком дорого. Но реальные альтернативы в виде Java и .NET, обе из которых построены на основе байт-кода (пусть и с компиляцией в нативный код на разных стадиях работы программы) – это тоже не правильно. Уж не знаю почему, но слишком тяжелыми и медлительными оказываются Java и .NET-приложения. Получается, что время разработчиков ценится дороже, чем время и нервы пользователей программ. Что не есть гуд.

PS. Кстати, если кто-то интересуется историей проблем с .NET-овской версии софта Лондонской биржи, то вот интересная подборка на английском: London Stock Exchange timeline of technical problems.

17 комментариев:

4ybaka комментирует...

У нас поэтому на .Net пишутся только RichGUI проекты. Конечно бывают проблемы с взаимодействием C++/.Net но вроде уже наловчились. Оказалось проще/дешевле держать несколько человек ответственными за взаимодействие платформ, чем все писать на С++.

eao197 комментирует...

А в какой области проекты, если не секрет?

4ybaka комментирует...

Как раз та самая торговля на бирже, только с другой стороны - со стороны трейдера.

eao197 комментирует...

Т.е. вы пишете тот софт, который показывают в новостях и в кино -- вокруг брокера куча мониторов, на которых всякие таблички, графики и котировки?

4ybaka комментирует...

Да, именно такой софт. Правда конкретно наш продукт я пока видел только в книжках и журналах/газетах.

eao197 комментирует...

Прошу прощения за назойливость, но раз представилась возможность, то хочу спросить. А в таком софте высокие требования к скорости реакции (раз уж приходится на C++ писать)?

4ybaka комментирует...

Я занимался пока только проектами, где не было возможности торговли. Т.е. именно те самые графики, таблицы и тому подобное (аналитика в общем). Так что здесь основная проблема была в скорости отрисовки большого количества данных.
Про реакцию отклика могу сказать только то, что действительно за ней гонются. Для некоторых инструментов скорость является критическим звеном. Когда зарабатываешь на разности курсов и нужно "одновременно" что-то купить и продать.

eao197 комментирует...

>Так что здесь основная проблема была в скорости отрисовки большого количества данных.

И как, .NET с отрисовкой справляется?

4ybaka комментирует...

Все зависит от рук и знаний тех, кто начинает проект. Есть и такие, когда простые комбобоксы начинают дергаться при изменении размера. И доработка таких проектов оказывается достаточно проблематичной, т.к. переписывать основы как всегда нету времени. Ну а те проекты, где изначально все хорошо продумано проблем никаких не вызывают. Разве что с подсасыванием большого количества данных, но это, обычно, уже задача С++ части)

eao197 комментирует...

>Все зависит от рук и знаний тех, кто начинает проект.

Я тоже так думаю.

Спасибо за беседу :beer:

Quaker комментирует...

Евгений, а как Вы относитесь к Delphi? Там, вроде, со скоростью исполнения особых проблем нет.

eao197 комментирует...

@Quaker:

Я в свое время попрограммировал на Pascal-е и попробовал ObjectPascal (времен 1997-1999 годов). Как язык мне Pascal очень нравился и нравится. А вот от ObjectPascal остались отрицательные впечатления. Помню, что мне показалось, что ООП туда прикрутили неудачно. Сам синтаксис языка не располагал к удобному использованию объектов. Например, нужно было отдельно объявлять переменную, затем создавать объект, затем уничтожать. В C++ и Java с этим было проще.

Текущего состояния ObjectPascal и Dephi я не знаю. Вроде бы Dephi в тяжелом положении и Windows only. А версия с FreePascal обзаводится какими-то новыми возможностями (чуть ли не шаблонами), но нет времени с ним разбираться. Имхо, поезд Pascal-я уже ушел давным-давно.

Анонимный комментирует...

>> Получается, что время разработчиков ценится дороже, чем время и нервы пользователей программ.

Совершенно с этим согласен.
Не так давно столкнулся с проблемой тормозов софта на .NET по обработке данных переписи населения РБ.
Для работы операторов требуется очень быстрая работа интерфейса, подгрузка данных из БД и т.п., а этого нет.
Очень тяжелая проблема на самом деле, существенно снижает производительность.
Уж лучше бы писали на каком-нибудь Клиппере под ДОС, честное слово.

eao197 комментирует...

@yuhala:

Думаю, что виноват здесь не сам .NET (как показывает опыт 4ybaka и на .NET можно быстрый софт делать), а эффекты, которые дают безопасные среды вроде .NET и Java. Можно сделать быстро и, казалось бы, качественно. Но только казалось бы. Чтобы получилось качественно нужно тратить время и силы.

Когда-то об этом эффекте я писал: http://eao197.blogspot.com/2009/10/compprogthoughts.html

Quaker комментирует...

Вроде бы Dephi в тяжелом положении и Windows only. А версия с FreePascal обзаводится какими-то новыми возможностями (чуть ли не шаблонами), но нет времени с ним разбираться. Имхо, поезд Pascal-я уже ушел давным-давно.
Насколько мне известно, пока что Dephi только под Windows, хотя разработчик обещает поддержку других ОС (планы на будущее можно прочесть здесь http://edn.embarcadero.com/article/39934). Но самое печальное для Delphi - ужасное состояние литературы. Большинство книг на русском описывают устаревшую 7-ую версию. Само описание как правило посвящено не структурам данных, алгоритмам и ООП, а средствам визуализации (описания свойств визуальных элементов). Никакой глубины изложения наподобие серьезных книг по C++. Такое ощущение неприятное возникает, что эта среда не для серьезных разработчиков, а для школьников предназначена.

eao197 комментирует...

По-моему, книги по Delphi все изначально такие были. Впрочем, как многие книги по MFC и Visual C++.

Quaker комментирует...

Да, большинство книг на русском про Delphi именно такое. Про англоязычные книги не в курсе, возможно там есть нормальные описания, не зацикленные на GUI. Как по мне, так начинать серьезную книгу о языке программирования общего назначения с GUI просто неразумно. Впрочем, я до сих пор нахожусь под сильным впечатлением от "OOSC"
Б. Мейера. После этого шедевра программистской мысли многие другие книги для меня просто протухли:-) или потеряли былую ценность.