Re: Не пора ли нам перейти на D
От: Zigmar Израиль  
Дата: 26.02.07 17:43
Оценка: 2 (2) +2 -1 :))) :)))
Здравствуйте, Disappear, Вы писали:
D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?
нет
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
Re: Не пора ли нам перейти на D
От: demi США  
Дата: 26.02.07 19:26
Оценка: 1 (1) -1 :))) :)))
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

Вот я считаю, что сейчас тон в программировании задают крупные компании (вы понимаете о ком я? ) — а это значит во главу угла ставится экономическая выгода (кто-то тут писал). Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++ — когда десяками лет тянется старое, извините, говнооптимизации, #include — все нафик это устарело. И нет человека способного это прекратить волевым решением. Бесят смарт поинтеры (assist зачасту не способен на -> нормальную подсказку выдать, мытарства когда надо F11 при дебаге), бесит тормознутость C0x, бесит список инициализации (вместо int const member = 10. С другой стороны имеем C# — хорош, но нет в нем академичности. Ну создан он business-to-business, нет в нем чего-то "разумного, доброго, вечного". Как бы нам ни говорили, что он решает наши проблемы, C# прежде всего решает проблемы Microsoft. У него есть достойные применения, но это выглядит как "мы посовещались, и я решил — мир будет писать под .NET". Извините, а альтернативы? Надоело думать что ты мясо — .NET, Java, C#, С++ требования к программистам так и пухнут, а вместе с ними и башка, а ЗП почему-то неуклонно тянет вниз. Индустрия как будто ополоумила и развивается вширь как на дрожжах. Когда это прекратится и начнется движение в глубь? Наверно только с квантовыми компутерами, благо работаюший образей на днях представили.

А D мне нравится. Нет в нем шелухи, и как оказывается можно сочетать скорость и простоту (камень в огород C#). Один только cast()() — я вообще слюни пустил... А увидел this() конструктор так вообще... ААА!!! В общем, хочу, да нет еще достойной реализации... И тут взглянул на код C++ и понял в каком я дерьме копаюсь...

С++ это как в самолете — тошнит, а выйти некуда... Такие проблемы надо силой решать. D с завтрашнего дня и все тут! Думаю, что сначала это себе позволят маленькие конторки — 4-5 человек или конторы с небольшой историей. Окажется, что после этого они догонят более крупные — писать на D легче, программы лучше. Потом только зашевелятся средние. Но для них это будет больно — тонны кода... Кто-то из них умрет, а кто-то перейдет на D. А там и до гигантов прогресс дойдет Революция как известно с низов начинается. Так что нормальную IDE D и немного либов и все, delete С++
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 17:40
Оценка: -2 :))) :)))
Долой прошлое, господа!
Хватит уже ходить по граблям обратной совместимости с другими граблями.

Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?
Разве мы не заслужили

26.02.07 23:29: Перенесено модератором из 'C/C++' — Хитрик Денис
Re[3]: Не пора ли нам перейти на D
От: demi США  
Дата: 28.02.07 14:51
Оценка: 37 (5) +1
Здравствуйте, ANM, Вы писали:

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


D>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++

ANM> Много эмоций, мало конкретики.
Да вы что? Писать предикаты вам не надоело? Думать об opertaor= и КК или писать boost::noncopyable? Чудовищный COM на котором построена винда вам тоже очень нравится? Даже со всеми хлеперами, вы должны от того отнаследоваться, здесь прописать... Вот простой вопрос. Вы видите определение шаблона для типа T. Каков должен быть тип T? Должен он иметь КК, operator= или там подразумевается скалярный тип или он должен поддреживать некий интерфейс? Только не заливайте, что это должно быть в комментариях. Смотрим boost и STL как вечно пихаемые примеры хорошего кода. Ну ну, разберитесь без доки. И где ваша хваленая читабельность кода? Я вижу определение шаблона, кочу узнать его интерфейс и ВЫНУЖДЕН тупо скролить тела функций (ну нет пока export). И вообще — в C++ слишком много ПИСАТЬ, он давно затраты/польза скатился ниже плинтуса. Конечно он не умрет, многие будут (и вы наверное) за него деражаться, и плыть на тех тоннах кода который уже существует — НО! — за C++ останется поддрежка текущего кода и специфичные сегменты рынка. Для новых приложений его вряд ли выберут. Программист стоит дороже, а пользы меньше. Ну подумаешь на секунду две больше грузится будет. А sprintf с его опасностью не только несовпадения типов, но и выхода за предел буфера. Стримы? Но несмотря на них ОЧЕНЬ большое количество людей попрежнему использует printf. Два типа delete вам тоже по душе? И понимате, это все капает на мозг. Я не секретарша, и мозг и так нагружен — а еще С++ давит.

D>>когда десяками лет тянется старое, извините, говнооптимизации

ANM> Что это такое?
Например, bitfields. Например, то что переменные по умолчанию не инициализируются. А эти инклюды... А триграфы, про которые только приколы и пишут? Вам мало? Это значит только одно — вам больше нравится писать, чем думать, потому что мысли должны естьтественно и немногословно ложиться код. Выводы делайте сами — обезьянки никому не нужны. Сюда включаем пережитки синтаксиса. И все хранится и пылится, а потом выползает в самый неудобный момент — как те же триграфы, выражения типа 3["hello!"] и прочей несуразицы.

D>>И нет человека способного это прекратить волевым решением.

ANM> Конечно. Потому что очень много компаний используют C++.
Ну да, да. Не спорю. В таких компаниях наверно никогда не находится время на рефакоринг. И только сознательные сотрудники, выкраивая своё время делают его. Разве боссу такой компании удасться втемяшитью что 3 месяца работы нудны на то что переделать внутреннюю структуру? Он согласится оплачивать работу своей орыва программистов, узнав, что фичи продукта остануться теми же? Умные архитекторы работают по схеме разработки когда разработка особенно нового сочетается с рефакторингом.

D>>Бесят смарт поинтеры (assist зачасту не способен на -> нормальную подсказку выдать, мытарства когда надо F11 при дебаге),

ANM> Не знаю.. У вас что сотни методов в классе? Если так то есть повод подумать над дизайном проекта.
Не сотни. А скажем 15. Умножьте на ~50 классов. Я не хочу и НЕ БУДУ дословно запоминать имена методов. Я предпочитаю начать писать его имя скажем, из серидины, пусть ассист сам найдет где такое встречается.

D>> бесит тормознутость C0x

ANM> По сравнению с чем ?
Тормознуость я плохо выразился. Я имел в виду, почему так долго они его там мусолят. Почему не так сложно сделать его не backward-compatible? То что происхлодит с C++ — это уже не эволюция. Это деградация. Великая империя не умрет, пока не сгниет из нутри — говорил умный философ. Ясно что в С++ гораздо сложнее вносить что-то новое чем более молодые языки.

D>>бесит список инициализации (вместо int const member = 10; )

ANM> Ну да. Но этого явно недостаточно для смены языка. Мало ли что вас будет бесить в новом.
Это к примеру. Я не буду тут плакаться что то не то, это не то. C++ есть, пока жив, но скоро он отойдет в тень. Еггоь вытеснили из CGI сферы. Его вытеснелили из Business приложений. Он сдает позиции. Это факт. Но с новыми технологиями дешевеет программист. Это факт. Грустный факт.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[46]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 15:23
Оценка: 21 (4) +2
Курилка wrote:
> OK much better
> Вопрос только — а что за сейфпойнты? Насколько трудно их находить,
> насколько их много в программе и не вырастет ли сохранение стека в
> вариант обычного переключения контекста по затратам?
Safepoint'ы нужны для точного GC в любом случае.

Если кратко, то представь метод:
void someMethod()
{
    SomeObject obj1=new ...;
    for(int f=0;f<obj1.getSomeNum();f++)
    {
        AnotherObject obj2=obj1.getSomething(f);
        obj2.someVar=obj2.someVar*2; //(1)
    }
    ...
}


Теперь представим, что в точке (1) у нас закончилась память (в другом
потоке какой-то гад распределил объект в 50Мб) и запустился GC. Для
своей работы GC должен прервать выполнение всех потоков и начать
обследовать объекты.

Однако, для этого GC нужно точно знать в каких регистрах и по каким
смещениям в стеке сейчас лежат указатели на объекты. Для этого в
программах "расставляют" safepoint'ы (сам safepoint никак не выделяется
в коде) для которых точно известно расположение ссылок на объекты,
обычно для этого строятся register map'ы и stackmap'ы (они действительно
обычно занимают некоторый объем, хотя в новой JVM от Sun'а они строятся
динамически по требованию).

Safepoint'ы обычно расставляются перед каждым условным переходом,
вызовом функции и обычно после некоторого числа инструкций (вроде бы,
после 100 инструкций в JVM).

Так что при начале цикла сборки GC просто ждет, пока все потоки не
остановятся на safepoint'ах (кстати, для этого используют интересные
трюки вроде hot code patching). А так как safepoint'ы расставляются
перед вызовами функций (в том числе и "new"), мы можем гарантировать,
что при активном цикле сборки у нас потоки до остановки на ближайшем
safepoint'е не смогут сделать никаких существенных операций с памятью.

Эхх... Надо мне будет как-нибудь дописать свою статью о GC
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[14]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 28.02.07 07:01
Оценка: 29 (5)
Здравствуйте, Cyberax, Вы писали:

C>Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС


C>А то бы можно было бы начать флейм "Только С++ пригоден для использования на АЭС". Эххх...


А меня 3 года назад сватали разработчиком С++ на Запорожскую АЭС.
Причем что плюсы я не знал тогда не знаю и сейчас
Плюсы там используются в системе контроля. То бишь датчики там разные, с них снимается информация и при превышении допустимого уровня звучит алярма. А для отладки и разработки используется эмулятор атомной станции писанный то ли в Беркли то ли еще где. И тоже писан на плюсах. Такие дела...
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[47]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 05.03.07 16:41
Оценка: +5
Здравствуйте, Cyberax, Вы писали:

C>Эхх... Надо мне будет как-нибудь дописать свою статью о GC


Это было бы очень здорово, более высокого уровня экпертизы по данной теме я здесь ещё не встречал.
now playing: Posthuman — Auberginetix Pingamix
Re[13]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 28.02.07 11:45
Оценка: 1 (1) +1 -1 :)
Здравствуйте, minorlogic, Вы писали:

M>Ээээ C++ ?

Это сложный и слабый язык.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 20:38
Оценка: :))) :)
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

26.02.07 23:29: Перенесено модератором из 'C/C++' — Хитрик Денис


2 Хитрик Денис: Вообще так не честно. В C/C++ это был бы нормальный флэйм. Правда ответ на вопрос почему С++-программисты никогда не перейдут на D уже был дан здесь
Автор: Lazy Cjow Rhrr
Дата: 12.02.07
. И С++-программистам это не объяснить (объяснение этого можно найти здесь
Автор: VladD2
Дата: 23.11.06
). Но это был бы честный флэйм в котором сила (масса) неприменно одалела бы разум.

Но снеся эту тему сюда ты неизбежно подменил тему спора, так как рано или подзно (рано с моей помощью, по позже без нее) тема все равно превратится в "Казалось бы причем тут Nemerle".

Так что ты жесток.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: факториальный оффтоп
От: deniok Россия  
Дата: 27.02.07 12:07
Оценка: +1 :)))
Здравствуйте, ie, Вы писали:

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


Ну раз уж пошло обсуждение факториалов, то в Хаскелл-community по этому поводу есть целая серия
здесь

Когда читал первый раз, то, дойдя до последней версии, упал под стол.
Re[5]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.02.07 11:53
Оценка: :))) :)
Здравствуйте, fmiracle, Вы писали:
F>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.
Это закрытая информация. Всё, что я могу сказать: сейчас на RSDN нет форума, в историю которого входит такой прецедент. И для вашего же благополучия — оставьте эти расспросы.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 09:30
Оценка: +3 -1
Здравствуйте, VladD2, Вы писали:

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


VD>Не было бы. Было бы значительно хуже.


То, что ты написал дальше — это хуже для дизайнеров этого языка. Это не проблемы пользователя. Дизайнеры не могут решить эту проблему и говорят — ок, пусть вывод типов будет только локально, это связано с тем, что сделать то-то и то-то трудно/неэффективно/чтонибудьещё. От того, что у ограничения есть объяснение его существования оно не перестаёт быть ограничением. Как отсутствие перегрузки в Хаскеле. Его ведь тоже можно объяснить, нес па?

Что касается "был выбор" то вообще не понятно. Ну, выбрали наличие в языке этого ограничения, ну есть для этого причины, и что? От того, что выбор был оно перестаёт быть ограничением?

А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 01:55
Оценка: +2 -2
Здравствуйте, VladD2, Вы писали:

L>>Прямой вопрос — ты умеешь общаться без перехода на личности?


VD>С такими как ты? Прямой ответ — нет. Ты переходишь на личность оппонента и еще имешь наглость это же предявлять оппоненту.


Наглость имеешь ты. Разговор был нормальным до тех пор, пока ты не начал переходить на личность: "Дело в том, что ты почему-то ассацируешь себя с остальными. Ты можешь ухо через ногу чесать, что с того?", "Что мне до твоего опыта? От твоих предочтений и привычек у людей исходные редпосылки не изменяются". Есть возражения — объясняй их. Не надо мне говорить, какой у меня опыт, как я себя и с кем ассоциирую и почему. Факты и мнение о предмете спора более интересны. Я не коснулся тебя ни разу пока этого не сделал ты. Где до процитированных слов на личность перешёл я?

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


Я задал вопрос, на который ты так и не ответил. Ветка пошла с этого. Оппонент мне вместо того, чтобы ответить на мой вопрос придрался к термину. Как оказалось позже, он сам использует этот же термин.

L>>Мне, знаешь ли, неприятно, когда мои аргументы опровергают тем, что это мол, мои аргументы, а значит априори ложны, бессмысленны и неинтересны.


VD>Какие твои аргументы это уже переходит все пределы. Ты разводишь флуд и демагогию в 70% своих сообщений. Мне уже давно вообще не хочется с тобой не о чем говорить. Ты и еще EvilChild — это две личности при назговоре с которыми у меня все мысли почему-то все время фокусируются на вопросе вменяемости этих личностей.


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

L>>Считай, но это неправда, аргументов полный карман, если они тебе интересны, достаточно всего лишь вежливо о них спросить.


VD>Серьезно? Ой не верю. Тога вернись к этому
Автор: VladD2
Дата: 02.03.07
сообщению и попытайся ответить на те претензии которые к тебе предявили, а не банально поскипав их переходить на личности. Уверне, что этого не произойдет и я сново увижу тонную флуда, демагогии и неадекватности.


Повторю, достаточно лишь вежливо о них спросить. Без перехода на личности, тонны флуда, демагогии и неадекватности, ага!

VD>Извини, но дискутировать можно только с теми кто адекватен, а у тебя я это не наблюдаю. А по сему мне просто не интересно с тобой общаться. Конструктива ведь нет и не предвидится.


Так елки-палки, чего ж общаешься то? Конструктива то нет и не предвидится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 09:27
Оценка: 3 (1) +2
Здравствуйте, Nuzhny, Вы писали:

N>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны.


Эээх... и почему все C++ программисты так говорят увидив код на Немерле?

N>Все программы на Немерле так выглядят?


Да!!! На Lisp они выглядят так:
(defun factorial (n &;optional (acc 1))
  (if (<;= n 1)
    acc
    (factorial (- n 1) (* acc n))))

на OCaml так:
let rec factorial x = 
  match x with 
      0 -> 1 
    | n -> (n * (factorial (n - 1)))

на Haskell так:
factorial 0 = 1
factorial n = n * (factorial (n-1))

на Prolog так:
factorial(0,1).
factorial(N,F) :- N > 0, M is N - 1, factorial(M,Fm), F is N * Fm.

на J вообще так:
factorial =. !

Страаааашно они все выглядят. Так что уважаемый, Блаб, бррр...... Nuzhny, продолжайте писать на C++, единственом лаконичном и по праву называемом великим языке!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[17]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 27.02.07 20:12
Оценка: 1 (1) +2
Здравствуйте, jedi, Вы писали:

J>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек


Та же самая байда, если plain-text код, скажем, на С использует вызов из бинарной библиотеки, который сделает чертичто при запуске приложения (ты ж его вряд ли только компилируешь, но скорее всего и запускаешь?)
Аналогично, нет гарантии как эта библиотека поведет себя в четверг после осадков.
Значит, если имеется приступ паранойи, то по любому надо изучать исходники всех используемых библиотек

Ну так в Nemerle макросы времени компиляции — это точно такая же библиотека, как и библиотеки времени исполнения.

Так что не думаю, что тут что-то серьезно меняется по сравнению с тем, что есть.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[3]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 27.02.07 11:24
Оценка: :)))
Здравствуйте, Disappear, Вы писали:

D>Практика программирования уже успела многое сказать о пригодности интерфейса STL


Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.
Re[10]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.07 11:39
Оценка: +3
Здравствуйте, Disappear, Вы писали:

D>Минусы VM:

D>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше.
Каких например? Это бессмысленный набор слов.
D>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины.
Не факт, что это минусы.
D>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить.
А можно показать конкретно, какие законы математики обеспечивают медленность VM по сравнению с нативным кодом? Я с такими законами не знаком.
D>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.
Как ни странно, большинство С++ программистов, бравировавших при мне своими привычками "ощущать" работу программы, исповедовали богатый набор заблуждений совершенно религиозного характера. Некоторые из них до сих пор оперируют познаниями, которые они получили при дизассемблировании результатов компиляции под 80286. "Ощущение" работы программы — признак хорошего программиста. Оно слабо связано с языком, зато сильно связано с опытом. Можно ощущать работу JVM и NET Runtime не намного хуже, чем работу С++ программы. Можно ощущать работу запроса в MS SQL. Можно ощущать работу x86 кода в современных процессорах Intel. Если, конечно, как следует разобраться в его конвеерах, ядрах и прочих подробностях. Я лично давненько не видал людей, способных, бегло глянув на ASM код, сказать, что там спаривается, а что будет выполняться последовательно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 27.02.07 12:14
Оценка: +2 :)
Здравствуйте, igna, Вы писали:

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


D>>Практика программирования уже успела многое сказать о пригодности интерфейса STL


I>Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.


Тогда лучший выбор — язык J.
Re[18]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 01.03.07 17:12
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>>>fac 0 = 1
VD>>>fac n = fac (n-1) * n


VD>Вот только обычны человек прочтет это код как "fac ((n-1) * n)"


Зато программист на C/C++/Java/C#/... прочтет это как "(fac (n-1)) * n".

Но возможно я не понял, что ты хотел сказать.
Re[22]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 09:20
Оценка: +2 :)
Здравствуйте, VladD2, Вы писали:

VD>Дело в том, что ты почему-то ассацируешь себя с остальными. Ты можешь ухо через ногу чесать, что с того?


О нет Влад, что ты! Это только твоя прерогатива. Слова "практика показывает", "этого нет, значит это никому не нужно" и прочее — это слова из твоих постов. Копирайты за тобой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 02.03.07 20:08
Оценка: +1 :))
Здравствуйте, Sinclair, Вы писали:

S>И что теперь, сетовать на потенциально низкую производительность x86 кода потому, что вдруг sun разработает свой эмулятор PC и забудет для него сделать джит? Бред.


Мда. Что-то на меня помутнение нашло. Конечно ты прав.

Как оно получается. Мыслишь себе мысль, она кажется умной.
И когда говоришь кажется умной. А по прошествии времени оказывапется что сморозил глупость.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[28]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 21:18
Оценка: +1 -1 :)
Здравствуйте, IT, Вы писали:

L>>"упрощение выявления ошибок и документирование"?


IT>С практической точки зрения особенно первое.


Можно пример, как глобальный вывод усложнит выявление ошибок?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 01:55
Оценка: -2 :)
Здравствуйте, Андрей Хропов, Вы писали:

АХ>1) скорость компиляции (взасчет локального, а не глобального анализа)


АХ>2) компонентность (в т.ч. интеграция с другими языками)


АХ>3) упрощение реализации Intellisense в IDE (по тем же причинам, что и 1) )


АХ>В общем я целиком за локальность и следующующую из нее компонентность.


1 и 3, к сожалению, не имеет отношения к тому, что меня интересовало. А вот под вторым пунктом что имелось в виду? Как глобальный вывод может ухудшить компонентность?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.03.07 19:28
Оценка: 18 (1) +1
Здравствуйте, Mirrorer, Вы писали:

M>Интерпретатор ассемблера с JIT компиляцией будет быстрее просто интерпретации ассемблера в общем.

Не болтайте ерундой. Еще десять лет назад существовали Альфы, которые гоняли x86 s режиме эмуляции. Ровно так, как рассказано: и с джитом, и с интерпретацией. Естествнно, приложения работали медленнее, чем нативные.
И что теперь, сетовать на потенциально низкую производительность x86 кода потому, что вдруг sun разработает свой эмулятор PC и забудет для него сделать джит? Бред.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 19:00
Оценка: 15 (2)
Здравствуйте, lomeo, Вы писали:

L>Ограничение заключается в том, что для нелокальной функции это использоваться не может. Впрочем, мне уже ответили, так что забей.


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

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

Но как человек немного в этом разбирающийся скажу честно. Алгоритм очень вычислительно сложный. Так что если не отсекать это дело на уровне методов, то тормозить будет не щадно.

Одако решение оказалось просто удивительно грамотным. Так оно позволило реализовать реалтайное редактирование тел методов в IDE (инкрементальную их компиляцию).
Сейчас мы делаем так. Сначала сканируем все файлы и сроим дерево типов. При этом тела не парсятся и не типизируются. Далее когда открывается конкретный файл в фоновом режиме компилирются тела только тех методов, что находятся в этом файле. При изменени метода происходит только его перекомпиляция. В итоге имеем практически реалтаймное редактирование языка значительно более лсожного чем С++. При этом поддерживаются раскрытие макросов и т.п.

Я даже не знаю как делать интеграцию с IDE если будет решено выводить типы глобальном уровне.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Библиотеки
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 18:31
Оценка: 14 (1) +1
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>И какая часть из них — открытая? Точнее, больше интересует бесплатность для разработчика, в т.ч. проприетарного софта (ибо на дядю работаю).


Бесплатны, т.е. не требуют каких либо отичислений, все перечисленные библиотеки.

Открыты, в смысле имеют ОпенСорс-реализацию, пока только #GTK и MS Forms (в Моно). Причем MS Forms реализована не полностью. Есть планы по реализации (в Моно) WPF.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Не пора ли нам перейти на D или что-нибудь вроде этог
От: OCTAGRAM Россия http://octagram.name/
Дата: 04.03.07 13:38
Оценка: 11 (2)
Здравствуйте, Alxndr, Вы писали:

A>Если на C++ получается писать только хлам — что ж, это выход


Основную проблему C++ я вижу в том, что он не безопасен by design. Это как запорожец ( C ), затюненный (++) под мерседес. (Но ведь это всё равно запорожец) Почему бы, спрашивается, сразу не выбрать мерседес? Очевидно, гораздо дешевле писать на привычном C++, а потом сказать, что это самый безопасный продукт за всю историю человечества. Java и .NET, конечно, хорошо, но какая-то часть кода всё равно должна быть нативной. Особенно, если это системный код. И вот тут-то, в самых критических местах до сих пор используется Це-баг-баг! (Если не сам Це, что не лучше)

Я слышал такие аргументы в сторону C++, что продвинутый человек может обходить все грабли, зная о них. В качестве контраргумента приведу начало из Cyclone: A Type-Safe Dialect of C :

If any bug has achieved celebrity status, it is the
buffer overflow. It made front-page news as early
as 1987, as the enabler of the Morris worm, the first
worm to spread through the Internet. In recent years,
attacks exploiting buffer overflows have become more
frequent, and more virulent. This year, for exam-
ple, the Witty worm was released to the wild less
than 48 hours after a buffer overflow vulnerability
was publicly announced; in 45 minutes, it infected
the entire world-wide population of 12,000 machines
running the vulnerable programs.
Notably, buffer overflows are a problem only for the
C and C++ languages—Java and other “safe” lan-
guages have built-in protection against them. More-
over, buffer overflows appear in C programs written
by expert programmers who are security concious—
programs such as OpenSSH, Kerberos, and the com-
mercial intrusion detection programs that were the
target of Witty.
This is bad news for C. If security experts have
trouble producing overflow-free C programs, then
there is not much hope for ordinary C program-
mers. On the other hand, programming in Java is
no panacea; for certain applications, C has no com-
petition. From a programmer’s point of view, all the
safe languages are about the same, while C is a very
different beast.


Ну и, например, такой комментарий :

Firefox security holes

There’s a new version of Firefox out (1.5.0.2), with fixes for 22 security issues, according to Secunia. My favorite is this one:

2) An error in the garbage collection in the JavaScript engine can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

Apparently garbage collectors are not perfect! Who knew.

Among the 22 issues there are a bunch that would clearly be prevented by a safe language like Cyclone:

3) A boundary error in the CSS border rendering implementation may be exploited to write past the end of an array.

4) An integer overflow in the handling of overly long regular expressions in JavaScript may be exploited to execute arbitrary JavaScript bytecode.

6) An error in the “InstallTrigger.install()” method can be exploited to cause a memory corruption.

13) An error in the processing of a certain sequence of HTML tags can be exploited to cause a memory corruption.

Successful exploitation allows execution of arbitrary code.

15) Some errors in the DHTML implementation can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

16) An integer overflow error in the processing of the CSS letter-spacing property can be exploited to cause a heap-based buffer overflow.

Successful exploitation allows execution of arbitrary code.

Some of the others might be safety issues as well, but it takes quite a bit of digging to figure these things out.

14 April 2006 by trevor



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

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

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

Я считаю, целостность — минимальное требование. Поэтому C/C++ я считаю хламом. Историческую функцию они исполнили (когда нужно лишь бы работало). Я считаю, нужно давно что-то менять. Вы можете признавать это, можете нет, это ваше дело.

Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada? Потому что на C похож (первое, что в глаза бросается)? Думаю, список должен быть шире. Вроде есть соседний топик "альтернативные" языки, но там альтернативность больше по ориентированности (ФП, ЛП) просвечивает, здесь же явно выраженная императивность.

Небольшие проги ещё на Cyclone можно писать.

Трудность в том, что непонятно, с какой стороны делать переход. Когда требования спускаются сверху, и требуется просто зарабатывать деньги (трое детей в семье, не считая собаки) на C/C++, тут трудно что-то изменить. А те, кто спускают требования, преследуют другие цели. Покупателю (в своей массе) не важно, как сделано, главное, как работает. Порочный круг.

Потенциальный выход я вижу в школьниках и студентах. Чему их сейчас учат? Вот на том они и пишут. В массе, опять же, в массе.

Приход Эйфеля в Россию я пока не наблюдаю. А вот у Ады есть шансы!

Ада &mdash; идеальный базовый язык образования в области информационных технологий

По настоящему важными, однако, являются следующие соображения: насколько данный
язык облегчает профессиональное изложение учебного материала и насколько он облегчает
усвоение студентами совокупности учебных дисциплин. Среди этих причин – привычки и
квалификация преподавателей, доступность литературы, изданной на бумажных носителях и
на русском языке, личные предпочтения тех, кто разрабатывает (или утверждает!) учебно-
квалификационные программы специальностей и рабочие программы конретных курсов, пред-
ставления о том, что в данный момент наиболее востребовано рынком труда. Сплошь и рядом
мы имеем совершенно ненормальные ситуации, когда основной (и нередко математизирова-
ный) курс по алгоритмам и структурам данных поддерживается ... языком Си, курс по парал-
лельному программированию и системам реального времени основывается на Джаве (которая
не для этих областей проектировалась и создавалась), а курс по методам разработки и сопро-
вождения больших программных систем использует в качестве языка сопровождающего прак-
тикума, извините, Паскаль-Дельфи. В результате существенная часть времени и сил тратится
на попытки разглядеть алгоритм (а еще того сложнее – структуру данных!) через криптогра-
фический синтаксис Си или, скажем, на то, чтобы отделить проблемы адресной арифметики от
логических и математических проблем организации сортировки и поиска. Или (в курсах по
параллельному программированию) возиться с тем, чтобы правильно переключать семафоры
и вовремя посылать сигналы (от чего всеми силами стремится уйти реальная программная ин-
дустрия!) вместо того, чтобы выделять процессы и разрабатывать модели их взаимодействия
высокоуровневыми средствами, допускающими эффективный статический и динамический
контроль. Еще конфузливей «освоение методов» проектирования и разработки больших про-
ектов и систем средствами Дельфи, предназначенной только (и в этом качестве действительно
широко и эффективно используемой) для быстрого прототипирования и создания графических
интерфейсов конкретно под Виндоуз. При этом такими реальностями больших проектов, как
полиплатформенные стандарты, Юникс-ориентированные инструменты, лицензионная чисто-
та, разумеется, даже не пахнет.


Я из приведённых мной языков (добавьте свои варианты по вкусу, например, Erlang) наивысший приоритет отдаю Аде, потому что это язык универсальный и при этом сравнительно разработанный. Из всех перечисленных языков только Ада входит в main GCC distribution. gcc и так для меня важный инструмент, а тут ещё Ада в основной поставке. Это удобно.

К тому же, GNAT осваивает .NET.

Это значит, переносимый код для нативных и управляемых сред. Удобно, не правда ли?
Re[51]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 18.03.07 11:41
Оценка: 8 (2)
VladD2 wrote:
> Откуда практика то? О чем ты? А теорией можешь разжиться через гугль.
Практики у меня немного есть. Я когда-то начинал писать точный GC для
Mono — как раз дошел до того, что у меня строились карты стека. Потом
надоело

> Набирашь те самые базворды GC "safe point" "GC root" map

> <http://www.google.ru/search?hl=ru&amp;q=GC+%22safe+point%22+%22GC+root%22+map&amp;lr=&gt;.
> Например, там во первых редах сразу попалась глава из книжки посвященной
> Ротору <http://www.oreilly.com/catalog/sscliess/chapter/ch07.pdf&gt;. ЖЦ
> дотнета посложнее, но принципы те же.
К сожалению, не все так просто. Хороших статей про внутреннее
описание работы тонких моментов в GC не так уж и много. Все что есть —
это, в основном, пересказы про то как работают механизмы GC с поколениями.

Например, организации safepoint'ов уделено не так уж много статей. В
твоей статье в про SSCLI используется самый простой и тупой подход —
поллинг.

Для сравнения — вот хороший отчет о GC safepoint'ах в JVM:
http://research.sun.com/techrep/1998/smli_tr-98-70.pdf

> Единственное, что есйчас интересно в этой област с точки зрения теории —

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

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

> Но будет ли выхлоп и какой он будет пока не ясно. Хотя

> технология очень многообещающая. По радостным рекламным возгласам
> эффективность управления памятью в плотную приблизится к лучшиму что
> можно достигнуь управляя памятью вручную (не путать с тем чего достигают
> большинство обывателей).
Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом
уже с WolfHound'ом говорил.

Ну и на ручное управление памятью не надо наезжать, оно живее всех живых

> Вот только боюсь, что это вся доступная информация по этому поводу .

Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено
искать.

> Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое

> изложение интересно еденицам.
Я ее прочел

> Есть даже пара книг специально алгоритмам сборки мусора посвященных.

> Но ты их даже не посмотришь.
Собственно, я знаю только одну хорошую книгу —
http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[8]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка: 7 (2)
Здравствуйте, Nuzhny, Вы писали:

N>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?


Ну, давай сравним с оригиналом.
Возмем саму функцию (на D):
template factorial(int n : 1)
{
    enum { factorial = 1 }
}

template factorial(int n)
{
    enum { factorial = n* factorial!(n-1) }
}

и на Nemerle:
Factorial(n : uint) : ulong
{
    | 0 | 1 => 1
    | _     => n * Factorial(n - 1)
}

Могу переписать ее более "понятно" для тех кто привык только к С++:
Factorial(n : uint) : ulong
{
  if (n == 0 || n == 1) 1
  else n * Factorial(n - 1)
}

Она правда корректна по сравнению с оригиналом (где в случае n < 1 будет зацикливание), но все же.
Где здесь какие-то лишние скобочки или еще что-то?

Теперь думаем что мы получили и как можем использовать. А получили мы рекурсивый шаблон на D. Использовать этот шаблон мы может только во время компиляции. Вычисляться он будет в режиме интерпретации.

На Nemerle мы получили просто функцю. Мы можем вызвать ее в программе как любую другую. Теперь чтобы вычислить эту функцию во время компляции мы просто помещаем ее вызов в макрос:
macro CompileTimeFactorial(n : uint)
{
    def res = Util.Factorial(n);
    <[ $(res : ulong) ]>
}

в котором мы производим вычисление и помещаем результат вычисления код генерируемый макросом.

В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.
То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.

Что тут непонятного? Возможно:
<[ $(res : ulong) ]>

да, это новое для D/C++-программиста. Но объяснить это не так то и сложно.
Это способ сгенерировать код. Подобных средств в D и С++ попросту нет. Потому и сравнивать тут нечего.
<[ ]> — это аналог строкового литерала в C++, но в отличии от С++ внутри этого литерала получается не страка, а выражение которое можно подставить в программу. Другими словами <[ ]> выделяет участки кода которые интерпретируются компилятором не как исполняемый код, а как заготовка для генерации кода.
$ — позвляет состалься в этой заготовке на переменные из внешнего кода. Так что мы, например, может написат так:
<[
if ($x)
SomeCall();
else
$x
]>
и значение "x" будет подставлено в те места где пы указали $x. Толко значнеие "x" будет интерпретироваться как участок кода. Так что если мы подставляем некий литерал, то нам нужно указать компилятору, что его нужно преобразовать в код. Так $(res : ulong) говорит, что значение из внешней (мета-) программы нужно преобрзовать в литерал (в компилируемой программе).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 19:51
Оценка: 6 (1) :)
Здравствуйте, fmiracle, Вы писали:

F>Программист даже на самом строгом языке может с легкостью нагенерить совершенно случайного кода.

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

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

Вот еще подумалось — если такие языки распространятся, то скачав безобидный исходник из сети и поставив его на компиляцию, я могу стать жертвой
очень хитрого вируса. Нет, в самом коде не будет "format c:", но какой-то хитрый макрос будет вызывать какую-то стандартную либу и использовать дыры в ней. Да мало ли ужастей можно придумать?

Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[24]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 21:18
Оценка: 6 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>Ну, что же... Ответов на прямые вопросы нет. Аргументов тоже. Наличиствует только мелкая демогогия и переход на личности.


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

VD>Будем считать, что ты просто пытался сказать, что у тебя закончились аргументы и вопросы. Адью.


Считай, но это неправда, аргументов полный карман, если они тебе интересны, достаточно всего лишь вежливо о них спросить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 02.03.07 06:32
Оценка: 3 (1) +1
Здравствуйте, VladD2, Вы писали:


VD>Вот это не правда. Никакого математического назначения туту нет и в помине. Это чистые проблемы Хасклеля с приоритетами. Такие проблем есть толко ML-подобных языках.


Я, конечно, не знаю все 200 с хвостиком существующих языков, но по-моему "проблема с приоритетами" операторов есть в любом из них (кроме Lisp-подобных, где всё префиксно)
Выражение типа

1+2*3


во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета. Хаскелл не требует использования скобок вокруг аргумента(-ов) функции, поэтому просто добавляется ещё один (высший) уровень приоритета — применение функции, то есть в выражении типа
1 + sin x * 2

сначала sin x, а потом всё остальное. Я, главное, не вижу здесь ровно никаких проблем. Просто нужно понять, что в Хаскелле любой идентификатор — функция и
1 + a b * 2

это ровно то же самое, что и в примере с sin: применение функции a к b и затем умножение и сложение — в порядке приоритетов.
Re[27]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 02.03.07 16:18
Оценка: 3 (1) +1
Здравствуйте, lomeo, Вы писали:

IT>>Были буквально тремя постами выше, просто ты не внимательно читал.


L>"упрощение выявления ошибок и документирование"?


С практической точки зрения особенно первое.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Не пора ли нам перейти на D
От: Аноним  
Дата: 26.02.07 18:21
Оценка: 2 (1) +1
Здравствуйте, Disappear, Вы писали:

D>А зачем что-то сменять? Есть бинарная совместимость на уровне obj-ектников. К старому хламу пишем кучу фасадов.


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

Если ты работаешь один, то все это тебя конечно не интересует.
А на реальных проектах просто так ничего не получится.
Да и сырой еще этот язык с туманной перспективой.
Re[12]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 10:35
Оценка: 1 (1) +1
Здравствуйте, Disappear, Вы писали:

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


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


M>>Теперь берем те же программу, переносим на Pentium IV.

M>>Внимание вопрос. Сможет ли с++ программа скомпилированная под 486 использовать фишки четвертого пня для ускорения работы ?
M>>А та же дотнетовская программа сможет. Потому что JIT сгенерирует native код для той платформы на которой он будет выполнятся.

И к тому же в догонку. Разве кто-то мешает отдельно скомпилировать программу для 586, x64 и во все что угодно, что компилятор позволяет...
Тут получается вопрос только в развертывании приложения, не более того.
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 10:59
Оценка: 1 (1) +1
Здравствуйте, Mystic, Вы писали:

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


D>>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>>Разве мы не заслужили

M>А от нас что-то зависит? Оно то может и пора, но пока непонятно, за счет чего может осуществится такой переход. Финансовых магнатов за этим языком не M>наблюдается. Весомых козырей тоже нет. Удобство при проектировании и разработке в общем-то фоска, так как проще обходить старые грабли, чем решать с M>нуля нетривиальное бизнес-требование, такое как GUI,


GUI библиотеки есть на D. Например DFL http://www.dprogramming.com/dfl.php

M>кроссплатворменность, работа с БД, работа с COM, распределенное приложение, и т. д. Для примера, насколько просто написать на D элементарное

M>приложение с использованием, например, библиотеки wxWidgets?

Существует мост также и для wxWidgets http://wxd.sourceforge.net/

M>Что-то мне кажется, что на этом пути можно встретить очень много проблем, начиная прямо

Безусловно, но это только в начале пути. Главное чтобы эти проблемы не происходили на всем пути.

M>от макросов DECLARE_CCLASS, IMPLEMENT_CCLASS, BEGIN_EVENT_TABLE. Думаю, что тривиальным фасадом тут обойтись будет проблематично.А как дела обстоят с

M>использованием STL? Остается надежда на энтузиастов,

Практика программирования уже успела многое сказать о пригодности интерфейса STL Включать что-то подобное в D, мне кажется, не было смысла.
А такие же инструменты, и даже более расширенных их набор в D есть.

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

M>кажется, что сейчас студенты больше интересуются не тем, чтобы самому реализовывать свою можель велосипедае (иногда более совершенную, иногда менее),
M>а тем, чтобы осваивать коммерчески успешные продукты, которые впоследтвие предоставят им возможность заработать больше денег.

Среди людей иногда попадаются энтузиасты. В том числе среди студентов.
Re[11]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 22:05
Оценка: 1 (1) +1
Здравствуйте, ie, Вы писали:

ie>Не знаю. Но C# программеры в моем окружении относятся к Немерле скорее положительно, а C++ наоборот


Дык это понятно. Если для C#-программиста Nemerle — это логическое развитие с небольшим количеством изменений, то для С++программиста — это крушения образа мысли. Сам переживал подобное пару раз и знаю насколько это тяжело переносить.

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

ie>Тот же D будет несомненным шагом вперед


+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.02.07 11:53
Оценка: 1 (1) +1
Здравствуйте, Disappear, Вы писали:

D>Xn = Y

D>Xv = V + Y

D>Xn != Xv

->>
D>X != V + Y
D>V > 0
->>

D>Xn < Xy



D>Xn — общее время выполнения native приложения

D>Xv — общее время выполнения managed приложения
D>Y — время выполнения кода приложения
D>V — время выполнения функций VM


Гм. А что такое "функции VM"? Кстати, если я правильно читаю запись, вы сначала исходите из аксиомы о неравенстве времен выполнения, а уже потом доказываете наличие какой-то злой силы.
Данная математика подразумевает модель, в которой в любом режиме выполняется один и тот же код, а "виртуальная машина" — это некоторое зло, которое крутится под ногами и занимает CPU. Это в корне неверно.
Во-первых, для начала, получить 100% одинаковый код практически невозможно. В том смысле, что, к примеру, использование смарт поинтеров приводит к тому, что у объектов постоянно изменяется m_refcount, даже при передаче только для чтения. И это в лучшем случае — когда код смарт поинтера заинлайнен, в КОМ это еще и неустранимые косвенные вызовы. В управляемой среде такие ухищрения не нужны, и этот мусорный код исполняться не будет.
Во-вторых, никаких особых "функций виртуальной машины" не существует в природе. JIT-компиляция? Не смешите меня, она выполняется максимум 1 раз за время использования кода. Это если не использовать предкомпиляцию — а ведь ее никто не запрещает. Сборка мусора? Для среднестатистического приложения она стоит столько же, сколько вызов деструкторов. В некоторых случаях она дешевле, в некоторых — нет.

D>Никие ощущения VM вам не помогут, когда дело дойдет до отладки системных API.

А что, вызовы системных API из управляемой среды ощущаются как-то иначе, чем они же из С++?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 01.03.07 08:19
Оценка: 1 (1) -1
VladD2 wrote:
> C>Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он
> C>хранится в виде single-linked списка. А это уже overhead.
> Мне плевать на JVM. В дотнете никаких списков нет. Это ровно один бит
> расположенный рядом с битом использованием для пометки объекта как
> посещенного. Так что у тебя проблемы с матчастью.
Тебя послать RTFS? Для GC важно заранее знать где он может встретить
за-pin'еные объекты, так как от этого сильно зависит оптимальность
упаковки кучи. Скажем, в JVM каждый pinned-объект скушает целую страницу
памяти из-за того, что GC использует guard-pages как триггер (это
позволяет сделать аллокатор буквально из двух инструкций). В .NET,
кстати, точно так же.

>> > Никаких контекстов ЖЦ сохранять не нужно.

> C>Нужно.
> ОК. Подверди, плиз свои утверждения. Сразу предупреждаю, чно кивать на
> Яву не надо.
Немного сложно объяснить — нативные функции могут работать даже во время
цикла полной сборки мусора, надежных общих способов остановить натвную
функцию не существует (я уж молчу про целые параллельные нативные
потоки, работающие с объектами в VM).

Поэтому у нативных функций есть два варианта работы с объектами в VM —
через pinned-объекты и с помощью handle'ов. Pinned-объекты очень часто
слишком дороги (поэтому в JNI из JVM они используются обычно только для
доступа к массивам). Так что остаются handle'ы.

Но тогда появляется проблема — нужно синхронизировать доступ GC к данным
в этом треде и доступ нативного мутатора. А тут появляется целая куча
интересных сценариев (рассказать?). Чтобы этого избежать можно просто
использовать мьютекс и не мучаться — но это жуткая потеря
производительности, поэтому в новых JVM используют хитрую схему с
трамплинами и code patching'ом. Поэтому при входе в нативную функцию и
требуются действия по модификации контекста GC.

Кстати, мне подумалось, что именно из-за этого MS и не сделала
нормальный аналог JNI.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Не пора ли нам перейти на D
От: Tilir Россия http://tilir.livejournal.com
Дата: 26.02.07 18:08
Оценка: :))
Здравствуйте, Disappear, Вы писали:

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

Я предлагаю вам привести какой-нибудь простой и ясный пример. Вот задача. Вот так она криво и плохо решается (или вообще не решается на C++). А вот так она красиво и грамотно решается на D. И сразу всё станет ясно и убедительно. Ссылка не убедила — язык без нормальных шаблонов, множественного наследования и макросов это шаг назад, а не вперёд, ИМХО. Да ещё и весьма сомнительный garbage collection. Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 20:15
Оценка: -2
Здравствуйте, Viper_Craft, Вы писали:

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



V_C>Тоже самое можно и в С++, но в С++ шаблоны не только для этого...

Но не так просто и изящно. И не только это...

T>>>множественного наследования

D>> многие с Вами не согласятся. А часто вы используете множественное наследование?
V_C>Да, а вы понимаете данный термин?

Множественным наследованием может быть только наследование интерфейсов, все остальное — супостат.


T>>>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

D>>В языке C++ его же идиому RAI сложно использовать.

V_C>Тут скорее так, в С++ ты можешь использовать GC и RAI, т.е. есть выбор, а это дополнительный плюс...


Подскажите мне пожалуйста хотябы одну реализацию GC в C++? Умные указатели не предлагать.
Re[6]: Например миксинами.Не пора ли нам перейти на D
От: vsb Казахстан  
Дата: 26.02.07 20:53
Оценка: -2
Здравствуйте, Alxndr, Вы писали:

A>Какие проблемы эта возможность порождает, чтобы нужно было от нее отказываться?

По-моему это довольно старый вопрос. Есть аргументы и за, и против. С точки зрения создателя D минусы перевесили плюсы.

A>Я напомню еще Eiffel и CLOS.

Спасибо.

A>Рановато называть D индустриальным. Остается C++, Java и C#.

При этом Java и C# появились куда позже C++, а значит у их создателей было время подумать над дизайном языка.

A>Аминь

A>Тогда шаблоны тоже нужно выкинуть — как не востребованные в большинстве индустриальных языков программирования.
A>И детерминированное уничтожение объектов туда же.
A>И много чего еще.
Почему? Я не говорю, что множественное наследование — плохо, я говорю, что его отсутствие — не есть реальная проблема. А отсутствие шаблонов — проблема. Которой в D к счастью нет.


A>Можно с этого места подробнее?

http://www.digitalmars.com/d/mixin.html
Re[7]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 26.02.07 21:17
Оценка: +2
Здравствуйте, Disappear, Вы писали:

S>И что это даст. Никаких библиотек под D особенно не


...

D>А насколько был эффективен перепрыг скажем с VB на C# и.NET 1.0? Так поступило множество контор. Что там было экономически выгодно?


К C# прилагался еще .NET Framework. А это ого-го какая библиотека. И вот она уже в сочетании с удобством и мощностью языка и дает экономические выгоды при разработке.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[8]: Не пора ли нам перейти на D
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.02.07 07:22
Оценка: +1 :)
Здравствуйте, Nuzhny, Вы писали:

N>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?


В C/C++ тоже множество непонятных скобок, в том числе фигурных, символов ('>>', '%', '!=') и т.д. Для меня вот C/C++ нечитабельным выглядит. Не то, что Scheme! Там вообще только один вид скобок — круглые. Тот же факториал записывается легко и доступно, с использованием совершенно читабельного синтаксиса.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[9]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 08:30
Оценка: +1 -1
Здравствуйте, konsoletyper, Вы писали:

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


D>>Читал про nemerle немного.


K>Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.


D>> Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)


K>И что? VM — весьма условная штука. На самом деле всё так же компилится в native-код и выполняется достаточно быстро.


Минусы VM:
— Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше.
— Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины.
— Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. Никакие технологии, и отчаянные попытки маркетологов не убедят в обратном.

Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.

D>>Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)


K>Какие именно закорючки не понравились? Чем вообще синтаксис плох?


Говорю же — субъективно. Как С++ программисту, нравится С/C++ синтаксис, а лучше — если он проще, как в D.
Re[2]: Nemerle - еще вопрос
От: Дм.Григорьев  
Дата: 27.02.07 10:06
Оценка: :))
Здравствуйте, Курилка, Вы писали:

К>Насколько я понимаю, всё это определяется платформой на которой работает немерле — .Net, думаю что есть в нём, ты в курсе.


Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 11:52
Оценка: :))
Здравствуйте, Sinclair, Вы писали:

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


D>>Минусы VM:

D>>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше.
S>Каких например? Это бессмысленный набор слов.
D>>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины.
S>Не факт, что это минусы.
Это был ответ на предыдущий вопрос. Это недостаток "мощи"

D>>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить.

S>А можно показать конкретно, какие законы математики обеспечивают медленность VM по сравнению с нативным кодом? Я с такими законами не знаком.

Xn = Y
Xv = V + Y

Xn != Xv
->
X != V + Y
V > 0
->

Xn < Xy


Xn — общее время выполнения native приложения
Xv — общее время выполнения managed приложения
Y — время выполнения кода приложения
V — время выполнения функций VM

D>>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.


S>Как ни странно, большинство С++ программистов, бравировавших при мне своими привычками "ощущать" работу программы, исповедовали богатый набор заблуждений совершенно религиозного характера. Некоторые из них до сих пор оперируют познаниями, которые они получили при дизассемблировании результатов компиляции под 80286. "Ощущение" работы программы — признак хорошего программиста. Оно слабо связано с языком, зато сильно связано с опытом. Можно ощущать работу JVM и NET Runtime не намного хуже, чем работу С++ программы. Можно ощущать работу запроса в MS SQL. Можно ощущать работу x86 кода в современных процессорах Intel. Если, конечно, как следует разобраться в его конвеерах, ядрах и прочих подробностях. Я лично давненько не видал людей, способных, бегло глянув на ASM код, сказать, что там спаривается, а что будет выполняться последовательно.


Никие ощущения VM вам не помогут, когда дело дойдет до отладки системных API.
Re[12]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 13:13
Оценка: +1 :)
Здравствуйте, Nuzhny, Вы писали:

ie>>Тот же D будет несомненным шагом вперед


N>Да? Я, вот, работаю и не ощущаю никаких неудобств, связанных с С++. Это, значит, плохо? Сложности возникают при разработке алгоритмов, а реализуется всё достаточно быстро и в срок.


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

N>Далее: тут приводится куча аргументов о скорой смерти С++ (а значит и D) в связи с развитием С#/Nemerle. Зачем же мне учить мертворожденный язык?


Учи Nemerle, но учти(!) после его использования хотя бы в одном проекте возникает жуткая ломка при возвращении к прежним языкам
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[5]: Не пора ли нам перейти на D
От: Tilir Россия http://tilir.livejournal.com
Дата: 27.02.07 13:28
Оценка: -1 :)
Здравствуйте, Disappear, Вы писали:

T>>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?

D>Вопрос поставлен неправильно. Правильно он звучит так.
D>Зачем нам такое г@вно на D?

Вы только что назвали г@вном библиотеку, которая стабильно использовалась для написания невероятного количества кода. Рабочего, активно использующегося, стабильного. Хочу добавить — мою любимую библиотеку. Минус ставить не буду, но прошу сбавить градус снобизма.

D>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.


А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?

T>>Или вы предлагаете хором перейти на VCL?

D>Нет, для MFC пожалуй не стоит использовать D.

Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?). В общем резюме такое — для разработки программ чуточку сложнее Hello World, язык D пока что не имеет ни достаточной инфраструктуры, ни средств для переноса на него существующих библиотек с C++.
Re[6]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 19:50
Оценка: +2
Здравствуйте, Tilir, Вы писали:

T>Вы только что назвали г@вном библиотеку, которая стабильно использовалась для написания невероятного количества кода. Рабочего, активно использующегося, стабильного. Хочу добавить — мою любимую библиотеку. Минус ставить не буду, но прошу сбавить градус снобизма.


Извини, но хвастаться макросными мапами — это смешно. Это даже для С++ дремучее и страшное прошлое. А для языков поддреживающих функции высшего порядка вообще смешно.
Вот как может выглядить подключение обработчика события без макросов:
listView.AfterSelect += fun(_, e) { Text = e.Node.Text; };

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

T>А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?


В Ди можно полностью потворить стиль ATL используя миксины.
Но лично я предпочитаю просто не связываться с КОМ. Уж больно некрасивая реализация у этой технолгии. Компонентная модель у дотнета и Явы куда лучше. Чтобы создать контрол не нужно так извращаться и "набивать" свой класс тонной непонятной функциональности (которая потом еще неясно как будет сосуществовать). Мне достаточно просто создать наследника от подходящего класса и все будет работать.

T>Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?). В общем резюме такое — для разработки программ чуточку сложнее Hello World, язык D пока что не имеет ни достаточной инфраструктуры, ни средств для переноса на него существующих библиотек с C++.


Во истину если у тебя в руках молоток, то все вокург кажется гвоздями.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 28.02.07 05:49
Оценка: :))
VladD2 wrote:
> D>И даже не CRM система для нового склада памперсов...
> Небольшая справка. "Софт для АЭС" — это такой прикло который постоянно
> всплывает как последний аргумент против управляемых сред. В общем, "Софт
> для АЭС" стал таким примера притянутого за уши аргумента.
Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС
(Indian Point Energy Center) для учета персонала

Прямо жаль, что я его писал на Java, а не на С++. А то бы можно было бы
начать флейм "Только С++ пригоден для использования на АЭС". Эххх...
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[12]: Не пора ли нам перейти на D
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 28.02.07 06:26
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

ie>>Не знаю. Но C# программеры в моем окружении относятся к Немерле скорее положительно, а C++ наоборот


VD>Дык это понятно. Если для C#-программиста Nemerle — это логическое развитие с небольшим количеством изменений, то для С++программиста — это крушения образа мысли. Сам переживал подобное пару раз и знаю насколько это тяжело переносить.


VD>Реакция обычно следующая. Сначала полное не понимание и безразличие. Потом страх и животная неприязнь. Потом разбитое состояние, ощущения расстерянности вызванное тем, что человек начинает понимать, что знакомые идеомы, навыки и т.п. все-все-все — это много лет не лучшим образом проведенной жизни. Далее есть варианты. Сильный человек оценивает достоинства и недостатки и выбирает более мощьный и простой язык, а мнее сильный обычно просто говорит себе — ну и хрен с ним — и поглубже зарывает голову в песок.


А умный — осознает, что смысл жизни далек от всего этого. Бугага.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[6]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 28.02.07 06:46
Оценка: +2
Здравствуйте, Tilir, Вы писали:

D>>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.


T>А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?


Я в свое время делал это на Delphi. И никак не мог понять почему COM программирование считается большим анусом... Потом прочитал книгу Inside COM, посмотрел на реализацию простейшего СОМ сервера на С++. Как бы это помягче выразится.. Впечатления были очень протеворечивые..

Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[7]: [OFFTOP]Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.02.07 07:19
Оценка: :))
Здравствуйте, Mirrorer, Вы писали:

M>Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.


Да не, ты чего , какое при смерти — Delphi for PHP ещё всем покажет
Re[10]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.02.07 11:53
Оценка: +2
Здравствуйте, minorlogic, Вы писали:
M>>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?
VD>>Это где же такое написанно?
M>C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.
Это не решение. Это и есть проблема. Во-первых, понять вот эту концепцию виртуального и невиртуального наследования крайне трудно. А главное — зачем? Вот покажите мне хоть один жизненный пример смешивания виртуального наследования с невиртуальным! Все эти правила призваны всего лишь разрулить неопределенности, возникающие из-за самой идеи двух видоа наследования. Никакой практической полезности в них нет.

M>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Задумчиво...
От: IT Россия linq2db.com
Дата: 01.03.07 05:24
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое"


Про лень забыл.

ГВ> и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.


Гена, ты когда сам себе вместо "Спи, Генульчик, спи, родной" говорил "Встать, урод, проснись, скотина"?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 01.03.07 07:56
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Те ты считаешь что С++ простой и мощьный?


Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?
Re[16]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.03.07 09:12
Оценка: +1 :)
Здравствуйте, igna, Вы писали:
I>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?
совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Не пора ли нам перейти на D
От: Disappear  
Дата: 01.03.07 09:59
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft. Если говорить о CLI, то потенциально, нет. Но серьезной реализацией интерпретатор не считается. В Моно тоже имеется компиляция. В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.


M>>З.Ы. В своем посте под .Net я подразумевал именно CLR, а не конкретно MS .Net. возможно из-за этого путаница возникла.


VD>И в очередной раз ошибаешся.


То, о чем вы тут говорите больше смахивает на демагогию. Нужно смотреть на реальное положение вещей — .NET это CLR и так будет всегда.
Без VM из всех ваших сверхмощных языков уйдет вся их сверхмощь — рефлекшены, дефрагментатор памяти, runtime inline и практически все то, ради чего тут загибали пальцы.
Re[2]: Задумчиво...
От: Disappear  
Дата: 01.03.07 10:14
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Disappear,


ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.


Люди не хотят конструктивно рассуждать. В основном те, кто подняли тут эти термины сами же им были подвержены.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:19
Оценка: -2
Здравствуйте, deniok, Вы писали:

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




VD>>Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что. Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.


D>Не, Влад, тут всё прозрачно. Применение функции имеет больший приоритет, чем любой оператор, поэтому в "factorial n — 1" сначала применится функция, а потом произойдёт вычитание. Другое дело, что из-за нетерминированной рекурсии получается, что должно вычисляться (n*(n*(n*(...)-1)-1)-1) — типичная экспансия Y-комбинатора.


Собственно что "нет"? Об этом я и говрю. Просто в отличии от тебя, я "знаю" Хаскель по паре введений прочитанных мной. Серьезно его не использовал. Но попытки балоства с языком показали, что я сразу начинаю перестраховываться и все брать в скобки (часто безосновательно).

Тем кто съел собаку на Хаскеле, может это уже и кажется нормальным. Но это не более чем привычка, а вообще, это не интуитивно.

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

D>А вот внешние скобки в примере — действительно лишние, из тех же самых соображений приоритета применения функции перед оператором (умножения). Так что версия факториала от Another junior Haskell programmer без лишних скобок такова

D>
D>fac 0 = 1
D>fac n = n * fac (n-1)
D>


Проблема в том, что даже эти скобки требуют немалого объяснения. Ведь ни один С-шник без специальной подготовки не допрер, до того, что речь идет о передачи кортежа или даже о взятии выражения в скобки. Для них это будет синтаксис вызова метода, а это не так.

D>Вообще, в Хаскелле круглые скобки используются в выражениях по своему прямому математическому назначению


Вот это не правда. Никакого математического назначения туту нет и в помине. Это чистые проблемы Хасклеля с приоритетами. Такие проблем есть толко ML-подобных языках.

Да и математик уже давно не имеет прямого отношения к программированию. Так что не стоит на нее пенять. А том ожно начать вспоминать, что Ричи выбирая семантику вызова фукцнии в С как раз использовал математическую нотацию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:12
Оценка: -2
Здравствуйте, lomeo, Вы писали:

VD>>
VD>>fac 0 = 1
VD>>fac n = fac (n-1) * n
VD>>


VD>>насколько я понимаю уже нельзя.


L>Можно. Говорю же у функций приоритет больше, чем у операторов.


Вот только обычны человек прочтет это код как "fac ((n-1) * n)"
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:45
Оценка: -1 :)
Здравствуйте, lomeo, Вы писали:

L>Таких примеров — масса. И это не зависит от языка.


Зависит...
Одни языки (точнее их авторы) пытаются подстраиваться под пользователя. Их авторы проводят эксперементы... наблюдают... Если видно, что люди в массовом порядке делают такие-то предоположения, то подстраивают язык под эти предположения (чтобы они были верны).
Другие отталкиваются от собственных представлений о чистоте и т.п. Они считают, что все вокруг должны заучить их умолчания и после этого наступит счастье.
Вот я приверженец первого подхода.

Собсвтенно С++ (при всех его ошибках) создавался именно по первому приципу. И в итоге завоевал популярность. Все ошибки не помешали ему это сделать. Думаю это произошло потому, что в то время конурирующие яызки имели намного больше ошибок и били куда менее интуитивны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 21:25
Оценка: +2
Здравствуйте, VladD2, Вы писали:

WH>>Он хочет спросить: Почему вывод типов работает только для локальных функций?


VD>Ну, тогда он очень плохо формулирует свои мысли.


Я, напротив, удивлён твоему непониманию такой простой мысли.

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


Это несерьёзно. Вроде как вывод типа был призван объединить всё то лучшее, что есть в статических и динамических подходах.

VD>Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций.

VD>Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.

Позволяет упрощать выявление ошибок, может быть, но связано это не с этим. Причины совершенно другие. Если я пишу функцию, реализация которой мне изначально понятна, я записываю её без типа. Если я пишу функцию, которую сходу написать не могу, то часто пользуюсь методом — "писать от типа". Это очень удобно, потому что тип более-менее ясен, так как я представляю что должна делать функция, а уж из типа вывожу реализацию. Если я пишу код, который предполагаю обработать haddock'ом, то, конечно, пишу типы, чтобы проставить к ним комментарии. Если мне нужен не общий тип для этой функции, а более специфичный (например, это связано с целью оптимизации), то я пишу нужный тип. С целью повышения скорости компиляции типы может и пишут, но я про такое не слышал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Не пора ли нам перейти на D
От: Трурль  
Дата: 02.03.07 07:05
Оценка: :))
Здравствуйте, deniok, Вы писали:

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


D>Я, конечно, не знаю все 200 с хвостиком существующих языков, но по-моему "проблема с приоритетами" операторов есть в любом из них (кроме Lisp-подобных, где всё префиксно)

D>Выражение типа

D>
D>1+2*3
D>


D>во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета.


  1+2*3
7
  2*3+1
8

Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка: +2
Здравствуйте, lomeo, Вы писали:

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


Не было бы. Было бы значительно хуже. Вывод типов и так часто приводитк к ошибкам которые не так то просто понять. Стандартная ситуация когда компилятор показывает в одно место, а реальная ошибка в другом. Если все лакализовано в методе, то проблема решается относительно легко. Если нет, то можно ее искать очень долго. Плюс ошибки не проходят в другие типы и модули. В итое все выльется в то, что для поиска ошибко компиляции потрбуются гуру которые один хрен будут решать проблему рассавляя декларации типов.

Для IDE это тоже решение отличное, так как иначе при каждом чихе прийдется перекомпилировать всю программу.

L>Полагаю, не это было причиной отказа от глобального вывода типов


Пологаю одного раза должно быть достаточно, что бы запомнить, что отаказа не было. Был выбор на основе некоторых соображений. Лично я этот выбор поддерживю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 09:05
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:


К>>Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример),


VD>Ну, значит могу? На том и порешим.


Нет, в данном случае половина решения не есть целое решение.
Как пример, для того чтобы гарантировать переключаемость между потоками/процессами надо инструментировать дотнетный/джавовский код, чтобы избавиться, например, от бесконечных циклов, отъедающих всё время процессора и не дающих "воздуху" другим вычислениям.
Твоё предположение что ты можешь сделать параллельность аналогичную Эрлангу (до софтриэлтайм гарантий) на базе CLI — домыслы, на том и порешим.
Будет реально работающая библиотека или что-то подобное — будет смысл вернуться к обсуждению, а так, извиняйте.
Re[23]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 19:07
Оценка: -1 :)
Здравствуйте, lomeo, Вы писали:

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


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


VD>>Не было бы. Было бы значительно хуже.


L>То, что ты написал дальше — это хуже для дизайнеров этого языка.


Конечно, конечно. Ты прав потому что ты не можешь быть не прав. Смотри и все месные извра... эээ неформалы с тобой согласны. Зачем так волноваться?

L> Это не проблемы пользователя. Дизайнеры не могут решить эту проблему и говорят — ок, пусть вывод типов будет только локально, это связано с тем, что сделать то-то и то-то трудно/неэффективно/чтонибудьещё.


Конечно, конечно. Ты ведь видишь правду насквозь. Это несомненно паронормальный дар. Только извини, я в паранормальные явления не верю.

Главное не ясно что ты пыташся доказать. Что этот язык недостаточно хорош для тебя? Да, это так. Это примитивный язык предназначеный для написания обычных программ для реального мира. Тренировать им мозг невозможно. Но для этого есть Хаскешь. Пользуйся им и твой мозг всегда будт как вареное яйцо.

L> От того, что у ограничения есть объяснение его существования оно не перестаёт быть ограничением. Как отсутствие перегрузки в Хаскеле. Его ведь тоже можно объяснить, нес па?


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

Если рассматривать Хаскель как игрушку для ученых-исследователей — это как минимум не плохо. Им плевать практических проблем взаимодействия с С++-подобныеми языками. Если язык рассматривается как претендент на звание мэйнстрим-языка, то это несомненно очень плохое решение.

Как я понимаю Хаскель его разработчиками считается исселедовательским, так что никаких противоречий нет. Точно так же Немерле его разработчикам рассматривается как претендет на звание мэйнстрим-языка. Так что предпочтения его авторов тоже вполне разумны, по карайней мере на мой взгляд.


L>Что касается "был выбор" то вообще не понятно.


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

L> Ну, выбрали наличие в языке этого ограничения, ну есть для этого причины, и что? От того, что выбор был оно перестаёт быть ограничением?


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

Если твой мозг не может этого понять, то я умываю руки. Ты никогда не станишь тем кто спосбен создать что-то нове.

L>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


Именно так. Верь в это. Тебе сразу станет лугче.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 22:40
Оценка: -2
Здравствуйте, lomeo, Вы писали:

VD>>Ну, что же... Ответов на прямые вопросы нет. Аргументов тоже. Наличиствует только мелкая демогогия и переход на личности.


L>Прямой вопрос — ты умеешь общаться без перехода на личности?


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

L>Мне, знаешь ли, неприятно, когда мои аргументы опровергают тем, что это мол, мои аргументы, а значит априори ложны, бессмысленны и неинтересны.


Какие твои аргументы это уже переходит все пределы. Ты разводишь флуд и демагогию в 70% своих сообщений. Мне уже давно вообще не хочется с тобой не о чем говорить. Ты и еще EvilChild — это две личности при назговоре с которыми у меня все мысли почему-то все время фокусируются на вопросе вменяемости этих личностей.

L>Считай, но это неправда, аргументов полный карман, если они тебе интересны, достаточно всего лишь вежливо о них спросить.


Серьезно? Ой не верю. Тога вернись к этому
Автор: VladD2
Дата: 02.03.07
сообщению и попытайся ответить на те претензии которые к тебе предявили, а не банально поскипав их переходить на личности. Уверне, что этого не произойдет и я сново увижу тонную флуда, демагогии и неадекватности.

Извини, но дискутировать можно только с теми кто адекватен, а у тебя я это не наблюдаю. А по сему мне просто не интересно с тобой общаться. Конструктива ведь нет и не предвидится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 03.03.07 00:33
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


VD>>>
VD>>>fac 0 = 1
VD>>>fac n = fac (n-1) * n
VD>>>


VD>>>насколько я понимаю уже нельзя.


L>>Можно. Говорю же у функций приоритет больше, чем у операторов.


VD>Вот только обычны человек прочтет это код как "fac ((n-1) * n)"


Чего ? Любой человек, кто в школе хотя бы немного видел математику (я думаю, что все-таки подавляющее большинство людей у нас в стране имеет хотя бы среднее образование) читает конструкции вида sin(x-1)*x совершенно однозначно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 03.03.07 12:33
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Ты и еще EvilChild — это две личности при назговоре с которыми у меня все мысли почему-то все время фокусируются на вопросе вменяемости этих личностей.


И ты ещё здесь кого-то упрекаешь в переходах на личности?
Я здесь каким боком?
Или топик "Внутренние проблемы Влада — помогите кто чем может"?
Если есть проблемы с фокусировками мыслей — обратись в профильный форум, в этом обсуждают другие вещи.
now playing: Quinoline Yellow — Sealed
Re[19]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 10.04.07 14:42
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

C>Ты можешь примерно набросать идею своей VM? Сейчас снова ожил проект http://hlvm.org/ — это как раз проект создания обобщенной виртуальной машины на базе LLVM. Может им полезно будет.

Не будет.
Ибо

focusing first on dynamic languages like Python and Ruby

А я считаю Python, Ruby и тп ошибкой природы. С++ я тоже считаю ошибкой природы.
Так что мои идеи совершенно несовместимы ни с LLVM ни с HLVM.

C>Благодаря ей у нас есть HotSpot в JVM. В теории, можно было бы заменить на многостадийную JIT-компиляцию, но сложность уже намного больше будет.

HotSpot в морг. Ибо не смотря на все потуги он не помогает жабе работать быстрее С++

C>Реально помогает, тем не менее.

Чем?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 09.04.07 03:37
Оценка: 50 (1)
Здравствуйте, gear nuke, Вы писали:

C>>Тут фича в том, что для x86 это достаточно просто сделать.

GN>Реальная причина другая — делать это требует рынок. Есть более простые способы получить лучшую произволительность, пример Itanic'а показал их жизнестойкость. Если MS доведут Сингулярность до ума (а они это сделают в том или ином виде, пусть и под другим названием) — такое железо появится. Фишка в том, что гигагерцы там не обязательны, для десктопа хватит подобного проца с частотой в сотню-другую мегагерц, для телефонов — подавно.
Какие "другие пути"?

x86 сейчас по совокупности показателей — самый быстрый, разве что новые POWER от IBM могут соперничать. По каким-то показателям другие процессоры могут обходить x86 (тот же Itanium может делать больше параллельных операций, но x86 его побьет в последовательном коде).

100-200Мгц для десктопа — в любом случае фантастика. Я работаю с MIPS-процессором на 175MHz (в ADM5120P, если кому интересно), работает быстрее Pentium'а аналогичной частоты, но не сильно быстрее.

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

C>>А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.

GN>Зачем регистры, там же стековая машина.
А стековая машина в железе неэффективна. Точнее, она будет очень простой и иметь хорошее отношение скорость/энергопотребление, но вот быстрой она не будет. ФОРТ-процессоры уже это проверили.

GN>Процессоры оптимизируют под языки. Как Керниган и Риччи заменили синтаксис ассемблера PDP на более "красивный" кросплатформенный, так и понеслось развитие в этом направлении. И вошло в замкнутый круг. Вот вроде бы революционная технология HT — попытка параллельного выполнения команд одним ядром. Но это плохо вписывается в модель PDP, поэтому реально даже тормоза оказылись.

Нормально оно вписывается.

GN>А если бы повсеместно писали на Erlang, кто знает, нужны ли бы были многоядерные процы с изоляцией ядер и громоздким механизмом межпроцессорного взаимодействия, не лучше ли иметь проц с большим набором регистров, каждый из котрых может служить и instruction pointer.

Были и такие варианты — тот же Itanium (там за сотню регистров, AFAIR). Swap между любым регистром и IP там тоже возможен.

Вот только ВСЕ современные процессоры построены по конвеерному принципу и смена IP ведет к перезагрузке ВСЕГО контейнера, а это медленно. А еще, не дай бог, попадешь на cache miss...

Поэтому в современных x86 есть очень крутой и мощный branch predictor и планировщик, которые как раз отвечают за большую часть сложности процессора. Если их выбросишь — получишь тормозной процессор.
Sapienti sat!
Re[3]: Nemerle - еще вопрос
От: Mirrorer  
Дата: 27.02.07 10:37
Оценка: 14 (1)
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.

Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re: Nemerle
От: Kisloid Мухосранск  
Дата: 27.02.07 11:15
Оценка: 14 (1)
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>1. Что слышно насчет реализаций под линукс, и/или свободных реализаций? Когда ожидать?


Вообще то, он изначально разрабатывается под Mono (свободная реализация .net, есть и под Линукс, Винду, МакОС). Существует уже достаточно давно.

ДГ>2. И во что дело упирается — в нормальную VM? Не верю. Что им мешает в натив компилять?


А зачем в натив? Выбор .net вполне разумен, получаем нахаляву всю FCL и все остальные плюсы .net'а.
Если бы в натив компилявили, то все библиотеки пришлось бы писать самим с нуля, бек-енд для кучи разных платформ, а так, только IL.

ДГ>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?


MonoDevelop — кроссплатформенно.

ДГ>4. Вообще, какова текущая ситуация? Что куда компилируется и где это 'куда' может работать?


Насколько мне известно дело уже близится к релизу первой версии.
Все компилириуется в IL.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[5]: Nemerle - еще вопрос
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 11:26
Оценка: 14 (1)
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.

M>>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.

ДГ>Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?


На текущий момент — да. Теоритически не исключена возможность прикручивания других бэкендов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[3]: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка: 14 (1)
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.


Это не предмет веры. Никаких "объектных либ" в природе не существует.
Существуют сборки. Они одинаковы (бинарно) для Моно и дотнета. Сборка скомпилированная из C#-искходников без проблем используется из Nemerle и наоборот.
Все что нужно сделать — это добавить ссыку на сборку. Сделать это можно или в Студии с помощью соотвествующего диалога, или из командной строки. Например, чтобы подключить сборки WinForms (из .Net Framwork) написанную на C# к проекту на Немерле нужно вызвать компилятор следующим образом:
ncc.exe /r:System.Windows.Forms.dll test.n

Собственно проект Интеграции со Студие состоит из проектов на C# и Nemerle взаимодействующих между собой. Никаких проблем при этом не возникает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 18:11
Оценка: 12 (1)
Здравствуйте, VladD2, Вы писали:

L>>Использование локальной функции.

VD>А в чем заключается это ограничение? Это наоборот полезная фича. Изъясняйся, плиз, развернутее.
Он хочет спросить: Почему вывод типов работает только для локальных функций?
Отвечаю: Иначе компилироваться будет ну очень долго.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Не пора ли нам перейти на D
От: Трурль  
Дата: 02.03.07 08:25
Оценка: 8 (1)
Здравствуйте, deniok, Вы писали:

D>ну значит не во всех Что за зверь?


J,K и вообще любой потомок APL. Ибо инфиксные операторы там есть, а приоритетов нет.
Re[16]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 15:42
Оценка: 7 (1)
Здравствуйте, VladD2, Вы писали:

VD>Это пока (лично для меня) вопрос будущего. Пока что параллельность была практически ненужна. Но конечно в будущем это стаенет одной из самых актуальных тем.

VD>Вот только лино я хотел бы чтобы язык позволял бы добавить нужную поддержку имеющимися срествами (в виде фрэйморка).
Не реально.
Эффективно и надежно паралельность можно сделать только на уровне ВМ. Никаким метапрограммированием хорощо паралельность не сделать.
Как минимум по тому что нужно очень сильно корежить менеджер памяти для того чтобы он хорошо работал в условиях многопоточности.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 27.02.07 11:14
Оценка: 6 (1)
Здравствуйте, Disappear, Вы писали:

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


Ок. Давай сделаем так. Ты приводишь пример теста, который тебя удовлетворит, методику тестирования, критерии приемки, реализацию на с++. А со своей стороны обещаю сделать реализацию под .NET. И поглядим.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:14
Оценка: 6 (1)
Здравствуйте, igna, Вы писали:

I>
ie>>>>factorial 0 = 1
ie>>>>factorial n = n * (factorial (n-1))
I>


VD>>К примеру, сможешь объяснить, что будет если убрать одни из скобок?


I>Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?


Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что. Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.

В отличии от Хаскеля, Nemerle имеет семантику близкую к С++, что приводик к тому, что для большинства C++/C#/Java-программистов воспринимают его совершенно интуитивно (конечно после того как они изучают расширенные констркции вроде паттерн-матчинга).

Что до многословности, то Nemerle поддерживает Python-оборазный синтаксис, так что этот пример можно записать так:
Factorial(n : uint) : ulong
  | 0 => 1
  | _ => n * Factorial(n - 1)

или даже так:
factorial(n)
  | 0 => 1
  | _ => n * Factorial(n - 1)

если использовать локальные фукнции и их вывод типов.
Это уже мало чем отличаетя от Хаскеля (даже короче на одни идентификатор). Но опять таки этот выигрыш эфимерен. Учитывая что большинство программистов имеет C++/C#/Java-образование я считаю скобки предпочтительными.

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

Ну, и еще один факт. Языки вроде Хаскеля, т.е. использующие систему типов Хиндли-Миллера не поддерживают некоторые возможности С-подобных языков. Так для них закрыты неявные прведения типов, перегрузка фукнций и т.п. Немерле поддерживает все эти фишки, что не может не сказываться на дизайне языка. В частности становится недоступна форма записи продемонстрированная в Хаскеле.

Так что вопрос "что лучше?" не является примитивным. Возможно в примитивных случаях запись Хаскеля хороша. Но если учесть все "но", то лично я без сомнения отдаю предпочтение подходу Немерла. Хотя и отдаю себе отчет, что тут немало влияет банальная вкусовщина.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 11:03
Оценка: 6 (1)
Здравствуйте, ironwit, Вы писали:

VD>>Если нужен другой язык. Не конкурент С++, а язык его заменяющий. То определись что ты хочешь от этого языка. Вот когда я сформулировал свои требования, то оказалось, что ближе всего к их воплощению подошел именно Nemerle.


I>можно о выделенном подробнее?


Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:
1. Статическую типизацию.
2. Компилируемый (не интерпретируемый).
3. Типобезопасность.
4. Модульность.
5. Компонентную модель (динамическая загрузка и выполнение кода из бинарных библиотек).
6. Выразительный (код должен быть относительно компактным и легко читаться).
7. Метапрограммирование (возможность встраивать DSL-и проямо в код на этом языке, и возможность
генерировать код по некоторым входным описаниям (например, обертки для таблиц БД)).
8. Мултипарадигности (поддержка ООП, ФП, МП).
9. Поддеркжка проектов большого размера.
10. Рефлексия времени выполнения.
11. Рефлексия времени компиляции.

VD>>А Ди это всего лишь клон С++ развивающий его неверные решения.


Не очень то он клон. Исползует те же идеи — да. Но это другой язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 01.03.07 13:07
Оценка: 6 (1)
Здравствуйте, VladD2, Вы писали:



VD>Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что. Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.


Не, Влад, тут всё прозрачно. Применение функции имеет больший приоритет, чем любой оператор, поэтому в "factorial n — 1" сначала применится функция, а потом произойдёт вычитание. Другое дело, что из-за нетерминированной рекурсии получается, что должно вычисляться (n*(n*(n*(...)-1)-1)-1) — типичная экспансия Y-комбинатора.

А вот внешние скобки в примере — действительно лишние, из тех же самых соображений приоритета применения функции перед оператором (умножения). Так что версия факториала от Another junior Haskell programmer без лишних скобок такова
fac 0 = 1
fac n = n * fac (n-1)


Вообще, в Хаскелле круглые скобки используются в выражениях по своему прямому математическому назначению — для группировки операций (и лишние не возбраняются, но и не вносят никакого дополнительного смысла). Ну и для кортежей, конечно, поскольку этот случай легко выделить по запятым, разделяющим элементы.
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка: 4 (1)
Здравствуйте, ironwit, Вы писали:

VD>>Мне нравится идея универсального инструмента который можно тоноко заточить под конкретную задачу/предметную область. Потому собственно я и обращаю внимание на метапрограммирование.


I>понятно. спасибо. значит не показалось


Не показалось. Я вообще, во многом разделяю идеи Страуструпа. Просто я несколько иначе вижу их реализацию и приоритеты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle
От: Дм.Григорьев  
Дата: 27.02.07 12:28
Оценка: 3 (1)
Здравствуйте, Kisloid, Вы писали:

K>Вообще то, он изначально разрабатывается под Mono (свободная реализация .net, есть и под Линукс, Винду, МакОС). Существует уже достаточно давно.


В Mono реализованы те же библиотеки классов, что и у MS? Интерфейс, сети и т.п.? Сорри за навязчивость, но сам я с .NET не работал.
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[4]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 22:03
Оценка: 2 (1)
Здравствуйте, Alxndr, Вы писали:

A>В каких, например, кроме Java/C#? И это ничего не подтверждает.


Я могу назвать только один язык где еще есть множественное наследование. Этот язык — Эфил. Больше я подобных не знаю.

Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития. Единственное разумное его применение — это подключение реализации интерфейсов. Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны. Плюс к тому же МН реально усложняет компилятор. Всесто него сеондя в современных языках используют одиночное наследование (для выстраивания единой иерархии реализации) в сочетании с МН для интерфейсов и (совсем новым веянием) трэйтсами/миксинами. D как раз поддерживает все это. Так что в этой области он совершенее С++.

В общем, то D совершенее С++ во всем кроме раскрученности и количества бибоитек. Но:
1. В следствии парадокса Блаба
Автор: VladD2
Дата: 23.11.06
, чтобы это понять надо серьезно изучить D.
2. C++ники не будут использовать D потому что они ещё живы
Автор: Lazy Cjow Rhrr
Дата: 12.02.07
.
3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 02.03.07 10:08
Оценка: 2 (1)
Курилка wrote:
>> > О изменениях VM пока что можно только мечтать.
> C>Я сейчас *финансирование на CLR для LLVM провожу*. Так что я могу и
> мечтать
> А можно расшифровать выделенное?
Собираюсь делать небольшой проект — портирование CLR на LLVM. Пока для
него финансирование делаю.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: Не пора ли нам перейти на D
От: Disappear  
Дата: 28.02.07 09:49
Оценка: 1 (1)
Здравствуйте, Tilir, Вы писали:

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


T>Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL...


Что же тогда сделал Хейлсберг, что всех так проперло (до сих под дым из ушей)?
Подмножества — это как раз то страшное зло, от которого успешно ушли создали D.

T>Кстати, я так и не дождался от вас конкретного примера, чего собственно изначально просил. Насчёт кучи всякой радости: зачем она нужна и радость ли это (в кучах не только радость бывает). Без ссылок на книги. Примерно как я вам привёл два куска актуального и нужного кода.


Если вам нужны примеры, видимо вы не знакомы с языком. Там все очевидно без глупых примеров.
Re[2]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 26.02.07 19:56
Оценка: :)
Здравствуйте, demi, Вы писали:

D>И тут взглянул на код C++ и понял в каком я дерьме копаюсь...


Зачем же было дерьмо писать?
Re[2]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 20:42
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>

26.02.07 23:29: Перенесено модератором из 'C/C++' — Хитрик Денис


VD>2 Хитрик Денис: [skipped]


Надо думать, на тебя запрет на открытую переписку о модерировании не распространяется?
Re[3]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 26.02.07 22:30
Оценка: :)
Здравствуйте, Alxndr, Вы писали:

A>Надо думать, на тебя запрет на открытую переписку о модерировании не распространяется?


Классно подколол.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 22:32
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Что же до любьви к прекрасному... то очень советю покурить Nemerle.


"И тут Остапа понесло"
Re[4]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 23:23
Оценка: :)
Здравствуйте, Alxndr, Вы писали:

A>"И тут Остапа понесло"


Можно спросить уважаемого Остпа, что он такого ел с утра, что его с этого понесло?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 27.02.07 06:26
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:

VD>
VD>macro CompileTimeFactorial(n : uint)
VD>{
VD>    def res = Util.Factorial(n);
VD>    <[ $(res : ulong) ]>
VD>}

VD>module Util
VD>{
VD>  // 
VD>    Factorial(n : uint) : ulong
VD>    {
VD>        | 0 | 1 => 1
VD>        | _     => n * Factorial(n - 1)
VD>    }
VD>}
VD>


И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?
Re[4]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 27.02.07 08:16
Оценка: :)
Здравствуйте, ie, Вы писали:

ie>Интересно, а история слыхала случаи о отправке модератора в бан?


Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.
Re[2]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 27.02.07 08:34
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Но снеся эту тему сюда ты неизбежно подменил тему спора, так как рано или подзно (рано с моей помощью, по позже без нее) тема все равно превратится в "Казалось бы причем тут Nemerle".


Вот именно. А нельзя ли попросить модератора вернуть тему взад? (Нет, это не обсуждение, это намек на просьбу.)

Я всерьез. Автор похоже хотел обсудить именно D vs. C++. Может быть это нужно было делать в "Философии" помянув и C++ в названии темы, но с имеющимся названием неудивительно, что здесь "рано или поздно" появилось кое-что не имеющее отношение к "D vs. C++".
Re[3]: Nemerle - еще вопрос
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 10:19
Оценка: +1
Здравствуйте, Дм.Григорьев, Вы писали:

К>>Насколько я понимаю, всё это определяется платформой на которой работает немерле — .Net, думаю что есть в нём, ты в курсе.

ДГ>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.

Дык дело тут не в конкретном языке а в понятии сборки в .NET. Уж коли почти весь FCL написан на C# и Nemerle, а так же еще добрый 10ок языков, их активно юзает, никаких препятсвий нет и быть не может.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 10:29
Оценка: :)
Здравствуйте, Mirrorer, Вы писали:

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


D>>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. Никакие технологии, и отчаянные попытки маркетологов не убедят в обратном.

M>JIT компиляция ?
M>Пример. Имеем программу работающую на 486 древнем. Not a big deal.
M>При первом запуске метода байткод дотнетовский JITнется в native. и последующие вызовы будут выполнятся уже без Jit компиляции.
M>С++ программа же скомпилирована со всеми потимизациями 486-го и работает быстрее. ТАк?

M>Теперь берем те же программу, переносим на Pentium IV.

M>Внимание вопрос. Сможет ли с++ программа скомпилированная под 486 использовать фишки четвертого пня для ускорения работы ?
M>А та же дотнетовская программа сможет. Потому что JIT сгенерирует native код для той платформы на которой он будет выполнятся.

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

Тормознутость Java и .NET видно даже на глаз, что там говорить и плеваться.
Re[5]: Не пора ли нам перейти на D
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 27.02.07 10:31
Оценка: +1
Здравствуйте, Disappear, Вы писали:

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


Пиши на BCB — там finally есть
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Не пора ли нам перейти на D
От: Tilir Россия http://tilir.livejournal.com
Дата: 27.02.07 12:00
Оценка: :)
Здравствуйте, Disappear, Вы писали:

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


D>
D>template factorial(int n : 1)
D>


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

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

BEGIN_MESSAGE_MAP(CTryListViewView, CListView)
  ON_COMMAND(ID_SHOWALL, &CTryListViewView::OnShowall)
  ON_COMMAND(ID_SHOW_DISTINCT, &CTryListViewView::OnShowDistinct)
  ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, &CTryListViewView::OnNMCustomdraw)
  ON_COMMAND(ID_SHOW_ABSENT_MIS, &CTryListViewView::OnShowAbsentMis)
  ON_WM_KEYDOWN()
END_MESSAGE_MAP()


Второй пример — активно использует множественное наследование (фрагмент реального ActiveX-контрола на ATL)

class ATL_NO_VTABLE CExtPanel :
    public CComObjectRootEx<CComSingleThreadModel>,
    public CStockPropImpl<CExtPanel, IExtPanel>,
    public IPersistStreamInitImpl<CExtPanel>,
    public IOleControlImpl<CExtPanel>,
    public IOleObjectImpl<CExtPanel>,
    public IOleInPlaceActiveObjectImpl<CExtPanel>,
    public IViewObjectExImpl<CExtPanel>,
    public IOleInPlaceObjectWindowlessImpl<CExtPanel>,
    public ISupportErrorInfo,
    public IConnectionPointContainerImpl<CExtPanel>,
    public CProxy_IExtPanelEvents<CExtPanel>,
    public IPersistStorageImpl<CExtPanel>,
    public ISpecifyPropertyPagesImpl<CExtPanel>,
    public IQuickActivateImpl<CExtPanel>,
#ifndef _WIN32_WCE
    public IDataObjectImpl<CExtPanel>,
#endif
    public IProvideClassInfo2Impl<&CLSID_ExtPanel, &__uuidof(_IExtPanelEvents), &LIBID_AtlPanel3Lib>,
    public IPropertyNotifySinkCP<CExtPanel>,
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctly
    public IObjectSafetyImpl<CExtPanel, INTERFACESAFE_FOR_UNTRUSTED_CALLER>,
#endif
    public CComCoClass<CExtPanel, &CLSID_ExtPanel>,
    public CComControl<CExtPanel>
{
...
}


Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?

Или вы предлагаете хором перейти на VCL?
Re[2]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка: :)
Здравствуйте, Socrat, Вы писали:

S>Предлагаю устроить новый флейм "D vs Oberon".


Боюсь, D сольет по некоторым показателям.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 13:17
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


D>>Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.


VD>Не у всех конечно. Но я то говорил о закономерности. А она на лицо.


VD>Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.


Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.
Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 13:38
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


D>>На D так:

D>>
D>>template factorial(int n)
D>>{
D>>  static if (n == 1)
D>>    const factorial = 1;
D>>  else
D>>    const factorial = n * factorial!(n-1);
D>>}
D>>


VD>Ну, вот и подумай насколько это глупый код!

VD>Ты не сможешь его вызвать из программы. Он доступен только во время компиляции.
VD>Я же свой код могу вызвать как во время компиляции, так и во время исполненения.
VD>Это будет один и тот же код. Более того, он будет скомпилированным! И выполнится очень быстро.
VD>Твой же код будет интерпретироваться компилятором. Конечно factorial-а это не проблема. Но мы же говорим не о нем?

Не понял что подразумевается под словом "использовать"?
Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

VD>В том-то все и дело. Факториал — это примитившена.


VD>Тут (на этом форуме) как то народ попытася повторить прмитивнеший пример реализованный на Немерле — реалзовать автоматический генератор паттерна "Абстрактная фабрика". И что ты думашь? Ни на С++, ни на D этот пример полностью поторить так и не удалось!

VD>http://rsdn.ru/Forum/Message.aspx?mid=2311589&amp;only=1
Автор: VladD2
Дата: 21.01.07

VD>Что-то удавалось, но на 100% все равно не получилось. Фабрика была или статичная, или ограниченная.
VD>И это в том время как у парня реализовавшего фабрику на макросах Немерле ушло на ее реализацию не более часа времени.

Опять Немерле.
Re[9]: Не пора ли нам перейти на D
От: Слоноежик  
Дата: 27.02.07 14:19
Оценка: +1
Здравствуйте, VladD2, Вы писали:

[вытоптано]

VD>и на Nemerle:

VD>
VD>Factorial(n : uint) : ulong
VD>{
VD>    | 0 | 1 => 1
VD>    | _     => n * Factorial(n - 1)
VD>}
VD>


[тут тоже немного затоптано]

VD>На Nemerle мы получили просто функцю. Мы можем вызвать ее в программе как любую другую. Теперь чтобы вычислить эту функцию во время компляции мы просто помещаем ее вызов в макрос:

VD>
VD>macro CompileTimeFactorial(n : uint)
VD>{
VD>    def res = Util.Factorial(n);
VD>    <[ $(res : ulong) ]>
VD>}
VD>

VD>в котором мы производим вычисление и помещаем результат вычисления код генерируемый макросом.

Вот пример эквивалентного кода из D


ulong factorial(uint index)
{
    if (index == 0 || index == 1)
    {
        return index;
    }
    return index * factorial(index - 1);
}


и макроса который заставляет вычислить ф-цию в время компиляции

template eval(A...) { alias A eval; }

//использование
static result = eval!(factorial(5));


И в отличии от Nemerle не надо для каждой функции писать макрос обертку.


VD>В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.

VD>То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.
Ну D это уже не относится.
для забивания гвоздя надо выбирать правильный микроскоп.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка: -1
Здравствуйте, Disappear, Вы писали:

VD>>Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.


D>Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.


А я где-то такое говорил? Тебе явно померещилось.

D>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.


Я не знаю что такое "разработка ПО мирового масштаба". Для разработки же просто ПО используются разные языки. И С++ несомненно удерживает второе место после Явы по массовости использвания.

Только я вот понять не могу, а что ты так удивляешся в том, что люди не принимают какой-то там Ди? Пойми в их догматах ПО пишут в основном на С++. А какой-то там Ди — это такая малпонятная игрушка от которой не ясно что и ждать то.

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

Все отличие тебя от них в том, что ты немного задумался над тем, что происходит. Но как только тебе попробовали показать "как глубока эта заячья нора" ты сразу же решил, что лучше зашорить глаза и оставаться жить в своем мире.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 27.02.07 17:28
Оценка: :)
Здравствуйте, Disappear, Вы писали:

I>>И вообще, круто и не для средних умов.


D>Очень убедительно C# программисты бы это слышали


А мы слушаем, слушаем... И записываем!!!
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[12]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 17:59
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


D>>Я ничего не имею против Nemerle. Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.


VD>Ну, и чем же Nemerle тут не подходит?


D>>Вот и спрашивается — причем тут Nemerle.


VD>Дык это как раз статически тпизированный язык со статической компиляцией (что в общем-то бред, так как компиляция она и Африке компиляция).


VD>Что касается конкуренов С++, то для меня это само по себе смешно. С++ маральный урод. Он устарел еще 10 лет назад. Его испоьзуют не потому что он лучий, а потому, что к нему привыкли и потому что вокруг него море фобий. Конкуренты ему попросту не нужны.


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


VD>Можно зайти и с другой стороны и подумать о том, что не нравится в С++. Сформулирвоать требования от противного, тык-сызыть.


Сейчас я понял, что считаю неверными решениями все ваши утверждения по поводу языков.
На основе этого можно сформулировать список требований
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 18:46
Оценка: +1
Здравствуйте, Disappear, Вы писали:

VD>>Все отличие тебя от них в том, что ты немного задумался над тем, что происходит. Но как только тебе попробовали показать "как глубока эта заячья нора" ты сразу же решил, что лучше зашорить глаза и оставаться жить в своем мире.


D>Почему вы так часто переходите на личности?


Потому что ты споришь со своим отражением. Как, позволь узнать, говорить об этом явлении не упоминая тебя?

D>Этот и другие языке мне интересны чисто из академических интересов.


Хм. "Не пора ли нам перейти на D" это академические соображения?

D> Для работы, по прежнему нет ничего лучше старых добрых инструментов — это дело привычки.


Значит ты сам ответил на свой вопрос "не пора". Точнее "всегда — нет".

D>Речь шла, о возможности постепенного перехода к использованию других инструментов.


А как же "нет ничего лучше старых добрых инструментов"? И зачем тогда новые если старый — добрые?

D> И что бы дала эта возможность.

D>По сути дела, то что было высказано в этой ветке, могло бы нести обьективный характер — за и против. Но, как оказалось, многие не считают, что можно обсуждать такие темы, потомучто в массах преобладает "эффект блаба", народная истерия, костность дедушкиной бороды или что еще там...
D>Быть может, люди не такие тупые, как Вы о них думаете? И даже С++ программисты.

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

И лично меня синдром блаба нисколько не удивляет и темболее не раздражает. По началу я был удивлен, но потмо понял, что и сам подвержен ему. Это нормальное проявление человеческих недостатков. Единственное что можно тут сделать — это осознать что сам являшся блабом и изучить разные языки чтобы потом можно было оценивать их более-менее осознанно и бесрпистрасно.

Эта же ветка не более чем отличная демонстрация этого эффекта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 27.02.07 20:20
Оценка: +1
Здравствуйте, jedi, Вы писали:

J>Дело не в том ... rand() — это просто пример недетерминированной функции. Другим примером может быть предположение о наличии какого-то файла на диске, какие-то тонкие предположения о наличии у пользователя каких то-прав в системе, наличие интернета в момент компиляции, да мало ли еще что.

J>Т.е. возникает неявная (!) возможность того, что компилируемость кода зависит от внешних факторов никак не отраженных в исходнике (напр. если происходит вызов внешней либы).
Если программист совсем больной то да. А если нет то все будет нормально. И мы имеем огромную мощь недоступную подавляющему большинству языков.

J>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек

Угу с тем же успехом можно скачать просто исходник (скажем на С++) из инета, скомпилировать и запустить то что получилось. И результат потырит все твои кредитки.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Не пора ли нам перейти на D
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.02.07 20:58
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Что касается конкуренов С++, то для меня это само по себе смешно. С++ маральный урод. Он устарел еще 10 лет назад. Его испоьзуют не потому что он лучий, а потому, что к нему привыкли и потому что вокруг него море фобий. Конкуренты ему попросту не нужны.


Что ж, а я всё уже думал сам высказаться по поводу "C++ vs !C++", правда не хочется опять флейм поднимать. Но раз уж начало положено (причём не в первый раз в этой ветке) то и я выскажусь.

Недавно прочитал замечательную книжку "The UNIX-HATERS Handbook". Книжка выпущена в далёком 1994 году. Собственно, кое-где авторы (ИМХО) перегибают палку, но в общем и целом мысли высказаны вполне адекватные (причём высказаны очень весело, я под столом валялся, когда читал, хотя некоторым бы впору горько плакать).

Не обошли авторы стороной и C++. Ему посвящена целая глава: "C++ — The COBOL of the 90s". Причём в самом начале есть замечание, что сравнивать C++ и COBOL было бы нечестно по отношению к COBOL'у.

Собственно, не буду приводить здесь полную аргументацию, кому нужно сами прочитайте, или постучитесь ко мне (мыло в профиле указано) и мы сразимся в "СВ". Показательно лишь одно: даже более 10 лет назад его считали неудачным. По сути, книжка утверждает, что "C++ was never formally designed: it grew". Причём, вырос он, преимущественно, согласно UNIX-овской философии (по мнению авторов): простота реализации — главное, в ущерб её можно (и нужно) проносить надёжность. А вот получается после этого сложный неповоротливый монстрик.

Короче, на всякий случай повторюсь: если кто-то хочет развить флейм, давайте начнём его в "СВ". Не хочется "ФП" засорять...
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[12]: Не пора ли нам перейти на D
От: Слоноежик  
Дата: 27.02.07 22:10
Оценка: :)
Здравствуйте, Слоноежик, Вы писали:


С>И что из этого. Правильное решение. D как впрочем и CLI не может гарантировать отсутсвие побочных эффектов. Сомневаюсь — что кому нибудь понравится функция которая вычисляет правильное значение только по чертвергам в полнолуние.

Досадный Глюк. естественно не CLI а CLR
для забивания гвоздя надо выбирать правильный микроскоп.
Re[5]: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:27
Оценка: :)
Здравствуйте, Disappear, Вы писали:

D>Windows — это очень узкий круг вычислительных устройств.


Я даже осмелюсь сделать более громкое заявление! Windows — вообще не вычислительное устройство, а семейство операционных систем! Во как значичь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:27
Оценка: +1
Здравствуйте, ie, Вы писали:

ДГ>>Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?


ie>На текущий момент — да.


Уточню. Не .NET, а на реализациях CLI (Comon Language Runtime). К коим относится и Моно.

ie>Теоритически не исключена возможность прикручивания других бэкендов.


+1 Но это не малая работа, так как кроме кодогенератора нужно реализовать еще и рантайм-сервисы вроде GC и рефлексии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Библиотеки
От: vdimas Россия  
Дата: 28.02.07 04:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>Открыты, в смысле имеют ОпенСорс-реализацию, пока только #GTK и MS Forms (в Моно). Причем MS Forms реализована не полностью. Есть планы по реализации (в Моно) WPF.


Похоже на то, что WPF будет реализовать на порядок проще для любых платформ, чем Windows.Forms (или даже на несколько порядков проще и переносимей)
Re[7]: Не пора ли нам перейти на D
От: Tilir Россия http://tilir.livejournal.com
Дата: 28.02.07 09:12
Оценка: -1
Здравствуйте, Mirrorer, Вы писали:

M>Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.


Вот и я боюсь, что на D работа с COM выродится во что-нибудь VCL-образное. VCL существенно ограничивает (мои) возможности, COM-сервера получаются как правило громадными и неоптимальными, а написать Full ActiveX или DCOM-службу на нём вообще нереально, проще уж на чистом API. В общем, месяцы, проведённые на билдере, я вспоминаю как кошмар. ATL — просто чудо по сравнению с этим.
Re[7]: Не пора ли нам перейти на D
От: Tilir Россия http://tilir.livejournal.com
Дата: 28.02.07 09:25
Оценка: +1
Здравствуйте, Disappear, Вы писали:

D>Приходилось, все же с ATL удобнее. С Microsoft всегда удобно работать через инструменты от Microsoft, но на этом все заканчивается.

D>Да и причем тут COM — что, это панацея? Многие CORBA используют.
D>Да, за счет множественно наследования и неудачной организации процесса обработки сообщений, библиотеки ATL, MFC, WTL не годятся для современных языков. Приходилось мне, естественно, достаточно долго работать с каждой из этих библиотек.

Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL. Аналогично произошло с Delphi и Pascal-подмножеством в нём. Если бы начали делать D и сказали: "любимые наши C++ — разработчики, вот вам C++-подмножество в D, наслаждайтесь. А на досуге, оцените ещё наши новые фичи — туплы, вариативные шаблоны и ещё кучу всякой радости". Да я бы обеими руками был бы за переход на такой язык и начальство бы уговорил.

Кстати, я так и не дождался от вас конкретного примера, чего собственно изначально просил. Насчёт кучи всякой радости: зачем она нужна и радость ли это (в кучах не только радость бывает). Без ссылок на книги. Примерно как я вам привёл два куска актуального и нужного кода.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 15:42
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС

C>(Indian Point Energy Center) для учета персонала

Незабудь сообщить дату запуска. Я поищу к этому времни надежное бомбоубежище.

C>Прямо жаль, что я его писал на Java, а не на С++. А то бы можно было бы

C>начать флейм "Только С++ пригоден для использования на АЭС". Эххх...

Ну, это если пронесет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 15:42
Оценка: :)
Здравствуйте, Mirrorer, Вы писали:

M>А меня 3 года назад сватали разработчиком С++ на Запорожскую АЭС.

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

Хорошо вы от нас далеко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Библиотеки
От: vdimas Россия  
Дата: 28.02.07 15:56
Оценка: +1
Здравствуйте, VladD2, Вы писали:


V>>Похоже на то, что WPF будет реализовать на порядок проще для любых платформ, чем Windows.Forms (или даже на несколько порядков проще и переносимей)


VD>WPF — сложная библиотека (большой объем кода). Единственное ее приемещество — она сразу рассчитана на довольно малый по объему модуль нэйтив-кода и не завист огромного WinAPI.


О том и речь. Разделение идёт на уровне заранее подготовленных абстрагирующих базовых классов, которых совсем немного. (DrawingContext, WindowHost и т.д.)


VD>Но объем работ все же не позволит быстро и лего ее реализовать. Так что будучи реализованной ее наверно действительно будет легко переностить, но вот реализовать ее будет не просто.


А рефлектор на что?

Просто я с трудом представляю себе суммарный объем работы для того, чтобы заставить на Линухе полноценно работать c Windows.Forms. Суммарный в смысле с wine, ибо в оригинале идёт жесткая спайка с WinApi в каждом втором методе, да еще надо поддержать юзверские контролы, в которых такое же WinAPI мракобесие творится (сам пишу контролы постоянно для Windows.Forms). В общем, зря моновцы изначально за эту задачу взялись и столько сил угробили.

Глядя на всё это я как-то пару лет назад уселся писать Lite-GUI библиотеку, кое-что сделал (общий енжин хостинга канваса, пару контролов), но затем слухи о подробностях реализации "Авалона" (тогда еще) прервали полёт творческой мысли.
Re[4]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 28.02.07 16:06
Оценка: +1
Здравствуйте, demi, Вы писали:

D>Это к примеру. Я не буду тут плакаться что то не то, это не то. C++ есть, пока жив, но скоро он отойдет в тень. Еггоь вытеснили из CGI сферы. Его вытеснелили из Business приложений. Он сдает позиции. Это факт. Но с новыми технологиями дешевеет программист. Это факт. Грустный факт.

Не дешевеет. Просто он за тоже время может сделать больше.
В этом смысле для работодателя программист дешевле и это хорошо.
Но никаких причин платить меньше нет ибо хороших программистов всегда мало и никакие технологии это не изменят.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Задумчиво...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.02.07 17:42
Оценка: +1
Здравствуйте, Disappear,

Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 18:44
Оценка: +1
Здравствуйте, Mirrorer, Вы писали:

M>Я в свое время делал это на Delphi. И никак не мог понять почему COM программирование считается большим анусом... Потом прочитал книгу Inside COM, посмотрел на реализацию простейшего СОМ сервера на С++. Как бы это помягче выразится.. Впечатления были очень протеворечивые..


Это потому, что Дельфи начиная с 4-ой версии (если не ошибаюсь) поддерживала КОМ на уровне языка, а в С++ все эмулировалось на уровне паттернов.

На дельфи 2.0 писать КОМ-объекты было еще противнее чем на С++, так как оддержики фактически не было, а эмуляция получалась еще более убогая чем на С++.

По большому счету поддеркжу КОМ можно представить как внутренний ДСЛ. И лучше всего тут будет выглядеть язык хорошо поддерживающий встравание внутренних ДСЛ-ей (или содержащий такой ДСЛ, как Дельфи).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 28.02.07 20:03
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.


Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.
now playing: Phace — fraXion
Re[9]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 28.02.07 20:12
Оценка: +1
Здравствуйте, ie, Вы писали:

ie>на Haskell так:

ie>
ie>factorial 0 = 1
ie>factorial n = n * (factorial (n-1))
ie>

Этот вариант всех рвёт по компактности и изяществу.
now playing: Impulse & Submerged — Dirty Bomb (Scorn Remix)
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:57
Оценка: -1
Здравствуйте, EvilChild, Вы писали:

EC>Ещё потому, что есть прорва legacy code написанного на нём,


Вот это чистейшей воды миф. Практически все API делаются совместимыми с C или одной из VM.

EC> которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++


В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.03.07 04:08
Оценка: +1
Здравствуйте, minorlogic, Вы писали:
M>Я встречал людей делящихся на 2 типа по отношению к МН, те которые его понимают и те которые его просто не знают. А вы мне говорите про какие то сложности ? Видимо вы исключение из правил.
Если честно, я не понял, про что эта фраза. Да, я понимаю, как работает МН в С++. Я это вообще в университете преподавал. И естественно, я думаю, что МН в С++ — это нелепое нагромождение компромиссов. Да, я в курсе, почему и зачем оно так сделано. Это всего лишь демонстрация того, как неверно сделанное в начале предположение приводит к кривому и запутанному дизайну.

M>Классический пример — наследование реализации для иерархии интерфейсов.

Конкретнее можно? Покажите мне, где я буду наследоваться от одного и того же класса и невиртуально и виртуально? Чтобы вот эта процитированная фраза реально применилась:

If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.

S>>Все эти правила призваны всего лишь разрулить неопределенности, возникающие из-за самой идеи двух видоа наследования. Никакой практической полезности в них нет.
M>Для вас нет ?
Я признаю их полезность как только мне ее продемонстрируют. Где она? Мое мнение: в реальной жизни это не применяется.

M>>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

S>>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.
M>Не факт , но мне хочется иметь возможность выбрать , а вам ?
Выбрать что? Мне хочется иметь возможность не выбирать. Меня вполне устраивает ситуация, в которой такие вещи, как инлайнинг кода, выбирает компилятор. Никакого требования копировать код в миксинах нету. Есть масса альтернативных стратегий. Лишь бы семантика была та же самая.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 01.03.07 04:58
Оценка: :)
Здравствуйте, konsoletyper, Вы писали:

K>Но главное, чтобы прога на Фортране была так же прогой на Мегафортране.


Если учеть тот факт, что Фотртан есть язык языков, то так оно и есть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 11:03
Оценка: +1
Здравствуйте, Disappear, Вы писали:

D>То, о чем вы тут говорите больше смахивает на демагогию. Нужно смотреть на реальное положение вещей — .NET это CLR и так будет всегда.


Советую покурить MSDN или LCS/CLI-стандарты.

D>Без VM из всех ваших сверхмощных языков уйдет вся их сверхмощь — рефлекшены, дефрагментатор памяти, runtime inline и практически все то, ради чего тут загибали пальцы.


VM — это образное выражение. Считается что управляемая программа пишется для некой подразумеваемой (виртуальной) машыны. Фактически же программа выполняется реким рантаймом который и обеспечивает все нужные сервисы. Таких рантаймов на сегодня 3: GNU (почти не рабочий), Моно и .Net CLR. Последнии два вполне рабочие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 01.03.07 13:15
Оценка: :)
Здравствуйте, Andir, Вы писали:

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


J>>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек


A>Хмм. А ведь интересная мысль!


а есть такая класная программа как янус
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[14]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 01.03.07 13:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:

VD>...

И параллельность. Чуть ли не половина глюков вылазит при многопоточности.
Re[13]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 01.03.07 14:17
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Интуитивно обе пары совершенно лишнии. Вот люди и лепят их на всякий пожарный.


Внутренние-то почему лишние? Возможно моя интуиция слишком "математизирована", но в

x * sin x — 1
vs.
x * sin (x — 1)

по-моему всё однозначно и понятно
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:20
Оценка: -1
Здравствуйте, igna, Вы писали:

I>
D>>fac 0 = 1
D>>fac n = n * fac (n-1)
I>


I>То есть все-таки так, как оно и должно быть.

Забавно, что вот так:
fac 0 = 1
fac n = fac (n-1) * n

насколько я понимаю уже нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:20
Оценка: +1
Здравствуйте, IT, Вы писали:

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


В Хаскеле нет перегрузки методов. Только паттерн-матчинг.
Да и "перегрузка метода по значению" — это какая-то фигня.

В общем, что-то ты не допонимаешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 16:08
Оценка: +1
Здравствуйте, Курилка, Вы писали:

К>Ну частично, думаю, можно достичь определённых результатов, если логику параллелизма вынести на уровень какого-нибудь DSL, где уже использовать нужные алгоритмы, правда ограничения исходного рантайма преодолеть не придётся, да.

ДСЛ это лишь сахарок. Без примитивов работы с многопоточностью всеравно ничего не сделаешь. А вот качественную реализацию правильных примитивов можно сделать только на уровне ВМ ибо нужно учитывать специфику конкретного железа на котором работаешь.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Не пора ли нам перейти на D
От: Gajdalager Украина  
Дата: 01.03.07 17:22
Оценка: :)
Здравствуйте, VladD2, Вы писали:


К>>Но вот откуда там тебе скобки мерещатся — мне непонятно


VD>Мне не мерещится ничего. Я тебе говорю как будет воспринимать это человек у которого мозги не изнасилованы тремя туториалами по Хаскелю. Это называется интуитивное восприятие.


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

VD>Вот знаешь как отличить кота от кошки?


Пинка дать? Если побежал — то кот, а если побежала — кошка?
Re[13]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 01.03.07 21:37
Оценка: +1
Здравствуйте, Disappear, Вы писали:

EC>>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.


D>Не совсем так. Современные С++ компиляторы такие вещи как inline, register, volatile в большинстве случаев просто пропускают. Поэтому ваш аргумент — не более чем выдумка.


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

Человеческий разум непобедим, особенно в неразумных поступках
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[16]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 02.03.07 06:22
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


I>>Влад. тут мы почитали внимательно...


VD>Кто, мы?

я и стая товарищей (с)

I>>Такое ощущение что тебе нужен не специалиированный язык. типа универсального бойца. Верно? или это обманчивое впечатление?


VD>Мне нравится идея универсального инструмента который можно тоноко заточить под конкретную задачу/предметную область. Потому собственно я и обращаю внимание на метапрограммирование.


понятно. спасибо. значит не показалось
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[16]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка: -1
Здравствуйте, deniok, Вы писали:

D>Как вычислить эти выражения, попадись они мне в школьном учебнике алгебры Хаскель сохраняет для функций одной переменной стандартный математический синтаксис.


Попадись тебе в учебнике запись вида "sin x — 1" ты бы подумал что sin — это имя переменной. Да и вычислять в неопределенных фукнциях в математике ничего нельзя. Это же формулы.

Та что не надо ничего притягивать за уши.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 02.03.07 09:25
Оценка: +1
VladD2 wrote:
> C>Даже параллельный конкуррентный GC вынужден на определенное время
> C>останавливать всех мутаторов. Оно достаточно короткое, но вполне
> C>существенное для многих целей.
> И что?
Не всегда это терпимо. Хороший пример — игры. Вряд ли тебе будет
приятно, если у тебя иногда игра будет на пару секунд зависать.

> C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки

> Это вопрос терминологии. К тому же конкуррентный и хорошо параллелящийся
> — это две большие разницы.
Это я прекрасно знаю, поэтому и пишу "параллельный конкуррентный".

> Я не вижу причин по которым не реализовать удобное распараллеливание в

> универсальных языках.
Проблема в том, что для GC в том же .NET не существует
иммутабельных объектов. Так как через reflection ты можешь поменять даже
содержимое string. А значит, куча оптимизаций из Erlang GC идет лесом.

> О изменениях VM пока что можно только мечтать.

Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[27]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 09:28
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:

>> О изменениях VM пока что можно только мечтать.
C>Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать

А можно расшифровать выделенное?
Re[23]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 02.03.07 14:30
Оценка: :)
Здравствуйте, lomeo, Вы писали:

L>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


Может он не нужен, потому что у него больше недостатков чем достоинств?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 15:33
Оценка: -1
Здравствуйте, IT, Вы писали:

L>>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


IT>Может он не нужен, потому что у него больше недостатков чем достоинств?




Может, однако недостатки глобального вывода для пользователя языка озвучены не были.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[25]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 02.03.07 15:52
Оценка: +1
Здравствуйте, lomeo, Вы писали:

IT>>Может он не нужен, потому что у него больше недостатков чем достоинств?


L>


L>Может, однако недостатки глобального вывода для пользователя языка озвучены не были.


Были буквально тремя постами выше, просто ты не внимательно читал.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 02.03.07 22:44
Оценка: +1
Здравствуйте, IT, Вы писали:

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


IT>>>Были буквально тремя постами выше, просто ты не внимательно читал.


L>>"упрощение выявления ошибок и документирование"?


IT>С практической точки зрения особенно первое.


А мне кажется и то и другое очень важно +

1) скорость компиляции (взасчет локального, а не глобального анализа)

2) компонентность (в т.ч. интеграция с другими языками)

3) упрощение реализации Intellisense в IDE (по тем же причинам, что и 1) )

В общем я целиком за локальность и следующующую из нее компонентность.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 01:55
Оценка: :)
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Что ты под этим ("писать от типа") понимаешь? Я не очень понял. Можно пример?


Стандартный прием, который используется в Хаскеле, и который многократно видел поданный как совет в разных книжках статьях и прочее. Очень простой: "Если не ясно как должна выглядеть функция, сначала напиши её тип".

Например, недавно вышла книжка по Хаскель основы, Hutton автор, название не помню. Там он часто упоминается на простых примерах. Я писал о нем, попытавшись как то его формализовать, как всегда не зная, что это сделано до нас но там, правда, тип был уже заранее известен.

В общем, используется в ситуации, когда раздумывая над реализацией сходу её написать не можешь, поэтому думаешь сначала — а какой должен быть тип у этой функции. Если нужен более простой пример, то могу описать примерную последовательность, но, полагаю, ты понял о чем я.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 02:15
Оценка: -1
Здравствуйте, Андрей Хропов, Вы писали:

L>>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


АХ>А какие у него достоинства?


Да такие же, как и у локального. Вот привел ты мне в пример (или не ты, не помню, да и не важно) факториал в локальной функции без типов, компилятор сам выведет. Здорово! Лаконичная запись, тем не менее типизация статическая. Почему при прочих равных то же самое для нелокальной функции будет недостатком?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 07.03.07 10:01
Оценка: +1
Здравствуйте, Курилка, Вы писали:

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


К>Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1


Хватит путаницы на ровном месте!

Конечно, умножение всегда должно указываться явно, в отличие от школьной алгебры. И, конечно, sin x — 1 не есть (sin * x) — 1.
Re[53]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 18.03.07 14:39
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Я не против статьи.

Вот и здорово, если она появится, то будет отличное дополнение к твоей.

VD>Я просто заранее предупреждаю о том, что это будет очень узкоспецифичная вещь.

Лучше когда статься есть, чем когда нет, а то вдруг Cyberax передумает
now playing: Quinoline Yellow — Garn Goy
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 17:47
Оценка:
Здравствуйте, Zigmar, Вы писали:

Z>нет


Нет — значит не заслужили?
Re: Не пора ли нам перейти на D
От: Smal Россия  
Дата: 26.02.07 17:50
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили
не пора. Сыроват
С уважением, Александр
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 17:53
Оценка:
Здравствуйте, Smal, Вы писали:

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

S>не пора. Сыроват

Единственный способ сделать его стабильным, массово начав программировать
Re[3]: Не пора ли нам перейти на D
От: Аноним  
Дата: 26.02.07 17:56
Оценка:
Здравствуйте, Disappear, Вы писали:

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


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

S>>не пора. Сыроват

D>Единственный способ сделать его стабильным, массово начав программировать


Начинай...
В студенческих или разовых проектов еще можно попробовать.
А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 18:01
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


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

S>>>не пора. Сыроват

D>>Единственный способ сделать его стабильным, массово начав программировать


А>Начинай...

А>В студенческих или разовых проектов еще можно попробовать.
А>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.

А зачем что-то сменять? Есть бинарная совместимость на уровне obj-ектников. К старому хламу пишем кучу фасадов.
Re[5]: Не пора ли нам перейти на D
От: Smal Россия  
Дата: 26.02.07 18:07
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Здравствуйте, Аноним, Вы писали:


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


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


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

S>>>>не пора. Сыроват

D>>>Единственный способ сделать его стабильным, массово начав программировать


А>>Начинай...

А>>В студенческих или разовых проектов еще можно попробовать.
А>>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.

D>А зачем что-то сменять? Есть бинарная совместимость на уровне obj-ектников. К старому хламу пишем кучу фасадов.


И что это даст. Никаких библиотек под D особенно не наблюдается.
Такой переход должен быть экономически выгоден.
С уважением, Александр
Re[6]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 18:14
Оценка:
Здравствуйте, Smal, Вы писали:

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


S>И что это даст. Никаких библиотек под D особенно не наблюдается.

S>Такой переход должен быть экономически выгоден.

Ну что-то уже есть, std например. Некоторые хорошие веши встроены в язык — string, lambda, boost::dynamic_bitset например.
А насколько был эффективен перепрыг скажем с VB на C# и.NET 1.0? Так поступило множество контор. Что там было экономически выгодно?

P.S. Мне самому факт перехода на неосвоенный человечеством язык вызывает не более чем гипотетически-астрономический интерес , но интересны также мнения...
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 18:24
Оценка:
Здравствуйте, Tilir, Вы писали:

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


D>>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>>Разве мы не заслужили

T>Я предлагаю вам привести какой-нибудь простой и ясный пример. Вот задача. Вот так она криво и плохо решается (или вообще не решается на C++).

T>А вот так она красиво и грамотно решается на D. И сразу всё станет ясно и убедительно.

Генератор примеров :
http://www.digitalmars.com/d/comparison.html

template factorial(int n : 1)
{
    enum { factorial = 1 }
}

template factorial(int n)
{
    enum { factorial = n* factorial!(n-1) }
}

void test()
{
    writefln("%s", factorial!(4));    // prints 24
}


T>Ссылка не убедила — язык без нормальных шаблонов,

Т.е. в D ненормальные шаблоны? чем они отличаются от нормальных?

T>множественного наследования

многие с Вами не согласятся. А часто вы используете множественное наследование?

T>и макросов это шаг назад,



T>а не вперёд, ИМХО.


T>Да ещё и весьма сомнительный garbage collection.

Еще в 98 году, когда миром правили микроконтроллеры, это было сомнительным.

T>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

В языке C++ его же идиому RAI сложно использовать.
Re: Walter Bright, The D Programming Language
От: igna Россия  
Дата: 26.02.07 18:47
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?


Жду появления книги Walter Bright, The D Programming Language, чтобы можно было почитать в трамвае, на диване и вообще. Сидя за компьютером и так есть чем заняться.
Re[3]: Не пора ли нам перейти на D
От: Viper_Craft  
Дата: 26.02.07 18:55
Оценка:
Здравствуйте, Disappear, Вы писали:


D>Генератор примеров :

D>http://www.digitalmars.com/d/comparison.html

D>
D>template factorial(int n : 1)
D>{
D>    enum { factorial = 1 }
D>}

D>template factorial(int n)
D>{
D>    enum { factorial = n* factorial!(n-1) }
D>}

D>void test()
D>{
D>    writefln("%s", factorial!(4));    // prints 24
D>}
D>


T>>Ссылка не убедила — язык без нормальных шаблонов,

D>Т.е. в D ненормальные шаблоны? чем они отличаются от нормальных?

Тоже самое можно и в С++, но в С++ шаблоны не только для этого...

T>>множественного наследования

D> многие с Вами не согласятся. А часто вы используете множественное наследование?

Да, а вы понимаете данный термин?


T>>Да ещё и весьма сомнительный garbage collection.

D>Еще в 98 году, когда миром правили микроконтроллеры, это было сомнительным.


T>>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

D>В языке C++ его же идиому RAI сложно использовать.

Тут скорее так, в С++ ты можешь использовать GC и RAI, т.е. есть выбор, а это дополнительный плюс...
Re[4]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 26.02.07 19:15
Оценка:
Здравствуйте, Viper_Craft, Вы писали:

V_C>Тут скорее так, в С++ ты можешь использовать GC и RAI, т.е. есть выбор, а это дополнительный плюс...


Дополнительный плюс — это так: С+++
Re[5]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 19:41
Оценка:
Здравствуйте, Disappear, Вы писали:

А>>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.


D>А зачем что-то сменять? Есть бинарная совместимость на уровне obj-ектников. К старому хламу пишем кучу фасадов.


Если на C++ получается писать только хлам — что ж, это выход
Re[2]: Не пора ли нам перейти на D
От: ANM Россия  
Дата: 26.02.07 19:46
Оценка:
Здравствуйте, demi, Вы писали:

D>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++

Много эмоций, мало конкретики.

D>когда десяками лет тянется старое, извините, говнооптимизации

Что это такое?

D>И нет человека способного это прекратить волевым решением.

Конечно. Потому что очень много компаний используют C++.

D>Бесят смарт поинтеры (assist зачасту не способен на -> нормальную подсказку выдать, мытарства когда надо F11 при дебаге),

Не знаю.. У вас что сотни методов в классе? Если так то есть повод подумать над дизайном проекта.

D> бесит тормознутость C0x

По сравнению с чем ?

D>бесит список инициализации (вместо int const member = 10;

Ну да. Но этого явно недостаточно для смены языка. Мало ли что вас будет бесить в новом.
Re[2]: Не пора ли нам перейти на D
От: vsb Казахстан  
Дата: 26.02.07 19:51
Оценка:
Здравствуйте, Tilir, Вы писали:

T> язык без нормальных шаблонов

В D шаблоны лучше, чем в C++

> множественного наследования

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

> макросов

Как это нет? cpp file.d > _file.d Суть в том, что макросы в D не нужны. Страуструп старательно вычищал С++ от макросов, Брайт завершил его дело.

> Да ещё и весьма сомнительный garbage collection. Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

GC опциональный. При желании можно руками всё собирать. Кстати ничего, что в следующем стандарте С++ тоже будет GC ?
Re[3]: Не пора ли нам перейти на D
От: vsb Казахстан  
Дата: 26.02.07 19:55
Оценка:
ANM> По сравнению с чем ?
Наверное по сравнению с dmd. Кстати да, субъективно компилятор D в десятки раз быстрее С++-ного. Всё стандартная библиотека (а там 60000 строк) у меня собирается за 2.5 секунды.
Re[3]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 19:56
Оценка:
Здравствуйте, vsb, Вы писали:

>> множественного наследования

vsb>интерфейсы есть. Остальное не нужно.

Не нужно Вам?

vsb>Собственно то, что множественного наследования в современных индустриальных яызках нет (за исключением С++) это подтверждает.


В каких, например, кроме Java/C#? И это ничего не подтверждает.

>> макросов

vsb>Как это нет? cpp file.d > _file.d Суть в том, что макросы в D не нужны. Страуструп старательно вычищал С++ от макросов, Брайт завершил его дело.

А как там избавляются от повторений фрагментов кода, которые не укладываются в структурную удиницу языка программирования (функцию, класс, шаблон и т.п.)?
Re[3]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 20:00
Оценка:
Здравствуйте, Nuzhny, Вы писали:

D>>И тут взглянул на код C++ и понял в каком я дерьме копаюсь...


N>Зачем же было дерьмо писать?


Чтобы было в чем копаться
Re[4]: Например миксинами.Не пора ли нам перейти на D
От: vsb Казахстан  
Дата: 26.02.07 20:05
Оценка:
Здравствуйте, Alxndr, Вы писали:

A>Не нужно Вам?Мне субъективно оно приятно, но я понимаю, что множественное наследование порождает больше проблем, чем решает.

Конечно я предпочитаю иметь возможность, чем не име No ть её. Но я думаю, что множественное наследование порождает больше проблем, чем решает.

A>В каких, например, кроме Java/C#?

Почему кроме? Какие ещё языки поддерживают множественное наследование? Я помню только C++ и Smalltalk, возможно скриптовые. А сравнивать имеет смысл С++, D, C#, Java, именно так. Или вы не согласны? Тогда приведите примеры.

A>И это ничего не подтверждает.

С моей точки зрения — подтверждает.


A>А как там избавляются от повторений фрагментов кода, которые не укладываются в структурную удиницу языка программирования (функцию, класс, шаблон и т.п.)?

Например миксинами.
Re[5]: Например миксинами.Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 20:22
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Конечно я предпочитаю иметь возможность, чем не име No ть её. Но я думаю, что множественное наследование порождает больше проблем, чем решает.


Какие проблемы эта возможность порождает, чтобы нужно было от нее отказываться?

A>>В каких, например, кроме Java/C#?

vsb>Почему кроме? Какие ещё языки поддерживают множественное наследование? Я помню только C++ и Smalltalk, возможно скриптовые.

Я напомню еще Eiffel и CLOS.

vsb>А сравнивать имеет смысл С++, D, C#, Java, именно так.


Рановато называть D индустриальным. Остается C++, Java и C#.

Или вы не согласны? Тогда приведите примеры.

A>>И это ничего не подтверждает.

vsb>С моей точки зрения — подтверждает.

Аминь
Тогда шаблоны тоже нужно выкинуть — как не востребованные в большинстве индустриальных языков программирования.
И детерминированное уничтожение объектов туда же.
И много чего еще.

A>>А как там избавляются от повторений фрагментов кода, которые не укладываются в структурную удиницу языка программирования (функцию, класс, шаблон и т.п.)?

vsb>Например миксинами.

Можно с этого места подробнее?
И как-то миксины не вполне сочетаются с отсутствием множественного наследования...
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 20:44
Оценка:
Здравствуйте, Alxndr, Вы писали:

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


>>> множественного наследования

vsb>>интерфейсы есть. Остальное не нужно.

A>Не нужно Вам?


vsb>>Собственно то, что множественного наследования в современных индустриальных яызках нет (за исключением С++) это подтверждает.


A>В каких, например, кроме Java/C#? И это ничего не подтверждает.


Это хороший показатель.

A>А как там избавляются от повторений фрагментов кода, которые не укладываются в структурную удиницу языка программирования (функцию, класс, шаблон и т.п.)?


Для этого есть mixin — одна из возможностей языка. Другие возможности (только корректные их возможности) макросов, тоже доступны в языке D.

GC — опциональный. Память можно освобождать вручную. Причем сделано это лучше чем в .NET, так как память при этом действительно освобождается а прыгает между покалениями.

Ну и native компиляция, что тут еще можно сказать.
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 20:54
Оценка:
Здравствуйте, demi, Вы писали:

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


D>С++ это как в самолете — тошнит, а выйти некуда... Такие проблемы надо силой решать. D с завтрашнего дня и все тут! Думаю, что сначала это себе позволят маленькие конторки — 4-5 человек или конторы с небольшой историей. Окажется, что после этого они догонят более крупные — писать на D легче, программы лучше. Потом только зашевелятся средние. Но для них это будет больно — тонны кода... Кто-то из них умрет, а кто-то перейдет на D. А там и до гигантов прогресс дойдет Революция как известно с низов начинается. Так что нормальную IDE D и немного либов и все, delete С++


Во многом разделяю ваши душевные стремления
Почему же нет реализациё. Есть компиляторы DMD от DigitalMars, GDC от GNU-шного набора компиляторов.
Re[3]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 21:29
Оценка:
Здравствуйте, Alxndr, Вы писали:

A>Надо думать, на тебя запрет на открытую переписку о модерировании не распространяется?


Да, есть момент. Формально непорядок. Однако, уверен, что Денис поймет, что это легкий стеб над бессмысленностью данной темы, а не обсуждение его решения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 22:03
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>В студенческих или разовых проектов еще можно попробовать.


С++ тоже по началу использовался в оснвном в университетакх.

А>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.


А как же тогда люди на С++ то перешли?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 22:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>В общем, то D совершенее С++ во всем кроме раскрученности и количества бибоитек. Но:

VD>1. В следствии парадокса Блаба
Автор: VladD2
Дата: 23.11.06
, чтобы это понять надо серьезно изучить D.

VD>2. C++ники не будут использовать D потому что они ещё живы
Автор: Lazy Cjow Rhrr
Дата: 12.02.07
.

VD>3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.

С подобным парадокcом неоднократно сталкивался, в том числе и сам
Дайте примеры по 3-ему пункту плиз.
Re[5]: Не пора ли нам перейти на D
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.02.07 22:15
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>В каких, например, кроме Java/C#? И это ничего не подтверждает.


VD>Я могу назвать только один язык где еще есть множественное наследование. Этот язык — Эфил. Больше я подобных не знаю.


Тогда загляни в википедию. Кстати, выше по ветке я уже писал и про Eiffel и про CLOS.

VD>Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития.


Мне он ничего такого не показал

VD>Единственное разумное его применение — это подключение реализации интерфейсов.


А что-нибудь про policy-based design ты слышал? Это так, к примеру.

VD>Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны.


Противники множественного наследования обычно говорят именно в таком ключе "ряд проблем вроде бриллиантового наследования". Никто не хочет этот ряд продолжать
Re[5]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 22:29
Оценка:
Здравствуйте, Disappear, Вы писали:

D>GC — опциональный. Память можно освобождать вручную. Причем сделано это лучше чем в .NET, так как память при этом действительно освобождается а прыгает между покалениями.


GC в D применяется очень слабенький. Причина тому наличие указателей (как в С++) и невозможность по этому поводу переупорядочивать объкты в памяти.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 22:29
Оценка:
Здравствуйте, demi, Вы писали:

D>С++ это как в самолете — тошнит, а выйти некуда... Такие проблемы надо силой решать. D с завтрашнего дня и все тут! Думаю, что сначала это себе позволят маленькие конторки — 4-5 человек или конторы с небольшой историей. Окажется, что после этого они догонят более крупные — писать на D легче, программы лучше. Потом только зашевелятся средние. Но для них это будет больно — тонны кода... Кто-то из них умрет, а кто-то перейдет на D. А там и до гигантов прогресс дойдет Революция как известно с низов начинается. Так что нормальную IDE D и немного либов и все, delete С++


delete С++ — это 100%-ный проход по памяти!
А вообще твоим New-Васюкам не суждено сбыться. C++ники не будут использовать D не из-за какого-то там мусора, а потому что они ещё живы.
Автор: Lazy Cjow Rhrr
Дата: 12.02.07

Что же до любьви к прекрасному... то очень советю покурить Nemerle. Если разберешся, то с вероятностью 99% через некоторое внемя ты поймешь, что D — это тупиковая ветвь эволюции. Ну, а с С++ тебя просто будет мутить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: bkat  
Дата: 26.02.07 22:33
Оценка:
Здравствуйте, VladD2, Вы писали:

А>>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.


VD>А как же тогда люди на С++ то перешли?


На нем более чем 10 лет тому назад как начали

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

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

Но такой вариант — это на самом деле и не вариант даже...
Re[6]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 22:58
Оценка:
Здравствуйте, Disappear, Вы писали:

VD>>3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.


D>С подобным парадокcом неоднократно сталкивался, в том числе и сам

D>Дайте примеры по 3-ему пункту плиз.

Неужели — это до сих пор нужно делать на этом форуме?

Пожалуйста! Их есть у меня (с).
http://rsdn.ru/summary/3766.xml
http://rsdn.ru/article/philosophy/Scala.xml
Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.


Языки чем-то похожие на D, но превосходящие его на голову.
Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:
macro CompileTimeFactorial(n : uint)
{
    def res = Util.Factorial(n);
    <[ $(res : ulong) ]>
}

module Util
{
  // 
    Factorial(n : uint) : ulong
    {
        | 0 | 1 => 1
        | _     => n * Factorial(n - 1)
    }
}

То есть это просто одинарный код только вызванный в макросе. А в прикладном коде он будет выглядеть как вызов фукнции:
WriteLine(CompileTimeFactorial(10));

и факториалы это просто детские шалости. Макросы это прямая и эффективная реализация метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 23:23
Оценка:
Здравствуйте, Alxndr, Вы писали:

A>Тогда загляни в википедию. Кстати, выше по ветке я уже писал и про Eiffel и про CLOS.


Мне казалось здесь идет речь о статически типизируемых компилируемых языках. CLOS это вообще бибилотека макросов, Прел — скрипт.
К тому же список все равно мизерный. И все языки довольно старые.
Кстати, ты прочел эту статью до конца? Там в конце пимечательный раздел есть:

Debate
There is debate as to whether multiple inheritance can be implemented simply and without ambiguity. It is often criticized for increased complexity and ambiguity, as well as versioning and maintenance problems it can cause (often summarized as the diamond problem).[1] Detractors also point out that multiple inheritance implementation problems such as not being able to explicitly inherit from multiple classes and the order of inheritance changing class semantics. There are languages that address all technical issues of multiple inheritance, but the main debate remains whether implementing and using multiple inheritance is easier than using single inheritance and software design patterns.


Так вот на сегодня почти единодушный ответ дизайнеров ЯП заключается в испльзовании еденичного наследования и миксинов/трэйтсов.

VD>>Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития.


A>Мне он ничего такого не показал


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

VD>>Единственное разумное его применение — это подключение реализации интерфейсов.


A>А что-нибудь про policy-based design ты слышал? Это так, к примеру.


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

VD>>Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны.


A>Противники множественного наследования обычно говорят именно в таком ключе "ряд проблем вроде бриллиантового наследования". Никто не хочет этот ряд продолжать


А зачем? Неоднозначность это уже огромная проблема. Это те грабли которые бьют по голове в самый неподходящий момент.

И это при том, что другие подходы решают проблемы решаемые МН не создавая неоднозначностей.

Понимаешь, то так просто — есть два решения. Одно решает нужные проблемы, но создает другие, а второе решает те еж проблемы, но не создает нвоых. Выбор для разумного человека очевиден... если бы не эффект Блаба.

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

Меж тем действительно слабые стороны Ди даже не обсуждались. И оно не мудренно. Ведь ни противники, ни сторонники Ди не знают даже о существовании других подходов. Обсуждение ограничено рамками С++. А это очень узкие рамки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.07 23:23
Оценка:
Здравствуйте, bkat, Вы писали:

VD>>А как же тогда люди на С++ то перешли?


B>На нем более чем 10 лет тому назад как начали


Ошибашся. Уже более двадцати.

B>А вообще — это реальная проблема, как перейти на новые технологии,

B>если уже

+1

B>есть серьезный багаж, который просто так не выкинуть.


Дело не в багаже. Дело в косности, привычках, лени и ... В общем, вот тут все описано:
http://rsdn.ru/Forum/Message.aspx?mid=2346697&amp;only=1
Автор: Lazy Cjow Rhrr
Дата: 12.02.07

http://rsdn.ru/Forum/Message.aspx?mid=2229002&amp;only=1
Автор: VladD2
Дата: 23.11.06



B>Ну кардинальный вариант понятен.

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

Проблема в том, что старички становятся начальниками. Так что как раз они и будут "набирать".

B>Но такой вариант — это на самом деле и не вариант даже...


Ага. Это утопия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Не пора ли нам перейти на D
От: Disappear  
Дата: 26.02.07 23:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.


D>>С подобным парадокcом неоднократно сталкивался, в том числе и сам

D>>Дайте примеры по 3-ему пункту плиз.

VD>Неужели — это до сих пор нужно делать на этом форуме?


VD>Пожалуйста! Их есть у меня (с).

VD>http://rsdn.ru/summary/3766.xml
VD>http://rsdn.ru/article/philosophy/Scala.xml
Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.


VD>Языки чем-то похожие на D, но превосходящие его на голову.

VD>Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:

Читал про nemerle немного. Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)
Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)

Вы отчаянный Nemerle-ист!
А я C++ шник, все же. Но нужно ведь постоянно что-то улучшать, адаптироваться и развиваться. За 9 лет со времен принятия первого стандарта С++ многое изменилось, для IT индустрии такой срок — целая вечность.
Эх.. раз уж теперь эта ветка о философии.
Re[7]: Не пора ли нам перейти на D
От: bkat  
Дата: 26.02.07 23:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>А как же тогда люди на С++ то перешли?


B>>На нем более чем 10 лет тому назад как начали


VD>Ошибашся. Уже более двадцати.


Я имел ввиду исключительно тот проект, на котором сейчас сижу.
Re[3]: Не пора ли нам перейти на D
От: qvasic Украина  
Дата: 27.02.07 00:05
Оценка:
T>>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.
D>В языке C++ его же идиому RAI сложно использовать

чем же её сложно использовать?
кроме того, о незакрытых файлах и неразлоченых мьютексах тоже сборщик мусора позоботиться? RAII ведь не только про память.
Re: Не пора ли нам перейти на D
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 27.02.07 02:06
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

А от нас что-то зависит? Оно то может и пора, но пока непонятно, за счет чего может осуществится такой переход. Финансовых магнатов за этим языком не наблюдается. Весомых козырей тоже нет. Удобство при проектировании и разработке в общем-то фоска, так как проще обходить старые грабли, чем решать с нуля нетривиальное бизнес-требование, такое как GUI, кроссплатворменность, работа с БД, работа с COM, распределенное приложение, и т. д. Для примера, насколько просто написать на D элементарное приложение с использованием, например, библиотеки wxWidgets? Что-то мне кажется, что на этом пути можно встретить очень много проблем, начиная прямо от макросов DECLARE_CCLASS, IMPLEMENT_CCLASS, BEGIN_EVENT_TABLE. Думаю, что тривиальным фасадом тут обойтись будет проблематично.А как дела обстоят с использованием STL? Остается надежда на энтузиастов, большей частью студентов, которым еще предстоит создать средства для этого. Но... что-то мне кажется, что сейчас студенты больше интересуются не тем, чтобы самому реализовывать свою можель велосипедае (иногда более совершенную, иногда менее), а тем, чтобы осваивать коммерчески успешные продукты, которые впоследтвие предоставят им возможность заработать больше денег.
Re[3]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 05:33
Оценка:
Здравствуйте, Alxndr, Вы писали:

VD>>2 Хитрик Денис: [skipped]

A>Надо думать, на тебя запрет на открытую переписку о модерировании не распространяется?

Интересно, а история слыхала случаи о отправке модератора в бан?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[8]: Не пора ли нам перейти на D
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.02.07 06:15
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Читал про nemerle немного.


Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.

D> Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)


И что? VM — весьма условная штука. На самом деле всё так же компилится в native-код и выполняется достаточно быстро.

D>Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)


Какие именно закорючки не понравились? Чем вообще синтаксис плох?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 27.02.07 06:21
Оценка:
VladD2 wrote:
> GC в D применяется очень слабенький. Причина тому наличие указателей
> (как в С++) и невозможность по этому поводу переупорядочивать объкты в
> памяти.
Не совсем так — там просто никто особо и не заботился о точном GC. Сам
язык, в общем и целом, позволяет использовать точный GC, но есть
несколько вещей, которые его запрещают (типа объединений в стиле С).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Не пора ли нам перейти на D
От: Socrat Россия  
Дата: 27.02.07 07:02
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

Предлагаю устроить новый флейм "D vs Oberon".
Re[3]: Не пора ли нам перейти на D
От: Socrat Россия  
Дата: 27.02.07 07:27
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Генератор примеров :

D>http://www.digitalmars.com/d/comparison.html

D>
D>template factorial(int n : 1)
D>{
D>    enum { factorial = 1 }
D>}

D>template factorial(int n)
D>{
D>    enum { factorial = n* factorial!(n-1) }
D>}

D>void test()
D>{
D>    writefln("%s", factorial!(4));    // prints 24
D>}
D>


И где тут шаблоны и чем они лучше?
Re[2]: Не пора ли нам перейти на D
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.02.07 07:32
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Я предлагаю вам привести какой-нибудь простой и ясный пример. Вот задача. Вот так она криво и плохо решается (или вообще не решается на C++). А вот так она красиво и грамотно решается на D. И сразу всё станет ясно и убедительно.


Advanced D Programming Language Features (by Walter Bright) -- там этих примеров достаточно. К тому же ничего не сказано о начавшихся работах по добавлению в язык compile-time вычислений.

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

Однако время для того, чтобы сейчас пробовать D в мелких proof-of-concept проектах вместо C++, уже пришло. ИМХО.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 07:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Проблема в том, что старички становятся начальниками. Так что как раз они и будут "набирать".


Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.
Re[2]: Не пора ли нам перейти на D
От: Дм.Григорьев  
Дата: 27.02.07 08:01
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.


It produces memory leaks which is the same but worse.
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Nemerle
От: Дм.Григорьев  
Дата: 27.02.07 08:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что же до любьви к прекрасному... то очень советю покурить Nemerle.


Блин, Немерле, Немерле... Хватит дразниться, в конце концов!!!
1. Что слышно насчет реализаций под линукс, и/или свободных реализаций? Когда ожидать?
2. И во что дело упирается — в нормальную VM? Не верю. Что им мешает в натив компилять?
3. Поддержка со стороны IDE, кроме VS + твоей интеграции?
4. Вообще, какова текущая ситуация? Что куда компилируется и где это 'куда' может работать?
Спасибо.
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 08:07
Оценка:
Здравствуйте, qvasic, Вы писали:

T>>>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

D>>В языке C++ его же идиому RAI сложно использовать

Q>чем же её сложно использовать?

Q>кроме того, о незакрытых файлах и неразлоченых мьютексах тоже сборщик мусора позоботиться? RAII ведь не только про память.

Вот вот. В С++ приходится писать многочисленные dummy классы, для разных видов ресурсов. В D для захвата ресурса есть ключевые слова scope и guard.
Замет — try, catch без finally. Понятно конечно, что можно снова городить кучу dummy классов, но более человечнее будет выглядеть код на языке с поддержкой finally.
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 08:09
Оценка:
Здравствуйте, Socrat, Вы писали:

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

...
S>И где тут шаблоны и чем они лучше?

http://www.digitalmars.com/d/templates-revisited.html
http://www.digitalmars.com/d/variadic-function-templates.html
Nemerle - еще вопрос
От: Дм.Григорьев  
Дата: 27.02.07 08:11
Оценка:
Еще вопрос: область применения, точнее наличие библиотек. В частности:

— построение графических интерфейсов (и какова степень развитости этой либы)
— коннекторы к SQL серверам
— поддержка сетей (в частности, http(s)-клиента)
— возможности использования для серверной разработки
— что ещё?
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re: Nemerle - еще вопрос
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.02.07 08:18
Оценка:
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Еще вопрос: область применения, точнее наличие библиотек. В частности:


ДГ>- построение графических интерфейсов (и какова степень развитости этой либы)

ДГ>- коннекторы к SQL серверам
ДГ>- поддержка сетей (в частности, http(s)-клиента)
ДГ>- возможности использования для серверной разработки
ДГ>- что ещё?

Насколько я понимаю, всё это определяется платформой на которой работает немерле — .Net, думаю что есть в нём, ты в курсе.
Re[5]: Не пора ли нам перейти на D
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.07 09:32
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.


И это уже было
... << RSDN@Home 1.2.0 alpha rev. 675>>
AVK Blog
Re[9]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 27.02.07 09:39
Оценка:
Здравствуйте, ie, Вы писали:

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


N>>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны.


ie>Эээх... и почему все C++ программисты так говорят увидив код на Немерле?


Причём тут С++? Сами же привели несколько нормальных вариантов. Могу ещё школу вспомнить и Паскаль с Бейсиком — будет читабельно (не обязательно кратко).


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

Для обработки изображений (чем я и занимаюсь) не так уж и много языков подходят. На чём мне ещё писать?
Re[6]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 27.02.07 09:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


F>>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.


AVK>И это уже было


ссылку сестра, ссылку
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[9]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 09:43
Оценка:
Здравствуйте, ie, Вы писали:

ie>Да!!! На Lisp они выглядят так:

ie>
ie>;(defun factorial (n &optional (acc 1))
ie>;  (if (<= n 1)
ie>;    acc
ie>;    (factorial (- n 1) (* acc n))))
ie>;

ie>на OCaml так:
ie>
ie>let rec factorial x = 
ie>  match x with 
ie>      0 -> 1 
ie>    | n -> (n * (factorial (n - 1)))
ie>

ie>на Haskell так:
ie>
ie>factorial 0 = 1
ie>factorial n = n * (factorial (n-1))
ie>

ie>на Prolog так:
ie>
ie>factorial(0,1).
ie>factorial(N,F) :- N > 0, M is N - 1, factorial(M,Fm), F is N * Fm.
ie>

ie>на J вообще так:
ie>
ie>factorial =. !
ie>


На D так:
template factorial(int n)
{
  static if (n == 1)
    const factorial = 1;
  else
    const factorial = n * factorial!(n-1);
}


кроме-того оптимизатор, может в compile-time посчитать такие функции:
int factorial(int n)
{
if (n == 1)
return 1;
else
return n * factorial(n — 1);
}

static int x = factorial(5);

Факториал — это только простейший пример, зачем на основе него строить какие-то выводы.
Re[10]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 10:14
Оценка:
Здравствуйте, Nuzhny, Вы писали:

ie>>Эээх... и почему все C++ программисты так говорят увидив код на Немерле?

N>Причём тут С++?

Не знаю. Но C# программеры в моем окружении относятся к Немерле скорее положительно, а C++ наоборот

N>Сами же привели несколько нормальных вариантов.


Хммм... Ну если варианты на Haskell и OCaml понятны, то почему на Немерле стало вдруг не ясно ?
Factorial(n : uint) : ulong
{
    | 0 => 1
    | _ => n * Factorial(n - 1)
}

сравните, очень ведь похоже.

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

N>Для обработки изображений (чем я и занимаюсь) не так уж и много языков подходят. На чём мне ещё писать?

Тот же D будет несомненным шагом вперед
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[10]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 10:14
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Факториал — это только простейший пример, зачем на основе него строить какие-то выводы.


Так я и не строю
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[10]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 27.02.07 10:21
Оценка:
Здравствуйте, Disappear, Вы писали:

D>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. Никакие технологии, и отчаянные попытки маркетологов не убедят в обратном.

JIT компиляция ?
Пример. Имеем программу работающую на 486 древнем. Not a big deal.
При первом запуске метода байткод дотнетовский JITнется в native. и последующие вызовы будут выполнятся уже без Jit компиляции.
С++ программа же скомпилирована со всеми потимизациями 486-го и работает быстрее. ТАк?

Теперь берем те же программу, переносим на Pentium IV.
Внимание вопрос. Сможет ли с++ программа скомпилированная под 486 использовать фишки четвертого пня для ускорения работы ?
А та же дотнетовская программа сможет. Потому что JIT сгенерирует native код для той платформы на которой он будет выполнятся.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[9]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 27.02.07 10:21
Оценка:
Здравствуйте, ie, Вы писали:

ie>на Haskell так:

ie>factorial 0 = 1
ie>factorial n = n * (factorial (n-1))


Ну так понятнее же чем на Nemerle.
Re[10]: Не пора ли нам перейти на D
От: ie Россия http://ziez.blogspot.com/
Дата: 27.02.07 10:38
Оценка:
Здравствуйте, igna, Вы писали:

ie>>на Haskell так:

I>
ie>>factorial 0 = 1
ie>>factorial n = n * (factorial (n-1))
I>


I>Ну так понятнее же чем на Nemerle.


Factorial(n : uint) : ulong
{
    | 0 => 1
    | _ => n * Factorial(n - 1)
}


Ну найди 10 отличий
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[4]: Nemerle - еще вопрос
От: Disappear  
Дата: 27.02.07 10:39
Оценка:
Здравствуйте, Mirrorer, Вы писали:

M>Здравствуйте, Дм.Григорьев, Вы писали:


ДГ>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.

M>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.

Windows — это очень узкий круг вычислительных устройств.
Re[7]: Не пора ли нам перейти на D
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.07 10:44
Оценка:
Здравствуйте, ironwit, Вы писали:

AVK>>И это уже было


I>ссылку сестра, ссылку


Нет никакой ссылки.
... << RSDN@Home 1.2.0 alpha rev. 675>>
AVK Blog
Re[4]: Nemerle - еще вопрос
От: Дм.Григорьев  
Дата: 27.02.07 10:58
Оценка:
Здравствуйте, Mirrorer, Вы писали:

ДГ>>Как-то не особо верится, что объектные либы от C# легко прикручиваются к немерле. Хочется услышать подтверждение от главного немерлиста.

M>Хех. В этом и состоит прелесть .NET Хоть Вб в Шарпу хоть f# к немерле, хоть все вместе И оно действительно работает. Потому что все они компилируются в MSIL.

Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[11]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 27.02.07 11:09
Оценка:
Здравствуйте, ie, Вы писали:

ie>Factorial(n : uint) : ulong
ie>{
ie>    | 0 => 1
ie>    | _ => n * Factorial(n - 1)
ie>}


ie>Ну найди 10 отличий


Каюсь, был неправ. Просто непривычно.
Re[5]: Nemerle - еще вопрос
От: Mirrorer  
Дата: 27.02.07 11:14
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Windows — это очень узкий круг вычислительных устройств.

Вообще я отвечал на один конкретный пункт — относительно интероперабельности между шарпом и немерле. Но тем не менее отвечу.

Есть еще Mono для Linux. Собственно под ним и ведется основная разработка Nemerle, насколько я знаю. Да, Моно это не совсем .Net, у него есть свои ограничения.
Но тем не менее он есть. И Немерле на нем работает. Я ответил на вопрос ?
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[6]: Nemerle - еще вопрос
От: Disappear  
Дата: 27.02.07 11:24
Оценка:
Здравствуйте, Mirrorer, Вы писали:

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


D>>Windows — это очень узкий круг вычислительных устройств.

...
M>Но тем не менее он есть. И Немерле на нем работает. Я ответил на вопрос ?

Думаю да.
Т.е. у нас есть Windows и кусочек Linux, это хорошо.
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 11:28
Оценка:
Здравствуйте, igna, Вы писали:

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


D>>Практика программирования уже успела многое сказать о пригодности интерфейса STL


I>Что именно? Что приходится думать больше чем собственно надо? Зато можно передавать заказчику исходный текст качественно написанной программы не опасаясь, что для сопровождения он наймет кого-нибудь подешевле. И вообще, круто и не для средних умов.


Очень убедительно C# программисты бы это слышали
Re[4]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 12:05
Оценка:
Здравствуйте, Tilir, Вы писали:

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


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


D>>
D>>template factorial(int n : 1)
D>>


T>Интересный пример. Но задача вычисления факториала может быть решена даже не на C++, а на чистом C и существенно проще. Я просил от вас демонстрацию актуальной задачи, подразумевающей, что на C++ нет решения или оно кривое.


T>Для того, чтобы вы лучше поняли что я хочу увидеть,я приведу вам "пример наоборот". Всего два коротких куска кода, один из которых активно использует макросы (карты сообщений MFC)


T>
T>BEGIN_MESSAGE_MAP(CTryListViewView, CListView)
T>  ON_COMMAND(ID_SHOWALL, &CTryListViewView::OnShowall)
T>  ON_COMMAND(ID_SHOW_DISTINCT, &CTryListViewView::OnShowDistinct)
T>  ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, &CTryListViewView::OnNMCustomdraw)
[..skipped..]
T>    public CComCoClass<CExtPanel, &CLSID_ExtPanel>,
T>    public CComControl<CExtPanel>
T>{
T>...
T>}
T>


T>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?

Вопрос поставлен неправильно. Правильно он звучит так.
Зачем нам такое г@вно на D?

Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.

T>Или вы предлагаете хором перейти на VCL?

Нет, для MFC пожалуй не стоит использовать D.
Re[11]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 27.02.07 12:54
Оценка:
Здравствуйте, ie, Вы писали:

N>>Для обработки изображений (чем я и занимаюсь) не так уж и много языков подходят. На чём мне ещё писать?


ie>Тот же D будет несомненным шагом вперед


Да? Я, вот, работаю и не ощущаю никаких неудобств, связанных с С++. Это, значит, плохо? Сложности возникают при разработке алгоритмов, а реализуется всё достаточно быстро и в срок.

Далее: тут приводится куча аргументов о скорой смерти С++ (а значит и D) в связи с развитием С#/Nemerle. Зачем же мне учить мертворожденный язык?
Re[8]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.


Не у всех конечно. Но я то говорил о закономерности. А она на лицо.

Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не совсем так — там просто никто особо и не заботился о точном GC. Сам

C>язык, в общем и целом, позволяет использовать точный GC, но есть
C>несколько вещей, которые его запрещают (типа объединений в стиле С).

Там таких мест достаточно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Читал про nemerle немного. Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)


А у тебя задачи которые требуют нэйтив-код? Ты драйверы для Виндовс, что ли пишеш?

D>Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)


Вот видишь? А что же ты хочешь от других С++-программистов? Ты такой же блаб как и они. Ну, чуть-чуть более продвинутый. Но это ничего не меняет. Ты точно так же смотришь не более мощьный язык как на нечто странное с причудами. И у тебя точно так же не возникает желания сесть и разобраться что это за причуды и почему они были придуманы. А если бы напрягся, то глядишь Ди тебе уже и не показался бы каким-то там продвинутым.

D>Вы отчаянный Nemerle-ист!


Я не отчаянный и не Nemerle-ист.
Я вообще не -ист, и не -аст. Я просто не блалб который не может выйти за узкие рамки собственных привычкек и знаний.

D>А я C++ шник, все же.


Я 10 лет писал на С/С++. Так что кто из нас больше С++-ник еще можно поспорить.

D> Но нужно ведь постоянно что-то улучшать, адаптироваться и развиваться.


Зачем? С является вполне достаточным для написания любых программ. У него даже есть свои немалые приемущества. Он, например, отлично переносится на любую платформу.
С++ уже не изменялся с 98-го года (почти 10 лет). И все (почти все) им пользуются.

D> За 9 лет со времен принятия первого стандарта С++ многое изменилось, для IT индустрии такой срок — целая вечность.


Это твое воображение. На самом деле для людей которые что-то понимал в этой индустрии все изменилось еще 25 лет назад.

С++ в качестве прототипа имел язык окторый и сейчас во многом его привосходит — Simula. Этот язык в те времена имел средства рефлексии, вирутальные методы, GC и многое другое. Все это Страуступ принес в угоду производительности. Прошло 20 лет. GC и все остальное уже не вызвает существенных проблем с произодительностью, но никто этого не замечает. Ведь С++ откровенно проутюжил мозги массам и оболванил их до собсвтенного уровня. Целое поголение программистов смотрит на мир глазами С++.

D>Эх.. раз уж теперь эта ветка о философии.


Здесь эта ветка просто спешна. А вот в С++ она была грустна. Так как не может быть ничего грустнее чем борьба одной посредственности с другой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, konsoletyper, Вы писали:

D>>Читал про nemerle немного.


K>Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.


Это как раз самое прикольное. Ведь он тут уже разбился об стену непонимания со стороны своих коллекг С++-ников которые точно так же "немного почитали о Ди".
Но спроецировать на себя он это просто не в силах. Ведь то что он пока не постиг для него "что-то непонятное и закарючистое", а Ди понятен и логичен. Вот только чего при таком подходе ждать от других то? Для них Ди точно так же непонятен и закорючист.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Минусы VM:

D>- Это всегда ряд ограничений при сближении с платформой. Все зависит от VM, но в хорошей VM этих ограничений должно быть больше.
D>- Прерывания, порты ввода вывода, управление памятью и другая жизненная реальность — все это скрыто под занавесом виртуальной машины.
D>- Код под виртуальной машиной всегда будет медленнее native кода. Это элементарные законы математики, тут ничего нельзя изменить. Никакие технологии, и отчаянные попытки маркетологов не убедят в обратном.

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

D>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.


Эти минусы ни что иное как фобии. Так что же ты хочешь когда сталкиваешся с такими же фобиями по отношению к Ди? Нормальный процесс.

K>>Какие именно закорючки не понравились? Чем вообще синтаксис плох?


D>Говорю же — субъективно. Как С++ программисту, нравится С/C++ синтаксис, а лучше — если он проще, как в D.


Ну, а какие тогда претензии к тем, для кого Ди закорчюки "чисто субъективно"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Причём тут С++? Сами же привели несколько нормальных вариантов. Могу ещё школу вспомнить и Паскаль с Бейсиком — будет читабельно (не обязательно кратко).


А что нечитабельного ты увидел в:
Factorial(n : uint) : ulong
{
    | 0 | 1 => 1
    | _     => n * Factorial(n - 1)
}

или
Factorial(n : uint) : ulong
{
  if (n == 0 || n == 1) 1
  else n * Factorial(n - 1)
}



N>Для обработки изображений (чем я и занимаюсь) не так уж и много языков подходят. На чём мне ещё писать?


На самом деле для этого подходят очень много языков. Птосто ты знаешь только те что знаешь. Вот и все.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Disappear, Вы писали:

D>На D так:

D>
D>template factorial(int n)
D>{
D>  static if (n == 1)
D>    const factorial = 1;
D>  else
D>    const factorial = n * factorial!(n-1);
D>}
D>


Ну, вот и подумай насколько это глупый код!
Ты не сможешь его вызвать из программы. Он доступен только во время компиляции.
Я же свой код могу вызвать как во время компиляции, так и во время исполненения.
Это будет один и тот же код. Более того, он будет скомпилированным! И выполнится очень быстро.
Твой же код будет интерпретироваться компилятором. Конечно factorial-а это не проблема. Но мы же говорим не о нем?

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

В Nemerle же ты имешь возможность написать просто код и использовать его где тебе надо.
То есть мета-язык и просто язык — это одно и тоже!

D>кроме-того оптимизатор, может в compile-time посчитать такие функции:

D>int factorial(int n)
D>{
D> if (n == 1)
D> return 1;
D> else
D> return n * factorial(n — 1);
D>}

D>static int x = factorial(5);


D>Факториал — это только простейший пример, зачем на основе него строить какие-то выводы.


В том-то все и дело. Факториал — это примитившена.

Тут (на этом форуме) как то народ попытася повторить прмитивнеший пример реализованный на Немерле — реалзовать автоматический генератор паттерна "Абстрактная фабрика". И что ты думашь? Ни на С++, ни на D этот пример полностью поторить так и не удалось!
http://rsdn.ru/Forum/Message.aspx?mid=2311589&amp;only=1
Автор: VladD2
Дата: 21.01.07

Что-то удавалось, но на 100% все равно не получилось. Фабрика была или статичная, или ограниченная.
И это в том время как у парня реализовавшего фабрику на макросах Немерле ушло на ее реализацию не более часа времени.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, eao197, Вы писали:

E>Однако время для того, чтобы сейчас пробовать D в мелких proof-of-concept проектах вместо C++, уже пришло. ИМХО.


Не уж то С++-ники уже начали вымирать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Блин, Немерле, Немерле... Хватит дразниться, в конце концов!!!


А кто дразнит то?

ДГ>1. Что слышно насчет реализаций под линукс, и/или свободных реализаций? Когда ожидать?


К сожалению никаких новостей... с тех пор как была выпущена первая версия Nemerle она отлично работает под Моно на любой платформе где Моно поддерживается (включая Линуксы, МакОС и т.п.). Так что никаких новостей.

ДГ>2. И во что дело упирается — в нормальную VM? Не верю. Что им мешает в натив компилять?


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

ДГ>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?


А зачем "кроме". В прочем думаю будет еще интеграция с МоноДвелоп-ом.

ДГ>4. Вообще, какова текущая ситуация? Что куда компилируется и где это 'куда' может работать?

ДГ>Спасибо.

Ситуация такая. Исходники компилирются в сборки и работают под MS .Net Framework или Mono.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Еще вопрос: область применения, точнее наличие библиотек. В частности:


ДГ>- построение графических интерфейсов (и какова степень развитости этой либы)


MS Forms, #GTK, WPF. Развитие недостижимое для С++-библиотек.

ДГ>- коннекторы к SQL серверам


Любые доступные под Моно и дотентом. Фактически ко всем современным СУБД.

ДГ>- поддержка сетей (в частности, http(s)-клиента)


Все, в общем, и в частности.

ДГ>- возможности использования для серверной разработки


Полные, в общем, и в частности.

ДГ>- что ещё?


Черт его знает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 13:11
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Насколько я понимаю, всё это определяется платформой на которой работает немерле — .Net, думаю что есть в нём, ты в курсе.


+ еще Моно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вопрос снимается - Влад объяснил про сборки. [-]
От: Дм.Григорьев  
Дата: 27.02.07 13:17
Оценка:
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Библиотеки
От: Дм.Григорьев  
Дата: 27.02.07 13:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>MS Forms, #GTK, WPF. Развитие недостижимое для С++-библиотек.


И какая часть из них — открытая? Точнее, больше интересует бесплатность для разработчика, в т.ч. проприетарного софта (ибо на дядю работаю).
http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 13:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Это набор фибий. То что ты называешь "ряд ограничений" — это на самом деле назвается более высокий уровень абстракции.

VD>Прирвывания и порты недоступны тебе так как сорверменная ОС не позоляют получить прямой доступ к ним. А через посредников ты можешь получить к ним доступ хоть из ЯваСкрип.
VD>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++. Ведь скорость исполнения не меняется (инструкции процессора то те же), а вот возможностей по алгоритмической отимизации у меня болше (потому что язык выше уровенм, и я заню по более).

К сожалению практика, подтверждает все эти фобии (тормозит так, что шум стоит)

D>>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.


VD>Эти минусы ни что иное как фобии. Так что же ты хочешь когда сталкиваешся с такими же фобиями по отношению к Ди? Нормальный процесс.


Безусловно
Re[5]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 27.02.07 13:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития. Единственное разумное его применение — это подключение реализации интерфейсов. Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны.


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

P.S.

Надеюсь вы читали , что по этому поводу пишет Страуструп , ?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 13:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>>Читал про nemerle немного.


K>>Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.


VD>Это как раз самое прикольное. Ведь он тут уже разбился об стену непонимания со стороны своих коллекг С++-ников которые точно так же "немного почитали о Ди".

VD>Но спроецировать на себя он это просто не в силах. Ведь то что он пока не постиг для него "что-то непонятное и закарючистое", а Ди понятен и логичен. Вот только чего при таком подходе ждать от других то? Для них Ди точно так же непонятен и закорючист.

Я ничего не имею против Nemerle. Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.
Вот и спрашивается — причем тут Nemerle.
Re: Не пора ли нам перейти на D
От: _ace_ Россия acefsm.livejournal.com
Дата: 27.02.07 13:41
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

пора ^_^
Re[6]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 13:45
Оценка:
Здравствуйте, Tilir, Вы писали:

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


T>>>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?

D>>Вопрос поставлен неправильно. Правильно он звучит так.
D>>Зачем нам такое г@вно на D?

T>Вы только что назвали г@вном библиотеку, которая стабильно использовалась для написания невероятного количества кода. Рабочего, активно использующегося, стабильного. Хочу добавить — мою любимую библиотеку. Минус ставить не буду, но прошу сбавить градус снобизма.


D>>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.


T>А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?


Приходилось, все же с ATL удобнее. С Microsoft всегда удобно работать через инструменты от Microsoft, но на этом все заканчивается.
Да и причем тут COM — что, это панацея? Многие CORBA используют.

T>Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?). В общем резюме такое — для разработки программ чуточку сложнее Hello World, язык D пока что не имеет ни достаточной инфраструктуры, ни средств для переноса на него существующих библиотек с C++.


Да, за счет множественно наследования и неудачной организации процесса обработки сообщений, библиотеки ATL, MFC, WTL не годятся для современных языков. Приходилось мне, естественно, достаточно долго работать с каждой из этих библиотек.
Re[11]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 27.02.07 13:51
Оценка:
Здравствуйте, Disappear, Вы писали:

D> Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.

D>Вот и спрашивается — причем тут Nemerle.
Ну как бы у него статическая типизация и статическая компиляция имеется. В чем отличие от плюсов — принудительный GC и компиляция в байт-код.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[6]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 14:05
Оценка:
Здравствуйте, Tilir, Вы писали:


T>Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?).


На самом деле для реализации ATL/WTL множественное наследование не нужно. Оно там используется для реализации миксинов (CRT pattern).
А в D миксины встроены в язык, так что никаких проблем перетянуть туда твои любимые либы не будет, если кто-то действительно этого захочет.
От себя добавлю, что и выглядеть оно будет покрасивше, без всяких static_cast<T *>(this)
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[12]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 27.02.07 14:06
Оценка:
Здравствуйте, Disappear, Вы писали:


D>Не понял что подразумевается под словом "использовать"?

D>Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.
Re[13]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 14:08
Оценка:
Здравствуйте, deniok, Вы писали:

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



D>>Не понял что подразумевается под словом "использовать"?

D>>Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

D>Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.


Хороший подход, мне нравится. В D какраз нечто-подобное используется.
Re[14]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 27.02.07 14:26
Оценка:
Здравствуйте, Disappear, Вы писали:

D>>Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.


D>Хороший подход, мне нравится. В D какраз нечто-подобное используется.


А для чего тогда отдельный статический подъязык в первой версии факториала?
Re[10]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 15:31
Оценка:
Здравствуйте, Слоноежик, Вы писали:

С>
С>template eval(A...) { alias A eval; }

С>//использование
С>static result = eval!(factorial(5));

С>


Интересно-интересно. А способен eval отличить недетермирированные функции от детерминированных? Если нет — то это полная ж...
А вдруг:
1) функция factorial зависит от некторых глобальных переменных (которые инициализируются в main и соответственно не проиницализированы в момент выполнения этой функции на этапе компиляции);
2) функция factorial вызывает функции из внешних библиотек, о которых неизвестно детерминированы они или нет (я уж не говорю оразных версиях этих библиотек в момент компиляции и исполнения);
3) тупо зовет rand() или time();

Каким будет результат компиляции в этом случае? Или программист сам себе злой буратино, если написал такое? Если так, то чем это "лучше"
пресловутых граблей С/С++ с = & == ?

P.S. Вопрос относится не только к D, это скорее вопрос ко всем адептам compile-time вычислений. Если средства в современных языках, помогающие разруливать описанные ситуации? Если есть, то как?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 27.02.07 15:41
Оценка:
Здравствуйте, jedi, Вы писали:

J>P.S. Вопрос относится не только к D, это скорее вопрос ко всем адептам compile-time вычислений. Если средства в современных языках, помогающие разруливать описанные ситуации? Если есть, то как?


В Хаскелле эта проблема решена радикально — там все функции чистые, то есть в твоей терминологии детерминированные. Поэтому в TemplateHaskell таких проблем при квазицитировании не возникает.
Re[11]: Не пора ли нам перейти на D
От: Слоноежик  
Дата: 27.02.07 16:15
Оценка:
Здравствуйте, jedi, Вы писали:

J>Здравствуйте, Слоноежик, Вы писали:

J>Интересно-интересно. А способен eval отличить недетермирированные функции от детерминированных? Если нет — то это полная ж...
Относительно D cмотреть здесь

J>Каким будет результат компиляции в этом случае? Или программист сам себе злой буратино, если написал такое? Если так, то чем это "лучше"

Не скомпилируется.

J>пресловутых граблей С/С++ с = & == ?

В D эти грабли убрали

P.S. Адептом чего либо (в том числе и D) не являюсь.
для забивания гвоздя надо выбирать правильный микроскоп.
Re[10]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 27.02.07 16:43
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.

D>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.

Про статическую типизацию согласен. ИМХО чистую динамику в морг.
Но вот про нативность это ты зря.
Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.
А то что очень много чего до сих пор пишут под натив то это и есть костность мышления.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 16:52
Оценка:
Здравствуйте, deniok, Вы писали:

D>В Хаскелле эта проблема решена радикально — там все функции чистые, то есть в твоей терминологии детерминированные. Поэтому в TemplateHaskell таких проблем при квазицитировании не возникает.


В Хаскелле нет возможности использовать внешние модули? Нет функций time() & rand().

P.S. Я спрашиваю потому что хочу знать, а не для того чтобы поподкалывать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[12]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 16:52
Оценка:
Здравствуйте, Слоноежик, Вы писали:

J>>Каким будет результат компиляции в этом случае? Или программист сам себе злой буратино, если написал такое? Если так, то чем это "лучше"

С>Не скомпилируется.

Так вот как раз интересно узнать как они это сделали? Нельзя вызывать функции из внешних модулей в compile-time?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Не пора ли нам перейти на D
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 27.02.07 16:57
Оценка:
Здравствуйте, Disappear, Вы писали:

VD>>Ды ты вот на свои рассуждения погляди. Ты спрашиваеш у людей почему бы в место устаревшего 10 лет назад языка не использовать новый который чуть лучше чем предыдущий. Но даже не задумываешся над тем, что он так же морально устарел.


D>Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.

D>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.



Просвяти, что же такое "ПО мирового масштаба"
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[13]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 27.02.07 17:23
Оценка:
Здравствуйте, jedi, Вы писали:


J>В Хаскелле нет возможности использовать внешние модули? Нет функций time() & rand().


Есть. Есть. Только тип возвращаемого значения упакован в монаду IO:
getCPUTime :: IO Integer
randomIO :: IO a


Про монады (и IO как частный случай) в двух словах не рассказать. Недавно была бурная ветка здесь
Автор: Mirrorer
Дата: 08.02.07
.
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, Disappear, Вы писали:

D>К сожалению практика, подтверждает все эти фобии (тормозит так, что шум стоит)


Прости, но это безотвественный треп.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Я ничего не имею против Nemerle. Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.


Ну, и чем же Nemerle тут не подходит?

D>Вот и спрашивается — причем тут Nemerle.


Дык это как раз статически тпизированный язык со статической компиляцией (что в общем-то бред, так как компиляция она и Африке компиляция).

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

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

Можно зайти и с другой стороны и подумать о том, что не нравится в С++. Сформулирвоать требования от противного, тык-сызыть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, Mirrorer, Вы писали:

M>Ну как бы у него статическая типизация и статическая компиляция имеется. В чем отличие от плюсов — принудительный GC и компиляция в байт-код.


Я бы сказал, что байт-код тоже не существеннен. В итоге ведь все равно имеем нэйтив-код.

А вот что их действительно отличает — это наличиеразвитого рантайма. Это значит наличие GC, рефлексии, динамической компиляци, защиты. Вот только в моем разуме это все приемущества, а не недостатки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
VD>>Ну, вот и подумай насколько это глупый код!
VD>>Ты не сможешь его вызвать из программы. Он доступен только во время компиляции.
VD>>Я же свой код могу вызвать как во время компиляции, так и во время исполненения.
VD>>Это будет один и тот же код. Более того, он будет скомпилированным! И выполнится очень быстро.
VD>>Твой же код будет интерпретироваться компилятором. Конечно factorial-а это не проблема. Но мы же говорим не о нем?

D>Не понял что подразумевается под словом "использовать"?


Извини, я не нашел в своих словах этого слова.

D>Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.


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

Еще раз попробую разживать свои слова.

Итак, что делаешь ты? Ты пишешь код используя разные выкрутасы Ди, чтобы можно было выполнить этот код во время компиляции. При этом ты уже не сможешь использовать этот же код во время выполнения, так как он использует разные статические конструкции (вроде static if).

Я же пишу код не используя никаую ахинею вроде "static if". Я просто пишу код и компилирую его в бинарный модуль. После этого я имею возможность как выполнить этот код в рантайме, так и во время компиляции! По сути я прост заставляю компилятор вызвать мою библиотеку! Твои static if будут интерпретироваться компилятором, в то время как мой код будет скомпилирован в нэйтив, а значит не будет интерпретироваться. Так что я получаю скорость и гибкость.

D>Опять Немерле.


А ты думал?! Ты даже не понимаешь на сколько D убог по сравнению с ним. Это как сравнивать потифон с современным звуковой HI-Fi-системой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Хороший подход, мне нравится. В D какраз нечто-подобное используется.


Не. В D ты вынужден использовать специальный интерпретируемый подязык чтобы выразить вычисления времени компиляции. Это далеко не тот же язык. Поробуй, например, с его помощью загрузить что-то из внешнего файла (или записать что-то во внешний файл). У меня это получится очень прость.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, Слоноежик, Вы писали:

С>и макроса который заставляет вычислить ф-цию в время компиляции


С>
С>template eval(A...) { alias A eval; }

С>//использование
С>static result = eval!(factorial(5));

С>


С>И в отличии от Nemerle не надо для каждой функции писать макрос обертку.


Дык, интерпретатор ведь.

ОК. Уложним условие. Попробуй создать аналог вот такой примитивной вещи:
macro LoadStringLiteralFromFile(fileName : string)
{
  def str File.ReadAllText(fileName);
    <[ $(str : string) ]>
}

Что не выходит?

VD>>В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.

VD>>То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.
С>Ну D это уже не относится.

Еще как отностися. Метакод в D пишется не на базовом D, а на статических расширениях.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 17:25
Оценка:
Здравствуйте, deniok, Вы писали:

J>>P.S. Вопрос относится не только к D, это скорее вопрос ко всем адептам compile-time вычислений. Если средства в современных языках, помогающие разруливать описанные ситуации? Если есть, то как?


D>В Хаскелле эта проблема решена радикально — там все функции чистые, то есть в твоей терминологии детерминированные. Поэтому в TemplateHaskell таких проблем при квазицитировании не возникает.


В Хаскеле есть монада IO с помощью которой все что хочешь сделать можно (любой побочный эффект). Но причем тут Хасель? Темболее причем тут ТемплэйтХаскель? В нем как раз применен подход аналогичный Немерлевому. Можно даже сазать, что Немерле равивает этот подход.

ЗЫ

А вообще, язык не позволяющий вызват функцию random — это само по себе было бы смешно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 27.02.07 17:28
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.


А что такое ПО мирового масштаба, кто его делает и почему там используют native языки?

Похоже, это уже даже не софт для АЭС...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[12]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 27.02.07 17:29
Оценка:
Здравствуйте, Слоноежик, Вы писали:

J>>Здравствуйте, Слоноежик, Вы писали:

J>>Интересно-интересно. А способен eval отличить недетермирированные функции от детерминированных? Если нет — то это полная ж...
С>Относительно D cмотреть здесь
Такое можно сделать на немерле раз и навсегда написанным макросом.
Вот только кому нужно решение с такими драконовскими ограничениями как в D?
Правильно тем кто ничего лучше не видел.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 17:34
Оценка:
Здравствуйте, fmiracle, Вы писали:

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


D>>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.


F>А что такое ПО мирового масштаба, кто его делает и почему там используют native языки?


F>Похоже, это уже даже не софт для АЭС...


И даже не CRM система для нового склада памперсов...
Re[11]: Не пора ли нам перейти на D
От: Disappear  
Дата: 27.02.07 17:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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


[..skipped..]
VD>Все отличие тебя от них в том, что ты немного задумался над тем, что происходит. Но как только тебе попробовали показать "как глубока эта заячья нора" ты сразу же решил, что лучше зашорить глаза и оставаться жить в своем мире.

Почему вы так часто переходите на личности? Этот и другие языке мне интересны чисто из академических интересов. Для работы, по прежнему нет ничего лучше старых добрых инструментов — это дело привычки.
Речь шла, о возможности постепенного перехода к использованию других инструментов. И что бы дала эта возможность.
По сути дела, то что было высказано в этой ветке, могло бы нести обьективный характер — за и против. Но, как оказалось, многие не считают, что можно обсуждать такие темы, потомучто в массах преобладает "эффект блаба", народная истерия, костность дедушкиной бороды или что еще там...
Быть может, люди не такие тупые, как Вы о них думаете? И даже С++ программисты.
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 18:31
Оценка:
Здравствуйте, jedi, Вы писали:

J>Так вот как раз интересно узнать как они это сделали? Нельзя вызывать функции из внешних модулей в compile-time?


Ага. Фактически Ди позволяет делать только две вещи. Описывать код который использует явные операции времени компиляции (const, static if и т.п.), а так же позволяет сам вычислить некоторые функции которые могут быть вычеслены в процессе свертки констант (то есть все входные данные которых константны). Фактически воторое это продвинутый констант-фолдинг. Даже в С можно было написать:
int x = 3 * 4 + 2;

и это подсчитается в компайл-тайме. В Ди это правило расширили позволив сворачивать выражения с простыми функциями.

Однако полезность от этого сильно не вырастает. В метакоде как раз нужно иметь возможность произвольных вычислений. А этого как раз нет.

Недавно в Ди пытались ввести "строковые макросы". Это небольшой шаг вперед. Но шаг дико кривой и не полноценный. Если они пойдут по првильному пути то где-то через год-другой (гы-гы) они дойдут до квази-цитирования и полноценных макросов. Хотя не факт что дойдут.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 18:31
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Я пытался найти реальные недостатки МН, но к сожалению не смог. Единственный недостаток о котором я слышал это передваваемое из уст в уста легенда о недостатках МН . Пожалуйста подскажите мне , где я могу почитать об этом ?


http://en.wikipedia.org/wiki/Diamond_problem

M>Надеюсь вы читали , что по этому поводу пишет Страуструп , ?


Да, читал. И не только по этому поводу. Мне интересно другое. Появилось бы в С++ МН если бы Страуструп в свое время додумался бы до трэйтсов/миксинов?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 18:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> поливание D грязью опущено


Секундочку. Т.е. "правильные" языки позволяют вызывать недетерминированные ф-ции в compile-time? Как тогда в них решаются проблемы мной описанные?

P.S. Я не спрашивал почему D такой хреновый, я спросил как в языках поддерживающих compile time вычисления решаются проблемы с вызовом недетриминированных ф-ций (или может это не считается проблемой вовсе и программист вправе превратить процесс компиляции в процесс генерации случайного байт-кода).
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 27.02.07 19:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.


Это про текущий момент или о перспективе?
now playing: Angelzero — Laroux
Re[11]: Не пора ли нам перейти на D
От: Слоноежик  
Дата: 27.02.07 19:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Слоноежик, Вы писали:


[много всего вытоптано]

VD>ОК. Уложним условие. Попробуй создать аналог вот такой примитивной вещи:

VD>
VD>macro LoadStringLiteralFromFile(fileName : string)
VD>{
VD>  def str File.ReadAllText(fileName);
VD>    <[ $(str : string) ]>
VD>}
VD>

VD>Что не выходит?

Нет. Но я ни капельки даже не расстроен. Никто вообще и не говорил что круче D только яйца, а про то что Nemerle есть Слово Господне... (ну в крайнем случае идеальный язык всех времен и народов) по крайней мере на этом форуме твердится постоянно.
Относительно примера — вызов метода из рантайма во время компиляции — это конечно интересная идея, но на практике это есть великое зло.

VD>>>В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.

VD>>>То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.
С>>Ну D это уже не относится.
VD>Еще как отностися. Метакод в D пишется не на базовом D, а на статических расширениях.
И что из этого. Правильное решение. D как впрочем и CLI не может гарантировать отсутсвие побочных эффектов. Сомневаюсь — что кому нибудь понравится функция которая вычисляет правильное значение только по чертвергам в полнолуние.

На сим откланяюсь.

P.S. Принимать участие в дальнейшем флейме не вижу никакого смысла.
для забивания гвоздя надо выбирать правильный микроскоп.
Re[15]: Не пора ли нам перейти на D
От: fmiracle  
Дата: 27.02.07 19:34
Оценка:
Здравствуйте, jedi, Вы писали:

J>P.S. Я не спрашивал почему D такой хреновый, я спросил как в языках поддерживающих compile time вычисления решаются проблемы с вызовом недетриминированных ф-ций (или может это не считается проблемой вовсе и программист вправе превратить процесс компиляции в процесс генерации случайного байт-кода).


Программист даже на самом строгом языке может с легкостью нагенерить совершенно случайного кода.
Язык должен представлять защиту от случайных ошибок. Если же програмист использует кодогенерацию на основе вызовов rand(), то тут никакая защита не поможет...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 19:50
Оценка:
Здравствуйте, Disappear, Вы писали:

F>>Похоже, это уже даже не софт для АЭС...


D>И даже не CRM система для нового склада памперсов...


Небольшая справка. "Софт для АЭС" — это такой прикло который постоянно всплывает как последний аргумент против управляемых сред. В общем, "Софт для АЭС" стал таким примера притянутого за уши аргумента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 19:50
Оценка:
Здравствуйте, jedi, Вы писали:

J>Секундочку. Т.е. "правильные" языки позволяют вызывать недетерминированные ф-ции в compile-time? Как тогда в них решаются проблемы мной описанные?


Я не в курсе какие проблемы ты описал. Но правильные языки действительно повзволюят вызвать во время компиляции любой код.

J>P.S. Я не спрашивал почему D такой хреновый, я спросил как в языках поддерживающих compile time вычисления решаются проблемы с вызовом недетриминированных ф-ций (или может это не считается проблемой вовсе и программист вправе превратить процесс компиляции в процесс генерации случайного байт-кода).


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

Если есть боязнь за то что можно "свалить" компилятор, то утешу тем, что свалить его можно и так. Создай вечный цикл в компиляторе. Этого будет достаточно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 20:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я не в курсе какие проблемы ты описал. Но правильные языки действительно повзволюят вызвать во время компиляции любой код.


Хороший повод читать всю ветку, а не последнее сообщение в ней .

Ок, самоцитируюсь (было 4-мя постами выше):

А вдруг:
1) функция factorial зависит от некторых глобальных переменных (которые инициализируются в main и соответственно не проиницализированы в момент выполнения этой функции на этапе компиляции);
2) функция factorial вызывает функции из внешних библиотек, о которых неизвестно детерминированы они или нет (я уж не говорю оразных версиях этих библиотек в момент компиляции и исполнения);
3) тупо зовет rand() или time();

VD>Программист всегда прав. Если он вменяем, то его код будет дейсвовать только во благо.


Ага, он также прав когда пишет =, а имел в виду ==. От глупых ошибок никто не застрахован (тем более в сторонних либах).

VD>Ошибки конечно возможны, но в большинстве случаев они приввдут только в выдаче соотвествующих сообщений об ошибках.


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

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


Нет, этого я не боюсь.

P.S. Ради бога, не нужно сводить все к флейму. Я задал вполне конкретный вопрос, а в результате услышал:
1) D — отстой;
2) "Программист всегда прав";
3) "правильные языки действительно повзволюят вызвать во время компиляции любой код".

Конструктивнее, пожалуйста
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[12]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 27.02.07 20:20
Оценка:
Здравствуйте, Слоноежик, Вы писали:

С>Нет. Но я ни капельки даже не расстроен. Никто вообще и не говорил что круче D только яйца, а про то что Nemerle есть Слово Господне... (ну в крайнем случае идеальный язык всех времен и народов) по крайней мере на этом форуме твердится постоянно.

Не нат. Говорят что это один из лучших языков на текущий момент.

С>Относительно примера — вызов метода из рантайма во время компиляции — это конечно интересная идея, но на практике это есть великое зло.

Это еще по чему?

С>На сим откланяюсь.


С>P.S. Принимать участие в дальнейшем флейме не вижу никакого смысла.

Разговор только начался, а ты уже в кусты?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 27.02.07 20:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>>Я пытался найти реальные недостатки МН, но к сожалению не смог. Единственный недостаток о котором я слышал это передваваемое из уст в уста легенда о недостатках МН . Пожалуйста подскажите мне , где я могу почитать об этом ?


VD>http://en.wikipedia.org/wiki/Diamond_problem


Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?


M>>Надеюсь вы читали , что по этому поводу пишет Страуструп , ?


VD>Да, читал. И не только по этому поводу. Мне интересно другое. Появилось бы в С++ МН если бы Страуструп в свое время додумался бы до трэйтсов/миксинов?


Или что то путаю , или миксины создают различную имплементацию много раз ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 21:55
Оценка:
Здравствуйте, jedi, Вы писали:

J>Хороший повод читать всю ветку, а не последнее сообщение в ней .


J>Ок, самоцитируюсь (было 4-мя постами выше):


J>А вдруг:

J>1) функция factorial зависит от некторых глобальных переменных (которые инициализируются в main и соответственно не проиницализированы в момент выполнения этой функции на этапе компиляции);
J>2) функция factorial вызывает функции из внешних библиотек, о которых неизвестно детерминированы они или нет (я уж не говорю оразных версиях этих библиотек в момент компиляции и исполнения);
J>3) тупо зовет rand() или time();

Это я читал. Только проблемы тут я не увидил. Это же приемущество, что мой код может сделать что-то полезное.

VD>>Программист всегда прав. Если он вменяем, то его код будет дейсвовать только во благо.


J>Ага, он также прав когда пишет =, а имел в виду ==. От глупых ошибок никто не застрахован (тем более в сторонних либах).


Ну, конкретно от этого не застрахован только тот кто пользуется С++, а точнее его плохими компиляторами. Хотя конечно ошибки бывают у всех. Но ошибка есть ошибка. Ее надо устранять. Кроме того язык надо проектировать так, чтобы избегать максимальное количество классов ошибок. И тут у Nemerle есть немало приемуществ. Потому на нем можно без проблем писать мета-код.

VD>>Ошибки конечно возможны, но в большинстве случаев они приввдут только в выдаче соотвествующих сообщений об ошибках.


J>Вот, уже ближе. Теперь конкртней, что за сообщения об ошибках? Как компилятор вообще узнает что их нужно выдать?


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

Естествно, что паравишьный язык позволяет выдавать и сообщения об ошибки штатными средствами компилятора. Но это умеет и Ди. Это только С++ не умеет.

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


J>Нет, этого я не боюсь.


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

J>P.S. Ради бога, не нужно сводить все к флейму.


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

J> Я задал вполне конкретный вопрос, а в результате услышал:

J>1) D — отстой;
Почему отстой? Он просто недостаточно хорош чтобы претендовать на лидерство.

J>2) "Программист всегда прав";

J>3) "правильные языки действительно повзволюят вызвать во время компиляции любой код".

J>Конструктивнее, пожалуйста


А что не конструктивно? Может быть лучше повернуть вопрос по другому?
Может лучше ты сам обоснуешь почему нельзя вызвать недетерминированные фукнции внутри мета-кода?

Лично у меня даже нет сомнений, что без этого смысл в мета-коде стремится к нулю. Ну, что простите, за фигня если я не могу вызвать библиотечную функцию внутри мета-программы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 21:55
Оценка:
Здравствуйте, Слоноежик, Вы писали:
VD>>Что не выходит?

С>Нет.


От и я о том же.

С> Но я ни капельки даже не расстроен.


Оптимизм — это хорошо!

С>Никто вообще и не говорил что круче D только яйца, а про то что Nemerle есть Слово Господне...


И правда такого наверно никто не говорил. Но сама данная тема явно свидетельствует о том, что D в глазах автора являет нечто большее чем просто заурядный ЯП. А ее развитие (закономерное с моей точки зрения) показывает, что его явно не понимают/не принимают его точки зрения.

С>Относительно примера — вызов метода из рантайма во время компиляции — это конечно интересная идея, но на практике это есть великое зло.


Дык, обоснуй. Обсудим. С моей точки зрения (того кто пробовал это делать) все ОК. Ну, и следовательно слова "на практике это есть великое зло" не более чем фобия.

VD>>Еще как отностися. Метакод в D пишется не на базовом D, а на статических расширениях.

С>И что из этого. Правильное решение.

В чем его правильность? В том что надо использовать второй — ограниченный и интерпретируемый язык вместо того чтобы использовать исходный и мощьный язык?

С> D как впрочем и CLI не может гарантировать отсутсвие побочных эффектов. Сомневаюсь — что кому нибудь понравится функция которая вычисляет правильное значение только по чертвергам в полнолуние.


Побочный эффект — это главное что добиваются от шаблонного метапрограммирования (ШМП) в С++ и Ди. Причем С++ реализация более чистая, так как ди имеет откровенные средства императивного программирования времени компиляции.

Суть ШМП в том, чтобы порождать некие структуры или код в зависимости от некоторых входных настроек (данных). Так что просто несерьезное утверждение.

С>P.S. Принимать участие в дальнейшем флейме не вижу никакого смысла.


Правильно. Для этого прийдется изучить что-то нове. А это всегда напрягает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: jedi Мухосранск  
Дата: 27.02.07 22:51
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Может лучше ты сам обоснуешь почему нельзя вызвать недетерминированные фукнции внутри мета-кода?


VD>Лично у меня даже нет сомнений, что без этого смысл в мета-коде стремится к нулю. Ну, что простите, за фигня если я не могу вызвать библиотечную функцию внутри мета-программы?


Знал бы почему — обосновал бы . В принципе, я понял твою точку зрения. К тому же выше fmiracle & WolfHound также привели достаточно весомые аргументы. Теперь надо бы подумать над этим

В общем-то суть в том, что у меня никогда не возникало необходимости звать что-то недетерминированное в рантайме. Даже кодогенерация зависит только от своих параметров (заготовка-описание, код на DSL итп), те детерминированна. Когда же мне сказали, что можно звать абсолютно все, я немного испугался. Теперь успокоился и понял, что это просто инструмент — такой же как и другие, обычный. Бъет по лбу (программиста сразу или юзера — через месяц), если что-то напортачил.

Короче, compile-time code execution — это просто возможность писать все на одном языке, не привлекая скрипты и внешние тулзы для кодогенерации. Ничего сверхъестественного. ИМХО, кроме всех очевидных плюсов, здесь есть минус — хитрый метакод запрятан в исходниках и внешне (в файл-менеджере) неотличим от "обычного" кода. Эта проблема решается, видимо, только тщательным документированием ...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 22:58
Оценка:
Здравствуйте, jedi, Вы писали:

J>Дело не в том ... rand() — это просто пример недетерминированной функции. Другим примером может быть предположение о наличии какого-то файла на диске,


И в чем проблема? Ну, скажет тебе компилятор "Нет нужного мне файла. Ивини комрад!", и что?

J>какие-то тонкие предположения о наличии у пользователя каких то-прав в системе, наличие интернета в момент компиляции, да мало ли еще что.


Опять же или компилятор ругнется и подскажет что делать, или ты имеешь пример плохого кода. Ты же не страдаешь от того, что бюбая библиотека или любой код может быть плохим и приводить к проблеме?

J>Т.е. возникает неявная (!) возможность того, что компилируемость кода зависит от внешних факторов никак не отраженных в исходнике (напр. если происходит вызов внешней либы).


Дык ты уже так или иноче от этого зависишь. Ты же не компилируешь (надеюсь) исходники из командной строки? Ты ведь скорее всего пользуешся неким build-engine-ом? А он и есть внешнаяя утилита без которой проект не собрать. А разные Ant-ы и MSBuild-ы к тому же расширяются именно что библоиотеками.

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

J>очень хитрого вируса. Нет, в самом коде не будет "format c:", но какой-то хитрый макрос будет вызывать какую-то стандартную либу и использовать дыры в ней. Да мало ли ужастей можно придумать?

В коде самом по себе может быть все что захочишь и если ты скачал его, скомпилировал и зпустил, то вирус можно поймать легко. Правда вероятность этого приблежается к нулю. Но все же. Опять же те же Ant и MSBuild точно так же позволяют загрузить любую фигню. VS даже честно предупреждает тебя о такой опасности когда ты открывашь изменный проект (хотя молчит когда в проекте вызвается внешняя утилита, что смешно).

J>Я понимаю, что это все может показаться надуманным,


Ага. Именно этим и кажется.

J>но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек


Дык любой мощьный инструмент это плака о двух концах. Ядерная энергия тоже опасна. Но все же приемущества ее исползования в мирных целях превышают опасность и люди решаются на ее использование. Точно так же и с мощью макросов. Да, скопировав левый макрос можно одхватить вирус. Но и возможности у него куда больше чем у беззубых и переусложныенных шаблонных решений в С++. Ведь ты можешь приконектится не к кридитке, а к СУБД и скачать не пины, а информацию о структуре БД сгенерировав по ним нужные тебе классы, например.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 22:58
Оценка:
Здравствуйте, minorlogic, Вы писали:

VD>>http://en.wikipedia.org/wiki/Diamond_problem


M>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?


Это где же такое написанно?

M>Или что то путаю , или миксины создают различную имплементацию много раз ?


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

Но забавно, что языки в которых есть фукнции высшего порядка зачастую вообще позволяют использоват другую технику. Лично я вообще не нуждался в МН в посление годы. Как-то привыкаешь проектировать без этго и получается даже лучше. Хотя возможно тут причаной является банальное повышение опыта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:19
Оценка:
Здравствуйте, jedi, Вы писали:

J>Знал бы почему — обосновал бы . В принципе, я понял твою точку зрения. К тому же выше fmiracle & WolfHound также привели достаточно весомые аргументы. Теперь надо бы подумать над этим


Хороший подход.

J>В общем-то суть в том, что у меня никогда не возникало необходимости звать что-то недетерминированное в рантайме. Даже кодогенерация зависит только от своих параметров (заготовка-описание, код на DSL итп), те детерминированна.


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

Однако на уровне реализации тебе все равно может понадобится некий не дерерминрованный код. Хотя бы ради быстродействия. Ведь недетерминированность и наличие побочных эффектов не совсем одно и то же. Например, быстрая сортировка массива совершенно детерминированная функция, но в процессе работы она меняет исходный массив. К тому же ее детерминированность зависит от фукнций сравнения. Если они будут кривыми, то и разультат будет не поределенным.

J> Когда же мне сказали, что можно звать абсолютно все, я немного испугался. Теперь успокоился и понял, что это просто инструмент — такой же как и другие, обычный. Бъет по лбу (программиста сразу или юзера — через месяц), если что-то напортачил.


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

J>Короче, compile-time code execution — это просто возможность писать все на одном языке, не привлекая скрипты и внешние тулзы для кодогенерации.


Именно. Но это только одна сторона. Ведь данный подход к тому же существенно упрощает создание метапрограмм. У него есть возможности контроллированной генерации коад и возможности анализировать код прогаммы и даже производить его декомпозицию. В купе это дает офигительно мощьное решение повзоляющее иногда писать мета-код проще чем писать прикладной код на С++.

J> Ничего сверхъестественного.


Так и есть. Хотя конечно если не изучить как это устроено, то выглядит магией. А некоторые вообще по началу не верят, что такое возможно.

J>ИМХО, кроме всех очевидных плюсов, здесь есть минус — хитрый метакод запрятан в исходниках и внешне (в файл-менеджере) неотличим от "обычного" кода. Эта проблема решается, видимо, только тщательным документированием ...


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

И на самом деле это еще только поверхностный взгляд. Рельно макросы могут менять синтаксис языка (страшно? ), стркуткуру программы и многое другое! Они даже могут парсить текстовые строки в компайлатайме. Например, для вывода в строку в Nemerle исползуется стандратный макрос которые овзоляет использовать похожую на php/Ruby — квази-строки:
def x = 1;
WriteLine($"x = $x; x + 2 = $(x + 2)");

этот код выведет:
x = 1; x + 2 = 3

в общем, магия для не посвещенных, и огромные возможности для посвященных.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:20
Оценка:
Здравствуйте, Слоноежик, Вы писали:

С>>И что из этого. Правильное решение. D как впрочем и CLI не может гарантировать отсутсвие побочных эффектов. Сомневаюсь — что кому нибудь понравится функция которая вычисляет правильное значение только по чертвергам в полнолуние.

С>Досадный Глюк. естественно не CLI а CLR

Ага. Это досадный глюк присуствует даже в машине Тьюринга.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Nemerle - еще вопрос
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:27
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Т.е. у нас есть Windows и кусочек Linux, это хорошо.


Не совсем. У нас есть дотне и Моно. Моно — это эдакий не очень хороший (более медленный) дотент в котром меньше библиотек, но который переносим почти как же как С, так как его исходники это процента на 3 С-код, а остальное написано на C#.

Так что можно сказать, что у нас есть Windows, Linux и даже МакОС, но Windows немного ровнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.07 23:31
Оценка:
Здравствуйте, Kisloid, Вы писали:

ДГ>>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?


K>MonoDevelop — кроссплатформенно.


Откровенно говоря когда мы взялись за работу над Интекрацией с VS, то поломали тот что было сделано для MonoDevelop, так как там все было очень криво, а эти ребята не сумели абстрагироваться от компилятора. Но сейчас все развянано и можно даже использовать наши наработки для создания следующией версии Интеграции с MonoDevelop.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Не пора ли нам перейти на D
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 28.02.07 01:50
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Практика программирования уже успела многое сказать о пригодности интерфейса STL


Да я привел STL и wxWidgets в качестве примера библиотек в предположении, что для коммерческого использования потребуется перевод на D аналогичных по сложности библиотек.
Re[9]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 28.02.07 03:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>http://en.wikipedia.org/wiki/Diamond_problem


M>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?


VD>Это где же такое написанно?


C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.


M>>Или что то путаю , или миксины создают различную имплементацию много раз ?


VD>Миксины,точнее трэйтсы (это более продуманная реализация) не приводит к наследованию. Мы как бы просто приказываем компилятору скопировать код в наш класс и тем самым добавить в него нужную нам фукнциональность. Тоже самое конечно можно сделать просто копи-пэстом, но при этом начинается проблема копи-пэста, когда повяляются множество копий одного и того же (по сути) кода и она могут оказаться арссинхронизированными. Тут же копирование проихводится во время компиляции, что устраняет проблему рассинхронизации.

VD>К тому же трэйтсы предполагают еще и средства разруливания неоднозначностей. Так методы можно переименовывать, ипотрировать толко для реализации методов интерфейсов и замещать методами из класса в который производится импорт.

VD>Но забавно, что языки в которых есть фукнции высшего порядка зачастую вообще позволяют использоват другую технику. Лично я вообще не нуждался в МН в посление годы. Как-то привыкаешь проектировать без этго и получается даже лучше. Хотя возможно тут причаной является банальное повышение опыта.


Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 28.02.07 03:07
Оценка:
M>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

Описался , имел ввиду наследование в общем.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[13]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 28.02.07 06:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я бы сказал, что байт-код тоже не существеннен. В итоге ведь все равно имеем нэйтив-код.

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

VD>А вот что их действительно отличает — это наличиеразвитого рантайма. Это значит наличие GC, рефлексии, динамической компиляци, защиты. Вот только в моем разуме это все приемущества, а не недостатки.

Веришь, в моем тоже Хотя конечно все от задач зависит. Но задач, которым нужен с++ с его возожностью ручного управления памятью я вижу все меньше и меньше...
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[12]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 28.02.07 08:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Реакция обычно следующая. Сначала полное не понимание и безразличие. Потом страх и животная неприязнь. Потом разбитое состояние, ощущения расстерянности вызванное тем, что человек начинает понимать, что знакомые идеомы, навыки и т.п. все-все-все — это много лет не лучшим образом проведенной жизни. Далее есть варианты. Сильный человек оценивает достоинства и недостатки и выбирает более мощьный и простой язык, а мнее сильный обычно просто говорит себе — ну и хрен с ним — и поглубже зарывает голову в песок.


Ээээ C++ ?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[8]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 28.02.07 09:43
Оценка:
Tilir wrote:
> Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы
> разрушим до основанья, а затем... Вот есть большие подозрения, что затем
> окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал
> C подмножеством C++.
D замечательно интегрируется с С. Но не с С++.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[13]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 28.02.07 11:59
Оценка:
Sinclair wrote:
> D>Никие ощущения VM вам не помогут, когда дело дойдет до отладки
> системных API.
> А что, вызовы системных API из управляемой среды ощущаются как-то иначе,
> чем они же из С++?
Вообще-то, обычно да. Той же JVM/C# приходится сделать достаточно много
работы для вызова неуправляемого кода — за-pin'ить объекты, сохранить
контекст GC и т.п.

В обычных системах это часто может маскироваться затратами на
переключение контекста, но я сейчас работаю на встроеной системе без MMU
— так там overhead вполне заметен.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 28.02.07 12:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

M>>>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?
VD>>>Это где же такое написанно?
M>>C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.
S>Это не решение. Это и есть проблема. Во-первых, понять вот эту концепцию виртуального и невиртуального наследования крайне трудно. А главное — зачем?

Я встречал людей делящихся на 2 типа по отношению к МН, те которые его понимают и те которые его просто не знают. А вы мне говорите про какие то сложности ? Видимо вы исключение из правил.


S> Вот покажите мне хоть один жизненный пример смешивания виртуального наследования с невиртуальным!

Классический пример — наследование реализации для иерархии интерфейсов.

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


Для вас нет ?



M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

Не факт , но мне хочется иметь возможность выбрать , а вам ?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[14]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 28.02.07 13:48
Оценка:
Здравствуйте, minorlogic, Вы поставили минус:

Те ты считаешь что С++ простой и мощьный?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 15:42
Оценка:
Здравствуйте, Mirrorer, Вы писали:

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


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

M>Веришь, в моем тоже Хотя конечно все от задач зависит. Но задач, которым нужен с++ с его возожностью ручного управления памятью я вижу все меньше и меньше...


+1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 15:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

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

Например, для разрешения ссылок на множество базовых классов в С++ часто испльзуется "двойной" указатель (на 32-битных платформах его размер обычно больше 32-х бит). Это вынуждает компилятор порождать код пересчета адресов, что естественно отражается на скорости вызова метода доводя его до скорости вызова интерфейса в дотнете. А раз так, ток каой смысл заниматься всеми этими сложностями?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Библиотеки
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 15:42
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Похоже на то, что WPF будет реализовать на порядок проще для любых платформ, чем Windows.Forms (или даже на несколько порядков проще и переносимей)


WPF — сложная библиотека (большой объем кода). Единственное ее приемещество — она сразу рассчитана на довольно малый по объему модуль нэйтив-кода и не завист огромного WinAPI. Но объем работ все же не позволит быстро и лего ее реализовать. Так что будучи реализованной ее наверно действительно будет легко переностить, но вот реализовать ее будет не просто.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Библиотеки
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 16:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А рефлектор на что?


Они же не могут украсть исходники 1 в 1? Тогда вообще не ясно зачем рефлектор. Сборки ведь перенесутся на ура. Создать только интеропные нэйтив-библиотеки и все.
Только при этом их МС сразу за жабры возьмет.

V>Просто я с трудом представляю себе суммарный объем работы для того, чтобы заставить на Линухе полноценно работать c Windows.Forms.


Тем не менее болшая часть (по их словам) уже работает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: demi США  
Дата: 28.02.07 16:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Не дешевеет. Просто он за тоже время может сделать больше.
WH>В этом смысле для работодателя программист дешевле и это хорошо.
WH>Но никаких причин платить меньше нет ибо хороших программистов всегда мало и никакие технологии это не изменят.

С одной сторон меня это обраджовало, но потом подумал к каким себя причислить. С другой, это означает что программистский труд будет далее делиться на уровни. Уже "отпочковались" тестеры, архитекторы. Далее наверно будет по платформам — (Java, .NET, С++), (embedded-asm-C-WinAPI), (ASP/интернет/HTML,cкриптеры) — так сказать выбирай по способностям Причем в скобках группы так сказать — базисные, низовые или железячники, и GUI-сты. Кстати, много ли есть контор сейчас, которые держат дизайнеров для окон, кнопок, сплеш-скринов? Это тоже мне кажется потихоньку придет — GUI отдойдет от клепания формочек программистами до уровня когда это легко как HTML (здесь лол на легко ) будут делать дизайнеры и уже не в Visual Studio, и сразу со скинами — хошь такой стиль, хошь такой. Благо виста богатые технологии отображения предоставляет. Насколько я знаю, Adobe и MS движутся в эту сторону — XML окна, легко сочитающие скины и функциаональность кнопочек.


Отвлеклись. Для объективности надо сделать голосование в таком формате — Устравивает ли вас C++? Если нет, то на какой язык вы хотели бы писать: Java, C#, D, функциональный. Ах, ну да, еще Nemerle Basic и Pascal в меньшинства, как не собравшие достаточное число подписей
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[8]: Не пора ли нам перейти на D
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 28.02.07 17:13
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL. Аналогично произошло с Delphi и Pascal-подмножеством в нём. Если бы начали делать D и сказали: "любимые наши C++ — разработчики, вот вам C++-подмножество в D, наслаждайтесь. А на досуге, оцените ещё наши новые фичи — туплы, вариативные шаблоны и ещё кучу всякой радости". Да я бы обеими руками был бы за переход на такой язык и начальство бы уговорил.


Ага, однажды пришёл C и разрушил всё до основания. Он предложил некоторые вещи, которые были круче, чем в Фортране. Но C не был надмножеством Фортрана, так что народ, мы идём по неправильному пути! Долой всякие там C/C++/C#! Даёшь Мегафортран с ФВП, лямбдами, замыканиями, метапрограммированием и STL! Но главное, чтобы прога на Фортране была так же прогой на Мегафортране.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 18:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вообще-то, обычно да. Той же JVM/C# приходится сделать достаточно много

C>работы для вызова неуправляемого кода — за-pin'ить объекты, сохранить
C>контекст GC и т.п.

Ерунду говоришь полнейшую. "Запинить объект" == установить ровно один бит в его заголовке. Никаких контекстов ЖЦ сохранять не нужно.
Другое дело, что форматы дотнета и WinAPI различаются. Так что в не тривильных случаях приходится производить конвертацию данных (маршалинг). Но оные действия приходится производить и в С++-коде. Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее всего скопируешь данные в std::string или его аналог. А это тот же маршалинг. Причем может быть лично ты напишешь код конвертации очень грамотно. А вот В.Пупкин может написать его криво и тормозно. Так что не факт, что дотет тут проиграет.

Рельно скорость маршалинга довольно высока. По крайней мере я за все время его использования не наблюдал ни одногшо солучая когда бы он стал узким местом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 28.02.07 19:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

S>>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

VD>Совершенно верно. Но можно сказать проще. Миксины/трэйтсы просто меняют структуру классов. Ни для кого не сикрет, что сами методы это просто глобальные фукнции получающие в качестве параметра ссылку на объект нужного типа. Так что миксины/трэйтсы не вызвают оверхэд, а на оборот приводят в итоге к более простым решениям в компиляторе.


VD>Например, для разрешения ссылок на множество базовых классов в С++ часто испльзуется "двойной" указатель (на 32-битных платформах его размер обычно больше 32-х бит). Это вынуждает компилятор порождать код пересчета адресов, что естественно отражается на скорости вызова метода доводя его до скорости вызова интерфейса в дотнете. А раз так, ток каой смысл заниматься всеми этими сложностями?


Это к чему ? Вы думаете это секрет что МН реализуется нетривиально ? Должен вас огорчить, к сожалению Страуструп в курсе. А в целом рекомендую почитать дизайн и эволюцию , про принцыпы C++ "не платим за то , что не используем". Удачи.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[15]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 28.02.07 19:18
Оценка:
VladD2 wrote:
> Ерунду говоришь полнейшую. "Запинить объект" == установить ровно один
> бит в его заголовке.
Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он
хранится в виде single-linked списка. А это уже overhead.

> Никаких контекстов ЖЦ сохранять не нужно.

Нужно.

> Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее

> всего скопируешь данные в std::string или его аналог.
Буду работать с char*, обернутым в мою строку
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[15]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 28.02.07 19:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Рельно скорость маршалинга довольно высока. По крайней мере я за все время его использования не наблюдал ни одногшо солучая когда бы он стал узким местом.


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

Кстати, есть где-нибудь детальное описание механики .NET-COM interop'а, чтобы знать, что именно там происходит?
now playing: Noisia & Phace — Surface Tension
Re[12]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 28.02.07 20:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что касается конкуренов С++, то для меня это само по себе смешно. С++ маральный урод. Он устарел еще 10 лет назад. Его испоьзуют не потому что он лучий, а потому, что к нему привыкли и потому что вокруг него море фобий.


Ещё потому, что есть прорва legacy code написанного на нём, которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++
now playing: Impulse & Submerged — Dirty Bomb (Scorn Remix)
Re[15]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 28.02.07 21:39
Оценка:
Здравствуйте, VladD2, Вы писали:


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


Если говорить именно о микрсофтовском .Net, то ты несомненно прав. Но ведь спецификация CLR вроде не обязывает иметь JIT или я ошибаюсь ?

З.Ы. В своем посте под .Net я подразумевал именно CLR, а не конкретно MS .Net. возможно из-за этого путаница возникла.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:19
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Это к чему ? Вы думаете это секрет что МН реализуется нетривиально ?


Для кого как.

M> Должен вас огорчить, к сожалению Страуструп в курсе.


Почему это должно меня было огорчить?

M> А в целом рекомендую почитать дизайн и эволюцию


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

M> , про принцыпы C++ "не платим за то , что не используем".


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

Собственно Страуструпу то простительно. Он просто не додумался до более простого и эффективного решения. Ведь трыйтсы били проработаны и описаны только недавно. Но для разработчиков языков сегодня повторение ошибок Страуструпа уже не проститльно. В прочем эти ошибки никто и не повторил (пока что).


M>Удачи.


Спасибо.

ЗЫ

И не надо так оверквотинг.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:57
Оценка:
Здравствуйте, Mirrorer, Вы писали:

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



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


M>Если говорить именно о микрсофтовском .Net, то ты несомненно прав. Но ведь спецификация CLR вроде не обязывает иметь JIT или я ошибаюсь ?


CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft. Если говорить о CLI, то потенциально, нет. Но серьезной реализацией интерпретатор не считается. В Моно тоже имеется компиляция. В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.

M>З.Ы. В своем посте под .Net я подразумевал именно CLR, а не конкретно MS .Net. возможно из-за этого путаница возникла.


И в очередной раз ошибаешся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он

C>хранится в виде single-linked списка. А это уже overhead.

Мне плевать на JVM. В дотнете никаких списков нет. Это ровно один бит расположенный рядом с битом использованием для пометки объекта как посещенного. Так что у тебя проблемы с матчастью.

>> Никаких контекстов ЖЦ сохранять не нужно.

C>Нужно.

ОК. Подверди, плиз свои утверждения. Сразу предупреждаю, чно кивать на Яву не надо.

>> Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее

>> всего скопируешь данные в std::string или его аналог.
C>Буду работать с char*, обернутым в мою строку

Ладно. Тебе можно. Работай с BSTR и char* обернутые в твою троку. Главное незабудь сказать когда этот софт будут запускать на АЭС.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:57
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я вот недавно профайлил своё приложение, которое очень интенсивно юзаем COM компоненты и с удивлением обнаружил, что служебный код interop находится в топе списка по сумме времени проведённом в вызове. В итоге я просто попросил профайлер не показывать его мне, ибо без толку — отказаться от использования этих компонент я не могу.


Думаю, твой профайлер показывал не время именно интеропа, а время проведенное вне управляемого кода.

EC>Кстати, есть где-нибудь детальное описание механики .NET-COM interop'а, чтобы знать, что именно там происходит?


В одном из старых номеров МСДН Маг-а (анклийсгого) была статья по этому повду.
А вообще, все сильно зависит от типов данных. Скажем для массива байтов вообще маршалинг не требудется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.07 22:57
Оценка:
Здравствуйте, igna, Вы писали:

ie>>на Haskell так:

I>
ie>>factorial 0 = 1
ie>>factorial n = n * (factorial (n-1))
I>


I>Ну так понятнее же чем на Nemerle.


Чем?

К примеру, сможешь объяснить, что будет если убрать одни из скобок?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 01.03.07 05:13
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Этот вариант всех рвёт по компактности и изяществу.


Согласен. Единственная проблема — очень сильно чувствуется узаконенный душок побочных эффектов компиляции некторых других языков.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Не пора ли нам перейти на D
От: minorlogic Украина  
Дата: 01.03.07 05:37
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.


EC>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.


Его так просто сбить с толку ? в топку !!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[17]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 01.03.07 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft.

Ага. То есть не CLR, а CLI. Хотя все равно буду путать

VD>Если говорить о CLI, то потенциально, нет.

VD> В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
Вот это я и хотел сказать с самого начала


VD>И в очередной раз ошибаешся.

Ну. Что ж тут сделаешь.. Зато всегда найдется тот кто поправит
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[14]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 01.03.07 07:35
Оценка:
Здравствуйте, VladD2, Вы писали:

EC>>Ещё потому, что есть прорва legacy code написанного на нём,


VD>Вот это чистейшей воды миф. Практически все API делаются совместимыми с C или одной из VM.


Это суровая реальность, данная как мимнимум мне в ощущениях.

EC>> которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++


VD>В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.


О поддержке слышал?
now playing: Sileni — Cold Sweat
Re[11]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 01.03.07 07:35
Оценка:
Здравствуйте, IT, Вы писали:

IT>Согласен. Единственная проблема — очень сильно чувствуется узаконенный душок побочных эффектов компиляции некторых других языков.


Ты о триках в духе C++ template metaprogramming говоришь? Если да, то не согласен — где тут побочные эффекты?
now playing: Sileni — Cold Sweat
Re[11]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 01.03.07 07:49
Оценка:
Здравствуйте, VladD2, Вы писали:

ie>>>factorial 0 = 1
ie>>>factorial n = n * (factorial (n-1))


VD>К примеру, сможешь объяснить, что будет если убрать одни из скобок?


Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?
Re[4]: Не пора ли нам перейти на D
От: x-code  
Дата: 01.03.07 08:11
Оценка:
Здравствуйте, demi, Вы писали:

D>>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++

Супер! 36 очков, и это не предел
Вы очень точно выразили основные проблемы программирования (и в частности, программирования на С++).
добавлю еще от себя немного
все существующие языки программирования "плоские". Вот например солюшн: 50 проектов (exe,lib,dll), в каждом по 50 классов, в каждом классе по 50 методов. Плюс глобальные функции и переменные, оставшиеся еще со времен когда проект был на Си. И во всем этом нужно ориентироваться. Плюс еще куча библиотек, API и т.д.
И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.
ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов.
Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди)
Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.
Re[12]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 01.03.07 08:21
Оценка:
Здравствуйте, igna, Вы писали:

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


I>
ie>>>>factorial 0 = 1
ie>>>>factorial n = n * (factorial (n-1))
I>


VD>>К примеру, сможешь объяснить, что будет если убрать одни из скобок?


I>Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?


Без внутренних? Будет возвращать 1 для нуля и надолго задумываться в противном случае. Что за ряд он там будет пытаться считать — можно отправить в качестве вопроса в этюды
Re[17]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 01.03.07 08:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Думаю, твой профайлер показывал не время именно интеропа, а время проведенное вне управляемого кода.


На прокси стабы указывал.
now playing: Break — Longed Out
Re[10]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 08:28
Оценка:
Здравствуйте, EvilChild, Вы писали:

ie>>на Haskell так:

ie>>
ie>>factorial 0 = 1
ie>>factorial n = n * (factorial (n-1))
ie>>

EC>Этот вариант всех рвёт по компактности и изяществу.

Жаль что он некорректный.

Что до изящиства, но мне кажется, две пары совершенно лишних скобок вряд ли можно назвать изяществом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:14
Оценка:
Здравствуйте, Mirrorer, Вы писали:

VD>>Если говорить о CLI, то потенциально, нет.

VD>> В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
M>Вот это я и хотел сказать с самого начала

И все же твои аргументы весма сомнительны. Ведь интерпретатор можно сделать и для ассемблеара. Нельзя же на этом основании делать какие-то выводы о производительности в общем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:14
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Это суровая реальность, данная как мимнимум мне в ощущениях.


А, ну, так бы сразу и сказал. Понятно, что там если В.Пупкин или И.И.Иванов не являются определяющими общее положение вещей, но ты другое дело.

VD>>В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.


EC>О поддержке слышал?


Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

[много воды поскипано]

Ссылок нет, на сем закончим эту бесельную беседу. Будут ссыкли — обсудим.

Еще раз повторюсь, что я говорю о конкретной реализации в дотнете. Никакх список там нет. Сборщик мусора просто проверяет биты запинености. Запиненные объекты просто не предвигаются. Это вызывает известные проблемы, но так как обычно запиненность не длится долго, то и серьезных проблем не происходит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 01.03.07 09:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?


При чём здесь новые проекты? Речь шла о том, что часто пишут на C++ потому как необходимо поддерживать существующий код.
now playing: Break — Longed Out
Re[11]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 01.03.07 09:24
Оценка:
VD>Жаль что он некорректный.
После исправления ошибки он свои эстетические свойства не потеряет.

VD>Что до изящиства, но мне кажется, две пары совершенно лишних скобок вряд ли можно назвать изяществом.

Дело вкуса.
now playing: Break — Longed Out
Re[11]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:42
Оценка:
Здравствуйте, IT, Вы писали:

IT>Согласен. Единственная проблема — очень сильно чувствуется узаконенный душок побочных эффектов компиляции некторых других языков.


Это ты о чем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 09:42
Оценка:
Здравствуйте, x-code, Вы писали:

XC>И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.


Думаю, что речь шала о подсказках IDE и о том, что в неоднозначном С++ эти подсказки зачастую сбиваются или попросту не могут быть показаны в следствии отсуствия информации. Незнаю как там с Ди, но в Немрле таких проблем нет.

XC>ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов.

XC>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди)
XC>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.

Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 01.03.07 09:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


можно о выделенном подробнее?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[12]: Не пора ли нам перейти на D
От: Disappear  
Дата: 01.03.07 09:53
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


VD>>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.


EC>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.


Не совсем так. Современные С++ компиляторы такие вещи как inline, register, volatile в большинстве случаев просто пропускают. Поэтому ваш аргумент — не более чем выдумка.
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 10:00
Оценка:
Здравствуйте, EvilChild, Вы писали:

VD>>Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?


EC>При чём здесь новые проекты?


Тогда читай внимательно о чем шла речь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Не пора ли нам перейти на D
От: Disappear  
Дата: 01.03.07 10:12
Оценка:
Здравствуйте, x-code, Вы писали:

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


D>>>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++

XC>Супер! 36 очков, и это не предел
[..skipped..]
XC>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди)
XC>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.

Есть какие-то идеи? Поделитесь с нами, пожалуйста.
Re[6]: Не пора ли нам перейти на D
От: x-code  
Дата: 01.03.07 10:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, x-code, Вы писали:


XC>>И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.


VD>Думаю, что речь шала о подсказках IDE и о том, что в неоднозначном С++ эти подсказки зачастую сбиваются или попросту не могут быть показаны в следствии отсуствия информации. Незнаю как там с Ди, но в Немрле таких проблем нет.

Не совсем. Нужен качественно новый подход к написанию кода, а не подсказки. См. ответ на второй вопрос.

XC>>ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов.

XC>>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди)
XC>>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.

VD>Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?

ФП — замечательный подход, я часто жалею что ничего подобного нет в С++. Но это локальный уровень, а нужен глобальный. И в локальном уровне должны быть заложены средства коннекта с глобальным.
У меня есть только интуитивные наметки, но формализовать пока неполучается — видимо, из-за нехватки времени. Поэтому попробую как сумею, наверняка получится криво

В общих словах — я хочу чтобы IDE понимала семантику и логику программы и как-то отражала это. Чтобы была некоторая "многослойность" и "многомерность" при разработке. Чтобы программист мог выразить семантику взаимодействующих объектов как-то так, чтобы это было видно, и чтобы компилятор извлекал из этого какую-то информацию.
Возможно, "программирование на уровне паттернов".
Возможно, такие концепции как "контейнер" и "итератор" стоит ввести в язык программирования.
Как-то на более высоком уровне реализовать идею объектов и связей между ними (не методы и указатели на интерфейсы)
Сделать прямой гейт "UML-язык программирования", а не те кривые реализации которые есть сейчас.

То есть вот хочу я написать программу. Создаю проект, ввожу название, краткое описание что программа делает. У меня на экране "квадратик" с именем программы. Далее, я хочу чтобы у программы был пользовательский интерфейс, чтобы она работала как клиент и как сервер в сети и работала с БД. Я беру в "ПАЛИТРЕ ФУНКЦИОНАЛЬНОСТИ" понятие "Пользовательский интерфейс" и перетаскиваю его на квадратик программы! Это не компонент, не класс, а именно "функциональная сущность". Там нет прямого кода на ЯП, нет классов и компонентов, а есть некоторый интеллектуальный блок который "знает" что такое "UI".
Далее, я хочу конкретизировать что же мне нужен за интерфейс. Я щелкаю на появившейся секции "UI" и спускаюсь на уровень ниже. Мне становится доступна новая палитра функциональности, включающая в себя различные варианты интерфейсов, например "Возможноть MDI окон", "Возможность консольных окон", "Полноэкранный режим DirectX", "Возможность пиктограммы в трее", "Голосовой ввод", "Воспроизведение аудио".
И дальше, опускаясь по дереву уровней все ниже и ниже, я в конечном итоге заполняю различные процедуры и функции, создаю структуры, перечисления, классы, связываю входы и выходы различных компонентов... не напрягаться какой бы "адаптер" придумать чтобы связать два класса, а просто СВЯЗАТЬ их и пусть компилятор думает...
Если мне нужна строка то я даже не задумываюсь какой из 20 типов строк использовать! Я просто использую абстракцию "строка", если мне нужно конкретизировать — я конкретизирую, если не нужно — компилятор сам за меня это сделает.
Не париться с STL и прочими контейнерами, а просто работать с абстрактными наборами данных — путь компилятор решает, что выгоднее — простой массив или двусвязный список с хеш-таблицей.

P.S. несколько сумбурно, но думаю идея понятна
Re[19]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 01.03.07 10:48
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>И все же твои аргументы весма сомнительны. Ведь интерпретатор можно сделать и для ассемблеара. Нельзя же на этом основании делать какие-то выводы о производительности в общем?


Интерпретатор ассемблера с JIT компиляцией будет быстрее просто интерпретации ассемблера в общем.

Допустим я написал реализацию CLI для .. ну допустим Solaris. И не сделал там JIT компиляцию.
И на Солярке программы будут тормозить.
Поэтому я и не согласился с твоим утверждением

VD>Я бы сказал, что байт-код тоже не существеннен. В итоге ведь все равно имеем нэйтив-код.


Потому что нейтив кода в моем гипотетическом .Solar мы не получим. Мы получим интерпретацию байткода.
Конечно? можно сказать что интерпретация тоже дает нейтив код, потому что сам интерпретатор исполняет нейтив код, и любая инструкция байткода перейдет в какую-то инструкцию нейтив кода, но это совсем не одно и то же, что интерпретатор с JIT компиляцией.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[13]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 11:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что.


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

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


Можно пример, когда карринг приводит к такому случаю?

С остальным согласен. Короткая запись ПМ на Немерле — очень здорово, в Хаскеле для этого приходится либо вторую строчку, либо case/of делать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 11:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что до изящиства, но мне кажется, две пары совершенно лишних скобок вряд ли можно назвать изяществом.


Да там внешние скобки не нужны, честно говоря.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 11:10
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Этот вариант всех рвёт по компактности и изяществу.


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

Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Задумчиво...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.03.07 11:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.


А мне еще кажется, что как к защитникам D, так и к критикам в данной теме относятся слова классика:

...Ведь в вине была горечь побед,
Которым цена — лишь костыль,
И, сражаясь за красоту, дурни подняли пыль.

(Крематорий, Винные Мемуары).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 01.03.07 12:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

I>>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?
S>совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".

<paranoid mode>
Неверно. Т.к. из истинности утверждения "С++ — простой или мощный" не следует истинность утверждения "С++ — простой и мощный" о котором шла речь.
</paranoid mode>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 01.03.07 12:10
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


ie>>на Haskell так:

ie>>
ie>>factorial 0 = 1
ie>>factorial n = n * (factorial (n-1))
ie>>

EC>Этот вариант всех рвёт по компактности и изяществу.

Какое уж тут изящество если название функции повторяется слева 2 раза. А если вариантов больше?

По-моему Немерле изящнее

factorial( n : uint ) : uint
    | 0 => 1
    | _ => n * factorial(n-1)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Не пора ли нам перейти на D
От: Andir Россия
Дата: 01.03.07 12:19
Оценка:
Здравствуйте, jedi, Вы писали:

J>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек


Хмм. А ведь интересная мысль!

C Уважением, Andir!
using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }
Re[17]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 01.03.07 12:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

I>>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?
S>совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".

Ремарка: исключение третьего здесь требует дополнительных обоснований.
Re[11]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 12:31
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Какое уж тут изящество если название функции повторяется слева 2 раза. А если вариантов больше?


Увы! Тогда case/of. Ну или повтор. Мне тоже хочется более простого варианта, честно! даже как то писал об этом.

АХ>По-моему Немерле изящнее


АХ>
АХ>factorial( n : uint ) : uint
АХ>    | 0 => 1
АХ>    | _ => n * factorial(n-1)
АХ>


Да, очень хороший код.
А чтобы тип был не uint, а любой numeric, как в примере на Haskell?

Правда, что этот вариант возможен только в локальных функциях?

Как насчёт guards? Не всегда нужно сравнивать только на равенство. Есть ли возможность написать что то вроде

sign n | n < 0     = -1
       | n > 0     =  1
             | otherwise =  0


Что то вроде лиспового cond...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 12:47
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Не совсем. Нужен качественно новый подход к написанию кода, а не подсказки. См. ответ на второй вопрос.


Цитирую:

Не сотни. А скажем 15. Умножьте на ~50 классов. Я не хочу и НЕ БУДУ дословно запоминать имена методов. Я предпочитаю начать писать его имя скажем, из серидины, пусть ассист сам найдет где такое встречается.


"ассист" — это, как я понимаю, речь идет о Tamato Visual Assist — т.е. продвинутом комплите для VC++.

VD>>Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?

XC>ФП — замечательный подход, я часто жалею что ничего подобного нет в С++.

Кое что все же есть в бусте. Но это конечно убогость.

XC>В общих словах — я хочу чтобы IDE понимала семантику и логику программы и как-то отражала это.


Семантика и так отображается. Только на для С++ конечно. А для C#/Java очень даже. Для Немерла тоже, только мы еще не закончили.

XC> Чтобы была некоторая "многослойность" и "многомерность" при разработке.


Это неопределенные понятия.

XC> Чтобы программист мог выразить семантику взаимодействующих объектов как-то так, чтобы это было видно, и чтобы компилятор извлекал из этого какую-то информацию.

XC>Возможно, "программирование на уровне паттернов".

Вот в современные языки и внедряются некторые паттерны или добавляются возможности позволяющие внедрить их.

XC>Возможно, такие концепции как "контейнер" и "итератор" стоит ввести в язык программирования.


Так и делается. C# и осбенно Nemerle поддерживают специальный сахар для работы с контейнерами, точнее со списками. Есть yield для легкой реализации итераторов. Есть встроенная поддержка list[T] в Nemerle. Есть foreach. Много чего есть. Но сами контейнеры выгодно все же иметь в виде типов написаннаых на самом языке.

XC>Как-то на более высоком уровне реализовать идею объектов и связей между ними (не методы и указатели на интерфейсы)


Опять что-то оморфное.

XC>Сделать прямой гейт "UML-язык программирования", а не те кривые реализации которые есть сейчас.


Ты открывал дизайнер классов в VS 2005? Или все представление основано на UML в сочетании с С++?

Много мечтаний далекий от жизни поскипаны.
Хочу подитожить следующим. Многое из того что ты описываешь уже реализовано. Не так правда как видиш это именно ты, но за-то работает на практике. Так что советую поглядеть на мир за пределами С++, так как это все недоступно в основном именно миру С++ в следствии того, что язык плохо подходит для этого.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Не пора ли нам перейти на D
От: Mirrorer  
Дата: 01.03.07 13:00
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Как насчёт guards? Не всегда нужно сравнивать только на равенство. Есть ли возможность написать что то вроде


L>
L>sign n | n < 0     = -1
L>       | n > 0     =  1
L>             | otherwise =  0
L>

Украл отсюда


public Contains (e : int) : bool
  {
    match (this) {
      | Tree.Node (l, cur, _) when e < cur => 
        l.Contains (e)
 
      | Tree.Node (_, cur, r) when e > cur => 
        r.Contains (e)
 
      | Tree.Node => true
      | Tree.Null => false
    }
  }
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[14]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 01.03.07 13:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:


Влад. тут мы почитали внимательно... Такое ощущение что тебе нужен не специалиированный язык. типа универсального бойца. Верно? или это обманчивое впечатление?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[14]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 01.03.07 13:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:


Влад. тут мы почитали внимательно... Такое ощущение что тебе нужен не специалиированный язык. типа универсального бойца. Верно? или это обманчивое впечатление?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[13]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 13:10
Оценка:
Здравствуйте, Mirrorer, Вы писали:

L>>
L>>sign n | n < 0     = -1
L>>       | n > 0     =  1
L>>             | otherwise =  0
L>>


M>Украл отсюда


Т.е. мой пример распишется как

sign(n : int) : int
    | _ when n < 0 => -1
    | _ when n > 0 =>  1
    | _            =>  0


так?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Задумчиво...
От: Mirrorer  
Дата: 01.03.07 13:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>

E>...Ведь в вине была горечь побед,
E>Которым цена — лишь костыль,
E>И, сражаясь за красоту, дурни подняли пыль.

E>(Крематорий, Винные Мемуары).

Мне больше нравится другая классика

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


БГ, Электрический пес
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Re[12]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 01.03.07 13:19
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Ты о триках в духе C++ template metaprogramming говоришь? Если да, то не согласен — где тут побочные эффекты?


Я же говорю, в данном случае эти трюки просто узаконены. Плохочитаемыми трюками они от этого быть не перестали. На таком примитивном примере всё, конечно, выглядит очень просто. Но, боюсь, с усложнением кода, такие вещи будут добавлять запутанности гораздо больше, чем запись в обычном императивном виде.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 01.03.07 13:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это ты о чем?


Я о том, что пока всё просто, такая запись выглядит неплохо. Но, боюсь, что в реальном коде перегрузка метода не только по типу, но ещё и по значению не добавит простоты и понятности.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Не пора ли нам перейти на D
От: igna Россия  
Дата: 01.03.07 13:32
Оценка:
Здравствуйте, deniok, Вы писали:

D>fac 0 = 1
D>fac n = n * fac (n-1)


То есть все-таки так, как оно и должно быть.
Re[15]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 01.03.07 13:44
Оценка:
Здравствуйте, igna, Вы писали:

I>То есть все-таки так, как оно и должно быть.


Конечно. А зачем по-другому?
Re[12]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 13:46
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Да там внешние скобки не нужны, честно говоря.


Интуитивно обе пары совершенно лишнии. Вот люди и лепят их на всякий пожарный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 13:46
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?


Какое еще ограничение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 14:08
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Да там внешние скобки не нужны, честно говоря.


VD>Интуитивно обе пары совершенно лишнии.


Ну про первую пару согласен, но в С-like языках вторая пара необходима, так что интуитивно вроде как она нужна, по моему.
Хотя интуиция такая вещь, если честно. Опыт то у всех разный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 14:08
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?


VD>Какое еще ограничение?


Ты написал

или даже так:

factorial(n)
  | 0 => 1
  | _ => n * Factorial(n - 1)


если использовать локальные фукнции и их вывод типов.


т.е. такая запись возможна только если factorial — локальная функция? или я тебя неверно понял?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Не пора ли нам перейти на D
От: ironwit Украина  
Дата: 01.03.07 14:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

F>>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.
S>Это закрытая информация. Всё, что я могу сказать: сейчас на RSDN нет форума, в историю которого входит такой прецедент. И для вашего же благополучия — оставьте эти расспросы.

хоть webarchive ищи какой нить
заинтриговали
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:19
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>И параллельность. Чуть ли не половина глюков вылазит при многопоточности.


Это пока (лично для меня) вопрос будущего. Пока что параллельность была практически ненужна. Но конечно в будущем это стаенет одной из самых актуальных тем.

Вот только лино я хотел бы чтобы язык позволял бы добавить нужную поддержку имеющимися срествами (в виде фрэйморка).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:19
Оценка:
Здравствуйте, ironwit, Вы писали:

I>Влад. тут мы почитали внимательно...


Кто, мы?

I>Такое ощущение что тебе нужен не специалиированный язык. типа универсального бойца. Верно? или это обманчивое впечатление?


Мне нравится идея универсального инструмента который можно тоноко заточить под конкретную задачу/предметную область. Потому собственно я и обращаю внимание на метапрограммирование.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:38
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ну про первую пару согласен, но в С-like языках вторая пара необходима,


В С-подобных языках это будет семантика вызова метода. А тут совсем иная. Так что это сокрее вводит в заблуждение.

L>Хотя интуиция такая вещь, если честно. Опыт то у всех разный.


Как показывает практика опыт то разный, но интуиция очень даже бизкая.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:38
Оценка:
Здравствуйте, deniok, Вы писали:

D>Внутренние-то почему лишние? Возможно моя интуиция слишком "математизирована", но в


D>x * sin x — 1

D>vs.
D>x * sin (x — 1)

D> по-моему всё однозначно и понятно


Что тебе понятно?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:38
Оценка:
Здравствуйте, lomeo, Вы писали:

L>т.е. такая запись возможна только если factorial — локальная функция? или я тебя неверно понял?


Именно так. Только я чуть ошибся. Точный синтаксис будет таков:
def factorial(n)
  | 0 => 1
  | _ => n * Factorial(n - 1)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:38
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Т.е. мой пример распишется как


L>
L>sign(n : int) : int
L>    | _ when n < 0 => -1
L>    | _ when n > 0 =>  1
L>    | _            =>  0
L>


L>так?


Можно и так. Хотя для столь вырожденных случаев нужно if использовать:
if (n < 0) -1 else if (n > 0) 1 else 0

в прочем if/else — это макрос который один фиг в match раскроется. Так что это синтаксический сахар.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.03.07 15:45
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


VD>>Это пока (лично для меня) вопрос будущего. Пока что параллельность была практически ненужна. Но конечно в будущем это стаенет одной из самых актуальных тем.

VD>>Вот только лино я хотел бы чтобы язык позволял бы добавить нужную поддержку имеющимися срествами (в виде фрэйморка).
WH>Не реально.
WH>Эффективно и надежно паралельность можно сделать только на уровне ВМ. Никаким метапрограммированием хорощо паралельность не сделать.
WH>Как минимум по тому что нужно очень сильно корежить менеджер памяти для того чтобы он хорошо работал в условиях многопоточности.

Ну частично, думаю, можно достичь определённых результатов, если логику параллелизма вынести на уровень какого-нибудь DSL, где уже использовать нужные алгоритмы, правда ограничения исходного рантайма преодолеть не придётся, да.
Re[17]: Не пора ли нам перейти на D
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 01.03.07 15:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Это пока (лично для меня) вопрос будущего. Пока что параллельность была практически ненужна. Но конечно в будущем это стаенет одной из самых актуальных тем.

VD>>Вот только лино я хотел бы чтобы язык позволял бы добавить нужную поддержку имеющимися срествами (в виде фрэйморка).
WH>Не реально.
WH>Эффективно и надежно паралельность можно сделать только на уровне ВМ.

ВМ — это какая-та новая абревиатура термина "человек разумный" ?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[18]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.03.07 15:48
Оценка:
Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>ВМ — это какая-та новая абревиатура термина "человек разумный" ?


VM или ВМ — виртуальная машина, насколько я понимаю
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 15:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Не реально.

WH>Эффективно и надежно паралельность можно сделать только на уровне ВМ. Никаким метапрограммированием хорощо паралельность не сделать.
WH>Как минимум по тому что нужно очень сильно корежить менеджер памяти для того чтобы он хорошо работал в условиях многопоточности.

Подходы к обеспечению параллельности есть разные. Например, Эрланговский. Конечно со спец. поддержкой в ВМ было бы проще, но и без ее много можно сделать.

Что до GC, то он и так рассчитан на многопотчность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 15:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Забавно, что вот так:


VD>
VD>fac 0 = 1
VD>fac n = fac (n-1) * n
VD>


VD>насколько я понимаю уже нельзя.


Можно. Говорю же у функций приоритет больше, чем у операторов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 15:57
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>т.е. такая запись возможна только если factorial — локальная функция? или я тебя неверно понял?


VD>Именно так.


Э-э-э так что насчёт моего вопроса? Чем вызвано такое ограничение?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 16:01
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ну про первую пару согласен, но в С-like языках вторая пара необходима,


VD>В С-подобных языках это будет семантика вызова метода. А тут совсем иная. Так что это сокрее вводит в заблуждение.


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

L>>Хотя интуиция такая вещь, если честно. Опыт то у всех разный.


VD>Как показывает практика опыт то разный, но интуиция очень даже бизкая.


Практика у всех тоже разная
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 16:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Подходы к обеспечению параллельности есть разные. Например, Эрланговский. Конечно со спец. поддержкой в ВМ было бы проще, но и без ее много можно сделать.

VD>Что до GC, то он и так рассчитан на многопотчность.
А region inference ты как будешь делать не имея полной информации о потоках?
А на одном ГЦ действительно быструю систему не сделать.
Да и просто генерить код можно по разному в зависимости от того какие сценарии многопоточности лучше работают на конкретной железке.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 16:08
Оценка:
Здравствуйте, Коваленко Дмитрий, Вы писали:

WH>>Не реально.

WH>>Эффективно и надежно паралельность можно сделать только на уровне ВМ.

КД>ВМ — это какая-та новая абревиатура термина "человек разумный" ?


Это сокращение от виртуальная машина.

Что касается человек разумный то без этого никуда. Но колупаться с многопоточностью без поддержки со стороны инструментов геморой еще тот. А наиболие мощьный инструмант это ВМ.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:13
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Э-э-э так что насчёт моего вопроса? Чем вызвано такое ограничение?


Еще раз. Какое еще ограничение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.03.07 16:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Подходы к обеспечению параллельности есть разные. Например, Эрланговский. Конечно со спец. поддержкой в ВМ было бы проще, но и без ее много можно сделать.


Как раз Эрланговский очень рассчитан на поддержку ВМ (уже далеко не 1 раз ведь обсуждалось), плюс и GC там тоже использует особенности эрланга.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А region inference ты как будешь делать не имея полной информации о потоках?


Какая еще нужна информация о потоках?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.03.07 16:22
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>
VD>>>fac 0 = 1
VD>>>fac n = fac (n-1) * n
VD>>>


VD>>>насколько я понимаю уже нельзя.


L>>Можно. Говорю же у функций приоритет больше, чем у операторов.


VD>Вот только обычны человек прочтет это код как "fac ((n-1) * n)"


Кто такой "обычный человек"?
Если брать в расчёт программистов или математиков, то очень сомневаюсь, что они бы так это увидели.
Правда есть ты в качестве опровержения
Но вот откуда там тебе скобки мерещатся — мне непонятно
Re[18]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 16:27
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Можно. Говорю же у функций приоритет больше, чем у операторов.


VD>Вот только обычны человек прочтет это код как "fac ((n-1) * n)"


Таких примеров — масса. И это не зависит от языка.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 16:27
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Э-э-э так что насчёт моего вопроса? Чем вызвано такое ограничение?


VD>Еще раз. Какое еще ограничение?


Использование локальной функции.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:28
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Как раз Эрланговский очень рассчитан на поддержку ВМ (уже далеко не 1 раз ведь обсуждалось), плюс и GC там тоже использует особенности эрланга.


Тут много что на словах обсуждалось. Это не значит, что те заключения в которые ты поверил действительно истенны. У Эрлэнга конечно есть какие-то приемещетсва в каких-то областях, но есть и недостатки. То что он интерпретатор еще никто не отменял. Значит повл в 10 раз у него уже будет. Опять же Эрлэн рассчитан не на параллелизм, а на псевдопараллизм. Так что еще бабушка на двое сказала что будет в условиях когда серьеная задача будет выполняться на нескольких процессорах.

Ну, и опять же лично мне Эрлэнг не интересен. Слишком узок его область применения. А получить аналогичный фрэймворк в универсальном языке очень даже интересно. Уверен, что он в любом случае будет полезен и даст выигрыш на некоторых задачах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Не пора ли нам перейти на D
От: iiice Россия  
Дата: 01.03.07 16:30
Оценка:
А то С++, D, Nemerle...
Многие всё ещё с чистого С слезть не могут, ибо нет второго такого же портабельного языка. ФП, МП, ООП — это конечно хорошо, но на чём ядро того же Линукса писать прикажете? Так что в списке явно не хватает переносимости
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:45
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Кто такой "обычный человек"?


Обычный значит обычный. Человек мозг которого не изнасилован, опыт которого не вилик, взгляды которого еще не предвзяты.

К>Если брать в расчёт программистов или математиков, то очень сомневаюсь, что они бы так это увидели.


Математиков вообще лучше никуда не брать.

К>Правда есть ты в качестве опровержения


Что же я могу опровергнуть?

К>Но вот откуда там тебе скобки мерещатся — мне непонятно


Мне не мерещится ничего. Я тебе говорю как будет воспринимать это человек у которого мозги не изнасилованы тремя туториалами по Хаскелю. Это называется интуитивное восприятие.

Вот знаешь как отличить кота от кошки?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:45
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Использование локальной функции.


А в чем заключается это ограничение? Это наоборот полезная фича. Изъясняйся, плиз, развернутее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 16:49
Оценка:
Здравствуйте, iiice, Вы писали:

I>А то С++, D, Nemerle...

I>Многие всё ещё с чистого С слезть не могут, ибо нет второго такого же портабельного языка. ФП, МП, ООП — это конечно хорошо, но на чём ядро того же Линукса писать прикажете? Так что в списке явно не хватает переносимости

А кому сейчас нужен еще один Линкус? Сейчас исследовательские ОС как раз на новых языках и пишут.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 16:56
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>А region inference ты как будешь делать не имея полной информации о потоках?

VD>Какая еще нужна информация о потоках?
Вся.
Допустим имеем вот такой код:
spawn запускает код в новом потоке и возвращает future
1)
def someFn() : void
{
    def str = readString();
    def foo()
    {
        str.length;
    }
    print(foo());
}

2)
def someFn() : void
{
    def str = readString();
    def foo()
    {
        str.length;
    }
    _ = spawn(foo());
}

3)
def someFn() : void
{
    def str = readString();
    def foo()
    {
        str.length;
    }
    def value = spawn(foo());
    print(value.get);
}


В первом и третьем случае строку можно разместить в стеке или в куче привязанной к функции someFn. Как это другой вопрос.
Во втором нельзя ибо мы можем выйти за приделы функции до того как свеже созданный поток будет завершон.

Болие того во втором случае можно вобще выкинуть запуск потока ибо никаких эффектов он не производит. А третий свести к первому ибо запуск потока даже если их очень сильно облегчить всеравно сильно дороже чем исполняемый код.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Не пора ли нам перейти на D
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 01.03.07 17:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ДСЛ это лишь сахарок. Без примитивов работы с многопоточностью всеравно ничего не сделаешь. А вот качественную реализацию правильных примитивов можно сделать только на уровне ВМ ибо нужно учитывать специфику конкретного железа на котором работаешь.


Т.е. одна программа под всевозможные архитектуры (векторные, кластеры и т.д.)? Как-то не верится. Сегодня, вроде, под архитектуру выбирается язык и технология.
А попытки создать такую ВМ есть? Почитал здесь и здесь. Но там не нашёл
Re[20]: нашёл
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 01.03.07 17:20
Оценка:
Хотя, нет. Нашёл в первой ссылке. DVM и есть оно.
Re[18]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 18:43
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Использование локальной функции.


VD>А в чем заключается это ограничение? Это наоборот полезная фича. Изъясняйся, плиз, развернутее.


Ограничение заключается в том, что для нелокальной функции это использоваться не может. Впрочем, мне уже ответили, так что забей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 18:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

Все что синхронизируется — это доступ к очереди. Орканизуется это примитивно на интерлокедах. Все объекты в очереди доступны только для чтения.

Ну, и в чем, сажи мне на милость, проблема реализовать подобный механизм?

Что? Это не всегда будет эффективным решением? Ну, и фиг с ним. Ведь в тех случаях когда это удобно — это поволит писть простой и логичный код который будет хорошо параллилться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 18:44
Оценка:
Здравствуйте, Gajdalager, Вы писали:

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


Я посморю на тебя когда ты что-то немного сложнее попробуешь почитать.

VD>>Вот знаешь как отличить кота от кошки?


G>Пинка дать? Если побежал — то кот, а если побежала — кошка?


Примерно, но не так жестоко.
Так вот, в этой шутке почти нет шутки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 19:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Он хочет спросить: Почему вывод типов работает только для локальных функций?


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

WH>Отвечаю: Иначе компилироваться будет ну очень долго.


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

ЗЫ
Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций.
Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 01.03.07 19:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это ты какие-то свои представления вываливашь. А теперь представь, что мы имеем некий фрэймворк где как в Сингулярити группы объектов крутятся в отдельном потоке. Для каждого потока одтельная очередь сообщений. Она разргребается и выполняется некая работа.

В сингулярити не так.
Там у потока может быть сколько угодно очередей сообщений.
Болие того эти очереди двунаправленные.

VD>Все что синхронизируется — это доступ к очереди. Орканизуется это примитивно на интерлокедах. Все объекты в очереди доступны только для чтения.

На словах. Я тут гдето реализацию lock-free очереди видел
К тому же учти что интерлокед на многопроцессорной тачке весьма не дешев.

VD>Ну, и в чем, сажи мне на милость, проблема реализовать подобный механизм?

ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.07 19:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В сингулярити не так.

WH>Там у потока может быть сколько угодно очередей сообщений.
WH>Болие того эти очереди двунаправленные.

Это детали реализации. Они в данном случае не важны.

VD>>Все что синхронизируется — это доступ к очереди. Орканизуется это примитивно на интерлокедах. Все объекты в очереди доступны только для чтения.

WH>На словах. Я тут гдето реализацию lock-free очереди видел
WH>К тому же учти что интерлокед на многопроцессорной тачке весьма не дешев.

Ничего. Дешевле все равно ничего не бывает. Один интерлок на обработку сообщения не будет даже в микроскоп заметно.

WH>ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать.


GC уже рассчитан на пногопоточность. У них там все хитро устроено. Плюс есть специальный серверный ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 01.03.07 20:13
Оценка:
VladD2 wrote:
> WH>ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать.
> GC уже рассчитан на пногопоточность. У них там все хитро устроено. Плюс
> есть специальный серверный ЖЦ.
Даже параллельный конкуррентный GC вынужден на определенное время
останавливать всех мутаторов. Оно достаточно короткое, но вполне
существенное для многих целей.

Нормальный полный конкуррентный GC невозможен без аппаратной поддержки
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[20]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 01.03.07 20:54
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ограничение заключается в том, что для нелокальной функции это использоваться не может. Впрочем, мне уже ответили, так что забей.


VD>Какое это ограничение?


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

За остальное спасибо, было интересно почитать.

VD>Я даже не знаю как делать интеграцию с IDE если будет решено выводить типы глобальном уровне.


Полагаю, не это было причиной отказа от глобального вывода типов
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 02.03.07 01:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>В Хаскеле нет перегрузки методов. Только паттерн-матчинг.


Я говорю не о хаскеле, а о стиле.

VD>Да и "перегрузка метода по значению" — это какая-то фигня.


Ну назови это как тебе больше нравится.

VD>В общем, что-то ты не допонимаешь.


И похоже я не одинок.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 02.03.07 02:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я даже не знаю как делать интеграцию с IDE если будет решено выводить типы глобальном уровне.


А если выводить тип приватных методов?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 02.03.07 06:37
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>Внутренние-то почему лишние? Возможно моя интуиция слишком "математизирована", но в


D>>x * sin x — 1

D>>vs.
D>>x * sin (x — 1)

D>> по-моему всё однозначно и понятно


VD>Что тебе понятно?


Как вычислить эти выражения, попадись они мне в школьном учебнике алгебры Хаскель сохраняет для функций одной переменной стандартный математический синтаксис.
Re[20]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 07:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, и опять же лично мне Эрлэнг не интересен. Слишком узок его область применения. А получить аналогичный фрэймворк в универсальном языке очень даже интересно. Уверен, что он в любом случае будет полезен и даст выигрыш на некоторых задачах.


Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример), но в целом модель Эрланга требует поддержки ВМ. И тут далеко не играют роль факторы, приводимые тобой про динамическуют типизацию и т.д. Вот здесь
Автор: VladD2
Дата: 01.03.07
всё расписано, повторяться не вижу смысла.
Если ты считаешь, что эту задачу можно решить библиотекой — ради бога, но правдой это не станет.
Я всё сказал.
Re[17]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 07:57
Оценка:
Здравствуйте, Трурль, Вы писали:

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


D>>
D>>1+2*3
D>>


D>>во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета.


Т>
Т>  1+2*3
Т>7
Т>  2*3+1
Т>8
Т>

Т>

Поменял ты порядок переменных и что?
Re[17]: Не пора ли нам перейти на D
От: deniok Россия  
Дата: 02.03.07 08:21
Оценка:
Здравствуйте, Трурль, Вы писали:


D>>
D>>1+2*3
D>>


D>>во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета.


Т>
Т>  1+2*3
Т>7
Т>  2*3+1
Т>8
Т>

Т>

ну значит не во всех Что за зверь?
Re[18]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 08:24
Оценка:
Здравствуйте, deniok, Вы писали:

D>ну значит не во всех Что за зверь?


Почему не во всех-то? Он порядок поменял, естественно изменились и действия, ведь 1 + 2 и 3+1 — разные вещи, разве не так?
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>Это несерьёзно. Вроде как вывод типа был призван объединить всё то лучшее, что есть в статических и динамических подходах.


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

VD>>Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций.

VD>>Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.

L>Позволяет упрощать выявление ошибок, может быть, но связано это не с этим.


С чем "не с этим"?

L> Причины совершенно другие. Если я пишу функцию, реализация которой мне изначально понятна, я записываю её без типа. Если я пишу функцию, которую сходу написать не могу, то часто пользуюсь методом — "писать от типа".


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

L> Это очень удобно, потому что тип более-менее ясен, так как я представляю что должна делать функция, а уж из типа вывожу реализацию.


Очередная мантра "выводу из типа".

L> Если я пишу код, который предполагаю обработать haddock'ом, то, конечно, пишу типы, чтобы проставить к ним комментарии. Если мне нужен не общий тип для этой функции, а более специфичный (например, это связано с целью оптимизации), то я пишу нужный тип. С целью повышения скорости компиляции типы может и пишут, но я про такое не слышал.


Дело в том, что ты почему-то ассацируешь себя с остальными. Ты можешь ухо через ногу чесать, что с того?

Я вообще не понял предмет обсуждения. Ты спросил, я тебе ответил. Что мне до твоего опыта? От твоих предочтений и привычек у людей исходные редпосылки не изменяются. Типы пишутся только по двум причинам. 1. Ускорение компиляции. 2. Чтобы компилятор внятно сообщил об ошибках если что не так.
В одном языке допускают опускать типы в публчном интерфейсе, а в другом считают это плохой практикой. Вот собственно и все.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка:
Здравствуйте, IT, Вы писали:

IT>А если выводить тип приватных методов?


Язык переживет. Тормозов только будет по больше. Для IDE — это будет полный кабждец. Прейдется перекомпилировать на каждый чих все приватные методы. Точнее все, так как их и выделить то нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример),


Ну, значит могу? На том и порешим.

К> но в целом


А в целом — это домыслы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 08:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Даже параллельный конкуррентный GC вынужден на определенное время

C>останавливать всех мутаторов. Оно достаточно короткое, но вполне
C>существенное для многих целей.

И что?

C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки


Это вопрос терминологии. К тому же конкуррентный и хорошо параллелящийся — это две большие разницы.

Я не вижу причин по которым не реализовать удобное распараллеливание в универсальных языках. Возможно эффективность будет несколько ниже неже ли если бы интегрировать поддержку в VM, но все равно решение будет полезным. О изменениях VM пока что можно только мечтать. А сделать фрэймворк можно здесь и сейчас. И он удет полезен на прктике. Так что не вижу предмета обсуждения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: Gajdalager Украина  
Дата: 02.03.07 09:36
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Трурль, Вы писали:



D>>>
D>>>1+2*3
D>>>


D>>>во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета.


Т>>
Т>>  1+2*3
Т>>7
Т>>  2*3+1
Т>>8
Т>>

Т>>

D>ну значит не во всех Что за зверь?

J?
Re[29]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.03.07 15:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Собираюсь делать небольшой проект — портирование CLR на LLVM. Пока для

C>него финансирование делаю.

CLI наверное имеется в виду? Интересно было бы посмотреть, мы услышим где как и что потом? Внутренний проект? Или Open Source?
Re[26]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 16:10
Оценка:
Здравствуйте, IT, Вы писали:

L>>Может, однако недостатки глобального вывода для пользователя языка озвучены не были.


IT>Были буквально тремя постами выше, просто ты не внимательно читал.


"упрощение выявления ошибок и документирование"?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 19:07
Оценка:
Здравствуйте, lomeo, Вы писали:

L>О нет Влад, что ты! Это только твоя прерогатива. Слова "практика показывает", "этого нет, значит это никому не нужно" и прочее — это слова из твоих постов. Копирайты за тобой.


Ну, что же... Ответов на прямые вопросы нет. Аргументов тоже. Наличиствует только мелкая демогогия и переход на личности. Будем считать, что ты просто пытался сказать, что у тебя закончились аргументы и вопросы. Адью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 02.03.07 21:08
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>То, что ты написал дальше — это хуже для дизайнеров этого языка.


VD>Конечно, конечно. Ты прав потому что ты не можешь быть не прав. Смотри и все месные извра... эээ неформалы с тобой согласны. Зачем так волноваться?


Нет, Влад, быть правым — это твоё, родное, забыл?

L>> Это не проблемы пользователя. Дизайнеры не могут решить эту проблему и говорят — ок, пусть вывод типов будет только локально, это связано с тем, что сделать то-то и то-то трудно/неэффективно/чтонибудьещё.


VD>Конечно, конечно. Ты ведь видишь правду насквозь. Это несомненно паронормальный дар. Только извини, я в паранормальные явления не верю.


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

VD>Главное не ясно что ты пыташся доказать. Что этот язык недостаточно хорош для тебя? Да, это так. Это примитивный язык предназначеный для написания обычных программ для реального мира. Тренировать им мозг невозможно. Но для этого есть Хаскешь.


Я всего лишь пытался спросить, почему было сделано такое ограничение. Это не было подколкой, это не было указанием на недостаток языка. Мне было интересно, почему был сделан выбор в пользу этого ограничения. Мне объяснили. Ты ввязался во флейм.

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


Проверено на VladD2!

Не будет Влад, не беспокойся за меня. У меня мозги по другому устроены — они нормальные, на яйца непохожие.

L>> От того, что у ограничения есть объяснение его существования оно не перестаёт быть ограничением. Как отсутствие перегрузки в Хаскеле. Его ведь тоже можно объяснить, нес па?


VD>Отсуствие перегрузки в Хаскеле — это дизайнерский выбор. Люди выбрали систему типов Хиндли-Миллера дающую ряд приемуществ (в частности готовый алгоритм вывода типов). Негативной стороной является отсуствие перегрзуки и запрет на неявное приведение типов. Так что это не хорошо и не плохо. Или и хорошо и плохо. Вопрос не в этом. Вопрос в том, насколько позитивные и негативные стороны влияют на конечный результат.


Я не говорил — хорошо, я не говорил — плохо. Я говорил — ограничение.

Классная кстати, тактика! Приписать оппоненту кучу своих домыслов, а потом их опровергать. Перед зеркалом, наверное, тренируешься?

L>>Что касается "был выбор" то вообще не понятно.


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


Ты читаешь вообще, о чем я пишу? Я написал о том, что из-за наличия/отсутствия выбора ограничение не перестает быть ограничением. Ты же эту мою фразу воспринял как то очень по своему.

L>> Ну, выбрали наличие в языке этого ограничения, ну есть для этого причины, и что? От того, что выбор был оно перестаёт быть ограничением?


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


К чему эта демагогия? Ты привязался к одному слову вместо того, чтобы ответить на вопрос.

VD>Если твой мозг не может этого понять, то я умываю руки. Ты никогда не станишь тем кто спосбен создать что-то нове.


Про тебя такого не скажешь, флеймы ты создавать — мастер!

L>>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


VD>Именно так. Верь в это. Тебе сразу станет лугче.


Да, я так и предполагал. Но, согласись, в таком случае ты не можешь оценить имеющихся у него преимуществ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[25]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 22:40
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Не извиню, то ты определяешь это как паранормальный дар, то говоришь, что в него не веришь. Ты уж давай определись


О! Заметил значит. Ну, значит не все потеряно. Так вот люди одаренные паранормальными способностями, они как баба яга или умный милиционер, т.е. существа мифические.
А с мифами разговаривать это не в полне нормальное занятие. По сему я этои больше заниматься не хочу. Адью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.07 22:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Даже параллельный конкуррентный GC вынужден на определенное время

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

У тебя отсуствует чувство реальности. Из своих же слов "на определенное время останавливать" ты почему-то сразу делаешь вывод "пару секунд зависать".
Между этими утверждениями нет никакой кареляции.
Подумай над этим.

>> C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки

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

>> Я не вижу причин по которым не реализовать удобное распараллеливание в

>> универсальных языках.
C>Проблема в том, что для GC в том же .NET не существует
C>иммутабельных объектов. Так как через reflection ты можешь поменять даже
C>содержимое string. А значит, куча оптимизаций из Erlang GC идет лесом.
Опять какие-то не относящиеся к делу аргументы. Я уже не говорю о том, что никакая рефлексия не мешает заниматься интернированием строк в донете. Мне просто интересно как все эта притянутая за уши фигня помешает мне создать удобный фрэймворк для распараллеливания некоторого класса задач?

>> О изменениях VM пока что можно только мечтать.

C>Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать

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

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

Учитывая все это, ответь плиз, на ворос — неужели нельзя создать удобный фрэйворк который хотя бы предотвратит тонных ошибок которые неизбежно убдут при ручной реалзации?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 02.03.07 23:10
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?


А какие у него достоинства?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 02.03.07 23:19
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций.

VD>>Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.

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


Что ты под этим ("писать от типа") понимаешь? Я не очень понял. Можно пример?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Не пора ли нам перейти на D
От: Андрей Хропов Россия  
Дата: 03.03.07 00:27
Оценка:
Здравствуйте, lomeo, Вы писали:

L>А чтобы тип был не uint, а любой numeric, как в примере на Haskell?


В системе типов .NET нет понятия numeric.
А так это бы выглядело примерно так (правда не уверен насчет приведения литералов, возможно надо было бы (0 : T)):

factorial[T](n : T) : T
    where T : numeric
    | 0 => 1
    | _ => n * factorial(n - 1)


С другой стороны, если Haskell как раз выведет тип функции factorial как numeric->numeric, то это неверно, поскольку вообще говоря факториал имеет смысл только для целых неотрицательных чисел, а вещественные числа вообще нельзя сравнивать на равенство (только с определенной точностью). Например

factorial 0.5


будет работать вечно
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 02:05
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

L>>А чтобы тип был не uint, а любой numeric, как в примере на Haskell?


АХ>В системе типов .NET нет понятия numeric.

АХ>А так это бы выглядело примерно так (правда не уверен насчет приведения литералов, возможно надо было бы (0 : T)):

Ясно, но это уже без вывода типов, так?

АХ>С другой стороны, если Haskell как раз выведет тип функции factorial как numeric->numeric, то это неверно,


Это да, но дело не в факториале, я вывод типов имел в виду.

Впрочем, ну его
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Не пора ли нам перейти на D
От: Andir Россия
Дата: 03.03.07 03:34
Оценка:
Здравствуйте, lomeo, Вы писали:

АХ>>Что ты под этим ("писать от типа") понимаешь? Я не очень понял. Можно пример?

L>Стандартный прием, который используется в Хаскеле, и который многократно видел поданный как совет в разных книжках статьях и прочее. Очень простой: "Если не ясно как должна выглядеть функция, сначала напиши её тип".

Это очень и очень напоминает Test-Driven Development, где собственно в качестве теста используется проверка на соответствие типа, но зато сразу осуществляется компилятором.

С Уважением, Andir!
Re[29]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 03.03.07 04:45
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>1) скорость компиляции (взасчет локального, а не глобального анализа)


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

АХ>2) компонентность (в т.ч. интеграция с другими языками)


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

АХ>3) упрощение реализации Intellisense в IDE (по тем же причинам, что и 1) )


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

АХ>В общем я целиком за локальность и следующующую из нее компонентность.


Думаю, основной проблемой глобального вывода типов будет всё же сложность глобальности, а сложность использования глобального вывода типов. Возможность снести крышу выводу типов в зависимости от запутанности кода увеличивается экспоненциально. И это только первое измерение. Второе измерение — это ошибочность набиваемого кода. Это уже не просто экспоненциальность, а экспоненциальная экспоненциальность. Уже этого достаточно, чтобы программист и компилятор уставившись друг в друга могли бы до посинения повторять: man, what's the fuck is going on Глобальность лишь добавит в эти отношения ещё одно измерение, ещё один уровень сложности. В результате процесс выйдет из под контроля и банально потеряет всю свою ценность.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Не пора ли нам перейти на D
От: vdimas Россия  
Дата: 03.03.07 06:36
Оценка:
Здравствуйте, Sinclair, Вы писали:


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


Интерфейсы в Java, Delphi, C# — аналоги виртуального наследования С++.

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


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


M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

А это пофиг. Оптимизация-то и инлайнинг происходят на ВЫЗЫВАЮЩЕЙ стороне. Т.е., даже если базовый метод уже "проджитен", он всё-равно может быть раскрыт в inline для конкретного места вызова. (для виртуальных машин рассуждения)
Re[30]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 03.03.07 09:29
Оценка:
Курилка wrote:
> C>Собираюсь делать небольшой проект — портирование CLR на LLVM. Пока для
> C>него финансирование делаю.
> CLI наверное имеется в виду? Интересно было бы посмотреть, мы услышим
> где как и что потом? Внутренний проект? Или Open Source?
Проект будет внутренним OpenSource проектом

В результате ожидается получение простейшего компилятора (который будет
еще и JIT-компилятором), способного переводить сборки .NET в объектные
файлы LLVM.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[28]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 03.03.07 09:47
Оценка:
VladD2 wrote:
>> > C>Даже параллельный конкуррентный GC вынужден на определенное время
>> > C>останавливать всех мутаторов. Оно достаточно короткое, но вполне
>> > C>существенное для многих целей.
>> > И что?
> C>Не всегда это терпимо. Хороший пример — игры. Вряд ли тебе будет
> C>приятно, если у тебя иногда игра будет на пару секунд зависать.
> У тебя отсуствует чувство реальности. Из своих же слов "на определенное
> время останавливать" ты почему-то сразу делаешь вывод "пару секунд
> зависать".
У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш
объектов) зависает примерно на 0.5-5 секунды каждые полчаса. Это было
очень неприятно, так как одна остановившаяся нода нарушала репликацию во
всем кластере.

>> > C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки

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

> C>Проблема в том, что для GC в том же .NET *не существует*

> C>иммутабельных объектов. Так как через reflection ты можешь поменять даже
> C>содержимое string. А значит, куча оптимизаций из Erlang GC идет лесом.
> Опять какие-то не относящиеся к делу аргументы. Я уже не говорю о том,
> что никакая рефлексия не мешает заниматься интернированием строк в
> донете.
Надеюсь, ты не будешь спорить о том, что интернация — это просто
оптимизация, которую применить можно очень редко, да которая еще и кривая?

> Мне просто интересно как все эта притянутая за уши фигня

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

>> > О изменениях VM пока что можно только мечтать.

> C>Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать
> Давай сделаем так. Если в друг твои мечты станут реальностью и ты
> доведешь это дело хотя бы до состояние бэты, то тогда и погворим. А
> потка ваши мечты и домысли не должны быть основанием для рассуждений,
> просто потому что они виртуальны.
Да без проблем

> Учитывая все это, ответь плиз, на ворос — неужели нельзя создать удобный

> фрэйворк который хотя бы предотвратит тонных ошибок которые неизбежно
> убдут при ручной реалзации?
В Эрланговском стиле? Вполне можно. Правда останутся проблемы с легкими
потоками — уж слишком гемморойно их эмулировать.

Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом
на нем аналог Эрланга и добавить туда фичи типа RI для управления
памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
уже слишком медленно.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[24]: Не пора ли нам перейти на D
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 03.03.07 10:12
Оценка:
Здравствуйте, Andir, Вы писали:

A>Это очень и очень напоминает Test-Driven Development, где собственно в качестве теста используется проверка на соответствие типа, но зато сразу осуществляется компилятором.


Да, наверное. В принципе, аналогий можно найти и других. Я имею в виду, что при использовании этого способа тип обычно остается в коде.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 11:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш

C>объектов) зависает примерно на 0.5-5 секунды каждые полчаса.

Оно крутится на дотнете? На каком типе GC?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 11:23
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>Чего ? Любой человек, кто в школе хотя бы немного видел математику (я думаю, что все-таки подавляющее большинство людей у нас в стране имеет хотя бы среднее образование) читает конструкции вида sin(x-1)*x совершенно однозначно.


Ага и совершенно не так как это требует синтаксис Хаскеля.

А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 11:23
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Так елки-палки, чего ж общаешься то? Конструктива то нет и не предвидится.


+1

Потому отвечать на выпады не буду.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 11:23
Оценка:
Здравствуйте, IT, Вы писали:

IT>Компонентность тут вообще никак не пострадает, т.к. скомпилированный метод уже будет выведен, либо просто не скомпилируется.


Тут ты не совсем понимашь о чем идет речь. Если мы говорим о глобальном выводе типов, но он делается на уровне всей программы. А это подразумевает, что любая новая строчка кода может изменить тип метода. Да и эта иделогия вообще не подразумевает наличие бинарных компонентов. Она рассматривает прграмму как монолит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 03.03.07 11:48
Оценка:
VladD2 wrote:
> C>У меня есть эмпирические данные — мое приложение с кучей в 4Гб (кэш
> C>объектов) зависает примерно на 0.5-5 секунды каждые полчаса.
> Оно крутится на дотнете? На каком типе GC?
Sun JVM, конкурентный параллельный инкрементальный GC. Если интересно,
то могу посмотреть конкретные настройки.

Проблема в том, что объектный кэш разделяется между всеми потоками
(даже, по сути, между всеми узлами кластера), да еще и постоянно
меняется, так как он служит чем-то вроде базы данных в памяти. Если
интересно, то этот кэш — это http://www.tangosol.com/coherence-overview.jsp

Аналогичная ситуация должна быть и в играх — там будет большой объем
данных, разделяемых между потоками. Особенно в новых играх с их
навороченой физикой.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[31]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 12:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Sun JVM, конкурентный параллельный инкрементальный GC.


Что и следоволо ожидать.

C>Если интересно,

C>то могу посмотреть конкретные настройки.

Нет, его проблем не интересуют. Просто не надо обобщать одну реализацию на все в целом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 03.03.07 14:46
Оценка:
VladD2 wrote:
> C>Sun JVM, конкурентный параллельный инкрементальный GC.
> Что и следоволо ожидать.
Как будто .NETвый GC сильно лучше.

> C>Если интересно,

> C>то могу посмотреть конкретные настройки.
> Нет, его проблем не интересуют. Просто не надо обобщать одну реализацию
> на все в целом.
Пока что Sun'овский GC — самый лучший, особенно если его настроить
правильно. По секрету скажу, что .NETовый GC загибается на 16
процессорах, а Sun'овский спокойно работает на 32. Данные вот от этих
товарищей: http://www.tangosol.com/coherence-.net.jsp
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[31]: Не пора ли нам перейти на D
От: IT Россия linq2db.com
Дата: 03.03.07 17:49
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>Компонентность тут вообще никак не пострадает, т.к. скомпилированный метод уже будет выведен, либо просто не скомпилируется.


VD>Тут ты не совсем понимашь о чем идет речь. Если мы говорим о глобальном выводе типов, но он делается на уровне всей программы. А это подразумевает, что любая новая строчка кода может изменить тип метода. Да и эта иделогия вообще не подразумевает наличие бинарных компонентов. Она рассматривает прграмму как монолит.


Да я в общем-то примерно о том же и говорю. Только я как бы предполагаю, что компонентность в .net уже есть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.07 19:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Как будто .NETвый GC сильно лучше.


Секундных задержек точно не замечано.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 03.03.07 20:20
Оценка:
VladD2 wrote:
> C>Как будто .NETвый GC сильно лучше.
> Секундных задержек точно не замечано.
Вполне заметно для некоторых сценариев использования.

Тут все зависит от вида графа объектов и их разделению между потоками.
Если каждый поток будет работать в основном со своими данными, то пауз
почти не будет — так как мусоросборщику не надо будет останавливать все
потоки (.NETовый и JVMные сборщики используют механизм защиты памяти для
остановки потока, если он обращается к данным, с которыми сейчас
работает GC). Точно так же, если данные будут не очень сильно связные,
то упаковщик пройдет по ним достаточно быстро и паузу можно не заметить.

У меня достаточно плохой случай — данных много, они разделяются между
потоками и они достаточно связные.

Я мониторил GC — сначала он достаточно долгое время использует полностью
конкуррентный mark&sweep (для старшей кучи, молодое поколение не
рассматриваем), но постепенно куча фрагментируется и он запускает
упаковщик. А это как раз и дает паузу.

А упаковка нескольких гигабайт объектов (даже параллельно на двух
процессорах) — занятие не мгновенное, как ни бейся.

Консультанты из Tangosol говорят, что их систему используют несколько
банков как раз для того, чтобы избежать этих пауз в GC с помощью их
системы распределенных запросов.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[7]: Не пора ли нам перейти на D или что-нибудь вроде этог
От: Disappear  
Дата: 04.03.07 14:29
Оценка:
Здравствуйте, OCTAGRAM, Вы писали:

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


[..умные и конструктивные высказывания пропущены, но учтены...]

OCT>Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada? Потому что на C похож (первое, что в глаза бросается)? Думаю, список должен быть шире. Вроде есть соседний топик "альтернативные" языки, но там альтернативность больше по ориентированности (ФП, ЛП) просвечивает, здесь же явно выраженная императивность.


Для static typed и native языка я не вижу в нем каких либо ограничений. И в конце концов, в мире же существуют какие-то стандарты, даже точнее не стандарты а культура. Почему возникло так много C подобных языков — потомучто большинству программистов, в силу естественного опыта, их проше воспринимать. А если вы С++ программист и я С++ программист, что может быть лучше редизайнутого С подобного языка, такого как D.
Re[12]: Не пора ли нам перейти на D
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.03.07 06:10
Оценка:
Здравствуйте, vdimas, Вы писали:
V>Интерфейсы в Java, Delphi, C# — аналоги виртуального наследования С++.
В третий раз повторяю: покажите мне жизненный пример, где есть "один виртуальный A и по одному невиртуальному A для каждого невиртуального пути наследования к A".
Кроме того, интерфейсы никак не являются аналогом виртуального наследования. У виртуального наследования аналогов нет.

V>Если наследовать интерфейсы, то да, достаточно лишь виртуального наследования. Но если охота наследовать реализации (вместе с данными/полями), то вид наследования определяет способ агрегирования базы. В принципе, ничего сложного в этом нет, один раз схема и стрелочки на бумаге рисуются и даже студенты моментально улавливают суть.

Не надо мне рассказывать, что такое виртуальное/невиртуальное наследование. Я в курсе. А у студентов, "моментально уловивших суть", я принимал экзамены по С++.

V>А это пофиг. Оптимизация-то и инлайнинг происходят на ВЫЗЫВАЮЩЕЙ стороне. Т.е., даже если базовый метод уже "проджитен", он всё-равно может быть раскрыт в inline для конкретного места вызова. (для виртуальных машин рассуждения)

Что-то сомневаюсь. Компилятор не имеет права инлайнить виртуальный метод, т.к. он может быть перегружен в одном из потомков.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 07:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>Чего ? Любой человек, кто в школе хотя бы немного видел математику (я думаю, что все-таки подавляющее большинство людей у нас в стране имеет хотя бы среднее образование) читает конструкции вида sin(x-1)*x совершенно однозначно.


VD>Ага и совершенно не так как это требует синтаксис Хаскеля.


Ты что-то путаешь, как раз тут будет полное соответствие синтаксису Хаскеля.

VD>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.


Тут тоже мат. значение и значение выражения в Хаскеле совпадают.
Влад, ты в чём разницу нашёл-то?
Re[29]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 08:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом

C>на нем аналог Эрланга и добавить туда фичи типа RI для управления
C>памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
C>уже слишком медленно.

Т.е. ты хочешь получить аналогичную модель, но более быструю за счёт статической типизации? Или есть ещё какие-то моменты оптимизации?
Re[30]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 08:28
Оценка:
Курилка wrote:
> C>Собственно, я сначала хотел портировать N. на LLVM, чтобы сделать потом
> C>на нем аналог Эрланга и добавить туда фичи типа RI для управления
> C>памятью. Потому как Эрланг работает неплохо, но на контроллерах с 170MHz
> C>уже слишком медленно.
> Т.е. ты хочешь получить аналогичную модель, но более быструю за счёт
> статической типизации? Или есть ещё какие-то моменты оптимизации?
Ага, я планирую повторить большую часть Эрланга. Если подумать, то
AppDomain'ы из .NET замечательно подходят для разделения границ потоков.
Хотя, наверное, придется придумать что-то свое.

На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже
занимается выводом типов и JIT-компиляцией, но на моих тестах он
существенного прироста скорости не дал.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[31]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 09:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ага, я планирую повторить большую часть Эрланга. Если подумать, то

C>AppDomain'ы из .NET замечательно подходят для разделения границ потоков.
C>Хотя, наверное, придется придумать что-то свое.

C>На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже

C>занимается выводом типов и JIT-компиляцией, но на моих тестах он
C>существенного прироста скорости не дал.

Круто.
Можно будет как-нибудь вам хотябы в бета-тестеры потом записаться?
Кстати, почему CLI а не JVM?
Re[32]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 09:30
Оценка:
Курилка wrote:
> C>На внутренности Эрланга я смотрел — мало что можно сделать. HiPE уже
> C>занимается выводом типов и JIT-компиляцией, но на моих тестах он
> C>существенного прироста скорости не дал.
> Круто.
> Можно будет как-нибудь вам хотябы в бета-тестеры потом записаться?
> Кстати, почему CLI а не JVM?
Хотя бы потому, что JVM для LLVM уже есть Там не хватает только
интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
мелочей типа многомерных массивов.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[33]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 10:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> Кстати, почему CLI а не JVM?
C>Хотя бы потому, что JVM для LLVM уже есть Там не хватает только
C>интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
C>мелочей типа многомерных массивов.

А почему не взята тогда за основу готовая JVM, если она есть? И на ней реализовать идеи эрланга?
Просто не совсем понимаю логику — зачем нужна реализация CLI для реализации эрланговских идей? Для интероперабельности?
И вообще какая, если не секрет, конечная цель продукта? Просто перегонять CLI-байткод в LLVM — это одна задача, эрланговская параллельность — другая задача, каким образом они пересекаются?
Re[34]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 10:42
Оценка:
Курилка wrote:
> C>Хотя бы потому, что JVM для LLVM уже есть Там не хватает только
> C>интерфейса с GC (в LLVM еще не было интеграции с GC, когда ее писали) и
> C>мелочей типа многомерных массивов.
> А почему не взята тогда за основу готовая JVM, если она есть? И на ней
> реализовать идеи эрланга?
Я просто не вижу смысла портировать JVM — она и так уже есть везде, где
только можно.

> Просто не совсем понимаю логику — зачем нужна реализация CLI для

> реализации эрланговских идей? Для интероперабельности?
> И вообще какая, если не секрет, конечная цель продукта? Просто
> перегонять CLI-байткод в LLVM — это одна задача, эрланговская
> параллельность — другая задача, каким образом они пересекаются?
Я хочу взять достаточно мощный язык (N.), а потом добавить туда
примитивы для многозадачности в Эрланговском стиле. Это можно сделать
даже в рамках CLR.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[35]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 10:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> Просто не совсем понимаю логику — зачем нужна реализация CLI для
>> реализации эрланговских идей? Для интероперабельности?
>> И вообще какая, если не секрет, конечная цель продукта? Просто
>> перегонять CLI-байткод в LLVM — это одна задача, эрланговская
>> параллельность — другая задача, каким образом они пересекаются?
C>Я хочу взять достаточно мощный язык (N.), а потом добавить туда
C>примитивы для многозадачности в Эрланговском стиле. Это можно сделать
C>даже в рамках CLR.

Но значительно медленней без поддержки в виртуальной машине?
Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на модель CLI.
У меня нет уверенности, что это в принципе возможно. От мутабельности переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?
Re[36]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 11:09
Оценка:
Курилка wrote:
> C>Я хочу взять достаточно мощный язык (N.), а потом добавить туда
> C>примитивы для многозадачности в Эрланговском стиле. Это можно сделать
> C>даже в рамках CLR.
> Но значительно медленней без поддержки в виртуальной машине?
В том-то и дело, что я хочу добавить поддержку в VM с интерфейсом в виде
intrinsic-функций.

> Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на

> модель CLI.
Просто

> У меня нет уверенности, что это в принципе возможно. От мутабельности

> переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
> Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?
Так пусть себе мутируют — для посылки сообщений между потоками можно
будет использовать только гарантировано иммутабельные объекты или
использовать глубокое копирование. А внутри потоков может быть что угодно.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[37]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 11:23
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на
>> модель CLI.
C>Просто
Да? Интересно было бы посмотреть

>> У меня нет уверенности, что это в принципе возможно. От мутабельности

>> переменных фиг избавишься, а это, сам понимаешь, модель уже сильно поменяет.
>> Реализация подобия эрланга на немерле — это тоже будет ваш проект или как?
C>Так пусть себе мутируют — для посылки сообщений между потоками можно
C>будет использовать только гарантировано иммутабельные объекты или
C>использовать глубокое копирование. А внутри потоков может быть что угодно.

Ну если забить на софтриалтайм, то да, но тогда на программисте будет лежать груз ответственности, что его бесконечный цикл не сьест всё время процессорное у ВМ. Или же будет какое-нибудь комбинирование лёгких и обычных потоков типа того, что в Scala.Actors возможно?
А проект на Немерле — секрет? Просто если Open Source, то возможно было бы интересно поучаствовать.
Re[38]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 11:30
Оценка:
Курилка wrote:
>> > Просто не совсем понятно, как ты эрланговскую семантику "натянешь" на
>> > модель CLI.
> C>Просто
> Да? Интересно было бы посмотреть
Если кратко — то в каждый объект добавляется флажок "immutable", после
того, как этот флажок выставлен попытки записать в объект будут вызывать
exception (в релизе можно будет отключить эту проверку).

Естественно, immutable-объект может указывать только на immutable-объекты.

> C>Так пусть себе мутируют — для посылки сообщений между потоками можно

> C>будет использовать только гарантировано иммутабельные объекты или
> C>использовать глубокое копирование. А внутри потоков может быть что угодно.
> Ну если забить на софтриалтайм, то да, но тогда на программисте будет
> лежать груз ответственности, что его бесконечный цикл не сьест всё время
> процессорное у ВМ.
Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
не отменял.

> Или же будет какое-нибудь комбинирование лёгких и

> обычных потоков типа того, что в Scala.Actors возможно?
Думаю пока. Легкие потоки кто-то уже реализовывал на LLVM, да и не
сильно это сложно.

> А проект на Немерле — секрет? Просто если Open Source, то возможно было

> бы интересно поучаствовать.
Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока
ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
личного присутствия начинать не хочется).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[39]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 11:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> Ну если забить на софтриалтайм, то да, но тогда на программисте будет
>> лежать груз ответственности, что его бесконечный цикл не сьест всё время
>> процессорное у ВМ.
C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
C>не отменял.
Т.е. всёж ответственность на программисте и любой кривой код сможет "подвесить" виртуальную машину?

>> А проект на Немерле — секрет? Просто если Open Source, то возможно было

>> бы интересно поучаствовать.
C>Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока
C> ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
C>личного присутствия начинать не хочется).
Теперь я уже запутался...
Ты озвучил 2 задачи:
1. CLI на LLVM
2. Реализации эрланговской модели на чём-нибудь типа N. на базе CLI

первый пункт понятно на C++, но второй?
Re[40]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 13:08
Оценка:
Курилка wrote:
> C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
> C>не отменял.
> Т.е. всёж ответственность на программисте и любой кривой код сможет
> "подвесить" виртуальную машину?
Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
проблемы-то?

> C>Проект на С++, так как сама LLVM на С++. Будет OpenSource, начнется пока

> C> ориентировочно 1 мая (я скоро улетаю в командировку, а без моего
> C>личного присутствия начинать не хочется).
> Теперь я уже запутался...
> Ты озвучил 2 задачи:
> 1. CLI на LLVM
> 2. Реализации эрланговской модели на чём-нибудь типа N. на базе CLI
> первый пункт понятно на C++, но второй?
Тоже на С++ — ведь придется VM расширять. Естественно, потребуются
какая-то интеграция со стороны N. — но это уже будут мелочи.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[41]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 13:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> C>Естественно, будут легкие потоки. Да и обычный scheduling потоков никто
>> C>не отменял.
>> Т.е. всёж ответственность на программисте и любой кривой код сможет
>> "подвесить" виртуальную машину?
C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
C>проблемы-то?

Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где будет этот вечный цикл ты прервать не сможешь для использования другими лёгкими процессами. Чего в Эрланге не получится.
Re[42]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 13:32
Оценка:
Курилка wrote:
> C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
> C>проблемы-то?
> Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где
> будет этот вечный цикл ты прервать не сможешь для использования другими
> лёгкими процессами.
Почему??? У нас ведь не кооперативная многозадачность с явным вызовом
yeild. Поток с вечным циклом — это просто один из претендентов на
процессорное время. То что в нем ничего полезного не делается — это
ничего не значит.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[43]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 13:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> C>Даже в обычном .NET/JVM вечный цикл не сможет подвесить JVM. Какие
>> C>проблемы-то?
>> Ну не подвесить, а сьесть почти всё процессорное время. И тот поток, где
>> будет этот вечный цикл ты прервать не сможешь для использования другими
>> лёгкими процессами.
C>Почему??? У нас ведь не кооперативная многозадачность с явным вызовом
C>yeild. Поток с вечным циклом — это просто один из претендентов на
C>процессорное время. То что в нем ничего полезного не делается — это
C>ничего не значит.

На лёгких процессах в рамках одного потока кооперативная и есть. Другое дело, что за этими потоками может шедулер следить и т.п. в другом потоке.
В рамках же эрланговской модели всё решается в рамках вообще одного потока и кооперативная многозадачность, только вот там дробление процессорного времени по редукциям идёт, а редукцию реально длинной сделать не получится.
А так как ты будешь перехватывать управление у процесса, который в бесконечный цикл вошёл, причём возможно там нужно сохранять соостояние и т.п. (что приводит к варианту с обычными потоками)?
Конечно, если не перехватывать, то всё нормально, только процессорное время отъедаться будет.
Re[44]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 05.03.07 14:24
Оценка:
Здравствуйте, Курилка, Вы писали:

C>>Почему??? У нас ведь не кооперативная многозадачность с явным вызовом

C>>yeild. Поток с вечным циклом — это просто один из претендентов на
C>>процессорное время. То что в нем ничего полезного не делается — это
C>>ничего не значит.
К>На лёгких процессах в рамках одного потока кооперативная и есть. Другое дело, что за этими потоками может шедулер следить и т.п. в другом потоке.
Это означает, что с точки зрения потока, многозадачность будет вытесняющей. А то что планировщик реализуется не ядром ОС — это уже детали.

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

К>А так как ты будешь перехватывать управление у процесса, который в бесконечный цикл вошёл, причём возможно там нужно сохранять соостояние и т.п. (что приводит к варианту с обычными потоками)?
Останавливаем его на ближайшем GC safepoint'е (очень удачная синэргетика получается ), сохраняем стек c регистрами и передаем управление "кому нужно".
Sapienti sat!
Re[45]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.03.07 14:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:


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

C>Останавливаем его на ближайшем GC safepoint'е (очень удачная синэргетика получается ), сохраняем стек c регистрами и передаем управление "кому нужно".

OK much better
Вопрос только — а что за сейфпойнты? Насколько трудно их находить, насколько их много в программе и не вырастет ли сохранение стека в вариант обычного переключения контекста по затратам?
Re[21]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.03.07 18:54
Оценка:
Здравствуйте, Курилка, Вы писали:

VD>>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.


К>Тут тоже мат. значение и значение выражения в Хаскеле совпадают.

К>Влад, ты в чём разницу нашёл-то?

Что совподает то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.03.07 07:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:


VD>>>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.


К>>Тут тоже мат. значение и значение выражения в Хаскеле совпадают.

К>>Влад, ты в чём разницу нашёл-то?

VD>Что совподает то?


Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1
Но мне уже надоело искать где ты проблему видишь, если честно. Ты хаскелем вроде не пользуешься, поэтому не страшно, наверное.
Re[24]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.03.07 10:17
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Курилка, Вы писали:


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


К>>Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1


D>Хватит путаницы на ровном месте!


D>Конечно, умножение всегда должно указываться явно, в отличие от школьной алгебры. И, конечно, sin x — 1 не есть (sin * x) — 1.


Фига
Я до такого не додумался
Re[24]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.03.07 10:18
Оценка:
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Курилка, Вы писали:


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


К>>Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1


D>Хватит путаницы на ровном месте!


D>Конечно, умножение всегда должно указываться явно, в отличие от школьной алгебры. И, конечно, sin x — 1 не есть (sin * x) — 1.


Блин, звёздочку-то я и не приметил, мда, запылились глаза уже, сорри
Re[25]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.03.07 22:00
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Блин, звёздочку-то я и не приметил, мда, запылились глаза уже, сорри


Я правильно понимаю, что вопрос знаком равенства между семантикой Хаскеля и "привычной всем школьной математикоЙ" снят?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.07 03:12
Оценка:
Здравствуйте, EvilChild, Вы писали:

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


Cyberax действительно соображает о чем говорит, но ты уж сильно преувуличиваешь о картах корней GC говорится в любой статье посвященной этому поводу, а безопасные точки единственный способ сделать их более менее компактными. Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 17.03.07 07:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Cyberax действительно соображает о чем говорит, но ты уж сильно преувуличиваешь о картах корней GC говорится в любой статье посвященной этому поводу, а безопасные точки единственный способ сделать их более менее компактными.

Да дело не в картах, просто у Cyberax'а есть подробная и целостностная картина в данном вопросе, подкреплённая нехилой практикой и есть желание поделиться этим знанием с другими — разве бывают лучшие предпосылки для статьи?

VD>Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна.

Если статья будет её будут читать те, кому она реально интересна, вот и всё.

В общем я не понял, что ты хотел своим постом сказать.
now playing: Peter Gabriel — Sledgehammer
Re[50]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.03.07 15:30
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Да дело не в картах, просто у Cyberax'а есть подробная и целостностная картина в данном вопросе, подкреплённая нехилой практикой и есть желание поделиться этим знанием с другими — разве бывают лучшие предпосылки для статьи?


Откуда практика то? О чем ты? А теорией можешь разжиться через гугль. Набирашь те самые базворды GC "safe point" "GC root" map. Например, там во первых редах сразу попалась глава из книжки посвященной Ротору. ЖЦ дотнета посложнее, но принципы те же.

А практика тебя разочарует. Это очень низкоуровневый и запутанный код. Там главное оптимизации. Алгоритмы давно извесны, но львиная доля успеха зависит от деталей.

Единственное, что есйчас интересно в этой област с точки зрения теории — это анализ потока данных и автоматическое размещение объектов на стеке. Вот только пока что нет ни одной удовлетворительно работающей реализации. Сан ведет работы над этим (эскейп-анализ называется) и пара институтов. Но будет ли выхлоп и какой он будет пока не ясно. Хотя технология очень многообещающая. По радостным рекламным возгласам эффективность управления памятью в плотную приблизится к лучшиму что можно достигнуь управляя памятью вручную (не путать с тем чего достигают большинство обывателей).

Вот только боюсь, что это вся доступная информация по этому поводу .

VD>>Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна.

EC>Если статья будет её будут читать те, кому она реально интересна, вот и всё.

Она интересна 5-10 коллективам которые занимаются эторй проблематикой. И боюсь, что все они русский не знают. Еще раз повторюсь — это очень низкоуровневая область. Это пожалуй единственное что в современных ОС имеет смысл писать на смеси С и ассемблера. Битовыжимание в общем.

Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое изложение интересно еденицам.

EC>В общем я не понял, что ты хотел своим постом сказать.


Я тебе объсняю, что тебе это интересно на очень поверхностном уровен. Если действительно писать серьезную статью, то получится переусложненная научная рабта на которую ты и не взглянишь. Таких (правда на английском) довольно много в открытом доступе валяется. Есть даже пара книг специально алгоритмам сборки мусора посвященных. Но ты их даже не посмотришь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: Не пора ли нам перейти на D
От: EvilChild Ниоткуда  
Дата: 17.03.07 18:06
Оценка:
Здравствуйте, VladD2, Вы писали:

Надеюсь Cyberax твоё сообщение не читал, а если читал, то напишет статью не смотря на него.
now playing: Quinoline Yellow — A Fraction Of Crouching
Re[52]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.03.07 14:16
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Надеюсь Cyberax твоё сообщение не читал, а если читал, то напишет статью не смотря на него.


Я не против статьи. Я просто заранее предупреждаю о том, что это будет очень узкоспецифичная вещь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.03.07 14:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>К сожалению, не все так просто. Хороших статей про внутреннее

C>описание работы тонких моментов в GC не так уж и много. Все что есть —
C>это, в основном, пересказы про то как работают механизмы GC с поколениями.

Не ты ли как то тут давал ссылку на сайт где описывались все возможные варинты GC вклюя инкрементальные и параллельные?

C>Например, организации safepoint'ов уделено не так уж много статей. В

C>твоей статье в про SSCLI используется самый простой и тупой подход —
C>поллинг.

Там описывается то что есть в Роторе. Собственно для понимания принципов этого более чем достаточно. А детали и есть детали. Все равно в основе базовая идея создания карт для некоторых участков кода.

C>Тут в теории нет ничего сложного


В теории GC — это элементарнь.
Вот только на практике GC был еще в Симуле, но Страуступ что-то отказался от реализации GC в С++ только на том основании, что не верил, что в приципе можно создать достаточно эффективный GC. Только в 1994 году Страуступ сказал, что возможно сейчас и можно было бы создать эффективный GC (так как теория продвинулась даеко вперд), но вот совместимость, да и все равно я не верю, в то что GC...

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

C> — просто строим CFG и ищем объекты,

C>которые не выходят за границы метода.

Языком можно очень просто делать многие вещи. Вот, например, встраивать виртуальные вызовы и функциональные объекты. А на практике это почему-то оказывается очень сложным.

Вот почему ты бросил разработку своего GC для Моно? Не уж то задача оказалась слишком простая?

C>Но это в теории, а на практике получается огромная сложность в связке

C>кодогенератор+GC. Причем еще и осложненная необходимостью быстрой
C>работы.

"Еще"? Это как бы главная задача. Медленный или хриновый GC может сделать и ребенок. Вот в Обероне очень быстрый GC... пока дело не доходит до дела. А на практике он умирает при некотором объеме объектов, а казалось бы несколько более медленный дотнетный живет при значительно большем объеме объектов.

C>Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом

C>уже с WolfHound'ом говорил.

Ты выше сказал правильную вещь. GC не отделим от JIT. Скажу больше подсистема анализа тоже. Это общий механизм и только будучи тесно интергрированными и спроектированными совместно можно достичь высокой скорости и малых объемов памяти.

В том то вся и сложность.

C>Ну и на ручное управление памятью не надо наезжать, оно живее всех живых


Оно — это этап в эволюции языков который должен был быть пройден еще десятки лет назад.
Заставлять управлять памятью вручную в 21-веке — это варварство. Так же как делать нетипобезопасные езяки.

>> Вот только боюсь, что это вся доступная информация по этому поводу .

C>Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено
C>искать.

Дай ссылку хоть на одну интересную. А то я только треп на тему видел.

>> Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое

>> изложение интересно еденицам.
C>Я ее прочел

Тебе в ней наверно вообще интересного ничего не было. Ну, да что с того даже если ты вошел в эти еденицы?

>> Есть даже пара книг специально алгоритмам сборки мусора посвященных.

>> Но ты их даже не посмотришь.
C>Собственно, я знаю только одну хорошую книгу —
C>http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484

У меня ссылок нет, но когда я интересовался этой темой то нашел целый сайт с офигительным описанием всех теоритических выладок.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[53]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 18.03.07 16:37
Оценка:
VladD2 wrote:
> C>К сожалению, не все так просто. *Хороших* статей про внутреннее
> C>описание работы тонких моментов в GC не так уж и много. Все что есть —
> C>это, в основном, пересказы про то как работают механизмы GC с поколениями.
> Не ты ли как то тут давал ссылку на сайт где описывались все возможные
> варинты GC вклюя инкрементальные и параллельные?
Ты имеешь в виду memorymanagement.org? Так там только по сути глоссарий
и хорошая библиография.

> C>Например, организации safepoint'ов уделено не так уж много статей. В

> C>твоей статье в про SSCLI используется самый простой и тупой подход —
> C>поллинг.
> Там описывается то что есть в Роторе. Собственно для понимания принципов
> этого более чем достаточно. А детали и есть детали.
Дьявол, как известно, как раз в деталях

> Все равно в основе базовая идея создания карт для некоторых участков кода.

Ну да, точно так же как и escape-анализ — это "просто" анализ CFG.

> В общем, теория и практика разные вещи. Именно по этому сейчас почти все

> исследования в области GC — это практические исследования или
> исселодования с большим объемом практического тестирования и сравнений.
Ну... Для теоретиков еще хватает места, например, в области
распределенных GC.

> Вот почему ты бросил разработку своего GC для Моно? Не уж то задача

> оказалась слишком простая?
Нет, просто потерял интерес к C# — увлекся Бустом. Хотя до сих пор
иногда хочется продолжить заниматься своим GC.

> C>Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом

> C>уже с WolfHound'ом говорил.
> Ты выше сказал правильную вещь. GC не отделим от JIT. Скажу больше
> подсистема анализа тоже. Это общий механизм и только будучи тесно
> интергрированными и спроектированными совместно можно достичь высокой
> скорости и малых объемов памяти.
Мне лень повторяться, но... Для GC результат escape-анализа заключается
в том, что он просто считает некоторые объекты находящимися в
pinned-куче. Никакие алгоритмы самого GC (кроме начального построения
корней) не меняются от того, что некоторые объекты вдруг оказываются на
стеке.

> В том то вся и сложность.

GC можно разделить на две части: низкоуровневую и высокоуровневую.
Низкоуровневая часть занимается сбором корней GC, остановкой потоков,
управлением виртуальной памятью. Это, на самом деле, не так уж много
кода занимает (хотя этот код и получается очень сложным).
Высокоуровневая часть — это алгоритмы упаковки, прохода по объектам, и т.п.

Низкоуровневую и высокоуровневую части вполне можно разделить, что и
делают в нормальных реализациях (см. Sun JVM, например, там алгоритмы GC
плугабельны).

> C>Ну и на ручное управление памятью не надо наезжать, оно живее всех живых

> Оно — это этап в эволюции языков который должен был быть пройден еще
> десятки лет назад.
> Заставлять управлять памятью вручную в 21-веке — это варварство. Так же
> как делать нетипобезопасные езяки.
Ну что сделать, без этих языков не было бы C#

>> > Вот только боюсь, что это вся доступная информация по этому поводу .

> C>Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено
> C>искать.
> Дай ссылку хоть на одну интересную. А то я только треп на тему видел.
См. ссылку про GC Points в предидущем письме, например.

Ну а так, смотри http://research.sun.com/techrep/

>> > Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое

>> > изложение интересно еденицам.
> C>Я ее прочел
> Тебе в ней наверно вообще интересного ничего не было. Ну, да что с того
> даже если ты вошел в эти еденицы?
Ну хоть люди будут знать как GC умеет собирать циклы объектов На моей
памяти этот вопрос дважды в форуме по Java задавали.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[54]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.03.07 22:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну хоть люди будут знать как GC умеет собирать циклы объектов На моей

C>памяти этот вопрос дважды в форуме по Java задавали.

Да ничерта не изменится. Вот писал я писал статью ро GC в дотнете и что? Все фобии как были так и остались.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.03.07 22:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Дай ссылку хоть на одну интересную. А то я только треп на тему видел.

C>См. ссылку про GC Points в предидущем письме, например.

C>Ну а так, смотри http://research.sun.com/techrep/


Напомню, что ты говорил о ссылках на интересную информацию о escape-анализе. А в прошлом твоем письме ссылка на статью 1998-года.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Не пора ли нам перейти на D
От: x-code  
Дата: 19.03.07 09:35
Оценка:
Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!

D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?

D>Разве мы не заслужили

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

ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ.
как думаете?
Re[55]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 19.03.07 09:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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

C>>Ну а так, смотри http://research.sun.com/techrep/
VD>Напомню, что ты говорил о ссылках на интересную информацию о escape-анализе. А в прошлом твоем письме ссылка на статью 1998-года.
Я говорил про статьи о GC в общем.

Ну а про escape analysis:
http://portal.acm.org/citation.cfm?id=1064996&amp;dl=ACM&amp;coll=&amp;CFID=15151515&amp;CFTOKEN=6184618

Ну и еще можно поискать, мне попадалась еще пара интересных статей.
Sapienti sat!
Re[2]: Не пора ли нам перейти на D
От: Disappear  
Дата: 19.03.07 10:02
Оценка:
Здравствуйте, x-code, Вы писали:

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


XC>думаю что разработчикам D стоит затратить некоторое время и написать плагин для студии, который бы позволял как встраивать D-шные файлы в существущие С++ные проекты, так и создавать целиком D-шные проекты.


XC>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам.

Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.

XC>ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ.

XC>как думаете?

Думаю, что это очень разумное предложение,
еще нужно не забыть о том, что этот плагин должен позволять дебажиться в D.
Re[56]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.03.07 11:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я говорил про статьи о GC в общем.


А зачем, если я спрашивал о конкретной вещи?

C>Ну а про escape analysis:

C>http://portal.acm.org/citation.cfm?id=1064996&amp;dl=ACM&amp;coll=&amp;CFID=15151515&amp;CFTOKEN=6184618

Кстати, как от туда взять статью то? Обзательно регистрироваться?

C>Ну и еще можно поискать, мне попадалась еще пара интересных статей.


Мне тоже попадались. Но вот сейчас поискал и что-то сразу не нашел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.03.07 12:01
Оценка:
Здравствуйте, Disappear, Вы писали:

XC>>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам.

D>Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.

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

XC>>ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ.


Гы-гы.

D>Думаю, что это очень разумное предложение,

D>еще нужно не забыть о том, что этот плагин должен позволять дебажиться в D.

Ребят. Интеграция для Ди делается. Только традиционно на C# (гы-гы). Вот только создать качественную интеграцию — это работа не сильно проше чем написать весь компилятор этого самого D. Так что не ждите чего-то сверхестественного в ближайшее время.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 19.03.07 12:09
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Я говорил про статьи о GC в общем.

VD>А зачем, если я спрашивал о конкретной вещи?
Ну чукча же не читатель

C>>Ну а про escape analysis:

C>>http://portal.acm.org/citation.cfm?id=1064996&amp;dl=ACM&amp;coll=&amp;CFID=15151515&amp;CFTOKEN=6184618
VD>Кстати, как от туда взять статью то? Обзательно регистрироваться?
Нет, просто нажми на кнопку "PDF". Прямая ссылка на PDF: http://delivery.acm.org/10.1145/1070000/1064996/p111-kotzmann.pdf?key1=1064996&amp;key2=3095034711&amp;coll=&amp;dl=ACM&amp;CFID=15151515&amp;CFTOKEN=6184618

C>>Ну и еще можно поискать, мне попадалась еще пара интересных статей.

VD>Мне тоже попадались. Но вот сейчас поискал и что-то сразу не нашел.
Могу в своих свалках ссылок поискать.
Sapienti sat!
Re[58]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.03.07 20:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, просто нажми на кнопку "PDF". Прямая ссылка на PDF: http://delivery.acm.org/10.1145/1070000/1064996/p111-kotzmann.pdf?key1=1064996&amp;key2=3095034711&amp;coll=&amp;dl=ACM&amp;CFID=15151515&amp;CFTOKEN=6184618


У них видимо сайт глючит переодически. Днем нажимал на Pdf, а мне выскакивал левый диалог логина. Зарегистрироваться вообще не удовалось (тормозил и выдавал ошибку). Сейча вот открылся. Явные глюки. И это типа под патронажем Гугля .

ОК, попрогую глянуть. Спасибо.

C>Могу в своих свалках ссылок поискать.


Мне то уже не нужно. Но народу може окажется интересным. Вот EvilChild интересуется...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Не пора ли нам перейти на D
От: x-code  
Дата: 20.03.07 13:33
Оценка:
Здравствуйте, VladD2, Вы писали:

XC>>>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам.

D>>Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.

VD>Библиотека изменяющая формат бинарных файлов? Это что-то новое.

VD>D и С++ не совместимы. В этом весь прикол. Так что создать общий проект можно только при условии, что интеграция идет через С. А это означает "скажи классам досвиданья".

Может имелся в виду линкер, который бы понимал и Сишные, и С++ные, и D-шные объектники? (ну и еще чтобы компилятор D понимал С++-ные h-файлы... не знаю как там с этим). Думаю это не настолько сложно как создать компилятор.

Вообще, с линкерами проблема: например, недавно парился с тем, что линкер в 2003 студии не видит ресурсы, включенные в библиотеку. Наверняка в исходниках линкера пару строчек исправить, а вот нет, не исправили (это еще с VS6 идет)
Re[5]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.03.07 21:03
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Может имелся в виду линкер, который бы понимал и Сишные, и С++ные, и D-шные объектники? (ну и еще чтобы компилятор D понимал С++-ные h-файлы... не знаю как там с этим).


Я кажется ясно сказал "D и С++ не совместимы.".

XC>Думаю это не настолько сложно как создать компилятор.


Это не сделано. А сложно или нет осбуждаеть смысла нет. Автор говорит, что сложно.

XC>Вообще, с линкерами проблема: например, недавно парился с тем, что линкер в 2003 студии не видит ресурсы, включенные в библиотеку. Наверняка в исходниках линкера пару строчек исправить, а вот нет, не исправили (это еще с VS6 идет)


Это проблемы МС. В принципе С++ от линкера не зависит. Лиш бы оный поддерживал длинные имена функций. Но конечно каждый производитель вносит свои изменения и они все между собой не совместимы.

С++ вообще никак не описывает бинарную совместимость в следствии чего в этой области полная вакханалия. Вот Ява и дотнет другое дело, но Ди и с ними не совместим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Не пора ли нам перейти на D или что-нибудь вроде этог
От: gear nuke  
Дата: 07.04.07 22:12
Оценка:
Здравствуйте, OCTAGRAM, Вы писали:

[]

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


Да, например, про рантаймы и компиляторы безопасных языков

Кстати, пресловутое переполнение буфера возникает (вопреки ошибочному мнению) не из-за отсутствия проверок на выход за пределы массива (которые есть не только в С++, но даже в x86 ассемблере) и т.п. при обработке данных, а из-за отсутствия валидации этих данных на входе, что является ошибкой в логике. Подобная ситуация может привести к многим другим способам инекции кода (eval/ASP/PHP/SQL/... injection), либо к отказу в обслуживании.

[]

OCT>Я считаю, целостность — минимальное требование. Поэтому C/C++ я считаю хламом. Историческую функцию они исполнили (когда нужно лишь бы работало). Я считаю, нужно давно что-то менять. Вы можете признавать это, можете нет, это ваше дело.


OCT>Взять в качестве только D, я считаю, сильное ограничение. Почему D? Почему не Eiffel или Ada?


one of the most famous computer bugs in history

Because of the different flight path, a data conversion from a 64-bit floating point to 16-bit signed integer value caused a hardware exception (more specifically, an arithmetic overflow, as the floating point number had a value too large to be represented by a 16-bit signed integer). Efficiency considerations had led to the disabling of the software handler (in Ada code) for this error trap, although other conversions of comparable variables in the code remained protected. This led to a cascade of problems, culminating in destruction of the entire flight.



Из серебра делают монеты, а не пули.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[11]: Не пора ли нам перейти на D
От: gear nuke  
Дата: 07.04.07 22:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.


Я с этим категорически... не пойму, согласен или нет Ведь по сути x86 опкоды выполняются на некоей RISC машине. Осталось доработать это дело, что бы выполнял MSIL. Догнать Java
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[12]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 08.04.07 00:33
Оценка:
Здравствуйте, gear nuke, Вы писали:

WH>>Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.

GN>Я с этим категорически... не пойму, согласен или нет Ведь по сути x86 опкоды выполняются на некоей RISC машине. Осталось доработать это дело, что бы выполнял MSIL. Догнать Java
Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус.

Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код.
Sapienti sat!
Re[13]: Не пора ли нам перейти на D
От: gear nuke  
Дата: 08.04.07 04:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус.


Я вобщем-то и намекал, что нативный код — понятие относительное

C>Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код.


Разные по размеру опкоды x86 тоже плохо подходят для выполнения на высокочастотных ядрах, поэтому разбиваются на микрооперации (JIT компиляция ).
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[14]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 08.04.07 05:36
Оценка:
Здравствуйте, gear nuke, Вы писали:

C>>Дык без проблем. Java-процессоров на рынке — завались. Выбирай на любой вкус.

GN>Я вобщем-то и намекал, что нативный код — понятие относительное
Ну так это понятно.

C>>Модель виртуальной машины в .NET/JVM — стековая, и не особо подходит для быстрого выполнения на реальном железе (а у .NET так вообще неприспособлена совершенно из-за generic арифметических инструкций). Ее надо предварительно превратить в нормальный промежуточный код.

GN>Разные по размеру опкоды x86 тоже плохо подходят для выполнения на высокочастотных ядрах, поэтому разбиваются на микрооперации (JIT компиляция ).
Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.
Sapienti sat!
Re[6]: Не пора ли нам перейти на D
От: -DeBUGGeR- Россия www.green-d.com
Дата: 08.04.07 12:57
Оценка:
Господа — это жесть столько сообщений в теме )))))

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

PS: или я не так все понял...
PSS: Может сделаем язык E ? (хотя может уже и есть)
Господи, перезагрузи этот мир...
Re[15]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 08.04.07 12:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.

А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Не пора ли нам перейти на D
От: gear nuke  
Дата: 08.04.07 14:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Тут фича в том, что для x86 это достаточно просто сделать.


Реальная причина другая — делать это требует рынок. Есть более простые способы получить лучшую произволительность, пример Itanic'а показал их жизнестойкость. Если MS доведут Сингулярность до ума (а они это сделают в том или ином виде, пусть и под другим названием) — такое железо появится. Фишка в том, что гигагерцы там не обязательны, для десктопа хватит подобного проца с частотой в сотню-другую мегагерц, для телефонов — подавно.

C>А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.


Зачем регистры, там же стековая машина.

Процессоры оптимизируют под языки. Как Керниган и Риччи заменили синтаксис ассемблера PDP на более "красивный" кросплатформенный, так и понеслось развитие в этом направлении. И вошло в замкнутый круг. Вот вроде бы революционная технология HT — попытка параллельного выполнения команд одним ядром. Но это плохо вписывается в модель PDP, поэтому реально даже тормоза оказылись. А если бы повсеместно писали на Erlang, кто знает, нужны ли бы были многоядерные процы с изоляцией ядер и громоздким механизмом межпроцессорного взаимодействия, не лучше ли иметь проц с большим набором регистров, каждый из котрых может служить и instruction pointer.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[7]: Не пора ли нам перейти на D
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.04.07 17:13
Оценка:
Здравствуйте, -DeBUGGeR-, Вы писали:

DBU>PSS: Может сделаем язык E ? (хотя может уже и есть)


Давно есть, причём есть довольно интересные идеи, да и там же есть ссылки на ещё 2 E.
Re[16]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 09.04.07 03:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Тут фича в том, что для x86 это достаточно просто сделать. А для Java-байткодов придется делать такие вещи, как оптимизированое распределение регистров, а для этого уже нужно строить полный CFG функций. Ну а это уже совершенно непрактично в железе.

WH>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?
Мы уже об этом флеймили

Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций. Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.
Sapienti sat!
Re[17]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 09.04.07 08:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

WH>>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?

C>Мы уже об этом флеймили
И в прошлый раз так и небыло показано никаких преимуществ хардкода арифметики в модель ВМ. Но были показаны проблемы на примере тогоже .NET 2

C>Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций.

Нечего им там делать.

C>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.

Интерпритацию в морг.
Она может быть допустима только в случае управляющих комманд для чегото гораздо болие тяжолого.
А если она выполняет основные вычисления то точно в морг.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 09.04.07 10:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А раз всеравно делать полноценный анализ то нафига вобще арифметику в виртуальную машину хардкодить?

C>>Мы уже об этом флеймили
WH>И в прошлый раз так и небыло показано никаких преимуществ хардкода арифметики в модель ВМ. Но были показаны проблемы на примере тогоже .NET 2
C>>Такие вещи, как аримфетика или векторные инструкции лучше пусть будут в наборе инструкций.
WH>Нечего им там делать.
Ты можешь примерно набросать идею своей VM? Сейчас снова ожил проект http://hlvm.org/ — это как раз проект создания обобщенной виртуальной машины на базе LLVM. Может им полезно будет.

C>>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.

WH>Интерпритацию в морг.
Благодаря ей у нас есть HotSpot в JVM. В теории, можно было бы заменить на многостадийную JIT-компиляцию, но сложность уже намного больше будет.

WH>Она может быть допустима только в случае управляющих комманд для чегото гораздо болие тяжолого.

WH>А если она выполняет основные вычисления то точно в морг.
Реально помогает, тем не менее.
Sapienti sat!
Re[17]: Не пора ли нам перейти на D
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.07 22:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.


Ой как я люблю такие словосочетания... "быстрой интерпретации", "живой труп", ... Обожаю!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 10.04.07 04:00
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Ну и для JVM у нас еще получается бенефит в виде возможности быстрой интерпретации.

VD>Ой как я люблю такие словосочетания... "быстрой интерпретации", "живой труп", ... Обожаю!
VD>
Ну что сделать, если для .NET интерпретация байт-кодов еще медленнее
Sapienti sat!
Re[19]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 10.04.07 14:42
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну что сделать, если для .NET интерпретация байт-кодов еще медленнее

А зачем вобще интерпритировать? Если можно компилировать?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 11.04.07 06:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Ты можешь примерно набросать идею своей VM? Сейчас снова ожил проект http://hlvm.org/ — это как раз проект создания обобщенной виртуальной машины на базе LLVM. Может им полезно будет.

WH>Не будет.
WH>Ибо
WH>

focusing first on dynamic languages like Python and Ruby

Заметь слово first — они не исключают статических языков.

WH>А я считаю Python, Ruby и тп ошибкой природы. С++ я тоже считаю ошибкой природы.

WH>Так что мои идеи совершенно несовместимы ни с LLVM ни с HLVM.
На Питоне очень удобно скрипты писать, так что не надо. А на С++ для девайсов тоже очень все неплохо пишется.

C>>Благодаря ей у нас есть HotSpot в JVM. В теории, можно было бы заменить на многостадийную JIT-компиляцию, но сложность уже намного больше будет.

WH>HotSpot в морг. Ибо не смотря на все потуги он не помогает жабе работать быстрее С++
Так JIT в .NET тоже не помогает

C>>Реально помогает, тем не менее.

WH>Чем?
Беты 1.7 работают в некоторых моих тестах ОЧЕНЬ быстро.
Sapienti sat!
Re[20]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 11.04.07 06:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Ну что сделать, если для .NET интерпретация байт-кодов еще медленнее

WH>А зачем вобще интерпритировать? Если можно компилировать?
Сложность HotSpot VM значительно возрастает. Возможно, но сложно.
Sapienti sat!
Re[21]: Не пора ли нам перейти на D
От: WolfHound  
Дата: 11.04.07 07:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Заметь слово first — они не исключают статических языков.

Угу. И LLVM не исключае safe языков. Вот только из-за этих уступок ОЧЕНЬ СИЛЬНО усложняется и ослабляется оптимизатор, а валидатор кода в большинстве случаев вобще курит.

C>На Питоне очень удобно скрипты писать, так что не надо.

На один экран кода и чтобы управляли чемто намного болие тяжолым. Иначе в морг.
Если кода больше то я лучше немерле возьму. Он по крайней мере мне все проверит, а не вылетит на пол пути из-за мелкой опечатки в редкоиспользуемом месте.

C>А на С++ для девайсов тоже очень все неплохо пишется.

Можно лучше.

C>Так JIT в .NET тоже не помогает

Ибо какойто 3.1415(скорей всего маркетойд) принял решение драть ВМ с жабы.
Если бы думали головой, а не лозунгом "догнать и перегнать сан" то все можно былобы сделать много лучше.

C>Беты 1.7 работают в некоторых моих тестах ОЧЕНЬ быстро.

Быстрее чем Intel C++? На тестах которые не получают преимущества от использования ГЦ?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Не пора ли нам перейти на D
От: Cyberax Марс  
Дата: 11.04.07 10:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Заметь слово first — они не исключают статических языков.

WH>Угу. И LLVM не исключае safe языков. Вот только из-за этих уступок ОЧЕНЬ СИЛЬНО усложняется и ослабляется оптимизатор, а валидатор кода в большинстве случаев вобще курит.
Safe-языки в LLVM делаются не просто, а очень просто. Достаточно запретить использование инструкции каста к указателям и явного удаления памяти.

Кстати, с точки зрения оптимизатора LLVM, safe и unsafe различаются очень немногим — почти что только более богатыми возможностями alias analysis в safe-языках.

Верификатор — это уже отдельный разговор.

C>>На Питоне очень удобно скрипты писать, так что не надо.

WH>На один экран кода и чтобы управляли чемто намного болие тяжолым. Иначе в морг.
Ну да, у меня таких скриптов полно — мелкие задачи замечательно оптимизируются. Еще для build-системы тоже очень неплохо подходит (использую Waf).

C>>А на С++ для девайсов тоже очень все неплохо пишется.

WH>Можно лучше.
Можно. Но пока не сделано.

C>>Так JIT в .NET тоже не помогает

WH>Ибо какойто 3.1415(скорей всего маркетойд) принял решение драть ВМ с жабы.
WH>Если бы думали головой, а не лозунгом "догнать и перегнать сан" то все можно былобы сделать много лучше.
Не получится. Без перекомпиляции налету с возможностью деоптимизации (ключевой пункт) многие возможности оптимизации просто невозможны.

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

C>>Беты 1.7 работают в некоторых моих тестах ОЧЕНЬ быстро.

WH>Быстрее чем Intel C++? На тестах которые не получают преимущества от использования ГЦ?
На чисто числодробительных задачах — не проверял. Но тут, собственно, ни один JIT не поможет — компилировать одну сборку полчаса при загрузке будет недопустимо. А вот HotSpot как может зарулить — просто запускаем движок оптимизации на соседнем ядре (Intel аннонсировал 8-ядерный процессоры, выполняющие по 16 параллельных тредов) и пусть себе там думает.
Sapienti sat!
Re[22]: Не пора ли нам перейти на D
От: Сергей Туленцев Россия http://software.tulentsev.com
Дата: 15.04.07 21:09
Оценка:
Здравствуйте, VladD2, Вы писали:

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


IT>>А если выводить тип приватных методов?


VD>Язык переживет. Тормозов только будет по больше. Для IDE — это будет полный кабждец. Прейдется перекомпилировать на каждый чих все приватные методы. Точнее все, так как их и выделить то нельзя.


То есть как это нельзя?
    FormatType(_tb : TypeBuilder) : void
    {
      def members = _tb.GetDirectMembers().Filter(m => 
                                            match(m)
                                            {
                                            | mb is MethodBuilder => (mb.Modifiers.Attributes & NemerleAttributes.Private) != 0
                                            | _ => false
                                            });
      foreach(member in members)
      {
        Debug.WriteLine($"Private method: $(member.Name)");
      }
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
--
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.