Чем так привлекателен C++ ? - Философия программирования

Здравствуйте AndrewVK, Вы писали:

ГВ>>Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора.
AVK>Неправильный пример, причем сильно неправильный. У Ассемблера своего рантайма 0. Весь его рантайм зависит от ОС, системы команд процессора, архитектуры компьютера и т.д. В нашем же случае мы имеет стандартизованный рантайм, одинаковый на любом компьютере.

Да, runtime-обвязки у него фактически нет, но он — производное от своей платформы. Слово "окружение" у меня преднамеренно было взято в кавычки.

ГВ>>ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций.
AVK>А сейчас вместо отсечения языка стали отсекать его рантайм. Джава тому примером. Почему ты решил что это хуже? В плане переносимости наоборот намного лучше. Я уже тебе писал — для джавы совместимость бинарная, что по определению на порядок большая степень изоляции от окружения. Думаешь для чего еще выдумали JVM и CLR.

От окружения класса целевой машины — несомненно, но не от своего собственного. Целевой машиной Java грубо можно считать JVM. Да, Java-программы можно переносить в бинарном виде. При наличии JVM или её аналога на целевой аппаратной платформе (есть почти везде, даже на .NET). Чего, кстати, нельзя пока сказать о C# (пока что).

Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.

ГВ>>PROLOG — хорновские дизъюнкты,
AVK>Какие? Ты где такой термин откопал? Его нгазывают логическрим языком, реляционным, языком исчисления предикатов, но вот такое вижу впервые.

Посмотри, например, здесь.

AVK>В общем хороший пример — язык очень глубоко завязан на свой рантайм, там даже БД встроена в рантайм и поддерживается на уровне языка. Впорочем лисп, как ты понимаешь, тоже без своего окружения ничто, это вобще скрипт по сути.

Для них, кстати, явно вводится понятие абстрактной машины (PROLOG-машина, LISP-машина и т.п.). А для PROLOG, по-моему, до сих пор способа трансляции в исполняемый код толком не нашли.

ГВ>> SQL — реляционная алгебра.
AVK>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL? SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет. ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.

Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).

ГВ>>Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля".
AVK>Ты по моему чего то не понимаешь. Это для инженерных расчетов можно себе позволить перекомпилировать исходники на каждый чих. А теперь представь себе следующую ситуацию — у нас сетка скажем из 100 машинок. На них стоит некий софт, в соответствии с "хорошим" стилем собранный статической линковкой. Все это работает в режиме 24х7. 1 час простоя обходится скажем в $10K. И вот теперь представь — для 5 рабочих мест ты что то поменял. Менять придется везде.

Пример слегка натянутый, но ... Так в чём проблема-то?

Остановка работы станции на 1 мин, копирование нового .EXE и перезапуск новой программы. И так на 5-и станциях. Всё.

И потом, если всё так критично, то известно об этом обычно с самого начала работы и проектные решения для подобных манипуляций должны приниматься заранее (есть, правда и другие практики, но это "не моя уже вина" (c) ). Так что, если я буду менять что-то для 5-и рабочих мест (и только для них), то обеспечу, чтобы остальные 95 остались нетронутыми.

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

Кстати, безотносительно используемых технологий мне всё равно придётся тормозить часть приложения (или всё), чтобы отключить удаляемые модули, если, конечно статическая линковка сделана в варианте .EXE+.DLL.

AVK>В общем глупо объяснять преимущества компонентных технологий. Они существенно увеличивают надежность системы. У тебя видимо несколько специфическая предметная облась если ты этого не замечаешь.

Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.

ГВ>> Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.
AVK>Следуя твоей логике нужно отказаться и от полиморфизма. Ибо рефлекшен по сути и есть полиморфизм, только более высокого уровня нежели тот который обеспечивается виртуальными методами.

Это наивное следствие из логики предложения. ИМХО — апофеоз попыток таких согласований — это шаблоны, которые позволяют разделить алгоритмы и структуры данных в объектном стиле.

ГВ>>При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.
AVK>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.

Я этого не утверждаю, а обозначаю своё видение целей.

ГВ>>Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.
AVK>Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.

ИМХО, снова не всё так просто. Вот поддержку комонентных технологий и аспектно-ориентированного подхода вижу, но это — просто перенос композиционных подходов компонентных технологий. Перенос подходов, которые, в частности, видоизменены для поддержки перехвата вызовов функций, — одного из элементов реализаци аспектно-ориентированного подхода. Да, набор библиотек, теоретически, может быть больше, манипулировать ими несколько проще, но причём тут абстракция высокого уровня? ИМХО, абстракция высокого уровня — это разделение алгоритмов на элементы, их перекомпоновка и применение к конкретным структурам данных, также обобщаемым.

ГВ>>ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.
AVK>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка. А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.

AVK>А потом — ты хоть раз видел программу на С++ компилирующуюся и под уних и под Win32? Я видел. Там половина кода в #ifdef ХХХ. Поэтому реально портируют софт с использованием cygwin. А это как раз и есть тот самый рантайм. Поэтому про переносимость С++ не надо, хреновая она совсем.

Программы можно писать по-разному. Из того, что ты сейчас сказал, можно сделать только тот вывод, что программу авторам просто лень было переписывать для кроссплатформенности. Или она изначально бестолково спроектирована. Абстракции уровня ОС не стоит смешивать с прикладной логикой — это, извини, альфа и омега.

ГВ>>То есть, языки системного программирования принципиально
AVK>Очень расплывчатый термин. Нет таких языком программирования. Есть задачи. Вот для этих задач (я имею ввиду написание ОС-специфичных вещей) С++ и нужен. И не потому что он обеспечивает высокую степень абстракции а наоборот, слишком тонкий слой отделяет его от ОС.

Это одно из его преимуществ перед другими. С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.

ГВ>>Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка".
AVK>Т.е. ты меня и Влада считаешь неквалифицированными программистами?

У меня нет на это оснований, ввиду того, что критерии квалификации, (да и то — приблизительные), я привёл чуть выше (поскипано) а возможности оценивать вас по этим критериям у меня нет, да я к ней и не рвусь.

И по-любому, я к конкретным личностям не апеллирую. Почему ты всё время пытешься сделать поспешные выводы относительно личностей?

ГВ>> Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже.
AVK>Однако почему то на джаве и шарпе у меня получается писать быстрее и качественнее.
AVK>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?

Я не буду переходить на личности. Умеешь ты строить абстракции или нет — не мне решать. Мы с тобой спорим. Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется. Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы. OK, вполне нормальный предмет спора. Ты приводишь одни аргументы, я другие. Лучше всего было бы, если бы аргументы касались только особенностей языков и платформ, статистических сведений, оценки целей и целесообразностей и т.п. — не касаясь конкретных личностей и их качеств. "Каков мой собеседник" — меня в данном контексте не интересует и не служит в моих глазах аргументом более значимым, чем логически и рационально обоснованное высказывание. Если тебя что-то лично задевает, даже в моих обобщающих высказываниях — скажи, что тебя это задело или постарайся от этого абстрагироваться или укажи на неправомерность обобщения. А то мы так до драки дойдём.

Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.

ГВ>>То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно

). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются.
AVK>Попробуй взглянуть на это с другой стороны. В софтостроении потихонечку произошла маленькая революция. Возможно это и возвращение старых идей, но на новом уровне. Тебе же объясняют — на шарпе получается писать намного быстрее и намного качественней даже профессионалам. А то что язык дисциплинирует тех самых чайников это его плюс. Джава в большей степени, шарп в меньшей. Тут альтернатива простая — либо средненькие программеры, либо никакие. В последнее время я предпочитаю брать на работу людей незнакомых с тем что применяется. Научить значительно проще чем переучить.

Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?

ГВ>> В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет!
AVK>Оно и в плюсах ничего нет.

Да и не нужно "в плюсах". Нужно — "для плюсов".

AVK>Математика не поспевает за программиролванием.

Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.

AVK>Пожалуй единственным успешным применением математики в программировании является теория множеств и теория графов.

Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)

AVK>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.

Не успев даже влезть в них полностью.

AVK>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.

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

ГВ>> Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.
AVK>Дорогой ты мой, их не посылать надо а делать из них нормальных спецов. Других нет.

Вопросы: 1. Что понимается под словами "нормальный спец"? (Я свои критерии, пусть и приблизительные предложил.) 2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.) 3. И захотят ли они сами этого? (ИМХО — нет.)

ГВ>>Вот тебе и "язык должен учитывать все эти проблемы...".
AVK>Обязательно. Иначе это не язык а абстракция.

А в противном случае это — гипертрофированный калькулятор.

ГВ>>Проблемы кого? Проблемы недоучившихся школьников?
AVK>Да

Не согласен. Это задача языка, на котором учатся применять фон-неймановскую и императивную модель.

ГВ>> То есть, давайте превратим всех в недоучившихся школьников,
AVK>Не надо превращать. Они уже есть.

Я говорю о тех, кто уже вышел из этого состояния. Их меньшинство, это естественно. Но зачем навязывать им мнение большинства? Впрочем — это уже риторический вопрос.

ГВ>> потому что так основной массе будет удобнее? Что-то в этом есть неверное, а конкретно — игнорирование интеллектуальной основы (ИМХО).
AVK>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.

Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень. Хотя... тут и твоя правда есть. Никто не может гарантировать, что оставшиеся действительно будут менять свой уровень.

ГВ>>(ну да — тот самый, очень "сложный", в первую очередь

AVK>Тот самый очень сложный под дотнет есть. MC++ называется.

Но это же не полный C++. А впрочем, это общая проблема...

ГВ>>), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела.
AVK>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.

Абсолютно согласен. Именно поэтому идеального языка не может быть, как и идеального процессора. А что мы имеем в случае .NET? Попытку нивелировать все .NET-языки под её лад.

ГВ>>Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес.
AVK>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.

Я — тоже.

ГВ>> ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.
AVK>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

Вот этим последним предложением. Рантайм вряд ли будет всегда стандартен, в том смысле, что один и тот же рантайм будет везде и везде одинаков. Тем более — такая махина.
Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие. И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь. И понесётся. Получим те же точно, старые как мир проблемы, только "в профиль".

ГВ>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>Абсолютно неверно.

Хорошо, не прав. Способ превращения элементарных данных в объекты.

AVK>>>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.
ГВ>>Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.
AVK>Так в чем проблема то?

Сделать предлагаешь? Может быть, когда-нибудь.

AVK>>>Есть еще джава.
ГВ>>Java, кстати, кажется и на .NET реализована.
AVK>J#.

ГВ>>Что доказывает их подобие
AVK>И гибкость CLR.

И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

ГВ>>Но никак не на подержку неограниченного повышения эффективности одного человека.
AVK>Практика показывает что эффективность он таки повышает.

Охарактеризуй задачи на которых так происходит, если не трудно.

ГВ>>ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371)
AVK>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.

Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.

ГВ>>Нас грубо подталкивают к эффективности реализации примитивных систем, но усложняют деятельность более высокого порядка.
AVK>Как раз наоборот получается. Когда мы пытаемся что то простенькое писать, зачастую на С++ получается не хуже, иногда даже лучше. А вот когда дело доходит до чего то тяжелого тогда и начинают работать все достоинства дотнета или джавы.

Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО). Может быть, моё высказывание в твоих глазах — иллюстрация моего неумения писать большие программы. Приведи, pls., описание какого-нибудь подходящего конкретного случая.

AVK>>>В том числе и для этого.
ГВ>>Но появятся ли новые?...
AVK>Почему нет?

Некому будет создавать.

AVK>>>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

AVK>>>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.
ГВ>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>А зачем? Она в дотнете уже есть.

Не царское это дело — ставить свою программу в зависимость от...

AVK>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.

Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.

Здравствуйте Геннадий Васильев, Вы писали:

ГВ>Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.
Вобще то на VM стандарт есть.

AVK>>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

ГВ>Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL?
SQL-сервер и VM выполнения запросов.

ГВ> SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет.
А как ты думаешь, почему? Вобще то производителям обычно выгодно придерживаться стандартов.

ГВ> ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.
Только SQL'92 они все же поддерживают. И потом я не зря сказал что все. Ну положим оракль может позволить себе поступать подоьбным образом, но MySQL что, тоже подобным образом клиентов отбивает? PostgreSQL? InterBase? Просто SQL'92 оказался слишком отвязан от рантайма и реальной жизни и просто не справился с меняющейся средой. Для современного сервера считается нормой поддержка хранимых процедур и триггеров. А вот этого SQL'92 обеспечить не в состоянии.
Вот и вышел пример отвязки языка от рантайма там где этого делать не следовало. Чтобы получить универсальный SQL нужно стандартизировать рантайм, а этого сделано не было.

ГВ>Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).
На CLR есть ECMA стандарт. А вот Win32 кстати является собственностью MS.

ГВ>Пример слегка натянутый, но ... Так в чём проблема-то?

Ага, а где гарантия что старый клиент с новым конфликтовать не будет?

ГВ>

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

Ну а во всем остальном мире подобные проблемы решают как раз с помощью компонентных технологий. Впрочем, не буду спорить, доказывать необходимость компонентных технологий я не хочу. Все познается в ходе разработки.

ГВ>Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.
Быстродействия нет, надежности да, причем в разы. Это практический опыт.

AVK>>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.
ГВ>Я этого не утверждаю, а обозначаю своё видение целей.
Это прямо следует из твоих утверждений.

AVK>>Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.

ГВ>ИМХО, снова не всё так просто.
Ну устал я уже с тобой спорить. Просто, не просто, но я это пробовал. Эффект есть, причем очень большой. Не веришь? Попробуй.

AVK>>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

ГВ>Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка.
Да прям уж. А чего так народ на JVM ругается что он очень сильно на язык заточен? Подвязана джава на свой рантайм, причем очень сильно.

ГВ> А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.
Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.

ГВ>Программы можно писать по-разному.
Ну да, конечно. Я писать не умею а ты умеешь.

ГВ>Это одно из его преимуществ перед другими.
И это же его недостаток. Следствие этого — трудность написания тех самых больших и сложных проектов.

ГВ> С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.
Идея другая, а реализация похожа.

AVK>>Т.е. ты меня и Влада считаешь неквалифицированными программистами?
ГВ>У меня нет на это оснований, ввиду того, что критерии квалификации,
Ну а как воспринимать тогда твои слова о том что на дотнете проще писать проекты только неквалифицированным программистам?
Вот лично мне большинство проектов проще писать на дотнете.

ГВ>Почему ты всё время пытешься сделать поспешные выводы относительно личностей?
Знаешь, я делаю логичные выводы из твоих предпосылок.

AVK>>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?
ГВ>Я не буду переходить на личности.
Знаешь, ты хорошую позицию выбрал. Намеки делаешь, а как тебя за них спрашивают то говоришь что ты такого не имел ввиду. Очень странное ощущуение возникает от такого общения.

ГВ>Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется.
Тогда не надо делать таких высказываний. Я тебе привел в качестве аргумента свой опыт реализации проектов на джаве, а теперь уже и на дотнете. А ты мне, (о да, прямо кого либо ты не упоминаешь) говоришь что мол некие программисты пишут некие программы на дотнете лучше потому что они не умеют строить абстракции на С++. Знаешь, у меня с логикой все в порядке и я еще в состоянии сделать соответствующие выводы.

ГВ> Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы.
Нет, я доказываю что ему пора меняться.

ГВ>Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.
Ты просто привык ими пользоваться. Вполне неплохо живется и без них.

ГВ>Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?
Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.

AVK>>Математика не поспевает за программиролванием.
ГВ>Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.
Это не математика.

ГВ>Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)
Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.

AVK>>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.
ГВ>Не успев даже влезть в них полностью.

Ну это уже издержки развития.

AVK>>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.
ГВ>То есть, невозможно показать структурный граф программы или функции и просто посчитать характеристики его ребер? Позволю себе в этом с тобой не согласиться.
Я еще раз повторюсь — Не отменять, но и не делать ее определяющей.

ГВ>Вопросы: 1. Что понимается под словами "нормальный спец"?
Человек который способен решать поставленные задачи и при этом решать их качественно.

ГВ>2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.)
Это зависит от обстоятельств. Как правило это руководитель группы.

ГВ>3. И захотят ли они сами этого? (ИМХО — нет.)
А им деваться будет некуда. Либо они учатся решать поставленные задачи либо идут лесом.

AVK>>Обязательно. Иначе это не язык а абстракция.
ГВ>А в противном случае это — гипертрофированный калькулятор.
Нет, это нормальный инструмент.

AVK>>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.
ГВ>Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень. Вот в этом все и дело. Тебе шашечки а тем кто деньги платит нужно ехать.

AVK>>Тот самый очень сложный под дотнет есть. MC++ называется.
ГВ>Но это же не полный C++. А впрочем, это общая проблема...
Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

AVK>>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.
ГВ>Абсолютно согласен. Именно поэтому идеального языка не может быть, как и идеального процессора. А что мы имеем в случае .NET? Попытку нивелировать все .NET-языки под её лад.
Ну там достаточно простора для вариаций. А вобще увеличение ограничений от ассемблера через С, С++ к дотнету очень хорошо прослеживается. Не вижу причин считать что ограничения С++ еще позволительны а дотнета уже нет.

AVK>>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.
ГВ>Я — тоже.

Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.

AVK>>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

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

ГВ>Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие.
Вот вот. А С++ не очень в плане совместимости.

ГВ> И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь.
За сколько там лет существования джавы несовместимых рантаймов пока не появилось.

ГВ>>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>>Абсолютно неверно.
ГВ>Хорошо, не прав. Способ превращения элементарных данных в объекты.
Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.

AVK>>Так в чем проблема то?
ГВ>Сделать предлагаешь? Может быть, когда-нибудь.
Вот. А в дотнете уже есть.

ГВ>>>Что доказывает их подобие
AVK>>И гибкость CLR.
ГВ>И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

Рефлекшен где?

AVK>>Практика показывает что эффективность он таки повышает.
ГВ>Охарактеризуй задачи на которых так происходит, если не трудно.
ERP, Web

AVK>>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.
ГВ>Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.
При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.

ГВ>Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО).
Вот вот. Все твои аргументы сводятся к тому что ты считаешь себя знатоком построения абстракций.

ГВ>>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>>А зачем? Она в дотнете уже есть.
ГВ>Не царское это дело — ставить свою программу в зависимость от...

Мне не шашечки, мне ехать. Написание художественных программ я оставлю на потом.

AVK>>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.
ГВ>Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.
Было давно, лет эдак 6 назад, да и не хочется мне это обсуждать.

... Янус версия 1.0 alpha 2

А у MS вообще нездоровая тяга все "улучшать" на свой вкус.

Не помню, кто сказал, что законы существуют, чтобы их нарушать.

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.
AVK>Вобще то на VM стандарт есть.

Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.

AVK>>>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

См. ниже.

ГВ>>Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL?
AVK>SQL-сервер и VM выполнения запросов.

ГВ>> SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет.
AVK>А как ты думаешь, почему? Вобще то производителям обычно выгодно придерживаться стандартов.

Я думаю, что это связано с тем, что стандартов выгоднее всего придерживаться "новым игрокам", поскольку следование стандартам автоматически обеспечивает им поле игры. А вот отклонения от стандарта удобнее всего "старым игрокам", поскольку за счёт отклонений от стандартов они привязывают потребителей к своим продуктам. В то же время, участие в формировании стандартов позволяет "титанам" снять себя часть обвинений в монополизации. Ну, и между собой повоевать, конечно

ГВ>> ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.
AVK>Только SQL'92 они все же поддерживают. И потом я не зря сказал что все. Ну положим оракль может позволить себе поступать подоьбным образом, но MySQL что, тоже подобным образом клиентов отбивает? PostgreSQL? InterBase? Просто SQL'92 оказался слишком отвязан от рантайма и реальной жизни и просто не справился с меняющейся средой. Для современного сервера считается нормой поддержка хранимых процедур и триггеров. А вот этого SQL'92 обеспечить не в состоянии.
AVK>Вот и вышел пример отвязки языка от рантайма там где этого делать не следовало. Чтобы получить универсальный SQL нужно стандартизировать рантайм, а этого сделано не было.

OK, хороший пример на самом деле. Но заметь, что если бы стандарт оговаривал ещё и реализацию VM, то это существенно усложнило бы выход новых игроков на рынок. Проиграли бы все. И ANSI — в том числе.

Кстати, SQL'92 достаточно сложный стандарт и его полная поддержка тоже есть не везде. (IB, если не ошибаюсь — Entry Level).

ГВ>>Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).
AVK>На CLR есть ECMA стандарт. А вот Win32 кстати является собственностью MS.

OK, CLR/ECMA.

ГВ>>Пример слегка натянутый, но ... Так в чём проблема-то?

AVK>Ага, а где гарантия что старый клиент с новым конфликтовать не будет?

Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?

ГВ>>

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

AVK>Ну а во всем остальном мире подобные проблемы решают как раз с помощью компонентных технологий. Впрочем, не буду спорить, доказывать необходимость компонентных технологий я не хочу. Все познается в ходе разработки.

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.

ГВ>>Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.
AVK>Быстродействия нет, надежности да, причем в разы. Это практический опыт.

Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения. Плюс — предоставлен ряд готовых отлаженных механизмов управления компонентами. Т.е., — причина — в конкретике, а не в парадигме.

AVK>>>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.
ГВ>>Я этого не утверждаю, а обозначаю своё видение целей.
AVK>Это прямо следует из твоих утверждений.

Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.

AVK>>>Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.
ГВ>>ИМХО, снова не всё так просто.
AVK>Ну устал я уже с тобой спорить. Просто, не просто, но я это пробовал. Эффект есть, причем очень большой. Не веришь? Попробуй.

Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.

AVK>>>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.
ГВ>>Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка.
AVK>Да прям уж. А чего так народ на JVM ругается что он очень сильно на язык заточен? Подвязана джава на свой рантайм, причем очень сильно.

Я понял, что некорректно высказался. Вернее будет: JVM+Java — одно целое.

ГВ>> А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.
AVK>Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.

А я вот смотрю и стараюсь выяснить, чем является что-то до того, как начну его использовать, тем более, использовать так, что пути назад потом не окажется. Затем уже я вывожу своё отношение к способу подачи этого самого чего-то. Почему, кстати, и остановился на C++, а не на Delphi в своё время. Кстати, благодарен тебе за оппонирование в этой и других дискуссиях. Заставил (косвенно) поразбираться с .NET и C#. Спасибо. Платформа меня заинтересовала в чём-то.

ГВ>>Программы можно писать по-разному.
AVK>Ну да, конечно. Я писать не умею а ты умеешь.

Не нужно обобщать на общее "умение" или "неумение". Если всякое моё сомнение и сослагательное наклонение расценивать как намёк серии "Здесь все дураки, а я умный", то ничего хорошего, не выйдет. Уверен, что у меня тоже хватает ошибок в доводах. Но искать их — удел оппонентов.

Моя задача — максимально логично с моей точки зрения их скомпоновать.

ГВ>>Это одно из его преимуществ перед другими.
AVK>И это же его недостаток. Следствие этого — трудность написания тех самых больших и сложных проектов.

ИМХО, самый большой недостаток C++ в том, что он заставляет делать выбор, но с моей точки зрения это — очень большое его преимущество и трактуется как предоставление свободы манёвра.

ГВ>> С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.
AVK>Идея другая, а реализация похожа.

Ну так он и создавался с учётом того, что очень много C-программистов и софта на C. Так что, прямое наследование C увы, было неизбежным. А отказ от модели объектов в стиле Smalltalk (общий базовый объект) — следствие требования сильной типизации и эффективности выполнения. Тот факт, что, например, идиомы C (например, const char *) затаскиваются на самый верхний уровень создаваймых на C++ абстракций, ИМХО, следствие неосознанного подхода. C++ включает C как подмножество, а не как однозначное руководство к действию!

AVK>>>Т.е. ты меня и Влада считаешь неквалифицированными программистами?
ГВ>>У меня нет на это оснований, ввиду того, что критерии квалификации,
AVK>Ну а как воспринимать тогда твои слова о том что на дотнете проще писать проекты только неквалифицированным программистам?
AVK>Вот лично мне большинство проектов проще писать на дотнете.

Воспринимать мои слова лучше всего в отвязке от персоналий, в каковой контекст они и были помещены. "И шо за манера всё на свой счёт принимать?"

Это — раз. Два. С другой стороны — а уж не ради ли неквалифицированных программистов, в частности, в дотнетовский C# внесены упрощения и сандартизированы идиомы? А? Уж не для них ли произведено "упрощение и развитие C++"? Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял). Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим концом заблокировали возможность реализации сложных комбинаций, которые не всем были "по силам".

Из вышесказанного, ИМХО, никак не следует, что я отношусь к тебе, как к неквалифицированому программисту.
А тебе просто советую. Прежде, чем делать скоротечные выводы и обижаться, подумать, например о корректности моего определения термина "квалификация".

ГВ>>Почему ты всё время пытешься сделать поспешные выводы относительно личностей?
AVK>Знаешь, я делаю логичные выводы из твоих предпосылок.

Но крайне поспешно, по отношению только к себе, и к тем, кому ты доверяешь, и абсолютно необоснованно обижаешься, чем сбиваешь дискуссию в сторону выяснений личных отношений. Ты вполне мог контраргументировать, например, обвинив меня в неуместном обобщении. Было бы интересно. А так... Знаешь, просто нерационально это — так активно бросаться на обобщения. Их может быть много и разных, они могут быть корректными или нет. На всех энергии не напасёсси.

AVK>>>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?
ГВ>>Я не буду переходить на личности.
AVK>Знаешь, ты хорошую позицию выбрал. Намеки делаешь, а как тебя за них спрашивают то говоришь что ты такого не имел ввиду. Очень странное ощущуение возникает от такого общения.

Если кто-то увидел в моих словах намёк на отрицательную оценку своей личности, извините, это уж не мои трудности. ИМХО, это просто нерационально и попахивает этаким "гусарством", типа "а кто тут против C#/C++/Java/VB...! Так он меня <отрицательный эпитет вписать> считает?". Если ты хочешь уличить меня в некорректности аргументов того или иного класса — уличай, а не превращай форум в склоку и выяснение личных отношений.

Последи за своими выводами и характером вопросов. Ты берешь моё очень общее высказывание, не потрудившись оценить корректности предпосылок, примериваешь его на себя. Вероятно, по тем или иным причинам находишь, что в данном контексте (неизвестно, корректном или нет!) на тебя накладывается отрицательная оценка и бросаешься на оппонента с вызывающими и провоцирующими вопросами, т.е., — атакуешь, аргументируя на совершенно ином уровне. Какой я могу сделать из этого вывод? А такой, что ты очень трепетно относишься к признанию своей правоты, и очень агрессивно даже косвенному её оспариванию. Извини, но в таком случае стоило выходить из спора раньше. Хотя, конечно, я понимаю, что концептуальные споры — достаточно опасная штука.

В противовес такой позиции я — не боюсь признания своей неправоты и при доказанной их некорректности корректирую свои взгляды и суждения. Так что? У кого из нас должно сложиться "странное ощущение"?

ГВ>>Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется.
AVK>Тогда не надо делать таких высказываний. Я тебе привел в качестве аргумента свой опыт реализации проектов на джаве, а теперь уже и на дотнете. А ты мне, (о да, прямо кого либо ты не упоминаешь) говоришь что мол некие программисты пишут некие программы на дотнете лучше потому что они не умеют строить абстракции на С++.

Я не понимаю, что оскорбительного в признании умения/неумения строить абстракции какой-то глубины на C++? Я вот, например, плохо знаю дотнет и спокойно отношусь к тому, что меня тыкают носом в это незнание. Сегодня — не знаю, завтра — знаю. Что здесь обидного? А у моей уверенности в том, что немного людей может хорошо программировать на C++ тоже рациональные основы. Мне вот, практически не приходилось близко сталкиваться с людьми (кроме как на форумах RSDN), которые уверенно оперируют конструкциями вроде двухуровневых вложенных шаблонов или частичной специализации. Тогда как наивных вопросов по шаблонам и воплей об их сложности — более чем достаточно.

С дргой стороны... ну, про простоту дотнета я уже писал.

AVK>Знаешь, у меня с логикой все в порядке и я еще в состоянии сделать соответствующие выводы.

Только ты их однобоко очень делаешь. Часто видишь повод для обиды, вместо того, чтобы сказать, что у тебя, к примеру, нет подходящих (контр-)аргументов, или я неправомерно привожу свои.

ГВ>> Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы.
AVK>Нет, я доказываю что ему пора меняться.

Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая), или на основании столкновения с неудачной его реализацией (MSVC6). Тогда как возможность реализации какой-либо идиомы на C++ даже в одном-единственном случае (частное решение) вполне себе основание для того, чтобы не изменять его ради этой идиомы. Чистый рационализм.

Хотя, безусловно, я вижу достаточно веские причины для отказа от использования того же C++ в силу и при условии: а) невозможности использовать его в полную.силу (отклонения MSVC6) и б) невозможности сменить транслятор.

ГВ>>Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.
AVK>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.

Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.

ГВ>>Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?
AVK>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.

ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?

AVK>>>Математика не поспевает за программиролванием.
ГВ>>Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.
AVK>Это не математика.

Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу). Как следствие, придётся временно признать твой довод о том, что математика не поспевает за програмированием. Я поищу доказательства обратного. Кстати, здесь лежит моделирование перехвата вызовов методов на языке формальной семантики.

ГВ>>Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)
AVK>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.

"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).

AVK>>>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.
ГВ>>Не успев даже влезть в них полностью.

AVK>Ну это уже издержки развития.

И погони за модой, ИМХО... Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются). В результате создаётся соблазн "быстрых решений" и... распыление усилий на разные реализации одних и тех же абстракций.

AVK>>>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.
ГВ>>То есть, невозможно показать структурный граф программы или функции и просто посчитать характеристики его ребер? Позволю себе в этом с тобой не согласиться.
AVK>Я еще раз повторюсь — Не отменять, но и не делать ее определяющей.

Я не думаю, что в данном случае математика стала бы определяющим фактором, но анализ каких-то аспектов программы мог бы оказаться проще. Кстати, подобные продукты есть, например, на www.powersoftware.com. Но мне, признаться, они не понравились в силу того, что очень криво обрабатывают C++.

AVK>
ГВ>>Вопросы: 1. Что понимается под словами "нормальный спец"?
AVK>Человек который способен решать поставленные задачи и при этом решать их качественно.

Каковы задачи? Каковы критерии качества?

ГВ>>2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.)
AVK>Это зависит от обстоятельств. Как правило это руководитель группы.

Руководитель группы — практик. Без собственнной теоретической и практической подготовки его ученики или не сумеют сделать обобщений, или потратят на это уйму времени.

ГВ>>3. И захотят ли они сами этого? (ИМХО — нет.)
AVK>А им деваться будет некуда. Либо они учатся решать поставленные задачи либо идут лесом.

Здесь надо обсудить решаемые задачи. Мне вот приходилось экспертную систему за ~месяц писать, вместе с интерпретатором языка. Так что, давай обсудим масштаб решаемых задач. ИМХО (!) — он должен при вышеуказанных (п.2) раскладах "сжиматься" до простых практических задач с чётко ограниченным контекстом.

AVK>>>Обязательно. Иначе это не язык а абстракция.
ГВ>>А в противном случае это — гипертрофированный калькулятор.
AVK>Нет, это нормальный инструмент.

Хорошо, принимаю, что ты считаешь инструмент такого рода нормальным. (Здесь я не накладываю ни на кого отрицательных оценок)

AVK>>>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.
ГВ>>Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень.
AVK>Вот в этом все и дело. Тебе шашечки а тем кто деньги платит нужно ехать.

Ты совершенно прав. Предлагаю разобраться в значении этих терминов с учётом времени эксплуатации программы, её мутабельности и т.п.

AVK>>>Тот самый очень сложный под дотнет есть. MC++ называется.
ГВ>>Но это же не полный C++. А впрочем, это общая проблема...
AVK>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

А какие шаблоны там есть? Частичная специализация есть? Насколько я знаю — нет.

AVK>>>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.
ГВ>>Абсолютно согласен. Именно поэтому идеального языка не может быть, как и идеального процессора. А что мы имеем в случае .NET? Попытку нивелировать все .NET-языки под её лад.
AVK>Ну там достаточно простора для вариаций. А вобще увеличение ограничений от ассемблера через С, С++ к дотнету очень хорошо прослеживается. Не вижу причин считать что ограничения С++ еще позволительны а дотнета уже нет.

Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.

AVK>>>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.
ГВ>>Я — тоже.

AVK>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.

Аналогично. Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++. Отсюда (и из других наблюдений) делаю вывод, что Влад просто не может быть единственным в своём роде, то есть какой-то процент голосов "за" дотнет собрал за счёт именно подобных ситуаций. Думаешь, я сомневаюсь в его интеллектуальных качествах? Или — в твоих? Поверь — нисколько. Я сомневаюсь в правомерности употребления каких-то аргументов и не более того.

Я и сам нахлебался с VC++ проблем именно из-за отсутствия нормальной реализации шаблонов. А отсюда не получил своевременно достаточного опыта их использования, да и не сделал того, что хотел сделать. Но отказываться от них и от C++ не собираюсь, уж слишком велики были потенциальные пряники в плане повышения эффективности труда. А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.

То есть, я апеллирую к тому, что реально программный комплекс можно сделать быстро и качетвенно одним из двух подходов — либо унификацией внутренней структуры реализации прикладных аспектов (

), либо за счёт разбиения программы на "цельные" в прикладном смысле модули — и тогда приходится работать большой командой. Первый подход очень трудно осуществлять в большой команде — даже больше 2-3 чел., но пряники просто охренительны и шаблоны оказывают здесь огромную помощь. Кстати, разумеется, что первый подход ни в коем случае не исключает использования второго, но структура модулей выбирается исходя из требований deployment. Результат достижим и в том и в другом случаях, но во втором мы получаем с большой вероятностью потерю внутренней унификации, а отсюда — бо-о-ольшой ворох проблем в будущем. Ну, сам, вероятно, знаешь. Так вот, я — сторонник первого подхода. Можно обсудить его рациональность или отсутствие таковой.

AVK>>>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.
ГВ>>Вот этим последним предложением. Рантайм вряд ли будет всегда стандартен, в том смысле, что один и тот же рантайм будет везде и везде одинаков.
AVK>Пример джавы показывает что это не так.

Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM. Так что, мне кажется, что твоё обобщение далековато от реальности.

ГВ>>Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие.
AVK>Вот вот. А С++ не очень в плане совместимости.

Увы, это так. Но посмотрим, как всё сложится дальше. Как я недавно выяснил, IBM VAC++, Intel, GCC 2.95.2, Comeau весьма близко подошли к реализации стандарта.

ГВ>> И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь.
AVK>За сколько там лет существования джавы несовместимых рантаймов пока не появилось.

Я, пожалуй, перегнул палку, но имелось ввиду, что а) мелкие несовместимости всё равно будут, б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...

ГВ>>>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>>>Абсолютно неверно.
ГВ>>Хорошо, не прав. Способ превращения элементарных данных в объекты.
AVK>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.

ИМХО, — слабоватая альтернатива шаблонам в целом. Недостаток производительности может щёлкнуть по носу при глубоко структурированных абстракциях.

AVK>>>Так в чем проблема то?
ГВ>>Сделать предлагаешь? Может быть, когда-нибудь.
AVK>Вот. А в дотнете уже есть.

В дотнете нету C++. Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.

ГВ>>>>Что доказывает их подобие
AVK>>>И гибкость CLR.
ГВ>>И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

AVK>Рефлекшен где?

Да где-где...

У разработчиков трансляторов спросить надо.

AVK>>>Практика показывает что эффективность он таки повышает.
ГВ>>Охарактеризуй задачи на которых так происходит, если не трудно.
AVK>ERP, Web

А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.

AVK>>>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.
ГВ>>Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.
AVK>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.

Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.

ГВ>>Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО).
AVK>Вот вот. Все твои аргументы сводятся к тому что ты считаешь себя знатоком построения абстракций.

Скажем так, пока что — получается. И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.

ГВ>>>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>>>А зачем? Она в дотнете уже есть.
ГВ>>Не царское это дело — ставить свою программу в зависимость от...

AVK>Мне не шашечки, мне ехать. Написание художественных программ я оставлю на потом.

Рационализм простой. Клиенты могут быть и на Windows (от 95 до XP), и на Unix, и на IPX/SPX, и на Token Ring.
Так что, что такое "шашечки", и что такое "ехать" — очень достойно отдельного обсуждения.

AVK>>>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.
ГВ>>Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.
AVK>Было давно, лет эдак 6 назад, да и не хочется мне это обсуждать.

Ну, не хочешь — не будем.

Здравствуйте Геннадий Васильев, Вы писали:

ГВ>Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.
Ну и что? Это взаимозаменяемые вещи. Т.е. если приложение написано под .NET то нет никакого смысла пытаться запустить его на JVM. Это не аппаратура или ОС которые со средствами разработки не пересекаются.

ГВ>OK, CLR/ECMA.
Знаешь в чем отличие стандарта от нестандарта? MS не имеет права запретить кому либо использовать стандарт.

ГВ>Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?
Да, ты явно не занимался никогда администрированием достаточно большой системы. Когда на разных машинах существуют разные версии одного и того же софта это начинает напоминать ад.

AVK>>Ну а во всем остальном мире подобные проблемы решают как раз с помощью компонентных технологий. Впрочем, не буду спорить, доказывать необходимость компонентных технологий я не хочу. Все познается в ходе разработки.
ГВ>

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.
Ну слава богу. А разумные пределы нужны всегда и везде.

AVK>>Быстродействия нет, надежности да, причем в разы. Это практический опыт.
ГВ>Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения.
Вот в дотнете эти ограничения и называются интерфейсом.

ГВ> Плюс — предоставлен ряд готовых отлаженных механизмов управления компонентами. Т.е., — причина — в конкретике, а не в парадигме.
Про парадигму никто и не спорит.

ГВ>Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.
А все потому что нельзя создать язык полностью отвязанным от окружения. Попыток создать такие языки было много, но результата никакого. Только джава научилась обеспечивать относительно приемлемую переносимость, да и то проблемы и там есть.

ГВ>Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.
Аппетит приходит во время еды

Серьезно. Я в свое время, когда писал на паскале и С++ тоже джаву считал извращением. А потом пришлось работать на ней. Через пару месяцев работы мое мое мнение поменялось кардинально. И когда потом пришлось опять что то делать на С++ то он просто раздражал своей недоделанностью.

AVK>>Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.
ГВ>А я вот смотрю и стараюсь выяснить, чем является что-то до того, как начну его использовать, тем более, использовать так, что пути назад потом не окажется. Затем уже я вывожу своё отношение к способу подачи этого самого чего-то. Почему, кстати, и остановился на C++, а не на Delphi в своё время. Кстати, благодарен тебе за оппонирование в этой и других дискуссиях. Заставил (косвенно) поразбираться с .NET и C#. Спасибо. Платформа меня заинтересовала в чём-то.
Я несколько раз накололся и теперь у меня есть твердое убеждение — чтобы оценить технологию надо попытаться ее применить для решения конкретных задач, пусть и учебных.

ГВ>С другой стороны — а уж не ради ли неквалифицированных программистов, в частности, в дотнетовский C# внесены упрощения и сандартизированы идиомы?
Нет, не ради. Даже самый квалифицированный программист иногда делает ошибки. И долг языка попытаться свести количество этих ошибок к минимуму.

ГВ> Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял).
О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

ГВ> Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим
Да не упрощал никто модель. Кое в чем классы дотнета значительно сложнее классов С++. Просто акценты сдвинуты. С++ пляшет как бы от железа, а шарп от задач.

AVK>>Нет, я доказываю что ему пора меняться.
ГВ>Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая),
Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.

AVK>>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.
ГВ>Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

ГВ>На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.
Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.

AVK>>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.
ГВ>ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?
Да, конечно.

ГВ>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)

AVK>>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.
ГВ>"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).
Тут все на самом деле просто — если математика обеспечивает выполнение поставленных задач то хорошо. А вот если не выполняет то не надо считать что делать нечего, надо забивать на математику и переходить к эмпирике.

ГВ>И погони за модой, ИМХО...
Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.

ГВ> Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются).
Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.

AVK>>Человек который способен решать поставленные задачи и при этом решать их качественно.
ГВ>Каковы задачи?
Которые поставлены.

ГВ> Каковы критерии качества?
Зависит от задачи. Точнее не сами критерии а их вес.

AVK>>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

ГВ>А какие шаблоны там есть?
Те же что и в VC. ATL к примеру компилируется.

ГВ> Частичная специализация есть? Насколько я знаю — нет.
Выражайся по понятнее — кто такая частичная специализация?

ГВ>Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.
Просто дотнет дальше отошел от конкретики железок.

AVK>>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.
ГВ>Аналогично.
Да, но у Влада и IT был опыт общения с дотнетом.

ГВ>Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++.
Я в свое время писал на BC++.

ГВ>А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.
Я думаю что ничего ты пока не видишь и не увидишь пока не попробуешь что нибудь реализовать.

AVK>>Пример джавы показывает что это не так.
ГВ>Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM.
В основном в плане производительности. Да и потихоньку это правят.

ГВ>Так что, мне кажется, что твоё обобщение далековато от реальности.
В основном это связано со старыми JVM, теперь ситуация получше.

ГВ>Я, пожалуй, перегнул палку, но имелось ввиду, что а) мелкие несовместимости всё равно будут,
Мелкие несовместимости есть таже между разными поколениями процессоров. Вот только стараются чтобы они так и оставались мелкими и несущественными.

ГВ> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.

AVK>>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.
ГВ>ИМХО, — слабоватая альтернатива шаблонам в целом.
Вся их функциональность реализуема. Просто не надо пытаться делать это так как это делали при помощи шаблонов.

AVK>>Вот. А в дотнете уже есть.
ГВ>В дотнете нету C++.
Исть!

ГВ>Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.
Судя по чему?

ГВ>А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.
Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.

AVK>>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.
ГВ>Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.
Даже если бы его стандартизовали ничего бы от этого не изменилось.

ГВ>Скажем так, пока что — получается.
У меня, как ни странно, тоже.

ГВ> И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.
Вот дотнет и является очередным оружием в этой войне.

... Янус версия 1.0 alpha 3

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.
AVK>Ну и что? Это взаимозаменяемые вещи. Т.е. если приложение написано под .NET то нет никакого смысла пытаться запустить его на JVM. Это не аппаратура или ОС которые со средствами разработки не пересекаются.

Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.

ГВ>>OK, CLR/ECMA.
AVK>Знаешь в чем отличие стандарта от нестандарта? MS не имеет права запретить кому либо использовать стандарт.

Верю. Хотя ECMA — это далеко не ANSI/ISO. Так что, пока ещё верю в то, что "ECMA-стандарт" — только одна из карт в колоде Microsoft.

ГВ>>Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?
AVK>Да, ты явно не занимался никогда администрированием достаточно большой системы. Когда на разных машинах существуют разные версии одного и того же софта это начинает напоминать ад.

Занимался

Только ты сам ввёл очень жёсткие ограничения. Вот и всё.

AVK>>>Ну а во всем остальном мире подобные проблемы решают как раз с помощью компонентных технологий. Впрочем, не буду спорить, доказывать необходимость компонентных технологий я не хочу. Все познается в ходе разработки.
ГВ>>

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.
AVK>Ну слава богу. А разумные пределы нужны всегда и везде.

Правильно, и трансмутировать каждый чих программы в компонент как элемент компонентной технологии — ИМХО-неразумно. Компонентный deployment — на здоровье.

AVK>>>Быстродействия нет, надежности да, причем в разы. Это практический опыт.
ГВ>>Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения.
AVK>Вот в дотнете эти ограничения и называются интерфейсом.

ИМХО, они везде называются интерфейсом. И на самом деле, от их определённости многое зависит. Но их нужно определять в любой сложной разработке.

ГВ>>Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.
AVK>А все потому что нельзя создать язык полностью отвязанным от окружения. Попыток создать такие языки было много, но результата никакого. Только джава научилась обеспечивать относительно приемлемую переносимость, да и то проблемы и там есть.

Не только в рантайме дело. На C++ ещё относительно долго принимался стандарт. А рантайм у него очень маленький. Стандартные библиотеки не в счёт.

ГВ>>Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.
AVK>Аппетит приходит во время еды

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

ГВ>> Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял).
AVK>О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

Не согласен. Я думаю, что главная цель языка программирования пока ещё — помочь человеку выразить структуру (данных, поведения — уже неважно) и сделать это так, чтобы минимизировать другие сопутствующие расходы.

ГВ>> Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим
AVK>Да не упрощал никто модель. Кое в чем классы дотнета значительно сложнее классов С++. Просто акценты сдвинуты. С++ пляшет как бы от железа, а шарп от задач.

Я имел ввиду модель композиции абстракций. ИМХО, C++ как раз "пляшет" не от железа, а от фон-неймановской архитектуры. А то, что шарп пляшет от задач — "бяда, бяда — огорчение" (c). Думаешь, шарп — последний?

AVK>>>Нет, я доказываю что ему пора меняться.
ГВ>>Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая),
AVK>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.

Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.

AVK>>>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.
ГВ>>Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
AVK>Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

В это-то и весь прикол. Не спорю, что шаблоны можно заменить соответствующими структурами, построенными на базе общего корневого класса и RTTI, однако весь вопрос в переходе от количества к качеству. Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC. Никуда от этого не денешься. Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.

ГВ>>На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.
AVK>Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.

Здесь надо конкретные условия оценить. Что за серверы приложений? Под какую функциональность, нагрузку? Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.

AVK>>>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.
ГВ>>ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?
AVK>Да, конечно.

ГВ>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)

Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.

AVK>>>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.
ГВ>>"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).
AVK>Тут все на самом деле просто — если математика обеспечивает выполнение поставленных задач то хорошо. А вот если не выполняет то не надо считать что делать нечего, надо забивать на математику и переходить к эмпирике.

Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).

ГВ>>И погони за модой, ИМХО...
AVK>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.

Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.

ГВ>> Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются).
AVK>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.

Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена. Уродств реализаций программ в терминах процедур SQL я насмотрелся по уши. ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.

В данном случае результат "надежность и стабильность бизнес-приложений" стоит рассматривать только в контексте условий его возникновения: кто, когда и в каких условиях писал и т.п.

AVK>>>Человек который способен решать поставленные задачи и при этом решать их качественно.
ГВ>>Каковы задачи?
AVK>Которые поставлены.

Охарактеризуй задачи, если не затруднит.

ГВ>> Каковы критерии качества?
AVK>Зависит от задачи. Точнее не сами критерии а их вес.

Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?

AVK>>>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

ГВ>>А какие шаблоны там есть?
AVK>Те же что и в VC. ATL к примеру компилируется.

ГВ>> Частичная специализация есть? Насколько я знаю — нет.
AVK>Выражайся по понятнее — кто такая частичная специализация?

Что мы там о вкусе устриц говорили?

Шутка.

Частичная специализация позволяет изменить реализацию шаблона для определённых заданных случаев его аргументов. Ну, например:

// Вот это - общий шаблон (1)
template<class T, class U> class A { ... };

// А это - частичная специализация для тех случаев,
// когда вторым аргументом шаблона A<x,y> является тип int. (2)
template<class T> class A<T, int> { ... };

// Использование (ну очень кратко):
A<double, double> a; // Инстанцирование генерится из (1)
A<double, [b]int[b]> b; // Инстанцирование генерится из (2)

Подробнее см. ANSI/ISO-14882:1998, 14.5.4.

Если компилятор не поддерживает частичной специализации, то приходится безумно извращаться и корёжить всё структуру абстракций. Или бросать эту затею нахрен и выворачиваться с помощью виртуальных функций и т.п.
MSVC поддерживает только "полную" специализацию, т.е., позволяет сделать особую реализацию шаблона только полностью специфицировав его аргументы. Приведённый пример пришлось бы делать примерно так:

// Вот это - общий шаблон (1)
template<class T, class U> class A { ... };

// А вот теперь мы не можем задать частичную специализаию, поэтому извращаемся,
// перечисляя специализации со торым аргументом типа int.
template<> class A<int, int> { ... };
template<> class A<double, int> { ... }; // (2)
template<> class A<char*, int> { ... };

// Использование (ну очень кратко):
A<double, double> a; // Инстанцирование генерится из (1)
A<double, [b]int[b]> b; // Инстанцирование генерится из (2)

Ну, и так далее. Отсутствие частичной специализации очень мешает, например, при разработке системных библиотек.

ГВ>>Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.
AVK>Просто дотнет дальше отошел от конкретики железок.

C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?

AVK>>>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.
ГВ>>Аналогично.
AVK>Да, но у Влада и IT был опыт общения с дотнетом.

Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.

ГВ>>Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++.
AVK>Я в свое время писал на BC++.

Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.

ГВ>>А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.
AVK>Я думаю что ничего ты пока не видишь и не увидишь пока не попробуешь что нибудь реализовать.

Уже кое-что прояснилось.

У меня с индукцией всё в порядке.

AVK>>>Пример джавы показывает что это не так.
ГВ>>Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM.
AVK>В основном в плане производительности. Да и потихоньку это правят.

Ну, ещё J# заиграет всеми красками...

ГВ>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.

Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.

AVK>>>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.
ГВ>>ИМХО, — слабоватая альтернатива шаблонам в целом.
AVK>Вся их функциональность реализуема. Просто не надо пытаться делать это так как это делали при помощи шаблонов.

Не смешно. Если заменять шаблоны даже виртуальными функциями, проигрыш в быстродействии — порядок или около того. Это же кумулятивный эффект — попробуй сравнить быстродействие с plain-int и с boxed-int (я не знаю конкретных цифр). А процессорные мощности всегда будут небесконечными.

AVK>>>Вот. А в дотнете уже есть.
ГВ>>В дотнете нету C++.
AVK>Исть!

Если предположить, что C++ — это множественное наследование и простейшие шаблоны (контейнеры + ATL), то твоё утверждение истинно, если же учесть, что исходная посылка состоит в том, что C++ — это ещё и поддержка частичной специализации и ещё кучи комбинационных возможностей шаблонов — то твоё утверждение ложно.

ГВ>>Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.
AVK>Судя по чему?

Судя по отзывам в форуме C/C++ и по результатам попыток трансляции делегатов Владом.

ГВ>>А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.
AVK>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.

Интересует что-нибудь из этого: количество экранов, модулей, таблиц, общий объём исходников.

AVK>>>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.
ГВ>>Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.
AVK>Даже если бы его стандартизовали ничего бы от этого не изменилось.

Согласен, поскольку он нафиг не нужен. Я просто иллюстрировал идею о промежуточной трансляции в P-код.

ГВ>>Скажем так, пока что — получается.
AVK>У меня, как ни странно, тоже.

OK.

ГВ>> И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.
AVK>Вот дотнет и является очередным оружием в этой войне.

Да, только немалая часть этой сложности — прямые следствия маркетинговых войн и результатов неполной их трактовки. А дотнет — оружие обоюдоострое. Страдают обычно пользователи.

[skip]

............. 2080-й год, отрывки из 39998792394234 сообщения в данном сабже, тема плавно перешла в формулировку "Чем же так привлекателен С#", в споре учавствуют внук Геннадия Васильева, приверженец чистого творческого программинга по старинке на С Шарп, и правнучатый племянник Андрея Владимировича, представителя нового поколения системных архитекторов, предпочитающих программировать клацая на менюшки и кнопочки, заполняя всевозможные визарды, и расскрашивая панельки построенных в визардах окошек в модные современные цвета.

Правнук Геннадия Васильева> Я придпочитаю самостоятельно планировать функциональность и иерархию абстракций, и благодаря гибкости языка это позволяет контроллтровать системные рессурсы.

Внучатый Племянник Андрея Владимировича> Твои старые технологии и никому непонятные ( да и не нужные )абсракции не в состоянии в течении полутора часов развернуть хорошо масштабируемое приложение для бизнес среды большого предприятия с несколькими сотнями тысяч рабочих мест, со сложными бизнес связями и развитыми инфраструктурами, принятыми в современном воркфлоу. И всю эту сложнейшую систему я в состоянии построить в течении нескольких часов, благодаря новейшей технологии генерации систем подобного рода на лету, разработки ведущего лидера в этой области "МегаСуперСофт". И все что мне при этом нужно — это заполнить несколько сотен визардов и форм, нажать кнопку Финиш и откинуться на спинку стула, наблюдая за рождением моего детища!!!

Здравствуйте Геннадий Васильев, Вы писали:

ГВ>Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.
Ты мне не расскажешь зачем?

ГВ>Ну что же, я могу только посокрушаться по этому поводу. С другой стороны — если это был 96-98 гг, то ничего удивительного.
А что — С++ с 96 года сильно изменился?

AVK>>Нет, не ради. Даже самый квалифицированный программист иногда делает ошибки. И долг языка попытаться свести количество этих ошибок к минимуму.

ГВ>Истинно так.

Что частично решается средствами C++, а вернее — шаблонами. Такое же частичное решение — атрибуты классов и рантайм-контроль. Применение последнего всегда приводит к увеличению вычислительной нагрузки. Притом — весьма нехилому.
Ну не так все на самом деле страшно. Приводит, да. Но не забывай что рантайм оптимизирован именно для таких операций. Так что в итоге все получается вполне приемлемо.

AVK>>О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

ГВ>Не согласен. Я думаю, что главная цель языка программирования пока ещё — помочь человеку выразить структуру (данных, поведения — уже неважно) и сделать это так, чтобы минимизировать другие сопутствующие расходы.
Ну так это и есть средство выражения.

AVK>>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.
ГВ>Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.
Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.

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

ГВ>В это-то и весь прикол. Не спорю, что шаблоны можно заменить соответствующими структурами, построенными на базе общего корневого класса и RTTI, однако весь вопрос в переходе от количества к качеству.
Не так уж там все медленно чтобы быть неприменимым. А в особо извращенных случаях можно сделать типизированные неполиморфные коллекции, обычно больших и критичных к быстродействию коллекций в программе мало, а часто вобще нет. Ну а если таких коллекций много то можно написать рантайм-генератор типизированных коллекций, или, если очень хочется контроля типов — генератор исходников. В общем как и в С++ в шарпе большинство задач решаемы. Все их отличие в плане выразительности заключается в акцентах. В шарпе акценты иные, а ты пытаешься мерить его плюсовым аршином. Да, есть вещи которые на С++ выразить проще, но есть вещи которые выразить проще на шарпе. Вопрос в том — что это за вещи.

ГВ> Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC.
У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ> Никуда от этого не денешься.
Вот опять ты не в курсе про наличие value-типов в дотнете и принципы работы GC и поэтому делаешь неверные выводы.

ГВ> Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.
Все это так, но можно привести и обратные примеры.

AVK>>Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.
ГВ>Здесь надо конкретные условия оценить. Что за серверы приложений?
Ну все тоже самое — ERP, Web

ГВ>Под какую функциональность, нагрузку?
Под приличную

ГВ> Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.
Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?

ГВ>>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)
ГВ>Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.
Ну математика то здесь при чем? Если конечно не назвать computer science математикой.

ГВ>Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).
Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.

AVK>>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.
ГВ>Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.
Вон все жужжат про веб сервисы. А на самом деле вещь достаточно узкоспециальная и отнюдь не вундерваффе программных технологий. Мне хватило пару дней чтобы разобраться. Зато в дотнете есть ремоутинг который в разы гибче и удобнее веб-сервисов, и тоже при должном желании вполне многоплатформенный, а о нем почему то не жужжат. Так что меньше надо слушать что жужжат и тем более не стоит по этому жужжанию оценивать программные технологии. Лучше взять документацию и почитать.

AVK>>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.
ГВ>Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена.
Увы да. Хотя идея очень красивая. Правда говорят что каше все же довели до ума. Вон компакт прислали, все никак руки не дойдут посмотреть.

ГВ> Уродств реализаций программ в терминах процедур SQL я насмотрелся по уши.
До SQL было еще хуже.

ГВ>ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.
Я тебе еще раз повторюсь — в современных продуктах ХП используются очень интенсивно до сих пор. И только массовое использование серверов приложений способно их оттуда вытолкнуть. Но сервера приложений штука довольно таки сложная, серверный софт все же сильно отличается по требованиям от настольного. Вот поэтому и появились Java2 и .NET чтобы получить языки и платформы которые были бы удобны для создания этого самого серверного софта.

AVK>>Которые поставлены.
ГВ>Охарактеризуй задачи, если не затруднит.
Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?

ГВ>>> Каковы критерии качества?
AVK>>Зависит от задачи. Точнее не сами критерии а их вес.
ГВ>Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?
Не так подробно — есть критерий простота модификации, в том числе и глубокой.

AVK>>Просто дотнет дальше отошел от конкретики железок.

ГВ>C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?
Ориентирован он, еще как ориентирован. Он зависит от порядка следования байтов в машинном слове к примеру.
Т.е. если на разных машинах порядок следования разный то надо это специально учитывать. Зависит от длинны машинного слова — int то он каждый раз иной.

AVK>>Да, но у Влада и IT был опыт общения с дотнетом.
ГВ>Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.
Судя по твоим словам нормальные С++ компиляторы только появились, и то, точно ты не знаешь потому что не смотрел. Так что видимо и у тебя такого опыта не было.

ГВ>Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.
По первости на 3.1, потом на 4.5 и немножко на 5.0.

AVK>>В основном в плане производительности. Да и потихоньку это правят.
ГВ>Ну, ещё J# заиграет всеми красками...
J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.

ГВ>>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.
ГВ>Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.
дотнет должен быть бинарно совместим. Так что каши не будет.

AVK>>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.
ГВ>Интересует что-нибудь из этого: количество экранов,
Не считали
ГВ> модулей,
Какие модули в джаве? Ты о чем?
ГВ> таблиц,
где то сотни две с половиной — три.
ГВ> общий объём исходников.
Тоже как то не интересновался. Несколько мегабайт.

AVK>>Даже если бы его стандартизовали ничего бы от этого не изменилось.
ГВ>Согласен, поскольку он нафиг не нужен. Я просто иллюстрировал идею о промежуточной трансляции в P-код.
P-код при наличии джита нужен только для бинарного и переносимого представления. Исполняется все равно нативный код.

... Янус версия 1.0 alpha 3

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.
AVK>Ты мне не расскажешь зачем?

Один из примеров приведён тобой (см. ниже).

ГВ>>Ну что же, я могу только посокрушаться по этому поводу. С другой стороны — если это был 96-98 гг, то ничего удивительного.
AVK>А что — С++ с 96 года сильно изменился?

Не столько C++, сколько инструменты, его поддерживающие. Кроме того, стандарт был принят-таки в 98 г.

ГВ>>... Что частично решается средствами C++, а вернее — шаблонами. Такое же частичное решение — атрибуты классов и рантайм-контроль. Применение последнего всегда приводит к увеличению вычислительной нагрузки. Притом — весьма нехилому.
AVK>Ну не так все на самом деле страшно. Приводит, да. Но не забывай что рантайм оптимизирован именно для таких операций. Так что в итоге все получается вполне приемлемо.

OK, предположим.

AVK>>>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.
ГВ>>Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.
AVK>Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.

Точно. Только ты уже повёлся на маркетинг. Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве. MS будет подкармливать .NET-овцев, а IBM, Sun и иже с ними будут подкармливать OSF.

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

ГВ>>В это-то и весь прикол. Не спорю, что шаблоны можно заменить соответствующими структурами, построенными на базе общего корневого класса и RTTI, однако весь вопрос в переходе от количества к качеству.
AVK>Не так уж там все медленно чтобы быть неприменимым. А в особо извращенных случаях можно сделать типизированные неполиморфные коллекции, обычно больших и критичных к быстродействию коллекций в программе мало, а часто вобще нет. Ну а если таких коллекций много то можно написать рантайм-генератор типизированных коллекций, или, если очень хочется контроля типов — генератор исходников. В общем как и в С++ в шарпе большинство задач решаемы. Все их отличие в плане выразительности заключается в акцентах. В шарпе акценты иные, а ты пытаешься мерить его плюсовым аршином. Да, есть вещи которые на С++ выразить проще, но есть вещи которые выразить проще на шарпе. Вопрос в том — что это за вещи.

Да. И именно об этом мы и дискутируем.

И часть этого вопроса — глубина структуры представления вещей и её зависимость от разных факторов, среди которых — итоговое быстродействие и суммарная компактность — не самые последние.

ГВ>> Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC.
AVK>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

1. Структуры — это всё-таки не совсем классы. 2. Ну какая разница: сам GC находит или ему передают?

ГВ>> Никуда от этого не денешься.
AVK>Вот опять ты не в курсе про наличие value-типов в дотнете и принципы работы GC и поэтому делаешь неверные выводы.

Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).

ГВ>> Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.
AVK>Все это так, но можно привести и обратные примеры.

Примеры в студию!

ГВ>> Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.
AVK>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.

Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.

AVK> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?

Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.

ГВ>>>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>>>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)
ГВ>>Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.
AVK>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.

Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.

ГВ>>Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).
AVK>Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.

OK, не буду обобщать в смысле названия (это была в определённом смысле метафора), хотя инструменты из теории множеств и булевой алгебры используются нередко.

AVK>>>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.
ГВ>>Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.
AVK>Вон все жужжат про веб сервисы. А на самом деле вещь достаточно узкоспециальная и отнюдь не вундерваффе программных технологий. Мне хватило пару дней чтобы разобраться. Зато в дотнете есть ремоутинг который в разы гибче и удобнее веб-сервисов, и тоже при должном желании вполне многоплатформенный, а о нем почему то не жужжат. Так что меньше надо слушать что жужжат и тем более не стоит по этому жужжанию оценивать программные технологии. Лучше взять документацию и почитать.

Я тоже оцениваю технологии не по жужжанию и согласен с твоим подходом. Но а) не все и не всегда поступают аналогично и б) не всегда слышны трезвые голоса, поскольку общий гвалт только возрастает.

AVK>>>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.
ГВ>>Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена.
AVK>Увы да. Хотя идея очень красивая. Правда говорят что каше все же довели до ума. Вон компакт прислали, все никак руки не дойдут посмотреть.

OK, Cache потом.

ГВ>>ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.
AVK>Я тебе еще раз повторюсь — в современных продуктах ХП используются очень интенсивно до сих пор. И только массовое использование серверов приложений способно их оттуда вытолкнуть. Но сервера приложений штука довольно таки сложная, серверный софт все же сильно отличается по требованиям от настольного. Вот поэтому и появились Java2 и .NET чтобы получить языки и платформы которые были бы удобны для создания этого самого серверного софта.

Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.

AVK>>>Которые поставлены.
ГВ>>Охарактеризуй задачи, если не затруднит.
AVK>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?

Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.

ГВ>>>> Каковы критерии качества?
AVK>>>Зависит от задачи. Точнее не сами критерии а их вес.
ГВ>>Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?
AVK>Не так подробно — есть критерий простота модификации, в том числе и глубокой.

OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.

AVK>>>Просто дотнет дальше отошел от конкретики железок.

ГВ>>C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?
AVK>Ориентирован он, еще как ориентирован. Он зависит от порядка следования байтов в машинном слове к примеру.
AVK>Т.е. если на разных машинах порядок следования разный то надо это специально учитывать. Зависит от длинны машинного слова — int то он каждый раз иной.

Порядок байт надо специально учитывать только при обработке взаимодействий с внешними средствами (сети, как правило). Ну будет у меня одна функция, переупорядочивающая байты. И всё. На остальную структуру программы это не сильно повлияет.

AVK>>>Да, но у Влада и IT был опыт общения с дотнетом.
ГВ>>Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.
AVK>Судя по твоим словам нормальные С++ компиляторы только появились, и то, точно ты не знаешь потому что не смотрел. Так что видимо и у тебя такого опыта не было.

К сожалению. И мне действительно очень много неудобств доставило отсутствие нормальной поддержки шаблонов в MSVC. Сравнение же компиляторов, на которое я нередко опираюсь лежит на: http://www.cuj.com/roundup/a.htm?topic=reference

ГВ>>Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.
AVK>По первости на 3.1, потом на 4.5 и немножко на 5.0.

Мда. Именно их я и имел ввиду...

AVK>>>В основном в плане производительности. Да и потихоньку это правят.
ГВ>>Ну, ещё J# заиграет всеми красками...
AVK>J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.

См. начало постинга.

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

ГВ>>>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>>>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.
ГВ>>Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.
AVK>дотнет должен быть бинарно совместим. Так что каши не будет.

С чем он должен быть бинарно совместим? ИМХО — только с самим собой. (Я не забыл, что он потенциально может ездить по любым аппаратным платформам). Вся прочая совместимость — только через исходники или "интероп". Иного пути нет.

AVK>>>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.
ГВ>>Интересует что-нибудь из этого: количество экранов,
AVK>Не считали

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

ГВ>> модулей,
AVK>Какие модули в джаве? Ты о чем?

А... Java. Тогда — количесто классов. Одним словом — количество deployment items.

ГВ>> таблиц,
AVK>где то сотни две с половиной — три.
ГВ>> общий объём исходников.
AVK>Тоже как то не интересновался. Несколько мегабайт.

Вот как раз этот объём и хорошо бы соотнести с числом экранов.

Здравствуйте Геннадий Васильев, Вы писали:

ГВ>Здравствуйте AndrewVK, Вы писали:

AVK>>А что — С++ с 96 года сильно изменился?
ГВ>Не столько C++, сколько инструменты, его поддерживающие. Кроме того, стандарт был принят-таки в 98 г.
Вот только что роадмап почитал — MS заявляет что в следующем релизе студии он реализует стандарт на 90%. Да, хорош язык коль такой монстр как MS смог реализовать 90% только к 8 версии.

AVK>>Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.
ГВ>Точно. Только ты уже повёлся на маркетинг.
Давай ты не будешь за меня говорить, ладно? Когда я заинтересовался дотнетом еще никакого маркетинга не было. Была бета которую я скачал и посмотрел. Посмотрел потому что мне было интересно.

ГВ> Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве.
Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

AVK>>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ>1. Структуры — это всё-таки не совсем классы.
Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.

ГВ> 2. Ну какая разница: сам GC находит или ему передают?
Очень большая. Когда GC ищет комп обычно не загружен и все равно простаивает. Т.е. в результате влияние GC на быстродействие заметно меньше чем того же сишного хипа. Можешь IT пораспрашивать, он в свое время очень тщательно это тестировал. А у Влада можешь спросить насколько критична скорость выделения/уничтожения объектов в хипе для общего быстродействия. Он тоже пробовал.

ГВ>Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).
Если тебе нужно быстродействие при работе с памятью используй структуры.

AVK>>Все это так, но можно привести и обратные примеры.
ГВ>Примеры в студию!
Тут этих примеров было вагон и маленькая тележка.

AVK>>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
ГВ>Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.
Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

AVK>> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?
ГВ>Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.
Приложение с веб-интерфейсом. Так понятнее?

AVK>>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.
ГВ>Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.
Ну тогда все точные науки математикой обозвать можно.

AVK>>Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.
ГВ>OK, не буду обобщать в смысле названия (это была в определённом смысле метафора), хотя инструменты из теории множеств и булевой алгебры используются нередко.
Используются, но чаще всего как вспомогательные.

ГВ>Я тоже оцениваю технологии не по жужжанию и согласен с твоим подходом. Но а) не все и не всегда поступают аналогично и б) не всегда слышны трезвые голоса, поскольку общий гвалт только возрастает.
Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.

ГВ>Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.
Это лучше чем если бы их не было.

AVK>>>>Которые поставлены.
ГВ>>>Охарактеризуй задачи, если не затруднит.
AVK>>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?
ГВ>Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.
Ну нет, дело совсем не так было. Ты спросил что такое спец. Я ответил что это человек который способен качественно решать поставленные перед ним задачи. Ты спросил какие. Я естественно ответил что которые поставлены. А что я еще мог тебе ответить?

AVK>>Не так подробно — есть критерий простота модификации, в том числе и глубокой.
ГВ>OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.
А так — никто заранее не знает. Есть определенные, полученные эмпирически прикидки.

ГВ>Порядок байт надо специально учитывать только при обработке взаимодействий с внешними средствами (сети, как правило).
А еще с файлами, БД, и т.д.

ГВ>Ну будет у меня одна функция, переупорядочивающая байты. И всё. На остальную структуру программы это не сильно повлияет.
Тока эту функцию в зависимости от платформы вызывать надо.

AVK>>По первости на 3.1, потом на 4.5 и немножко на 5.0.
ГВ>Мда. Именно их я и имел ввиду...

Ну так там на 5.5 вроде все закончилось. Или ты билдер имеешь ввиду?

AVK>>J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.
ГВ>См. начало постинга.

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

AVK>>дотнет должен быть бинарно совместим. Так что каши не будет.
ГВ>С чем он должен быть бинарно совместим? ИМХО — только с самим собой.
Этого достаточно.

AVK>>Не считали
ГВ>Попробуйте посчитать. Особенно в соотношении с другими показателями могут получиться интересные цифры.

Не получиться. Я давно уже там не работаю.

ГВ>А... Java. Тогда — количесто классов. Одним словом — количество deployment items.
Много, больше тысячи точно. Точнее не знаю.

AVK>>Тоже как то не интересновался. Несколько мегабайт.
ГВ>Вот как раз этот объём и хорошо бы соотнести с числом экранов.

А ты что рассчитываешь узнать? И о каких экранах речь идет? Там собственно формочек было очень мало — 90% интерфейсов собиралось на лету. Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.

... Янус версия 1.0 alpha 3

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Здравствуйте AndrewVK, Вы писали:

AVK>Вот только что роадмап почитал — MS заявляет что в следующем релизе студии он реализует стандарт на 90%. Да, хорош язык коль такой монстр как MS смог реализовать 90% только к 8 версии.

ИМХО — хорош монстр!

А если совсем ИМХХО, то это признак того, что монстру просто это не было нужно. А отнюдь не показатель характеристик языка.

AVK>Давай ты не будешь за меня говорить, ладно? Когда я заинтересовался дотнетом еще никакого маркетинга не было. Была бета которую я скачал и посмотрел. Посмотрел потому что мне было интересно.

Ни секунды в этом не сомневаюсь. Посмотрел, потому что было интересно.

ГВ>> Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве.
AVK>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит! Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?

AVK>
AVK>>>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ>>1. Структуры — это всё-таки не совсем классы.
AVK>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.

Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type. Собственно, struct отличается от class только public-доступом по умолчанию. Сам же знаешь. Или не ощущаешь разницы?

ГВ>> 2. Ну какая разница: сам GC находит или ему передают?
AVK>Очень большая. Когда GC ищет комп обычно не загружен и все равно простаивает. Т.е. в результате влияние GC на быстродействие заметно меньше чем того же сишного хипа. Можешь IT пораспрашивать, он в свое время очень тщательно это тестировал. А у Влада можешь спросить насколько критична скорость выделения/уничтожения объектов в хипе для общего быстродействия. Он тоже пробовал.

Я это и сам хорошо понимаю. Только если сервер работает в режиме 24x7 то...

ГВ>>Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).
AVK>Если тебе нужно быстродействие при работе с памятью используй структуры.

Т.е., вопросы, связанные с управлением памятью также перекладываются на проектирование, как и для C++?

AVK>>>Все это так, но можно привести и обратные примеры.
ГВ>>Примеры в студию!
AVK>Тут этих примеров было вагон и маленькая тележка.

Да, я помню примеры о компонентах, летающих по станциям сети и генерацию прокси-классов. Я думал, ты приведёшь какой-то более частный случай, который не сводится к компонентизации. Ну, не хочешь — не смею настаивать.

AVK>>>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
ГВ>>Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.
AVK>Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

С++ и компонентные технологии — понятия несколько разных категорий, не находишь? Напоминаю, что я говорил, что а) компонентные технологии нужны на своём месте, б) что можно обойтись без COM, в) ради поддержки компонентных технологий не стоит менять C++. Как из этого могло последовать, что я отрицаю модульность (компонентные технологии — просто модное обозначение этой парадигмы) и собираюсь реализовывать СП без неё?

Без той или иной ипостаси модульного deployment "вода не освятится" в любом случае. А самый общий и самый сложный момент организации взаимодействия "бизнес-приложений" — это решение проблемы "отсечения" клиентов (не пользователей, а объектов-клиентов) от тех модулей, которые предполагается выгрузить и обновить. ИМХО, это общий момент. Не находишь?

Ну нельзя же отцепить модуль, если его объекты в настоящий момент используются! Однако это решается разными способами и в том числе, — подходящими идиомами указателей, но только в рамках межмодульных интерфейсов. Остальные проблемы — конвертации БД, освобождение библиотек, компонентов и т.п. — решаются проще. Только при этом внутри модулей (и, кстати, для интерфейсов экспортируемых ими классов) сохраняются все преимущества использования C++, а в особенности — библиотек шаблонов, которые не тянут за собой трёх вагонов других модулей.

Сервер обеспечивает приложения набором необходимых сервисов, в т.ч. — сервисами загрузки/выгрузки модулей и контролем их функционирования. Вот, собственно и всё основное. Зачем же его перекомпилировать-то?

AVK>>> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?
ГВ>>Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.
AVK>Приложение с веб-интерфейсом. Так понятнее?

Замечательно! Я именно на это определение и надеялся.

Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак) А место C++ здесь — очень даже на стороне приложения. Ну не виноват я, что принято реализовывать прикладную логику на интерфейсных и скриптовых языках. Не виноват!

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.

AVK>>>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.
ГВ>>Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.
AVK>Ну тогда все точные науки математикой обозвать можно.

Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.

ГВ>>Я тоже оцениваю технологии не по жужжанию и согласен с твоим подходом. Но а) не все и не всегда поступают аналогично и б) не всегда слышны трезвые голоса, поскольку общий гвалт только возрастает.
AVK>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.

Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

ГВ>>Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.
AVK>Это лучше чем если бы их не было.

Бесспорно, но одно другого всё равно не отменяет.

AVK>>>>>Которые поставлены.
ГВ>>>>Охарактеризуй задачи, если не затруднит.
AVK>>>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?
ГВ>>Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.
AVK>Ну нет, дело совсем не так было. Ты спросил что такое спец. Я ответил что это человек который способен качественно решать поставленные перед ним задачи. Ты спросил какие. Я естественно ответил что которые поставлены. А что я еще мог тебе ответить?

Пожалуй, что я тут тоже не совсем корректно себя повёл. Пока снимаю вопрос. Обсудим его попозже, если настроение будет.

AVK>>>Не так подробно — есть критерий простота модификации, в том числе и глубокой.
ГВ>>OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.
AVK>А так — никто заранее не знает. Есть определенные, полученные эмпирически прикидки.

Так, принимаю к сведению.

ГВ>>Порядок байт надо специально учитывать только при обработке взаимодействий с внешними средствами (сети, как правило).
AVK>А еще с файлами, БД, и т.д.

Суть — внешние средства.

ГВ>>Ну будет у меня одна функция, переупорядочивающая байты. И всё. На остальную структуру программы это не сильно повлияет.
AVK>Тока эту функцию в зависимости от платформы вызывать надо.

Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.

AVK>>>По первости на 3.1, потом на 4.5 и немножко на 5.0.
ГВ>>Мда. Именно их я и имел ввиду...

AVK>Ну так там на 5.5 вроде все закончилось. Или ты билдер имеешь ввиду?

Нет-нет, именно Borland C++ 3.1 до 5.5. Ещё бытовало название "Багланд".

AVK>>>дотнет должен быть бинарно совместим. Так что каши не будет.
ГВ>>С чем он должен быть бинарно совместим? ИМХО — только с самим собой.
AVK>Этого достаточно.

Для работы C# — да.

ГВ>>А... Java. Тогда — количесто классов. Одним словом — количество deployment items.
AVK>Много, больше тысячи точно. Точнее не знаю.

Немало...

AVK>А ты что рассчитываешь узнать? И о каких экранах речь идет? Там собственно формочек было очень мало — 90% интерфейсов собиралось на лету.

Вот это уже неплохо.

AVK>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.

Для отчётов генератор делали или готовым пользовались, коль не секрет?

Здравствуйте Геннадий Васильев, Вы писали:

AVK>>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

ГВ>Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит!

Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

ГВ>Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?
Persistence Software имеешь ввиду? Да, знакомо. А тебе Castor? Из той же оперы.

AVK>>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.
ГВ>Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type.
А в шарпе в safe коде от указателей избавились. Отсуда и отличия. Зато у С++ есть примитивы, а есть классы/структуры. А в шарпе и примитивы это тоже структуры.

ГВ> Собственно, struct отличается от class только public-доступом по умолчанию. Сам же знаешь. Или не ощущаешь разницы?
Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>Я это и сам хорошо понимаю. Только если сервер работает в режиме 24x7 то...
То что? У самого загруженного сервера нагрузка все равно неравномерна.

AVK>>Если тебе нужно быстродействие при работе с памятью используй структуры.
ГВ>Т.е., вопросы, связанные с управлением памятью также перекладываются на проектирование, как и для C++?
Нет, только тогда когда тебе нужно выжать максимум быстродействия.

AVK>>Тут этих примеров было вагон и маленькая тележка.
ГВ>Да, я помню примеры о компонентах, летающих по станциям сети и генерацию прокси-классов. Я думал, ты приведёшь какой-то более частный случай, который не сводится к компонентизации. Ну, не хочешь — не смею настаивать.
Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.

AVK>>Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

ГВ>Без той или иной ипостаси модульного deployment "вода не освятится" в любом случае. А самый общий и самый сложный момент организации взаимодействия "бизнес-приложений" — это решение проблемы "отсечения" клиентов (не пользователей, а объектов-клиентов) от тех модулей, которые предполагается выгрузить и обновить. ИМХО, это общий момент. Не находишь?

Ну нельзя же отцепить модуль, если его объекты в настоящий момент используются!
Вот видишь, ты даже возможности такой не видишь. Рекомендую для ознакомления ну например Resin. Он то как не странно вполне замечательно на лету меняет энтерпрайз-бины.

ГВ>Однако это решается разными способами и в том числе, — подходящими идиомами указателей, но только в рамках межмодульных интерфейсов.
Это все общие слова. Ты мне объясни как ты собираешься заменять висящие в памяти классы.

ГВ> Остальные проблемы — конвертации БД, освобождение библиотек, компонентов и т.п. — решаются проще. Только при этом внутри модулей (и, кстати, для интерфейсов экспортируемых ими классов) сохраняются все преимущества использования C++, а в особенности — библиотек шаблонов, которые не тянут за собой трёх вагонов других модулей.
Вагон слов и ничего конкретного.

ГВ>Сервер обеспечивает приложения набором необходимых сервисов, в т.ч. — сервисами загрузки/выгрузки модулей и контролем их функционирования. Вот, собственно и всё основное. Зачем же его перекомпилировать-то?
Сервисы ты эти как реализовывать будешь?

или "GUI-приложению", но не вижу в этом смысла.
AVK>>Приложение с веб-интерфейсом. Так понятнее?

ГВ>Замечательно! Я именно на это определение и надеялся.

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.
Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.

AVK>>Ну тогда все точные науки математикой обозвать можно.
ГВ>Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.
Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

AVK>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

AVK>>А еще с файлами, БД, и т.д.
ГВ>Суть — внешние средства.
Тока эти внешние средства есть во всех приложениях.

AVK>>Тока эту функцию в зависимости от платформы вызывать надо.
ГВ>Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.
При чем тут оптимизация? На платформе А порядок следования байтов один, на платформе В другой. Если ты пишешь код для обоих платформ тебе придется учитывать это.

ГВ>Нет-нет, именно Borland C++ 3.1 до 5.5. Ещё бытовало название "Багланд".
Ну так другиъх и не было. А названия к чему только не придумывали.

AVK>>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.
ГВ>Для отчётов генератор делали или готовым пользовались, коль не секрет?
Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.

... Янус версия 1.0 alpha 3

Извини, предыдущее сообщение глюкодромно отправилось.

Здравствуйте AndrewVK, Вы писали:

AVK>>>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

ГВ>>Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит!

AVK>Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

А почему ты занимался джавой? Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.

ГВ>>Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?
AVK>Persistence Software имеешь ввиду? Да, знакомо. А тебе Castor? Из той же оперы.

Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.

AVK>>>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.
ГВ>>Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type.
AVK>А в шарпе в safe коде от указателей избавились. Отсуда и отличия. Зато у С++ есть примитивы, а есть классы/структуры. А в шарпе и примитивы это тоже структуры.

Как подкласс value-type-ов. До чего только оптимизация не доводит.

Оно намного более корректно, чем "Web-приложение". Есть приложение и есть Web- или Windows- или VGA- или TTY-интерфейсы пользователя к нему. А также — Web (Http), или TCP/IP, или ещё какая-то коммуникационная среда. Таким образом, термин "Web-приложение" означает приложение с Web-интерфейсом пользователя (читай — xxx Markup Language) и поддерживающее http-протокол взаимодействия с пользователем же.
AVK>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.

А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).

ГВ>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)
AVK>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.

Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.

Кратко обосную свой взгляд.

Логика взаимодействия человека с машиной в человеко-машинной системе не менялась со времён кнопок и лампочек и не поменяется, ИМХО, ещё столько же. Машина (более узко — прикладная логика приложения) даёт пользователю сигналы и предоставляет органы управления, с помощью которых можно ограниченно (fool-protection) изменяють её параметры. Бесспорно, что внутренняя структура и логика интерфейсной системы самой по себе отличается от структуры управляемой через неё системы. Равно как и внутренние логики разных интерфейсных систем тоже отличаются одна от другой. Как, например, отличается организация Web-интерфейса самого по себе от Windows-интерфейса самого по себе. Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными. А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен. Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.

Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.

ГВ>> А место C++ здесь — очень даже на стороне приложения. Ну не виноват я, что принято реализовывать прикладную логику на интерфейсных и скриптовых языках. Не виноват!

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.
AVK>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.

Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту. Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

AVK>>>Ну тогда все точные науки математикой обозвать можно.
ГВ>>Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.
AVK>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

Конечно, не должна определять "всё остальное", но компьютеры-то — строго детерминированные системы. Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".

AVK>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

AVK>Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

Ну, на сегодняшний день, время потраченное на изучение C++ окупается многократно. Хотя бы потому, что как Java, так и C# — прямые его наследники по многим показателям.

А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

AVK>>>А еще с файлами, БД, и т.д.
ГВ>>Суть — внешние средства.
AVK>Тока эти внешние средства есть во всех приложениях.

Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.

AVK>>>Тока эту функцию в зависимости от платформы вызывать надо.
ГВ>>Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.
AVK>При чем тут оптимизация? На платформе А порядок следования байтов один, на платформе В другой. Если ты пишешь код для обоих платформ тебе придется учитывать это.

"Оптимизация" в данном случае означет исключение операции перестановки байтов, если это не нужно на конкретной платформе. Согласен, что я опять неудачный термин выбрал. Тем не менее, в процессе работы определить характер платформы и поставить соответствующий флажок, на основании которого выполнять или не выполнять конвертацию, — не составляет никакого особенного труда.

AVK>>>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.
ГВ>>Для отчётов генератор делали или готовым пользовались, коль не секрет?
AVK>Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.

С промежуточным форматом хранения в XML -хорошая идея, одобрямс.

ГВ>Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

А чего зря воздух сотрясать?

Все равно все останутся при своем мнении. А "мои знакомые" — это абсолютно нерепрезентативная выборка.

Здравствуйте Igor Trofimov, Вы писали:

ГВ>>Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

Не верю. Хотя, в принципе, возможно, если они тоже занимаются программированием только ради концепции.

IT>А чего зря воздух сотрясать?

Все равно все останутся при своем мнении. А "мои знакомые" — это абсолютно нерепрезентативная выборка.

Здравствуйте Геннадий Васильев, Вы писали:

AVK>>Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

ГВ>А почему ты занимался джавой?
Как ты интересно разговор в сторону уводишь. В данном случае не я выбирал средство разработки.

ГВ> Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.
Ну во первых TP 5.5 был первым объектным вариантом паскаля, первый рабочий был 7.0. Во вторых то что ты не умеешь проектировать без множественного наследования еще не означает что без него жить нельзя. Я писал и на паскале, и на джаве, теперь вот на дотнете. И как ни странно от отсутствия множественного наследования не страдаю. Шаблоны действительно иногда позволяют повысить эффективность выполнения, но вот множественное наследование бывает полезным в очень небольшом количестве случаев, жа и те по большей части ограничиваются множественным наследованием интерфейсов, которое и в джаве и в дотнете есть.
А вобще забавно — по TP 5.5 судить о джаве и дотнете

ГВ>Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.
Глупая причина надо сказать.

ГВ>Как подкласс value-type-ов. До чего только оптимизация не доводит.

Да, наворочено до небес. Это интересно выглядит с позиций C++ — программирования, где, как я помню, всё-таки стремятся унифицировать концепции, сведя всё к классам. Это, кстати, и в мануалах по C++ было: "в C++ все типы — классы".
Ага, int в С++ тоже класс?

ГВ> С этой позиции Java гораздо лучше C# (концептуально), хотя и хуже, чем C++ (как концептуально, так и по быстродействию).
Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы. В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.

ГВ>По сути, проблемы, связанные с GC и его влиянием на проектирование никуда не делись. Только теперь придётся думать ещё и о том, где вводить value-, а где class-type.
Проблем GC решает куда больше.

ГВ>Обрати внимание, что от структур на C++ очень даже можно унаследоваться, чего нельзя сделать от C#-структур.
ГВ> Они — sealed по определению.
Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.

AVK>>Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>В смысле — как ипостаси value-type? Ну да, согласен. ИМХО, концептуально — кошмар, поскольку вместо разделения "элементарный тип/класс" (C++)
Ты сам себе противоречишь — то у тебя главный недостаток шарпа в том что у него типы не унифицированны, то главный недостаток что они унифицированны. Помоему ты уже споришь ради спора, поскольку вместо аргументов в ход пошла софистика.

ГВ>вводится дополнительная градация: "элементарный тип/структура/класс". Собственно говоря, именно это я и имел ввиду.
Во первых не там никакой градации. Любые данные я могу привести к object. А потом — ты скромно умалчиваешь что в С++ есть указатели на экземпляры, а есть экземпляры классов. Те же яйца вид в профиль.

AVK>>То что? У самого загруженного сервера нагрузка все равно неравномерна.
ГВ>Да, только ему наверняка потребуется мусор выбрасывать именно в моменты пиковой нагрузки. Это просто из логики функционирования GC следует.
Ну ты понимаешь что люди тестировали, и даже при стрессовых нагрузках GC оказывался быстрее сишного хипа. Единственный недостаток GC — непрогнозируемость задержек. Поэтому ни джава ни дотнет не могут применяться в рилтайм системах.

AVK>>Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.
ГВ>Ты имеешь ввиду описанную тобой ERP или что-то ещё?
Это не я описывал.

ГВ> Вроде бы, asp.net мы вообще не упоминали. Или ты его в качестве примера привёл?
В качестве примера.

AVK>>Это все общие слова. Ты мне объясни как ты собираешься заменять висящие в памяти классы.
ГВ>Ты имеешь ввиду классы или экземпляры объектов?
И классы и экземпляры.

ГВ> Если классы, то они автоматически удалятся при выгрузке библиотеки, а если объекты, то они будут удалены перед выгрузкой или во время уничтожения статических данных модуля. Это уже детали проектирования в конкретном контексте конкретного App-сервера.
А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

AVK>>Вагон слов и ничего конкретного.
ГВ>Я тебе описал самые общие моменты, как ты и просил. Конкретизируй вопрос. ИМХО, на общий вопрос — общий ответ.
Куда уж конкретнее — как в сях на лету подгрузить класс.

AVK>>Сервисы ты эти как реализовывать будешь?
ГВ>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
Опять общие слова. Это все можно сказать про любое средство разработки.

AVK>>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.
ГВ>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная?
Вот сразу видно что ты никогда не писал эти самые работающие в глобальной сети. Разница есть — в величине и предсказуемости задержек, вероятности обрыва, толшине канала и т.д. Вот в обратную сторону пожалуйста — из глобальной сети в локальную.

ГВ>Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
Все это ты красиво говоришь, только при чем тут С++. И что из тобой перечисленного нельзя реализовать на джаве, дотнете?

AVK>>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.
ГВ>Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.
С точки зрения приложения логика совершенно иная.

ГВ>Кратко обосную свой взгляд.

ГВ> Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными.
ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.

ГВ> А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен.
Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.

ГВ>Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.
Ну да, во всех бедах виноваты маркетологи. Это как в старом анекдоте — если ты такой умный, то почему ж не богатый?

ГВ>Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.
А при чем здесь средства разработки. Ты не уходи от темы.

AVK>>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.
ГВ>Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту.
Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.

ГВ> Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.

AVK>>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

ГВ>Конечно, не должна определять "всё остальное", но компьютеры-то — строго детерминированные системы.
Компьютер это не сферический конь в вакууме. Программы пишуться не ради программ а ради реального мира. И нет там никакой детерминированности. А еще есть такой раздел прикладной науки как надежность вычисления. Так вот, там априори считается что комп подвержен случайным ошибкам.

ГВ> Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".
Есть такая наука — системотехника. Так вот — во всех учебниках там ясно написано — аналитическая модель сложных систем на данном уровне развития науки невозможна. Получается описать аналитически только очень простые системы. Вот такие вот пирожки.

AVK>>Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

ГВ>Ну, на сегодняшний день, время потраченное на изучение C++ окупается многократно. Хотя бы потому, что как Java, так и C# — прямые его наследники по многим показателям.
Шарп и джава похожи на С++ в основном внешне. Как ни странно но у дотнета и дельфи больше сходств чем у дотнета и С++.

ГВ>А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.
Я тебе отвечу твоими же словами — не умеют строить абстракции. Да и потом — непонятно когда они только успели пописать, поплеваться и вернуться обратно. Релиз только в феврале вышел. Просто видимо они писали 2 дня, не разобрались и вернулись на старое. Вон Влад тоже первое время говорил что дотнет это по большей части фигня полная. Однако у него хватило ума не бросать а разобраться.

AVK>>Тока эти внешние средства есть во всех приложениях.
ГВ>Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.
Меняет это одно — переносимые программы на С++ писать тяжело.

ГВ>"Оптимизация" в данном случае означет исключение операции перестановки байтов, если это не нужно на конкретной платформе. Согласен, что я опять неудачный термин выбрал. Тем не менее, в процессе работы определить характер платформы и поставить соответствующий флажок, на основании которого выполнять или не выполнять конвертацию, — не составляет никакого особенного труда.
Вот из таких операций и складываются горы. Вон американы на марсе аппарат потеряли из-за того что футы и метры попутали. А уж там наверное софт тестировался дай боже.

AVK>>Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.
ГВ>

С промежуточным форматом хранения в XML -хорошая идея, одобрямс.

А каковой она была 4 года назад, когда это все задумывалось! Я ж говорю, заказчики, когда первую рабочую версию репортера увидели прям паром в потолок били

(у них до этого была системка на дельфи 1 писанная еще под вин 3.1 с родным дельфевым quick report по моему).

<<... J 1.0 alpha 4 >>

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	02.09.02 18:03
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	02.09.02 18:56
Оценка:

	От:	Mink
	Дата:	03.09.02 11:23
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	03.09.02 13:56
Оценка:	20 (2)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	03.09.02 16:35
Оценка:

От:	Batiskaf	http://www.mult.ru/
Дата:	04.09.02 16:38
Оценка:	80 (10)

От:	VladD2	www.nemerle.org
Дата:	08.09.02 22:44
Оценка:

	От:	IPv6
	Дата:	09.09.02 07:13
	Оценка: