FireGM:
А) Статическая типизация.
Б) Никто не говорит что нужно использовать инструменты Go. Я назвал вариант с Clojure в качества хоста/кодогенератора
В) Есть забавная мысль, что f(a,b) сложнее чем f(a)(b). Кодогенерация, это, фактически, частичное исполнение.
Не говоря о том, что лимитов у неё вообще нет. (Можно параллельно генерировать тесты, вьюхи и стили, например)
copal: Например, рабочая модель скрапера есть. Фактически скромное дерево селекторов и соответствующих полей разворачивается в многопоточный статически типизированный скрапер с поддержкой нескольких бекендов и красивой админкой.
-----
Задача моделирования сайта сложнее, поэтому я испрашиваю совета
Забыл упомянуть. Если вы говорите в контексте lazy loading pagination, то это не подходит.
Нужна честная навигация в N элементах в том объеме который не держит браузер.
Lazy loading, я понимаю как тупое добавление нового чанка даты в конец списка по событию конца скролла.
Что до описываемого вами кейса с прокруткой из начала в конец - если мы резко переходим - это будет один запрос.
----
Простите, каким образом?
У нас в каждый момент скролла есть некоторое окно с текущими элементами.
Если мы проскроллили в конец( или, в любую другую точку), это означает, что это окно было отрендерено N/M (где M индекс элемета, N размер страницы) раз, пусть и очень быстро(например, плейсхолдерами).
Я нашел следующее решение. Допустим мы прокрутили к X и остановились(нет скролла N миллисекунд), достать все индексы X-10..X и запросить дату. В случае если скролл продолжился, то запрос нужно как-то прервать(открытый вопрос)
Ваше решение с чанками я не понял, поясните пожалуйста.
Пожалуйста. ИМХО, а какая разница. Все, более менее развитое, имеет хорошие библиотеки(Java/Python). Ну а сами эти методы по feature extraction вполне и ручками делаются за 15 минут(кроме стеммера и POS теггера).
No offence.
Но, во первых от языка это не зависит.
А во вторых тут есть два других ответа которые повторяют туже ошибку.
Contains по значению на массиве будет O(N) и его надо избегать как чумы, по идее...
Доброго. Сначала показалось что нашел(декомпилинг chrome speech recognition api). Но там все тоже мутно. (Например, лимит в 60 секунд, и 50 запросов в сутки, без возможности заплатить/увеличить). Сейчас изучаю микрософтовский проект Оксфорд: https://www.projectoxford.ai/speech Они по крайней мере не м***ки. С прайсом и требованиями все понятно.
Простите, но у вас несколько в кучу намешано всего. :
---------
Во первых: Sass Less Coffescript и TypeScript не могут быть в одной категории. Как не могут быть синтаксический сахар, шаблонизаторы и полноценная система типов.
----------
Фреймворки: Вы забыли React. А он, судя по всему скоро скушает ангуляр и не подавится.
---------
Во третьих, Алгоритмы: Две категории, да еще и самые распространенные, да еще и никак не связанные друг с другом.
Вы бы упомянули хоть анализ сложности алгоритмов. Способы оптимизации сложности. Ну, и категории хоть по интересней: методы оптимизации, supervised-unsupervised learning, clustering, какие нибудь вероятностные вещи, вроде тех же байесовых сетей.
----------
Вы забыли структуры данных. Интересные: Вероятностные множества, LSH хеши. Скучные: красно-черные/бинарные/префиксные деревья...
----------
И.т.д. и.т.п.
Я бы ваш список исправил.
А) Статическая типизация.
Б) Никто не говорит что нужно использовать инструменты Go. Я назвал вариант с Clojure в качества хоста/кодогенератора
В) Есть забавная мысль, что f(a,b) сложнее чем f(a)(b). Кодогенерация, это, фактически, частичное исполнение.
Не говоря о том, что лимитов у неё вообще нет. (Можно параллельно генерировать тесты, вьюхи и стили, например)