Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.
Чтобы такие символы не появлялись, нужно код ревью. Стоимость разрабов этому ортогональна.
То сложное, что скала позволяет делать, завязано на работу с типами. Нужно в реализации приложений редко и можно обойтись. Как раз для таких финтов и нужны более дорогие разрабы.
Нет. Вы просто повторяете маркетинговый буклет при том, что дьявол всегда в деталях.
Сравнивая разные модели вычислений, вывод почему-то перенесся целиком на рантаймы.
Почти всегда в вопросах производительности заложен как минимум один трейдофф. Этим всегда пользуются маркетологи, рисуя один кейс и игнорируя другие. «Уверовавшие»потом ходят и продолжают их дело, рассказывают про эдем, эликсир вечного перформансного счастья и т.д. (чем ниже порог входа тем проще и больше можно привлекать людей, «жизнь коротка, ты и так уже потратил 15 минут на обучение, ты теперь можешь всё!»)
У монады смысл в том, что производится манипуляция не только со значением, но и с эффектом конкретной монады. То, что можно выделить интерфейс и в каких-то случаях абстрагироваться от конкретики, конечно прекрасно, но все же вторично.
Опыт различных коллег по цеху и о 2ой версии. Поэтому и пометил как тролль-мод.
Почитать можно Кайла, который специализируется на тестировании распределенных систем. Как раз появились результаты свежего теста монги. В архив есть еще пара о ней же и пара ресинковских.
Её ценность как раз в тех вещах, что отличают её от других документо ориентированных баз. [mode type=«troll»]В отличие от монги она еще не разваливается в кластере при дуновении ветра[/mode]
Спасибо, что поиск теперь работает лучше чем год назад, когда на запрос scala выдавалось еще всё со словом scalable. А вакансий субъективно стало наоборот больше.
1) Реализация на уровне типов в скале возможна далеко не всегда. К сожалению сейчас эта система типов не тьюринг полная.
2) Помимо функциональных различий есть еще различия в производительности. Обобщенное программирование всегда будет выливаться в вызов виртуальных методов.
Запихать все в один бин можно, но лишь в части кейсов. Таким образом вы лишаетесь возможности создавать вторичные индексы по части данных и доставать из базы лишь часть данных. Я надеюсь, что библиотека все же ориентируется на универсальное использование. Иначе смысла в этом действительно нет.
CLR стал доступен позже под не-винду, чем от него отказались. Скорее всего выбирать все равно пришлось бы, потому что две разных VM трудно одновременно поддерживать.
1) Чем не устроил ворох существующих инструментов?
2) Как у любого измерительного прибора нужны какие то гарантии по точности измерений.
3) Большие сомнения, что в комбайне учтены нюансы такого сложного мира как «диски».
Каррирование — преобразование сигнатуры функции, для получения результата нужно передать то же количество аргументов. После каррирования получается функция, которая принимает часть аргументов и возвращает новую функцию, которая принимает другую часть аргументов и возвращает…
Частичное применение производится на каррированной функции. Если передать передать лишь первую группу аргументов, то на выходе будет новая функция (которая благодаря замыканию, будет использовать переданные ранее значения). Это не так часто применимо как об этом пишут, но когда потребуется, позволяет сильно сократить код, повысить читаемость (наверно потому так часто и упоминают, что польза большая, а минусов нет). Если применять везде, то читаемость только ухудшится, потому что сигнатуры не будут нести логического обоснования и в большом нагромождении принесут путаницу.
Каррирование и частичное применение связаны непосредственно друг с другом, поэтому это нормально, что не видно сначала разницы.
Чтобы такие символы не появлялись, нужно код ревью. Стоимость разрабов этому ортогональна.
То сложное, что скала позволяет делать, завязано на работу с типами. Нужно в реализации приложений редко и можно обойтись. Как раз для таких финтов и нужны более дорогие разрабы.
Это всего лишь стокгольмский синдром.
[mode=«troll»]Не могу удержаться [/mode]
Почитать можно Кайла, который специализируется на тестировании распределенных систем. Как раз появились результаты свежего теста монги. В архив есть еще пара о ней же и пара ресинковских.
2) Помимо функциональных различий есть еще различия в производительности. Обобщенное программирование всегда будет выливаться в вызов виртуальных методов.
А в целом да, холиварная тема.
з.ы. цирцея все-таки с макросами живет.
2) Как у любого измерительного прибора нужны какие то гарантии по точности измерений.
3) Большие сомнения, что в комбайне учтены нюансы такого сложного мира как «диски».
Частичное применение производится на каррированной функции. Если передать передать лишь первую группу аргументов, то на выходе будет новая функция (которая благодаря замыканию, будет использовать переданные ранее значения). Это не так часто применимо как об этом пишут, но когда потребуется, позволяет сильно сократить код, повысить читаемость (наверно потому так часто и упоминают, что польза большая, а минусов нет). Если применять везде, то читаемость только ухудшится, потому что сигнатуры не будут нести логического обоснования и в большом нагромождении принесут путаницу.
Каррирование и частичное применение связаны непосредственно друг с другом, поэтому это нормально, что не видно сначала разницы.