К счастью, IE8 в нашем мире осталось не так уж и много. Совместимость это хорошо, но когда совместимость достигается в угоду производительности это уже не так хорошо. Было бы неплохо ключом компиляции это настраивать хотя бы.
Я хочу сказать, что проход по массиву в джаваскрипте делается с помощью forEach map и им подобными. Делается не только из соображений удобства, но и из соображений производительности. А coffeescript при трансляции выбирает медленный вариант.
Вы ничего не перепутали? В JS массивы как массивы, там только цифровые индексы, и:
Увы, это не так. Массивы в джаваскрипте примерно такие же как в php. Собственно если в языке можно писать и array[1] и array['ke'] то они другими и быть не могут.
Не стоит винить синтаксический сахар в том, что его используют неправильно
Не стоит использовать его там, где в нём нет нужды. И тем более не стоит выкладывать примеры бесполезного использования на главную страницу.
Если бы array comprehensions были частью javascript, замечание было бы справедливым. Но там их нет и поэтому for из coffeescript имеет с for циклом столько же общего, сколько с ним имеет for in.
Могу и даже рекомендовал писать именно его в заключении. Но приведённый мной код — цитата с главной страницы сайта CoffeeScript. Поэтому он и был подвергнут разбору.
За совет с jsperf спасибо.
Эта опечатка показалась мне очень смешной, но никто не заметил. Тогда я опечатался ещё раз, в надежде, что мой юмор найдёт своего ценителя. И он нашёлся :).
В данном случае золотая середина это на 100% покрытая юнит тестами программа, написанная на языке программирования с сильной статистической типизацией.
Во Fringe главные герои — учёные. Только наука у них такая, что Хогвартс нервно курит в сторонке. Там хотя бы Дамблдор честно говрорит — это всё магия, дети. Если бы главным героем был какой-нибудь бешеный командир корабля, сериал можно было бы назвать фантастикой, да и то с натяжкой. А так — вы бы ещё Warehouse 13 в НФ записали.
Мне будет очень приятно, если вы приведёте цитату, в которой я заявил, что я не учил и не хочу учить Go. Да что там, даже цитата, в которой я сказал, что Go мне не нравится, меня порадует.
Я поинтересовался как в Go без дженериков. Как решаются те задачи, которые в других языках решаются с их помощью. Выяснилось, что некоторые задачи решаются с помощью интерфейсов, а задача создания параметризированного контейнера не решается никак.
Кроме того вы утверждали, что дженерики неоправданно усложняют язык и неоднократно советовали ознакомиться с документом. Я с ним ознакомился и выяснил, что в документе написано — язык усложняют не дженерики, а их отсутствие. Недостатки и компромисы технологий и подходов действительно надо понимать, но в случае с дженериками вы по меньшей мере понимаете их недостатки не так, как авторы документа, который вы рекомендуете к прочтению.
Обратите внимание, я не говорю, что Go — это плохо, я делаю конкретные утверждения. Например о том, что дженерики нужны для изготовления параметризированных контейнеров. И о том, что без дженериков делать контейнеры крайне неудобно. Или я утверждаю, что быстрая компиляция и гарантированная пауза для сборки мусора это крайне удобно. Всегда приводите конкретные утверждения, которые легко проверить, это делает вашу точку зрения гораздо более понятной для окружающих.
Ну и конечно когда человек, обвиняющий окружающих в хейтерстве переходит на личности первым — это пять.
vintage да, осуждает.
Что касается меня, то посмотрите внимательнее, что я писал про Cons. Там в основном молчанивое согласие.
А вот Pros, да, сомнительные.
divan0 в защиту отсутствия дженериков приводил аргумент, что дженерики усложняют язык. И советовал всем прочитать документ, чтобы лучше разобраться в теме. А в документе написано обратное. Написано что язык усложняет отсутствие дженериков.
Прошу прощения, половина поста случайно отправилась.
Cons
each generic type adds complication to compiler
Таки усложняет компилятор, если волшебных generic типов много
each generic type makes the language more complicated
Опа. Оказывается, по мнению авторов документа, это отсутствие поддержки дженериков делает язык сложнее. А вы почему-то, ссылаясь на документ, утверждаете обратное.
the generic types must perform well in lots of cases
Сложно встроить дженерики в язык так, чтобы он работал хорошо во всех случаях — кто бы мог подумать.
the language is less flexible (because users can build less abstractions)
и
Это две разные конструкции, вот что я хочу сказать.
Увы, это не так. Массивы в джаваскрипте примерно такие же как в php. Собственно если в языке можно писать и array[1] и array['ke'] то они другими и быть не могут.
Не стоит использовать его там, где в нём нет нужды. И тем более не стоит выкладывать примеры бесполезного использования на главную страницу.
За совет с jsperf спасибо.
А так, да, я про статическую типизацию.
Я поинтересовался как в Go без дженериков. Как решаются те задачи, которые в других языках решаются с их помощью. Выяснилось, что некоторые задачи решаются с помощью интерфейсов, а задача создания параметризированного контейнера не решается никак.
Кроме того вы утверждали, что дженерики неоправданно усложняют язык и неоднократно советовали ознакомиться с документом. Я с ним ознакомился и выяснил, что в документе написано — язык усложняют не дженерики, а их отсутствие. Недостатки и компромисы технологий и подходов действительно надо понимать, но в случае с дженериками вы по меньшей мере понимаете их недостатки не так, как авторы документа, который вы рекомендуете к прочтению.
Обратите внимание, я не говорю, что Go — это плохо, я делаю конкретные утверждения. Например о том, что дженерики нужны для изготовления параметризированных контейнеров. И о том, что без дженериков делать контейнеры крайне неудобно. Или я утверждаю, что быстрая компиляция и гарантированная пауза для сборки мусора это крайне удобно. Всегда приводите конкретные утверждения, которые легко проверить, это делает вашу точку зрения гораздо более понятной для окружающих.
Ну и конечно когда человек, обвиняющий окружающих в хейтерстве переходит на личности первым — это пять.
Что касается меня, то посмотрите внимательнее, что я писал про Cons. Там в основном молчанивое согласие.
А вот Pros, да, сомнительные.
divan0 в защиту отсутствия дженериков приводил аргумент, что дженерики усложняют язык. И советовал всем прочитать документ, чтобы лучше разобраться в теме. А в документе написано обратное. Написано что язык усложняет отсутствие дженериков.
Cons
Таки усложняет компилятор, если волшебных generic типов много
Опа. Оказывается, по мнению авторов документа, это отсутствие поддержки дженериков делает язык сложнее. А вы почему-то, ссылаясь на документ, утверждаете обратное.
Сложно встроить дженерики в язык так, чтобы он работал хорошо во всех случаях — кто бы мог подумать.
Ну понятно в общем, чего коментировать.
Pros
В джаве куча стандартных параметризированных типо, они ведут себя предельно предсказуемо. И наличие дженериков этому не помешало.
И таки да, это правда. Только вы почему-то утверждаете, что дело не в этом.
Преимущество сомнительное, в С++ при необходимости оптимизации просто определяют специализацию шаблона.
Преимущество опять же сомнительное, не хочешь абстракций — не делай их.