Comments 50
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Эти слова принадлежат выдающемуся советскому учёному, одному из пионеров теоретического и системного программирования академику Андрей Петровичу Ершову (статья «О человеческом и эстетическом факторах в программировании», 1972):
Мне кажется эти слова хорошо определяют настоящее и будущее программирования.
«Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы,
бросать навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация — удел насекомых».
— Роберт Хайнлайн
Два коррелирующих высказывания.
Не похоже на то. Высказывание Хайнлайна – фактически про горизонтальное/вертикальное масштабирование, и оно противоречит наблюдаемым фактам (росту специализации в ходе развития отрасли, в частности IT), в то время как высказывание Ершова – про структуру компетенций отдельной профессии.
Хайлайн говорит о том, что любой человек должен владеть всеми компетенциями бухгалтера, а Ершов – о том, что некоторые люди (те, кто выбрали профессию программиста) должны владеть некоторыми компетенциями бухгалтера (аккуратностью).
Думается что это все это классическое - От частного к общему или наоборот, я уже не помню....,
Формально да, но в данном случае это полностью меняет смысл.
Тут приходит на ум классический пример из экономики, почему законы, работающие на микроуровне, не обязательно работают на макро-: если некоторые люди на трибунах стадиона во время матча встанут, им будет лучше видно, но если все люди на трибунах встанут, лучше видно им не будет (но при этом все будут стоять). [от разницы в росте предусмотрительно предлагаю абстрагироваться]
Справочные и обучающие ресурсы могут появиться прямо в вашей среде IDE, чтобы вам не пришлось покидать ее и прерывать рабочий процесс.
Ну вот я смотрю на это и в упор не понимаю, какой смысл такого «ИИ», который по сути генерирует тривиальные бесполезные комментарии вида
i++; //this code increments i
А подстрочник, который обучает использованию того или иного языка программирования и его библиотек, появился на рубеже 1980-х и 1990-х, и он уже тогда был ничуть не менее информативен, чем современные аналоги.
Необходимо проводить научную оценку и выдвигать проверяемые критерии к коду, библиотекам и фреймворкам. Производительность, энергопотребление, соответствие стандартам, читаемость, сравнение подходов для решения типовых задач. Ну и конечно же обсуждение моделей, парадигм и архитектур, создание лучших языков, с красивыми обоями и котиками.
Это и будет будущее программирования.
Конечно, это будет в будущем если люди осилят что-то кроме современных экономических моделей, ибо сейчас компании и структуры просто пользуются опенсорс кодом почти ничего не привнося в него, как и в целом в образование и науку.
компании и структуры просто пользуются опенсорс кодом почти ничего не привнося в него
Некоторые компании и структуры выводят целые библиотеки и инструменты в опенсорс
Обычно в опенсорс корпорации выкладывают непрофильный код - все что не создаёт им явных конкурентных преимуществ. Все самое вкусное и полезное остаётся внутри и строго охраняется.
Верх цинизма это когда при наличии массы документации, эффективные способы использования решения, выложенного в опенсорс, для сторонних разработчиков остаются недокументированными. При этом они крайне неэффективно тратят ресурсы своих работодателей (а значит вероятных конкурентов) пытаясь внедрять технологию на хайпе.
Вот тебе несколько примеров кода и его комментариев:
1. i++; // Увеличиваем кол-во товаров, подходящих по условию выборки пользователем
2. i++; // Повышаем степень "энтропии" с каждой коллизией объекта на сцене
3. i++; // Увеличим кол-во контролов, т.к. пользователь ещё раз нажал "Добавить"
4. i++; // Повышаем температуру, т.к. прошла секунда
Понимаешь к чему я?
i++; //this code increments i
Это лишь пример того, что код может быть одинаковым в разных проектах (или даже в рамках одного), а описание того, что он делает - разное. Потому что применяется в разных местах. Переменная i может быть разная в данном случае, только вот комментарий от ИИ мы получим тот же.Так что нет смысла пытаться принижать меня, т.к. это не мой код, а пример.
var++; //this code increments var
N.B. Разумеется, я говорю про системы, предназначенные для анализа семантики кода, а не перечисления выполняемых кодом арифметических действий. Бессмысленные комментарии вида «увеличить x на 1» анализа семантики не требуют.
Любая программа, построенная на достаточно сложных эвристиках, периодически ошибается — будь то шахматная программа, основанная на анализе возможных ходов или нейросеть, анализирующая лица на видео.
N.B. Да, все современные нейросети — это тоже вид эвристики. Отличающийся только тем, что настройка параметров производится автоматически — в процессе «обучения» на специально подобранной выборке.
Компьютер ограничен теорией алгоритмов, в свою очередь ограниченной формальной логикой. Именно потому существует множество задач, которые компьютер не может решить. Но мышление человека формальной логикой никак не ограничено. И это позволяет человеку решать задачи, недоступные для компьютера.
Любой логический парадокс (кто бреет брадобрея?) и компьютер либо завис, либо выдал заведомо ошибочный ответ. Но человек такие задачи решает — и на бытовом уровне, и в рамках матлогики. Более того, логические парадоксы — неотъемлемая часть человеческого интеллекта.
Автор программы может предусмотреть множество типичных случаев, но не может предусмотреть всё. Более того, по мере усложнения эвристик наступит момент, когда разные эвристики начнут противоречить друг другу: найдутся участки кода, на которых разные части анализатора дадут разные ответы.
Брадобрея не существует (на что указал сам Рассел, сформулировавший парадокс брадобрея).
Но это не значит, что не существует алгоритма, дающего либо всегда правильный ответ, либо «хз».Да, такой алгоритм существует — тот самый, который ищет конструкции ++x; (и аналогичные тривиальные) и пишет к ним комментарии вида «значение x увеличивается на 1», а для всех прочих строк пишет «хз». Т.е. вообще не содержит семантического анализатора.
Но я выше прямым русским языком писал, что не рассматриваю подобные примитивные имитации, а говорю только об алгоритмах, способных анализировать семантику кода. Добавлю: на уровне, позволяющем писать реально полезные комментарии. Программа, пишущая «хз» даже в тривиальных случаях, никому не нужна, а эвристики, позволяющие генерировать нетривиальные комментарии, не могут не ошибаться.
N.B. Достаточно посмотреть на статические анализаторы кода (решающие в чём-то схожую, но на порядки более простую задачу), регулярно выдающие ложные сообщения об ошибках и столь же регулярно не замечающие реальные ошибки. А в многократно более сложной системе комментирования кода возможностей для появления ошибочных комментариев будет куда больше.
И вы вместе с Расселом к этому пришли формальной логикой, верно?Смысл парадокса в том, что формально-логический ответ лежит вне рамок формально-логической системы вопроса. На вопрос «кто бреет брадобрея?» человек может ответить: «брадобрея не существует» (осознанно выйдя за границы вопроса), а компьютер такой ответ дать не может.
PS Правда программист тоже особым умом не блещет, если думает что у него есть шанс сделать это без ошибок.
Обычно, когда меня спрашивают что-то подобное, я отвечаю парой цитат (с вашего позволения я оставлю их на английском, чтоб не портить переводом):
Первая от Фредерика Брукса:
"The programmer, like the poet, works only slightly removed from pure thought-stuff, build castles in the air, from air, creating by exertion of the imagination."
А вторая от Джонатана Эдвардса:
“Programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements"
В этом и есть суть - весь путь развития программирования, все эти высокоуровневые языки, ООП, декомпозиции и т.д. - всё это лишь для того, чтобы облечь весьма сложные парадигмы в максимально простую форму, чтобы бороться с возрастающей сложностью (и программист в этой битве как правило всегда в проигрыше).Фортран семидесятых несравним, скажем, с современным С#. Ну и пакеты, типа того же tensorflow, они фантастические. Я за полдня могу набросать в питоне, сортирующий собачек и котиков, а четверть века назад я б полмесяца на это убил, если не больше.
Что касается будущего, то я считаю, что так или иначе через несколько десятилетий графическое программирование вероятно сильно потеснит олдскульное текстовое (сейчас это серъёзно не воспринимается, но там явно есть потенциал).
Хотя вот все прошедшие выходные я угробил на то, чтобы собрать "привет, мир" приложение для андроида из под линукса на C#, используя dotnet и авалонию, так что есть ещё куда развиваться.
Программирование - это командная работа по созданию ценности для клиента через код.
— Robert S. Barton (1967)
"Причина существования большинства типов данных — это производительность. С увеличением производительности в миллион раз может случиться фундаментальный сдвиг парадигмы."
Это конечно очень важная причина, но вообще есть еще несколько - это, например выразительность языка (объяснение, что объект умеет делать) и то, что реальный мир тоже состоит из различных типов объектов.
Поэтому языки со слабой и динамической типизацией тоже сползают к этому (typescript и нотации в python)
В оригинале там "Most data structures exist because of speed" и по ощущениям это уже сбывшееся пророчество. В 2022 (почти 20 лет спустя) программисты на python не думают о том, нужно ли им красно-чёрное дерево или хеш, они просто используют встроенный тип данных.
В том же абзаце, правда, странное:
Semantically, strings are more or less a subset of lists in which the elements are characters. So why do you need a separate data type? You don't, really. Strings only exist for efficiency. But it's lame to clutter up the semantics of the language with hacks to make programs run faster. Having strings in a language seems to be a case of premature optimization.
Но по-моему это просто не очень хороший пример - в python строки всё-таки семантически отличаются от произвольного массива чисел, да и в целом юникодные строки это очень нетривиальный объект.
Судя по контексту, автор имел в виду, что логику работы со строками нужно выносить из ядра языка в библиотеки.
Я апеллирую автору - говорю "нет, это не единственная причина существования структур данных, хотя и эта причина важна".
Есть как минимум еще парочка - выразительность языка и гарантии.
Я имею в виду под "структурами данных" типы и классы.
Есть фундаментальные ограничения - мы описываем средствами ЯП абстракции и модели реального мира, они разные, из этого органически растет требование, что сущности программирования должны быть разными.
То есть разные наборы данных нужны для описания предметной области.
То, что js и python прячут типы, но типы от этого никуда не деваются.
Второй момент - правильные инструменты описания типов придают языку выразительность.
python и js используют юнит тесты зачастую не от хорошей жизни, а для тестирования типичных случаев и гарантий валидности данных. Библиотеки же обычно спроектированы так, чтобы принимать параметры базовых типов, потому что продвинутые варианты сложны для использования, а типы данных плохо обеспечивают проверку инвариантов.
Статическое описание типов позволяет проектировать более качественное апи и обеспечить защиту объектов от невалидных состояний.
То есть уже давно всем пофиг, как сделаны словари под капотом, и зачастую используются неоптимальные алгоритмы и структуры данных, это уже так.
Но это не уменьшает важности хорошего описания высокоуровневых объектов и к ним предъявляются похожие требования.
То, о чём вы говорите - Abstract Data Type. То, о чём говорит автор - Data Structure.
The data structure implements the physical form of the data type
Ваши рассуждения верны (или как минимум применимы) в отношении ADT (типов и классов).
Согласен. Причины существования типов данных:
Связь реальностью;
Оптимизация
Те типы, которые хороши по обоим параметрам, глубоко вросли нам в мозг и без них мы программирование не представляем.
Например, словари с точки зрения математики - это множество пар [ключ]=значение. Но почему не (ключ, значение) ? Потомучто:
Мы ищем значение по ключу но не наоборот;
Хеши
То есть словари, хотя бы частично, своим существованием обязаны оптимизации.
На самом деле, если глубоко копнуть, то даже целые числа - оптимизация. Ведь они всего лишь отражают число объектов в множестве. А самого множества может уже и не быть...
Поиграться то можно и сейчас, но что то реальное будет, когда будущее поставит какие-нибудь вопросы ребром перед современным программированием. Вот тогда, решая эти вопросы, и появится программирование будущего. Потом появятся другие вопросы и опять ответом будет программирование будущего, но уже другое.
Пытаться придумать что-то сейчас и реально рассчитывать на практический смысл это будет как представление прошлого о современном. Т.е. мимо, в лучшем случае весьма отдалённо. Достаточно взглянуть на иллюстрации из классики фантастики и сравнить с реальностью.
Не понимаю, за что минусят статью, ведь составлена она неплохо. Если вы не согласны с идеями (как и я), не обязательно минусить. Можно высказать свои аргументы в комментариях.
Причина существования большинства типов данных — это производительность. С увеличением производительности в миллион раз может случиться фундаментальный сдвиг парадигмы.
Через сто лет программисты захотят такой язык, на котором можно оперативно и с минимальными усилиями набросать первую, невероятно неэффективно работающую версию программы.
Хех, так это не будущее, это безжалостное настоящее :)
Не имеет значение, как кто-то пытается внушить нам веру, что в программировании что-то измениться в будущем. Ничего не изменится, и даже спустя сто лет. По крайней мере, пока не измениться фундаментальные основы математики и физики. Да, Физики, так как это следущий уровень, как мне кажется, в программировании будущего.
Программирование по законам математики есть и никуда не денется, а вот программирование физических явлений только начинается. ООП как первый шаг за которым последуют ещё более сложные шаги.
Конечно. Основная мысль, которую я выделил для себя, это попытка сделать программирование настолько доступным, что программист, как профессия уже не нужна. "Программирование без программиста". Это и возмутило. Скорее всего я не понял ваш вопрос. "Почему?" Можете ли вы уточнить к чему именно был адресован этот вопрос?
И есть тонны работ 60-70 годов, где раскрыта суть более программистского программирования в отличие от текущего бастардского недопрограммирования.
Точно, что программирование не должно превратиться в игру для всех желающих. Это есть и должен быть уникальный процесс, основанный на научных подходах.
Найти фундаментальные оператор - не существует никакого минимального набора операторов, любой набор определяется через эквивалентность машине Тьюринга или лямбда исчислению, в языке может существовать N разложений на комбинации каждая из которых Тьюринг полна
Будущее программирования