Если серьёзно, ни разу не видел термин wrangling в применении к данным — cleaning, cleansing, scrubbing и т.п.
По всей видимости, придумывание необычных терминов — это что-то от маркетологов :)
Ну всё, теперь понял.
Я написал не о распараллеливании функции (внутри), а о распараллеливании выполнения нескольких функций.
Если порядок выполнения не важен, то их можно выполнять параллельно (в контексте нашей беседы — map).
Про распараллеливание кода foldа речи не было.
Здесь действительно может быть возможность параллелизации, а может и не быть.
Добавлю gbg
Как правило, в коде ФП есть требование чистых функций, то есть, без побочных эффектов.
Порядок их выполнения не важен (в отличие от объектов, сохраняющих состояние), поэтому выполнение легко распараллелить или поменять местами их время выполнения.
Ну да, просто насколько хороша по смыслу эта игра — сразу понятно чем может похвастаться это приложение.
А ещё если приглядеться, то между bulldozer и buildozer в типографике всего одна маленькая белая точка
На Гитхабе в Settings
Necessary changes in the configuration of the multiplexer can be made in the configuration file config.go
ссылка с config.go ведёт в никуда.
Не могу назвать себя впечатлительным, но что-то поймал себя на ощущении, что хочется почесаться :)
Может на КДПВ лучше солдатика?
А милаху под спойлер?
И вообще лучше бы добавить фотографий симпатичной коллеги.
Разве Вы читали не внимательно?
Грэм как раз не делал ненужных обобщений — он явно указал, что есть приложения, которые не стоит делать server-based.
А чего Вы так за апплеты-то переживаете?
О них он вроде бы тоже ничего крамольного не сказал.
Перечитал.
Server-based — это синоним «клиент-серверные с тонким клиентом».
Java-апплеты были придуманы для клиента потолще, но всё равно в клиент-серверной парадигме.
Иначе проще скачать приложение (любым способом и протоколом) и запустить как обычное Java-приложение.
Апплеты за очень редким исключением запускались из браузера и из его процесса, что было их недостатком в случае апплета с собственным окном — пользователи закрывали браузер после запуска апплета, и апплет закрывался вместе с ним.
В этой статье Грэм продвигает Server-based computing в противопоставление standalone приложениям. Из всех его доводов это прозрачно видно. Что касается апплетов в этом разрезе, то история с практической стороны показала какое место они получили в компьютерной индустрии.
Расшифруйте, пожалуйста.
Потому что я помню как они появились, и как тогда на русский их переводили как «приложеньица», потому что были очень легковесными — читай использовались как лёгкий фронтенд для технологии «клиент-сервер».
Смысл в том, что они должны были применяться только как интерфейс к серверным приложениям (в отрыве от них не имеют смысла — не считая всяких анимированных часиков и прочих поделок).
Так что апплеты — технология для [клиент-]серверных приложений.
Это совсем не означает, что они работают именно на сервере, а означает, что они не предназначены для разработки standalone приложений.
Вот с data munging, которое в wikipedia ставится синонимом data wrangling, сталкивался.
Если серьёзно, ни разу не видел термин wrangling в применении к данным — cleaning, cleansing, scrubbing и т.п.
По всей видимости, придумывание необычных терминов — это что-то от маркетологов :)
Я написал не о распараллеливании функции (внутри), а о распараллеливании выполнения нескольких функций.
Если порядок выполнения не важен, то их можно выполнять параллельно (в контексте нашей беседы — map).
Про распараллеливание кода foldа речи не было.
Здесь действительно может быть возможность параллелизации, а может и не быть.
Или я совсем не понял последний вопрос — что такое что-то ассоциативное?
Как правило, в коде ФП есть требование чистых функций, то есть, без побочных эффектов.
Порядок их выполнения не важен (в отличие от объектов, сохраняющих состояние), поэтому выполнение легко распараллелить или поменять местами их время выполнения.
А ещё если приглядеться, то между bulldozer и buildozer в типографике всего одна маленькая белая точка
На SO качество ответов и кода значительно выше.
Хотя чужой код никогда не вставлял — побаиваюсь :)
Settings
Necessary changes in the configuration of the multiplexer can be made in the configuration file config.go
ссылка с config.go ведёт в никуда.
Но это не помогло :)
Может на КДПВ лучше солдатика?
А милаху под спойлер?
И вообще лучше бы добавить фотографий симпатичной коллеги.
Сама статья отлична — кратко и по делу.
Спасибо!
И чем оно отличается от клиент-серверного.
Грэм как раз не делал ненужных обобщений — он явно указал, что есть приложения, которые не стоит делать server-based.
А чего Вы так за апплеты-то переживаете?
О них он вроде бы тоже ничего крамольного не сказал.
Server-based — это синоним «клиент-серверные с тонким клиентом».
Java-апплеты были придуманы для клиента потолще, но всё равно в клиент-серверной парадигме.
Иначе проще скачать приложение (любым способом и протоколом) и запустить как обычное Java-приложение.
Апплеты за очень редким исключением запускались из браузера и из его процесса, что было их недостатком в случае апплета с собственным окном — пользователи закрывали браузер после запуска апплета, и апплет закрывался вместе с ним.
В этой статье Грэм продвигает Server-based computing в противопоставление standalone приложениям. Из всех его доводов это прозрачно видно. Что касается апплетов в этом разрезе, то история с практической стороны показала какое место они получили в компьютерной индустрии.
Потому что я помню как они появились, и как тогда на русский их переводили как «приложеньица», потому что были очень легковесными — читай использовались как лёгкий фронтенд для технологии «клиент-сервер».
Смысл в том, что они должны были применяться только как интерфейс к серверным приложениям (в отрыве от них не имеют смысла — не считая всяких анимированных часиков и прочих поделок).
Так что апплеты — технология для [клиент-]серверных приложений.
Это совсем не означает, что они работают именно на сервере, а означает, что они не предназначены для разработки standalone приложений.
The Other Road Ahead