Facebook и язык D - первый шаг наверх. - Философия программирования

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

EP>>Где я ограничивал разговор алгоритмами для массивов?
FR>alex_public выразил мысль что в D можно прекрасно обойтись без интервалов, заменив их массивами
FR>и срезами, ты сказал что нельзя так как будет невозможно пользоваться std.algorithm я показал
FR>что это не так, можно вполне свободно использовать и не использовать при этом интервалы.

alex_public сказал, что для работы с контейнерами STL крайне рекомендуется знать итераторы — а в D можно обойтись без интервалов, на что я ответил:

EP>Вообще-то при работе из STL используются не только контейнеры, но и алгоритмы, причём алгоритмы намного разнообразней.
EP>И в том же std.algorithm в D — там всё на range'ах, так что от них никуда не уйти.

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

_>Т.е. в этом смысле range из D и итераторы из C++ имеют очень разную значимость. А основной тон для работы с массивами в D задают скорее срезы. Например вот классический пример двоичного поиска из учебника D:

Справидливости ради, мы писали на С++ во времена когда stl еще не стал популярной (на грани этого срока) и прекрасно жили без stl. У нас бил свои (не так хорошо спроектирвоанные) обертки. Еще были разные MFC и другие библиотеки где были обертки. Так что жизнь за пределами stl есть.

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

EP>>И внезапно, полный код выглядит на порядок чище чем в D и Nemerle

FR>На самом деле красиво

Не хватает встроенной в стандарт compile-time reflection — тогда от макроса можно было бы уйти.

FR>Но к сожалению Владовскую задачу не решает, член а класс не добавляет, а без этого на D легко
FR>повторить также красиво.

В С++ не принято добавлять члены в класс на каждый чих, наоборот — non-member предпочтительнее.

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

VD>static if-ы — баловство. Мета-код не должен отличаться от обычного.

Так это и не отличие а точка перехода из обычного в статический

Конечно перегрузкой шаблонов местами и красивей и декларативней выходит
(особенно с будущими концептами), но писать со static if гораздо проще.

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

EP>alex_public сказал, что для работы с контейнерами STL крайне рекомендуется знать итераторы — а в D можно обойтись без интервалов, на что я ответил:
EP>

EP>>Вообще-то при работе из STL используются не только контейнеры, но и алгоритмы, причём алгоритмы намного разнообразней.
EP>>И в том же std.algorithm в D — там всё на range'ах, так что от них никуда не уйти.

Так я и показал что можно использовать std.algorithm и даже не подозревать что там есть какие-то range.

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

EP>Не хватает встроенной в стандарт compile-time reflection — тогда от макроса можно было бы уйти.

Угу, притом как Влад уже говорил очень давно не хватает

EP>В С++ не принято добавлять члены в класс на каждый чих, наоборот — non-member предпочтительнее.

Конечно, но задача не решена.

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

VD>>или вы продемонстрируете аналог генерации функции GetHashCode и мы сравним код.

EP>Вот полный код:
EP>

EP>BOOST_FUSION_DEFINE_STRUCT
EP>(
EP>    (), Widget,
EP>    (int, field1)
EP>    (std::string, field2)
EP>)
EP>...
EP>

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

Я подобной хренью с MAP-ами на препроцессоре 10 лет назад маялся. Больше не хочу.

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

В твоем решении даже нет:
1) проверки для int;
2) формирования метода.

EP>И внезапно, полный код выглядит на порядок чище чем в D и Nemerle

Это потому что ты знаешь ровно один язык. Очень советую изучить тот же D и Nemerle, тогда ты подобные заблуждения высказывать не будешь. Код по ссылке решает исходную задачу, а не подогнанную и упрощенную. И он таки проще, чем твой. Только надо иметь базовые знания для его понимания.

EP>>>Нет. D-style range'и не добавляют ни параллельности, ни иммутабельности.
VD>>Они банально удобно для функционального программирования,

EP>Чем они удобней?

Да всем. Ты попробуй реальный код пописать, и сам поймешь.

Ренжи — это аналоги ленивых списков из ФП или IEnumerable из дотнета. Ленивые списки в купе с правильной библиотекой вроде linq-а повышают уровень кода в разы. При этом код компилируется довольно быстро и есть полноценный интелисенс.

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

J>Для новых проектов на новых языках нужны новые программисты.

То есть ты не осилишь D?

J>А такое счастье никому не нужно. Чтоб вложиться в это, выгоды от нового языка должны быть очень большими.

А они есть. Скорость копиляции, лучший интелисенс, качественное метапрограммирование, более высокоуровневый код. Это довольно много. Хотя у D тут есть не мало конкурентов. Но D, в отличии от них, старается предоставлять близкие к С++ показатели в области быстродействия получаемого кода.

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

EP>>_1 это библиотечная полиморфная лямбда,
VD>Давай поглядим на ее реализацию. Приведи, плиз.

уже было выше

VD>А 29 лет в нем вообще не было бямбд. Хотя лямбды старше С++ еще на 30 лет.

Ты считаешь что в язык нужно тащить каждую фичу?

EP>>Чисто как язык — возможно. Но помимо языка нужна платформа — библиотеки, компиляторы, с которыми, afaik, пока не густо.
VD>Библиотеки дело наживное.

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

VD>Если бы люди вроде тебя вместо того чтобы искать фатальные достатки просто попробовали что-нить написать на Ди, то и библиотеки появились бы.

А, ну то есть программисты во всём виноваты — не пишут библиотеки для языка который непонятно взлетит или нет, непонятно с каким runtime overhead'ом (см. выше интервью с автором). Да как они посмели!

VD>Что касается ренджей, то они, скорее всего, и так достаточно быстрые и никому не нужно искать им замену.

Помимо скорости, они ещё и менее удобные, и менее мощные.

VD>Заметь в Nemerle if самый обыкновенный. static if не нужен, а кодом можно манипулировать как данными.

В D можно манипулировать кодом как строкой — см. mixin.

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

M>Никакого срача — это лишь ваше личное восприятие. То, что Ди как язык на голову превосходит С++ — очевидно даже школоло, это я и подчеркнул. Если вам лично обидно за потраченное на С++ время — ССЗБ.
D не нужен. Потому что его нишу плотно занимают C#/Java с тоннами библиотек на любой вкус. И я не вижу у него никакого преимущества, особенно перед C# в технологическом смысле.
Так что D не нужен. И на смену С++ он придет явно не в этом десятилетии.

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

FR>Так я и показал что можно использовать std.algorithm и даже не подозревать что там есть какие-то range.

1. Массивы это не единственные используемые структуры данных. Если бы всё ограничивалось обычными массивами то не зачем было бы возится с STL, D Rane, etc.
2. Помимо непосредственно использования готовых алгоритмов, часто пишут свои.

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

EP>А где тут кто-то говорил про невероятную крутизну C++?

А разве не ты бросился отстаивать его превосходство над тем же D?

EP>Я вот не пойму — откуда у программистов не пишущих на C++ к нему такая злость/зависть/etc?

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

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

У новых языков (D, Scala, F#, Nemerle, Kotlin, Haskel, ...) есть только одна проблема — размеры комьюнити. Куча народа, вроде вас, ходит и что-то там себе доказывает вместо того чтобы взять и начать помогать развивать перспективные языки.

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

Ну, глупо в 21-м веке использовать языки в которых:
1. Не поддерживается модульность, а вместо нее есть препроцессор с инклюдами.
2. 30 лет не могут создать полноценный интелисенс.
3. Скорость компиляции больших проектов чудовищно низкая.
4. Система метапрограммирования основана на побочных эффектах от других средств, а не разработана специально.
5. Нет бинарного ABI.
6. Нет даже соглашений по формированию имен функций в библиотеках.
7. Требуются предварительные декларации.
8. Нет даже опциональной системы автоматического управления памятью.

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

FR>Так это и не отличие а точка перехода из обычного в статический

FR>Конечно перегрузкой шаблонов местами и красивей и декларативней выходит
FR>(особенно с будущими концептами), но писать со static if гораздо проще.

А зачем вообще смешивать мета-код с обычным? Чтобы крыша ехала надежнее?

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

DM>В D как раз вполне себе можно использовать тот же язык как в обычном коде, так и в МП (в компайл-тайме).

Если бы это было так, то static if был бы не нужен.

DM>

DM>    auto runTimeValue = getNums(argv[1].to!int); //вызываем ее в рантайме
DM>    enum compileTimeValue = getNums(100); //вызываем ее же в компайл-тайме
DM>}
DM>

это частный случай.

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

Смешивание метакода и обычного кода — это недостаток. В "более примитивных" подходах МП используется чуть менее чем везде, в отличии от ...

DM>И чтобы можно было при такой записи вперемежку выбирать между рантаймом и компайлтаймом, есть ...

костыли.

Про невозможность менять синтаксис я уже молчу.

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

VD>>Так уже лучше
J>ничего не изменилось, вообще-то

Или ты про переименование?

Ты просто невнимательно читаешь. Вот предыдущий пример:

J>>boost::copy( irange(0,10) | transformed(_1*_1) | filtered (_1%2)
J>>           , std::ostream_iterator<int>(std::cout, "\n") )

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

EP>>Не хватает встроенной в стандарт compile-time reflection — тогда от макроса можно было бы уйти.
FR>Угу, притом как Влад уже говорил очень давно не хватает

Если кто-то постоянно тем и занимается что итетрирует структуры данных, и ему не хватает текущих возможностей — то пусть отсылает proposal в reflection study group #7, его обязательно рассмотрят.

EP>>В С++ не принято добавлять члены в класс на каждый чих, наоборот — non-member предпочтительнее.
FR>Конечно, но задача не решена.

В разных языках разные подходы. Non-member функция hash_value — это стандартный протокол в C++. И я не вижу никакого смысла использовать функцию член, когда допустим хэш-таблица ожидает non-member, только ради какой-то синтетической задачи.

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

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

А давай сравним где больше коричневых красок:

struct Hasher
{
    template<typename T>
    size_t operator()(size_t hash, T x)
    {
        boost::hash_combine(hash, x);
        return hash;
    }
};

template<typename Struct>
size_t hash_it(const Struct &x)
{
    return boost::fusion::fold(x, size_t(0), Hasher{});
}

versus

[MacroUsage(MacroPhase.WithTypedMembers, MacroTargets.Class)]
macro ImplementGetHeshCode(typeBuilder : TypeBuilder)
{
  def fields = typeBuilder.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
  def make(field)
  {
    if (field.GetMemType().Equals(<[ ttype: int ]>))
      <[ result ^= this.$(field.Name : usesite) ]>
    else
      <[ result ^= this.$(field.Name : usesite).GetHashCode(); ]>
  }
      
  typeBuilder.Define(<[ decl: 
    public override GetHashCode() : int
    {
      mutable result = 0;
      ..$(fields.Map(make));
      result
    }
  ]>);
}

versus

mixin template ImplementGetSheeshCode() { 
    size_t GetSheeshCode()
    {
        alias T = typeof(this);
        size_t h = 123;        
        foreach(m; __traits(allMembers, T))
            static if (m!="Monitor") {             
                static if (isIntegral!(typeof(__traits(getMember, T, m))))
                    h ^= __traits(getMember, T, m);
                else static if (__traits(hasMember, typeof(__traits(getMember, T, m)), "toHash"))
                    h ^= __traits(getMember, T, m).toHash;
            }            
        return h;
    }
}

Разве не очевидно какой код второй по счёту пахнет резче остальных?

VD>В твоем решении даже нет:
VD>1) проверки для int;

Вообще-то boost::hash_combine вызывает нужную hash_value

VD>2) формирования метода.

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

EP>>И внезапно, полный код выглядит на порядок чище чем в D и Nemerle

VD>Это потому что ты знаешь ровно один язык.

Твоя телепатия не работает.

VD>Очень советую изучить тот же D и Nemerle, тогда ты подобные заблуждения высказывать не будешь.

D — возможно, Nemerle — нет уж, спасибо

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

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

EP>>>>Нет. D-style range'и не добавляют ни параллельности, ни иммутабельности.
VD>>>Они банально удобно для функционального программирования,
EP>>Чем они удобней?
VD>Да всем. Ты попробуй реальный код пописать, и сам поймешь.

Практически все преимущества range-only решения, доступны для решения итераторы+обвёртки.

VD>Ренжи — это аналоги ленивых списков из ФА или IEnumerable из дотнета.

Это ты сильно льстишь IEnumerable — D-Range намного мощнее

VD>Ленивые списки в купе с правильной библиотекой вроде linq-а повышают уровень кода в разы.

Эта ленивость доступна и для STL итераторов, причём без бешеной abstraction penalty.

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

EP>>>>В С++ пока нет compile-time reflection,
VD>>>Ага. Это "пока" наблюдается самую малость — на протяжении 30 лет.
EP>>В смысле? Study group для reflection появилась недавно.
VD>Кого это трогает? Комитет по С++ существует не менее 20 лет. За это время гора родила мышь.

Это говорит лишь о том, что было не нужно/были вещи по-важнее

EP>>Или ты думаешь что создатели уже 30 лет думают как бы впихнуть reflection, да всё никак не получается?

VD>Я не думаю. Я знаю об этом.

То есть ты утверждаешь, что Bjarne тридцать лет назад пытался впихнуть reflection?

VD>Мы 10 лет назад обсуждали эту тему. А воз и ныне там.

Где? На форуме, или в комитете?

EP>>Или тебе больше не о чём поспорить?

VD>Я и не спорю.

А вот это к чему было:

VD>Давай или признаем, что в области метапрограммирования С++ существенно уступает D, или вы продемонстрируете аналог генерации функции GetHashCode и мы сравним код.

?
Ты не читаешь ответы на свои сообщения? Я тебе явно сказал, что у D метапрограммирование лучше.
Или если закрыть эту тему — то холивара не получится?
Кто-то считает что в языке который он не использует есть хорошие фичи — внезапно, да?

VD>Просто тема итераторов смешна.

Что смешного?

VD>А больше вы ничего предявить не хотите.

А зачем?
Мне интересна тема Range-only vs Interator+Range, по этому поводу сформировалось некоторое мнение — интересно услышать разные аргументы, точки зрения. В чём проблема? Или тут можно обсуждать только синтаксис? Или так холивара не получится?

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

Кто и где выдвигал такой тезис? И что значит лучше? Лучше для чего?

От:	VladD2	www.nemerle.org
Дата:	24.10.13 18:55
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	24.10.13 18:58
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.10.13 18:58
Оценка:	+1

	От:	Evgeny.Panasyuk
	Дата:	24.10.13 19:01
	Оценка:	+1

	От:	FR
	Дата:	24.10.13 19:01
	Оценка: