Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Xentrax, Вы писали:
X>>или даже RSDN я сейчас сяду и напишу
AVK>Не напишешь. Потому что количество неотвратимо переходит в качество. Борьба со сложностью это на настоящий момент наиважнейшая задача создания информационных систем. Непонимать этого значит заведомо провалить любой мало мальски сложный проект.
Я позволил себе выделить вашу очень смешную фразу, про то что я не смогу написать RSDN. Я как программист (он же разработчик) и вообще дипломированный специалист по АСУиОбработкеИнформации умею бороться со сложностью, поэтому RSDN я знаю как писать. И даже знал 5 лет назад.
Я вам сейчас кратко расскажу про информационную сложность.
Предположим как вам решение, включающее себя спутниковые приемники (включая инфраструтуру — антенны, кабели, триподы), лазерные нивелиры, высокточные теодолиты (включая новые модели с выделением дополнительной информации из изображений), роботизированные бульдозеры, контроллеры, сети виртуальных базовых станций, людей в офисе и в поле, соединить это все информационными потоками и логически — и физически — через радио-модемы, лазерные лучи, GPRS, CDMA, создать собственные процессоры для этого оборудования, да еще и обеспечить интегарцию всего этого с конкурентами, итд итп. Так вот, написать это я не смогу, хотя уже 5-ый год в этом.
Потому что я не могу в одиночку охватить всю предметную область. Что уж там говорить — в самой обычной американской дороге заложено науки и расчетов побольше чем в среднего размера сайте.
Да просто, чтобы посчитать гридовые координаты для какой нибудь несчастной малайзийской деревни нужны специальные выверенные алгоритмы, и определенные параметры преобразований. И если у вас в вашем алгоритме (написанном 10 лет назад на С) появится ошибка, то команда бородатых сурвейеров, потратившая месяц-два времени, и нагулявшийсь по местным джунглям, разбившая там пару теодолитов за $50000 каждый, будет очень удивлена объяснением, что зато язык C# позволяет бороться с информационной сложностью. Был у нас приблизительно такой случай
А ведь у нас это все работает. И написано вовсе не на C#. И язык для таких задач уже не важен, более того, для некоторых процессоров наши разработчики вынужены писать на ассемблере очень сложную логику просто потому, что нет для них компилятора даже языка C.
Чтобы получить фиксированное решение на 50 километровой базовой линии, недостаточно хорошо знать язык C#. Чтобы у вас безотражательный теодолит работал на расстоянии в километр, C# уже не поможет. Зная C#, вы не построите сеть виртуальных базовых станций, потому что дело не в языке, а в математике. И вот, я каждый день вижу людей, которые все это делают. И это работает.
А ведь есть еще маркетинг, дистрибуция, техподдержка, десятки офисов по всему миру. И растущие прибыли, хотя ни в одной системе в компании .Net пока не используется, хотя учитывая разговоры о том, что наш сайт пора выбрасывать, то, думаю, эту, самую важную часть решения перепишут на чем-нибудь новомодном.
), я не знаю, чем вы по жизни занимаетесь, но это же правда смешно. Вы СЕРЬЕЗНО думаете, что нет ничего сложнее, чем соединить GotDotNet и RSDN???
Ну да, я тоже пишу фактически как хобби на .Net/ASP.Net комплекс, который на лету по построенным индексам считает параметры рынка коммерческой недвижимости в динамике и статике на основе данных, которые операторы готовят, анализируют и фильтруем на шумы заранее. Ну что-то типа недо-OLAP. И в общем, информационная сложность этого "решения", мягко говоря, никакая. Не думаю, что RSDN на 2 порядка сложнее, чем моя программка.
----
Еще раз. Есть задачи, где неважно на каком языке вы пишете, а важно, ЧТО вы пишете, и какие ЗНАНИЯ вы туда закладываете. Хотя наверное стоит забить на сотни миллионов долларов интеллектуальных инвестиций, сделанных в код, и перейти на язык, в котором сделано множество существенных улучшений, например используется необычайно прогрессивная и насущная технология реализации интерфейсов вместо устаревшего и неприменимого в реальных задачах множественного наследования.
---
Во, я тут вспомнил, что мне это напоминает. Я однажды на форуме Лингво посмел сказать, что их полная версия дороговата, и что пора думать об апдейте со скидкой. Ёёёёё, как мне там разработчики стали доказывать, что лингвисты — самая нужная, важная и тяжелая профессия на земле.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>Мало уступает, да? E>А как тогда на C# сделать такое: А generic-и так могут?
Доделают в третьей версии языка.
А если серьёзно, то вспомните поговорку:
"Умный человек — это тот, кто знает, как выпутаться из сложной ситуации, а мудрый — тот, кто знает, как в неё не попадать". Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
Боже мой! Я фанат C++ и защищаю эту мерзость! Какой позор... Смайлика с харакири здесь нет?
Здравствуйте, vdimas, Вы писали:
ГВ>>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.);
V>1. Сложность не надо путать с объемностью.
Что в твоём понимании сложность? А то пока ты не дал своего определения вряд ли мы сможем говорить об одном и том же.
V>2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)
В молодой конторе с бурно развивающимся бизнесом наличие ТЗ такая же редкость как и сферические кони вне вакуума. Сроки — вчера. Polymorphic behaviour — в сад. Code Conventions — лесом. Релиз — раз в неделю. Программер — швец, жнец, на дуде игрец. Архитектор — специалист по ампутированию гландов через выхлопную трубу и замены протезов во время забега. В наличии несколько часов после 24:00 для деплоймента, 1000 компов в трёх странах и право хранить молчание, которое всё равно будет использовано против Вас.
А теперь вопрос. Какое нафиг ТЗ?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Xentrax, Вы писали:
X>или даже RSDN я сейчас сяду и напишу
Не напишешь. Потому что количество неотвратимо переходит в качество. Борьба со сложностью это на настоящий момент наиважнейшая задача создания информационных систем. Непонимать этого значит заведомо провалить любой мало мальски сложный проект.
If you arenґt C++ programmer... study C++, right now!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Есть одно ёмкое русское слово очень хорошо подходящее для описания данного эссе — бред.
VD>Думаю, что C++/CLI повторит судьбу первой версии МС++. Вообще-то об этом тут уже не раз говрилось. Сделай поиск по CLI...
Повторит судьбу в каком смысле? В том что оставшиеся непокобелимые остатки C++ девелоперов таки попробуют C++/CLI, подсядут на .NET, так между прочим случайно попробуют C# и опаньки? Знакомая история
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> AVK>Ну это как бы тоже велосипедизм. Т.е. как работает типичная >> современная РСУБД я представляю хорошо, но вот чтобы свою писать ... >> А как же Oracle, MSSQL, DB2 -- их что велосипедисты разрабатывают?
C>Какие же это велосипеды? Это уже давно тяжелые грузовики.
Пора вводить новые термины:
— Грузовикостроение,
— Поездостроение
Симметрично можно ввести градацию в противоположную сторону:
— "делать свой самокат"
— "разрабатывать свои ролики"
"VladD2" <73@users.rsdn.ru> wrote in message news:1238246@news.rsdn.ru > Здравствуйте, Павел Кузнецов, Вы писали: > >>> Полноценных компиляторов С++ ровно... один. Дальше делай выводы. > >> Что значит "полноценных"? > > Компилирующих С++, а не собственное наречие.
Странное определение полноценного компилятора, очевидно, приведенное здесь для того, чтобы количество оных было не больше одного.
Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT. Все остальные гораздо сложнее. Просто в последние 5-10 лет это самая емкая и популярная область. И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
--------
Простой вопрос на засыпку. Кто из современных т.н. "архитекторов" ПО, после разработки очередной гениальной схемы ПО (как статической так и динамической) своей системы, делает попытки расчитать предполагаемые характеристики ее работы?
Здравствуйте, eao197, Вы писали:
E>Просто для оценки объективности твоего высказывания: какими еще задачами тебе приходилось заниматься?
А из каких частей по-твоему состоят бизнес-приложения и сайты? vdimas уже озвучил свою точку зрения, по его мнению они состоят из базы данных и формочек. А по-твоему?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
VladD2,
> ПК> Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...
> Мне просто влом копаться в стандарте. Можешь вынимать их по одному и обсудим.
Следовательно, свое утверждение о степени влиянии наличия неопределенного поведения на сложность реализации рефакторинга ты делал голословно, без предшествующего анализа. Впрочем, я так и думал...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Kisloid, Вы писали:
K>Хочется узнать ваше мнение
Как я понимаю вопрос стоит в C# vs managed C++?
Не так давно потребовалось мне поработать с железкой. Весь интерфейс с ней составлял кучу сишных хедеров и либов. Разумеется решил использовать С++, благо в нем можно достаточно просто мешать managed & unmanaged код. Эх! Давно не брал я в руки шашки (года 3), пора вспомнить молодость плюсовую и заодно погонять С++ под дотнетом! В результате получил кучу "удовольствий", о которых успел уже толком подзабыть за время своей C#-ной деятельности.
Для начала я лишился решарпера и всех прибамбахов студии. Привык, блин, к хорошему. Поиск элементарных ошибок путем компиляции всего проекта... мда, невесело. Ну да ладно, в 2005-й студии ситуация обещают поправить, а вот решарпер даже и не планируют делать для С++. Как я раньше без него работал, хз.
Дальше с интересом отметил ужасающую скорость компиляции. В разы медленнее кода на C#. А ведь когда-то вполне было нормальным минут на 5 запустить компиляцию и спокойненько покурить, и не жаловался! Ну да ладно, фасад для сишних либ получился не особо большой, терпимо.
Пришлось заодно вспомнить приколы с хедерами, с раздельной декларацией и реализацией метода.
Ну и конечно, куча мелочевок, завязанных именно на синтаксис:
1. Events, properties ну очень "красиво" и громоздко выглядят.
2. Так же весьма "приятно" постоянно писать __box для боксинга.
3. Приведение типов... вместо as и (Type) извольте использовать громоздкие __try_cast & dynamic_cast.
4. Передача аргументов для функции с переменным количеством оных вынуждает использовать конструкцию Object* args[] = { ... }; Method(args);
5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
6. Поимел проблемку с NullReferenceException при __nogc new. Решилось поиском в гугле и прописыванием нужной либы линкеру. Уж и забыл, что линкер имеется
Вообщем веселье....
А теперь вопросец. Мне понятно, почему я не хочу использовать С++ для написание софта под дотнет, за исключением разве что интеропа к легаси коду. Отсутствие полезных тулзов (решарпер), тормозной компилятор, громоздкий синтаксис. Так в чем же плюсы плюсов? К чему собственно агитирует автор по исходной ссылке? К лени и нежеланию учить другой язык?
Здравствуйте, Xentrax, Вы писали:
X>Ну а то, что стандартизаторы С++ тормозят развитие языка, это наша общая большая беда. reflection и properties не хватает, конечно. Поразительно, что многочисленные пользовтаели, стонущие из-за их отсутсвия, не могут уже много лет самоорганизоваться и потребовать этих измениий.
И только к счастью, что не могут. С++ не задумывался для этих целей. И не стоит курочить язык, что бы сделать гибрид слона с попугаем. Эти возможности есть в C# и в Java — так зачем их тащить на C++? Не лучше ли сделать в C# или Java более удобные generics и расслабиться?
Здравствуйте, eao197, Вы писали:
V>>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT. Все остальные гораздо сложнее. Просто в последние 5-10 лет это самая емкая и популярная область. И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
E>Дима, а какую именно область IT ты считаещь более сложной, чем бизнес-приложения?
Их много, часть из них ты называл в той ветке, не хочу повторятся.
Так же могу добавить:
— разработка различного инструментария (в помощь администрированию, например, там широченное поле деятельности).
— разработка компонентов для стандартных вещей (например, в CORBA есть куча стандартов на middleware, но мало качественных реализаций) и т.д.
— разработка тех же повторно-применимых фреймворков для тех же бизнес-приложений (прочуствуйте разницу).
----
Если уж пошли перечислять, кто чем другим занимался, позволю и себе.
Из других задач нравились обработка сигналов и всякие вещи по массовому обслуживанию в условиях ненадежной связи.
Были разработки ассемблеров (под x51, ибо стандартный Интеловый компилил неимоверно долго на той технике).
Разработка системы цифрового TV (начиная от железки и архитектуры сети, заканчивая сборкой спец. редакции сверх-урезанной uсLinux) и еще куча работ железно-софтового направления (вплоть до управляемого высокочастотного свар-аппарата и динамических систем поджига неоновой рекламы).
Туда же тонна утилиток и программок моделируещего и расчетного плана (не всегда симуляторы справлялись). На плюсах и Matlab обычно.
Но больше всего приходилось заниматься именно бизнес-приложениями (склад, бух, кадры, ресурсы, закладки-фасовки, аналитика, прогноз кое-какой, документооборот кое-какой), и по субъективному ощущению — все это "не то" , хотя и платят больше.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>>Мало уступает, да? E>>А как тогда на C# сделать такое: А generic-и так могут?
AF>Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием). А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста, кого-то вроде меня
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>У меня Assist не глючит и не тормозит
Значит ты особенный.
ПК>Так "по функциональности сопоставим" или "и одного процента не умеет"?
Скачай погляди.
ПК>Или наоборот: "толку больше, траха меньше".
Траха больше. Тут даже обсуждать не чего. А что до толку... Ну, если бы это было так, то я лично бы первым на него перепрыгнул. Вот двича помучился еще чутка и викинул МС++ ввобще к чертям. Не стоит он того.
ПК> Очень содержательная дискуссия Если хочешь, что-то сказать по делу, содержательно, а не выплеснуть эмоции — скажи, не таись. Пока что информационная ценность стремится к 0 за отсутствием конкретики.
Я разберусь, что мне делать. Ты лучше следи за содержательностью совоей рекламы C++. А то от обвинений в несодержательности чужих слов твои содержательнее не становятся.
>> ПК>Это все о Managed Extensions for C++, а не о C++/CLI. >> >> Да, да. Как щаз помню... Пытался свойство описать. Долго пытался понять кто идион я или компилятор.
ПК>Я, пожалуй, воздержусь от вывода.
А что так? Боишся что они окажутся не содержательными?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> 5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
ПК>Спорный вопрос, что лучше.
еще как спорный
если в студии стоит решарпер, то может это и не важно, какой синтаксис, ибо при подведении мышки к символу всплывает его определение...
а если писать не в студии, то использование '.' везде и всюду элементарно сбивает с толку.
Здравствуйте, vdimas, Вы писали:
V>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT.
Не думаю.
V> Все остальные гораздо сложнее.
Пока что решений, сопоставимых по информационной сложности с системами управления крупными предприятиями в других направлениях немного.
V> Просто в последние 5-10 лет это самая емкая и популярная область. И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
У тебя очень примитивное представление об информационных системах предприятий.
eao197 wrote:
> AVK>Ну это как бы тоже велосипедизм. Т.е. как работает типичная > современная РСУБД я представляю хорошо, но вот чтобы свою писать ... > А как же Oracle, MSSQL, DB2 -- их что велосипедисты разрабатывают?
Какие же это велосипеды? Это уже давно тяжелые грузовики.
Здравствуйте, AndrewVK, Вы писали:
AVK>Пока что решений, сопоставимых по информационной сложности с системами управления крупными предприятиями в других направлениях немного.
Сложность эта весьма специфического плана, а именно — обусловлена количеством абстракций и операций над ними. Сами абстракции и тем более операции над ними — более чем примитивны. Я подобную сложность привык именовать рутинностью.
V>> Просто в последние 5-10 лет это самая емкая и популярная область. И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
AVK>У тебя очень примитивное представление об информационных системах предприятий.
Отчего ты так решил? Последние лет 10 бОльшую часть времени именно этим и занимаюсь, к сожалению. (Бухгалтерия, торговля, производство, кадры, ресурсы, аналитика и прогнозирование). Под громкими словами зачастую скрываются обыденные, по сути, вещи (типа, "комплексная система управления предприятием"). Максимум, каким математическим аппаратом приходится оперировать — так это уровня алгебры 7-го класса. (Ну иногда статистикой, но реже)
Горад
Более того, слово "комплексная" зачастую означает интегрирование в нечто условно работающее и почти единое целое различных систем, изначально не предназначенных для совместной работы, и тем не менее... Самый трахательный вид деятельности и самый неблагодарный, кстати, подобная "интеграция".
Когда я частенько повторяю, что тысячи людей по всему миру пишут, по сути, одно и то же, то имею в виду бизнес-приложения в большей степени. Как нигде здесь масса поддающихся унификации вещей. И даже есть тонна стандартов транзакций, те же EDI и их новые XML-ветки. Но мало кто ориентируется на стандарты, везде разношерстица и решения "по месту".
Действительная сложность, с которой порой все же приходится сталкиваться "автоматизаторам" — это именно совмещение несовместимого. Но эти задачи скорее на хитрость и изворотливость, чем на применение каких-либо фундаментальных знаний.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Павел Кузнецов, Вы писали:
>>> Для начала я лишился решарпера и всех прибамбахов студии.
ПК>>VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
AVK>Нет, не умеет даже близко.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>>Далеко не только. Хинты, практически полный конроль синтаксиса на лету, масса хелперов. Рассказывать долго, лучше попробовать.
ПК>>Попробовать вряд ли придется, т.к. для C++ этот инструмент не работает, а с C# мне работать не приходится.
AVK>Не зарекайся.
One of the reasons I stayed at JPL for twelve years was that I was appalled at what the software industry had become. The management world has tried to develop software engineering processes that allow people to be plugged into them like interchangeable components. The "interface specification" for these "components" usually involves a list of tools in which an engineer has received "training." (I really detest the use of the word "training" in relation to professional activities. Training is what you do to dogs. What you should be doing with people is educating them, not training them. There is a big, big difference.)
To my mind, the hallmark of the interchangeable component model of software engineers is Java. Without going into too many details, I'll just say that having programmed in Lisp the shortcomings of Java are glaringly obvious, and programming in Java means a life of continual and unremitting pain. So I vowed I would never be a Java programmer, which pretty much shut me out of 90% of all software engineering jobs in the late 90's. This was OK since I was managing to put together a reasonably successful career as a researcher. But after Remote Agent I found myself more and more frustrated, and the opportunity to work at Google just happened to coincide with a local frustration maximum.
One of the reasons I decided to go work for Google was that they were not using Java. So of course you can guess what my first assignment was: lead the inaugural Java development at the company, what eventually became Google AdWords. Thank God I had a junior engineer working for me who actually knew something about Java and didn't mind it so much. In the ancient tradition of senior-junior relationships, he did all the work, and I took all the credit.
А C# не далеко от Java ушел
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Павел Кузнецов, Вы писали:
>>> Для начала я лишился решарпера и всех прибамбахов студии.
ПК>>VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
AVK>Нет, не умеет даже близко.
Он не умеет только рефакторинг. В смысле навигации, подсказки опеределения при наведении мышкой и подсветки — аналогично.
Здравствуйте, VladD2, Вы писали:
VD>Предлагаю позвать его и спросить его мнение по поводу сложности создания утилит рефакторинга для С++.
Звали?
Если говорить про C++ и рефакторинг, то основную сложность там представляет препроцессор. До сих пор он очень активно используется, а производить рефакторинг когда часть описания или реализации развертывается из макросов — это трындец полнейший.
Если говорить про on-line assitance, то там сложности скорее технические. Как то например совершенно охрененный объем хедеров, которые надо успеть отпарсить/разобрать/разложить по внутренним структурам данных. И аналоги precompiled header тут не спасут поскольку надо быть котовым по малейшему чиху эту операция переделать заново (например, юхер что-то начал печатать в начале файла)
А вообще утилита рефакторинга, работающая с 99% точностью для C++ сейчас уже есть. Насколько я знаю, она даже в состоянии бэты. Пишет ее один мужик из Питера, для собственного развлечения.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, eao197, Вы писали:
E>>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>>>Мало уступает, да? E>>>А как тогда на C# сделать такое: А generic-и так могут?
AF>>Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
E>Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием).
Совершенно согласен. Отделный +1 по поводу мудрого человека.
E>А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Бывает и так, но я вообще-то имел в виду инструментальные средства для рефакторинга, которых для C++ я пока не видел.
E>Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Да, согласен. Но часто бывает так, что в каждом языке есть некоторая своя фенечка, которой в других языках нет и в некоторых ситуациях именно эта фенечка является безумно удобной и полезной. В том же Smalltalk были подобные фенечки (по рассказам — вроде перехвата вызовов методов). Это не означает обязательного превосходства данного языка.
Хотя в целом, Евгений, я с вами согласен — C++ — очень хороший язык. Замечу, что C# — тоже на мой взгляд. Но за ним нет пока такого громадного опыта и истории.
E>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста, кого-то вроде меня
Именно. У них разные цели, задачи и предназначение.
Здравствуйте, eao197, Вы писали:
E>Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием). А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Очень советую попробовать использовать системы рефакторинга. Думаю после этого ты изменишь свое мнение. Незнаю уж почему, но рефакторинг доступен только для шарпа и явы, так что пробовать прийдется на них. Но рефакторинг намного лучше нежели заплаты и ужимки с целью обмануть свой же код. А лучше он потому, что в его результате получается чистый код который легко поддерживать и равивать.
E>Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Это все делать можно. На то есть интерфейсы и делегаты. Единственное что действительно нельзя делать на дженериках, и что можно делать на шаблонах — заниматься вычислениями во время компиляции. Это следствие компонентной природы жденириков и макросно-компиляционной природы шаблонов.
E>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста,
Согласен.
E> кого-то вроде меня
Кокетничаешь?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Xentrax wrote:
> Еще раз. Есть задачи, где неважно на каком языке вы пишете, а важно, > *ЧТО* вы пишете, и какие *ЗНАНИЯ* вы туда закладываете. Хотя наверное > стоит забить на сотни миллионов долларов интеллектуальных инвестиций, > сделанных в код, и перейти на язык, в котором сделано множество > существенных улучшений, например используется необычайно прогрессивная > и насущная технология реализации интерфейсов вместо устаревшего и > неприменимого в реальных задачах множественного наследования.
Да, а в множественное наследование сколько миллионов вложено? Нам что,
сразу всем переходить в технологию, в которую больше $$$ вложено?
Термин "информационная сложность" вы не понимаете — видимо не видели
исходников на С++/Java/... в десятки и _сотни_ мегабайт. Средненькая
программа занимает сейчас больше места чем "Война и Мир", и ошибка в
нескольких строчках может иметь серьезные последствия.
Ну а сложные алгоритмы на Фортране/С/Ассемблере — это не пример
информационной сложности, а пример сложности алгоритмической. Совершенно
другая вещь.
А ведь программы еще и дописывают, и очень часто наблюдается ситуация,
когда из программного "Запорожца" делают "Мерседес". Вы можете
спроектировать автомобиль, который можно будет так доработать без
переделки всей конструкции? А тут многим приходится делать нечто подобное.
Во, я тут вспомнил, что мне это напоминает. Я однажды на форуме Лингво
посмел сказать, что их полная версия дороговата, и что пора думать об
апдейте со скидкой. Ёёёёё, как мне там разработчики стали доказывать,
что лингвисты — самая нужная, важная и тяжелая профессия на земле.
Никто вроде не говорит, что программирование — главная профессия, но вот
недооценивать трудности программирования — глупо.
Здравствуйте, Xentrax, Вы писали:
X>Я позволил себе выделить вашу очень смешную фразу, про то что я не смогу написать RSDN. Я как программист (он же разработчик) и вообще дипломированный специалист по АСУиОбработкеИнформации умею бороться со сложностью, поэтому RSDN я знаю как писать. И даже знал 5 лет назад.
Молодец. Но диплом никак не является признаком неимоверной крутости. Так что давай не будем пиписьками меряться, ОК?
X>Предположим как вам решение, включающее себя спутниковые приемники (включая инфраструтуру — антенны, кабели, триподы), лазерные нивелиры, высокточные теодолиты (включая новые модели с выделением дополнительной информации из изображений), роботизированные бульдозеры, контроллеры, сети виртуальных базовых станций, людей в офисе и в поле, соединить это все информационными потоками и логически — и физически — через радио-модемы, лазерные лучи, GPRS, CDMA, создать собственные процессоры для этого оборудования, да еще и обеспечить интегарцию всего этого с конкурентами, итд итп. Так вот, написать это я не смогу, хотя уже 5-ый год в этом.
Напомню, что форум называется "Философия программирования". Обсуждать проблемы разработки программно-аппаратных комплексов я не хочу, так как занимался этим последний раз давно. И уж тем более не имеет смысл сравнивать язык C# и такую рназработку.
X>Люди (http://www.rsdn.ru/Forum/RateList.aspx?mid=1232538
), я не знаю, чем вы по жизни занимаетесь, но это же правда смешно. Вы СЕРЬЕЗНО думаете, что нет ничего сложнее, чем соединить GotDotNet и RSDN???
Нет. Но мы прекрасно знаем чтолюбой мало-мальски серьезный софт это очень непросто. Идей море, реализаций мало, а качественных реализаций еще меньше. Хотя казалось бы — ну что там сложного.
X>Еще раз. Есть задачи, где неважно на каком языке вы пишете, а важно, ЧТО вы пишете, и какие ЗНАНИЯ вы туда закладываете.
А с чего ты взял, что в RSDN заложено мало знаний?
X>Во, я тут вспомнил, что мне это напоминает. Я однажды на форуме Лингво посмел сказать, что их полная версия дороговата, и что пора думать об апдейте со скидкой. Ёёёёё, как мне там разработчики стали доказывать, что лингвисты — самая нужная, важная и тяжелая профессия на земле.
Ты видимо что то попутал. Я ведь не убеждаю тебя в крутости RSDN конкретно, мне не нравится твое шапкозакидательство, мол, что нам стоит дом построить. Стоит, иначе бы мы давно бы жили с кучей крутейшего и безглючного софта в тех сферах, которые вроде как затрат на R&D не требуют.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>vs. C++/CLI, а большинство твоих претензий относится к Microsoft Managed Extensions for C++.
А поподробнее можно насчет отличий C++/CLI & Managed C++? Может зря я трачу время на всякую фигню, а есть волшебный чекбокс, выбрав который все проблемы решаются?
Здравствуйте, Павел Кузнецов, Вы писали:
>> Нет, не умеет даже близко.
ПК>Речь идет о поддержке элементарных операций "рефакторинга", или о чем-то другом?
Далеко не только. Хинты, практически полный конроль синтаксиса на лету, масса хелперов. Рассказывать долго, лучше попробовать. Расскажу только о результате — продуктивность увеличивается в 2-3 раза.
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>Далеко не только. Хинты, практически полный конроль синтаксиса на лету, масса хелперов. Рассказывать долго, лучше попробовать.
ПК>Попробовать вряд ли придется, т.к. для C++ этот инструмент не работает, а с C# мне работать не приходится.
Не зарекайся.
AVK>> Расскажу только о результате — продуктивность увеличивается в 2-3 раза.
ПК>Я так понимаю, по сравнению с программированием с использованием "голой" студии? С Visual Assist вряд ли корректно сравнивать продуктивность: по-моему, последний с C# работать не умеет.
По твоему может быть, а на самом деле умеет. И я им довольно долго в свое время пользовался. Резюме — просто не сравнить (в частности от VA я в итоге отказался).
VladD2,
> VisualAssist верт, глючит и тормозит. Ну, а по функциональности он действительно сопостовим.
У меня Assist не глючит и не тормозит
> ПК> — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper... > > И одного процента не умеет.
Так "по функциональности сопоставим" или "и одного процента не умеет"?
> ПК>Если использовать C++/CLI в режиме, аналогичном C#, т.е. импортировать namespaces .Net, а не пользоваться #include, скорость компиляции будет +- такая же.
> Не. Не такая же, а всего раза в 3 медленее. Но вот вопрос "нахрена козе баян"? Ну, зачем сдался МС++ в применяемый в режиме Шарпа? Траха больше, толку меньше.
Или наоборот: "толку больше, траха меньше". Очень содержательная дискуссия Если хочешь, что-то сказать по делу, содержательно, а не выплеснуть эмоции — скажи, не таись. Пока что информационная ценность стремится к 0 за отсутствием конкретики.
> ПК>Это все о Managed Extensions for C++, а не о C++/CLI. > > Да, да. Как щаз помню... Пытался свойство описать. Долго пытался понять кто идион я или компилятор.
Я, пожалуй, воздержусь от вывода.
<... остаток эмоций опущен ...>
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
AVK>>Пока что решений, сопоставимых по информационной сложности с системами управления крупными предприятиями в других направлениях немного.
E>Решений или задач?
Сложно их отделить. Реально стоящие задачи обычно появляются при технической возможности их решения.
E>Просто для оценки объективности твоего высказывания: какими еще задачами тебе приходилось заниматься?
Пиписьками хочешь померяться? Ну давай
1) Система 3D рендеринга (давно, во-времена 3D Studio под ДОС)
2) Система захвата целей не скажу для чего.
3) Система обнаружения утечек в нефтепродуктопроводе.
Здравствуйте, eao197, Вы писали:
E>Нет, не достаточно.
E>А где математические расчеты? Например, реализация методов конечных/граничных элементов и решение СЛАУ большой размерности.
Да там практически во всех трех пунктах математики хватает.
E> Или распознавание образов?
п.2 в большом объеме, п.3 немного. В обоих это ключевой функционал.
E>А где создание компиляторов (начиная от лексического анализа и заканчивая глобальной оптимизацией машинного кода)?
Написал свой интерпретатор, немного ковырялся в R#. Но это мелочи.
E>А где разработка ОС? Например, ОС реального времени.
Этого не доводилось. Столь явно выраженный велосипедизм мне претит.
E>А где программирование для встраиваемых систем или скажем сигнальных процессоров?
п. 2
E>А где разработка САПР?
E>А где разработка middleware компонентов?
Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
E>А где разработка СУБД (самих СУБД)?
Ну это как бы тоже велосипедизм. Т.е. как работает типичная современная РСУБД я представляю хорошо, но вот чтобы свою писать ...
E>Это только то, что в голову пришло. А сколько еще вещей, про которые я даже понятия не имею...
Ну и? Что теперь? Я не могу судить о том в каком направлении какая сложность систем? Ну пусть так. Но тогда, ради симметрии, высказывание vdimas ничуть не лучше, не так ли?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
V>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT. Все остальные гораздо сложнее. Просто в последние 5-10 лет это самая емкая и популярная область. И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
Дима, а какую именно область IT ты считаещь более сложной, чем бизнес-приложения?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Сложность эта весьма специфического плана, а именно — обусловлена количеством абстракций и операций над ними. Сами абстракции и тем более операции над ними — более чем примитивны. Я подобную сложность привык именовать рутинностью.
Это зависит от подхода. Если решать подобные задачи в лоб, то оно конечно. Но практически всегда существуют решения, позволяющие от рутины избавится, поскольку рутина это ничто иное как повторяющиеся однотипные простые действия, как ты справедливо заметил, следовательно это хорошее место для автоматизации.
AVK>>У тебя очень примитивное представление об информационных системах предприятий.
V>Отчего ты так решил? Последние лет 10 бОльшую часть времени именно этим и занимаюсь, к сожалению. (Бухгалтерия, торговля, производство, кадры, ресурсы, аналитика и прогнозирование). Под громкими словами зачастую скрываются обыденные, по сути, вещи (типа, "комплексная система управления предприятием"). Максимум, каким математическим аппаратом приходится оперировать — так это уровня алгебры 7-го класса. (Ну иногда статистикой, но реже)
Математика это не единственная сложнае вещь в этом мире.
V>Когда я частенько повторяю, что тысячи людей по всему миру пишут, по сути, одно и то же, то имею в виду бизнес-приложения в большей степени. Как нигде здесь масса поддающихся унификации вещей. И даже есть тонна стандартов транзакций, те же EDI и их новые XML-ветки. Но мало кто ориентируется на стандарты, везде разношерстица и решения "по месту".
А, так все таки проблема не в самой категории софта, а в неверных решениях с которыми ты сталкивался. Так почему ты тогда огульно обвинил всю отрасль? Поверь, в этой сфере встречаются весьма непростые задачи с красивыми и нетривиальными решениями.
V>Но эти задачи скорее на хитрость и изворотливость, чем на применение каких-либо фундаментальных знаний.
А фундаментальные знания по твоему это только математика?
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Нет там такой резкой границы. Где то пользуются большим количеством middleware, где то меньшим, а остальное дописывают самостоятельно. В идеале собственно прикладная логика должна задаваться на примитивном DSL (вся). И вот чтобы решить эту мегазадачу нужно приложить массу усилий.
ГВ>На примитивном языке лучше всего решать несложные задачи. Т.н. "прикладной функционал" к таковым относится дадлеко не всегда. Собственно, примеров использования "примитивных языков" для программирования прикладной логики — пруд пруди, скажем, тот же VB6. И что? Да уродство на выходе получается! А T-SQL? Уж куда примтивнее! А чудовища ещё те получаются.
Видимо ты плохо понял, что он сказал. Слово "примитивный" явно подразумивало не "убогий", а простой в использовании. DSL же подразумевает, что это язык описывающий прикладную область (доменную). Так что DSL описывает область на нужном уровне просто по определению. Иначе он не DSL.
А мега-задача — это как раз создать максимально простой но выразительный DSL и максимально навороченный его интерпретатор/компилятор который позволит не писать рутинного кода вообще.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Патрик, Вы писали:
П>Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API
Грамотным пользованием чужим АПИ многие задачи сводятся на нет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>здесь
K>Хочется узнать ваше мнение
Думаю это перегиб. C++ изначально задумывался как объектно-ориентирование расширение C, причём расшерение, сохраняющее одну из главных прелестей языка — тестную связь с аппаратурой и возможность работать с ней напрямую. Причём работать эффективно. В тоже время язык обладает полномасштабной поддержкой концепций ООП. Сочетание этих важных особенностей языка во многом и обеспечило столь огромную его популярность. Однако C++ не задумывался для работы со сборщиками мусора. В нём до последнего времени не было поддержки свойств, нет поддержки атрибутов — метаинформации. То есть того, что вышло во многих задачах на передний край в наше время.
Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
AF> Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
C++/CLI это тот же С++ плюс добавленный набор синтаксических фич для работы с managed кодом. Я считаю что он будет использоваться для поддержки ранее написанного на С++ коде, для тех участков где действительно важна скорость, там где GC не справляется (а такие места я думаю есть и будут есть). Причем на С++/CLI можно в приниципе писать точно так же как и на Си шарпе, плюс возможности писать unmanaged код (знаю что в С# есть unsafe участки, но все таки это не то).
Лично я считаю, что эти два языка не взаимоисключают друг друга, у них совершенно разная философия, они будут долго существовать вместе как мне кажется.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
AF>> Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
K>C++/CLI это тот же С++ плюс добавленный набор синтаксических фич для работы с managed кодом. Я считаю что он будет использоваться для поддержки ранее написанного на С++ коде, для тех участков где действительно важна скорость, там где GC не справляется (а такие места я думаю есть и будут есть). Причем на С++/CLI можно в приниципе писать точно так же как и на Си шарпе, плюс возможности писать unmanaged код (знаю что в С# есть unsafe участки, но все таки это не то).
Полностью согласен.
K>Лично я считаю, что эти два языка не взаимоисключают друг друга, у них совершенно разная философия, они будут долго существовать вместе как мне кажется.
И тут полностью согласен. Собственно именно это я и имел в виду, когда написал, что статья содержит явный перегиб.
Для меня ближе, роднее и любимее С++ — как для микроэлектронщика. Ну люблю я в регистрах покопаться... Но как для архитектора или дизайнера — мне ближе Java или C# (возможно и Smalltalk и даже Оберун, если бы я их знал )
Чем мне понравился тот же C# — так это та же Jaba, но язык живой, со множеством полезных, практичных доплнений, делающих его более удобным и практичным.
Я думаю что у обоих языков есть хорошее будущее — у каждого своё — своя область, где он более удобен. Со временем появятся новые языки, которые превзойдут и тот и другой (в своей области применения) и двинутся дальше.
Здравствуйте, VladD2, Вы писали:
E>>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста,
VD>Согласен.
E>> кого-то вроде меня
VD>Кокетничаешь?
Нет, подумываю о смене деятельности. Например, о переходе в технические писатели. Вот кой-какой опыт. Или вот еще.
Жаль только, что правописание хромает.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Повторит судьбу в каком смысле? В том что оставшиеся непокобелимые остатки C++ девелоперов таки попробуют C++/CLI, подсядут на .NET, так между прочим случайно попробуют C# и опаньки? Знакомая история
Именно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Хочется узнать ваше мнение
По сути эти дискуссии сводятся к двум пунктам
1. Если что-то надо учить больше двух месяцев, то это бесполезно и даже вредно
2. Брось это старье, смотри сюды, какая фенька, и "мы наш мы новый мир построим".
По пункту 2 нужно понять, что есть два типа программ — с заложенным интеллектуальным трудом и без оного. Всяческие веб-конференции, калькуляторы и небольшие программы складского учета в принципе все равно, на чем писать. Более сложные программы обычно наследуют старый код, написание которого по новой требует времени программистов-специалистов в предметной области. Т.е., если калькулятор или даже RSDN я сейчас сяду и напишу, то FineReader я не напишу, потому что не представляю, как это делается.
Причем надо еoе заметить, что IT индустрия замедляется, и дело даже не в том, что технологии медленнее заменяют друг друга, а в том что новые технологии очень похожи на старые, причем зачастую наблюдается регресс — неплохие языки Java и C# до сих пор иногда продвигаются как спеицальный такой C++ для идиотов (вспомним про понятие Learning Curve и плавно перейдем к пукту 1). Отметим только такое "исключение", как Asp.Net, где зачастую наследуется код VB...
По пункту 1. Почему когда у нас случается острый аппендицит, мы все жутко боимся и стараемся дать кому-нибудь денег, только не попасть к свежеиспеченному хирургу, несомненно изучившему самые современные технологии и способы удаления аппендицита. Архитектору-энтузиасту с красным дипломом мы все равно побоимся доверить проект небоскреба. Во многи профессиях опыт в лет 10 считается обязательным, и только программистов перестают брать на работу в 35 лет. Это связано именно с быстрым развитием отрасли в последние годы, но концепции программирования фактически устоялись — обаалдеть нововведение в C# — generics! Ех-ты-ж! Что это мне напоминает?
И тут наоборот, сбывается мечта идиотов — в работе реально нужны мощные инструменты, так как у программистов появляется время их освоить.
Ну а то, что стандартизаторы С++ тормозят развитие языка, это наша общая большая беда. reflection и properties не хватает, конечно. Поразительно, что многочисленные пользовтаели, стонущие из-за их отсутсвия, не могут уже много лет самоорганизоваться и потребовать этих измениий.
olegkr,
> Как я понимаю вопрос стоит в C# vs managed C++?
vs. C++/CLI, а большинство твоих претензий относится к Microsoft Managed Extensions for C++.
> Для начала я лишился решарпера и всех прибамбахов студии.
VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
> Дальше с интересом отметил ужасающую скорость компиляции. В разы медленнее кода на C#.
Если использовать C++/CLI в режиме, аналогичном C#, т.е. импортировать namespaces .Net, а не пользоваться #include, скорость компиляции будет +- такая же. А за счет использования компоновщика потенциально еще и чуть быстрее, т.к. при изменении одного файла остальные не нужно перекомпилировать.
> Пришлось заодно вспомнить приколы с хедерами, с раздельной декларацией и реализацией метода.
Если использовать C++/CLI в режиме, аналогичном C#, то это не нужно. Хотя, имхо, полезно.
> Ну и конечно, куча мелочевок, завязанных именно на синтаксис: > 1. Events, properties ну очень "красиво" и громоздко выглядят. > 2. Так же весьма "приятно" постоянно писать __box для боксинга. > 3. Приведение типов... вместо as и (Type) извольте использовать громоздкие __try_cast & dynamic_cast. > 4. Передача аргументов для функции с переменным количеством оных вынуждает использовать конструкцию Object* args[] = { ... }; Method(args);
Это все о Managed Extensions for C++, а не о C++/CLI.
> 5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
Спорный вопрос, что лучше.
> 6. Поимел проблемку с NullReferenceException при __nogc new. Решилось поиском в гугле и прописыванием нужной либы линкеру. Уж и забыл, что линкер имеется
Тут не знаю, как это будет в C++/CLI.
> Так в чем же плюсы плюсов?
В больших возможностях: в более развитой объектной модели, в поддержке детерменированного разрушения в т.ч. и для ref classes, в наличии полноценных шаблонов и т.п.
> К чему собственно агитирует автор по исходной ссылке?
К тому, чтоб посмотреть на C++/CLI.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Для начала я лишился решарпера и всех прибамбахов студии.
ПК>VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, FR, Вы писали:
FR>>А вот эти?:
O>Навскидку.
FR>>Ref++ http://www.ideat-solutions.com/index.htm
O>Только рефакторинг. К тому же не так уж много методов.
Чего именно не хватает?
FR>>SlickEdit http://www.slickedit.com/content/view/73/60/
O>Доступен либо, как отдельная среда, либо в виде плагина к эклипсу. Функционал то же не особо впечатлил.
Я раньше работал с версией 8.0, не хуже чем VC6-7. autocomplit и т. п. работал гораздо лучше чем в VC71.
Здравствуйте, FR, Вы писали:
FR>Чего именно не хватает?
Например, у решарпера есть еще в дополнении такие методы рефакторинга:
— Move types with reference correction
— Extract type to a new file
— Inline variable
— Convert method to property
— Convert property to method(s)
— Extract Interface
— Copy Type
— Introduce Field
— Encapsulate Field
— Introduce Parameter
— Convert Interface to Abstract Class
— Convert Abstract Class to Interface
Но это не самое главное, больше всего мне нравится
— Автокоррекция ошибок (нажал, к примеру, Alt+Enter и сделал преобразование типа)
— Само собой, подсветка ошибок и предупреждений. Правда она иногда глючит. Например, решарпер не знает, что enum можно сравнивать с null
— Настраиваемые шаблоны
— Форматирование исходников по заданным правилам. оченно помогает, когда приходит из CVS код какого-нить индуса
— Интеллектуальный комплит, которые выбирает не все подряд, а то, что подходит по типу
— Удобная навигация. Нажал Ctrl+N, ввел часть названия класса и перепрыгнул на него. Когда в проекте несколько тыщ классов — весьма актуально. Ну и конечно, поиск референсов.
FR>Я раньше работал с версией 8.0, не хуже чем VC6-7. autocomplit и т. п. работал гораздо лучше чем в VC71.
По правде сказать в VC71 вообще мало какие удобства работают для С++
AndrewVK,
>>> Для начала я лишился решарпера и всех прибамбахов студии.
> ПК>VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
> Нет, не умеет даже близко.
Речь идет о поддержке элементарных операций "рефакторинга", или о чем-то другом?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
FR wrote:
> FR>>SlickEdit http://www.slickedit.com/content/view/73/60/ > O>Доступен либо, как отдельная среда, либо в виде плагина к эклипсу. > Функционал то же не особо впечатлил. > Я раньше работал с версией 8.0, не хуже чем VC6-7. autocomplit и т. п. > работал гораздо лучше чем в VC71.
olegkr,
> ПК> C++/CLI, а большинство твоих претензий относится к Microsoft Managed Extensions for C++.
> А поподробнее можно насчет отличий C++/CLI & Managed C++?
Кратко об отличиях — здесь. Подробно — здесь. Еще ссылки о C++/CLI — например, здесь.
> Может зря я трачу время на всякую фигню, а есть волшебный чекбокс, выбрав который все проблемы решаются?
Чекбокс в Visual Studio 2003 выбрать не получится, если ты об этом, т.к. обсуждаемая статья говорит о следующей версии C# и C++ для .Net. Соответствующая функциональность C++/CLI будет доступна в Visual Studio 2005.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, olegkr, Вы писали:
O>Например, у решарпера есть еще в дополнении такие методы рефакторинга: O>- Move types with reference correction O>- Extract type to a new file O>- Inline variable O>- Convert method to property O>- Convert property to method(s) O>- Extract Interface O>- Copy Type O>- Introduce Field O>- Encapsulate Field O>- Introduce Parameter O>- Convert Interface to Abstract Class O>- Convert Abstract Class to Interface
O>Но это не самое главное, больше всего мне нравится O>- Автокоррекция ошибок (нажал, к примеру, Alt+Enter и сделал преобразование типа) O>- Само собой, подсветка ошибок и предупреждений. Правда она иногда глючит. Например, решарпер не знает, что enum можно сравнивать с null O>- Настраиваемые шаблоны O>- Форматирование исходников по заданным правилам. оченно помогает, когда приходит из CVS код какого-нить индуса O>- Интеллектуальный комплит, которые выбирает не все подряд, а то, что подходит по типу O>- Удобная навигация. Нажал Ctrl+N, ввел часть названия класса и перепрыгнул на него. Когда в проекте несколько тыщ классов — весьма актуально. Ну и конечно, поиск референсов.
У Ассиста тоже есть некоторые преимущества, но в последнее время он глючит все сильнее и сильнее — баги плодятся со страшной скоростью. Это при том, что исправлять старые баги никто и не чешется
Здравствуйте, AndrewVK, Вы писали:
>>> Нет, не умеет даже близко.
ПК>>Речь идет о поддержке элементарных операций "рефакторинга", или о чем-то другом?
AVK>Далеко не только. Хинты, практически полный конроль синтаксиса на лету, масса хелперов. Рассказывать долго, лучше попробовать.
Попробовать вряд ли придется, т.к. для C++ этот инструмент не работает, а с C# мне работать не приходится.
AVK> Расскажу только о результате — продуктивность увеличивается в 2-3 раза.
Я так понимаю, по сравнению с программированием с использованием "голой" студии? С Visual Assist вряд ли корректно сравнивать продуктивность: по-моему, последний с C# работать не умеет.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Xentrax, Вы писали:
X>Чтобы получить фиксированное решение на 50 километровой базовой линии, недостаточно хорошо знать язык C#. Чтобы у вас безотражательный теодолит работал на расстоянии в километр, C# уже не поможет. Зная C#, вы не построите сеть виртуальных базовых станций, потому что дело не в языке, а в математике. И вот, я каждый день вижу людей, которые все это делают. И это работает.
А кто то утверждал что для решения любых задачь достаточно знания одного C#?
Или этот пассаж доказывает, что решение описанных проблем на C# было бы сложенее или хотя бы не легче? Тогда к чему вся эта куча слов?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>vs. C++/CLI, а большинство твоих претензий относится к Microsoft Managed Extensions for C++.
Вот давича имел точно такой же трах с C++/CLI. И пришлось констатировать факт, что ничего не меняется. Трах на месте.
ПК>VisualAssist не пробовал?..
Паш, пробовали твой VisualAssist. Более того, года 3 назад только на нем и жили. Только VisualAssist по сравнению с C# + МЫ 2005 и уж темболее по сравнению с решарпером — это все равно что отбойный молоток по сравнению с роторным эксковатором в открытом разрезе. Хотя аналогия не очень похожая. Отбойный молоток не глючит и не врем. А VisualAssist верт, глючит и тормозит. Ну, а по функциональности он действительно сопостовим.
ПК> — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
И одного процента не умеет.
ПК>Если использовать C++/CLI в режиме, аналогичном C#, т.е. импортировать namespaces .Net, а не пользоваться #include, скорость компиляции будет +- такая же.
Не. Не такая же, а всего раза в 3 медленее. Но вот вопрос "нахрена козе баян"? Ну, зачем сдался МС++ в применяемый в режиме Шарпа? Траха больше, толку меньше.
ПК> А за счет использования компоновщика потенциально еще и чуть быстрее,
Точно. Лишний шаг он всегда потенциально скорость увличивает.
ПК> т.к. при изменении одного файла остальные не нужно перекомпилировать.
Ты зайди в студию, создай шарповский проект... и погляди в его настройки. Увидишь там ошцию инкриментальной компиляции. Прочитай по ней хэлп...
А лучше не пытайся придумть отмазки, а просто создай два проекта и измерий время компиляции. Нечего тут теорию разводить. Тут все просто как три копейки.
>> Пришлось заодно вспомнить приколы с хедерами, с раздельной декларацией и реализацией метода.
ПК>Если использовать C++/CLI в режиме, аналогичном C#,
ПК> то это не нужно. Хотя, имхо, полезно.
Чё в С++ предварительную декларацию отеменили?
ПК>Это все о Managed Extensions for C++, а не о C++/CLI.
Да, да. Как щаз помню... Пытался свойство описать. Долго пытался понять кто идион я или компилятор.
>> 5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
ПК>Спорный вопрос, что лучше.
Ооочень.
ПК>В больших возможностях
Это — да. Но тут есть одна загвоздка. 99% кода в библиотеках дотнета написаны на Шарпе. МС++ там и не пахнет. Видимо те кто его писали были глупыми и не знали о болших возможностя.
ПК>: в более развитой объектной модели,
О, да. Она в МС++ более объектная.
ПК> в поддержке детерменированного разрушения в т.ч. и для ref classes, в наличии полноценных шаблонов и т.п.
О, да. Как тупые шарповцы обходятся using совсем не ясно. Ведь кругом одни анменеджед-ресурсы! Ну, тупые они.
И главное не верь тем кто после года программирования на Шарпе пытается снова сесть за плюсы и испытывает жудкий дискомфорт. Это ни все назло тебе придумывают. Ну, чтобы позлить и направить на неверный путь.
>> К чему собственно агитирует автор по исходной ссылке?
ПК>К тому, чтоб посмотреть на C++/CLI.
Паш, МС++ мог все что может С++. Поверь, что если бы это было хоть кому-то надо, то все давно писали на МС++, а не на шарпе.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Речь идет о поддержке элементарных операций "рефакторинга", или о чем-то другом?
> О другмо. О удобстве работы. Фичи нафиг не упали. Нужно чтобы было удобно. Вот этого и нет.
Мне с Visual Assist удобно
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Попробовать вряд ли придется, т.к. для C++ этот инструмент не работает, а с C# мне работать не приходится.
Чтобы попробовать не обязательно рабоать. Я вот не работая на винной факбрике легко пробую вино.
ПК>Я так понимаю, по сравнению с программированием с использованием "голой" студии?
АВК еще сильно скромничает.
ПК> С Visual Assist вряд ли корректно сравнивать продуктивность: по-моему, последний с C# работать не умеет.
Ты бы хоть ради хохмы попробовал. Visual Assist еще год назад с Шарпом работал лучше чем с С++.
ЗЫ
А все Visual Assist нервно курят в углу.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Мне с Visual Assist удобно
Кому и кобыла невеста (с)
Visual Assist недотянет до решарпера не потому, что его разрабатывают менее квалифицированные люди. Тут проблема в другом и ты прекрасно понимашь в чем.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexeiz, Вы писали:
A>Странное определение полноценного компилятора, очевидно, приведенное здесь для того, чтобы количество оных было не больше одного.
Приведенное для того, чтобы объяснить почему корректные и полноценные утилиты рефакторинга для С++ сделать очень сложно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>А сколько полноценных компиляторов C#?
3. Но других нет.
WH>ЗЫ Учитывая что xvost постоянно плачется в форуме .NET о том что он ничего не понимает...
Он плачется об ошибках. Причем очень специфичных. Ну, и как видишь xvost является разработчиком того самого решарпера который очень так живо рефакторит этот самый C#.
Предлагаю позвать его и спросить его мнение по поводу сложности создания утилит рефакторинга для С++.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Он не умеет только рефакторинг. В смысле навигации, подсказки опеределения при наведении мышкой и подсветки — аналогично.
Так, на всякий случай — решарпер в основном ради рефакторинга и сделан и это главный его функционал. И именно из-за рефакторинга совмещенного со смарттегами он так сильно ускоряет процесс написания кода.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT.
AVK>Не думаю.
V>> Все остальные гораздо сложнее.
AVK>Пока что решений, сопоставимых по информационной сложности с системами управления крупными предприятиями в других направлениях немного.
Решений или задач?
Просто для оценки объективности твоего высказывания: какими еще задачами тебе приходилось заниматься?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Пока что решений, сопоставимых по информационной сложности с системами управления крупными предприятиями в других направлениях немного.
E>>Решений или задач?
AVK>Сложно их отделить. Реально стоящие задачи обычно появляются при технической возможности их решения.
E>>Просто для оценки объективности твоего высказывания: какими еще задачами тебе приходилось заниматься?
AVK>Пиписьками хочешь померяться? Ну давай
Нет, годы уже не те, чтобы чем-то меряться.
AVK>1) Система 3D рендеринга (давно, во-времена 3D Studio под ДОС) AVK>2) Система захвата целей не скажу для чего. AVK>3) Система обнаружения утечек в нефтепродуктопроводе.
AVK>Достаточно?
Нет, не достаточно.
А где математические расчеты? Например, реализация методов конечных/граничных элементов и решение СЛАУ большой размерности. Или распознавание образов?
А где создание компиляторов (начиная от лексического анализа и заканчивая глобальной оптимизацией машинного кода)?
А где разработка ОС? Например, ОС реального времени.
А где программирование для встраиваемых систем или скажем сигнальных процессоров?
А где разработка САПР?
А где разработка middleware компонентов?
А где разработка СУБД (самих СУБД)?
Это только то, что в голову пришло. А сколько еще вещей, про которые я даже понятия не имею...
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
E>>А где создание компиляторов (начиная от лексического анализа и заканчивая глобальной оптимизацией машинного кода)?
AVK>Написал свой интерпретатор, немного ковырялся в R#. Но это мелочи.
Угу.
E>>А где разработка ОС? Например, ОС реального времени.
AVK>Этого не доводилось. Столь явно выраженный велосипедизм мне претит.
А причем здесь велосипедизм?
Ты был сотрудником Sun (Solaris, хотябы), HP (HP-UX, NonStopKernel), IBM (AIX), Microsoft (Win, WinCE)? Эти компании выпускают коммерческие ОС. Равно как и производители специализированных ОС типа QNX, VxWorks.
E>>А где разработка middleware компонентов?
AVK>Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
Т.е. ты пишешь софт типа JBoss Application Server или Corba ORB?
E>>А где разработка СУБД (самих СУБД)?
AVK>Ну это как бы тоже велосипедизм. Т.е. как работает типичная современная РСУБД я представляю хорошо, но вот чтобы свою писать ...
А как же Oracle, MSSQL, DB2 -- их что велосипедисты разрабатывают?
E>>Это только то, что в голову пришло. А сколько еще вещей, про которые я даже понятия не имею...
AVK>Ну и? Что теперь? Я не могу судить о том в каком направлении какая сложность систем? Ну пусть так. Но тогда, ради симметрии, высказывание vdimas ничуть не лучше, не так ли?
Не совсем так. Возможно, что vdimas знаком с направлениями, которые сложнее, чем разработка бизнес-софта.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ты был сотрудником Sun (Solaris, хотябы), HP (HP-UX, NonStopKernel), IBM (AIX), Microsoft (Win, WinCE)? Эти компании выпускают коммерческие ОС. Равно как и производители специализированных ОС типа QNX, VxWorks.
Увы, в России таких компаний нет.
AVK>>Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
E>Т.е. ты пишешь софт типа JBoss Application Server или Corba ORB?
Ага.
AVK>>Ну это как бы тоже велосипедизм. Т.е. как работает типичная современная РСУБД я представляю хорошо, но вот чтобы свою писать ...
E>А как же Oracle, MSSQL, DB2 -- их что велосипедисты разрабатывают?
Нет. Но я то о себе говорю.
AVK>>Ну и? Что теперь? Я не могу судить о том в каком направлении какая сложность систем? Ну пусть так. Но тогда, ради симметрии, высказывание vdimas ничуть не лучше, не так ли?
E>Не совсем так. Возможно, что vdimas знаком с направлениями, которые сложнее, чем разработка бизнес-софта.
Ну так я тоже знаком. А вот знаком ли он с разработкой софта вроде упомянутого тобой JBoss? Ой, что это я, чур меня, чур.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Ты был сотрудником Sun (Solaris, хотябы), HP (HP-UX, NonStopKernel), IBM (AIX), Microsoft (Win, WinCE)? Эти компании выпускают коммерческие ОС. Равно как и производители специализированных ОС типа QNX, VxWorks.
AVK>Увы, в России таких компаний нет.
МинОбороны?
Где-то же os2000 (или как она сейчас называется) клепают.
AVK>>>Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
E>>Т.е. ты пишешь софт типа JBoss Application Server или Corba ORB?
AVK>Ага.
Понятно. Только я думал, что бизнес-софт это тот, что поверх JBoss работает. А сам JBoss -- это больше к системному (в смысле, что не к прикладному) программированию относится.
AVK>>>Ну это как бы тоже велосипедизм. Т.е. как работает типичная современная РСУБД я представляю хорошо, но вот чтобы свою писать ...
E>>А как же Oracle, MSSQL, DB2 -- их что велосипедисты разрабатывают?
AVK>Нет. Но я то о себе говорю.
Ну как сказать. Если уж о велосипедах говорить, то их ведь пишут не столько потому, что они нужны. Сколько потому, что хочется.
Вот, например, у Константина Книжника очень даже ничего получается.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Увы, в России таких компаний нет.
E>МинОбороны?
Не смешно.
E>>>Т.е. ты пишешь софт типа JBoss Application Server или Corba ORB?
AVK>>Ага.
E>Понятно. Только я думал, что бизнес-софт это тот, что поверх JBoss работает.
Business software is generally any software program that helps a business increase productivity or measure their productivity.
E> А сам JBoss -- это больше к системному (в смысле, что не к прикладному) программированию относится.
А кто говорил про прикладное программирование? Говорили именно про бизнес-софт. А пользуется ли этот софт готовыми платформами и серверами, или содержит свои, аналогичные но специализированные средства, это уже детали.
AVK>>Нет. Но я то о себе говорю.
E>Ну как сказать. Если уж о велосипедах говорить, то их ведь пишут не столько потому, что они нужны. Сколько потому, что хочется.
Тогда это точно не ко мне. Бесполезная деятельность интереса у меня не вызывает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Увы, в России таких компаний нет.
E>>МинОбороны?
AVK>Не смешно.
А я и не думал смеятся.
Кто-то же os2000 разрабатывает. И я уверен, он не считает, что писать бизнес-софт сложнее.
E>>>>Т.е. ты пишешь софт типа JBoss Application Server или Corba ORB?
AVK>>>Ага.
E>>Понятно. Только я думал, что бизнес-софт это тот, что поверх JBoss работает.
AVK>http://en.wikipedia.org/wiki/Business_software AVK>
Business software is generally any software program that helps a business increase productivity or measure their productivity.
Тогда ReSharper и IDEA -- это тоже бизнес софт?
(а это я уже шучу )
AVK>>>Нет. Но я то о себе говорю.
E>>Ну как сказать. Если уж о велосипедах говорить, то их ведь пишут не столько потому, что они нужны. Сколько потому, что хочется.
AVK>Тогда это точно не ко мне. Бесполезная деятельность интереса у меня не вызывает.
Ты наверное очень серьезно свою деятельность воспринимаешь
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
E>>А где разработка middleware компонентов?
AVK>Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
Да не бизнес это софт. Это инструмент для оного, и задача чуть более интересная, ИМХО.
В принципе, в этой разношерстице пора вводить стандарты более-менее высокого уровня. (Как например, на прикладные транзакции EDI, HIPPA и пр.), но только на уровне именно программных интерфейсов/структур данных/протоколов.
Если ввести подобные стандарты, то разработка middleware стала бы еще более благородной задачей, ибо гораздо более повторно применимой.
Кстати, какие, елси не секрет, компоненты разрабатываешь и по каким стандартам?
Здравствуйте, eao197, Вы писали:
E>А я и не думал смеятся. E>Кто-то же os2000 разрабатывает. И я уверен, он не считает, что писать бизнес-софт сложнее.
А я думаю что если там люди нормальные, то они вобще никакую область сильно проще другой не считают и понимают что везде есть свои заморочки, поскольку тому есть вполне объективные причины.
AVK>>Тогда это точно не ко мне. Бесполезная деятельность интереса у меня не вызывает.
E>Ты наверное очень серьезно свою деятельность воспринимаешь
Да нет, просто есть масса интересных вещей, которые к тому же и полезны.
Здравствуйте, vdimas, Вы писали:
E>>>А где разработка middleware компонентов?
AVK>>Это основная моя специализация. Только это же тот самый бизнес-софт, на который товарищь так гневно обрушился.
V>Да не бизнес это софт. Это инструмент для оного, и задача чуть более интересная, ИМХО.
Нет там такой резкой границы. Где то пользуются большим количеством middleware, где то меньшим, а остальное дописывают самостоятельно. В идеале собственно прикладная логика должна задаваться на примитивном DSL (вся). И вот чтобы решить эту мегазадачу нужно приложить массу усилий.
V>Кстати, какие, елси не секрет, компоненты разрабатываешь и по каким стандартам?
Платформу для средних предприятий. Подробнее сказать пока не могу.
Здравствуйте, vdimas, Вы писали:
V>В принципе, в этой разношерстице пора вводить стандарты более-менее высокого уровня. (Как например, на прикладные транзакции EDI, HIPPA и пр.), но только на уровне именно программных интерфейсов/структур данных/протоколов.
Вот тут позволю себе не согласиться. Поскольку появится масса стандартов для разных прикладных областей.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT. Все остальные гораздо сложнее.
Ну не совсем так. На самом деле, из того факта, что чаще всего заметны задачи типа "вынуть-из-БД-отобразить-в-Web" такого обобщения сделать нельзя. Структура информационной системы может по сложности ну ой как перемахивать через компиляторы и ОС. Просто сложность здесь заключается в:
— Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.);
— Необходимости сильной адаптации интерфейса пользователя к требованиям конечного пользователя;
— Необходимости согласования работы ИС с целой кучей софта, уже имеющегося у покупателя (нередко).
V>Просто в последние 5-10 лет это самая емкая и популярная область.
Не... в последние, эдак, лет 40. И такая ситуация — навсегда, увы.
V>И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
В сущности — да, без умения оперировать чужими АПИ никуда, но это очень примитивное обобщение.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Просто для оценки объективности твоего высказывания: какими еще задачами тебе приходилось заниматься?
IT>
IT>А из каких частей по-твоему состоят бизнес-приложения и сайты? vdimas уже озвучил свою точку зрения, по его мнению они состоят из базы данных и формочек. А по-твоему?
Про бизнес-приложения не скажу, поскольку понятие довольно размытое. Какая-нибудь хрень, которая опрашивает котировки акций и рассылает их в виде SMS-ов руководителям какой-нибудь фирмы так же может считаться бизнес-приложением.
А сайты, в принципе, состоят из web-сервера, какого-то сервера приложений (если вспомнить Java) и БД. Там где мне пришлось этим заниматься, web-проложение пыталось на основе данных в БД и запросов пользователя выдать список наводящих вопросов. Затем, после уточнения -- еще один список и т.д., пока пользователь либо не будет удовлетворен, либо не опишет собственный случай отдельно. Собственно обычная задача, только что через web-интерфейс должна была работать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет там такой резкой границы. Где то пользуются большим количеством middleware, где то меньшим, а остальное дописывают самостоятельно. В идеале собственно прикладная логика должна задаваться на примитивном DSL (вся). И вот чтобы решить эту мегазадачу нужно приложить массу усилий.
Слово "в идеале" — ключевое. Я примерно так себе и представляю "правильную" разработку бизнес-систем. То, что вижу сейчас, это зачастую решение задач "в лоб", пусть с ООП, пусть с паттернами, но все равно "в лоб".
V>>Кстати, какие, елси не секрет, компоненты разрабатываешь и по каким стандартам?
AVK>Платформу для средних предприятий. Подробнее сказать пока не могу.
Я не зря спросил про стандарты. Для реальной возможности существования (порождения) описанного DSL должна существовать и быть признанной куча прикладных спецификаций. Де-юре уже существуют различные прикладные спецификации, но де-факто их практически не используют. А значит, каждая прикладная система продолжает оставаться "вещью в себе", и разработка подобного более-менее универсального DSL технически маловероятна.
Ведь реальные программы должны подразумевать кучу специфических вещей, типа транзакций, права доступа на имеющиеся и порождаемые объекты, взаимодействие с хранилищем экземпляров сущностей, обыгрывание одновременного доступа к ним, репликации и синхронизации, документооборот (или более общо — движение сущностей по подписчикам или assignee) и т.д. и т.п.. К бизнес логике перечисленное имеет, скажем так, косвенное отношение (т.е. должны являтся вещами декларативного а не императивного плана, а еще лучше — внешне настраиваемы без перекомпиляции бизнес-кода), однако эти вещи — наиболее воспроизводимы и повторно применимы, и являются первыми преттендентами на устаканивание спецификаций.
Наверняка в своем фреймворке ты решаешь, помимо прочего, и указанные задачи (как и сотни других разработчиков фреймворков). А без каких-либо стандартов, применение подобного middleware возможно только в собственном окружении, либо (как это зачастую происходит ) через кучу самописного интеграционного кода.
Здравствуйте, AndrewVK, Вы писали:
V>>Да не бизнес это софт. Это инструмент для оного, и задача чуть более интересная, ИМХО.
AVK>Нет там такой резкой границы. Где то пользуются большим количеством middleware, где то меньшим, а остальное дописывают самостоятельно. В идеале собственно прикладная логика должна задаваться на примитивном DSL (вся). И вот чтобы решить эту мегазадачу нужно приложить массу усилий.
На примитивном языке лучше всего решать несложные задачи. Т.н. "прикладной функционал" к таковым относится дадлеко не всегда. Собственно, примеров использования "примитивных языков" для программирования прикладной логики — пруд пруди, скажем, тот же VB6. И что? Да уродство на выходе получается! А T-SQL? Уж куда примтивнее! А чудовища ещё те получаются.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну так я тоже знаком. А вот знаком ли он с разработкой софта вроде упомянутого тобой JBoss? Ой, что это я, чур меня, чур.
Здравствуйте, IT, Вы писали:
IT>А из каких частей по-твоему состоят бизнес-приложения и сайты? vdimas уже озвучил свою точку зрения, по его мнению они состоят из базы данных и формочек. А по-твоему?
Ты пропустил еще прослойку между оными
Я больше по ней пытался пройтись, чем по формочкам.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Кто-то же os2000 разрабатывает. И я уверен, он не считает, что писать бизнес-софт сложнее.
IT>Заметь, тут никто не говорил про то что бизнес-софт писать сложнее. Говорилось совсем обратное.
И чему мои слова противоречат?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
V>>Когда я частенько повторяю, что тысячи людей по всему миру пишут, по сути, одно и то же, то имею в виду бизнес-приложения в большей степени. Как нигде здесь масса поддающихся унификации вещей. И даже есть тонна стандартов транзакций, те же EDI и их новые XML-ветки. Но мало кто ориентируется на стандарты, везде разношерстица и решения "по месту".
AVK>А, так все таки проблема не в самой категории софта, а в неверных решениях с которыми ты сталкивался. Так почему ты тогда огульно обвинил всю отрасль? Поверь, в этой сфере встречаются весьма непростые задачи с красивыми и нетривиальными решениями.
Можно примеры?
Скажу, что прилично разбирался с Navision одно время (было интеерсно, что там MS двигать собралась). Так же с Парус. (это вообще кошмар, по-моему, к нему труднее всего собственные бизнес-блоки прикручиваются)
Немного более стройные решения от Alef и... Accent (угу, несмотря на платформу).
С 1С все ясно — она ближе всех подошла к "правильной" идее образца конца 90-x... однако, явно хромает имплементация и налицо отсутствие приемлимой масштабируемости. К тому же, даже в "серверной" 8-ке, их сервер не является самодостаточным сервером приложений.
Про SAP я спрашивал у разработчиков конфигураций под нее. Ответы просто невероятные — при наличии некоей масштабируемости этот гроб гораздо более трухлявее внутри чем та же 1С. Разрабатывать под SAP вообще неудобно, а ведь это — один из первых критериев: легкость разработки под бизнес-платформу (и отладки, разумеется).
Так что, если можешь — покажи мне выделенное.
Или оно пока в разработке? Когда посмотреть можно будет?
V>>Но эти задачи скорее на хитрость и изворотливость, чем на применение каких-либо фундаментальных знаний.
AVK>А фундаментальные знания по твоему это только математика?
ИМХО, те же паттерны ООП — это что-то вроде таблицы умножения или правил сокращения дробей, которые надо просто знать и уметь распознавать.
Математика бывает, однако, и прикладной. Теория МО — тоже часть математики, и должна хоть иногда применятся при разработке тех же серверов приложений.
Здравствуйте, eao197, Вы писали:
IT>>Заметь, тут никто не говорил про то что бизнес-софт писать сложнее. Говорилось совсем обратное.
E>И чему мои слова противоречат?
Они не противоречат. Акцент другой.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
V>>Как ни крути, а создание бизнес-приложений — это одно из самых легких направлений IT. Все остальные гораздо сложнее.
ГВ>Ну не совсем так. На самом деле, из того факта, что чаще всего заметны задачи типа "вынуть-из-БД-отобразить-в-Web" такого обобщения сделать нельзя. 1. Структура информационной системы может по сложности ну ой как перемахивать через компиляторы и ОС. Просто сложность здесь заключается в: ГВ>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.); ГВ>3. — Необходимости сильной адаптации интерфейса пользователя к требованиям конечного пользователя; ГВ>4. — Необходимости согласования работы ИС с целой кучей софта, уже имеющегося у покупателя (нередко).
Я пронумеровал твои пункты.
1. Сложность не надо путать с объемностью.
2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)
3. Это разнавидность п.2 применимого к ГУИ. Частично разновидность п.1. Если не удается достаточно хорошо унифицировать и автоматизировать этот вопрос, то именно ручками формочки и клепаем. В этом случае это чистое подтверждение п.1.
4. О!!! Самый правильный пункт. Задача интеграции — действительно бывает сложной задачей, особенно в отсутствии закладки стандартов в "интегрируемые" продукты. Иногда требует изворотливости и даже где-то технического "хамства" и хакерства. Однажды мне заказали 2 локальных специализированных прокси-сервера: для клиентской и для серверной стороны, которые адаптировали трафик клиента и сервера друг-другу. Клиент подключался к локальному прокси, а к серверу стучался прокси со стороны сервера. Почему 2 прокси а не 1? Оба обслуживаемых гаврика помимо прочего требовали наличие постоянного TCP коннекшена, эту "постоянность" приходилось эмулировать (обман и подлог... вот он удел интеграторов )
Де-факто, ситуация присутствует, однако, она искусственно создана. Ликвидации (или значительного снижения) именно этого момента я ожидаю от популярных бизнес-систем следующего поколения.
V>>Просто в последние 5-10 лет это самая емкая и популярная область.
ГВ>Не... в последние, эдак, лет 40. И такая ситуация — навсегда, увы.
Да нет. Ты мне давал книжку, в которой приводилось примерное распределение отраслей и задач, использующих выч. технику в разное время. Именно с ростом популярности персонального компьютера + интернета и удешевления серверов бизнес-отрасль получила мощный толчек.
V>>И порой программисты считают себя спецами лишь потому, что в состоянии прочитать что-то из базы и куда-то это прочитанное вывести. Хотя, по сути, требуется лишь умение оперировать чужими АПИ.
ГВ>В сущности — да, без умения оперировать чужими АПИ никуда, но это очень примитивное обобщение.
Я ничего не обобщал, я возразил против того определения "специалист", которое имеет ныне много сторонников.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, eao197, Вы писали:
E>>Тогда ReSharper и IDEA -- это тоже бизнес софт? E>>(а это я уже шучу )
V>ага, вместе с компиляторами и даже самими компьютерами и сетевыми картами.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ты упустил такую мелочь, как наличие кучи неопределенных ситуаций которые при рефакторинге могут привести к неопределенным последствиям.
X>А вообще утилита рефакторинга, работающая с 99% точностью для C++ сейчас уже есть. Насколько я знаю, она даже в состоянии бэты. Пишет ее один мужик из Питера, для собственного развлечения.
И когда она должна материализоваться? Почему-то меня не покидает ощущение, что или вместо 99% будет 9% или 0.9%, ну, или эта утилита так и не увидит свет.
Даже создание полноценного парсера для С++ уже огромная проблема, а сделать его еще быстрым (как минимум инкриментальным) вообще задача неподъемная.
Интересно, что использует этот мужик в качестве парсера?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Не совсем так. Возможно, что vdimas знаком с направлениями, которые сложнее, чем разработка бизнес-софта.
Не может быть направление сложнее или проще. Все определяется конкретной задачей. Есть и компиляторы сверх-сложне. И безнес-системы ахриненной сложности. И софт для космический кораблей сложностью с "привет, мир".
Ну, если уж говорить о возможностях, то возможно, что vdimas не знаком с серьезными бизнес-системами. Я вот сталкивался и не думаю, что какие-нибудь компиляторы сложнее их.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> X>... > > Ты упустил такую мелочь, как наличие кучи неопределенных ситуаций которые при рефакторинге могут привести к неопределенным последствиям.
А именно?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, xvost, Вы писали:
X>>...
VD>Ты упустил такую мелочь, как наличие кучи неопределенных ситуаций которые при рефакторинге могут привести к неопределенным последствиям.
X>>А вообще утилита рефакторинга, работающая с 99% точностью для C++ сейчас уже есть. Насколько я знаю, она даже в состоянии бэты. Пишет ее один мужик из Питера, для собственного развлечения.
VD>И когда она должна материализоваться? Почему-то меня не покидает ощущение, что или вместо 99% будет 9% или 0.9%, ну, или эта утилита так и не увидит свет.
А как же те три коммерческие утилиты для рефакторинга С++, ссылки на которые я тут недавно приводил?
Здравствуйте, vdimas, Вы писали:
V>Слово "в идеале" — ключевое. Я примерно так себе и представляю "правильную" разработку бизнес-систем. То, что вижу сейчас, это зачастую решение задач "в лоб", пусть с ООП, пусть с паттернами, но все равно "в лоб".
Ну и? Разве это говорит о том что отрасль создания софта для бизнеса очень простая?
Ну например Парус-Магазин (неофициально парус 9). Довольно старый проект, но спроектирован довольно неплохо. Неплохие решения (далеко не все) есть в Парус 7, хотя технологически он отстал очень сильно.
V>Так же с Парус. (это вообще кошмар, по-моему, к нему труднее всего собственные бизнес-блоки прикручиваются)
Парус много разных платформ продает. Ты о какой?
Что же касается прикручивания собственных блоков, то это не из-за неверных технических решений, это из-за такой политики Паруса. Сейчас ситуация потихоньку меняется.
V>С 1С все ясно — она ближе всех подошла к "правильной" идее образца конца 90-x...
Не знаю точно что ты под "правильной моделью" имеешь ввиду, но есть еще Axapta, упомянутый тобой Акцент, Тектон.
V> однако, явно хромает имплементация и налицо отсутствие приемлимой масштабируемости. К тому же, даже в "серверной" 8-ке, их сервер не является самодостаточным сервером приложений.
В 8-ке нет сервера приложений. Это классическая двухзвенка.
V>Про SAP я спрашивал у разработчиков конфигураций под нее. Ответы просто невероятные — при наличии некоей масштабируемости этот гроб гораздо более трухлявее внутри чем та же 1С.
Ты в курсе сколько их решениям лет?
V> Разрабатывать под SAP вообще неудобно,
Разрабатывать под SAP практически невозможно. Ты покупаешь готовое решение и услуги по перепроектированию собственных бизнес-процессов. Вобще, на западе, ввиду того что бизнес-процессы у них на порядок стабильнее онных в России, системы чаще продают готовые. Единственная гибкая западная система, которую я видел, это Axapta.
V>Или оно пока в разработке?
И в разработке тоже.
V> Когда посмотреть можно будет?
Могу только про себя говорить. Ориентировочно к концу года.
AVK>>А фундаментальные знания по твоему это только математика?
V>ИМХО, те же паттерны ООП — это что-то вроде таблицы умножения или правил сокращения дробей, которые надо просто знать и уметь распознавать.
Паттерны, они разные бывают. Те, что у банды описаны, они конечно. А вот к примеру те, что описаны в Microsoft Pattern&Practice уже на порядок сложнее (см. к примеру SCOAB (Smart Client Offline Application Block)). Есть еще более сложные. И наконец есть конкретные решения с еще более сложной структурой.
V>Математика бывает, однако, и прикладной. Теория МО — тоже часть математики, и должна хоть иногда применятся при разработке тех же серверов приложений.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
ГВ>>>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.);
V>>1. Сложность не надо путать с объемностью.
IT>Что в твоём понимании сложность? А то пока ты не дал своего определения вряд ли мы сможем говорить об одном и том же.
Для себя я определяю сложность как степень "напряжения" мозгов. Подойдет такое определение? Чем большего сосредоточения и умственной отдачи требует работа, тем она сложнее. Ну а тепеь можно бесконечно перечислять внешние факторы, влияющие на мозговую напряженность:
— известность задачи для исполнителя,
— объем и сложность (!!!) теоретических знаний,
— количество необходимых действий в уме
— объем материала, который необходимо дежать в уме одновременно для выполнения задачи (размерность с т.з. человеческого понимания).
— количество моментов в задаче, которые сможем исполнять "по-привычке" (т.е. практически не думая, как перемножаем числа до 10).
— и т.д.
V>>2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)
IT>В молодой конторе с бурно развивающимся бизнесом наличие ТЗ такая же редкость как и сферические кони вне вакуума. Сроки — вчера. Polymorphic behaviour — в сад. Code Conventions — лесом. Релиз — раз в неделю. Программер — швец, жнец, на дуде игрец. Архитектор — специалист по ампутированию гландов через выхлопную трубу и замены протезов во время забега. В наличии несколько часов после 24:00 для деплоймента, 1000 компов в трёх странах и право хранить молчание, которое всё равно будет использовано против Вас.
IT>А теперь вопрос. Какое нафиг ТЗ?
Хороший стиль, я бы подумал о писательском поприще
Если мы будем так же рассматривать сложности организационного порядка, то тут мне ничего не останется как согласится со определением "сложность", ибо, в этом случае, потребуется неимоверное напряжение тех самых умственных усилий.
-----------
А для составления ТЗ необязательно штатных аналитиков держать, можно и постороннего нанять.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А именно?..
А именно открывашь стандарт и начинашь искать неопределенное поведение и т.п. в любом таком месте у создателя утилиты рефакторинга будет инфаркт. И или эта утилита будет переодически гробить код, или она на более менее сложный код начнет чихать и ругаться "мол что за барахло вы мне подсунули". Ну, а все эти макросы и инклюды подольют масла в огонь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>А именно?..
> А именно открывашь стандарт и начинашь искать неопределенное поведение и т.п. в любом таком месте у создателя утилиты рефакторинга будет инфаркт.
Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, vdimas, Вы писали:
E>>Дима, а какую именно область IT ты считаещь более сложной, чем бизнес-приложения?
V>Так же могу добавить: V>- разработка различного инструментария (в помощь администрированию, например, там широченное поле деятельности).
Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Покажи, как именно это будет происходить на примере любого из случаев неопределенного поведения, упомянутых в стандарте C++. Я не представляю, как наличие неопределенного, равно как и implementation defined или unspecified behavior может влиять на рефакторинг...
Мне просто влом копаться в стандарте. Можешь вынимать их по одному и обсудим.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Патрик, Вы писали:
П>>Как человек, который последние несколько лет занимается именно этим — уверяю, ничего сложного в этом нет....Даже более того, трудно поискать другую сферу деятельности, которая настолько сводится к грамотному пользованию чужим API
VD>Грамотным пользованием чужим АПИ многие задачи сводятся на нет.
Что-то эту фразу я не переварил
Разработка программ для администраторов — это создание правильной комбинации вызовов чужого АПИ
Здравствуйте, vdimas, Вы писали:
ГВ>>Ну не совсем так. На самом деле, из того факта, что чаще всего заметны задачи типа "вынуть-из-БД-отобразить-в-Web" такого обобщения сделать нельзя. 1. Структура информационной системы может по сложности ну ой как перемахивать через компиляторы и ОС. Просто сложность здесь заключается в: ГВ>>2. — Нестабильности предметной области (сколько финансистов — столько финансовых школ, сколько страховых компаний — столько методов страхования, сколько торговых компаний — столько моделей работы с клиентами и т.п.); ГВ>>3. — Необходимости сильной адаптации интерфейса пользователя к требованиям конечного пользователя; ГВ>>4. — Необходимости согласования работы ИС с целой кучей софта, уже имеющегося у покупателя (нередко).
V>Я пронумеровал твои пункты.
V>1. Сложность не надо путать с объемностью.
Нет. Это она и есть — количество структурных элементов и есть сложность.
V>2. При наличии конкретного ТЗ (или конкретного клиента с конкретной моделью) это никак не увеличивает сложность самой задачи. (Хотя, это бы увеличило сложность, скажем, "супер-мега-универсальной" системы. Но разработка подобной системы — это скорее разработка системного плана)
Проблема не в этом. Порой для того, чтобы сформировать детальное ТЗ нужно взять теоретический талмуд и... списать его наполовину. Потому и ТЗ будет у нас не всегда. Понятно, что последовательная борьба с такой нестабильностью приводит к разработкам "системного" плана.
V>3. Это разнавидность п.2 применимого к ГУИ. Частично разновидность п.1. Если не удается достаточно хорошо унифицировать и автоматизировать этот вопрос, то именно ручками формочки и клепаем. В этом случае это чистое подтверждение п.1.
+1
V>Де-факто, ситуация присутствует, однако, она искусственно создана. Ликвидации (или значительного снижения) именно этого момента я ожидаю от популярных бизнес-систем следующего поколения.
ИМХО — это невозможно. Поскольку это прямо зависит от количества разработчиков систем: набор понятий, структура связей между ними и т.п. Собственно, такая же ситуация была и с процессорами несколько раньше. Но тут положение дел упростилось за счёт того, что Intel подавила конкурентов соотношением цена/качество и... ну, и IBM помогла, разумеется.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
И даже знал 5 лет назад.
Был у нас приблизительно такой случай 
перепишут на чем-нибудь новомодном. 
Если нам не помогут, то мы тоже никого не пощадим.
)
