Инженерия тут не причем - понятно дело, что если возникла необходимость решения математической нестандартной задачи (ибо стандартные типа sort и тд давно уже живут ф библиотеках и фреймворках), то необходимо посмотреть, а как ее лучше решить не "в лоб" (перебор - это, например, в лоб).
И вот тут нужно либо воспользоваться математиком, который подскажет куда копать, или как раз таки спросить у ЛЛМ - именно не код написать, а про алго и оптимальные пути его решения, потом самому переложить это в код.
И, имхо, правильный инженер должен поступит именно так.
Затем, в сухом остатке остается знание, что при возникновении такого типа задач нужно воспользоваться таким-то алгоритмом. Не нужно инженеру или программисту знать наизусть кучу вещей, которые могут не понадобиться вообще. Нужно лишь понимание где может возникать бутылочное горлышко - а для этого нужна лишь базовая логика, остальное можно будет уточнить или проверить.
Ну и, иногда, решения "в лоб" работают лучше, чем куча хитростей и сложный алго - это тоже надо понимать.
Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.
И индексы тоже не нужны! Да и БД! Даешь просто текстовые файлы!!! )))
Конечно нужны - это единственное, что бережет консистентность ваших данных в БД, а как известно из законов Мерфи - если что-то может случиться - это случиться.
Джуны/кот/комета/шальной скрипт/не сработавшая тразакция - на страже всего этого стоят эти ключи, чтобы случайно и далеко не обязательно, что напрямую через шастанье в БД не превратить ваши данные в желе.
Попробовав все что сейчас есть из устоявшегося, считаю что это либо VUE, либо Svelte.
VUE из-за зрелого коммьюнити с инфраструктурой, да и в целом отличного и модульного подхода (в тч composition API), кроме того найти разработчиков под него не проблема. Писать на нем проще, нет такого оверхэда как на React и Angular, компоненты просты и с нормальным HTML в качестве шаблона, причем в компонет можно как инкапсулировать все - и шаблон, и логику и стили, так и вынести их вовне. Отсуствие ада коллбэков, нормальная событийная модель и отсутствие JSX из-коробки (хотя можно использовать) для меня огромный плюс.
Svelte из-за простоты, размера и скорости, приятного и простого апи.
Все остальное или переусложнено, имеет странный api, необъяснимую магию или имеет околнулевое коммьюнити и полное отсутствие кадров на рынке.
Это не оборонительная ответственность - он ее реально никуда не смещает, он ее берет потому что считает, что так нужно (например потому, что остальные не справятся или не сделают так, чтобы дальше было хорошо) - и он имеет право так считать и делать, если он эту ответственность берет на себя. Ничего "вовне" не уходит в этом случае - ответственность замыкается на нем и он ее тащит.
Что до лысения - если реально начнётся - нужно сходить к доктору и если это окажется естественное состояние - не нужно мучать свой организм гормонами, постоянными процедурами и тд - ибо только в этом случае или постоянной пересадки вы сохраните волосы - лечить это не научились, нужно просто это принять и все - нечего в этом страшного нет, ну придётся имидж чуток подправить, чтобы соответствовать образу и все.
С одной стороны производители техники, как бы это сказать мягко... охренели и делют дичь из вязкого вещества и палок и при этом палок систематически не докладывают.
С другой стороны вы купили бюджетку за очень не дорого.
Вы купили ноут с дискреткой (что сразу плохо, ибо в ноуте оно не нужно). А в бюджетке оно не нужно и проблемно вдвойне. Это же касается и охлаждения и места в ноуте, его комплектации опреденным форм-фатором дисков и т.д.
Вы говорите про драйвер для Линукса, однако тут вопросы к производителю железа, а не к производителю ноута, ибо он (это, к сожалению, правда, хоть и очень не хочется) задумывался под винду, ну вот так, да.
Апгрейд - ноутбуки не приспособлены к этому, если не разработаны специально под это, и, обычно, используются AS IS, все остальное - на ваш страх и риск.
Акум - вопрос, а пробовали в Вантаже смотреть, есть ли параметр "заряжать на 80% при работе на зарядке" + скорее всего вы его и использовали по-большей части на ней? Ну вот плоды, к сожалению, ИМХО, это должно быть сразу в БИОСе, но есть что есть.
Бонусная переферия (мышь и тд) - это сразу мусор, вроде как все технари это все прекрасно понимают, нет? ) Ну и после возни с жидким металлом перепаять микрик в мышке вроде как не должно быть сложным.
Грубо говоря простыми словами - вы купили бюджетный автомобиль для езде в городе, а пытались его использовать как внедорожник.
Но да, это не оправдывает некоторых костыльных и дурацких решений (а возможно они сделаны намеренно для запланированного устаревания).
Lenovo по цене/качество сейчас вообще самое лучшее решение на рынке (Lenovo ThinkBook G6+ / Lecoo и тд).
Преимуществ, когда один стэк и на фронте и на бэке - куча, нода уже взрослая и отлично показала себя в проде, библиотек на все случаи жизни, а если что-то не так - всегда можно залезть и поправить.
Все проблемы у людей от головыи рук, не надо инструменты винить.
При безграмотной арзитектуре, погоне за хайпом и борще в голове вас нечего не спасёт. Выбирать надо под задачу, под вектор развития и под приемственность (сходите ваканчии под go/rust помониторьте).
У нас в университете был лифт, когда я туда поступил, он уже не работал. У меня учился там старший товарищ, и даже когда он поступал - лифт тоже не работал. На одном из капустников мы задали вопрос нашему декану - а вообще этот лифт когда-либо работал? Декан хитро улыбнулся и сказал что да, при сдаче корпуса, но потом его сразу отключили. На вопрос почему, Декан с ещё бОльшей хитрецой ответил так: "Представьте, что лифт вмещает n человек, а хотят на нем уехать k, и k всегда много больше n..." - это про поиск девушек в IT, если вы не поняли про что я)
Можно поспорить?
Инженерия тут не причем - понятно дело, что если возникла необходимость решения математической нестандартной задачи (ибо стандартные типа sort и тд давно уже живут ф библиотеках и фреймворках), то необходимо посмотреть, а как ее лучше решить не "в лоб" (перебор - это, например, в лоб).
И вот тут нужно либо воспользоваться математиком, который подскажет куда копать, или как раз таки спросить у ЛЛМ - именно не код написать, а про алго и оптимальные пути его решения, потом самому переложить это в код.
И, имхо, правильный инженер должен поступит именно так.
Затем, в сухом остатке остается знание, что при возникновении такого типа задач нужно воспользоваться таким-то алгоритмом. Не нужно инженеру или программисту знать наизусть кучу вещей, которые могут не понадобиться вообще. Нужно лишь понимание где может возникать бутылочное горлышко - а для этого нужна лишь базовая логика, остальное можно будет уточнить или проверить.
Ну и, иногда, решения "в лоб" работают лучше, чем куча хитростей и сложный алго - это тоже надо понимать.
Жди - щас сюда ворвется главный евангелист и псевдосеньор гно-молла и начнет кричать что вот мол - это мол хорошо, а это, мол, все плохо :D
Хотя, исходя из парадигмы, это должно работать и в его поделии.
Ну и не забарсывайте это дело - вещь шужная и полезная в текущем зоопарке фреймворков.
Все-таки если не лезть в дебри, то оно вполне, ИМХО (а дебри везде есть, это как времена в английском;))
Соглашусь, что в Паскале проще - но есть еще один нюанс, который я учитывал, давая эту рекомендацию - все-таки хорошо учить не мертвому языку, Си в этом плане куда лучше. И есть потом куда развиваться (я про плюсы и дебри).
Если про == я могу согласиться, то что не так с открывающей скобкой в блоке? B про "мутнейшее описание сложных конструкций" можно подробней? - прямо очень интересно, без всякого сарказма.
Ну, уж ) генераторы/итераторы и декораторы - это как раз не магия, а хороший синтаксический сахар (за который как раз этот язык можно и нужно любить).
Магия - это не очевидное поведение.
Например, в Python значения "по-умолчанию" у фии, которые не являются примитивом, сохраняются между вызывами этой функции, ну или то, что округление по-умолчанию - "бухгалтерское".
Лапша - например, задекларировано, что все есть объект, но при этом чтобы посчитать кол-во символов в строке нужно сделать "len( строка )" вместо "строка.len" и тд. Т.е. есть собственные базовые фии вызываются иногда "из объекта", а иногда "на объект", всякие магические названия вроде __main или не менее магические названия приавтных членов класса, геттеров/сеттеров, кваргсы и тд - те когда нет четкой и жесткой структуры работы.
Делал на ATTINY85, BluePill для такого это даже не оверинженеринг, а гораздо хуже )
А где я писал, что что-то не описано в документации? )
Ну и описанная магия магией быть не перестает.
Я преподавал и много, для себя вывел следующее - лучший язык для понимания - это Си, без плюсов.
Потому как там четкая система типов, указатели (очень важная штука для хорошего программиста), а при левелапе можно и ООП настоящее дать, но уже в плюсах.
То, что в статье - полностью согласен.
Про Python могу очень много плохого наговорить с аргументами, его преподносят часто как "гораздо лучший, чем лапшистый и с кучей магии PHP", а по факту лапши и магии там в разы больше. Я не люблю ни тот, ни тот, но, к сожалению, ввиду того что Python преподается практически во всех университетах мира, он стал стандартом де-факто, увы.
Это просто еще одна ступень защиты (как и ограничение прав), естественно, а не серебрянная пуля, вы предлагаете ее отключить.
А часто бывает, что скрипт при разработке что-то делает, и права там не мешают.
Ну и есть еще плюшки от FK, например удаление цепочек.
И индексы тоже не нужны! Да и БД! Даешь просто текстовые файлы!!! )))
Конечно нужны - это единственное, что бережет консистентность ваших данных в БД, а как известно из законов Мерфи - если что-то может случиться - это случиться.
Джуны/кот/комета/шальной скрипт/не сработавшая тразакция - на страже всего этого стоят эти ключи, чтобы случайно и далеко не обязательно, что напрямую через шастанье в БД не превратить ваши данные в желе.
Попробовав все что сейчас есть из устоявшегося, считаю что это либо VUE, либо Svelte.
VUE из-за зрелого коммьюнити с инфраструктурой, да и в целом отличного и модульного подхода (в тч composition API), кроме того найти разработчиков под него не проблема. Писать на нем проще, нет такого оверхэда как на React и Angular, компоненты просты и с нормальным HTML в качестве шаблона, причем в компонет можно как инкапсулировать все - и шаблон, и логику и стили, так и вынести их вовне. Отсуствие ада коллбэков, нормальная событийная модель и отсутствие JSX из-коробки (хотя можно использовать) для меня огромный плюс.
Svelte из-за простоты, размера и скорости, приятного и простого апи.
Все остальное или переусложнено, имеет странный api, необъяснимую магию или имеет околнулевое коммьюнити и полное отсутствие кадров на рынке.
Это не оборонительная ответственность - он ее реально никуда не смещает, он ее берет потому что считает, что так нужно (например потому, что остальные не справятся или не сделают так, чтобы дальше было хорошо) - и он имеет право так считать и делать, если он эту ответственность берет на себя. Ничего "вовне" не уходит в этом случае - ответственность замыкается на нем и он ее тащит.
Очередная реклама фуфломицина, дожили (
Что до лысения - если реально начнётся - нужно сходить к доктору и если это окажется естественное состояние - не нужно мучать свой организм гормонами, постоянными процедурами и тд - ибо только в этом случае или постоянной пересадки вы сохраните волосы - лечить это не научились, нужно просто это принять и все - нечего в этом страшного нет, ну придётся имидж чуток подправить, чтобы соответствовать образу и все.
Насчёт девченок не переживайте - не уменьшатся)
Очень спорно.
С одной стороны производители техники, как бы это сказать мягко... охренели и делют дичь из вязкого вещества и палок и при этом палок систематически не докладывают.
С другой стороны вы купили бюджетку за очень не дорого.
Вы купили ноут с дискреткой (что сразу плохо, ибо в ноуте оно не нужно). А в бюджетке оно не нужно и проблемно вдвойне. Это же касается и охлаждения и места в ноуте, его комплектации опреденным форм-фатором дисков и т.д.
Вы говорите про драйвер для Линукса, однако тут вопросы к производителю железа, а не к производителю ноута, ибо он (это, к сожалению, правда, хоть и очень не хочется) задумывался под винду, ну вот так, да.
Апгрейд - ноутбуки не приспособлены к этому, если не разработаны специально под это, и, обычно, используются AS IS, все остальное - на ваш страх и риск.
Акум - вопрос, а пробовали в Вантаже смотреть, есть ли параметр "заряжать на 80% при работе на зарядке" + скорее всего вы его и использовали по-большей части на ней? Ну вот плоды, к сожалению, ИМХО, это должно быть сразу в БИОСе, но есть что есть.
Бонусная переферия (мышь и тд) - это сразу мусор, вроде как все технари это все прекрасно понимают, нет? ) Ну и после возни с жидким металлом перепаять микрик в мышке вроде как не должно быть сложным.
Грубо говоря простыми словами - вы купили бюджетный автомобиль для езде в городе, а пытались его использовать как внедорожник.
Но да, это не оправдывает некоторых костыльных и дурацких решений (а возможно они сделаны намеренно для запланированного устаревания).
Lenovo по цене/качество сейчас вообще самое лучшее решение на рынке (Lenovo ThinkBook G6+ / Lecoo и тд).
Там кровати-то двигать бесполезно давно)
Кто на первой фотографии - робот? (:
Почему нет?
Вот не надо пинять на язык, ладно)
Преимуществ, когда один стэк и на фронте и на бэке - куча, нода уже взрослая и отлично показала себя в проде, библиотек на все случаи жизни, а если что-то не так - всегда можно залезть и поправить.
Все проблемы у людей от головыи рук, не надо инструменты винить.
При безграмотной арзитектуре, погоне за хайпом и борще в голове вас нечего не спасёт. Выбирать надо под задачу, под вектор развития и под приемственность (сходите ваканчии под go/rust помониторьте).
У нас в университете был лифт, когда я туда поступил, он уже не работал. У меня учился там старший товарищ, и даже когда он поступал - лифт тоже не работал. На одном из капустников мы задали вопрос нашему декану - а вообще этот лифт когда-либо работал? Декан хитро улыбнулся и сказал что да, при сдаче корпуса, но потом его сразу отключили. На вопрос почему, Декан с ещё бОльшей хитрецой ответил так: "Представьте, что лифт вмещает n человек, а хотят на нем уехать k, и k всегда много больше n..." - это про поиск девушек в IT, если вы не поняли про что я)
Уберите этот фильтр и будет куда проще.