Исследуем JavaScript Generators

С Вашим примером так и до хаскеля недалеко, уж очень синтаксис нестандартный в этом LiveScript. Я так понял, что восклицательный знак как то обозначает асинхронную операцию.

Исследуем JavaScript Generators

Ну так черновик следующей версии спецификации — ECMAScript 6 draft, список нововведений, список предложений новых фич

Опыт обучения школьников программированию

На Scheme:

(define (left-pos rect) (car rect))
(define (top-pos rect) (cadr rect))
(define (width rect) (caddr rect))
(define (height rect) (cadddr rect))

(define (in? x low hi)
  (and (>= x low) (<= x hi)))
                         
(define (inside? rect x y) 
  (and
   (in? x (left-pos rect) (+ (left-pos rect) (width rect)))
   (in? y (top-pos rect) (+ (top-pos rect) (height rect)))))

(inside? (list 0 0 30 40) 20 30)

Опыт обучения школьников программированию

Вот решение квадратного уравнения.

(define (discriminant a b c)
  (- (* b b) (* 4 a c)))

(define (solve a b c)
  (let ((d (discriminant a b c)))
    (cond ((< d 0) (error "уравнение не имеет действительных корней"))
          ((= d 0) (- (/ b (* 2 a))))
          (else (list (/ (+ (- b) (sqrt d)) (* 2 a)) 
                      (/ (- (- b) (sqrt d)) (* 2 a)))))))

(solve 1 8 7)

Разве все так ужасно выглядит?

Опыт обучения школьников программированию

Ну это же стереотип. Для мелких заданий очень даже удачный синтаксис.

Опыт обучения школьников программированию

Если следовать основной мысли подхода, а именно учить не языку, а решению задач, то я предлагаю Scheme. Сам я начинал с С. Так вот, для того что б начать программировать на С, нужно хоть базово знать архитектуру процессора и основы организации памяти в компьютере.

Хроники LinguaLeo: как мы сделали «Диалоги на английском» с Node.js и DynamoDB

На мой взгляд, «плохо прикручиваются» потому что там где их активно используют никому это не нужно.

Обзор ECMAScript 6, следующей версии JavaScript

Подробно изучите возможности деструктуризации (destructuring assignment), именно она применяется для разбора параметров.
В данном случае в теле функции foo будут доступны две переменные — from и to, значениями которых будут {bar:2, foo: 3} и 5 соответственно.

Асинхронные API и объект Deferred в деталях

Концепция Deferred давно знакома в мире JavaScript. Более того, в ранних версиях Node.js применяли Promise API для асинхронных функций. Но как-то не прижилось, и на это есть свои причины. Недавно пройшла очередная волна споров, что лучше, callback или promise:
Callbacks are imperative, promises are functional: Node’s biggest missed opportunity
Broken Promises
Broken Promises
Callbacks, promises and simplicity

Лично я предпочитаю callbacks как более простое решение.

Связные списки в функциональном стиле

сar и cdr это тяжелое наследие лиспа, причем нифига не семантичное, в отличии от head и tail

Обзор ECMAScript 6, следующей версии JavaScript

Вот rest и spread действительно нужно добавить в статью, как мне кажется, полезная вещь.

Javascript умирает или перерождается?

Не вводите людей в заблуждение. Замыкания в JavaScript как раз лексические.
А вот контекст и вправду динамический. Но как только ты об этом узнаеш, вся магия исчезает. Это фича JavaScript.

Javascript умирает или перерождается?

Мне тоже нравятся строготипизированные функциональные языки, и именно поэтому я люблю JavaScript. Ведь до недавнего времени только на JavaScript (среди прочих мейнстрим языков) можно было хоть как-то писать в функциональном стиле (функции как сущности первого порядка, замыкания).
Боюсь что еще нескоро такие языки как OCaml, Haskell, даже Scala, получат значительную долю на рынке.

Почему вам стоит использовать TypeScript

Для себя сделал такое заключение.
Основная проблема при понимании реализации ООП в JavaScript — модель наследования. Она отличается от популярних языков.
Все привыкли к иерархическому наследованию, тогда как в JavaScript другая модель — делегирующее наследование.
В JavaScript нет ключевого слова extend, вот тут у многих начинается паника. И вместо того чтоб разобратся с теми возможностями, которые предоставляет JavaScript, они ставят клеймо на язык «недоООП».

Тем не менее на JavaScript можно реализовать и иерархическое наследование. В таких случаях и делают разные обертки для того чтоб не повторять каждый раз одно и тоже. Здесь я поддерживаю предложение синтаксиса классов в ES6.

Почему вам стоит использовать TypeScript

Ну так это просто синтаксический сахар. Прототипы никуда не денутся.
Лично для меня ES6 классы — это:
1) декларативное описание иерархическое наследование (как у C/C++/Java)
2) унификация обьявления классов (вместо собственного велосипеда)

Ratatype — клавиатурный тренажер, с планами покорить мир

Для меня пока что идеал — klava.org. Большой плюс, что там можно тренировать ввод на языках программирования.
Для разнообразия попробую и ваш сервис.

Сборка клиентских JavaScript шаблонов

Все шаблоны собираються вместе с кодом приложения в один файл app.js. Но если взять отдельный шаблон, тогда получается так: исходный шаблон — 1.4 КБ, скомпилированный — 3,8 КБ.

Да, размер на самом деле больше. Вы заставили меня задуматся. Правда у меня сейчас не так много шаблонов, что б волноватся за их размер.

Но надо заметить, что часть кода сжимается js минификатором и думаю для одностраничных приложений, где много кода приложения, шаблоны не будут сильно влиять на итоговый размер.

Сборка клиентских JavaScript шаблонов

Поддерживаю. Прекомпиляции не вижу, только конкатенация и быстрый доступ посредством глобальной переменной.

Сборка клиентских JavaScript шаблонов

На своих проектах использую brunch + handlebars + live reload plugin. В результате все шаблоны скомпилированы, brunch следит за изменениями, а live reload прямо перегружает браузер. Очень удобно!

По поводу доступа. Все шаблоны лежат в папке app/templates. В скомпилированом коде это просто javascript функции, которые доступны как CommonJS модули.

Для примера есть шаблон app/templates/main-layout.hbs. В програмном коде пишем:

var mainLayoutTmpl = require('templates/main-layout');
var renderedTmpl   = mainLayoutTmpl({ title: 'Hello world!' });

Простой доступ и никаких глобальных переменных.

Абстрагирование потока управления

Мне например легче читать функциональний вариант нежели императивный (возможно из за того что я плохо знаком с Python). В результате мы получаем и используем некий DSL, который да, нужно понимать. Минус в том, что этот DSL надо описать, и здесь Python не настолько удобен и местами избыточен. Но надо заметить один факт: мы получаем код, разбитий на маленькие кусочки. Декомпозиция в действии. Каждый кусочек можна расматривать отдельно, и что самое главное на мой взгляд, на основе этих мелким елементов можна построить все более и более сложные блоки, при этом сохраняя простоту и независимость каждого из них. Вот вам и повторное использование кода! Чем больше императивного кода, тем сложнее разобратся что же он делает в конце концов.