AVK>Забавный ты человек. Тебе говорят, что C# это совсем не C++, что окромя синтаксиса, между ними мало общего. Ты не веришь, набиваешь себе шишки, но при этом продолжаешь гнуть старое.
Забавные вы все люди. Почему-то решили, что C# это принципиально новое, по сравнению с C++. Как же при этом можно писать программы на принципиально новом C# и сопрягать их с совсем не новыми C++ и VB, пусть даже и managed ? Не преувеличивайте хоть, а то можно подумать, что если ввели некоторое изменение, то уж и впрямь нечто такое получилось, чему и аналогов-то нет.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>В современных условиях прорыв такого типа представляется маловероятным, т.к. "железо больше не ресурс": для новых языков программирования вопрос зверской эффективности уже не является определяющим фактом популярности. (В связи с этим фактом интересен "пролет" функциональных языков: когда "железо еще было ресурсом", они заработали ту самую стойкую репутацию "академических поделок", а сегодня — это уже слишком старые идеи, чтобы кого-то увлечь; то же со Smalltalk.)
Давайте не будем о пролетах. Уже Микрософт вставляет в свое детище поддержку функционального стиля (слишком старых идей!), а некоторые все еще твердят о пролетах. Вы, извините, еще и о половине этих старых идей не знаете, а уже готовы списать все в помойку. Не вижу смысла ориентироваться на кул хацкеров, жаждущих невиданных прорывов и неведомых новых идей. Как правильно сказал, Грехем, если ходите узнать, что будет в будущем, зайдите на факультет университета, там работают над этим будущим.
Здравствуйте, minorlogic, Вы писали:
M>Да , WSDL это именно шаг в сторону которую я описывал , но современные языки зная WSDL описанеи , не построят связей между компонентами. Это описание скорее для юзера , кторы йбудет потом работать с классом сгенерированным WSDL.
M>Я же говорю про описание компонента , которое сможет ПОНИМАТЬ ( оперировать) сам язык или его управляющая оболочка.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Как следует из опыта, поддержка корпорацией вовсе не означает, что язык не умрет. Свежий пример -- VB, имевший большую базу пользователей, и убитый большой корпорацией. GZ>Ну во первых он не умер, а развился в VB.NET. <...>
Прошу прощения, а разве "развился" не понимает по собой хоть какой-то обратной совместимости?
Что общего у VB6 и VB.NET? Синтаксис?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали:
iZEN>>a) сильная инкапсуляция; iZEN>>б) смешивание (mixins); VD>Класс! Постановка в один список базовых свойств и частных фич! Отпадная логика!
А почему, собственно, mixins нельзя сделать "базовой фичей"?
iZEN>>2) Независимым от платформы — компиляция в промежуточный код. iZEN>>3) Иметь простую виртуальную машину для выполнения кода (грубо: модель процессора со стэковой архитектурой). VD>А почему не сложную (грубо: на базе комбинаторной логики и каких-нить сверток графов)?
А вот это уже вопрос портабельности такой машины на многие платформы начиная от коммуникаторов и заканчивая кластерами сервером. В принципе, чем проще машина, тем легче сделать её одинаковой для разных устройств.
VD>Зачем вообще привязывать свое видение реализации к анализу требований?
Так просто.
iZEN>>4) И самое главное, чтобы исходники программы на этом языке легко читались ЧЕЛОВЕКОМ. iZEN>>И тогда создание поистине всемирных библиотек кода на этом языке можно сделать по принципу Wikipedia. И Сеть будет Компьютером. VD>+1 VD>Вот это красивая мечта.
Ага.
iZEN>>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает. VD>Все уже поняли, что ты ратушь за миксины. Но не нужно делать это навязчивой идеей.
Уточню: миксины против наследования. Это имеет смысл.
Компонентное программирование — это частный случай "смешивания кода", когда компонент представлен из нескольких объектов, работающих в агрегате (компоненте).
VD>К тому же есть более общие навязчивые идеи. Например, идея расширяемых языков и метапрограммирования позволит сделать и миксины, и foreach, и черта лысого. И все это без изменения самого языка!
Язык Forth не "пошёл" в массы из-за своего идиотского синтаксиса (обратная польская нотация).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, iZEN, Вы писали:
GZ>Ну раз уж так, и я скажу. GZ>1) Должен быть компонентным. Надеюсь компонент не надо сравнивать с классом?
Ага. Компонент — это агрегат объектов. GZ>2) Должно быть наследование классов. Если нет наследования, то общественность это не поймет. Даже не рассуждая наследование плохо или хорошо, общественное мнение главнее.
Наследование в небольших проектах (например, приложения для сотовых телефонов) имеет громадный оверхед, поэтому от него отказываются, заменяя красивую пирамидальную иерархию на "плато" из десятка объектов с кучей методов. GZ>3) Должен поддерживать все основные фичи процесса построения приложений. То есть, как минимум обладать большинством фич UML. И не противоречить ему.(RUP-подобные постановки еще главенствуют и я думаю будут продолжать главенствовать).
без комментариев (я не знаю, что сказать) GZ>4) Должен быть поддержан большой корпорацией. Пользователи языка должны быть уверены, что язык не умрет и не будет оставаться академическим опытом. И корпорация должна отвечать за качество реализации компилятора(что очень немаловажно).
Необязательно.
Необходимо и Достаточно оформившееся комьюнити (пример: Java Community Process, корпоративное Symbian Community, в крайнем случае стихийное комьюнити вокруг Linux, FreeBSD и т.д.). GZ>5) Должно быть достаточно большое количество библиотек. Это можно даже сказать правило определяющее. При выборе языка, нужно быть уверенным что можно найти библиотеку на все случаи жизни.
Переписать Java API и этого будет достаточно! ж)) GZ>Все остальное, типа mixin и т.д. — всего лишь конфетки, которые скрашивают нашу жизнь, но не определяют общую линию партии. В общем, бизнес — есть бизнес.
Линия партии? А что это такое? iZEN>>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает. GZ>Ты просто неумеешь их готовить. Наследование опасно в неумелых руках, но в умелых оно спасает до 70 процентов ООП проекта(оценка из башки, но можно и померить). Ничего лучше чем функциональная декомпозиция, человечество в ООП не придумало. Другой вопрос, что при этом человечество забывает принципы Барбары Лисков, и забывают инкапсуляцию классов в наследовании друг от друга. А ведь все для этого в современных языках есть. private, protected — вполне достаточные инструменты чтобы это обеспечить.
Умею, не беспокойтесь. Но что-то в последних проектах на J2ME мне противно отказываться от глубокой иерархии в пользу непорядочного "плоского" кода. Но выбора нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Забавные вы все люди. Почему-то решили, что C# это принципиально новое, по сравнению с C++.
Не новое, а другое. Не переиначивай мои слова.
PD> Как же при этом можно писать программы на принципиально новом C# и сопрягать их с совсем не новыми C++ и VB, пусть даже и managed ?
Как обычно, при помощи головы.
PD> Не преувеличивайте хоть, а то можно подумать, что если ввели некоторое изменение, то уж и впрямь нечто такое получилось, чему и аналогов-то нет.
Здравствуйте, Пацак, Вы писали:
AVK>>Лямбда-функции? Так они и в Питоне тож есть. П>В питоне лямбды несколько "недоделанные" — в них можно только простейшие действия выполнять. То есть, например П> b = lambda x: if x>0 : x*x П>SyntaxError: invalid syntax П>уже нельзя.
В твоем случае надо просто использовать локальные функции вместо слова lambda. Лямбда недоделанная из-за питоновского синтаксиса (стейтменты должны быть на новых строчках с соблюдением отступов), а не из-за лени разработчиков. В твоём случае надо было писать примерно так:
Т.е. условные операторы в выражениях (как ?: в С++) надо делать из and/or, но читабельность получается нулевая
В лямбда-функциях куда важен механизм лексических замыканий, чем синтаксис, возволяющий использовать тело функции как выражение, или объявить локальную функцию, или что угодно ещё.
Вот например, если бы они были в С++ и реализовывались так:
void foo(void (*fn)())
{
fn();
}
void (*)() bar(string word)
{
struct A {
static void baz() {
cout << "Me a de " << word << " nuttah" << endl;
}
};
return &A::baz;
}
int main()
{
foo(bar("original")); // выводит Me a de original nuttah
foo(bar("mad")); // выводит Me a de mad nuttah
}
...то фактически язык бы имел всю мощь лямбды из Лиспа и др. Синтаксис не ахти, но это не настолько важно.
С другой стороны, возможность написать foo( void lambda() { std::cout << "Koukou"; } ) ничего радикально в языке не поменяет.
В Питоне лексические замыкания есть, вот этот код работает верно:
def foo(f):
f()
def bar(w):
def l():
print "Me a de", w, "nuttah"
return l
foo(bar("original"))
foo(bar("mad"))
Поэтому "следующий язык" должен в первую очередь содержать лексические замыкания, и на втором месте — синтаксический сахар для объявления мелких локальных функций и лямбд
Здравствуйте, eao197, Вы писали:
E>Нет, лямбда по сравнению с Ruby блоками гораздо слабее, как мне показалось при поверхносном знакомстве с Python.
Я так понял это принципиальная позиция создателя python — лямбда служит только для вычисления коротких выражений. С другой стороны может оно и правильно — меньше потенциальных ошибок. А с третьей стороны никто не запрещает делать, например так:
Здравствуйте, AndrewVK, Вы писали:
AVK>Не новое, а другое. Не переиначивай мои слова.
Другое — согласен. Но прочти еще раз мой ответ Зверьку. Я же там ясно писал
> в некотором смысле Java и C# не есть нечто совершенно новое по сравнению с Фортраном.
Понимаешь — в некотором смысле. Наверное, я все же в состоянии отличать Java от Фортрана . Но и тот, и другой, и C# и C++ — это языки одного в общем-то направления. Вот Лисп или Пролог — действительно иное. И если бы их не было на данный момент, а потом они появились — я бы первым сказал — новое слово. А тут — не скажу. Потому что C# есть просто некоторая модификация Java, а Java — некоторая модификация C++, и в обоих случаях никаких особо новых идей не появилось. Считать такой идеей управляемый код я никак не могу, тем более что он уживается с совсем не новыми Basic и C++.
Не согласен ? OK, тогда ставлю вопрос прямо
Какие новые идеи появились с C#, которых нет ни в C++, ни в Object Pascal etc. Подчеркиваю — идеи, а не реализация и синтаксис.
Кстати, перечитай еще раз исходное письмо Зверька, там достаточно ограничено поле обсуждения.
AVK>Ну тогда продолжай набивать шишки.
Ну в этом форуме шишки набить сложно. . Слава богу, сейчас не совестские времена, за неправильную философию не наказывают
Здравствуйте, Пацак, Вы писали:
E>>Ну и может быть кто-то из знающих Python товарищей скажет, как в Python сделать такую конструкцию:
П>А можно чуть поподробнее? А то не зная рубийного синтаксиса трудно понять, даже с теми комментариями, что ниже.
Хмм... Попробую.
Есть класс Target, в объектах которого нужно хранить имена C++ файлов. Имя каждого C++ файла должно включать и путь к файлу. Поскольку часто группа файлов располагается в одном каталоге, то не хотелось бы задавать для каждого из них путь явно. Поэтому класс Target содержит строку с текущим значением пути к C++ файлам. Когда вызывается метод cpp_source для добавления очередного файла класс Target просто объединяет текущее значение пути с заданным именем. Для того, чтобы изменять значения текущего пути в Target есть метод sources_root.
Пусть есть подкаталог impl с файлами a.cpp и b.cpp. В нем так же есть подкаталоги win32 (с файлом c.cpp) и posix (с файлом d.cpp). Если не использовать блоки кода, то перечисление этих файлов объекту Target могло бы выглядеть так:
t = Target.new
# Устанавливаем новый текущий путь и сохраняем предыдущий чтобы восстановить его позже.
pre_impl = t.sources_root( t.current_sources_root() + "/impl" )
# Теперь имена C++ файлов будут относительно impl.
t.cpp_source( "a.cpp" )
t.cpp_source( "b.cpp" )
# Ныряем вглубь impl/win32.
pre_win32 = t.sources_root( t.current_sources_root() + "/win32" )
t.cpp_source( "c.cpp" )
# И выходим из него.
t.sources_root( pre_win32 )
# Ныряем вглубь impl/posix.
pre_posix = t.sources_root( t.current_sources_root() + "/posix" )
t.cpp_source( "d.cpp" )
# И выходим из него.
t.sources_root( pre_posix )
# Выходим из impl.
t.sources_root( pre_impl )
А теперь то же самое с блоками:
t = Target.new { # Вот это начало блока.
# Все последующие вызовы неявно выполняются для экземпляра t.
# За вызовом sources_root скрыто:
# pre = t.current_sources_root() + "/impl".
# Затем вызов блока, код которого выполняется для объекта t.
# t.sources_root( pre ).
sources_root( "impl" ) {
# t.cpp_source...
cpp_source( "a.cpp" )
# t.cpp_source...
cpp_source( "b.cpp" )
# Дальше то же самое.
}
}
А вот, собственно, сам код метода sources_root из Mxx_ru:
# Сменить путь, относительно которого задаются имена
# исходных файлов. Если установить пустую строку,
# то нужно будет задавать полные имена файлов.
# Если задан блок, то путь меняется на новый, блок выполняется,
# после чего старое значение пути восстанавливается.
#
# Возвращает предыдущее значение mxx_sources_root. Актуально
# для случая, когда метод вызывается без параметра-блока.
def sources_root( a_root )
old_root = @mxx_sources_root.clone
if block_given?
@mxx_sources_root = File.join( [ @mxx_sources_root, a_root ] )
yield
@mxx_sources_root = old_root
else
@mxx_sources_root = a_root
end
return old_root
end
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Понимаешь — в некотором смысле. Наверное, я все же в состоянии отличать Java от Фортрана . Но и тот, и другой, и C# и C++ — это языки одного в общем-то направления.
Базовые парадигмы одинаковы (конечно, оба в большей степени императивны). Но идеология отличается очень сильно. Твои вопросы в дотнетном форуме говорят о том, что ты этого не понимаешь. И когда тебе народ пытается объяснить, к примеру, что работать с памятью в дотнете не надо, ты, вместо того чтобы вопользоваться советом, начинаешь спорить. Хотя, очевидно, опыта в этой области у тебя немного. Вот это и удивляет.
PD>и в обоих случаях никаких особо новых идей не появилось.
Появились. Просто ты их не видишь (не желаешь видеть?).
PD> Считать такой идеей управляемый код я никак не могу,
Вот в этом и проблема. С верой спорить бессмысленно.
PD>Какие новые идеи появились с C#, которых нет ни в C++, ни в Object Pascal etc.
Что такое etc? Под это можно подвести массу языков. Если же ограничится С++ и Delphi, то пожалуйста:
Интерфейсы как сущность языка, GC, управляемый верифицируемый код, CAS (Code Access Security), yield, анонимные методы (они же лямбда функции), Reflection, Reflection.Emit, атрибуты, TransparentProxy и еще много чего еще. Игнорировать это конечно можно, но об эффективном программировании придется забыть.
AVK>>Ну тогда продолжай набивать шишки.
PD>Ну в этом форуме шишки набить сложно. . Слава богу, сейчас не совестские времена, за неправильную философию не наказывают
При чем тут форум? Шишки ты набиваешь при программировании под .NET.
Здравствуйте, Quintanar, Вы писали:
Q>...Как правильно сказал, Грехем, если ходите узнать, что будет в будущем, зайдите на факультет университета, там работают над этим будущим.
Здравствуйте, Pavel Dvorkin, Вы писали:
ЗХ>>1. вообще говоря, ни тот ни другой язык не были "совершенно новыми": и до Фортрана были попытки создать язык высокого уровня; и до С++ существовали объектно-ориентированные языки.
PD>Зверёк, а не стоит ли попытаться определить, что такое "совершенно новые".
В исходном сообщении была ссылка. Там написано.
ЗХ>>- до Фортрана считалось... PD>Ну не знаю. ИМХО основной задачей при создании Фортрана... ЗХ>>- до С++ считалось, что ОО языки... PD>Опять-таки не уверен. По-моему, основной задачей было...
Павел, я сейчас обложен несколькими десятками полновесных книжек по истории компьютерных наук и гигабайтами электронных документов. Я могу привести развернутые цитаты в подтверждение своих слов, но может быть, Вы поверите мне на слово?
ЗХ>>В современных условиях прорыв такого типа представляется маловероятным, т.к. "железо больше не ресурс": для новых языков программирования вопрос зверской эффективности уже не является определяющим фактом популярности.
PD>На эту тему я как-нибудь поподробнее выскажусь. Мне этот тезис не кажется верным.
Ждем
>>Тут нужно заметить, что и для С++ важным фактором была совместимость с С (что некоторые и полагают главной ошибкой ), но чем дальше, тем сложнее языки; попытка сделать язык с одной стороны совершенно новый, с другой стороны совместимый со "старым", столкнется со слишком большими идеологическими ограничениями, накладываемыми "старым". (Отсюда можно сделать вывод, что новые парадигмы могут стать не развитиемм старых, а "уходом в другую сторону").
PD>Нет, не согласен. C#, что бы там его адепты не говорили, есть несколько модифицированный C++. И именно поэтому у меня возникли проблемы с перенесением привычных понятий в Шарп.
Гхм. У C# совсем другая идеология. Ваабсче. Поэтому, несмотря на некоторое мое неприятие, я не могу не признать, что шарп — это не "модифицированный С++" и не "правильно сделанная Java", а другой, новый язык.
Отсюда, кстати, и проблемы при переходе на шарп плюсистов — там не "нельзя это сделать". Там "это делается по-другому".
PD>А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.
AVK>Базовые парадигмы одинаковы (конечно, оба в большей степени императивны).
Вот об этом я и говорю, а ты меня понять не хочешь. Мы же немного в другом форуме, и мой ответ Зверьку — отнюдь не продолжение дискуссий в форуме по .Net. В том. что в .Net есть отличия от того, что было раньше — не спорю. Но назвать эти отличия новыми в том плане, как об этом писал Зверек — ИМХО это уж слишком.
>Но идеология отличается очень сильно. Твои вопросы в дотнетном форуме говорят о том, что ты этого не понимаешь.
Да понимаю я вас всех прекрасно. Вам создали специальные правила, мне они не по душе, я в них вижу больше оверхеда, чем пользы, вот и пытаюсь понять, как в этой среде писать эффективную программу, а мне в ответ тыкают, что я , дескать, идеи не понимаю.
>И когда тебе народ пытается объяснить, к примеру, что работать с памятью в дотнете не надо, ты, вместо того чтобы вопользоваться советом, начинаешь спорить.
Andrew, хватит. Я эту парадигму прекрасно понимал еще тогда, когда вопросы свои задавал. И готов не спорить. Но только до тех пор, пока эти рамки меня серьезно ограничивать не станут. А начнут ограничивать (по эффективности, к примеру) — пошлю я все эти рамки куда подальше, и буду делать так, как мне хочется, под свою ответственность. Вот меня и интересовало — есть ли способ эти рамки послать ? На случай, если придется. А похоже, придется, так как заказчик грозит C# и не уверен, что я смогу его от этого отговорить, а в программе нужно все эффективно делать и минуту + 57 Мбайт тратить на чтение каталога я не могу. Вот и все.
>Хотя, очевидно, опыта в этой области у тебя немного. Вот это и удивляет.
Вот именно. Мне поэтому и надо знать, как на этом самом .Net написать все с нужной мне эффективностью.
Хочешь аналогию ? Для паскальщика или с-шника в языке средств всяких сколько угодно на всякие действия. А мне надо понять, как в Паскале или С ассемблерную вставку сделать — для максимальной эффективности. Я об этом и спрашиваю. А мне в ответ — а зачем тебе команда mov, когда в языке есть замечательный оператор присваивания!
PD>> Считать такой идеей управляемый код я никак не могу,
AVK>Вот в этом и проблема. С верой спорить бессмысленно.
Ну уж верой это не назвать. Я вообще-то Фома неверующий . Просто уж слишком серьезное заявление для такого нововведения.
AVK>Что такое etc? Под это можно подвести массу языков. Если же ограничится С++ и Delphi, то пожалуйста: AVK>Интерфейсы как сущность языка
Появились в Java.
>, GC,
Под другим названием — тоже в Java.
>управляемый верифицируемый код, CAS (Code Access Security)
Да, не помню, кажется я этого не видел раньше. Но это все на одну тему — защита. А то, что защиту я не считаю особо серьезным нововведением — я уже сказал.
> yield, анонимные методы (они же лямбда функции)
Ну тогда надо признать, что появление template в C++ — тоже радикальное нововведение.
>Reflection, Reflection.Emit,
Зачатки этого Reflection — RTTI C++, Object Pascal
>атрибуты, TransparentProxy и еще много чего еще.
С этим, увы, не знаком пока что.
>Игнорировать это конечно можно, но об эффективном программировании придется забыть.
Об эффективности программирования я как-нибудь особо напишу, здесь.
AVK>При чем тут форум? Шишки ты набиваешь при программировании под .NET.
О господи! Еще раз объясняю — не собираюсь я набивать шишки. Я вполне могу писать, придерживаясь всех ваших правил, которые для вас, похоже, такая же истина в последней инстанции, как бытие божее для верующего. Меня просто интересует, есть ли способы в нужный момент эти правила обойти, приняв ответственность на себя. Не волнуйся — никаких шишек при этом не будет. В конце концов, не скажешь же ты что я некорректно делаю, если интерфейс пользователя я вынесу в C#, а для математики напишу обыкновенную DLL на C++ и там буду делать как всегда делал ?
Здравствуйте, Зверёк Харьковский, Вы писали:
PD>>Зверёк, а не стоит ли попытаться определить, что такое "совершенно новые".
ЗХ>В исходном сообщении была ссылка. Там написано.
Увы, у меня The page cannot be displayed. Можешь процитировать или прислать на e-mail ?
ЗХ>Павел, я сейчас обложен несколькими десятками полновесных книжек по истории компьютерных наук и гигабайтами электронных документов. Я могу привести развернутые цитаты в подтверждение своих слов, но может быть, Вы поверите мне на слово?
Вполне готов поверить. Это все было ИМХО.
ЗХ>Гхм. У C# совсем другая идеология. Ваабсче. Поэтому, несмотря на некоторое мое неприятие, я не могу не признать, что шарп — это не "модифицированный С++" и не "правильно сделанная Java", а другой, новый язык.
Ну что же, Ваше право так считать.
PD>>А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.
ЗХ>Взгляните все же на руби и питон
Здравствуйте, Пацак, Вы писали:
П>Думаю минус даже не в этом. Насколько мне помнится, пролог решал задачи по принципу "все или ничего", т.е. ему нельзя было сказать: "вот тебе цель, выполни ее, а если не получится — то сделай хотя бы вот это, а если и оно не выйдет — то попробуй хотя бы вон то и вон то". Т.е. нельзя было задать этакую "деградирующую" иерархию целей и заставить язык проанализировать, что из этой иерархии не работает и как ее надо исправить, чтоб заработало. Можно было, правда, написать кучу целей вручную и "пробежаться" по ним, отыскивая слабое звено, но это ИМХО совсем не то.
Странно, я в отсечении (!) вижу инструмент именно такой постановки задач.
GlebZ,
> ПК> Как следует из опыта, поддержка корпорацией вовсе не означает, что язык не умрет. Свежий пример -- VB, имевший большую базу пользователей, и убитый большой корпорацией.
> Ну во первых он не умер, а развился в VB.NET.
Это и называется умер. Можешь спросить у тех, кто писал на VB, и теперь не может скомпилировать свои продукты новой студией, и не может использовать идиомы из VB в VB.Net.
> В данном случае больше подходит аналогия с MC++.
В чем аналогия? MC++ тоже умер: C++/CLI развитием MC++ тоже не является, хотя при его создании и использовался опыт, полученный в результате MC++.
>>> Наследование опасно в неумелых руках, но в умелых оно спасает <...>
> ПК> В умелых его стараются заменять менее сильными связями.
> У меня практически всегда описание предметной области имеет наследование. И что в этом плохого?
Нужно смотреть case by case. Общие отрицательные черты -- слишком сильные связи.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
GlebZ,
> ПК> В умелых его стараются заменять менее сильными связями.
> И вообще, отсутсвие наследования хорошо компенсируется копи-пастным программирование. Это показал VB.
Типичный софизм: если нет наследования, то некоторые заменяют его copy-paste; значит отказ от наследования в ряде случаев приведет к copy-paste.
> Что лучше?
Лучше использовать разнообразные patterns, значительная часть которых направлена на ослабление связей, в т.ч. за счет отказа от наследования.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
