Далеко не всегда можно получить всю нужную инфу одним sql запросом, даже если не стесняться использовать джоины направо и налево. К примеру, это интернет магазин. Нужно и профиль юзера получить, и корзину его товаров, и категории товаров, и подробная информация об одном товаре, и список схожих товаров, и путь от главной страницы до определенного товара — категория, подкатегории, и тд.
Асинхронно это реализовывать на nodejs довольно бесяче (особенно раньше, на колбеках), но очень производительно — когда один запрос ожидает ответа от внешнего сервиса — бд, кеша или еще чего — другой исполняется.
Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.
А ведь решение простое — пусть компилятор компилирует, а линтер проверяет на все эти неиспользуемые переменные. По отдельности. Или флаг какой-нибудь ввести, чтобы управлять поведением компилятора. Но нет, разработчики языка же самые умные, давайте мол, заставим всех писать так, а не иначе.
На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
Именно. Если не знать руби, то так оно и выглядит.
В каком-нибудь javascript'e
function b() { return 42; }
a(b)
и
function b() { return 42; }
a(b())
означают совершенно разную логику. В первом случае мы в функцию а передали функцию б, которую можно будет вызвать внутри этой функции а. Во втором случае мы вызвали функцию б и результаты ее выполнения передали в функцию а.
Но в руби
def b
42
end
a(b)
и
def b
42
end
a(b())
и
b = 42
a(b)
по результатам выполнения означают одно и то же. В первом случае мы вызвали функцию б, результаты ее выполнения передали в функцию а (не смотря на отсутствие скобок, это все равно вызов функции, а не ее передача в другую функцию). Во втором случае — то же самое. В третьем — мы вручную присвоили переменной данные и передали их в функцию а. В итоге, во всех трех случаях, на вход в функцию а поступит число 42.
Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.
Когда начинаешь этим пользоваться, понимаешь, насколько это удобно — когда «a» может быть хоть переменной, хоть функцией, и тебе на это плевать.
Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
@user = User.create(create_params)
create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
@user = User.create(create_params())
Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?
А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Если этот программер, сын маминой подруги, которого не уволить, похерил работу команды за всю неделю и в ус не дует, то эти слова тоже будут не совсем неадекватны?
То есть вы осознанно нанимаете джуниора под видом сеньора, даете ему сеньорские таски, а потом ему же начинаете претензии предъявлять, что он не сеньор? Божественная логика. Осталось только с позором уволить уборщицу из-за багов в продакшене, с таким-то подходом.
Опять же. Ну допустим, обматерите вы его. И что, после этого ровно в полночь он превратится в тыкву в сеньора? Вам тогда стоит курсы повышения квалификации открывать — заходит студент в кабинет, 15 минут криков, выходит крутой специалист.
Понятное дело, что устраиваясь работать программистом, я не буду мыть полы или, к примеру, исполнять обязанности бухгалтера — не те обязательства я на себя беру.
Но ведь и писать код можно по-разному. Можно это делать «на отвали». К примеру, менеджеры обычно довольно посредственно ориентируются в архитектуре ПО. И если сегодня исполнить таску как она поставлена — завтра надо будет что-то переделать. Зато не надо думать и нагружать себя — сделал что сказали и ушел домой.
Но можно ведь и по-другому. Можно первым начать разговор, мол, «вот смотри, такая-то логика приведет к таким-то последствиям в дальнейшем, придется делать вот это — ты уверен, что нам это нужно, может лучше сделать вот эдак?» Но это отнимает дополнительное время, хоть и полезно бизнесу — вместо этого можно ведь хабр почитать или там на гитхабе что интересного поискать — ведь формально от работника требуется кодить, а не думать как будет лучше бизнесу.
Какие-то философские (читай — глупые) рассуждения в статье.
Если вы можете себе позволить лежать целый год на печи и плевать в потолок — вперед. Какая еще социальная ответственность? Да вас в пример будут приводить другим людям — вот мол, смотрите, какой молодец мой %set_name%. А ваш %another_name% горбатится на трех работах, дома не бывает, а вы еще и впроголодь живете.
Когда вы устраиваетесь на работу, вы по сути заключаете долговременную сделку купли-продажи — продаете свое время. Точнее даже не просто время, а свои навыко-часы или навыко-месяцы. Всякие стенания «ах, это рабство», «а жить когда?», «работнику не должно быть дела до бизнеса» — какой-то инфантилизм, если честно. Нормальный человек будет стараться исполнять свои обязательства по духу, а не по букве, и будет требовать от окружающих людей того же. Если вы продали 5 часов своей жизни бизнесу — то ожидается, что вы потратите это время на пользу бизнеса, а не на личную пользу. То же ожидается и от бизнеса — оговоренного вознаграждения без проволочек и комфортной обстановки. Владельцу бизнеса может и выгодна бюрократия, лишение премий, невразумительные метрики для штрафов, кидание с зарплатой и прочее, но ожидается, что он так же добросовестно, как и работник, будет выполнять свои обязательства.
Если я хочу использовать какую-то новую, еще незнакомую мне технологию в проекте — я честно говорю об этом. Мы оцениваем риски и возможности, и решаем, можем ли мы себе это позволить. В конечном счете новый опыт полезен не только мне — более квалифицированный разработчик принесет бизнесу больше пользы. Но вот делать это втихомолку, плюя на свои обязательства, занимаясь лишь самообразованием, а «после нас хоть потоп» — это уже саботаж какой-то.
Обыватель, прочитав такую крутую статью без очернения, загорается идеей. Заходит в интернет, гуглит, натыкается на сайт с чудо-таблеткой из сахара всего лишь за 999.90, покупает её за много денег, пьет по утрам перед едой и твердо уверен, что будет теперь жить на 100500 лет дольше.
Чем это поможет ученым?
Научные работы сложные. Чтобы их просто прочитать, требуется как минимум знать английский, плюс иметь понимание о научном методе и о том, какие требования нужно соблюдать при проведении эксперимента. Плюс он должен уметь отличать научную работу от журналистского «высера». Плюс хотя бы чуть-чуть в биологии шарить.
Я, хоть и не считаю себя обычным обывателем, не уверен что смогу вот так просто отличить зерна от плевел, без того, чтобы потратить пару-тройку суток на изучение отдельно взятой научной статьи. Если у вас есть способ, который позволит простому человеку совершенно без раздумий правильно отличать отличать одно от другого — поделитесь им. Потому что не будет обычный человек тратить десятки часов на это, он либо даст деньги сразу, либо развернется и уйдет.
Ну как бы это разные каналы. Если мы объединяем в один тип SMS, Email и Websocket, то с тем же успехом можно объединить в один тип строку, число и булево значение — всё это данные. Только зачем тогда вообще типы нужны, если мы их все приводим к одному супертипу?
UPDATE Мне в этом смысле golang нравится — есть структуры (типы), а есть интерфейсы (поведение). В итоге разные структуры (SMS, Email и Websocket) реализовывают одно и то же поведение — отправку сообщения.
Для начала следует собрать уже существующее — это легче, чем писать новое. В целом, практически все книги и статьи о положительном бессмертии пишутся трансгуманистами, от этого надо и отталкиваться. Да и в принципе можно просто постараться популяризовать идею трансгуманизма lesswrong.ru/w/Трансгуманизм_как_упрощенный_гуманизм
Я порекомендовал бы книжку «Гарри Поттер и Методы Рационального Мышления». Там есть сцены обсуждения этой проблемы между двумя сторонами — «смерть — это хорошо» и «смерть — это плохо», с достаточно хорошими аргументами обеих сторон.
Ну пожертвуете вы каким-то жуликам с улицы в «фонд исследований продления жизни», думаете это реально приблизит светлое будущее?)
Нужно хоть немного разбираться в вопросе для совершения эффективных действий. А то получится как в финансах — форекс конторы полностью дискредитировали настоящие биржи в глазах простого населения в странах бывшего союза. Вы хотите подложить ту же свинью для идеи бессмертия? Спасибо, нам такого не надо.
Честно скажу, что увлекали частые новости о «гигантских прорывах» в борьбе со старением, «прививки вечной жизни» и т.п. А сейчас вижу, что всё очень и очень даже не просто. Если не сказать, что абсолютно сложно.
Говоря, что этот комментарий ложный, вы подразумеваете, что в борьбе со старением все очень даже просто? Это откровенная ложь — иначе бы уже запатентовали «лекарство от старости» и продавали бы его за 100500 денег.
Ну знаете ли, если вы сталкиваетесь только с теми задачами, которые уже решали ранее, ничего не мешает писать сразу правильно и быстро — тут даже прототип будет вполне качественный уже с первой версии.
Только вот это скучно, а программисты в большинстве своем — народ, который не любит несколько раз делать одно и то же, а любит делать что-то новое. Поэтому, к примеру, и меняют места работы каждую пару лет — перерос существующее, пора искать более сложное. Вот и получается, что почти в каждом проекте есть неизвестный кусок — новая технология, новый подход, новые требования, и тд.
Допустим, есть опросник. На некоторые пункты юзер отвечает текстом, на другие — числом, еще один — выбор нескольких вариантов из перечисленных, и вдогонку еще и фотографии может прикрепить.
Вам нужно сделать фронт-админку для этого. Вы отправляете на бек запрос с айдишником опроса, в ответ от присылает вам всё что заполнил юзер — массив из данных разных типов. Вы каждый раз получаете следующий элемент этого массива — цикл по сути, в js это можно сделать функцией forEach() — и оно возвращает каждый раз данные разного типа. В зависимости от типа данных вы рендерите по-разному: где-то добавляете тег img, где-то checkbox, где-то просто вставляете строку.
Вот и получается что-то такое странное:
let arr = returnedDataFromBackend;
arr.forEach((ele) => {
// функция каждый раз возвращает переменную ele разных типов
if (typeof ele === 'string') return renderString(ele);
if (ele.type == 'image') return renderImage(ele);
...
});
Разумеется, этот код можно улучшить. К примеру, подойти к беку и сказать, чтобы он отдавал мне все данные в виде массива хешей с двумя полями: type и value. Либо самому написать прослойку которая нормализует полученные данные, а потом передает их дальше. Но это уже совсем другая история :)
Какой процент софта разрабатывается реально с нуля? Особенно, как вы говорите, «человечеством», так-то для студента каждая программа — что-то новое. Давайте возьмем как пример самую распространенную область — веб приложения и корпоративное ПО. Что там нового? Взял фреймворк, написал поверх него бизнес логику, протестировал, задеплоил на продакшен. Бизнес логика разная? Ну так и один и тот же дом, в зависимости от местоположения, будет различаться — где-то утеплить сильнее, где-то фундамент изменить и тд.
Допустим, вам надо отправить сообщение юзеру, для этого нужно получить канал отправки по id юзера, а потом отправить это сообщение по каналу. У вас есть функция, которая принимает на вход user_id, на выходе отдает один из нескольких типов данных: или экземпляр класса SMS, или экземпляр класса Email, или экземпляр класса Websocket, или вообще null. Вы вызываете эту функцию, получаете объект, а потом через него отправляете сообщение object.send(«hello»).
Или же вы функцией берете из нереляционной базы какие-то данные — так уж получилось, что не вы её заполняете и в ответ может прийти и число, и масив, и даже фотография. Потом, в зависимости от типа, передаете эти данные нужному обработчику.
Да.
Асинхронно это реализовывать на nodejs довольно бесяче (особенно раньше, на колбеках), но очень производительно — когда один запрос ожидает ответа от внешнего сервиса — бд, кеша или еще чего — другой исполняется.
stackoverflow.com/questions/21743841/how-to-avoid-annoying-error-declared-and-not-used
Дебаг становится болью и страданием. Часть кода и импортируемых либ вечно закомменчена, потому что компилятор много на себя берет. Ходи вечно туда-сюда, то закомментируй, то раскомментируй кусок. Потом обязательно что-то забываешь раскомментить, из-за этого упадет в другом месте, и так далее.
А ведь решение простое — пусть компилятор компилирует, а линтер проверяет на все эти неиспользуемые переменные. По отдельности. Или флаг какой-нибудь ввести, чтобы управлять поведением компилятора. Но нет, разработчики языка же самые умные, давайте мол, заставим всех писать так, а не иначе.
На самом деле хороший язык в своей области, и писать на нем в целом приятно, но вот от этого момента у меня конкретно пригорает. Сколько лет прошло, а до сих пор не изменили это поведение.
В каком-нибудь javascript'e
и
означают совершенно разную логику. В первом случае мы в функцию а передали функцию б, которую можно будет вызвать внутри этой функции а. Во втором случае мы вызвали функцию б и результаты ее выполнения передали в функцию а.
Но в руби
и
и
по результатам выполнения означают одно и то же. В первом случае мы вызвали функцию б, результаты ее выполнения передали в функцию а (не смотря на отсутствие скобок, это все равно вызов функции, а не ее передача в другую функцию). Во втором случае — то же самое. В третьем — мы вручную присвоили переменной данные и передали их в функцию а. В итоге, во всех трех случаях, на вход в функцию а поступит число 42.
Это удобно когда знаешь, и непривычно, когда не знаешь. Но оценка с точки зрения непривычности — не самая адекватная. Я, к примеру, совершенно не разбираюсь в c++. И, когда читаю исходник какого-либо интересного мне репозитория, чтобы разобраться в алгоритме, для меня код просто дико нечитаемый, приходится продираться сквозь него. Но это не значит, что синтаксис языка плох.
Когда начинаешь этим пользоваться, понимаешь, насколько это удобно — когда «a» может быть хоть переменной, хоть функцией, и тебе на это плевать.
Например, определенный контроллер обрабатывает апи-запрос на создание пользователя. В теле этого контроллера будет строка, что-то вроде:
create_params на самом деле функция, описанная где-нибудь выше, но в этом случае используется как переменная. И это намного более читаемо, чем что-то вроде такого:
Зачем тут акцентировать скобками вызов функции? Какую пользу это принесет, кроме «в пхп/жс/питоне я привык, чтоб было так»?
А вот польза «без скобок» вполне очевидная — поведение не зависит от реализации. В других языках вызвать переменную как функцию — ошибка, вызвать функцию как переменную — ошибка. Изменил потом переменную на функцию или наоборот — и ходи потом во все места, где оно используется, исправляй.
Опять же. Ну допустим, обматерите вы его. И что, после этого
ровно в полночьон превратитсяв тыквув сеньора? Вам тогда стоит курсы повышения квалификации открывать — заходит студент в кабинет, 15 минут криков, выходит крутой специалист.Но ведь и писать код можно по-разному. Можно это делать «на отвали». К примеру, менеджеры обычно довольно посредственно ориентируются в архитектуре ПО. И если сегодня исполнить таску как она поставлена — завтра надо будет что-то переделать. Зато не надо думать и нагружать себя — сделал что сказали и ушел домой.
Но можно ведь и по-другому. Можно первым начать разговор, мол, «вот смотри, такая-то логика приведет к таким-то последствиям в дальнейшем, придется делать вот это — ты уверен, что нам это нужно, может лучше сделать вот эдак?» Но это отнимает дополнительное время, хоть и полезно бизнесу — вместо этого можно ведь хабр почитать или там на гитхабе что интересного поискать — ведь формально от работника требуется кодить, а не думать как будет лучше бизнесу.
Если вы можете себе позволить лежать целый год на печи и плевать в потолок — вперед. Какая еще социальная ответственность? Да вас в пример будут приводить другим людям — вот мол, смотрите, какой молодец мой %set_name%. А ваш %another_name% горбатится на трех работах, дома не бывает, а вы еще и впроголодь живете.
Когда вы устраиваетесь на работу, вы по сути заключаете долговременную сделку купли-продажи — продаете свое время. Точнее даже не просто время, а свои навыко-часы или навыко-месяцы. Всякие стенания «ах, это рабство», «а жить когда?», «работнику не должно быть дела до бизнеса» — какой-то инфантилизм, если честно. Нормальный человек будет стараться исполнять свои обязательства по духу, а не по букве, и будет требовать от окружающих людей того же. Если вы продали 5 часов своей жизни бизнесу — то ожидается, что вы потратите это время на пользу бизнеса, а не на личную пользу. То же ожидается и от бизнеса — оговоренного вознаграждения без проволочек и комфортной обстановки. Владельцу бизнеса может и выгодна бюрократия, лишение премий, невразумительные метрики для штрафов, кидание с зарплатой и прочее, но ожидается, что он так же добросовестно, как и работник, будет выполнять свои обязательства.
Если я хочу использовать какую-то новую, еще незнакомую мне технологию в проекте — я честно говорю об этом. Мы оцениваем риски и возможности, и решаем, можем ли мы себе это позволить. В конечном счете новый опыт полезен не только мне — более квалифицированный разработчик принесет бизнесу больше пользы. Но вот делать это втихомолку, плюя на свои обязательства, занимаясь лишь самообразованием, а «после нас хоть потоп» — это уже саботаж какой-то.
Несмотря на сомнительное название, произведение довольно любопытное.
Обыватель, прочитав такую крутую статью без очернения, загорается идеей. Заходит в интернет, гуглит, натыкается на сайт с чудо-таблеткой из сахара всего лишь за 999.90, покупает её за много денег, пьет по утрам перед едой и твердо уверен, что будет теперь жить на 100500 лет дольше.
Чем это поможет ученым?
Научные работы сложные. Чтобы их просто прочитать, требуется как минимум знать английский, плюс иметь понимание о научном методе и о том, какие требования нужно соблюдать при проведении эксперимента. Плюс он должен уметь отличать научную работу от журналистского «высера». Плюс хотя бы чуть-чуть в биологии шарить.
Я, хоть и не считаю себя обычным обывателем, не уверен что смогу вот так просто отличить зерна от плевел, без того, чтобы потратить пару-тройку суток на изучение отдельно взятой научной статьи. Если у вас есть способ, который позволит простому человеку совершенно без раздумий правильно отличать отличать одно от другого — поделитесь им. Потому что не будет обычный человек тратить десятки часов на это, он либо даст деньги сразу, либо развернется и уйдет.
UPDATE Мне в этом смысле golang нравится — есть структуры (типы), а есть интерфейсы (поведение). В итоге разные структуры (SMS, Email и Websocket) реализовывают одно и то же поведение — отправку сообщения.
Я порекомендовал бы книжку «Гарри Поттер и Методы Рационального Мышления». Там есть сцены обсуждения этой проблемы между двумя сторонами — «смерть — это хорошо» и «смерть — это плохо», с достаточно хорошими аргументами обеих сторон.
Нужно хоть немного разбираться в вопросе для совершения эффективных действий. А то получится как в финансах — форекс конторы полностью дискредитировали настоящие биржи в глазах простого населения в странах бывшего союза. Вы хотите подложить ту же свинью для идеи бессмертия? Спасибо, нам такого не надо.
Только вот это скучно, а программисты в большинстве своем — народ, который не любит несколько раз делать одно и то же, а любит делать что-то новое. Поэтому, к примеру, и меняют места работы каждую пару лет — перерос существующее, пора искать более сложное. Вот и получается, что почти в каждом проекте есть неизвестный кусок — новая технология, новый подход, новые требования, и тд.
Вам нужно сделать фронт-админку для этого. Вы отправляете на бек запрос с айдишником опроса, в ответ от присылает вам всё что заполнил юзер — массив из данных разных типов. Вы каждый раз получаете следующий элемент этого массива — цикл по сути, в js это можно сделать функцией forEach() — и оно возвращает каждый раз данные разного типа. В зависимости от типа данных вы рендерите по-разному: где-то добавляете тег img, где-то checkbox, где-то просто вставляете строку.
Вот и получается что-то такое странное:
Разумеется, этот код можно улучшить. К примеру, подойти к беку и сказать, чтобы он отдавал мне все данные в виде массива хешей с двумя полями: type и value. Либо самому написать прослойку которая нормализует полученные данные, а потом передает их дальше. Но это уже совсем другая история :)
Какой процент софта разрабатывается реально с нуля? Особенно, как вы говорите, «человечеством», так-то для студента каждая программа — что-то новое. Давайте возьмем как пример самую распространенную область — веб приложения и корпоративное ПО. Что там нового? Взял фреймворк, написал поверх него бизнес логику, протестировал, задеплоил на продакшен. Бизнес логика разная? Ну так и один и тот же дом, в зависимости от местоположения, будет различаться — где-то утеплить сильнее, где-то фундамент изменить и тд.
Или же вы функцией берете из нереляционной базы какие-то данные — так уж получилось, что не вы её заполняете и в ответ может прийти и число, и масив, и даже фотография. Потом, в зависимости от типа, передаете эти данные нужному обработчику.