По-моему, этот минус (если он так уж беспокоит) преодолим посредством «выворачивания» дерева в месте последней модификации на манер finger tree. Я подумывал скомбинировать органицацию набора блоков приличной длины (а не по несколько символов, как если бы finger tree использовалось в лоб для хранения массива символов) с выворачиванием, а ещё рассматривал забавную идею immutable блока с гэп-буфером: давайте контрольную запись (указатель на блок плюс индексы краёв гэпа) хранить отдельно от самого блока. Тогда при добавлении символов на краях гэпа блок клонировать не надо — создаются новые контрольные записи с обновленными индексами краёв гэпа (гэп сужается) — старые контрольные записи продолжают оставаться в том же состоянии (immutable), указывая на тот же блок!
Товарищи на видео (и конкретно Хейслберг) обсуждают эту область как вторую по популярности просьбу (первая — generics — выполнена). В версии 1 этой фичи точно не будет — причина в недостаточной определённости текущего драфта ECMAScript 6 в смежной области, насколько я понял: без продвижения этого драфта сгенерированный из конструкций async / await JS код будет сильно отличаться от оригинального TS, а это входит в противоречия с намереньями авторов TS.
В идеале особой разницы быть не должно (более того, в некоторых подразделениях её устраняют формально), но на практике «менталитет», так сказать, отличается (ну и критерии отбора кандидатов при найме другие). Пост этого сотрудника (Ahmet Alp Balkan) мне напомнил личных знакомых-программистов, которые, будучи несчастливо нанятые в тестовые подразделения, воспряли, переведясь в разработчики. Впрочем, один мой знакомый, очень продуктивный программист-энтузиаст, прекрасно чувствует себя и в тестовом подразделении (возможно, повезло с командой / начальником… Исключение, подтверждающее правило?)
Насколько я понимаю, в подразделении, в котором трудится автор исходного поста (Ahmet Alp Balkan) пишут по большой части на C# (тем более, он в тесте, не в девелопменте). По части C++11 — ситуация неоднозначная, на мой взгляд. Давайте взглянем на что-то довольно новое — разработку на С++ под плиточный интерфейс Windows 8 (ранее называвшийся «Метро»).С одной стороны, языковые нововведения C++11 задействованы, и их использование приветствуется (характерный, бросающийся в глаза пример — лямбда-выражения для программирования асинхронных операций). С другой — в этом контексте предлагается программировать на так называемом C++/CX, как наиболее удобном варианте программирования «на C++» в этом контексте — и это действительно так!.. Но этот нестандартное расширение C++. Можно следовать такой тактике: писать код на стандартном C++11, изолируя системно-зависимую логику в хорошо ограниченной группе C++/CX исходников.
Забавно — парня, написавшего исходный пост наняли в тестовую организацию Azure (это явно высказано в диалоге с Хансельманом в комментариях), а он со своей колокольни эдак обобщительно и за девелоперов пишет — ну, ветер ему в паруса.
Да, согласен, задача несколько другая, но смежная — я всё-таки подумываю о пересказе того, что просматривал на досуге; темы переплетаются (и, как показывает беглый поиск, здесь на Хабре заинтересовавшие меня вопросы пока не обсуждались). Один из интересных пунктов — формальное определение оного свойства «фрактальности», при соблюдении которого для большой карты увеличение размера памяти для хранения МКР-информации всей карты — фиксированный множитель. Не буду вдаваться в детали, потому что могу легко что-нибудь напутать из памяти — надо сесть, вдумчиво пересмотреть статьи / презентации. Если таки-доведу идею написать запись по теме до успешного воплощения, помещу здесь ссылку.
А вы не рассматривали алгоритмы с многоуровневыми вспомогательными графами на подобие МКР? Если вам это любопытно, могу найти ссылки на статьи и, возможно, слайды (на английском, правда). Интересная деталь, которая мне вспоминается про эту область (я по работе с ней дела не имею, ознакомился поверхностно на досуге) — определённое свойство «фрактальности» графа дорожной сети там определяется формально, и для типичных графов континентального масштаба оно действительно выполняется (в одной из статей есть даже рассуждения на тему, что так получается из-за исторически инкрементального развития сети дорог). Оно, правда, не выполняется, например, на регулярных сетках типа расчерченного строго перпендикулярными улицами района города.
Практический аспект — континентальные дорожные сети очень велики и алгоритмы линейной сложности по размеру графа не удовлетворяют практическим требованиям, нужны алгоритмы суб-линейные по сложности (которые как раз существуют для пред-обработанных графов с пред-вычисленной дополнительной информацией, аналогичной многоуровневым МКР). О, кстати, бегло пробежавшись по ссылкам, увидел знакомую фамилию по последней ссылке — Голдберг, я был как раз на его презентации однажды (на которой он излагал теорию и практику этого подхода).
Тут имеется некоторый исторический аспект. Из эвклидовой геометрии тоже выросло дерево, не настолько пышное, но более вписавшееся в современный контекст (да, есть неэвклидова геометрия, но она не отменяет логические построения эвклидовой геометрии — просто имеет другую аксиоматику).
Аристотелева логика же, трудами раннехристианских философов и, позднее, средневековых схоластов была возведена в ранг догмы, что выхолостило её рациональное зерно (при полном отказе от критики) и затормозило развитие формальной логики как научной дисциплины на столетия, если не на тысячелетие.
Бертран Рассел (мне недавно попался соответствующий фрагмент в его «Истории западной философии») указывает на определённые слабости Аристотелевой логики, вот ссылка на цитату (по-английски, можно при желании найти русский перевод): www.physicsforums.com/showthread.php?t=537913.
Применительно к фразе «все кентавры говорящие» его рассуждения звучат примерно так. Рассматривая похожие и неразличаемые в Аристотелевой логике фразы «Фол — говорящий» (Фол — субъект, конкретный кентавр) и «все кентавры говорящие» Рассел указывает на то, что подразумеваемое прочтение второй фразы приводит к выводу, чту у неё субъекта (в понятном смысле, как в первой фразе) нет. Подразумеваемое прочтение второй фразы у него такое: она эквивалентна конъюнкции фраз «существуют кентавры» и «если что-то есть кентавр, это что-то — говорящее» — ни в одной из них о «всех кентаврах» речи не идёт.
(думаю заглянуть-таки в русский перевод за цитатами и запостить здесь более дельное резюме его критики, показавшейся мне довольно обоснованной)
Классно, удачи с помидорами — я на всякий случай снова нашёл и сохранил чужое аналитическое решение (отличное от моего, «физического», тем, что для доказательства правильности аналитического решения ничего особо не надо, в то время как в «физическом» у меня дыры из-за пробелов в образовании — я программист, а не математик, хотя и учился на мат-мехе). Я в этом чужом решении так досконально и не разобрался (оно записано очень сжато, а интерес к задаче я уже потерял).
Да, вы правы; однако, усложнять формулировку в надежде, что она останется достаточно изящной, мне лень. Кстати у меня есть про запас совсем другая задача, в которой в пределе получается такая вероятность (1 — 1/e), без ошибок — «задача про гниющие помидоры» (автор задачи — Ольга Леонтьева). Надо бы напрячься и опубликовать здесь отдельной записью. Мне удалось решить её только «физическим» способом, хотя она комбинаторная (через переход к непрерывной функции, предполагая, что её непрерывность и дифференцируемость доказывается — и затем решая дифур), но у неё есть и честное комбинаторное решение (которое мне найти было слабо, но добрые люди помогли… надеюсь, у меня его запись где-то сохранилась).
Спасибо, интересно. Тут же возникает вопрос: а как можно было бы сформулировать другую (но очень похожую) задачу, в которой решение и ответ Кэролла оказались бы корректными?
Предлагаю такую (в правильности не уверен, сейчас нет времени хорошо обдумать и проверить):
«Среди некоторого нечётного количества человек, случайно построенных в шеренгу, ровно один — рыжий. Какова предельная вероятность того, что он окажется ровно в середине шеренги, при неограниченном увеличении длины шеренги?»
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
Спасибо, прочитал с большим удовольствием. Ваш текст напомнил мне о давнем, до сих пор не реализованном намереньи прочитать The Programmer's Stone. Правда, мне показалось, что последняя часть вашего рассмотрения («устремлённый») не вполне продолжает противопоставление «грязный-чистый»: например, неустремлённый программист (тот, который «не достигает вершины своего изначального потенциала» и работает строго по спецификациям в знакомой области) может производить очень чистый код. И наоборот, устремлённый супер-производительный «хакер» (в хорошем смысле :) ) может продвинуть сложный проект так, как никто другой, но при этом произведя не особо чистый код (например, натащив какого-нибудь «прогрессивного новья», интересного ему в данный момент, но не полезного проекту в долгосрочной перспективе); т.е. противопоставление неустремлённый / устремлённый не вполне коррелирует с противпоставлением производитель грязного / производитель чистого кода. Это неможко смазывает посыл сообщения, по-моему.
Спасибо, интересно, но вот тут: " Синтаксис TypeScript — подмножество синтаксиса EcmaScript 5 (ES5) " я бы рекомендовал подправить (superset — надмножество или, более по-русски, надстройка или расширение… по ряду пунктов совместимое с проектом стандарта EcmaScript 6, но выходящее за его пределы).
Практический аспект — континентальные дорожные сети очень велики и алгоритмы линейной сложности по размеру графа не удовлетворяют практическим требованиям, нужны алгоритмы суб-линейные по сложности (которые как раз существуют для пред-обработанных графов с пред-вычисленной дополнительной информацией, аналогичной многоуровневым МКР). О, кстати, бегло пробежавшись по ссылкам, увидел знакомую фамилию по последней ссылке — Голдберг, я был как раз на его презентации однажды (на которой он излагал теорию и практику этого подхода).
Аристотелева логика же, трудами раннехристианских философов и, позднее, средневековых схоластов была возведена в ранг догмы, что выхолостило её рациональное зерно (при полном отказе от критики) и затормозило развитие формальной логики как научной дисциплины на столетия, если не на тысячелетие.
Применительно к фразе «все кентавры говорящие» его рассуждения звучат примерно так. Рассматривая похожие и неразличаемые в Аристотелевой логике фразы «Фол — говорящий» (Фол — субъект, конкретный кентавр) и «все кентавры говорящие» Рассел указывает на то, что подразумеваемое прочтение второй фразы приводит к выводу, чту у неё субъекта (в понятном смысле, как в первой фразе) нет. Подразумеваемое прочтение второй фразы у него такое: она эквивалентна конъюнкции фраз «существуют кентавры» и «если что-то есть кентавр, это что-то — говорящее» — ни в одной из них о «всех кентаврах» речи не идёт.
(думаю заглянуть-таки в русский перевод за цитатами и запостить здесь более дельное резюме его критики, показавшейся мне довольно обоснованной)
Предлагаю такую (в правильности не уверен, сейчас нет времени хорошо обдумать и проверить):
«Среди некоторого нечётного количества человек, случайно построенных в шеренгу, ровно один — рыжий. Какова предельная вероятность того, что он окажется ровно в середине шеренги, при неограниченном увеличении длины шеренги?»
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).