Что-то тут сравнивается теплое с мягким — система верстки и текстовый редактор. И конечно тот факт, что emacs не подсвечивает опечатки — это проблема emacs, а не Latex. odt в emacs вообще невозможно редактировать — и что?
"Undefined behavior" можете добавить в теги. Вообще странно, что его существование и разная обработка в зависимости от компилятора вас удивляет. http://en.cppreference.com/w/cpp/language/ub
Для меня эта статья выглядела "как из git сделать mercurial". Например скрипт для просмотра текущей ветки выглядит… диковато.
У гита вроде есть дополнение (к сожалению, не могу вспомнить название), которое дает кучу алиасов и делает все "проще".
Ожидал более практических результатов в этой статье.
Я, например, пробовал компиляцию в js — как proof-of-concept интересно, но тулинг и поддержка студии (основы "философии") — отвратительные, их практически нет.
Некоторые идеи, представленные здесь — далеко не новые, а уже давно "витают" в сообществе. В Kotlin'е просто использованы свежие идеи. Но от влияния Java он никуда не денется: на некоторые issue JetBrains так и говорит: мы сделали это так, потому что это так в Java.
Я понимаю, что поддерживать старые устройства уже не модно, но у меня на safari в ios7 разметка отвратительная. При предудыщем редизайне было тоже плохо, но терпимо: выезжало черти куда всего пара элементов.
Интересно, практически руководство к "хитрым" методам коллекций. Однако некоторые рекомендации могут привести к менее читаемому коду (хотя, конечно, это вопрос вкусовщины и сильно зависит от контекста).
Например, вспомнить навскидку, что означает ++:= — тяжело.
Другой пример: в тестах, на мой взгляд, assert(x == Some(y)) гораздо понятнее, чем assert(x.contains(y)) (соответственно x shouldBe Some(y) в ScalaTest лучше, чем x should contain (y))
Я считаю, что с точки зрения цены времени программиста — это мало.
Если вы для вас скорость критична — это много.
Если вы разрабатываете «обычное» ПО, и у вас есть другие источники тормозов — база данных, пинг HTTP, накладные расходы от вашего любимого Application Server и т.д., то это мало.
В csv «Benchmark»,«Mode»,«Threads»,«Samples»,«Score»,«Score Error (99.9%)»,«Unit»,«Param: collectionSize»
Вы для Score Error разницу посчитали.
Но как уже ниже написали, есть «ощутимая» разница, которую плохо видно. Но в абсолютном выражении — это ничто.
Просто любое случайное дерево? Их же бесконечное количество?
Или дерево определенного размера? Дерево с ограничением на размер сверху? Остовное дерево для заданного графа? k-ичное дерево?
Это все очень разные задачи, уточните пожалуйста, какую именно вы имели в виду.
Что-то в третьем примере вы не используете наработки из первого.
Что-то тут сравнивается теплое с мягким — система верстки и текстовый редактор. И конечно тот факт, что emacs не подсвечивает опечатки — это проблема emacs, а не Latex. odt в emacs вообще невозможно редактировать — и что?
"Undefined behavior" можете добавить в теги. Вообще странно, что его существование и разная обработка в зависимости от компилятора вас удивляет.
http://en.cppreference.com/w/cpp/language/ub
Puppet, chef, ansible?
Для меня эта статья выглядела "как из git сделать mercurial". Например скрипт для просмотра текущей ветки выглядит… диковато.
У гита вроде есть дополнение (к сожалению, не могу вспомнить название), которое дает кучу алиасов и делает все "проще".
Ожидал более практических результатов в этой статье.
Я, например, пробовал компиляцию в js — как proof-of-concept интересно, но тулинг и поддержка студии (основы "философии") — отвратительные, их практически нет.
Некоторые идеи, представленные здесь — далеко не новые, а уже давно "витают" в сообществе. В Kotlin'е просто использованы свежие идеи. Но от влияния Java он никуда не денется: на некоторые issue JetBrains так и говорит: мы сделали это так, потому что это так в Java.
Хотелось бы пруфов. Да, MLib отказываются от rdd, но о подтверждений того, что от rdd откажутся в core (или хотя бы думают над этим) я не смог найти.
Я понимаю, что поддерживать старые устройства уже не модно, но у меня на safari в ios7 разметка отвратительная. При предудыщем редизайне было тоже плохо, но терпимо: выезжало черти куда всего пара элементов.
https://habrastorage.org/web/95d/e8c/f39/95de8cf396ab46e99afdd300f7d7863f.jpg
https://habrastorage.org/web/bdf/140/f11/bdf140f1132c48cca6cff741f9e2287b.jpg
https://habrastorage.org/web/e5b/8db/3ec/e5b8db3ecb844719bec8ece6574ed7e5.jpg
https://habrastorage.org/web/958/058/30e/95805830e4204258b8a0b55420979702.jpg
Просто, но воспроизводить каждый раз цепочку для
++:=
в уме, когда этот оператор используется пару раз на весь проект — задолбаешься.Интересно, практически руководство к "хитрым" методам коллекций. Однако некоторые рекомендации могут привести к менее читаемому коду (хотя, конечно, это вопрос вкусовщины и сильно зависит от контекста).
Например, вспомнить навскидку, что означает
++:=
— тяжело.Другой пример: в тестах, на мой взгляд,
assert(x == Some(y))
гораздо понятнее, чемassert(x.contains(y))
(соответственноx shouldBe Some(y)
в ScalaTest лучше, чемx should contain (y)
)Если вы для вас скорость критична — это много.
Если вы разрабатываете «обычное» ПО, и у вас есть другие источники тормозов — база данных, пинг HTTP, накладные расходы от вашего любимого Application Server и т.д., то это мало.
Вы для Score Error разницу посчитали.
Но как уже ниже написали, есть «ощутимая» разница, которую плохо видно. Но в абсолютном выражении — это ничто.
Или дерево определенного размера? Дерево с ограничением на размер сверху? Остовное дерево для заданного графа? k-ичное дерево?
Это все очень разные задачи, уточните пожалуйста, какую именно вы имели в виду.
Можно с этого места поподробнее?