В ветке scalaz7 они отделили основную функциональность от операторов, поэтому если вам категорически не нравится юникод то вместо него можно использовать длинные текстовые имена методов. Признаться честно, я и сам в реальном коде предпочитаю не использовать юникодные операторы.
Считать же scalaz истинным злом я бы не стал — реализуемые этой библиотекой абстракции действительно очень полезны.
Да, я видел этот проект. Тоже хороший вариант, но на мой взгляд он больше похож именно на web framework, а для простого rest мне unfiltered нравится больше. К тому же, в unfiltered вроде типизация построже.
Пример какой-то не очень удачный. Насколько я понимаю, основной смысл этого свойства в том, что размеры могут быть в разных единицах, например width: 30%, а border: 1px. Тогда действительно без box-sizing сложно.
А если всё в пикселах, то можно и заранее просчитать, ради такого не стали бы отдельное свойство вводить.
Мы для избежания таких проблем стараемся во-первых, ставить задачам по инспекции более высокий приоритет по сравнению с обычной разработкой, а во-вторых разрабатывать небольшими законченными кусками, что бы инспектору не приходилось неделями сидеть и разбираться что же там такое написали.
Ну вот я здесь про CS написал, может процент новичков и увеличится.
А среди профи процент я думаю и так достаточно высок, всё же без желания изучать новое профессионалом вообще стать трудно.
К тому же, речь идёт не о скриптах типа «хочу что бы кнопка donate сама бегала за курсором», а о web-приложениях. Хочется надеяться, что среди их авторов профессионалов чуть больше чем в среднем по палате.
3 — это всё библиотеки, а не язык. Местами (например в node.js) асинхронность вообще в абсолют возведена. А асинхронность в языке это например async/await из С#. Или, если говорить о JS, то это например streamline.js.
Что касается «утиной» типизации — язык не заставляет вас сравнивать прототипы или как-то указывать тип объектов, вы просто вызываете методы, или проверяете наличие свойств. Если же вы начнёте в начале каждого метода проверять прототипы объектов, то по сути вы действительно «утиную» типизацию уберёте.
А я сразу сказал что это взгляд с колокольни С++, Javа, и некоторых других популярных языков. Да и вообще, посмотрите на заглавную картинку поста.
Если вы уже профессионал в JS, то это вполне нормальная причина использовать его, а не CS.
А если вы в JS новичок, но по каким-то причинам вам нужно разработать Web-приложение, то лучше взять CS и сразу начать писать правильный код, а про устройство JS почитать отдельно. Иначе велик шанс, что код придётся неоднократно переписывать по мере узнавания той или иной «особенности» языка.
То, что он похож на this в C++ или Java, но при этом ведёт себя по другому — указывает не на тот объект, которому принадлежит функция, а на тот объект, на котором её вызвали. Именно отсюда возникла
//удобная ссылка на сам объект
var self = this;
в четвёртом пункте статьи.
Это всё некритичные вещи, «особенности», как вы их назвали. Но именно из таких «особенностей» складывается образ языка программирования. Про них можно знать и к ним можно привыкнуть, но лучше бы их не было.
Пример в п.2 какой-то неверный и не имеющий никакого отношения к прототипному наследованию.
Что касается 3, то асинхронность языка вовсе не даёт вам параллельность вычислений. JavaScript однопоточен, а Web workers появились совсем недавно. Да и нет в самом JavaScript особой асинхронности.
Да и с 5 я бы тоже не согласился, к функциональному стилю JS приближает только наличие замыканий, но замыкания сейчас есть в том или ином виде практически везде. Конечно, вы можете писать на JS в функциональном стиле и получать все не описанные вами преимущества, но сам язык этому точно не способствует.
Про this вы сами ответили. Про область видимости — блоки {...} не создают новый scope. Прототипное наследование как минимум непривычно.
Ещё раз повторюсь, я не говорю что JavaScript плохой язык, или что его логику невозможно понять, но если мне понадобится писать под Web я выберу что-то более привычное. Для большинства программистов CoffeScript окажется более привычным. А за новыми идеями и концепциями я лучше в Haskell пойду.
Считать же scalaz истинным злом я бы не стал — реализуемые этой библиотекой абстракции действительно очень полезны.
width: 30%, аborder: 1px. Тогда действительно без box-sizing сложно.А если всё в пикселах, то можно и заранее просчитать, ради такого не стали бы отдельное свойство вводить.
А среди профи процент я думаю и так достаточно высок, всё же без желания изучать новое профессионалом вообще стать трудно.
К тому же, речь идёт не о скриптах типа «хочу что бы кнопка donate сама бегала за курсором», а о web-приложениях. Хочется надеяться, что среди их авторов профессионалов чуть больше чем в среднем по палате.
Что касается «утиной» типизации — язык не заставляет вас сравнивать прототипы или как-то указывать тип объектов, вы просто вызываете методы, или проверяете наличие свойств. Если же вы начнёте в начале каждого метода проверять прототипы объектов, то по сути вы действительно «утиную» типизацию уберёте.
Если вы уже профессионал в JS, то это вполне нормальная причина использовать его, а не CS.
А если вы в JS новичок, но по каким-то причинам вам нужно разработать Web-приложение, то лучше взять CS и сразу начать писать правильный код, а про устройство JS почитать отдельно. Иначе велик шанс, что код придётся неоднократно переписывать по мере узнавания той или иной «особенности» языка.
в четвёртом пункте статьи.
Это всё некритичные вещи, «особенности», как вы их назвали. Но именно из таких «особенностей» складывается образ языка программирования. Про них можно знать и к ним можно привыкнуть, но лучше бы их не было.
Что касается 3, то асинхронность языка вовсе не даёт вам параллельность вычислений. JavaScript однопоточен, а Web workers появились совсем недавно. Да и нет в самом JavaScript особой асинхронности.
Да и с 5 я бы тоже не согласился, к функциональному стилю JS приближает только наличие замыканий, но замыкания сейчас есть в том или ином виде практически везде. Конечно, вы можете писать на JS в функциональном стиле и получать все не описанные вами преимущества, но сам язык этому точно не способствует.
Ещё раз повторюсь, я не говорю что JavaScript плохой язык, или что его логику невозможно понять, но если мне понадобится писать под Web я выберу что-то более привычное. Для большинства программистов CoffeScript окажется более привычным. А за новыми идеями и концепциями я лучше в Haskell пойду.