Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).
SVN, например, проще и интуитивно понятнее для не-программистов, которым объяснить идею и научить пользоваться системой контроля версий бывает достаточно сложно. А ещё у него очень удобные идентификаторы коммитов - простые и понятные всем числа, а не хэши. Идущие последовательно, так что по номеру ревизии сразу понятно, какая версия новее, какая старее, и т.п. Когда всё это дело активно используется, а репозиториев десятки и сотни, уйти на другую систему может быть достаточно сложно — взвешиваешь плюсы и минусы перехода, и плюсов оказывается меньше.
...LG запустила программу обновляемой техники. Президент компании объявил, что эта программа должна будет бросить вызов представлениям о том, что дорогая бытовая техника разрабатывается с учётом запланированного устаревания.
Я почему-то вижу тут некое противоречие. На моей практике, по крайней мере, всё хардовое и необновляемое — устаревало разве что морально (и то, с оговорками). А вот всё онлайново-обновляемое, наоборот устаревает как-то даже быстрее, иногда моментально (и, часто, именно по воле производителя). Старые плееры, консоли, телефоны, вот это вот всё, пусть даже этим девайсам десятки лет уже, но их включаешь, и оно работает. А с момента прихода в эти девайсы интернета и обновлений — уже не факт. Зависимость от серверов и сервисов рано или поздно превращает девайс в тыкву. И бытовуху, вроде стиральной машины, я хочу "тупую", насколько это возможно. Ещё мне не хватало в телефон лезть, чтобы стирку запустить, вместо того, чтобы просто кнопку нажать. Вообще, как по мне, вся эта нынешняя тенденция по "упрощению" физических интерфейсов посредством переноса их на тачскрины (в автомобилях) или на смарты (в бытовой технике) это просто удешевление производства под модным соусом "умности" и "современности".
Вот да, всё так и есть. Я поэтому стараюсь новичкам привить мысль, что в процессе разработки всегда нужно задумываться — а зачем именно мы делаем то, что делаем? Какова цель написания данного кода? Но всё равно, не всегда получается достигнуть понимания. Даёшь, допустим, несложную задачку на пару часов (ну там, скриптик написать, перекладывающий поток данных из COM-порта в сокет). Через неделю интересуешься, как там дела; отвечают, что нужно ещё полгода разработки ) Ээ, окей, а зачем? А вот, чтобы построить универсальную расширяемую архитектуру, красиво всё на паттернах запилить, и всё в таком духе... В очередной раз пытаешься объяснить, что здесь всё это совершенно не нужно, потому что задача вообще не в этом, а нужен простой скриптик на пол-страницы. На этом моменте, бывает, даже обижаются, что я ничего не понимаю и рушу их идеалы )
И ещё вот что интересное замечаю. Многие, видя большой, сложный, запутанный код, проникаются уважением к автору — мозг! Во какое написал! (разбираться в этом мы, конечно, не будем)). А когда встречают простой, короткий и понятный код от более опытного коллеги, думают — банальщина, неинтересно. И, наверное, так получается, что подсознательно хочется быть похожим на "мозга", чтобы и от твоего кода все "ахали".
Про "код — это пассив" — чистая правда. Но как же трудно бывает объяснить это новичкам. Что цель на самом деле — решить задачу, а не писать код. Я думаю, что частично понимаю причины такой ситуации — когда ты молод, позитивен, не "побит жизнью", когда ты всерьёз любишь кодить, когда голова свеженагружена шаблонами проектирования, бест-практиками, книжками, курсами и всем таким прочим по вкусу, то хочется быстрее применить всё это дело на практике. Но до чего это бывает гипер-выражено, это-ж словами не передать. Чем дальше, тем больше начинаю считать, что умелое удаление кода — даже более важный навык, чем его написание.
Думаю, конкретно такое сравнение некорректно. То, что происходит, больше похоже на эпоху индустриализации, когда станки стали заменять рабочие руки. И то, сравнение будет не совсем верным. Тогда заменяли руки, а мозги-то как раз становились нужнее, потому что машины нужно разрабатывать и обслуживать. Теперь же заменяют как раз мозги. А таких процессов и в таких масштабах я в истории не припомню. Это новое.
Быть может, замена условным гуглом мозгов не так и страшна была бы, если бы это хорошо работало где-то кроме шаблонных ситуаций вроде решения примера из домашки. Я стал замечать странную тенденцию - в моменты, когда поисковик решил бы проблему, люди его просто не используют (не умеют? не хотят? непонятно). Всё чаще сталкиваюсь с ситуациями, когда людям что-то нужно, причём ответ на вопрос чуть ли не первых строках выдачи будет, но они просто не ищут. И это я про программистов, если что.
Десятков тысяч, а так всё верно. Как только люди начали сильнее социализироваться, а потом от охоты/собирательства к земледелию постепенно переходить, так мозги скорее всего на спад и пошли, что вполне объяснимо - для успеха в деле выживания больше не нужно было быть условным мастером на все руки, ибо началось разделение труда и появились специализации.
Начиная со второй картинки статьи и дальше, сюжет всё сильнее напоминал мне сказку про кашу из топора. Первоначальная структура постепенно обвешивается, обвешиватся и обвешивается сторонними сервисами, децентрализация с каждым шагом уходит, и в конце оказывается, что собственно блокчейн это всего лишь один из многих квадратиков на схеме, не очень понятно зачем вообще теперь нужный.
У меня крепнет ощущение, что я был неправильно понят. Я ни в коем случае не предлагаю использовать final ни "для оптимизации", ни "на всякий случай". Только для того, для чего оно предназначено. Например, чтобы явно указать поддерживающему программисту, у которого по какой-то причине возникнет желание метод перегрузить, что он идёт в неверном направлении, и автором предполагалось, что работать оно должно не так, как он считает. Да, действительно, хорошо бы и комментарий иметь от автора, где сказано, почему оно так. Но один комментарий сам по себе делу может и не помочь, его могут не заметить; final же гарантирует, что не пропустят. А вероятность того, что код, возможно, станет чуточку быстрее, можно воспринимать просто как приятный бонус.
Для общего случая - целиком и полностью согласен. Всерьёз оптимизировать нужно там, где наличествуют бутылочные горлышки, а их покажут только замеры. Но здесь не тот случай. Я считаю, что добавление ключевого слова, которое придаст коду больше однозначности - само по себе полезно. Поэтому и считаю "бесплатным". Спецификатор override тоже ведь можно не писать (и я его поначалу его не использовал), но с ним код становится понятнее (и когда я это заметил, то стал стараться его использовать).
И не совсем оптимизация - ассемблерный выход с final и без может быть одинаков.
Да, и я именно это и имел в виду, когда писал, что "хуже не сделает". Если final делает код (или, может, видение автора кода) понятнее, и при этом даёт хотя бы малую вероятность, что станет чуть быстрее, почему бы его не использовать?
Но часто, просто не слишком общительный интроверт, который любит именно программировать, то есть говорить машине, как именно она (машина) должна что-то сделать. А для общения с нейронками, похоже, совсем другой скилл нужен будет - объяснять машине, что сделать, а не как. То есть, программисту кем-то вроде начальника нужно будет стать. И да, придётся постоянно мириться с тем, что сделано будет не совсем так, как хотелось бы, потому что исполнитель не идеален, не всегда понимает что от него хотят, или понимает как-то очень по-своему. Вот это вот всё, а не программировать в привычном понимании. Далеко не всем такой жизни захочется.
И тут возникает вопрос, что в данном контексте считать ложными данными? Только ли те, что специально созданы людьми? А как на счёт всего того контента, что уже сейчас активно генерируют сами нейросети? Да, первые сети учились только на контенте, созданном людьми. Другого не было. Но чем дальше, тем большая часть данных в Сети будет уже сама создана нейросетями, и новые сети по факту будут всё больше и больше обучаться на результате работы других сетей, которые тоже частично учились на результатах других сетей, и т.д. Может в итоге оказаться, что "корни" всего этого дела будут потеряны, и что есть "не ложная" информация станет совершенно неочевидным.
А касательно именно кода, для сеток это и проблемой-то, скорее всего, не будет. Сетки не станут просто вслепую копипастить. Будут не просто генерировать код, но и анализировать и тестировать. И справляться с этим, похоже, станут лучше людей.
Меня последние полгода не покидает ощущение, что мы уже где-то совсем рядом, всего в паре шагов от технологической сингулярности. Текстовая нейросеть общего назначения, которая пишет за вас код, делает реверс ассемблера, сочиняет стихи и пишет рефераты. Круто. Какие возможности! Но стоит задуматься поглубже, и окажется, что всё поменялось. Мир не будет прежним. Как бы не оказалось, что голова хомо сапиенсам скоро станет нужна только для того, чтобы в неё есть.
Вот возьмём, к примеру, школьное обучение. Выходит, что уже сейчас домашние задания давать становится бесполезно, потому что никто своим мозгом решать их не будет, все будут ответы от сетки выдавать, которые от реальных-то и не отличить. А потом постепенно люди станут вовсе отказываться учиться (и так-то мало кто это дело любил). Зачем что-то делать мозгом, если сетка у тебя в кармане сделает всё моментально и в разы лучше?
Очень интересно, к чему всё придет. И как-то немного страшновато.
Вот да, я тоже скорее к такому пониманию понятия "программист" склоняюсь. Не просто занимающий должность программиста на работе, а программист "по жизни".
"Разработчик" это слишком общее определение, всегда требующее уточнения. Разработчик аппаратных средств, например. Разработка ПО это только частный случай.
Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).
Под какую корку? ) Наверное всё-таки "уйдёт в подкорку", это же про вполне конкретные отделы мозга выражение, которые в обиходе "подкоркой" именуют.
SVN, например, проще и интуитивно понятнее для не-программистов, которым объяснить идею и научить пользоваться системой контроля версий бывает достаточно сложно. А ещё у него очень удобные идентификаторы коммитов - простые и понятные всем числа, а не хэши. Идущие последовательно, так что по номеру ревизии сразу понятно, какая версия новее, какая старее, и т.п. Когда всё это дело активно используется, а репозиториев десятки и сотни, уйти на другую систему может быть достаточно сложно — взвешиваешь плюсы и минусы перехода, и плюсов оказывается меньше.
По-моему, Интернет в списке лишний. Это не научное, и не открытие. Это технология, плод труда инженеров. Вакцина(ы) от Covid-19 — аналогично.
Я почему-то вижу тут некое противоречие. На моей практике, по крайней мере, всё хардовое и необновляемое — устаревало разве что морально (и то, с оговорками). А вот всё онлайново-обновляемое, наоборот устаревает как-то даже быстрее, иногда моментально (и, часто, именно по воле производителя). Старые плееры, консоли, телефоны, вот это вот всё, пусть даже этим девайсам десятки лет уже, но их включаешь, и оно работает. А с момента прихода в эти девайсы интернета и обновлений — уже не факт. Зависимость от серверов и сервисов рано или поздно превращает девайс в тыкву. И бытовуху, вроде стиральной машины, я хочу "тупую", насколько это возможно. Ещё мне не хватало в телефон лезть, чтобы стирку запустить, вместо того, чтобы просто кнопку нажать. Вообще, как по мне, вся эта нынешняя тенденция по "упрощению" физических интерфейсов посредством переноса их на тачскрины (в автомобилях) или на смарты (в бытовой технике) это просто удешевление производства под модным соусом "умности" и "современности".
Вот да, всё так и есть. Я поэтому стараюсь новичкам привить мысль, что в процессе разработки всегда нужно задумываться — а зачем именно мы делаем то, что делаем? Какова цель написания данного кода? Но всё равно, не всегда получается достигнуть понимания. Даёшь, допустим, несложную задачку на пару часов (ну там, скриптик написать, перекладывающий поток данных из COM-порта в сокет). Через неделю интересуешься, как там дела; отвечают, что нужно ещё полгода разработки ) Ээ, окей, а зачем? А вот, чтобы построить универсальную расширяемую архитектуру, красиво всё на паттернах запилить, и всё в таком духе... В очередной раз пытаешься объяснить, что здесь всё это совершенно не нужно, потому что задача вообще не в этом, а нужен простой скриптик на пол-страницы. На этом моменте, бывает, даже обижаются, что я ничего не понимаю и рушу их идеалы )
И ещё вот что интересное замечаю. Многие, видя большой, сложный, запутанный код, проникаются уважением к автору — мозг! Во какое написал! (разбираться в этом мы, конечно, не будем)). А когда встречают простой, короткий и понятный код от более опытного коллеги, думают — банальщина, неинтересно. И, наверное, так получается, что подсознательно хочется быть похожим на "мозга", чтобы и от твоего кода все "ахали".
Про "код — это пассив" — чистая правда. Но как же трудно бывает объяснить это новичкам. Что цель на самом деле — решить задачу, а не писать код. Я думаю, что частично понимаю причины такой ситуации — когда ты молод, позитивен, не "побит жизнью", когда ты всерьёз любишь кодить, когда голова свеженагружена шаблонами проектирования, бест-практиками, книжками, курсами и всем таким прочим по вкусу, то хочется быстрее применить всё это дело на практике. Но до чего это бывает гипер-выражено, это-ж словами не передать. Чем дальше, тем больше начинаю считать, что умелое удаление кода — даже более важный навык, чем его написание.
А почему "белый дварф"? Аж глаз режет. По-русски такие звёзды "белыми карликами" всю жизнь были.
Думаю, конкретно такое сравнение некорректно. То, что происходит, больше похоже на эпоху индустриализации, когда станки стали заменять рабочие руки. И то, сравнение будет не совсем верным. Тогда заменяли руки, а мозги-то как раз становились нужнее, потому что машины нужно разрабатывать и обслуживать. Теперь же заменяют как раз мозги. А таких процессов и в таких масштабах я в истории не припомню. Это новое.
Быть может, замена условным гуглом мозгов не так и страшна была бы, если бы это хорошо работало где-то кроме шаблонных ситуаций вроде решения примера из домашки. Я стал замечать странную тенденцию - в моменты, когда поисковик решил бы проблему, люди его просто не используют (не умеют? не хотят? непонятно). Всё чаще сталкиваюсь с ситуациями, когда людям что-то нужно, причём ответ на вопрос чуть ли не первых строках выдачи будет, но они просто не ищут. И это я про программистов, если что.
Десятков тысяч, а так всё верно. Как только люди начали сильнее социализироваться, а потом от охоты/собирательства к земледелию постепенно переходить, так мозги скорее всего на спад и пошли, что вполне объяснимо - для успеха в деле выживания больше не нужно было быть условным мастером на все руки, ибо началось разделение труда и появились специализации.
Начиная со второй картинки статьи и дальше, сюжет всё сильнее напоминал мне сказку про кашу из топора. Первоначальная структура постепенно обвешивается, обвешиватся и обвешивается сторонними сервисами, децентрализация с каждым шагом уходит, и в конце оказывается, что собственно блокчейн это всего лишь один из многих квадратиков на схеме, не очень понятно зачем вообще теперь нужный.
У меня крепнет ощущение, что я был неправильно понят. Я ни в коем случае не предлагаю использовать final ни "для оптимизации", ни "на всякий случай". Только для того, для чего оно предназначено. Например, чтобы явно указать поддерживающему программисту, у которого по какой-то причине возникнет желание метод перегрузить, что он идёт в неверном направлении, и автором предполагалось, что работать оно должно не так, как он считает. Да, действительно, хорошо бы и комментарий иметь от автора, где сказано, почему оно так. Но один комментарий сам по себе делу может и не помочь, его могут не заметить; final же гарантирует, что не пропустят. А вероятность того, что код, возможно, станет чуточку быстрее, можно воспринимать просто как приятный бонус.
Для общего случая - целиком и полностью согласен. Всерьёз оптимизировать нужно там, где наличествуют бутылочные горлышки, а их покажут только замеры. Но здесь не тот случай. Я считаю, что добавление ключевого слова, которое придаст коду больше однозначности - само по себе полезно. Поэтому и считаю "бесплатным". Спецификатор override тоже ведь можно не писать (и я его поначалу его не использовал), но с ним код становится понятнее (и когда я это заметил, то стал стараться его использовать).
Да, и я именно это и имел в виду, когда писал, что "хуже не сделает". Если final делает код (или, может, видение автора кода) понятнее, и при этом даёт хотя бы малую вероятность, что станет чуть быстрее, почему бы его не использовать?
Пусть даже оптимизация в конкретном случае окажется и не шибко эффективная, но если она "бесплатная", то почему бы нет? Хуже-то точно не сделает.
Но часто, просто не слишком общительный интроверт, который любит именно программировать, то есть говорить машине, как именно она (машина) должна что-то сделать. А для общения с нейронками, похоже, совсем другой скилл нужен будет - объяснять машине, что сделать, а не как. То есть, программисту кем-то вроде начальника нужно будет стать. И да, придётся постоянно мириться с тем, что сделано будет не совсем так, как хотелось бы, потому что исполнитель не идеален, не всегда понимает что от него хотят, или понимает как-то очень по-своему. Вот это вот всё, а не программировать в привычном понимании. Далеко не всем такой жизни захочется.
И тут возникает вопрос, что в данном контексте считать ложными данными? Только ли те, что специально созданы людьми? А как на счёт всего того контента, что уже сейчас активно генерируют сами нейросети? Да, первые сети учились только на контенте, созданном людьми. Другого не было. Но чем дальше, тем большая часть данных в Сети будет уже сама создана нейросетями, и новые сети по факту будут всё больше и больше обучаться на результате работы других сетей, которые тоже частично учились на результатах других сетей, и т.д. Может в итоге оказаться, что "корни" всего этого дела будут потеряны, и что есть "не ложная" информация станет совершенно неочевидным.
А касательно именно кода, для сеток это и проблемой-то, скорее всего, не будет. Сетки не станут просто вслепую копипастить. Будут не просто генерировать код, но и анализировать и тестировать. И справляться с этим, похоже, станут лучше людей.
Меня последние полгода не покидает ощущение, что мы уже где-то совсем рядом, всего в паре шагов от технологической сингулярности. Текстовая нейросеть общего назначения, которая пишет за вас код, делает реверс ассемблера, сочиняет стихи и пишет рефераты. Круто. Какие возможности! Но стоит задуматься поглубже, и окажется, что всё поменялось. Мир не будет прежним. Как бы не оказалось, что голова хомо сапиенсам скоро станет нужна только для того, чтобы в неё есть.
Вот возьмём, к примеру, школьное обучение. Выходит, что уже сейчас домашние задания давать становится бесполезно, потому что никто своим мозгом решать их не будет, все будут ответы от сетки выдавать, которые от реальных-то и не отличить. А потом постепенно люди станут вовсе отказываться учиться (и так-то мало кто это дело любил). Зачем что-то делать мозгом, если сетка у тебя в кармане сделает всё моментально и в разы лучше?
Очень интересно, к чему всё придет. И как-то немного страшновато.
Вот да, я тоже скорее к такому пониманию понятия "программист" склоняюсь. Не просто занимающий должность программиста на работе, а программист "по жизни".
"Разработчик" это слишком общее определение, всегда требующее уточнения. Разработчик аппаратных средств, например. Разработка ПО это только частный случай.