Никто не знает и не понимает, что такое «программирование» и что такое «компьютер». Какими они задумывались, какими они могли бы быть и какими они могут стать.
Недавно я разговаривал с физтехом и он мне с железобетонной уверенностью выпалил определение: «Программирование — это написание четких инструкций для компьютера». Я же, пересмотрев десятки лекций Кнута, опубликовав десятки переводов Ликлайдера, Ванневара Буша и Дугласа Энгельбарта, немного призадумался о природе его догматичности и отсутствию «сомнений» в своей правоте.
Предлагаю обсудить будущее программирования и рассмотреть взгляды нескольких философов и парочки практиков, которые работают над созданием будущего программирования прямо сейчас.
(Дополняйте своими находками «ростков будущего» и ключевыми статями и лекциями.)
Амджад Масад, 2022
Амджад Масад создает браузерное IDE с целью сократить время от мысли до кода. Недавно он проанонсировал планируемые фичи, на что Пол Грэм восторженно написал:
Replit имеет большие амбиции, чем думает большинство людей. Они не просто хотят разрешить программирование в браузере. Они хотят продвинуть вперед то, что такое программирование.
Вот такие фичи хочет внедрить Replit:
Своевременная помощь. ИИ предложит учебные пособия на основе того, что вы кодируете, и, возможно, даже некоторых друзей, которые могли бы помочь вам, исходя из того, что они кодировали в прошлом.
Справочные и обучающие ресурсы могут появиться прямо в вашей среде IDE, чтобы вам не пришлось покидать ее и прерывать рабочий процесс.
Мы переписываем функцию Explain Code, чтобы сделать ее более полезной. В новой версии вы сможете выбрать свой уровень знаний, а ИИ изменит способ объяснения кода в соответствии с вашим уровнем.
Наконец, и это уже построено и скоро будет выпущено, ИИ сможет находить для вас ошибки, которые не может сделать никакой другой инструмент, включая логические и человеческие ошибки.
Сумасшедшая большая идея здесь заключается в том, что мы думаем, что это может стать началом универсальной среды обучения, симбиоза человека и машины, выходящего за рамки простого кодирования.
Далее идут ссылки и краткие выжимки идей теоретиков «программирования» и повстанцев, ратующих за настоящую компьютерную революцию.
Джозеф Ликлайдер, 1960
«Любой человек и любая компания, использующие компьютер в интерактивном режиме, должны испытывать благодарность по отношению к Лику»
— Боб Тейлор, основатель Xerox PARC и основатель исследовательской лаборатории DEC
- Джозеф «Лик» Ликлайдер: «Симбиоз человека и компьютера» (1960), часть 1
- Джозеф «Лик» Ликлайдер: «Межгалактическая компьютерная сеть» (1963 год)
- Джозеф «Lick» Ликлайдер: «Интергалактическая компьютерная сеть» и «Симбиоз человека и компьютера»
Андрей Ершов, 1982
Эта заметка появилась на свет при размышлении о разработке программного обеспечения как человеческой деятельности. Если в этом плане рассматривать работу программиста, то нужно различать два, как мне кажется, весьма разных её вида: к одной из них программист относится как слуга, а к другой — как хозяин.
- Программирование — вторая грамотность
- Андрей Ершов: «Два облика программирования»
-
Дональд Кнут: как я занялся анализом алгоритмов и ради этого поехал в СССР (37,91,97/97)
Брет Виктор, 2013 (1973)
Технологии развиваются быстро, мышление людей — медленно.
Брет Виктор выступил на конференции в 2013 году, но он вещал как-будто бы в 1973 году про будущее программирования через 40 лет. Его слайды были на прозрачной бумаге и на световом проекторе (как у меня в универе в 2001 году) .
Беда не в том, что многие через 40 лет удивятся, что в 1973 году были такие идеи насчет программирования, более негативный сценарий в том, что в 2013 году люди будут иметь четкое представление о том, что такое «программирование». И будут обсуждать детали и частные ситуации только одной парадигмы программирования из тех нескольких, что я показал сегодня, и откинут все остальные пути развития программирования. Беда в том, что подавляющее большинство программистов вырастет на догмах.
В 1973 году было очень много идей по поводу программирования и информационных систем потому что никто толком не знал, что такое программирование и каким оно может быть. Люди были с чистым незапятнанным разумом и пробовали все подряд.
Самая опасная вещь, которая может быть у созидающего человека — это в точности знать, что ты хочешь сделать. Создатель перестает смотреть по сторонам и становится слеп. Скажите себе: «Я не знаю, что я собираюсь делать. Я не знаю, что такое программирование и каким оно может быть. Я не знаю, что такое компьютер и каким он может быть». И вы станете свободны от догм и начнете мыслить.
Пол Грэм, PyCon 2003
Во-первых, язык программирования будущего, в принципе, может быть изобретён сегодня. Во-вторых, такой язык может годиться для программирования и в наше время. Сложно удержаться и не подумать: так почему бы не попробовать написать язык будущего прямо сейчас?
Оригинал: The Hundred-Year Language
Перевод: Языки программирования через сто лет, Язык программирования будущего — сегодня
Основные мысли:
- Во что эволюционируют ЯП за 100 лет может быть интересно потому, что хотелось бы знать, на какую ветвь «древа эволюции» сделать ставку сегодня.
- А будут ли через 100 лет вообще писать код?
- Любой язык программирования можно поделить на две части: некий набор фундаментальных операторов, которые играют роль аксиом, и остаток языка, который, в принципе, может быть описан в терминах этих фундаментальных операторов. Я считаю, что фундаментальные операторы — это самый важный фактор, влияющий на выживание языка в долгосрочной перспективе. Всё остальное может меняться.
- Языки программирования — это не технологии, а больше похожи на математическую нотацию. А нотации развиваются намного медленнее чем технологии.
- Если закона Мура сохранится, через 100 лет компьютеры станут в 74 квинтиллиона раз быстрее.
- Причина существования большинства типов данных — это производительность. С увеличением производительности в миллион раз может случиться фундаментальный сдвиг парадигмы.
- Можно ли избавиться от массивов?
- Можно ли избавиться от чисел как фундаментального типа данных?
- Через сто лет программисты захотят такой язык, на котором можно оперативно и с минимальными усилиями набросать первую, невероятно неэффективно работающую версию программы. По крайней мере, так это можно описать в современных терминах. Они скажут, что им нужен язык, на котором легко программировать.
- Параллелизм не будет распространен в программах через сто лет.
- Сейчас вполне возможно изобрести язык, который будет привлекателен для пользователей через сто лет.
- Если бы мы получили язык программирования будущего, стали бы мы использовать его?
Алан Кей, 2015
Алан Кей, пожалуй, самый радикальный и оптимистичный философ программирования. Он работал и в Xerox PARC и в Disney, был ментором Стива Джобса. Алан Кей стоял у истоков первых персональных компьютеров и разработал проект лэптопа, ввел понятие ООП (по этой теме много споров что оно ушло не туда). У него есть десяток лекций и статей (в том числе и много переводов на Хабре), где он делится своим видением, каким может быть программирование и обучение.
Пожалуй, вот эти две лекции самые содержательные про будущее программирования:
Наш препод сказал — моя задача полностью размазать все ваши представления о том, что такое «компьютеры» и «программирование» — лучший класс который у меня был в универе.
— Алан Кей
Если кратко, то Алан Кей утверждает, что настоящая информационная революция еще не наступила, потому что на сегодняшний день программирование больше похоже на «алхимию», когда люди наугад что-то соединяют и смотрят что получится. Алан предлагает перейти от простого сваливания в кучу
Кто хочет копнуть про идеи Алана Кея чуть глубже, вот несколько ссылок:
- С днём рождения, Алан Кейǃ (или как получить +80 к IQ)
- Алан Кей: Будущее «чтения» зависит от будущего «обучения сложным для понимания вещей»
- Алан Кей: «Компьютеры — это инструменты, музыка которых — идеи»
- Алан Кей: Что сделало Xerox PARC особенными и кто еще сегодня похож на них
- Алан Кей: крутым концепциям тоже нужна любовь
- Алан Кей: Как обстоят дела у всего человечества, вид «из космоса»
- Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»
- Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
- Алан Кей: как бы я преподавал Computer Science 101
- Алан Кей: Будущее нельзя построить постепенно
- Персона. Алан Кэй — пророк, автор концепции GUI и языка Smalltalk
- Алан Кэй, создатель ООП, про разработку, Лисп и ООП
- Алан Кей в мире компьютеров
Джонатан Блоу, 2019
Создатель игр Braid и The Whitness сейчас занимается разработкой новой игры, которая будет сделана на новом движке, разрабатываемым Джонатоном Блоу, а движок в свою очередь, будет написан на языке программирования тоже созданным Джонатоном.
Джонатан очень недоволен текущим положением дел в программировании и пророчит в ближайшем времени коллапс:
Краткое изложение мыслей Джонатана Блоу есть Никитонкого: Хорошие времена рождают слабаков
- Кризис программного обеспечения носит системный и поколенческий характер.
- Знания не передаются следующему поколению автоматически.
- В программировании мы развиваем абстракции с пугающей скоростью. Когда они накапливаются в достаточном количестве, понимать и контролировать всё что происходит становится невозможным.
PS
Пост «Моё разочарование в софте» набрал 443+, так какое же должно быть программирование, чтобы не быть разочарованным?
«А для завтра что сегодня сделал я?»
Комментарии (44)
DrPass
10.04.2022 17:36+11Справочные и обучающие ресурсы могут появиться прямо в вашей среде IDE, чтобы вам не пришлось покидать ее и прерывать рабочий процесс.
Ну вот я смотрю на это и в упор не понимаю, какой смысл такого «ИИ», который по сути генерирует тривиальные бесполезные комментарии вида
i++; //this code increments i
А подстрочник, который обучает использованию того или иного языка программирования и его библиотек, появился на рубеже 1980-х и 1990-х, и он уже тогда был ничуть не менее информативен, чем современные аналоги.
agray
10.04.2022 18:38Необходимо проводить научную оценку и выдвигать проверяемые критерии к коду, библиотекам и фреймворкам. Производительность, энергопотребление, соответствие стандартам, читаемость, сравнение подходов для решения типовых задач. Ну и конечно же обсуждение моделей, парадигм и архитектур, создание лучших языков, с красивыми обоями и котиками.
Это и будет будущее программирования.
Конечно, это будет в будущем если люди осилят что-то кроме современных экономических моделей, ибо сейчас компании и структуры просто пользуются опенсорс кодом почти ничего не привнося в него, как и в целом в образование и науку.
MentalBlood
10.04.2022 19:22компании и структуры просто пользуются опенсорс кодом почти ничего не привнося в него
Некоторые компании и структуры выводят целые библиотеки и инструменты в опенсорс
funca
10.04.2022 20:31Обычно в опенсорс корпорации выкладывают непрофильный код - все что не создаёт им явных конкурентных преимуществ. Все самое вкусное и полезное остаётся внутри и строго охраняется.
Верх цинизма это когда при наличии массы документации, эффективные способы использования решения, выложенного в опенсорс, для сторонних разработчиков остаются недокументированными. При этом они крайне неэффективно тратят ресурсы своих работодателей (а значит вероятных конкурентов) пытаясь внедрять технологию на хайпе.
HemulGM
10.04.2022 18:38+3Вот тебе несколько примеров кода и его комментариев:
1. i++; // Увеличиваем кол-во товаров, подходящих по условию выборки пользователем
2. i++; // Повышаем степень "энтропии" с каждой коллизией объекта на сцене
3. i++; // Увеличим кол-во контролов, т.к. пользователь ещё раз нажал "Добавить"
4. i++; // Повышаем температуру, т.к. прошла секундаПонимаешь к чему я?
DrPass
10.04.2022 20:16+1Если это должно было быть ответом на мой комментарий, то нет, не понимаю. Чтобы писать подобные комментарии, надо предметную область знать. Чего от встроенной в IDE интеллектуальной читалки кода ожидать не приходится. Поэтому только вот так:
i++; //this code increments i
HemulGM
10.04.2022 21:11+5Не, это не тебе), а автору, на тему "ИИ пишет комментарии за вас, очень удобно и быстро, без регистрации и СМС".
И да, мой посыл как раз такой же)
eandr_67
10.04.2022 20:21+1К тому, что автор подобных комментариев не понимает, что такое «самодокументированный код» и вместо того, чтобы дать переменным названия, отражающие их семантику, пытается комментариями объяснить смысл переменных. Для него краткость имени переменной важнее читабельности кода. А то, что читающим этот код, придётся тратить время и силы на разбор того, насколько эти комментарии соответствуют реальности, автора кода не колышет.
HemulGM
10.04.2022 21:17Это лишь пример того, что код может быть одинаковым в разных проектах (или даже в рамках одного), а описание того, что он делает - разное. Потому что применяется в разных местах. Переменная i может быть разная в данном случае, только вот комментарий от ИИ мы получим тот же.Так что нет смысла пытаться принижать меня, т.к. это не мой код, а пример.
var++; //this code increments var
eandr_67
10.04.2022 22:51+1С невозможностью ИИ осмысленно комментировать я не спорю. Чтобы ИИ смог написать осмысленный комментарий, он должен понимать, что именно код делает. Но современный ИИ — это алгоритм (современные нейросети, построенные на базе цифровых вычислительных систем — это детерминированные алгоритмы), а теория алгоритмов много десятилетий назад доказала, что алгоритм, способный анализировать произвольные алгоритмы, не существует — это алгоритмически неразрешимая задача.
0xd34df00d
11.04.2022 00:08+2Теория алгоритмов не запрещает существовать алгоритму, который для 99% алгоритмов на практике их анализирует и пишет нормальные комментарии, а для оставшихся выдаёт
// хз, какая-то чёрная магия, отрефакторить.eandr_67
11.04.2022 11:11В том-то и проблема, что в оставшемся 1% случаев где-то будет «хз», а где-то — заведомо ошибочные комментарии: если бы «хз» всегда ставилось в нужных местах, это не была бы алгоритмически неразрешимая задача. И чтобы отличить правильные комментарии от ошибочных, понадобится человек — который будет вручную анализировать и код, и проставленные ИИ комментарии.
0xd34df00d
11.04.2022 17:04В том-то и проблема, что в оставшемся 1% случаев где-то будет «хз», а где-то — заведомо ошибочные комментарии: если бы «хз» всегда ставилось в нужных местах, это не была бы алгоритмически неразрешимая задача.
Нет, ошибочных мест может и не быть. Тут «хз» — признак, что алгоритм не может выдать решение на данном куске программы.
И чтобы отличить правильные комментарии от ошибочных, понадобится человек — который будет вручную анализировать и код, и проставленные ИИ комментарии.
Почему вы думаете, что люди мощнее компьютеров? :]
eandr_67
11.04.2022 20:06Ошибочные комментарии будут — обязательно. Т.к. алгоритм семантического анализа произвольного кода построить невозможно, значит будут использованы эвристики, пытающиеся выделить в коде заданный набор паттернов. Но никакие эвристики не в состоянии дать правильный ответ («хз» — тоже вариант правильного ответа) в 100% случаев — иначе это была бы не эвристика, а полноценный алгоритм, который — по определению — построить невозможно.
N.B. Разумеется, я говорю про системы, предназначенные для анализа семантики кода, а не перечисления выполняемых кодом арифметических действий. Бессмысленные комментарии вида «увеличить x на 1» анализа семантики не требуют.
Любая программа, построенная на достаточно сложных эвристиках, периодически ошибается — будь то шахматная программа, основанная на анализе возможных ходов или нейросеть, анализирующая лица на видео.
N.B. Да, все современные нейросети — это тоже вид эвристики. Отличающийся только тем, что настройка параметров производится автоматически — в процессе «обучения» на специально подобранной выборке.
Компьютер ограничен теорией алгоритмов, в свою очередь ограниченной формальной логикой. Именно потому существует множество задач, которые компьютер не может решить. Но мышление человека формальной логикой никак не ограничено. И это позволяет человеку решать задачи, недоступные для компьютера.
Любой логический парадокс (кто бреет брадобрея?) и компьютер либо завис, либо выдал заведомо ошибочный ответ. Но человек такие задачи решает — и на бытовом уровне, и в рамках матлогики. Более того, логические парадоксы — неотъемлемая часть человеческого интеллекта.0xd34df00d
11.04.2022 20:33+1Ошибочные комментарии будут — обязательно.
Не обязательно. Теория алгоритмов существованию нетривиального алгоритма, анализирующего любой другой и выдающего «да»/«нет»/«не знаю», не противоречит.
Любой логический парадокс (кто бреет брадобрея?) и компьютер либо завис, либо выдал заведомо ошибочный ответ. Но человек такие задачи решает — и на бытовом уровне, и в рамках матлогики. Более того, логические парадоксы — неотъемлемая часть человеческого интеллекта.
Очень хорошо. Ну так и кто бреет брадобрея? Скажите мне как человек человеку.
eandr_67
11.04.2022 21:24Теория алгоритмов утверждает, что не существует алгоритма, способного дать правильный ответ для любого алгоритма. Следовательно, для любой — даже самой изощрённой — программы найдётся алгоритм, для которого она даст ошибочный ответ. И совсем необязательно, что это будет какая-то экзотика.
Автор программы может предусмотреть множество типичных случаев, но не может предусмотреть всё. Более того, по мере усложнения эвристик наступит момент, когда разные эвристики начнут противоречить друг другу: найдутся участки кода, на которых разные части анализатора дадут разные ответы.
Брадобрея не существует (на что указал сам Рассел, сформулировавший парадокс брадобрея).0xd34df00d
11.04.2022 22:17Теория алгоритмов утверждает, что не существует алгоритма, способного дать правильный ответ для любого алгоритма.
Да. Но это не значит, что не существует алгоритма, дающего либо всегда правильный ответ, либо «хз».
Брадобрея не существует (на что указал сам Рассел, сформулировавший парадокс брадобрея).
И вы вместе с Расселом к этому пришли формальной логикой, верно?
eandr_67
12.04.2022 00:10Но это не значит, что не существует алгоритма, дающего либо всегда правильный ответ, либо «хз».
Да, такой алгоритм существует — тот самый, который ищет конструкции ++x; (и аналогичные тривиальные) и пишет к ним комментарии вида «значение x увеличивается на 1», а для всех прочих строк пишет «хз». Т.е. вообще не содержит семантического анализатора.
Но я выше прямым русским языком писал, что не рассматриваю подобные примитивные имитации, а говорю только об алгоритмах, способных анализировать семантику кода. Добавлю: на уровне, позволяющем писать реально полезные комментарии. Программа, пишущая «хз» даже в тривиальных случаях, никому не нужна, а эвристики, позволяющие генерировать нетривиальные комментарии, не могут не ошибаться.
N.B. Достаточно посмотреть на статические анализаторы кода (решающие в чём-то схожую, но на порядки более простую задачу), регулярно выдающие ложные сообщения об ошибках и столь же регулярно не замечающие реальные ошибки. А в многократно более сложной системе комментирования кода возможностей для появления ошибочных комментариев будет куда больше.И вы вместе с Расселом к этому пришли формальной логикой, верно?
Смысл парадокса в том, что формально-логический ответ лежит вне рамок формально-логической системы вопроса. На вопрос «кто бреет брадобрея?» человек может ответить: «брадобрея не существует» (осознанно выйдя за границы вопроса), а компьютер такой ответ дать не может.
Rutel_Nsk
10.04.2022 19:42-3Программирование это создание программистом подробного списка действий, который может быть выполнен быстрым и исполнительным дебилом (процессором).
PS Правда программист тоже особым умом не блещет, если думает что у него есть шанс сделать это без ошибок.
AndreyDmitriev
10.04.2022 21:43Обычно, когда меня спрашивают что-то подобное, я отвечаю парой цитат (с вашего позволения я оставлю их на английском, чтоб не портить переводом):
Первая от Фредерика Брукса:
"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 и авалонию, так что есть ещё куда развиваться.
randomsimplenumber
11.04.2022 08:56-1все прошедшие выходные я угробил на то, чтобы собрать "привет, мир" приложение для андроида из под линукса на C#,используя dotnet и авалонию
Вы не программированием занимались, а боролись с системой сборки.
mayorovp
11.04.2022 11:32Предположу, что там борьба была не столько с системой сборки, сколько с линкером.
kotk
10.04.2022 22:31-1Программирование - это командная работа по созданию ценности для клиента через код.
MagisterLudi Автор
10.04.2022 22:33-2«Systems programmers are the high priests of a low cult.»
— Robert S. Barton (1967)
SadOcean
10.04.2022 22:45"Причина существования большинства типов данных — это производительность. С увеличением производительности в миллион раз может случиться фундаментальный сдвиг парадигмы."
Это конечно очень важная причина, но вообще есть еще несколько - это, например выразительность языка (объяснение, что объект умеет делать) и то, что реальный мир тоже состоит из различных типов объектов.
Поэтому языки со слабой и динамической типизацией тоже сползают к этому (typescript и нотации в python)Drino
11.04.2022 02:18+1В оригинале там "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 строки всё-таки семантически отличаются от произвольного массива чисел, да и в целом юникодные строки это очень нетривиальный объект.
sophist
11.04.2022 10:58+2Судя по контексту, автор имел в виду, что логику работы со строками нужно выносить из ядра языка в библиотеки.
MrNutz
11.04.2022 13:23+1Поиграться то можно и сейчас, но что то реальное будет, когда будущее поставит какие-нибудь вопросы ребром перед современным программированием. Вот тогда, решая эти вопросы, и появится программирование будущего. Потом появятся другие вопросы и опять ответом будет программирование будущего, но уже другое.
Пытаться придумать что-то сейчас и реально рассчитывать на практический смысл это будет как представление прошлого о современном. Т.е. мимо, в лучшем случае весьма отдалённо. Достаточно взглянуть на иллюстрации из классики фантастики и сравнить с реальностью.
SergeiMinaev
11.04.2022 14:37Не понимаю, за что минусят статью, ведь составлена она неплохо. Если вы не согласны с идеями (как и я), не обязательно минусить. Можно высказать свои аргументы в комментариях.
Причина существования большинства типов данных — это производительность. С увеличением производительности в миллион раз может случиться фундаментальный сдвиг парадигмы.
Через сто лет программисты захотят такой язык, на котором можно оперативно и с минимальными усилиями набросать первую, невероятно неэффективно работающую версию программы.
Хех, так это не будущее, это безжалостное настоящее :)
over_seer
13.04.2022 11:27Не имеет значение, как кто-то пытается внушить нам веру, что в программировании что-то измениться в будущем. Ничего не изменится, и даже спустя сто лет. По крайней мере, пока не измениться фундаментальные основы математики и физики. Да, Физики, так как это следущий уровень, как мне кажется, в программировании будущего.
MagisterLudi Автор
13.04.2022 11:28Почему?
over_seer
13.04.2022 12:31Программирование по законам математики есть и никуда не денется, а вот программирование физических явлений только начинается. ООП как первый шаг за которым последуют ещё более сложные шаги.
MagisterLudi Автор
13.04.2022 12:33Вы текст поста читали?
over_seer
13.04.2022 15:15Конечно. Основная мысль, которую я выделил для себя, это попытка сделать программирование настолько доступным, что программист, как профессия уже не нужна. "Программирование без программиста". Это и возмутило. Скорее всего я не понял ваш вопрос. "Почему?" Можете ли вы уточнить к чему именно был адресован этот вопрос?
over_seer
13.04.2022 12:30-1Точно, что программирование не должно превратиться в игру для всех желающих. Это есть и должен быть уникальный процесс, основанный на научных подходах.
saipr
Эти слова принадлежат выдающемуся советскому учёному, одному из пионеров теоретического и системного программирования академику Андрей Петровичу Ершову (статья «О человеческом и эстетическом факторах в программировании», 1972):
Мне кажется эти слова хорошо определяют настоящее и будущее программирования.
MagisterLudi Автор
saipr
Два коррелирующих высказывания.
sophist
Не похоже на то. Высказывание Хайнлайна – фактически про горизонтальное/вертикальное масштабирование, и оно противоречит наблюдаемым фактам (росту специализации в ходе развития отрасли, в частности IT), в то время как высказывание Ершова – про структуру компетенций отдельной профессии.
Хайлайн говорит о том, что любой человек должен владеть всеми компетенциями бухгалтера, а Ершов – о том, что некоторые люди (те, кто выбрали профессию программиста) должны владеть некоторыми компетенциями бухгалтера (аккуратностью).
Zamix80
Думается что это все это классическое - От частного к общему или наоборот, я уже не помню....,
sophist
Формально да, но в данном случае это полностью меняет смысл.
Тут приходит на ум классический пример из экономики, почему законы, работающие на микроуровне, не обязательно работают на макро-: если некоторые люди на трибунах стадиона во время матча встанут, им будет лучше видно, но если все люди на трибунах встанут, лучше видно им не будет (но при этом все будут стоять). [от разницы в росте предусмотрительно предлагаю абстрагироваться]
Kotman
Так и не могу понять по какому принципу тут минусы лепят. Не ставят, а именно лепят.
MagisterLudi Автор
Спасибо!