Ну «активный аккаунт в соцсетях», на мой взгляд, весьма избыточное требование (особенно после загруженного скана паспорта). К тому же выбор тех же соцсетей получился весьма ограниченным: Фейсбук, Гугл да Линкед-Ин. Да и что значит «активность» аккаунта? Количество постов? «Друзей»? Время существования. Непонятно, в общем-то.
Когда я верифицировал аккаунт, скормленный Airbnb адрес моей электропочты в гугле был опознан как «не слишком активный» и они предложили мне снять видеопрезентацию самого себя. По мне так это перебор.
Я считаю что того же скана паспорта + номера кредитки (а лучше вообще просто номера кредитки) было бы вполне достаточно для полноценной верификации.
> Я говорил про костыльный Promise который до es6.
Promise в ES6 это практически те же самые Promise, которые были и до этого. Просто они ушли в стандарт, не более того. Костылей там никаких никогда и не было: их и на обычном стандартном EcmaScript 3 вполне можно реализовать.
> В JS'e нет ничего про асинхроность и реактор. О чем вы говорите? Асинхроность в node.js целиком и полностью находится в libuv.
Асинхронность — это не стандарт, конечно же, но все популярные движки JS работают именно так. Что касается libuv — я говорил про общий подход, а не про конкретную реализацию асинхронного ввода-вывода.
> Однопоточные серверные приложения не нужны.
Почему? Чем вам не угодили, например, однопоточные, но многопроцессные серверные приложения, например?
> Странный вопрос. Используйте что хотите :) Я предпочитаю browserify, например ;)
> …
Я имел ввиду что не понимаю стенаний по-поводу того что использовать: AMD, CJS, RequireJS или ES6. Что вы конкретно хотели этим сказать?
> Язык практически не менялся годами. Там forEach был не сразу. Только в es6 начал приобретать человеческий вид.
Он начал развиваться вместе с бумом веб-приложений середины двухтысячных. Когда появилась необходимость в более продвинутых инструментах — появился и новый стандарт. Ничего необычного.
Ну я не согласен что Promise — это магия. Так и любой шаблон проектирования можно магией назвать.
> Что мне использовать? AMD? RequireJS? CJS? Или же модули из es6?
Странный вопрос. Используйте что хотите :) Я предпочитаю browserify, например ;)
Я не утверждаю что JavaScript — идеальный. Просто это язык который вымучен и создан практикой и все вещи которые в нем появились — появились из практических соображений. А асинхронная природа, которая появилась как раз в результате создания «на коленке» пришлась очень кстати при написании серверных приложений.
> Я писал на node.js на чистом js вообще не возможно писать
А что конкретно было плохо? Я, например, как-то к Promise прикипел и пишу асинхронный код абсолютно спокойно, без всякой странной магии, которую предлагает IcedCoffee, типа await и defer.
> зачем оно вне браузера
Странный какой-то вопрос. Это полноценный, стандартизированный язык высокого уровня, на котором можно с успехом писать (и пишут ведь, и много) server-side и desktop-приложения. JavaScript никоим образом ни разу не заточен на «манипуляции с веб-страничками»: ни по стандарту, ни по архитектуре.
Ну в голом Javascript такого нет. Можно использовать функциональные языки, например ClojureScript. Есть еще Scala.js, но я не знаю насколько она стабильна.
Если что-то упирается в производительность процессора/памяти, то это «что-то» обычно переписывают на чем-то более высоко-производительном. Частая связка, например, Ruby+Scala.
Я написал что для array-like объектов, т.е. для объектов с полями-индексами и length. Или arguments, например :)
Для обычных объектов, разумеется, нет. Хотя для примера из вашего комментария можно соорудить что-то вроде этого:
var collection = {
foo: 'bar',
baz: 'qux'
};
var predicate = function (x) {
return collection[x] === 'bar';
};
console.log(Array.prototype.filter.call(Object.keys(collection), predicate).map(function(key) { return collection[key]; }));
Но это уже легкий изврат :)
Я в таких случаях предпочитаю писать более прямой и понятный код. По крайней мере поведение _.filter в данном случае мне кажется не совсем очевидным, поскольку фильтрующая функция применяется к значениям, а не к ключам объекта или хотя бы к парам [ключ, значение]. Но это ИМХО, конечно.
Когда я верифицировал аккаунт, скормленный Airbnb адрес моей электропочты в гугле был опознан как «не слишком активный» и они предложили мне снять видеопрезентацию самого себя. По мне так это перебор.
Я считаю что того же скана паспорта + номера кредитки (а лучше вообще просто номера кредитки) было бы вполне достаточно для полноценной верификации.
Promise в ES6 это практически те же самые Promise, которые были и до этого. Просто они ушли в стандарт, не более того. Костылей там никаких никогда и не было: их и на обычном стандартном EcmaScript 3 вполне можно реализовать.
> В JS'e нет ничего про асинхроность и реактор. О чем вы говорите? Асинхроность в node.js целиком и полностью находится в libuv.
Асинхронность — это не стандарт, конечно же, но все популярные движки JS работают именно так. Что касается libuv — я говорил про общий подход, а не про конкретную реализацию асинхронного ввода-вывода.
> Однопоточные серверные приложения не нужны.
Почему? Чем вам не угодили, например, однопоточные, но многопроцессные серверные приложения, например?
> Странный вопрос. Используйте что хотите :) Я предпочитаю browserify, например ;)
> …
Я имел ввиду что не понимаю стенаний по-поводу того что использовать: AMD, CJS, RequireJS или ES6. Что вы конкретно хотели этим сказать?
> Язык практически не менялся годами. Там forEach был не сразу. Только в es6 начал приобретать человеческий вид.
Он начал развиваться вместе с бумом веб-приложений середины двухтысячных. Когда появилась необходимость в более продвинутых инструментах — появился и новый стандарт. Ничего необычного.
> Что мне использовать? AMD? RequireJS? CJS? Или же модули из es6?
Странный вопрос. Используйте что хотите :) Я предпочитаю browserify, например ;)
Я не утверждаю что JavaScript — идеальный. Просто это язык который вымучен и создан практикой и все вещи которые в нем появились — появились из практических соображений. А асинхронная природа, которая появилась как раз в результате создания «на коленке» пришлась очень кстати при написании серверных приложений.
А что конкретно было плохо? Я, например, как-то к Promise прикипел и пишу асинхронный код абсолютно спокойно, без всякой странной магии, которую предлагает IcedCoffee, типа
awaitиdefer.Странный какой-то вопрос. Это полноценный, стандартизированный язык высокого уровня, на котором можно с успехом писать (и пишут ведь, и много) server-side и desktop-приложения. JavaScript никоим образом ни разу не заточен на «манипуляции с веб-страничками»: ни по стандарту, ни по архитектуре.
итог будет иметь тип
Tuple2[Tuple2[T, U], S]А есть ли элегантный способ сделать так чтобы тип был
Tuple3[T, U, S]?Для обычных объектов, разумеется, нет. Хотя для примера из вашего комментария можно соорудить что-то вроде этого:
Но это уже легкий изврат :)
Я в таких случаях предпочитаю писать более прямой и понятный код. По крайней мере поведение _.filter в данном случае мне кажется не совсем очевидным, поскольку фильтрующая функция применяется к значениям, а не к ключам объекта или хотя бы к парам [ключ, значение]. Но это ИМХО, конечно.