Просто первый был бизнесмен, а второй — программист.
Потому у них были разные цели (хотя из пересказа это неочевидно).
Первый всего лишь заработал кучу денег, второй — получил огромное удовольствие от работы.
Вам, видимо, важнее деньги :)
Ммм… не совсем понятно, зачем абстрагироваться от коллекций и при этом писать reduce, который работает лишь для массива или объекта, похожего на массив.
Надо бы подумать над этим моментом, а иначе все преимущество вынесенного append (потенциально позволяет собирать другую коллекцию вместо массива) уходит практически в никуда: либо собирай им только массив (скучно!), либо для следующей обработки полученной коллекции придется перегонять ее в массив (скучно вдвойне!).
В общем, идея здравая, но несколько недоделанная на мой взгляд. Нужен способ абстрактного итерирования по коллекции.
А еще лично я бы не стал безоглядно тащить все из функциональщины.
То, что хорошо выглядит на Хаскеле (в силу особенностей синтаксиса), отвратительно выглядит на джаваскрипте.
Имхо, в джаваскрипте лучше работает коллекция (массив).
То есть для достижения того же результата, достаточно просто остановиться на нотации типа step = function (result, item) {… return {result: new_result, item: new_item};}, договориться о «break» и «continue», т.е. на ряду со специальным значением Reduced, которое в данном случае может выглядеть как {result: new_result} ввести специальное значение Skipped — {result: new_result, skip: true} — которое позволяет перейти на следующий шаг итерации, не заканчивая вычислять результат этой), а потом положить набор таких функций в массив, который дефакто будет трасдьюсером (слово то какое сложное!). Потом на каждом шаге итерации надо просто бежать по этому массиву, вычисляя промежуточный результат. Такая реализация упрощает написание атомарных трансдьюсеров (нет нужды писать функцию, которая возвращает функцию, возвращающую функцию; пишем функцию попроще, которая возвращает функцию типа step).
Пример кода использования для filterMapTake для такой реализации:
где transduce = function (coll, seed, transducer)
Имхо, такой синтаксис более оправдан; не вижу особого смысла выделять append и усложнять его специальными случаями.
С самим vim идет vimtutor, для начала — прекрасная вещь.
Это по сути запущенный vim с текстовым файлом (правда, на английском, надеюсь, что не проблема), в котором тебе рассказывают, что к чему, и ставят задания, которые в нем же и выполняешь.
Базовые навыки осваиваются на ура.
А потом уже хелп самого vim для более тонкой настройки.
Прошу учитывать, что я не гуру vim, я не пишу для него плагины, например, и не делаю из него ide, как некоторые.
Для меня это просто достаточно удобный текстовый редактор — не более.
Хотя код под линуксом я пишу исключительно в нем.
Ага, я тоже после ртути поначалу плевался. А еще staging считал жутко неудобной никому не нужной хренью. :)
Но потом заметил, что перестал случайно добавлять всякую ерунду в коммиты, и плеваться закончил.
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
Являсь сторонником git и достаточно ярым почитателем консоли (мержу, например, исключительно с использованием vim), отмечу, что следующие вещи делать без GUI жутко неудобно:
1. Рассматривать дерево истории
2. Брать в commit лишь часть локальных изменений файла
3. Просматривать аннотацию (кто, какие изменения и в каких версиях внес)
4. Смотреть дифф при большом количестве изменений или когда необходимо знать контекст изменения в широком смысле (то бишь полазить по файлу, чтобы понять, а что тут что)
У меня работает именно так, как в описании, то есть ни repository, ни refspec не являются обязательными, у них есть значения по умолчанию.
Но лично я их чаще всего в явном виде прописываю, чтобы самому себе точно показать что и куда я push'у, например.
Потому у них были разные цели (хотя из пересказа это неочевидно).
Первый всего лишь заработал кучу денег, второй — получил огромное удовольствие от работы.
Вам, видимо, важнее деньги :)
Надо бы подумать над этим моментом, а иначе все преимущество вынесенного append (потенциально позволяет собирать другую коллекцию вместо массива) уходит практически в никуда: либо собирай им только массив (скучно!), либо для следующей обработки полученной коллекции придется перегонять ее в массив (скучно вдвойне!).
В общем, идея здравая, но несколько недоделанная на мой взгляд. Нужен способ абстрактного итерирования по коллекции.
А еще лично я бы не стал безоглядно тащить все из функциональщины.
То, что хорошо выглядит на Хаскеле (в силу особенностей синтаксиса), отвратительно выглядит на джаваскрипте.
Имхо, в джаваскрипте лучше работает коллекция (массив).
То есть для достижения того же результата, достаточно просто остановиться на нотации типа step = function (result, item) {… return {result: new_result, item: new_item};}, договориться о «break» и «continue», т.е. на ряду со специальным значением Reduced, которое в данном случае может выглядеть как {result: new_result} ввести специальное значение Skipped — {result: new_result, skip: true} — которое позволяет перейти на следующий шаг итерации, не заканчивая вычислять результат этой), а потом положить набор таких функций в массив, который дефакто будет трасдьюсером (слово то какое сложное!). Потом на каждом шаге итерации надо просто бежать по этому массиву, вычисляя промежуточный результат. Такая реализация упрощает написание атомарных трансдьюсеров (нет нужды писать функцию, которая возвращает функцию, возвращающую функцию; пишем функцию попроще, которая возвращает функцию типа step).
Пример кода использования для filterMapTake для такой реализации:
где transduce = function (coll, seed, transducer)
Имхо, такой синтаксис более оправдан; не вижу особого смысла выделять append и усложнять его специальными случаями.
Попробую при случае.
Это по сути запущенный vim с текстовым файлом (правда, на английском, надеюсь, что не проблема), в котором тебе рассказывают, что к чему, и ставят задания, которые в нем же и выполняешь.
Базовые навыки осваиваются на ура.
Еще есть вот это: www.google.ru/search?q=vim+graphical+cheat+sheet&hl=ru&newwindow=1&client=safari&tbo=u&rls=en&tbm=isch&source=univ&sa=X&ei=69kUUY-kL-Gq4ASd3YCIAw&ved=0CDwQsAQ&biw=1279&bih=904
А потом уже хелп самого vim для более тонкой настройки.
Прошу учитывать, что я не гуру vim, я не пишу для него плагины, например, и не делаю из него ide, как некоторые.
Для меня это просто достаточно удобный текстовый редактор — не более.
Хотя код под линуксом я пишу исключительно в нем.
Но потом заметил, что перестал случайно добавлять всякую ерунду в коммиты, и плеваться закончил.
Являсь сторонником git и достаточно ярым почитателем консоли (мержу, например, исключительно с использованием vim), отмечу, что следующие вещи делать без GUI жутко неудобно:
1. Рассматривать дерево истории
2. Брать в commit лишь часть локальных изменений файла
3. Просматривать аннотацию (кто, какие изменения и в каких версиях внес)
4. Смотреть дифф при большом количестве изменений или когда необходимо знать контекст изменения в широком смысле (то бишь полазить по файлу, чтобы понять, а что тут что)
SYNOPSIS git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] [<repository> [<refspec>...]]У меня работает именно так, как в описании, то есть ни repository, ни refspec не являются обязательными, у них есть значения по умолчанию.
Но лично я их чаще всего в явном виде прописываю, чтобы самому себе точно показать что и куда я push'у, например.