Не секрет, что флагманами асинхронной разработки на бэкенде являются по сути три языка - это javascript, go и python.Пора уже окончательно сделать выбор между этими титанами и развернуть достойный дискусс.Расчехляем ваши линейки, господа, приступаем...
>>1273526 (OP)Я бы хотел сказать го, но он всратый, как выйдет го2 - перейду на него. А пока что питон, очень няшный синтаксис и простота написания асинхронного кода.
>>1273526 (OP)слушай, ну если сам создатель ноды говорит, что для прототипчиков нода пойдёт, но в продакшен он пишет на го, то какбэ чьё мнение тебе ещё надо-то? на практике у меня на работе получается так же.что касается питона то лично я не умею его готовить и сервера на нём у меня как-то тяжело идут, я его использую как замену баша для девопса итп вещей. всё пытаюсь перейти на го и для этих целей, но чёт пока лениво как-то.но тут ещё надо учесть, что я херачил много на сишечке в своё время и для меня го сразу показался благолепным и очевидным; господам, приходящим из реакта нода может зайти намного проще, так что тут хз, я неистово топлю за то, что надо использовать то, что уже знаешь и за что платят, так что и с >>1273546 господином я тоже согласен.
>>1273905Скажи, что ты называешь "асинхронностью". И почему в Go обычно говорят о concurrency, а не async?Для тебя это синонимы, или есть различие?
>>1273526 (OP)зачем учить это говно, когда есть божественный php, html, css, mysql с шикарной библиотекой встроенных компонентов?
>>1273928Затем, что есть задачи, которые php просто не вывозит. В моей рабочей практике таких задач было несколько -- в одном случае веб-сервер должен был принимать данные от стримера потокового видео о состоянии потоков, каковых там было пару сотен, обновление несколько раз в секунду и пхп просто не прожевал. Во второй ситуации нужен был udp-сервер, в который железки слали информацию о событиях, там событий было не так уж много, зато железок счёт шёл на тысячи. Вероятно, всё это можно было сделать и на пхп методом тюнинга итд итп, но на ноде оно всё просто заработало сразу и пиздец.
>>1273958>Затем, что есть задачи, которые php просто не вывозитПхп 7 уже скоро как полтора года ебёт ноду по скорости, алё.https://habr.com/post/320670/
>>1273959Чтобы пхп ебал ноду по скорости в реальном мире, к нему надо прикрутить асинхронный модуль для *sql как минимум. Что толку от того, что он хэллоуворлды научился быстро отдавать или там строки складывать? А когда ты посмотришь на неблокирующие модули для пыхи, которые на Amp сделаны, например, то ты там узришь ВНЕЗАПНО тот же ивент луп, промисы итд итп. Ну и нахуя? Просто чтобы принципиально не зашквариваться об ЖС? Ну я подобными заёбами не страдаю.
>>1273925Ты видимо слишком туп или запутался в баззвордах.Совершенно насрать как она там под капотом реализовано concurrency, мьютексы, синхронайзы, горутины, корутины, асинки с промисами или обычные калбэки, важно понимать, то что ты получаешь асинхронное исполнение, просто по умолчанию (где в других языках япуться с промисами и асинками).Именно поэтому выстрелил го (и в свое время нода), а не потому что хомякам сказали что он хороший.
>>1273968Эм, чот нидогоняю, в ноде же один паток, как она может быть асинкронная. Почему нода не блокирующая ио, как можно не заблокировать один жеский диск? Чот ваще вас не понимаю. Алсо треды вроде уже можно намутить через птхреадс. На крайняк все скармилвать в сервер очередей какаой нибудь. Чистая асинхронщина же выходит. Алсо а как же промисы из гузла, они не асинхронны?
>>1274029>в ноде же один патокВсе просто.Прежде чем принимать за истину то, что ты где-то что-то слышал, попытался бы хоть раз, сам изучить что такое нода и как она устроена.Нет, в ней не один поток. И никогда не был один.
>>1274029>Почему нода не блокирующая ио, как можно не заблокировать один жеский диск?Это у тебя тотальный пробел в понимании устройства ОС, компьютеров и всего остального.
Ну что ты, братишка, притих? Работаешь на дядю? Тимлид мудак? Работа на галере приносит деньги, но не удовлетворения? Хочется уже делать что-то интересное, по кайфу? Вероятно, мы можем помочь тебе с этим, если ты поможешь нам. В команду бродяг-энтузиастов гаражного кодинга мы ищем:— Back- программиста, который знаком, python/asyncio/асинхронные сокеты— Front-программиста, который знаком: React/ReduxПока Телеграм закрывать не собираются, мы ищем молодых и амбициозных, умеющих добиваться поставленных целей и нацеленных результат фронтендеров, могущих в сокеты и Реакт/РедуксBack - python/AsyncIOдля запуска уникального®™ веб-сервиса. С нас как обычно и несколько опытных ребят, которые всегда помогут со сложностями. Скостылим proof of concept на голом энтузиазме и потных шутках — сможем выйти за рубеж уже на серьёзных щах, снять склад в Марьино воркшоп в Москва-Сити и купить всем Маки. Всё почти готово, старичок, тебя не хватает. Демка уже есть, божественный trello,zeppelin и почитать notion. С нас как всегда аниме стикеры и два чая.Пиши: телега @anon4k
>>1274053>Скостылим proof of concept на голом энтузиазме и потных шутках>React/Redux>python/asyncio/асинхронные сокетыОх уж этот доширачный энтузиазм
>>1274101а разве это не про тсп соединения? Типа у хдд ссд нету физических способов же писать в несколько потоков.
>>1274102ну есть еще вариант с ядрами процессора, или за место потоков запускать процессы, я думал это все и позволяет замутить асинхронность. но разве нода умеет в несколоко ядер, или создавать поллпроцессы?
>>1274115ты думал неправильно. не обязательно полагаться на железо (ядра процессора) и механизмы ОС (форк, тредики) для реализации асинхронности. Гугли green threads например.>>1274036если прям совсем на быдлоуровне, то да, разницы никакой.>>1274111ты путаешься в уровнях абстракции. понятно, что головка на хдд может только в один сектор писать в один момент времени, но если подняться на уровень выше, то за счёт буферизации на уровне даже самого контроллера хдд, потоков уже несколько. а потом ещё уровень ОС, где ясен хуй ты можешь (и всегда так делаешь) читать и писать на диск "одновременно".
>>1274014> ты получаешь асинхронное исполнение, просто по умолчанию (где в других языках япуться с промисами и асинками)Ты видимо слишком тупой, что валишь всё в одну кучу, да ещё и называешь эту кучу "асинхронным исполнением", да ещё и противопоставляя это ебле с промисами и асинками.Но мне похуй, что ты тупой, няша :3
>>1274198>ты путаешься в уровнях абстракцииНу да на уровне оси, но это же не меняет скорости записи, если ты один файл записал со скоростью Н и второй со скоростью К, то ведь если ты их одновременно будешь записывать то все равно будет скорость Н+К ну и плюс еще небольшие затраты на буферизацию и всякие там дела из ос.По-моему для пыхи вполне хватает аяксовой загрузки нескольких файлов. Впрочем как и в ноде. На пыхе есть какой то Swoole хз чо это за хрень, но тоже позволяет асинхронно писать.>green threads например.Это вроде и в пыхе есть и ноде? разве нет?>на быдлоуровне,Ну а какой уровень нужен, что бы разницу почувствовать? Интересны примеры.
>>1274328>Это вроде и в пыхе есть и ноде? разве нет?В ноде нет, там можно только кластер в несколько независимых процессов поднимать аля фпм. Весь твой код - однопоточный, асинхронное выполнение собственного кода (если, скажем, речь о разборе и преобразовании большого jsona и так на дохуя подключенных клиентов) пердолится путём раскидывания setTimeout/генераторов/промисов на каждые 5 строк логики.
>>1274334>там можно только кластер в несколько независимых процессов поднимать аля фпмНу не пиздаболь.Воркеры для кого?
>>1274334Ну судя по всему как что в ноде что в пыхе, это одинаково работает, тогда вообще не вижу разницы, кроме синтаксиса.
>>1273959Братюнь, а при чём тут скорость? Самая большая боль PHP это born to die. Любой скрипт рассчитан на то что ты его а) запустил, б) он сделал свое дело и в) он благополучно сдох и выгрузился из памяти. Из-за чего на пыхе весьма проблемно писать: 1. Любой риалтайм, даже тупейший чятик на вебсокетах2. Любые резидентные демоны. Тут, к слову, огромная проблема ещё и в том что пых не умеет в concurrency в любом виде. То есть если у тебя будет задача по сбору ебических объемов данных и их архивации вместо того чтобы распараллелить процесс и создать очередь как в каком-нибудь питоне / руби / ноде ты будешь делать всё по очереди. А так да, на числодробилках мб и быстрее
>>1274365>Самая большая боль PHP это born to die.Но ведь можно демона на пыхе написать. Никто не мешает тебе из этого демона плодить процессы, тем самым распаралеливая задачу.
>>1274376Можно, они даже есть в продакшне. Вот только нахуя этот геморрой? Пых создавался для веба и под свои цели инструмент таки весьма и весьма удачный вышел. Тот же born to die, являющийся головной болью при разработке каких-нибудь демонов из-за кучи проблем, весьма удобен если ты пишешь какой-нибудь rest сервис просто потому что он автоматически делает любой запрос stateless. И можно не заморачиваться об утечках памяти в качестве бонуса. Но зачем использовать инструмент в областях в которых он просто неудобен? Ну и плодить процессы в пыхе это отдельное веселье. В те времена когда я с ним работал (лет шесть назад) максимумом конкарренси в PHP были форки. А работа с общей памятью вообще в какие-то анальные пляски превращалась
>>1274384>автоматически делает любой запрос statelessПри этом state из логики никуда не исчезает и начинается хипстопляска с базами данных и разномастными кешами и асинхронными хранилищами, которые по-сути оный стейт и заменяют, не забыв посадить все приложение на свою бутылку.
>>1274384>Пых создавался для вебану так и жс создавался для фронтенда, а тут его на бэк его перетаскивают, с точки зрения например пыхо разраба тоже непонятно зачем. Про утечки в памяти пыха впервые слышу, можно поподробнее?И вроде как для пыха amphp.org изобрели теперь нету проблем с потоками. Хотя вроде и спотоками не особо сложно. Где то находил пасты кода, где можно создавать процессы.Если следовать твоей логике каждого инструмента под свои задачи, то тогда можно например для реста и статики пилить сервер на пыхе, и когда нужны вебсокеты брать ноду, и добавлять ее в проект.
>>1274386Ага, всё так. С той лишь разницей что стейт о котором ты говоришь это стейт __приложения__ а не __обработчика__. Есть у тебя апп который делает похуй что и имеет какое-то api. В пыхе ты не сможешь поменять переменную в коде так чтобы она дала эффект при следующем запросе (коряво наверное описал, грубо говоря сделать что-то типа MyGreateSingleton.property = 'monkey'). На питоне или ноде сможешь. Фактически это потенциальный источник охуительных проблем уровня "дев тестировал в локали и всё работало а потом перенёс на прод и всё нахуй сломалось потому что там больше одного воркера". Хотя это конечно макакапроблемы. Ну и плюс можно забить большой-пребольшой болт на такие вещи как утечки памяти просто потому что после запроса процесс умирает
>>1274389Я лет пять не работал с пыхом, не могу никак прокомментировать >> И вроде как для пыха amphp.org изобрели теперь нету проблем с потоками. Хотя вроде и спотоками не особо сложно. Где то находил пасты кода, где можно создавать процессы.Проблемы с памятью были у целой кучи ORM в своё время как минимум. У Yii (первого) лично сталкивался, знакомые посоны на симфони говорили тоже печалька. Если честно уже не вспомню конкретику>> Если следовать твоей логике каждого инструмента под свои задачи, то тогда можно например для реста и статики пилить сервер на пыхе, и когда нужны вебсокеты брать ноду, и добавлять ее в проект.Ну таки да. Тут вопрос инфраструктуры в общем-то. Если ты пилишь всё на каком-нибудь питоне то можешь юзать один и тот же воркер для запросов и сокетов. Ну и куча кода будет общим. В мире ноды эта хуйня вообще в абсолют возведена в плане того что там ещё и фронтэнд на том же языке. Я как-то принимал участие в разработке внутренней учётной херни, писали на ноде с использованием реакта, экспресса и тайпскрипта. Довольно приятно получилось на мой вкус. Или другой пример. До появления ченнелз при работе с джангой для сокетов юзали торнадо и aiohttp. Бонусы те же - куча единого кода, можно при желании использовать ORM. С костылями правда, была печалька с закрытием старых соединений ( явный вызов from django.db import close_old_connections ) из-за того что джанговский орм делал такие дела при закрытии коннекшна, который в резидентном демоне не закрывался никогда. >> ну так и жс создавался для фронтенда, а тут его на бэк его перетаскивают, с точки зрения например пыхо разраба тоже непонятно зачем. JS изначально асинхронный плюс он широко юзается на фронтэнде. Минус один язык для фуллстака, иногда оправданно. Плюс он изначально создавался для постоянной работы (как минимум в рамках открытой вкладки браузера), из-за чего там не положен такой большой и толстый болт на рантайм
>>1274328>если ты один файл записал со скоростью Н и второй со скоростью К, то ведь если ты их одновременно будешь записывать то все равно будет скорость Н+К ну и плюс еще небольшие затраты на буферизацию и всякие там дела из ос.да, всё так. но асинхронность решает не проблему увеличения скорости записи выше скорости самого диска лол, а проблему того, чтобы максимизировать утилизацию = чтобы ресурс был всегда задрочен вусмерть, причём задрочен эффективно, а не простаивал в ожидании. а это уже решать можно по-разному, но в целом всё один хуй сводится к какому-то пулу или тредов или просто кусков кода, которые оркестровщик переключает так, чтобы канплюктер постоянно делал что-то полезное. в роли оркестровщика может быть и ядро ОС и ВМ самого языка и в теории даже просто твой самописный код в теории даже на пхп, если ты кибердемон поехавший.
>>1274389>Если следовать твоей логике каждого инструмента под свои задачи, то тогда можно например для реста и статики пилить сервер на пыхе, и когда нужны вебсокеты брать ноду, и добавлять ее в проект. я так и делаю. и ещё питон для анализа данных. то есть у меня нода как быстрый асинхронный непротекающий демон данные в мускуль собирает. потом питон удобными библами эти данные перебирает, там скорость уже не важна. а морда на пхп и бэкбоне (легаси щито поделать) клиентам уже инфу выдаёт. у психически здоровых людей такой подход встречается повсеместно. желание написать всё на чём-то одном оно в принципе нормально на начальных этапах, но через пару лет опыта ты понимаешь, что этот ёбаный цирк даром никому не всрался.
>>1274479>у психически здоровых людей такой подход встречается повсеместноПоходу я стал просвященным.
>>1273526 (OP)Какой умник поставил рядом слова "python" и "ассинхронный"? И почему нет java-based-языков? Того же котлина с его корутинами?
>>1274529да ну сколько можно-то? асинхронность -- это просто паттерн. его можно и на ассемблере и на квикбейсике реализовать.
>>1274322>Ты видимо слишком туп или запутался в баззвордах.Оказалось, что в баззвордах ты не запутался.
>>1273526 (OP)Божественная Java + Ratpack, конечно же.Всяким скриптопетухам, чтоб убедились в своей убогости, предлагаю написать простенький веб-сервер вычисляющий рекурсивно функцию Фибоначчи, дергая самого себя (прям как ты пока никого нет дома).Вот готовый код для Ratpack https://github.com/setblackWs/ratpackFibb/blob/master/src/main/java/pl/setblack/fibbo/FibboServer.java (количество тредов можно (и даже нужно) в 1 выставить - на это не обращаем внимание). Сюда постим результат работы для n=30.
>>1276796Так и не понял нахуя эта параша если уже есть такие-то петухоны со всякими джангами, асинкайо и твистедами, жабы со спрингами, спарками и вертэксами, шарп с аспнетом. А для ебических скоростей всегда есть плюсы. Го какой-то всратый
>>1277294>петухоны со всякими джангамиКоторые или интерпретатор в 2к18 или половина пакетов и библиотек на пупу не работает. И все эти асинкайо им как мертвому припарка.> жабы со спрингами, спарками и вертэксамиОтличный рантайм угроблен интырпрайзным подходом и гиговыми библиотеками. А ведь когда-то игрушки на телефонах с метром оперативы и процом меньше сотки кекогерц шустро работали, при том что жаба на них обычно калечная с примитивным житом стояла.> шарп с аспнетомОн за пределами /gd/ дохлый аки позапрошлогодний скелет мертвой вороны.
>>1277304>> Которые или интерпретатор в 2к18 или половина пакетов и библиотек на пупу не работает. И все эти асинкайо им как мертвому припаркаНи пони. Жаба тоже интерпретатор так-то, как и шарп. Большинство проблем со скоростью можно решить инфраструктурой. Тяжелые вещи ничего не мешает пилить на каком-нибудь cython, если уж так приспичило. В чем проблема? >> Отличный рантайм угроблен интырпрайзным подходом и гиговыми библиотеками. А ведь когда-то игрушки на телефонах с метром оперативы и процом меньше сотки кекогерц шустро работали, при том что жаба на них обычно калечная с примитивным житом стояла.Соглашусь. У меня в стародавние времена жаба для сетевых дел примерно поэтому и не пошла. Уж очень оно долгое, в плане разработки>> Он за пределами /gd/ дохлый аки позапрошлогодний скелет мертвой вороны.Ну хуй знает, рынок труда с тобой не согласен
>>1277562>Жаба тоже интерпретатор так-то, как и шарпОни только в первый раз интерпретатор, потом фрагмент кода jit-компилируют. Равно как и нодка с пыхом. Только питон в 2к18 чистый интерпретатор без JIT. Или pypy, который вечная альфа и половина не работает.> Большинство проблем со скоростью можно решить инфраструктурой. Только вот зачем, если JIT всё делает за тебя. > Ну хуй знает, рынок труда с тобой не согласен Там легаси дремучее, так то и на делфи есть дофига вакансий.
>>1277571>> Только вот зачем, если JIT всё делает за тебя. Я стесняюсь спросить как jit полностью решит проблему в случае если апп ходит за данными на стороннее апи, например. Или как оно поможет в случае если узкое место это база данных. Или если у тебя есть нечто дико выжирающее ресурсы и огромный объем запросов - отсрочит пиздец, но не предотвратит. Штука-то хорошая, но нихрена не панацея>> Там легаси дремучее, так то и на делфи есть дофига вакансий.Да ты шутишь, в обоих случаях. На дельфях вакансий полторы штуки, а легаси что у шарпа что у жабы много. Да и у петухона если уж на то пошло. Не так всё печально
>>1275312> быть дауном который считает что фп и ооп ортогональные вещиМетаклассов тебе в анусА если по делу - в кложуре есть классы, добро пожаловать
>>1277853>в кложуре есть классыИ вот по честному нахрена? Серьезно, либо ты отделяешь алгоритмы и данные, то отделяй ты их до конца. Нахера мешать в кучу объектное говно?Если в язык тянут вещи, лишь по тому, что они модны и популярны - в жопу такой язык.
>>1277721>> Я стесняюсь спросить как jit полностью решит проблему в случае если апп ходит за данными на стороннее апи, например. Или как оно поможет в случае если узкое место это база данных. Или если у тебя есть нечто дико выжирающее ресурсы и огромный объем запросов - отсрочит пиздец, но не предотвратит. Штука-то хорошая, но нихрена не панацеяНу тогда уже про ЯП можно не спорить, бд и прочие сторонние апи - это всегда будут независимыми от ЯП узкими местами.
>>1278002А я на это изначально и смотрел. В предел производительности питона в рабочих делах не упирался ни разу. А вот какое-нибудь тормозное внешнее апи которое при сихронных воркерах блокирует нахер весь воркер - запросто. Потому про такой-то asyncio и aiohttp и писал. Ну и туда же долгие запросы к базе с блокировкой в синхронном режиме
>>1277860> Серьезно, либо ты отделяешь алгоритмы и данные, то отделяй ты их до конца.Только ситхи всё возводят в абсолют!
>>1278399Ну тогда попробуй хоть раз в жизни в "дискуссию" и опровергни мои слова или продолжай звонко пукать вместо ответа, как это принято у малолеток
>>1278435Я даже помогу тебя.ООП - это парадигма императивного программирования.Ключевой аспект - последовательный процесс вычисления с изменением состояний и никак по другомуФП - это функциональная парадигма.Ключевой аспект настоящего ФП - все является результатом или исполнением функции, желательно чистой. Никакой последовательности и как следствие хранимых состояний отсюда дроч на иммутабельность, правда не все понимают зачем.Эти парадигмы, несовместимы на фундаментальном уровне.А теперь попробуй не пукнуть и сказать что-то умное, или укатывайся в js тред.
>>1278436>Никакой последовательности и как следствие хранимых состоянийИ именно поэтому ФП сосет. Без изменяемого состояния невозможно написать эффективную реализацию мало-мальски сложного алгоритма.Эталонный пример - квиксорт на хаскеле.
>>1278436>ООП - это парадигма императивного программирования.>Ключевой аспект - последовательный процесс вычисления с изменением состояний и никак по другому>>ФП - это функциональная парадигма.>Ключевой аспект настоящего ФП - все является результатом или исполнением функции, желательно чистой. Никакой последовательности и как следствие хранимых состояний отсюда дроч на иммутабельность, правда не все понимают зачем.Легко совмещаемы. Дауны спорят, люди делают. Есть такой фреймворк, как reactive programming под несколько языков, и, например в анройде для многопоточки он нужен, но конечно же нет потому что есть корутины скажет выблядокТак вот, написавsubscriber().join().map().subscribeOn().observeOn().subscribe(result -> print(sosi xui));Я применил функциональную парадигму. Так что, соси хуй. Язык это инструмент, а не выяснение у кого хуй длиннее.
>>1278448>subscribeOn>observeOn() >result -> print(sosi xui)>Я применил функциональную парадигму.Не-а, ты насрал в глобальный стейт.Если делать чисто функциональный реактивный фреймворк, он будет устроен совершенно по-другому. Сама же реактивность ни о чем не говорит.
>>1278474> Я применил функциональную парадигму ... Язык это инструмент, а не выяснение у кого хуй длиннее.Поддвачну этогоФункциональное программирование - это просто парадигма, которая для каких-то задач более эффективна, для каких-то - менее.А обмазываться функциональностью ради функциональности - это фанатизм, но никак не профессионализм.
>>1278448>Так вот, написавЛол, ты же понимаешь, что если в императивный язык тебе добавили синтаксический сахар в виде одной только лямбды, то твой язык не стал сразу ФППричем лямбды и функции высшего порядка были даже в процедурных языках. Но это не делало их функциональными языками.Еще раз, для гуманитариев, в фп все и вся есть функции без состояния. А если ты вызываешь функции последовательно, то это, извини меня, процедурное программирование.
>>1278514То есть, для очень очень глупых, в этом примере, тебе добавили лямбду из процедурного языка, к ФП это не имеет никакого отношения.subscriber().join().map().subscribeOn().observeOn().subscribe(result -> print(sosi xui));У тебя либо всё вычисление это результат функций, либо у тебя императивно последовательное каша. А если последовательное, значит между вызовами должно быть состояние, которое нужно между вызовами держать и изменять.
>>1278514>>1278517Мне кажется надо еще проще, для js программистов.Если в твоем языке есть переменная (есть мутабельность) - то язык не функциональный. Даже если ты как истинный джедай все в калбэках пишешь и константах.
>>1279180Алгоритм Фибоначчи стал уже эталонным мемом и признаком аутизма в программирование, но вот сервер, вычисляющий фибоначии, это просто праздник какой-то, просто апогей одарённости.
>>1278436>Ключевой аспект настоящего ФП это как настоящие шотландцы, только ФП. Все кто делает не так, как ты скозал -- не настоящие?
>>1274053Как не надо работать в стартапе: вестись на обещания "вот выйдем в плюс, поднимем тебе зарплату (нет), поделимся процентом прибылей (владелец просто выставляет себе зарплату так, чтобы прибыль была нулевая и ты сосёшь писю без соли), опционы (реальная стоимость опционов хорошо если 1-2% от номинала)"Как надо работать в стартапе: быть полноценным совладельцем с самого начала, пусть даже твоя доля 5-10% либо работать за полноценную рыночную зарплату строго с 9 до 5.
>>1279234Считаю, что программисты делятся на разработчиков и скриптомакак. Первые отличаются от вторых тем, что задумываются о том, что они пишут и как это будет работать.Чем хороши задачи типа "напиши расчёт числа Фибоначчи" - так это тем, что показывают, о чём человек думает во время разработки. Кодирование - это ведь только часть задачи. Если чувак сел и решил это всё рекурсивно и, что называется, "в тупую" - то значит и в бою он будет писать код который как-то работает.Я видел таких, способны "пофиксить" баг, устранив конкретный симптом не докопавшись до реальной проблемы. Я бы таких себе в команду не взял - приходится тратить прорву личного времени, чтобы решение было приемлемого качества и не отвалилось в неожиданный момент.
>>1280013>Если чувак сел и решил это всё рекурсивно и, что называется, "в тупую" - то значит и в бою он будет писать код который как-то работает.Это значит, что чувак не занимается злом - преждевременной оптимизацией и будет выкатывать фичи быстрее байтоебов.
>>1280013Оценивать человека по Фибоначчи, это как оценивает балерину по её ногтям.Откуда вы такие гуманитарные философы то берётесь??И кстати, почему канализационные люки круглые??
>>1280013>>1280120>>1280168Нужно для начала определить границы его знаний, задавая те или иные вопросы, а потом дать ему домашку (если чел метит выше мидла). И не с Фибоначчи глупые вы философы а что-то реальное, что покажет как он пишет код, как оформляет и как "думает" (модульно, или как скрипто баран - линейно как есть).Почему домашку и время - потому что чел в привычных условиях покажет себя как есть. может он еб#ный аутист и асоциал, но кодит хорошо, в привычных ему условиях и надо выжать из парня все, чтобы понять кто он и на что способен
>>1280175И да, иногда бывает важнее насколько чел глубоко знает, скажем SQL и какую-то матчасть. Мне совершенно срать сможет ли он там вспомнить как писать фибоначчи или бинарный поиск - мне важно чтобы он это умел это использовать когда нужно.
>>1280179Если это "домашнее" задание - то плевать, все алгоритмы гуглятся. Тут важно понять, какой у чувака подход. Лично я стараюсь сделать максимально качественно в оговорённых границах (временных, финансовых, т.п.). Если у чувака другой подход - надо смотреть и обсуждать.Преждевременная оптимизация - одна сторона фанатизма, "писать код не задумываясь о производительности и в принципе качестве" - другая.
>>1280509>Домашнее задание>АлгоритмыСразу видно пет-скрипт-киди. Ты хотя бы подумал, зачем давать на дом алгоритмы в 5-50 строк. Нет, речь идет про мини-проекты, по которым можно даже определить, умеет ли человек писать код в команде.
>>1280509> какой у чувака подходИ какие подходы бывают?? Представь, ты собеседующая сторона и ты пытаешься понять какие-то некие подходы. То есть, ты сам себе ставишь абстрактную херню и потом будешь пытаться эту фантазию у человека найти. Не глупо ли?Нет, тебе нужен работник. Если речь про качество - то что такое качество? Это 3 ошибки на 1000 строк? Или это как у джуниора, который пишет 100 строк пол дня, конечно вдумчиво, и верит, что он тем самым не тормоз, а просто делает качественно? Что есть тут качество?>Преждевременная оптимизация - одна сторона фанатизмаСнова пошли фразочки и выкрики идолов. Мы вообще об оптимизации не говорили.Твой мозг уже работает как у гуманитарного программиста, а не как у технаря. Ты говоришь о высоком, абстракции, без конкретики и под свои удобные границы.
>>1275337Хуёвая у тебя фибоначча.1. Переделывайте на BigInteger2. Чтобы работало за O(log2 n)3. В компайл-тайме предрасчёт первых ста чисел.
>>1280013Разработчики делятся на возвышенных дрочил, которые умеют делать с входными и выходными данными то, чего в камасутре даже нет, и приземленных работяг, которые переводят хотелки начальства в готовую программу. Нужны и те и другие, просто каждому своё место. Грубо говоря - одни ебашат охуенные кирпичи, а другие охуенно строят из них стены. а потом приходят макаки и вместо крыши ставят очередной фреймворк для пола, потому что ничего кроме заученного фреймворка не умеют
>>1280696> подходыЯ видел всего три : "хуяк хуяк и в релиз", "надо продумать архитектуру для фич, которые появятся в проекте через десять лет " и "щас че нить ебанем, а там как пойдёт".
>>1280756У программистов зачастую завышенное ЧСВ. На самом деле нужен галерный гребец и все простой офисный работник, который бы работал ровно так же как и другие Есть, конечно, проблема нехватки высококвалифицированных специалистов, для которых приходится делать кувырки, чтобы избежать текучки, откуда это ЧСВ и стекает на всех других программистов, но это скорее исключение.Поэтому все это маня мечты программистов - типа узнать как он пишет фибоначчи, как он качественен там или нет. Это все утопия и розовые очки кодера. Бизнесу нафиг не нужен глубокий внутренний мир тебя, бизнесу нужно только узнать твою область знаний и соотнести как это поможет сейчас. Ты просто инвестиция и все, ты просто ресурс.
>>1280782>Бизнесу нафиг не нужен Хорошему бизнесу.Гуманитарии в HR конечно же начитаются херни и будут натягивать этот мир на высокие абстрактные идеалы понюхивая свои пуки
>>1280013>Если чувак сел и решил это всё рекурсивно и, что называется, "в тупую"Напишу на функциональщине с хвостовой рекурсией, но ты, петушок, даже и не поймешь.
>>1280783Первое - "щас сделаем как всегда, лишь бы работало", третье - "михалыч, меня сегодня тянет на творчество". Я не очень удачно подобрал название для третьего
>>1280760> "надо продумать архитектуру для фич, которые появятся в проекте через десять лет " Это я и это нихуя не хорошо. Часто бывает трудно что-то написать не заебываясь архитектурой, понятностью кода и производительностью. Завидую тем кто можнет просто "хуяк-хуяк", а потом рефакторить.
>>1280845Я постоянно хуячу лишь бы работало, а потом рефакторю вилкой. Правда посередине, в команде нужны оба подхода. Такие как я-чтобы быстрее сдать задачу бизнесу, такие как ты, чтобы держать задачу на плаву.
>>1279180>>1280724Маньки, вы даже проблемы не поняли. Тему этого треда прочитали прежде чем писать? Попробуйте реализовать это на своём любимом фреймворке - может тогда дойдет.
>2018>иметь божественный, мощный С# и .NET Core>юзать бомжеязыки полускриптовые и ГО без дженериковВы дебилы?
>>1280756Формошлёпы тоже нужны, да.Но вот скажи мне, кто тебе помешает, получив задачу (к примеру) "запили мне расчёт числа Фибоначчи" - набрать это слово в гугле и обнаружить, что можно рассчитать его динамически, затратив O(n) операций, вместо того тупой рекурсии (если что, сложность будет экспоненциальной).Время одно и то же, а итоговое качество различается кардинально.Все эти скрипт-кидди с их смузиподходами "работает - и ладно", "поставил гигабайт сторонних пакетов, запрос в бд работает минуту - зато я потратил на него 10 минут и подключил новую хипстерскую орм", "много кушает - купим ещё оперативы, она дешёвая" живы пока только потому, что стоимость времени программиста пока что выше, чем стоимость электроэнергии и прочих "железных" затрат.Но ничего страшного - это нормально (в любой "новой" области такое происходит во время интенсивного расширения) и это пройдёт. Технологии устоятся, тем развития замедлится (закон Мура уже сбоит) и бизнес начнёт больше времени уделять качеству. Тогда несоразмерно задранная планка заработной платы разработчиков упадёт до нормального значения и все эти школьники, которые отработали пару лет, научились лепить формочки на cms'ке и уже называют себя сеньорами, начиная плавать, даже если просто заговорить с ними о паттернах и просто ну очевиднейших практиках хорошего кода типа "не пиши запросов в шаблонах".Профессионал тем и отличается от новичка, что способен оценить задачу и выбрать наиболее качественный вариант под заданные временные рамки. Например, написать не только быстро, но и достаточно качественно, просто не совершив очевидных ошибок.
>>1281045В тему, как раз недавно случай был, я общался с одним таким "разработчиком" и он мне доказывал, что базы данных и всё такое "не нужны", он же и так "справляется с работой". Через несколько дней обнаружилось, что связь между сущностями ожидалась не один-ко-многим, а многие-ко-многим (задача была на уровне "опиши библиотеку с авторами и книгами" - очевидно, что у автора может быть много книг, а у книги - много авторов). В итоге потребовалось писать миграции, править код и всё такое - лишние несколько часов работы.Сеньор бы в таком случае или сразу догадался сделал правильно, или спросил бы (вообще, навык задавать правильные вопросы - очень недооценённый, но очень важный).
>>1281046К слову, то, что у стольких людей предложение "напиши мне расчёт ХХХ" вызывает возгорание - меня не удивляет, потому что этим я (или кто-то ещё) явно тыкаю в их неумение разобраться в вопросе и сделать что-то качественно, без переделок. Чем-то напоминает строителей, там тоже мало какая бригада делает всё сразу, без косяков (профессионалов всегда меньше). И, если указывать на неровную плитку и прочую фигню, возмущаются горе-строители также громко ("мы ведь сделали! Ну и что, что криво!").
>>1281045Судя по твоему посту ты сам недалеко от джуна-теоретика ушёл. Вещи красивые говоришь, но не понимаешь что бизнесу нахуй не нужен красивый хорошо работающий код. Бизнесу надо код, который выполняет задачу. А если задача новая, то чтобы код был написан быстро. Все эти хипстерские языки и фреймворки появились на рынке лишь потому что позволяют быстро шлепать то что нужно.А в тех областях, где требуется оптимизация, экономия памяти и прочие подсчёты тактов процесса, там нету всякого скипающего времени сахара.Как говорил мой дед, каждому хуюшке по своей пиздюшке.
Поясните пожалуйста, за асинхронное программирование. Только вкатываюсь, не знаю про это почти ничего. Где применяется, зачем и сколько нужно знать и понимать для применения?
