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

Из моих слов можно сделать такой вывод?   Хотя твоим домыслам я уже перестаю удивляться.

То есть никогда.

Если тебя просил об этом такой человек, то обсуждай это с ним. Я не просил, а констатировал факт твоей неспособности признать поражение, но, учитывая твою способность выводить из слов собеседника вообще всё что угодно, видимо этому тоже удивляться не следует. А насчёт трактовок - вообще бред: я тебе с самого начала сказал, что на смерть продукта влияет не смерть вендора, а востребованность на рынке, сейчас повторяю ровно то же самое, но ты в этом усмотрел другую трактовку. Подозреваю, что решая в детстве задачки типа "найди 10 различий", тебе всегда удавалось найти гораздо больше.  

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

А если подумать, вот накроется MS и вместе с ней VS, что тогда ждет плюсы, которые на винде останутся без компилятора с IDE? C++ Builder за альтернативу я не считаю, т. к. он все равно приделан к паскалевской VCL. Qt, я так понимаю, тоже не тот масштаб.



А может оно бы и к лучшему было бы, если бы Delphi стала open-source, сразу бы исчез вопрос цены, и не было бы такой тягомотины с правкой чего-то там.

Такой вывод сам напрашивается, в отличии от твоей претянутой за уши трактовки.Смерть вендора не аргумент в случае с C++, Haskell, PHP, etc -> это не аргумент и в случае с дельфи.Что плохого в уточнении? Ненулевая вероятность смерти продукта, как и ненулевая вероятность его выживания при смерти вендора существует всегда. Другой вопрос - насколько существенна вероятность смерти дельфи при смерти абры. Я считаю что вероятность достаточная, что бы её упомянуть. Особенной статистикой для подобных проектов я не обладаю, просто считаю что дельфа особо никому не нужна. Ты считаешь(видимо) иначе.
От твоего нытья ничего не изменится, можешь особенно не стараться.   

Это сообщение отредактировал(а) Bother - 11.5.2013, 13:38

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

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

В уточнении ничего плохого, если оно не меняет смысл практически до противоположного.

С этим никто и не спорил, вопрос только в том, какие выводы следуют из этого беззубого замечания? Вот если смерть продукта неминуема в этом случае, то это - да, аргумент. 

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

Как сказал выше, данными по этому вопросу не обладаю.

И что по-твоему я пытаюсь изменить своим "нытьём"? Меня всё устраивает: ты спор проиграл и пытаешься теперь убедить меня в том, что я неправильно интерпретирую свои же слова, а твое изменение формулировок - не более чем уточнение. Чего мне ещё желать-то?  

В изначальной фразе ты говоришь что если кому-то эта участь не угрожает, то и дельфи не угрожает. На лицо отсутсвие логики. Позже ты попытался это переинтерпретировать, якобы дельфи это не обязательно угрожает.Так я от этого и не отказывался. Захочет абра - закроет дельфи. Алсо про "молиться на абру" - не только возможность её смерти имелась ввиду.Ну, это только твоих утверждений касается(см.выше). Мои не противоречат друг другу.Вон BeOS умерла. Насколько она была востребована - не мне судить, но гайку зачем-то пилят(хорошая ось). А какие примеры у тебя? Java, которая не могла умереть, и Sun который фактически стал подразделением Oracle? Netscape Navigator, который AOL выкупил с убытком для себя, ничего не поимев взамен(местный выриант чуда)? Кто по твоему купит дельфи?Я не знаю, что ты хочешь изменить. Возможно просто занимаешься самовнушением. Хочешь - ной дальше, для меня это не проблема.   

Это сообщение отредактировал(а) Bother - 11.5.2013, 18:38

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

О том, что если абра захочет я не спорил, только сказал, что это точно из области фантастики. О тупиковом развитии тоже помню, но это я вроде тоже не комментировал. Я сказал только о том, что смерть технологии в результате смерти вендора - не является общим правилом, а стало быть из неё ничего вывести нельзя. Больше не утверждал ровным счётом ничего. 

Противоречие есть только между моими словами и твоей интерпретацией оных. Хотя я всё ещё жду ссылку.

Ога, ты только так уточняешь, что смысл меняется.

Что это? 

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

Примеры чего? Ты сам уже признал, что смерть вендора совсем не обязательно ведёт к смерти технологии. Или это снова доказывать надо?  

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

И что же я себе внушаю?    

Не прекратишь хамить, проблемой это может стать именно для тебя.  

Я вообще ничего про неминуемую смерть не писал, только про возможную.Это не общее "правило", только для тех кто зависит от вендора.Ссылку на что? Я привёл твою цитату, контекст с того момента не менялся.Совсем нет. Выше написал, почему.ОСь такая, из 90х. Сложно привести примеры из тех областей, с которыми не сталкивался. Я тыкал haiku, о BeOS знаю оттуда.Ну раз создали опенсорсный аналог - значит сколько-нибудь востребовано.Примеры выживания продукта после смерти вендора. Просто для статистики.Боевых роботов на меня натравите, ваше злейшество?   

Это сообщение отредактировал(а) Bother - 11.5.2013, 20:25

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

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

Я же объяснил. Ты привел интерпретацию моих слов, в которой хоть и узнавалась моя же фраза, процитированная тобой ранее, тем не менее смысл был искажён. Поэтому я прокомментировал фразу, которую я узнал и указал в чем неточность интерпретации. Но на случай, если ты имел в виду другую фразу, я и испросил ссылку. Судя по всему это была именно та самая фраза.

Ну дельфу-то все знают.

Жив продукт. Не? 

Ява с навигатором - продукты очень известные, их вполне достаточно. 

Ты меня понял  

Мы тут с Белтаром замутили сравнение скорости работы класса (T)StringBuilder в .NET и Delphi. Сей синтетический тест, разумеется, не имеет практического значения, однако результаты забавные: несмотря на то, что на стороне дельфи "оптимизированный нативный код" и "самый быстрый менеджер памяти", а на стороне шарпа -- "тормозной JIT компилятор" и "тормозная сборка мусора", дельфи умудрилась просесть на конкатенации строк В РАЗЫ.

Сравнение производительности конкатенации строк



Пояснения к таблицам:

Строки конкатенируются при помощи StringBuilder.Append. Используется четыре конфигурации длин сливаемых строк (вторая строка таблицы): [1], [1, 2], [1, 10, 2, 5]. Эти длины умножаются на коэффициент от 1 до 100 (первый столбец таблицы). Строки сливаются в цикле, и повторяется это от 1 до 1000000 раз (первая строка таблицы). Чтобы выровнять результаты, в зависимости от количества повторов операция производится от 100000000 до 100 раз (100000000, делённые на первую строку). Некоторые ячейки оставлены пустыми, так как потребляют слишком много памяти (гигабайты) или выполняются слишком долго.

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

В значащих ячейках -- количество затраченного времени (либо в формате миллисекунд, либо в формате времени).

Примечания:

1. Реализация конкатенации строк была изменена в .NET 4.0. Раньше использовался один буфер, растущий по степеням двойки. Сейчас используется связный список буферов. Эта оптимизация нацелена на самый частый случай: слияние небольших строк. Также ускоряется вставка символов. С большими строками новая реализация проигрывает старой, однако на оптимальных случаях ускорение до 8 раз.

2. В дельфи конкатенация строк реализована как в старой версии .NET.

3. Реализация на дельфи просела не только по времени, но и по памяти. Это даже для меня было сюрпризом. Дотнет отжирал до 700 метров, дельфи отжирала до 1150 метров. Справделивости ради, на старте дельфи съела 5 МБ, .NET 4.5 -- 20 МБ, .NET 3.5 -- 40 МБ.

4. Очевидно, тут в большой мере тестируется не скорость выполнения кода, а производительность менеджера памяти. Стоит однако заметить, что тест для любого менеджера памяти очень приятен: блоки создаются и тут же уничтожаются; блоки выделяются одних и тех же размеров.

Выводы:

1. Дельфи сосёт.

P.S. Реализацию сейчас залью.

Это сообщение отредактировал(а) Athari - 12.5.2013, 01:02

Сорцы на гитхабе: https://github.com/Athari/Tmp-StringBuilderPerf

Примечания:

1. Хоть на дворе 21-й век, сорцы дельфи до сих пор не юникодовые. Поэтому на сайте код Белтара выглядит как г... ещё хуже, чем он есть на самом деле. Можете скачать и открыть в блокноте.
2. Результаты в папке Results. Там и текстовый вывод приложений с компов меня и Белтара, и исходник табличек из поста выше.
3. Дельфи не умеет сохранять текст в юникоде (?), поэтому результаты тоже выглядят как г... и всё в дельфи.

Внимание! Желающие могут принять участие в опускании дельфи! Для этого нужно:

1. Написать аналогичное приложение на вашем любимом языке.
2. Ваш результат должен быть лучше, чем у дельфи (что не должно составить труда  ).
3. Чтобы оставаться в одной весовой категории: кэшировать аналог string-builder'а запрещается; использовать распараллеливание на разные потоки запрещается; строки должны быть в UTF-16/UCS-2; код должен выполняться под виндой.

P.S. Ну вот, осквернил гитхаб дельфой.  

Как раз менеджер памяти-то тут и не тестируется нифига, а вот создание объектов очень даже.



Тогда отключи GC раз он в отдельном потоке. Ну а работы для GC именно по поиску связей тут не наблюдается.

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

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

@Beltar


А менеджер памяти выделением и удалением объектов не занимается совсем?  


Я GC отключаю, а ты убираешь вызов Free, ОК?  


Мне лень переписывать дотнетовый стринг-билдер на байты, но, уверяю, на однобайтовых строках дельфи точно так же сольётся. Собственно, в тесте юникодовость/неюникодовость на относительные результаты особо не влияет: строки конкатенируются всех размеров.


Разумеется. Winternals Process Explorer by Mark Russinovich. Private Bytes, Max Private Bytes. Да, и своп отключен, так что Working Set не будет снижаться из-за вываливания из RAM даже в стандартном диспетчере задач.


Это ты так аргументировал расползание дельфи в памяти? Сформулируй нормально мысль, а то мысль теряется: что там размер строки определяет? что там с отдачей системе?


LLVM не поможет. Тут узкое место -- "Fast"MM. В LLVM, я так подозреваю, используется "системный" менеджер памяти, который ещё медленнее FastMM (только в однопоточных приложениях и только на 10% в случае винды, что как раз наш случай).

Речь шла о минусах привязки к вендору относительно её отсутствия. И "правило" я потому и взял в кавычки, т.к это скорее зависимость чем правило.
Изначальная фраза:Интерпретация:Жив другой продукт. Это как лазарус для дельфи.А если мой язык настолько ленивый, что вообще ничего делать не будет?(а это правда, хаскель не пошивелится)

там в файл dpr какой-то бредовый, совсем не dpr
и зачем res выложили?
выложите проект куда-нибудь на файлопомойку одним архивом

Там есть кнопочка Zip.

Добавлено через 8 минут и 1 секунду
Блин, Beltar, тебя не учили пробелами выделять операторы? Какое-то сплошное месиво символов.