Здравствуйте, alexeiz, Вы писали:
GZ>>>Терминология мне жутко понравилась. Просто и ясно, без синтетического static. Кё>>В С++ дофига таких ляпов То же static в другом контексте означает изменение видимости символа для линкера. A>Это не ляпы, а перегрузка ключевых слов.
Именно ляпы. Равно как и constructor vs. function prototype, невозможность объявить реализацию функции темплейтного класса вне декларации (а инициализировать статический член наоборот, нельзя в декларации) и пр.пр.пр. Надо делать язык простым, логичным и хорошим до конца, а не ссылаться на объективные трудности и тёмное прошлое.
Уж где-где, а в "следующем языке программирования" таких косяков точно не должно быть.
A> Ты знаком с историей C++?
Знаком. Ляп в том, что объявляя реализацию статической функции класса в cpp с ключевым словом static, мы получаем конфуз — что имеется ввиду? Это такой же неочевидный момент, как и f(i++,i++). Опытные программисты его знают и в принципе не имеют проблем (точно так же как опытный водитель запорожца знает, где у его машины предел прочности и как на ней ездить не стоит).
class A {
static void foo();
};
// можете использовать это как очередной
// дурацкий вопрос при приеме на работу С++-программиста :)static void A::foo() {
}
static void bar() {
}
WH>Единственное что пришлось делать руками это писать свою хеш-таблицу на value-типах ибо миллионы мелких объектов для ГЦ тяжеловато темболие если есть value-типы.
Здравствуйте, Serginio1, Вы писали:
WH>>Единственное что пришлось делать руками это писать свою хеш-таблицу на value-типах ибо миллионы мелких объектов для ГЦ тяжеловато темболие если есть value-типы. S> Да и существующая не слишком эффултивна. http://www.rsdn.ru/forum/?mid=437992
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
WH>>>Единственное что пришлось делать руками это писать свою хеш-таблицу на value-типах ибо миллионы мелких объектов для ГЦ тяжеловато темболие если есть value-типы. S>> Да и существующая не слишком эффултивна. http://www.rsdn.ru/forum/?mid=437992
WH>Еслибы не десятки миллионов 8 байтных объектов то я бы взял стандартную.
Наверное лимитирующим здесь является частота обращения к этим десятки миллионам. И общее затрачиваемое время.
Когда 4-8 кратное увеличение скорости начинаетс явно ощущаться
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Наверное лимитирующим здесь является частота обращения к этим десятки миллионам. И общее затрачиваемое время. S> Когда 4-8 кратное увеличение скорости начинаетс явно ощущаться
Нет. Тут выходит на первый план с огромным отрывом менеджер памяти... Согласись что один здоровый массив напрягает ГЦ куда меньше чем десятки миллионов мелких, долгоживущих объектов. Да и оверхед по памяти получается очень не маленький.
Но если нет огромного колличества мелочи то извращаться с рукописными контейнерами нет никакого смысла.
А вобще когда перелопачиваешь многогигабайтные файлы все упирается в винт если конечно сильно не накосячил с реализацией алгоритма.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
S>> Наверное лимитирующим здесь является частота обращения к этим десятки миллионам. И общее затрачиваемое время. S>> Когда 4-8 кратное увеличение скорости начинаетс явно ощущаться WH>Нет. Тут выходит на первый план с огромным отрывом менеджер памяти... Согласись что один здоровый массив напрягает ГЦ куда меньше чем десятки миллионов мелких, долгоживущих объектов. Да и оверхед по памяти получается очень не маленький.
WH>Но если нет огромного колличества мелочи то извращаться с рукописными контейнерами нет никакого смысла.
Все зависит от затрат, если они ничтожны то почему бы и нет ... WH>А вобще когда перелопачиваешь многогигабайтные файлы все упирается в винт если конечно сильно не накосячил с реализацией алгоритма.
Кстати для интереса твой diff на нахождении LCS ???
Как это для бинарников ??? (для строк понятно)
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Кстати для интереса твой diff на нахождении LCS ???
Чего? S> Как это для бинарников ??? (для строк понятно) binary diff
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, alexeiz, Вы писали:
GZ>>>>Терминология мне жутко понравилась. Просто и ясно, без синтетического static. Кё>>>В С++ дофига таких ляпов То же static в другом контексте означает изменение видимости символа для линкера. A>>Это не ляпы, а перегрузка ключевых слов.
Кё>Именно ляпы. Равно как и constructor vs. function prototype, невозможность объявить реализацию функции темплейтного класса вне декларации (а инициализировать статический член наоборот, нельзя в декларации) и пр.пр.пр. Надо делать язык простым, логичным и хорошим до конца, а не ссылаться на объективные трудности и тёмное прошлое.
Blah, blah, blah. Это особенности языка. Ничего больше. "Хороших до конща" языков не существует.
Кё>Уж где-где, а в "следующем языке программирования" таких косяков точно не должно быть.
A>> Ты знаком с историей C++?
Кё>Знаком.
Не похоже.
Перегруженные ключевые слова по определению обозначают разные вещи в разных контекстах. Я не понимаю, ты это дело отрицаешь или игнорируешь?
>Ляп в том, что объявляя реализацию статической функции класса в cpp с ключевым словом static, мы получаем конфуз — что имеется ввиду?
Отнюдь. В этом месте имеется ввиду только одно, что ты хочешь придать функции static linkage. Если тебе кажется, что имеется что-то другое, то ты не читал документации.
>Это такой же неочевидный момент, как и f(i++,i++).
Вырожденный пример без особого смысла.
static — это не ляп и даже не кофуз. Конфуз — это >> в шаблонах. Или вот это (пример с friend operator<<). А static — это детские игры.
Кстати, по той же программе будет перегружено слово auto в ближайшем будущем. Перегрузка в C++ — это нормальное дело. Нельзя назвать ляпом основной принцип дизайна языка.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, VladD2, Вы писали:
ЗХ>>>Ты просил — вероятность принятия индустрией нового языка, за которым не стоят монстры ЗХ>>>Я ответил
VD>>Тут вот иногда народ спрашивает сколько приложений на вашем компьютере менеджед и расстраивается когда народ называет 1-3 приложения. А сколько у тебя приложений на Руби, Питоне или не дай бог на ПХП с Перлом?
VD>>Боюсь столько же скольсо у меня. Максимум где-нить в каталоге скриптик заволялся.
ЗХ>Ну, на Python'e у меня WikidPad,
Это не у тебя. Это где-то на сайте. У нас тоже вики на дотнете, но на десктопе от этого нета больше не становится.
ЗХ>А на перле — несколько сотен одноразовых скриптов, написанных мной самим для повседневных нужд (типа перебрать 1000 файлов в каталоге, извлечь из них ссылки на .gif'ы, сложить в один файл).
Это на клиенте? Или опять на сервере? Опять же эти скрипты не сидят постоянно в памяти. Так что если изучать список загруженных процессов, то скриптов среди них не окажется.
ЗХ>На PHP у меня десятки мелких скриптов на imho.com.ua
Опять же на сервере.
Выводы можно сделать такие же как делаются о дотнете. На клиенте пока что этих языков практически нет. Ну, если ты конечно не линуксоид ставящий на машину все подряд.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, henson, Вы писали:
H>Представляете, я им даже пользуюсь!
И что тогда спрашивашь?
H> Но это ни на шаг не приближает меня к описанию объектной модели.
И в чем проблема?
H> Да чтобы я мог ей еще и поделиться и меня при этом поняли все, а не узкий круг ограниченных людей.
Надо быть реалистом. Тетя Маша с рынка тебя не поймет никогда, а специалист в этой области разберется за пять минут. Лиш бы формат был разумный.
H> Нужен готовый цельный стандарт, а не самодеятельность на заданную тему.
Стандарт? Кому? Ну, даже если и так. Так что же ты тут про отсуствие возможностей то рассуждаешь, а не о необходимости стандартов? Так бы и писал: "Хочу, мол, стандарт на описание ОО-медели в ХМЛ". Никто и слова бы не сказал бы.
H>Где?
На сайте МС.
H> Это пока только проба пера.
Это бэта версия. Рельно работающая.
H> И только под бету системы ожидаемой только через год.
Это ты о чем? Авалон написан под второй фрэймворк и Виндовс. У меня он работает под ХРюшей.
H> И почему это вообще должно быть связано с операционкой?
Ну, как бы без них никуда. Но подозреваю, что ды подразумевашь только Висту, в то время как Авалон доступен для ХРюш и 2003-ей.
H>Если есть объектная модель зачем возня с файлами?
За тем что это удобнее. Правишь ты файлы. И правишь ты не только ОО-модель. Правиль ты и коментарии, и размещение внутри файла. Ну, а главное, если нет проблем, то не нужно пытаться сделать что-то новое. Иначе проблемы обязательно появятся.
H>>>5) Библиотеки функций и алгоритмов в Интернет/Интранет, ставишь в исходном коде ссылку и все, получается как WebService, но на уровне исходных текстов VD>>Это есть начиная с VS 2002. H>Это шутка? Есть вызов WebService'ов, а не вставка кусков кода.
А причем тут куски кода? Ссылки на сборки никто не отменял. Компонентная модель однако.
VD>>Это есть если установить ReSharper или VS2005. H>Угу, только большинство этим не пользуются иначе бы каждая контора не лепила свои правила оформления исходного кода
Ненужно думать про большинство как про стадо баранов. Ну, и даже самый последний баран перейдя на новую версию студии получит в свое распоряжение рефакторинг (конечно если он пишет на Шарпе).
H>Да бросьте Вы, есть решения изначально правильные, а есть по принципу "если очень хочется, то можно".
А есть вечно недовольные окружающим люди. И что им недовай они все ворчат.
H>Видимо Вам существующих инструментов достаточно для разработки, мне нет
Ну, пока что ничего нового не прозвучало. Только стоны.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, VladD2, Вы писали:
H>>>2) XML диалект для унифицированного описания GUI приложения, чтобы отделить интерфейс от логики и исходных текстов приложения H>>>3) Везде перейти от абсолютного позиционирования элементов GUI к относительному VD>>Avalon к твоим услугам. ZEN>Что значит "абсолютное и относительное позиционирование"?
Непонял почему вопрос ко мне. Но думаю, речь идет о HTML like-стиле.
ZEN>И можно ли считать расположение виджетов на форме (в Delphi, к примеру) по принципу выравнивания: "по какому-то краю", "на всю незанятую область" и т.д. — "относительным" позиционированием?
Думаю что на 100% нельзя. Все равно ведь привязка к координатам остается в некоторых местах. Хотя это зависит от интерпретации терминов.
ZEN>Менеджеры (Layouts Managers) проблему разве не решают? Напишите свой!
Еще раз. Адресуй этот вопрос тому кому отвечал я. Что до меня, то я понимаю разницу между HTML-стилем и менеджерами раскладок, но пережил бы и с последним.
ZEN>Что есть "объект" в такой системе? Описание всего класса? А как быть с анонимными классами?
Кому вопрос задашь? Ты форум в плоскую читашь, что ли?
Если речь о том как бы я бы это делал, то отвечу... через AST. Хранение версий исходников действительно можно производить на уровне AST. Но особого смысла в этом не вижу. Текстовые системы хранения версий меня полностью удовлетворяют.
ZEN>В Java есть переменная среды CODEBASE, которая может указывать куда угодно даже во время написания кода. ZEN>Это ОНО?
Чесно говоря завязку на переменные окружения считают не очень удобной... Да и говорил я о другом. Говорил я о ссылках на другие сборки в проектах.
VD>>Это есть если установить ReSharper или VS2005. ZEN>Зачем такие сложности?
А в чем собственно сложности?
ZEN>В независимых (от операционной системы) средах программирования (NetBeans, IDEA, Eclipse и др.) это давно и успешно работает, достаточно нажать определённую комбинацию клавиш, заведующую форматированием кода.
Из всего перечисленного IDEA конечно продукт отличный. Но это для Явы, а для дотнета те же возможности предоставляют VS2003 + ReSharper или VS2005. Собственно все продукты платные, так что я не вижу предмета для споров. Сложностей с ними тоже никаких нет. В общем, тебе нужно боросться со своими предрассудками.
ZEN>Странно, что большое число компаний устанавливают какие-то внутренние "стандарты" оформления кода, когда проблема-то решается на местах "горячей клавишей" в среде того человека, кто этот код читает.
Еще одна алогичность. Стандарты нужны для того чтобы код выглядел одинаково. IDE всего лишь позволяют автоматизировать соблюдения эти соглашения. Переформатирование всего кода проекта (особенно если он огромный) приведет к необходимости сболее сложного сравнения версий и скорее всего заливки в систему контроля версий всего содержимого проекта. К тому же это еще и время занимает. Ну, и код приходится смотреть не только из IDE. В том же сорсконтроле, например.
ZEN>Проблема надуманна и раздута.
Я не знаю, что там у тебя придумано.
VD>>Ты спал что ли последние 5 лет? ZEN>(Вопрос, конечно, не ко мне, но откомментирую) ZEN>Почему именно 5?
Потому-что 5 лет назад большинство из перечисленного действительно было проблемой.
ZEN> XML, XSLT, продвинутые среды программирования и т.д. появились гораздо раньше VS.
Залесь за w3c погляди когда был принят стандарт на XSLT.
ZEN> И не стоит ограничивать кругозор только этой (далеко не самой лучшей) средой.
Какой? Ты о студии? Каждый выбирает для него то что ему удобнее. Я например, не понимаю зачем себя ограничивать далего не самым лучшим языком — Явой. Но развивать эту тему не имею желания, так как "каждому свое".
ZEN>А henson, по-моему наблюдению, занимается этими фишками достаточное продолжительное время.
И к данному моменту задается вышеприведенными вопросами? Хм... странно он занимается этими вопросами.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alxndr, Вы писали:
A>Именно. Что и означает потерю обратной совместимости.
Дык тогда С++ вообще ни с чем не совместим. Все используют разные библиотеки. Просто раньше ВБ был один с единой библиотекой и о совместимости говорить не приходилось. А теперь бибилотека поменялась и нужно говорить о языковой совместимости (как это обычно бывает при обсуждении С++) и платформной (донтен/не дотнет).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ЗХ>>>>Ты просил — вероятность принятия индустрией нового языка, за которым не стоят монстры ЗХ>>>>Я ответил
VD>>>Тут вот иногда народ спрашивает сколько приложений на вашем компьютере менеджед и расстраивается когда народ называет 1-3 приложения. А сколько у тебя приложений на Руби, Питоне или не дай бог на ПХП с Перлом?
VD>>>Боюсь столько же скольсо у меня. Максимум где-нить в каталоге скриптик заволялся.
ЗХ>>Ну, на Python'e у меня WikidPad,
VD>Это не у тебя. Это где-то на сайте.
По ссылке сходы, да? Это десктопное приложение.
ЗХ>>А на перле — несколько сотен одноразовых скриптов, написанных мной самим для повседневных нужд (типа перебрать 1000 файлов в каталоге, извлечь из них ссылки на .gif'ы, сложить в один файл).
VD>Это на клиенте? Или опять на сервере?
У меня дома на винте. Запускаются командой "<имя скрипта>.pl <параметры>"
VD>Опять же эти скрипты не сидят постоянно в памяти. Так что если изучать список загруженных процессов, то скриптов среди них не окажется.
И что это доказывает?
ЗХ>>На PHP у меня десятки мелких скриптов на imho.com.ua
VD>Опять же на сервере.
Факт.
VD>Выводы можно сделать такие же как делаются о дотнете. На клиенте пока что этих языков практически нет. Ну, если ты конечно не линуксоид ставящий на машину все подряд.
Погоди. Мы говорили просто о "вероятность принятия индустрией нового языка". Ты можешь про эти языки утверждать, что "индустрия их не приняла"?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И вот я вижу конструкцию, которая мне подозрительной по эффективности кажется. И спрашиваю — нельзя ли здесь как-то иначе. Потому как если начну я просто писать — как бы потом не вышло, что программа будет работать с неприемлемой скоростью.
Если не тормозит — не оптимизируй!
Сколько раз про это писали в книгах, говорили на лекциях — а до людей так и не доходит
Здравствуйте, DarkGray, Вы писали:
DG>>>На вскидку, для языков прикладного уровня я вижу два глобальных направление: П>>(скип) П>>Не знаю почему, но мне это очень сильно напомнило пролог.
DG>Да, именно что-то такое и хочется, только хочется не в виде теоретической разработки, а в виде языка прикладного уровня.
К сожалению у пролога и (аналогичных идей — логические языки) есть один, но очень большой минус — эти идеи не осуществимы даже теоретически . Почти все что есть в нашей работе интересного требует для формализации логики предикатов первого порядка (например нам очень интересна арифметика), а задача доказательства в этом исчислении неразрешима (мат. теорема). Ксати есть есть один, всем известный, логический язык "прикладного уровня" — SQL и те кто на нем пытался хоть что-то сделать (речь, конечно, не о тривиальном запросе) очень быстро упираются в необходимость использовать императивные вставки типа PL/SQL, или получив результат запроса доработать его на на другом языке.
Можно конечно ждать озарений от теоретиков, которые найдут разрешимое исчисление, достаточное в большинстве прикладных задач, но... на сколько мне известно очень давно не было заметных подвижек в этом направлении
DG>У пролога есть один большой и жирный минус — он не подразумевает диалог с программистом.
Я в свое время имел дело с "автоматическими" системами построения доказательств, они, в силу неразрешимости всего интересного, работают в диалоговом режиме, но что это за диалог! Для того что бы добиться от нее даже тривиального результата, надо очень долго искать путь как твою мысль формализовать, что бы "подтолкнуть" эту систему. В частности это выливается в то что надо очень хорошо понимать доказательство и принципы работы "автоматической" части. По сути единственная польза от них в том что если ничего не получается то скорее всего пытаешься доказать неверное утверждение И то, обычно выясняется, что нужное утверждение верно, просто оно неправильно сформулировано...
Мое мнение, что диалог это конечно здорово, но компы пока слишком медленные, что бы с ними разговаривать не как с идиотом
DG>т.е. если задача неподъемная, то комп не говорит — у меня здесь проблема, мне нужно подумать пару лет и т.д.
DG>также прологу нельзя сказать — ну, реши хоть как-нибудь, давай вот в этом месте мы "схитрим" и т.д.
А вот тут, на сколько я понимаю, есть место для прорыва. Если человек готов пожертвовать качеством ответа (в частности его верностью ) то все становится быстрее и даже невозможное становится возможным. К сожалению эта математика мне почти неизвестна. Тривиальный пример — верность утверждения выясняется за время O(1) если вероятность ошибки 50% приелима
PD>>то это срабатывает мгновенно, и памяти программа по TaskManger — Mem Usage занимает 672 Кб.
IT>А почему счётчик аж до 100? До 10 ещё быстрее страбатывало бы
Во-первых, потому что это скопировано из дискуссии в .Net, где меня убеждали, что при доступе к каталогу Windows читает его целиком
Там предложили для пары файлов сделать, ну а я решил не мелочиться
IT>Вообще-то на .NET это будет выглядеть один в один. На MC++. На шарпе можно поизрвщаться немного с DllImport и получится тот же результат.
Так я же не против, что с выходом в unmanaged code это 1:1 получится. Мой вопрос — почему это нельзя без такого выхода сделать ? Иными словами, почему авторы библиотеки так легко Мбайтами разбрасываются ? А ну как я чистый дотнетчик , Win API вообще не знаю, тогда что ? Я ведь даже не догадаюсь тогда, что можно иначе и будет для меня GetFiles истиной в последней инстанции...
IT>В общем, в очередной раз, как я и подозревал, в наличии необоснованные наезды
О господи, да когда же вы перестанете везде наезды искать ? Ну подумай — зачем мне это надо ? Мне же не 18 лет, это из профиля очень хорошо видно . Если я пытаюсь разобраться, значит, мне это как раз нужно, чтобы на такие грабли потом не наступать.
Давай вот что сделаем! Ладно, с моей стороны — это наезды . Прекрасно, давай тогда расскажи ты (или другие гуру от дотнета), что в ней плохо. Что в ней явно хуже, чем в неуправляемом коде. Или ссылки дай. Не может же быть, чтобы в ней все было хорошо. Вот за такую информацию я большое спасибо скажу, так как буду знать, на какие грабли мне наступать не стоит.
Возьмешься ? Я думаю, если у тебя нормальное отношение к ней, с пониманием преимуществ ее и недостатков, то ты (или другие дотнетчики) в состоянии это сделать, и это никак не уменьшит ее реноме. Да, конечно, отдельные несознательные граждане могут завопить — вот, дескать, сами гуру от дотнета ее ругают, но на дураков обращать внимания не стоит. А серьезные люди только с большим уважением относиться будут...
Ну а если ваше отношение к дотнету напоминает "В России нет еще пока команды лучше Спартака" — тогда, конечно , все ясно
Д>Если не тормозит — не оптимизируй! Д>Сколько раз про это писали в книгах, говорили на лекциях — а до людей так и не доходит
Батенька, я об этом знал еще 20 лет назад! И на лекциях сам об этом не раз говорил.
Тормозит. Очень даже тормозит. Жаль мне 56 Мбайт на ровном месте использовать, где один Кбайт нужен. И времени жаль — минуты нет у меня на простенькие операции, где миллисекунды нужны.
Да и не это главное. Но об этом как-нибудь позже — собираюсь изложить свои мысли на этот счет в отдельном выступлении
Здравствуйте, VladD2, Вы писали:
EXO>>Потому как, по моим наблюдениями, быстродействие зависит EXO>>в первую очередь — от архитектуры системы, EXO>>во вторую — от алгоритма,
VD>Это одно и тоже. Архитектура — это алгоритм на очень высоком уровне асбтракции. Но в целом согласен.
EXO>>и уже в третью — от языка реализации...
VD>Согласен. Но опять таки конечный продукт может оказаться медлненее из-за любого из факторов. Конечно архитектура и алгоритмы очень важны, но если с ними все впорядке, но система написана на Руби, а в ней море мат.вычислений, то не фак, что она будет приемлема для использовании на современной технике.
Есть замечательный подход:
1. Пишем продукт на чем удобно => экономим кучу времени на девелопменте, получаем более качественный (по функциональности и фичам) и сопровождаемый продукт.
2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память.
3. Находим тормозные места. Их всегда мало, написать столько кода что бы проц делающий милиарды операций в секунду не справился невозможно, все сводится к выполнению одного и того же кода в цикле (как вариант рекурсия).
4. Оптимайзим, если на выбранном языке никак — переписываем, например, на C++. И вылизываем этот код. Задача небольшая, времения на первом этапе сэкономлено много, низкоуровневый язык нас еще не задолбал проблемами типа GPF.
5. Получаем качественный и быстрый продукт, особо критичные места вылизаны с тщательностью недоступной для тех кто писал на C++ весь проект.
EXO>>И очень часто хорошую архитектуру на "быстрых" языках делать неподьемно долго и дорого. EXO>>в результате — делается что попроще. выигрываются разы, проигрываются порядки. VD>Тоже согласен. Я бы даже сказал слишком часто. Но его рассуждения были не о том. А домыслы... они и есть досмыслы.
Наблюдал C++ vs Smalltalk, выбрав адекватную архитектуру (на C++ ее действительно было очень накладно реализовывать) выигрыш был на порядки! Просто потому что реализация на Smalltalk не занималась ненужной работой.
EXO>>Дазумеется, если реализовывать один и тот же алгорим и одну архитектуру... EXO>>... но это просто глупость архитектора.
VD>Да нет. Это не глупость. Но согласен, что трудозотраты для "быстрых" языков будут несоизмеримо больше, а вот реальный выигрышь не сильно. Ну, а реально скорее всего "быстрые" языки сядут на алгоритмах которые поленились оптимизировать программисты погрязшие в подробности "быстрых" языков.
Не только на алгоритмах, но и на архитектуре. Например наличие GC расширяет выбор архитектур просто за счет того что снимает вопросы типа "А когда это объект должен сдохнут?" "Как бы освобождать память и не нарываться на GPF?" и т.п.
Просто и ясно, без синтетического static.
То же static в другом контексте означает изменение видимости символа для линкера.
