Это вы красиво записали увольнение в "одномоментную потерю выгоды". Потеря работы может принести вполне реальные долгосрочные негативные последствия не для абстрактных "будущих поколений", а для вполне конкретных детей вполне конкретного человека, который эту работу потерял. На детей требуется вполне немаленькая сумма денег. При этом задача "найти работу" будет уже куда сложнее, ведь про человека будет известно, что он "политический", а значит проблемный.
Как обычно, быть "за всё хорошее и против всего плохого" в теории несложно, а вот с практикой уже все не так однозначно.
Потому что получившийся "объект" ведет себя не как множество. На нем не задано отношение принадлежности. Но мы его можем мыслить как функцию, которая результатом будет иметь множество.
Не буду обсуждать смысл создания локализованной несовместимой версии языка, для которой примеров днем с огнем не найдешь. Но замечу, что лучше на китайский переводить. На порядок более массовый продукт будет. Даже если пользоваться будет примерно такая же доля носителей языка, то просто за счет количества.
SQL был мною предложен как простая и понятная аналогия, с которой большинство встречалось. Просто как некое представление о порядке сложности задачи.
GraphQL, конечно же, не SQL, это скорее это развитие NoSQL трендов последних лет. Если SQL строился как язык для реляционных данных, то GraphQL создавался как язык запросов к графам объектов. И это не учитывая того, что у них совершенно разный синтаксис. Так что бэкенд вам понадобится хотя бы для перевода одного в другое.
Другое дело, что бэкенд, даже в простейшем случае CRUD операций, может быть точкой сопряжения огромного чила разных баз данных, хранилищ данных, внешних сервисов. Сейчас многие типичные проекты имеют одну или более базу данных, кеш (а то и не один), выделенные процессы, выполняющие долговременные операции (по запросу или по расписанию), подключения к нескольким внешним сервисам. Всем это хочется управлять, так сказать, на своей территории, не отдавая наружу (во фронтенд) лишнего.
Например, если сказать, что взвод окопался, то понятно, что в данном контексте речь идет о системе взвод, рассматриваемом нами как объект. Если же сказать, что взвод состоит из 20 бойцов, то речь идет о взводе, который рассматривается нами как множество объектов. При этом первое значение термина «взвод» никак не связано со вторым значением того же слова «взвод».
А если сказать, что состоящий из 20 бойцов взвод окопался, то у нас появится невозможная химера, которая ведет себя как непримиримые противоположности?
Дело может быть в войне громкости. Дополнительно обработка для компакт-дисков вполне может привести (и часто приводит) к ухудшению звука по сравнению с винилом (хотя казалось бы)
Тут все еще несколько хитрее. Глобальная область видимости — это поля глобального объекта, в данном случае window. Однако же localFoo не принадлежит window, это просто локально объявленная константа. Вот пример того, как мы радостно дали эту функцию другому объекту (это ровно одна и та же функция, нужно заметить), а this снова поменялся.
this внутри функции сам по себе по умолчанию не привязан к определенному объекту, а определяется способом вызова.
Т.е. если мы вызываем функцию как метод (obj.foo()), то this будет определен как объект, содержащий поле. Но если мы вызываем функцию как функцию, то такого объекта, очевидно, нет. Но javascript в данном случае нам просто радостно подставляет глобальный объект. Это особенно раздражает в случае если передавать метод как callback. Но напрямую это сделать нельзя (this потеряется), его нужно каким-то образом привязать к правильному объекту.
С другой стороны это позволяет делать многие вещи, которые напрямую невозможны в других языках. Например, мы можем передать функцию, которая затем будет вызвана как метод другого объекта (на этом половина jQuery построена).
Нет, не равноценно. fn — локальное, оно видно только внутри блока, в котором объявленно. В случае консоли, оно, конечно, будет глобальным. Вот пример с локальной областью видимости.
Так я об архитектурных абстракциях и забочусь, чтобы они были правильные, удобные и не протекали. И если какая-то абстракция в программировании при проверке реальностью оказывается плохой, то нужно отказываться от абстракции, а не от реальности.
Вот где вы проводите границу между этими модулями? Года, например, вы включили в модуль дат, хотя они, очевидно, существенно зависят от календаря. А вот, скажем, недели вас не устроили, хотя они не зависят от календаря.
Более того, как вы определяете дату, если "число единиц времени с начала отсчёта" вас не устраивает? Хотя это единственный способ определить дату так, чтобы не привязаться к какому-то календарю.
Нельзя, там надо e-mail, и его верификация, скорее всего.
Зачем? Вся инфа идет уже из вашего аккаунта, доступ к которому вы сами и разрешите. Сейчас как-раз регистрацию через email сложнее встретить, чем через социалки.
Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".
В вашей статистике учтено, что большая часть сектора ИТ сосредоточена в крупных городах с большим доходом, чем в целом по стране?
Это налоги для юридических лиц, что несколько отличается от налогов для физических лиц
Это вы красиво записали увольнение в "одномоментную потерю выгоды". Потеря работы может принести вполне реальные долгосрочные негативные последствия не для абстрактных "будущих поколений", а для вполне конкретных детей вполне конкретного человека, который эту работу потерял. На детей требуется вполне немаленькая сумма денег. При этом задача "найти работу" будет уже куда сложнее, ведь про человека будет известно, что он "политический", а значит проблемный.
Как обычно, быть "за всё хорошее и против всего плохого" в теории несложно, а вот с практикой уже все не так однозначно.
Потому что получившийся "объект" ведет себя не как множество. На нем не задано отношение принадлежности. Но мы его можем мыслить как функцию, которая результатом будет иметь множество.
Не буду обсуждать смысл создания локализованной несовместимой версии языка, для которой примеров днем с огнем не найдешь. Но замечу, что лучше на китайский переводить. На порядок более массовый продукт будет. Даже если пользоваться будет примерно такая же доля носителей языка, то просто за счет количества.
SQL был мною предложен как простая и понятная аналогия, с которой большинство встречалось. Просто как некое представление о порядке сложности задачи.
GraphQL, конечно же, не SQL, это скорее это развитие NoSQL трендов последних лет. Если SQL строился как язык для реляционных данных, то GraphQL создавался как язык запросов к графам объектов. И это не учитывая того, что у них совершенно разный синтаксис. Так что бэкенд вам понадобится хотя бы для перевода одного в другое.
Другое дело, что бэкенд, даже в простейшем случае CRUD операций, может быть точкой сопряжения огромного чила разных баз данных, хранилищ данных, внешних сервисов. Сейчас многие типичные проекты имеют одну или более базу данных, кеш (а то и не один), выделенные процессы, выполняющие долговременные операции (по запросу или по расписанию), подключения к нескольким внешним сервисам. Всем это хочется управлять, так сказать, на своей территории, не отдавая наружу (во фронтенд) лишнего.
Боюсь вас расстраивать, но это перевод, а название придумал кто-то в недрах MS
Это у вас получается классическое трио
А он не должен вас смущать. Вы должны сразу понимать, что GraphQL — это
БОЛЬязык для составления запросов. Со всей добавленной головной болью.Просто представьте, что ваш сервер должен предоставлять SQL-доступ к вашим данным.
А где вы увидели динамические касты? О_о
С вероятностью 90% у физической модели ящика нет стенок. Это сплошной куб
А если сказать, что состоящий из 20 бойцов взвод окопался, то у нас появится невозможная химера, которая ведет себя как непримиримые противоположности?
Это транслитерация с английского: https://en.wikipedia.org/wiki/Valleytronics
Дело может быть в войне громкости. Дополнительно обработка для компакт-дисков вполне может привести (и часто приводит) к ухудшению звука по сравнению с винилом (хотя казалось бы)
Тут все еще несколько хитрее. Глобальная область видимости — это поля глобального объекта, в данном случае window. Однако же localFoo не принадлежит window, это просто локально объявленная константа. Вот пример того, как мы радостно дали эту функцию другому объекту (это ровно одна и та же функция, нужно заметить), а this снова поменялся.
this внутри функции сам по себе по умолчанию не привязан к определенному объекту, а определяется способом вызова.
Т.е. если мы вызываем функцию как метод (obj.foo()), то this будет определен как объект, содержащий поле. Но если мы вызываем функцию как функцию, то такого объекта, очевидно, нет. Но javascript в данном случае нам просто радостно подставляет глобальный объект. Это особенно раздражает в случае если передавать метод как callback. Но напрямую это сделать нельзя (this потеряется), его нужно каким-то образом привязать к правильному объекту.
С другой стороны это позволяет делать многие вещи, которые напрямую невозможны в других языках. Например, мы можем передать функцию, которая затем будет вызвана как метод другого объекта (на этом половина jQuery построена).
Нет, не равноценно. fn — локальное, оно видно только внутри блока, в котором объявленно. В случае консоли, оно, конечно, будет глобальным. Вот пример с локальной областью видимости.
С this все плохо, оно определяется способом вызова (про связанные функции не будем вспоминать)
Перечитал ваш комментарий, признаю, неправильно вас понял
Так я об архитектурных абстракциях и забочусь, чтобы они были правильные, удобные и не протекали. И если какая-то абстракция в программировании при проверке реальностью оказывается плохой, то нужно отказываться от абстракции, а не от реальности.
Вот где вы проводите границу между этими модулями? Года, например, вы включили в модуль дат, хотя они, очевидно, существенно зависят от календаря. А вот, скажем, недели вас не устроили, хотя они не зависят от календаря.
Более того, как вы определяете дату, если "число единиц времени с начала отсчёта" вас не устраивает? Хотя это единственный способ определить дату так, чтобы не привязаться к какому-то календарю.
Зачем? Вся инфа идет уже из вашего аккаунта, доступ к которому вы сами и разрешите. Сейчас как-раз регистрацию через email сложнее встретить, чем через социалки.
Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".