func

\0

так это

будет ответ, или таки ro?

Почему это недостаток-то?

о недостатках, которые мы не можем исправить, лучше молчать

не согласен, я надеюсь заразить своим мнением других людей и набрав критическую массу заставить пайка в го 2.0 сделать человеческий for ... in ...!

не согласен, я надеюсь заразить своим мнением других людей и набрав критическую массу заставить пайка в го 2.0 сделать человеческий for ... in ...!

Ты так ничего и не обосновал.

и что?

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

не согласен, я надеюсь заразить своим мнением других людей и набрав критическую массу заставить пайка в го 2.0 сделать человеческий for ... in ...!

Не нравится - для тебя есть другие языки

а мне по кайфу range

А можешь обосновать - вот это хотя бы будет интереснее

а мне по кайфу range

Плюсую

for i in a vs for i := range a

какая запись короче ?

причем тут короче, дядь?

какая запись семантически понятнее ?

:= визуально разделяет блоки слева, и справа

какая запись семантически понятнее ?

Range

Ясен пень

:= визуально разделяет блоки слева, и справа

при чем тут разделение ?

при чем тут разделение ?

Ты сам поднял вопрос семантики

давайте ещё жабоскрипт вспомним, а ? a.each((i, v) => {})

коротко?

давайте ещё жабоскрипт вспомним, а ? a.each((i, v) => {})

Или map

Но там есть for in

давайте ещё жабоскрипт вспомним, а ? a.each((i, v) => {})

ну кстати шутки шутками, а немножко функциональщины иногда действительно не хватает

давайте ещё жабоскрипт вспомним, а ? a.each((i, v) => {})

forEach

ну кстати шутки шутками, а немножко функциональщины иногда действительно не хватает

ну это пока пишешь

Который в неумелых руках бывает и в ногу стреляет

Или map

А что не так с map?

Range

для i назначить диапазон a vs для i из a что вы выбираете ?

forEach

Нэт. [].prototype.each = [].prototype.forEach

шах и мат

А что не так с map?

А я не говорил, что не так. Мне в целом нравится es6 в том виде, в котором он получился

Нэт. [].prototype.each = [].prototype.forEach

так делают только говнокодеры

ну это пока пишешь

Пока читаешь - не хватает ещё больше. Императивную лапшу же читать невозможно, особенно, когда проект немаленький.

это уже другой вопрос

для i назначить диапазон a vs для i из a что вы выбираете ?

i в диапазоне a, естественно

i в диапазоне a, естественно

нет там предлога в

нет там предлога в

:=

Пока читаешь - не хватает ещё больше. Императивную лапшу же читать невозможно, особенно, когда проект немаленький.

дай возможность, и люди понапишут лапши из функциональщины и ад из коллбеков.

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

а если зарплата вам жить не позволит - тогда не живите, никто не неволит

дай возможность, и люди понапишут лапши из функциональщины и ад из коллбеков.

Async await!

Пока что обоснования я так и не увидел

дай возможность, и люди понапишут лапши из функциональщины и ад из коллбеков.

Ад из коллбэков - атрибут императивной асинхронщины.

дай возможность, и люди понапишут лапши из функциональщины и ад из коллбеков.

лапша лашпой, а аналог даже .map(x => x ^ 2) на циклах и вправду пострашнее выглядит)

да ладно, чего пристали к человеку, ну не нравится ему синтаксис и бог с ним :)

Обсирает - пусть отвечает

коллеги

сворачивайтесь

Пока что обоснования я так и не увидел

более простая семантика и краткость не подойдут ? ну тогда вас ничем не убедить

лапша лашпой, а аналог даже .map(x => x ^ 2) на циклах и вправду пострашнее выглядит)

во-первых, как часто вы пишите .map(x => x ^ 2). а во-вторых, я согласен что это красиво и удобно, если ограничить такую конструкцию 20 символами. Реалии таковы, что в жизни вы такие короткие строчки будете видеть в разы реже, чем коллбеки на 10-15 строк.

дай возможность, и люди понапишут лапши из функциональщины и ад из коллбеков.

Да, только всякая функциональщина дает все возможности, чтобы писать не лапшу. Всякие C и Go же не дают, потому-что абстракции это, видите ли, сложно, студенты не поймут

короче, строгость - благо. гибкость - бардак и хаос.

Enough

короче, строгость - благо. гибкость - бардак и хаос.

Но у го нету ни строгости, ни гибкости.

товарищи нас сейчас палкой будут пиздить, давайте перекочуем во флудильню

короткие имена для деталей реализации. Все равно они могут быть в любой момент отрефакторены и их всегда можно переименовать. Длинные имена - для внешнего API

Но у го нету ни строгости, ни гибкости.

+

товарищи нас сейчас палкой будут пиздить, давайте перекочуем во флудильню

Почему будут? Я уже

Почему будут? Я уже

значит я пока успешно уклоняюсь

короткие имена для деталей реализации. Все равно они могут быть в любой момент отрефакторены и их всегда можно переименовать. Длинные имена - для внешнего API

а вот например в драйвере монги самом популярном сейчас коллекцию на базе получаешь таким образом : db.C("users"). Метод с названием "C"(читай Collection) - зло?)

а вот например в драйвере монги самом популярном сейчас коллекцию на базе получаешь таким образом : db.C("users"). Метод с названием "C"(читай Collection) - зло?)

В публичном апи? Да

это в публичном апи, кроме шуток

Ну вот я и ответил)

ERROR: S client not available

https://godoc.org/gopkg.in/mgo.v2#Database.C

можно было бы и DropDatabase() error сделать D() error

чего уж там

во-первых, как часто вы пишите .map(x => x ^ 2). а во-вторых, я согласен что это красиво и удобно, если ограничить такую конструкцию 20 символами. Реалии таковы, что в жизни вы такие короткие строчки будете видеть в разы реже, чем коллбеки на 10-15 строк.

> во-первых, как часто вы пишите .map(x => dosmth(x)) не поверишь, через строку пишу а иногда и chain call делаю ("иногда" сарказм конеш, постоянно) .map(...).filter(...).dispatch(...).join_by(...)

пруфайте кодом

> во-первых, как часто вы пишите .map(x => dosmth(x)) не поверишь, через строку пишу а иногда и chain call делаю ("иногда" сарказм конеш, постоянно) .map(...).filter(...).dispatch(...).join_by(...)

ССЗБ

у вас или какой-то хардкор с данными, или какие-то проблемы с ними

ССЗБ

пфф, а почему злобный буратино? лучше когда Filter(Map(..., ..., ...), ... , ...) ?

я о том, что ты постоянно делаешь цепочки

хз, они просто понятнее циклов, в которых нужно перебрать все элементы

пишутся короче, с индексами не паришься и всякое такое

в го же есть аналоги в виде Filter() и Map() и ещё что-то там

давайте ещё жабоскрипт вспомним, а ? a.each((i, v) => {})

a.forEach(e => do(e)) но можно и a.map((e, i, arr) => do(e, i, arr))

мапы, фильтры и т.д. в js мне нравится, да, но по опыту - хорошо спроектированное апи чаще всего не требует таких цепочек

мапы, фильтры и т.д. в js мне нравится, да, но по опыту - хорошо спроектированное апи чаще всего не требует таких цепочек

> хорошо спроектированное апи чаще всего не требует таких цепочек спорное утверждение

a.forEach(e => do(e)) но можно и a.map((e, i, arr) => do(e, i, arr))

Так .map использовать нельзя (на самом деле можно в JS, но семантика у него другая)

мапы, фильтры и т.д. в js мне нравится, да, но по опыту - хорошо спроектированное апи чаще всего не требует таких цепочек

чет бред

a.forEach(e => do(e)) но можно и a.map((e, i, arr) => do(e, i, arr))

.map и .forEach выполняют разные вещи

чет бред

пруфай тогда

мой опыт это однозначно дал понять

Так .map использовать нельзя (на самом деле можно в JS, но семантика у него другая)

че? можно

пруфай тогда

почему это не требует? да и вообще это разные подходы

пруфай тогда

Так твое утверждение, ты и пруфай

Так .map использовать нельзя (на самом деле можно в JS, но семантика у него другая)

единственная разница — forEach просто для каждого делает, map — вернет

мапы, фильтры и т.д. в js мне нравится, да, но по опыту - хорошо спроектированное апи чаще всего не требует таких цепочек

Даже простой бизнес пример, взять коллекцию Person и составить список номеров телефонов/имен. Етц. Можно делать лениво и пагинацию делать уже в другом месте

> хорошо спроектированное апи чаще всего не требует таких цепочек спорное утверждение

так можно сказать, что не нужны .map, .filter, .find и прочее так как можно всё выразить через .reduce

Народ кто нить работал с JWT

Народ кто нить работал с JWT

кто-нибудь работал.

пруфай тогда

ну например, разбор десерелизированного html html_dom.select_all( /* выбираем все теги X */) .filter( /* говорим, что у Х должен быть class=Y */ ) .map( /* convert inner value to struct */ )

так можно сказать, что не нужны .map, .filter, .find и прочее так как можно всё выразить через .reduce

Его идея это через цикл выражать

Его идея это через цикл выражать

императивщина vs. функциональный подход