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

EP>В начале топика как раз произошёл такой прокол

Автор: D. Mon
Дата: 23.10.13

— там два return'а, которые возвращают разные типы (ниже по ветке разбор). Пока был массив — там видимо работала специализация, но для общего случае оно не заведётся

Ну это один из вопросов, который я в Ди не просёк. Хотел бы посмотреть, что скажут по этому поводу профи в вопросе...

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

E>Ну, вот, например, надо нам писать драйвера какие-то, или числодробилки. На сколько все эти твои "довольно много" снизят стоимость разработки/поддержки?..

Сложно сказать. Но скажем средства для построения встроенных DSL (чем обычно очень любят заниматься авторы математических библиотек) в D намного сильнее чем в C++. Даже если заговорить о банальной перегрузке операторов... Разделение перегрузки оператора справа и слева уже даёт много вкусного для например матричной алгебры и т.п.

E>А теперь, положим нам надо какое-то формошлёпство с вебом пополам, насколько там Ди окажется ВЫГОДНЕЕ чем шарп?

Ооо, а вот что-то подобное мы как раз сейчас и пытаемся проверить на нашем небольшом проектике. Пока по ощущениям можно будет обойтись хостингом за $10 для той же задачи, что обычно требует хостинга за $500. Но там ещё очень далеко от завершения, так что пока не буду ничего точного говорить. Тем более что это у нас как бы такой стажёрский проектик (правда пока похоже больше обучается руководитель, а не стажёр) и даже не по нашему основному профилю.

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

DM>RTTI там не используется как раз. Типы выводятся и определяются статически.

В смысле? Как статически выбрать тип "первые Н" или "отсюда до обеда", если оно от данных зависит?

DM>take тут берет до 100 элементов и делает это лениво, поэтому если встретится '\n', то дальше итерация не пойдет.

Это уход от вопроса, на самом деле. Вопрос был про то, что делать, если НУЖНО ВЕТВЛЕНИЕ.

Ну, например, если в последовательности ГДЕ_ТО есть конец строки, то вернуть до него, а если нет, то первые 100 и т. д...

Или ты хочешь сказать, что обычно всегда всё можно как-то хитро лениво закодировать так, что никогда не надо ветвиться?

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

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

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

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

_>А в чём проблема? Это же и в C++ без проблем работает, а уж в D то и подавно. )
Какая разница в данном случае Си или Ди? Вопрос в том, как использоваь такую концепцию интервалов, а не то, в каком языке её реализовывать.
В каком-то смысле этот вопрос вообще ортоганален языку. Главное что бы концепция в язык укладывалась

E>>Как такое написать эффективно?

_>

_>auto l=SList!dchar(['а', 'б', 'в', 'г', 'д', 'е', 'ё'])[];
_>l.until('г').take(6).writeln();//выводит "абв"
_>l.until('Г').take(6).writeln();//выводит "абвгде"
_>

Это не эффективно, так как мы, что бы вывести 6 букв просмотрели 7...

тут можно, конечно, схимичить и взять первые 6, а потом поискать, но вдруг оба предиката будут такие, что "бесплатно" их не прокрутишь?

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

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

I>>Я на самом деле на D смотрю с большой надеждой. Если он выстрелит нормально в фейсбуке, это будет очень большое событие

E>Смотря в куда выстрелит... А то из С++ выстрелить в ногу/голову/спину/грудь тоже неплохо можно

Подразумевается, что на D одни дураки пишут ?

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

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

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

Вообще-то и в Си и в Паскале и вообще почти везде есть возможность просто взять да и написать генератор кода, если уж задача такая, что без метопрограммирования никуда...

Только такие задачи -- редкость всё-таки...

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

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

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

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

E>Это не эффективно, так как мы, что бы вывести 6 букв просмотрели 7...

С чего бы это? И until и take — это ленивые функции.

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

DM>>RTTI там не используется как раз. Типы выводятся и определяются статически.
E>В смысле? Как статически выбрать тип "первые Н" или "отсюда до обеда", если оно от данных зависит?
E>Вопрос был про то, что делать, если НУЖНО ВЕТВЛЕНИЕ.

Если ветвление и в разных ветках разные типы получаются, то получается, что на выходе нечто с известным интерфейсом (функциями вроде empty и popFront), но как именно они работают (какая из реализаций выбрана) определяется в рантайме. Ничто не напоминает? Правильно, таблица виртуальных функций. Для этого есть функция inputRangeObject, которая принимает input range некоторого типа (известного статически) и делает из него объект типа InputRangeObject, он будет одинаковый для всех веток.
Но когда такого ветвления нет, то можно обойтись одной статикой, без виртуальных функций.

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

EP>>так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!".

VD>Вот это характерно! Ты программируешь на ХМЛ-е, а не на С++.

Дык всё так и есть, для задачи, где нужен DSL юзают DSL, средсва поддержки которого написаны на плюсах, например, или ещё на чём-то...
И, скорее всего, тут намного важнее фреймворк для создания DSL'ей, а не язык на котором они создаются...
\
А встраивать один язык в другой вообще путь к запутыванию кода, IMHO, то есть маломасштабируемый и тупиковый.

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

E>>IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...
E>>Или таки можно?
_>А в чём проблема? Это же и в C++ без проблем работает, а уж в D то и подавно. )

Библиотечный findSplit возвращает три range, два из которых результат takeExactly, а третий оригинального типа.
Допустим тебе в функцию передали BidirectionalRange, внутри ты сделал этот findSplit, и тебе нужно вернуть либо первый range либо последний. Как будешь делать?
А вот на итераторах это элементарно разруливается

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

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

В отличие от хаскеля и скалы, D как раз пилят практики, можно сказать пролетарии. От этого он получается очень удобным в практическом использовании (и для меня стал language of choice для очень многих задач, сильно потеснив С++ и окамл), но с другой стороны такой подход (от практики) ведет к тому, что у языка нет четкой теоретической базы (в отличие от тех же хаскеля, скалы или окамла), что во многом и служит причиной кучи багов в компиляторе и медленного развития (другая причина — что компилятор написан на С++).

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

DM>Если ветвление и в разных ветках разные типы получаются, то получается, что на выходе нечто с известным интерфейсом (функциями вроде empty и popFront), но как именно они работают (какая из реализаций выбрана) определяется в рантайме. Ничто не напоминает? Правильно, таблица виртуальных функций. Для этого есть функция inputRangeObject, которая принимает input range некоторого типа (известного статически) и делает из него объект типа InputRangeObject, он будет одинаковый для всех веток.

Это называется type erasure — ты только и подтвердил опасение Erop'а:

E>IMHO, тут намного хуже то, что, насколько я понимаю, они не просто выдают новый интервал, но ещё и интервал ДРУГОГО ТИПА, так что комбинировать их без RTTI вообще нельзя. А это уже принципиальный прокол в производительности...

Дело в том, что в C++ любой sub-range представляется парой итераторов — и при использовании алгоритмов не появляются новые типы итераторов на ровном месте.
А тут если вызвать банальный findSplit — то уже всё, уже приплыли.

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

EP>Это называется type erasure — ты только и подтвердил опасение Erop'а:

А VMT относится к RTTI? Тогда да.

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

EP>>Это называется type erasure — ты только и подтвердил опасение Erop'а:
DM>А VMT относится к RTTI? Тогда да.

Я уверен что он имел ввиду любой runtime полиморфизм. Хоть на виртуальных функциях, хоть на tagged union, хоть на обычных func ptr, хоть на switch'ах по typeid (которое самое что ни на есть RTTI).

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

_>Сложно сказать. Но скажем средства для построения встроенных DSL (чем обычно очень любят заниматься авторы математических библиотек) в D намного сильнее чем в C++. Даже если заговорить о банальной перегрузке операторов... Разделение перегрузки оператора справа и слева уже даёт много вкусного для например матричной алгебры и т.п.

IMHO, если мы таки за рассчёты-рассчёты, то ничего лучше фортрана либо матлаба (в зависимости от того, что за рассчёты) не придумали. Это я тебе как вычматик говорю...

И библиотеки там ЛУЧШИЕ, хотя совсем перегрузками операторов не балуются при этом...

Тут IMHO, С++ будет очень сильно оверкилл. И Ди, насколько я понимаю, тоже...

ну и потом, библиотеки -- особенно их интерфейс -- это микроскопическая часть кода, вообще-то.

_>Ооо, а вот что-то подобное мы как раз сейчас и пытаемся проверить на нашем небольшом проектике. Пока по ощущениям можно будет обойтись хостингом за $10 для той же задачи, что обычно требует хостинга за $500. Но там ещё очень далеко от завершения, так что пока не буду ничего точного говорить. Тем более что это у нас как бы такой стажёрский проектик (правда пока похоже больше обучается руководитель, а не стажёр) и даже не по нашему основному профилю.

Ж

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

I>Подразумевается, что на D одни дураки пишут ?
Ну про С++ же подразумевается?..

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

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

_>С чего бы это? И until и take — это ленивые функции.

А если ленивость вредна?
Скажем я по этому диапазону буду потом 100500 раз елозить и не хотел бы все 100500 раз вычислять предикаты?..

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

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