Я не особо разбираюсь, но на реальном примере: void Foo(List<string> strings){ strings= new List<string>(); } и void Foo(ref List<string> strings){ strings = new List<string>(); }
будут иметь разное поведение. Как я понимаю это происходит как раз потому что в первом случае так же передается копия ссылки, а во втором - сама ссылка.
Я lodash привел как пример. Его все знают и понимают что оно делает и зачем нужно.
Если говорить, что нам всегда критична скорость и размер. Ну давайте откатимся к си, откажемся от жутко тормознутого HTTP, который даже с HTTP3 - будет проигрывать кастомному бинарному протоколу под конкретные задачи. Ну а что? Скорость работы и размер - самое важное. Взяли си в зубы и пошли хендлерами обмазываться, да свои алокаторы писать, потом запилили свой очень быстрый клиент на OpenGL. Скорость и размер - главное. Такое вот решение будет пару КБ весить и летать на компьютере 30 летней давности. А то что потом никто поддерживать и развивать не сможет - ну, да и фиг с ними, своего времени не жалко, денег заказчика не жалко, пользователей, которым это все инсталлировать - тоже не жалко, так что напишем еще раз с нуля, желательно, сломав обратную совместимость.
Да, тут я ерничаю. Но вот вы прицепились к lodash, будто суть поста была в его рекламе. Я лишь говорил о том, что чтобы писать свой велосипед - нужны веские основания, потому что свой велосипед это дополнительные траты на поддержку, развитие, введение в курс дела новых разработчиков, и далеко не факт, что ваш велосипед будет лучше чем тот, который уже есть.
Поворчать, это конечно весело. Но давайте спустимся на землю. В реальном проекте, если бы я увидел, как кто-то пишет свой обход JS'овсвского объекта, вместо использования lodash - я бы немного РАССТРОИЛСЯ. И да, вроде как те же аргументы: обойти-то просто, из библиотеки нужно 2,5 функции. Только вот ты не один обычно над проектом работаешь. Один написал свой обход так, другой - эдак, третий - придумал еще что-то. В результате, у вас 100500 реализаций обхода объекта, чтобы просто получить значение свойства, причем каждый реализует по своему. А затем приходит еще один человек, он видит эти 100500 этих функций, в результате не понимая, чем они отличаются - делает свою и у вас 100501 функция. И да, на истории про то, что у вас должны быть ревью, должна быть архитектура, диаграммки UML, четкая документация, чтобы все знали что уже есть, чего нет, как нам с этим работать, кто-то должен следить и т.д. Ну, да. Только вот как-то так получается, что в реальном мире - никто особо не хочет ревьюить чужой код, особенно, когда есть свои задачи; архитектура не успевает за хотелками; диаграмки - устаревают и никто их не поддерживает; документацию пишут недостаточную; вся информация о проекте в несколько миллионов строк не держится в голове; а нанять сертифицированного следителя за порядком - бизнес не хочет. А потому - нужно выбирать решения, которые стандартны, которые проверены и бить по рукам тех, кто будет без острой необходимости свое писать.
Допустим, вот у меня научрук был анализу данных - знает SQL, R и немного JS. И ОЧЕНЬ МНОГО МАТАНА. Вот матана там действительно много было. Был ли он плохим специалистом? Да не, он был отличным специалистом, мог за все кишочки пояснить, а т.к. опыта довольно много - он показывал недокументированные штуки, о которых он знал - а вот нагуглить это не представлялось возможным. Назвал бы я его разработчиком? Нет. Но вот к айти он точно относится.
К чему я это? К тому, что во-первых, АйТи не ограничивается разработкой; во-вторых, чтобы быть крутым в чем-то, внезапно, нужно лезть вглубь, а вот это вот: ассемблер изучи, си изучи, перл изучи, чтобы потом гонять json в базу на спринге - это оставьте для студентов и людей, которым заняться нечем.
Вы троллите или серьезно так считаете? Просто достаточно взглянуть на недавнее (в рамках истории) прошлое и увидеть падавшие самолеты из-за ошибок в ПО, марсоходы, разбивающиеся о поверхность планеты, неправильно работавшие системы ПВО и ПРО, аппараты для лучевой терапии, сжигавшие людей. И все ПО для них писалось на ассемблере или Си, иногда на более специфичных, но таких же низкоуровневых языках.
Неужели все это были вредители, которые специально хотели как можно больше людей поубивать, да попортить имущество таким вот интересным способом? А может таки человек - существо неидеальное, и допускает ошибки, и выбор более сложного в использовании инструмента - не снизит их количество?
Справедливости ради отмечу, что при игре в исследователя - игра превращается в легкую прогулку. Ведь когда ты доходишь таки до боссов которые должны быть сложными, у тебя в руках +25 дубина и перекач на 40+ левелов от того что нагеймдизайнили там фромы. Не везде и не со всеми боссами, но во многих случаях я именно вот так с боссами и дрался на 20+ часу игры: зашел, покатался - убил со второго трая. Исключения были Радан, Маления и огненный великан.
Та по хорошему, с реальной разработкой имеет общее только умение понравится HR(чтобы дальше пустили), умение показаться своим среди вумных(чтобы тот кто техсобес проводил - дальше пустил) и умение составить в гугле запрос и пользоваться ctrl+c ctrl+v. Вот она - реальная разработка. Которая кроится за красивым: решением бизнес-задач заказчика. Нужно ли так вот учить людей? Я - как-то сомневаюсь.
Да не то чтобы СОВСЕМ неоптимальный. Просто это первое решение которое приходит в голову даже ребенку. Сложность квадратичная. На маленьких данных нормально работает. На больших - кряхтит. Плюс - в том что пишется очень просто, а понять даже ребенок в состоянии. Для обучения - нормально. В реальной жизни его использовать никто не будет просто потому что все делают что-то типа: data.Sort("age"); Прямо НЕОПТИМАЛЬНЫЙ-НЕОПТИМАЛЬНЫЙ, это что-то типа BogoSort(ака обезьянья сортировка).
Как все весело придумали. Чего бы не добавить в качества программиста, ну, допустим, умение пользоваться фотошопом и блендером каким-нибудь, дизайн накидать там, ну, пусть еще и в колористику может, а то что он за профессионал-то? До кучи, пусть еще и разбирается во всех предметных областях, а то приходит заказчик такой, магазин автоматизировать по продаже футболок, а программист - не знает как бухучет вести правильно, чего ж он такого там напрограммирует? О, хорошо бы и законы всех стран знать, ведь кто знает откуда будет заказчик, а накодит там чего-нибудь, а потом инспекция придет и по шапке надает. Вот если этого минимума нет, то какой вы программист-то тогда? Проходимец с курсов какой-нибудь. Да, а если найдется такой вот настоящий ведущий, то платить ему 80к рублей в месяц, а то программисты и так жируют, иначе откуда столько курсов-то?
Если по тону сообщения непонятно - это шуточка. Программист, внезапно, должен программировать. Выяснять что там хочет заказчик - задача менеджеров и аналитиков. Если программист на себя берет их обязанности, то с разделением труда в конторе не все в порядке.
Как я понимаю, дело в том, что патенты на производство инсулина - у фармкомпаний. Ну и соотвественно, чтобы продавать свой инсулин - придется изобретать новый способ его производства.
Если я правильно помню, они примерно так говорили про AlphaStar в контексте старкрафта. Только вот альфастар там - была довольно глупенькая и побеждала за счет читов (видела одновременно все, что не в тумане войны, в то время как человек так не может, ну и имела доступ напрямую к апи).
Я это к чему. К тому что к заявлениям от лиц, заинтересованных в том, чтобы получать финансирование, относиться стоит с опасением.
Тем же Select - вы говорите: дай мне это отсюда в таком-то порядке отфильтровав таким-то образом. При этом как это будет происходить вас не волнует. Если бы вы писали в императивном стиле - вы бы уже должны были думать о том, какая там структура данных для хранения, как будете обходить, фильтровать хранить таблицы, объединять и т.д.
Так что, как мне кажется, SQL - вполне себе декларативный. То что нужно часто знать, что под капотом делается, чтобы писать оптимальные запросы - другой вопрос.
Ну вот есть сотня-другая железок китайских. Они используют свой проприетарный протокол для сетевого взаимодействия, а производитель предоставляет только описание этого протокола. Нужно сделать сервер сбора информации по этому протоколу, чтобы он не был подвержен C10k, потому что кто знает сколько этих железок будет в бедующем.
Так вот, в Java — есть решения, в которых все уже готово, соединение воспринимается как абстрактная сессия, готовы события, готова планировка IO, а я могу просто реализовать парсер, прикрутить БД и жить себе спокойно.
В .net я буду сидеть и с сокетами играться, реализовывать систему событий, буду делать свой пул буфферов и прочими малополезными вещами заниматься.
Да, сейчас можно костылями часть работы переложить на кестрел, но это все еще костыли.
А я, справедливости ради, таки отмечу, что многих хороших вещей в .net'е нет. Ну, да, многие простые сценарии с CRUD — покрыты, но банально, хочу я спуститься на уровень пониже, допустим поверх TCP/IP поработать — бери сокет/TCPListener и делай все руками, ничего уровня Netty или MINA — нет, попытки портировать их — нельзя пускать в прод, NetCoreServer — сыроват и все равно намного меньше возможностей. И я могу еще сотню-другую таких же примеров из современного .net привести. Шаг влево-вправо от типовых задач — бери и делай сам.
«Монолит» — никак не связан с плохо, неявно или чем-то еще. Это просто тип архитектуры приложения. Все. Превратится ли монолит в плохое, неявно связанное и нетестируемое легаси зависит от того какие решения будут приниматься в процессе развития и насколько профессиональны были разработчики что это писали.
Я не особо разбираюсь, но на реальном примере:
void Foo(List<string> strings){
иstrings= new List<string>();
}
void Foo(ref List<string> strings){
strings = new List<string>();
}
будут иметь разное поведение. Как я понимаю это происходит как раз потому что в первом случае так же передается копия ссылки, а во втором - сама ссылка.
Я lodash привел как пример. Его все знают и понимают что оно делает и зачем нужно.
Если говорить, что нам всегда критична скорость и размер. Ну давайте откатимся к си, откажемся от жутко тормознутого HTTP, который даже с HTTP3 - будет проигрывать кастомному бинарному протоколу под конкретные задачи. Ну а что? Скорость работы и размер - самое важное. Взяли си в зубы и пошли хендлерами обмазываться, да свои алокаторы писать, потом запилили свой очень быстрый клиент на OpenGL. Скорость и размер - главное. Такое вот решение будет пару КБ весить и летать на компьютере 30 летней давности. А то что потом никто поддерживать и развивать не сможет - ну, да и фиг с ними, своего времени не жалко, денег заказчика не жалко, пользователей, которым это все инсталлировать - тоже не жалко, так что напишем еще раз с нуля, желательно, сломав обратную совместимость.
Да, тут я ерничаю. Но вот вы прицепились к lodash, будто суть поста была в его рекламе. Я лишь говорил о том, что чтобы писать свой велосипед - нужны веские основания, потому что свой велосипед это дополнительные траты на поддержку, развитие, введение в курс дела новых разработчиков, и далеко не факт, что ваш велосипед будет лучше чем тот, который уже есть.
Поворчать, это конечно весело. Но давайте спустимся на землю.
В реальном проекте, если бы я увидел, как кто-то пишет свой обход JS'овсвского объекта, вместо использования lodash - я бы немного РАССТРОИЛСЯ. И да, вроде как те же аргументы: обойти-то просто, из библиотеки нужно 2,5 функции. Только вот ты не один обычно над проектом работаешь. Один написал свой обход так, другой - эдак, третий - придумал еще что-то. В результате, у вас 100500 реализаций обхода объекта, чтобы просто получить значение свойства, причем каждый реализует по своему. А затем приходит еще один человек, он видит эти 100500 этих функций, в результате не понимая, чем они отличаются - делает свою и у вас 100501 функция.
И да, на истории про то, что у вас должны быть ревью, должна быть архитектура, диаграммки UML, четкая документация, чтобы все знали что уже есть, чего нет, как нам с этим работать, кто-то должен следить и т.д. Ну, да. Только вот как-то так получается, что в реальном мире - никто особо не хочет ревьюить чужой код, особенно, когда есть свои задачи; архитектура не успевает за хотелками; диаграмки - устаревают и никто их не поддерживает; документацию пишут недостаточную; вся информация о проекте в несколько миллионов строк не держится в голове; а нанять сертифицированного следителя за порядком - бизнес не хочет. А потому - нужно выбирать решения, которые стандартны, которые проверены и бить по рукам тех, кто будет без острой необходимости свое писать.
Довольно странный вообще выбор технологий.
Допустим, вот у меня научрук был анализу данных - знает SQL, R и немного JS. И ОЧЕНЬ МНОГО МАТАНА. Вот матана там действительно много было. Был ли он плохим специалистом? Да не, он был отличным специалистом, мог за все кишочки пояснить, а т.к. опыта довольно много - он показывал недокументированные штуки, о которых он знал - а вот нагуглить это не представлялось возможным. Назвал бы я его разработчиком? Нет. Но вот к айти он точно относится.
К чему я это? К тому, что во-первых, АйТи не ограничивается разработкой; во-вторых, чтобы быть крутым в чем-то, внезапно, нужно лезть вглубь, а вот это вот: ассемблер изучи, си изучи, перл изучи, чтобы потом гонять json в базу на спринге - это оставьте для студентов и людей, которым заняться нечем.
Вы троллите или серьезно так считаете?
Просто достаточно взглянуть на недавнее (в рамках истории) прошлое и увидеть падавшие самолеты из-за ошибок в ПО, марсоходы, разбивающиеся о поверхность планеты, неправильно работавшие системы ПВО и ПРО, аппараты для лучевой терапии, сжигавшие людей. И все ПО для них писалось на ассемблере или Си, иногда на более специфичных, но таких же низкоуровневых языках.
Неужели все это были вредители, которые специально хотели как можно больше людей поубивать, да попортить имущество таким вот интересным способом? А может таки человек - существо неидеальное, и допускает ошибки, и выбор более сложного в использовании инструмента - не снизит их количество?
Справедливости ради отмечу, что при игре в исследователя - игра превращается в легкую прогулку. Ведь когда ты доходишь таки до боссов которые должны быть сложными, у тебя в руках +25 дубина и перекач на 40+ левелов от того что нагеймдизайнили там фромы.
Не везде и не со всеми боссами, но во многих случаях я именно вот так с боссами и дрался на 20+ часу игры: зашел, покатался - убил со второго трая. Исключения были Радан, Маления и огненный великан.
Та по хорошему, с реальной разработкой имеет общее только умение понравится HR(чтобы дальше пустили), умение показаться своим среди вумных(чтобы тот кто техсобес проводил - дальше пустил) и умение составить в гугле запрос и пользоваться ctrl+c ctrl+v. Вот она - реальная разработка. Которая кроится за красивым: решением бизнес-задач заказчика.
Нужно ли так вот учить людей? Я - как-то сомневаюсь.
Да не то чтобы СОВСЕМ неоптимальный. Просто это первое решение которое приходит в голову даже ребенку. Сложность квадратичная. На маленьких данных нормально работает. На больших - кряхтит. Плюс - в том что пишется очень просто, а понять даже ребенок в состоянии. Для обучения - нормально.
В реальной жизни его использовать никто не будет просто потому что все делают что-то типа: data.Sort("age");
Прямо НЕОПТИМАЛЬНЫЙ-НЕОПТИМАЛЬНЫЙ, это что-то типа BogoSort(ака обезьянья сортировка).
Как все весело придумали.
Чего бы не добавить в качества программиста, ну, допустим, умение пользоваться фотошопом и блендером каким-нибудь, дизайн накидать там, ну, пусть еще и в колористику может, а то что он за профессионал-то? До кучи, пусть еще и разбирается во всех предметных областях, а то приходит заказчик такой, магазин автоматизировать по продаже футболок, а программист - не знает как бухучет вести правильно, чего ж он такого там напрограммирует? О, хорошо бы и законы всех стран знать, ведь кто знает откуда будет заказчик, а накодит там чего-нибудь, а потом инспекция придет и по шапке надает.
Вот если этого минимума нет, то какой вы программист-то тогда? Проходимец с курсов какой-нибудь.
Да, а если найдется такой вот настоящий ведущий, то платить ему 80к рублей в месяц, а то программисты и так жируют, иначе откуда столько курсов-то?
Если по тону сообщения непонятно - это шуточка. Программист, внезапно, должен программировать. Выяснять что там хочет заказчик - задача менеджеров и аналитиков. Если программист на себя берет их обязанности, то с разделением труда в конторе не все в порядке.
Как я понимаю, дело в том, что патенты на производство инсулина - у фармкомпаний. Ну и соотвественно, чтобы продавать свой инсулин - придется изобретать новый способ его производства.
Если я правильно помню, они примерно так говорили про AlphaStar в контексте старкрафта. Только вот альфастар там - была довольно глупенькая и побеждала за счет читов (видела одновременно все, что не в тумане войны, в то время как человек так не может, ну и имела доступ напрямую к апи).
Я это к чему. К тому что к заявлениям от лиц, заинтересованных в том, чтобы получать финансирование, относиться стоит с опасением.
Столько лет пользовался постманом и только из-за этого поста таки заметил вкладочку Test
Негативное пространство же довольно популярный термину у тех же художников.
Я не считаю себя специалистом, но лично меня пугает вложенность if'ов. Да и как-то не по ООПшному это все выглядит.
Я не совсем понял претензию к SQL
Тем же Select - вы говорите: дай мне это отсюда в таком-то порядке отфильтровав таким-то образом. При этом как это будет происходить вас не волнует. Если бы вы писали в императивном стиле - вы бы уже должны были думать о том, какая там структура данных для хранения, как будете обходить, фильтровать хранить таблицы, объединять и т.д.
Так что, как мне кажется, SQL - вполне себе декларативный. То что нужно часто знать, что под капотом делается, чтобы писать оптимальные запросы - другой вопрос.
По сравнению с тем что было лет 10 назад - все намного лучше сейчас.
Так вот, в Java — есть решения, в которых все уже готово, соединение воспринимается как абстрактная сессия, готовы события, готова планировка IO, а я могу просто реализовать парсер, прикрутить БД и жить себе спокойно.
В .net я буду сидеть и с сокетами играться, реализовывать систему событий, буду делать свой пул буфферов и прочими малополезными вещами заниматься.
Да, сейчас можно костылями часть работы переложить на кестрел, но это все еще костыли.