Многие считают, что основная причина падения качества контента — заминусовали хороших авторов / комментаторов, и выбраться из такой минусовой ямы почти нереально ( ресет кармы только один ).
Вопрос: как бы вы отнеслись к тому, что при проставлении минуса в карму другому человеку у вас бы тратилась ваша карма? Т. е. человеку -1 кармы, а вам -0.1.
Понятно, что это может ввести некоторый перекос в сторону плюсов ( за плюсы ничего не снимают, а за минусы снимают ), но у нас сейчас вроде как перекос в сторону минусов?
Или я не учел еще какой-то нюанс, и такая система приведет к фиаско?
Он создан умирать, — говорят в каждом подобном топике
Эта фраза не означает, что язык должен умереть и исчезнуть.
Это сказано в том смысле, что на PHP не стоит делать программы, крутящиеся в вечном цикле. Он рассчитан на инициализацию, обработку запроса, завершение.
Вы почему-то написали это в ответ на мой комментарий, так что отвечу.
1.
Распять мерзавца, как он посмел высказать свое мнение! Четвертовать его!
Лично Вам я поставил плюс.
2.
И внезапно язык становится неудобным во всем
Я этого не говорил. Прочитайте сообщение SirEdvin. В нем он спрашивает, почему некоторые моменты языка неудобны, чем вызваны данные решения создателей языка. Ему в ответ overmes пишет, что удобство языка нигде в статье не упоминается. И я отвечаю, что оно подразумевается во многих местах данной статьи.
3.
Я не преувеличу, если скажу, что немного разочарован в сообществе программистов. Более того, все эти кровавые холивары происходят по той же самой причине.
А мне кажется, что это как раз двигатель развития — аргументированный спор ( не путать с тупым флеймом! ). Программисты в душе — идеалисты. Хочется найти священный Грааль лаконичности, понятности и производительности. Вот и происходят споры, выявляющие плюсы и минусы каждого инструмента. Главное — не скатываться на личности и эмоции.
попытка восстановить баланс разумного доброго и вечного
Серьезно?
Любой, кто писал на С/C++, знает во что превращаются проекты, после того, как кодом поработают 5-10 программистов, и код пройдет несколько стадий рефакторинга
писать несколько месяцев REST-бекенд на C++ и нанять для этого ещё 2 rock-star C++ программиста
и в Go, в отличие от, скажем С++, нет undefined behavior при сокрытии переменных
Все эти сравнения ( причем первые два — субъективные ) С++ с Go происходят, когда есть возможность показать, что Go лучше. При обратном сравнении приводится такая аргументация
Go — это другой язык, это не C++
И как финальный аккорд — проезд по остальным языкам
В отличии от многих других языков, Go рождался не студентами-любителями в порыве написать что-нибудь свое, и не теоретиками, гоняющимися за фишками из свежих научных трудов
Я бы Вашу характеристику отнес бы к обеим статьям
не слишком основательно прорабатывает аргументацию, смещая акцент в эмоции. «Инженерный» троллинг :)
Иногда можно уперется в память, т. к. в linked list хранятся указатели на предыдущий и следующий элементы.
И linked list не поддерживает случаный доступ ( привет, O(n) вместо O(1) )
Стоп, кажется, это уже было сказано здесь…
С вашего сайта:
«Инфраструктура Анонимные сообщений для учреждения здравоохранения»
«Улучшенный Сообщение платформу для работы»
«Управление, мониторинг и визуализировать весь трафик данных»
Я не граммар-наци, но это уже за гранью добра и зла…
1. HashMap не потоко-безопасна. HAMT можно реализовать потоко-безопасным ( это не так уж сложно ). Конечно, есть ConcurrentHashMap. Я не пишу на Java, так что ничего не могу сказать про быстродействие.
2. К HAMT можно написать итераторы и обходить как простое дерево, HashMap обходить в определенном порядке, кажется, нельзя.
Еще хороший пример использования HAMT при передаче файлов.
Вообще, всё что я написал выше, применимо ко всем hash trees.
Можно поискать статьи типа «Hash map vs hash tree» для изучения.
Насчет производительности нашел такой набор слайдов. Тут, правда, Haskell, но можно взглянуть на приведенные на последнем слайде цифры.
Тогда фраза «Каждая пара команд играет по 1 разу.» должна звучать «Каждая пара не превосходящих друг друга команд играет по 1 разу.»
Спасибо за уточнение.
Вопрос: как бы вы отнеслись к тому, что при проставлении минуса в карму другому человеку у вас бы тратилась ваша карма? Т. е. человеку -1 кармы, а вам -0.1.
Понятно, что это может ввести некоторый перекос в сторону плюсов ( за плюсы ничего не снимают, а за минусы снимают ), но у нас сейчас вроде как перекос в сторону минусов?
Или я не учел еще какой-то нюанс, и такая система приведет к фиаско?
Потерянные исходники
Вот работающая ссылка
Эта фраза не означает, что язык должен умереть и исчезнуть.
Это сказано в том смысле, что на PHP не стоит делать программы, крутящиеся в вечном цикле. Он рассчитан на инициализацию, обработку запроса, завершение.
Насколько я помню, в стандартной библиотеке нет, но есть iconv
Можно пояснить, что это?
1.
Лично Вам я поставил плюс.
2.
Я этого не говорил. Прочитайте сообщение SirEdvin. В нем он спрашивает, почему некоторые моменты языка неудобны, чем вызваны данные решения создателей языка. Ему в ответ overmes пишет, что удобство языка нигде в статье не упоминается. И я отвечаю, что оно подразумевается во многих местах данной статьи.
3.
А мне кажется, что это как раз двигатель развития — аргументированный спор ( не путать с тупым флеймом! ). Программисты в душе — идеалисты. Хочется найти священный Грааль лаконичности, понятности и производительности. Вот и происходят споры, выявляющие плюсы и минусы каждого инструмента. Главное — не скатываться на личности и эмоции.
Серьезно?
Все эти сравнения ( причем первые два — субъективные ) С++ с Go происходят, когда есть возможность показать, что Go лучше. При обратном сравнении приводится такая аргументация
И как финальный аккорд — проезд по остальным языкам
Я бы Вашу характеристику отнес бы к обеим статьям
Возможно, я ошибаюсь, но мне кажется, что на неудобном языке быстро не напишешь.
Поэтому удобство подразумевается в данном контексте.
Не знал, что такая реализация ( это получается vector из C++ ). Тогда замечание про память невалидно.
Иногда можно уперется в память, т. к. в linked list хранятся указатели на предыдущий и следующий элементы.
И linked list не поддерживает случаный доступ ( привет, O(n) вместо O(1) )
Стоп, кажется, это уже было сказано здесь…
Возможно, человек писал через translate?
Да, надо читать теги.
«Инфраструктура Анонимные сообщений для учреждения здравоохранения»
«Улучшенный Сообщение платформу для работы»
«Управление, мониторинг и визуализировать весь трафик данных»
Я не граммар-наци, но это уже за гранью добра и зла…
2. К HAMT можно написать итераторы и обходить как простое дерево, HashMap обходить в определенном порядке, кажется, нельзя.
Еще хороший пример использования HAMT при передаче файлов.
Вообще, всё что я написал выше, применимо ко всем hash trees.
Можно поискать статьи типа «Hash map vs hash tree» для изучения.
Насчет производительности нашел такой набор слайдов. Тут, правда, Haskell, но можно взглянуть на приведенные на последнем слайде цифры.
Спасибо за уточнение.