Автор: IvanVlаskin1976
В 70 программировали математики. Возможности компьютера были очень маленькими- и что бы с них выжать побольше нужен был очень большой математический талант.
А сейчас возможности огромные- можно 10 миллионам гуманитариям поручить программировать.
Проблема маркетинговая- Надо найти идею и закодить то что народ будет покупать. Даже Баги не надо искать- проще перекодить все заново. |
|
1. Архитектура и ассемблер: В начале своего пути программирование тесно связывалось с знанием аппаратной части. Программисты создавали программы, тесно взаимодействуя с железом, понимали архитектуру процессоров, писали на ассемблере. Знание аппаратуры было необходимым элементом профессиональной компетенции.
Программисты того времени были настоящими инженерами, глубоко понимавшими аппаратные особенности компьютеров. Они не только знали, как писать код, но и как он будет исполняться на уровне микропроцессора.
В условиях ограниченных вычислительных ресурсов программисты стремились к созданию максимально эффективных и оптимизированных программ. Каждый байт и такт процессора были ценными ресурсами.
Поскольку инструменты разработки были значительно ограничены, программисты часто создавали свои собственные компиляторы, ассемблеры и даже операционные системы. Это требовало не только знаний программирования, но и понимания внутреннего устройства компьютеров.
Программисты того времени часто увлекались аппаратной частью компьютеров. Они могли разбирать и модифицировать железо, экспериментировать с новыми компонентами и даже строить свои собственные компьютеры.
Работа с ассемблером требовала тесного взаимодействия с железом. Программисты знали не только команды процессора, но и структуру памяти, устройство регистров и периферийных устройств.
Программисты того времени мечтали о расширении возможностей компьютеров. Они стремились создавать программы, способные выполнять более сложные задачи, чем когда-либо прежде, и вносить вклад в развитие компьютерных технологий.
С учетом ограниченных объемов памяти и скорости процессоров программисты разрабатывали алгоритмы, учитывающие эти ограничения. Это требовало особого подхода к созданию программ.
В условиях, когда многие аспекты программирования были еще не определены, программисты часто экспериментировали и проявляли творческий подход к решению задач.
Программирование рассматривалось как искусство создания эффективных и красивых программ. Код писался не только для выполнения задачи, но и с учетом его структуры и читаемости.
Программисты того времени обычно составляли небольшие, но страстные сообщества энтузиастов, обмениваясь идеями и опытом в мире, который только начинал осваиваться.
2. Языки низкого уровня: Но "программирование", как мы его знаем, начиналось с применения языков более высокого уровня, таких как Fortran, COBOL и C. Эти языки позволяли ближе подходить к аппаратному уровню, но требовали глубокого технического понимания.
Период развития Fortran, COBOL и C охватывает примерно 1950-1970 годы, и программисты того времени были в значительной степени представителями первого поколения компьютерных специалистов. Вот несколько аспектов жизни и увлечений программистов того времени:
Программисты того времени часто были высококвалифицированными инженерами с фундаментальным пониманием аппаратной части компьютера.
Разработка программ всё ещё требовала углубленного понимания архитектуры процессоров и операционных систем, не смотря на то что языки Fortran, COBOL и C предоставляли более высокоуровневый, но все еще близкий к аппаратному, доступ к машине.
COBOL (Common Business-Oriented Language) был разработан для обработки бизнес-данных. Программисты, использующие COBOL, часто работали в области банковского дела, финансов и других сферах, где необходимо было эффективно управлять большими объемами данных.
Fortran был создан для научных и инженерных вычислений. Программисты Fortran занимались разработкой программ для расчетов в физике, математике, инженерии и других научных областях.
Программы того времени разрабатывались уже в основном в командном режиме, и программисты часто работали в больших группах над крупными проектами.
Управление ресурсами и оптимизация производительности были важными аспектами, и программистам приходилось активно использовать возможности языков программирования для эффективного управления памятью и процессорным временем.
Программисты того времени мечтали о расширении возможностей компьютеров и создании более эффективных программ.
Развитие технологии и рост вычислительных мощностей внушали надежду на решение более сложных задач и создание инновационных приложений.
Общим для большинства программистов было стремление к совершенствованию навыков программирования, а также к применению компьютеров в различных областях жизни для решения сложных задач. Этот период был временем активного формирования профессионального сообщества программистов и становления компьютерных технологий как ключевого элемента в различных областях человеческой деятельности.
3. Объектно-ориентированное программирование: В последующие десятилетия стало активно развиваться объектно-ориентированное программирование (ООП), что сделало код более модульным, повысило его читаемость и облегчило сопровождение.
Линукс Торвальдс писал про С++ :
| C++ провоцирует на написание в дополнение к структурам и функциям Си значительного объёма кода, не имеющего принципиального значения с точки зрения функциональности программы. Например, многие шаблоны STL требуют обязательного описания для обрабатываемых типов нескольких конструкторов и переопределения оператора присваивания. В итоге код на C++ может быть даже больше из-за обязательных описаний, которые в Си вообще не требуются |
|
Журналисты того времени говорили так:
Взгляните на это: парадигма ООП, словно сверкающая жемчужина, ворвалась в мир программирования, обещая благосостояние и порядок. "Объекты", "классы", "наследование" – звучит как симфония для ушей каждого программиста, и как не влюбиться в идею организации кода в виде маленьких, автономных "объектов"?
И вот мы, погружены в этот романтический мир ООП, где все является объектом, где абстракция становится реальностью, и код словно сглаженные камушки на побережье. Но давайте не будем обманывать себя – в этой идиллии прячется подвох.
О, как же много обещаний принесла с собой эта парадигма! Как будто программирующий мир стал беззаботным садом, полным абстракций и удобства. Но, оказавшись в объятиях ООП, мы поняли, что цена за этот рай – высокая.
Изначально восхищение превращается в разочарование, когда сталкиваешься с неуклюжестью некоторых языков, в которых ООП становится тяжеловесной бюрократией, кормящейся наследованием и полиморфизмом. Какой-то громоздкий код и непонятные отношения между классами – словно интриги в высшем обществе!
А что насчет производительности? Вместо стремительных ускорений получаем часто ненужные слои абстракции, которые, казалось бы, должны делать наш код лучше, но в реальности просто превращают его в медленное монстрозное творение.
О, парадигма ООП, как ты меняешься от восторга к разочарованию! Перестань быть этим идеальным витражом и стань реальной поддержкой для программистов. Не будь иллюзией, а будь реальностью!
Как ярко сверкнула звезда ООП на небесах программирования, обещая чистоту кода и легкость сопровождения! Но разве она не стала инструментом, с которым сложно смириться? В поиске высшей абстракции, мы потеряли землю под ногами.
"Наследование", как прекрасное слово, плодит горы классов и долгие цепочки зависимостей. Разве не преследует нас дух неуклюжести, когда нам приходится раскрывать тайны далеких предков, чтобы понять, что происходит в нашем коде?
И как насчет этого "полиморфизма", что обещал поразительную гибкость? Но, о чудо, сколько же часов мы тратим, чтобы раскрывать тайны иерархии, только чтобы понять, где же скрывается тот самый метод?
Абстракция – вот его имя! Но где граница между "абстракцией" и "магией"? Загадочные методы, неявные зависимости – словно колдовство, в которое мы все вдруг стали верить.
И как же нам обойтись без этих завораживающих "объектов"? Но порой они становятся замедляющими танцорами, загружая наши программы дополнительными бременами. Обещания эффективности расходятся с реальностью вычислений.
ООП, ты обещал нам рай, но вместо этого мы оказались в лабиринте абстракций и сложных взаимосвязей. Программисты страдают, пытаясь понять, как избежать паутины зависимостей.
Так что лишь восторг первых встреч с ООП был иллюзией, а реальность оказалась сложной и запутанной, словно героиня трагического романа. Мы все еще мечтаем о чистом коде и элегантных решениях, но ООП, похоже, водит нас вокруг своего пальца, играя на нотах сложности и потерь.
|
|
Однако не реально писать код больших проектов без ООП, это факт. Приходится мириться с политикой и "интригами в высшем обществе". Программист постепенно становится политиком с этого момента. Теперь приходится бороться за популярность, выглядеть хорошо, посещать курсы ораторского мастерства.
4. Глобальные сети и интернет: В 90-х годах появление глобальных сетей и интернета существенно изменило подход к программированию. Разработка клиент-серверных приложений, веб-технологий и распределенных систем стала актуальной областью.
В эпоху виртуальной революции, 90-е годы, программисты оказались в вихре перемен, принесших с собой глобальные сети и интернет. Быт и стиль работы программистов претерпели существенные изменения, требуя новых навыков и подходов.
Вместо монолитных приложений программистам стали необходимы клиент-серверные решения, где важную роль играли взаимодействие и обмен данными между клиентской и серверной частями.
Программистам приходилось разрабатывать и поддерживать сложные архитектуры, где обработка данных переместилась на сервер, а клиентская часть стала отвечать за визуализацию и взаимодействие с пользователем.
Появление веб-технологий открыло новую эру разработки. Программистам предстояло осваивать языки веб-разработки, такие как HTML, CSS, и JavaScript.
Интернет стал платформой для создания и распространения приложений, и программисты активно учились использовать браузеры в качестве клиентского интерфейса.
Программисты стали сталкиваться с созданием и поддержкой распределенных систем, где компоненты приложения могли быть разбросаны по разным серверам и даже странам.
Решения в области масштабируемости и обеспечения надежности стали приоритетом, а программа не ограничивалась работой на одной машине.
С развитием интернета программисты стали более "социальными". Веб-технологии привнесли понятие веб-разработчика, который не только создает код, но и взаимодействует с дизайнерами, маркетологами и заказчиками.
Командная работа и общение с различными профессионалами стали важной частью процесса разработки.
С появлением форумов, сообществ и открытых исходных кодов программисты того времени стали активными участниками обмена опытом, идеями и новыми технологиями.
Способность быстро учиться и адаптироваться стала ключевым фактором успеха.
Программисты 90-х годов оказались в центре цифровой революции, и их работа перестала быть изолированной деятельностью. Требования к ним стали более разнообразными, включая как технические навыки, так и социальные способности.
5. Появление языков высокого уровня и фреймворков: В 2000-х годах стало модным использовать языки высокого уровня, такие как JavaScript, Python и Ruby, а также различные фреймворки, упрощающие разработку и ускоряющие процесс создания приложений.
Да, языки эти удобны, словно любимая старая обувь. Простота и выразительность – вот их девиз. Но куда пропало профессиональное мастерство, где сложные задачи требуют глубокого погружения? Всё стало чем то…, гуманитарным что ли...
Фреймворки, эти волшебные палочки, ускоряющие разработку. Но что с навыками самостоятельного конструирования? Разве не исчезает профессионализм, когда каждый второй разработчик всего лишь собирает кубики из конструктора? Где же, ети твою мать, грань между удобством и потерей мастерства?
Да, фреймворки предоставляют готовые решения для распространенных задач, упрощая жизнь разработчика. Избавившись от повседневных трудностей, программист может фокусироваться на более высокоуровневых аспектах проекта.
Однако, чем больше программист полагается на готовые фреймворки, тем меньше времени уделяется самостоятельному проектированию. Каждый следующий проект становится всего лишь сборкой компонентов, а навык создания сложных решений с нуля постепенно утрачивается(если он вообще был изначально).
Фреймворки предлагают высокий уровень абстракции, скрывая детали реализации. Это удобно, но ведет к тому, что программист может потерять контроль и глубокое понимание того, что происходит "под капотом". Ну и само использование инструментов, которые не до конца понимаешь, часто не даёт максимальной отдачи, ограничиваясь лишь поверхностным конкурированием.
Использование фреймворков стандартизирует подходы к решению задач, что, с одной стороны, облегчает совместную работу в команде. С другой стороны, это может привести к тому, что разработчики становятся механическими исполнителями стандартных сценариев, не выходящими за рамки заданных шаблонов. Впрочем "овчинка стоит выделки", как правило, точнее стоила бы, ели бы не одно жирное НО: стандарты меняются так быстро, что собственно говоря о "стандартах" уже даже речи не идёт, скорей о ситуативных "трендах" и "хайпах", о которых забывают через год.
Использование фреймворков безусловно экономит время и ресурсы, но в долгосрочной перспективе это может привести к утрате разносторонних навыков и уменьшению креативности в решении уникальных задач.
Сложные фреймворки могут вносить ограничения в архитектуру проекта. Разработчик оказывается в ловушке, где некоторые аспекты решения уже определены, и изменения в них становятся более сложными. Начинаются хитроумные натягивания сов на глобусы, причем структурность этого процесса, порой оказывается сложнее и рискованней, чем написание с нуля нужного функционала под задачу.
В конечном итоге, программист, слишком увлеченный удобством фреймворков, может оказаться в плену своих собственных инструментов. Быстрота разработки не должна заменять глубокое понимание и творческий подход к решению проблем. Профессионализм в программировании — это не только умение собирать конструктор, но и способность создавать нечто уникальное, индивидуальное и глубоко продуманное.
Программисты превращаются в модников, выбирая языки и фреймворки не по их эффективности, а по их популярности. Неужели стандарты и оптимизация стали архаичными понятиями?
Где специализация? Где уникальные подходы? Все становятся одним серым массовым потребителем технологической моды, словно бараны, следуя друг за другом.
Фреймворки – это маяк, на который все ориентируются. Но в этом маяке заключается опасность забыть, как писать код без костылей, словно музыкант, забывший, как играть без нот.
Так вот, в мире блеска и удобства, мы стоим на грани деградации. Профессионализм смешивается с массовым бездумьем, а языки и фреймворки становятся пуговицами на одежде, скрывая под ними пустоту знания и творческого мышления.
Совсем другое дело мой веб-фрейворк который я пишу уже почти 20 лет, он основан на ИИ и функции eval(), он заменит всё гавно что сейчас хайпуется, реакты, ангуляры, вью и пр. ненавижу их.
6. Автоматизация тестирования и CI/CD: С развитием методологий DevOps стал актуальным автоматизировать тестирование и процессы непрерывной интеграции/деплоя (CI/CD), что улучшило бы качество и стабильность программного обеспечения. На словах всё хорошо, но "гладко было на бумаге и забыли про овраги".
Да, DevOps, эта новая философия, которая обещает сплотить разработчиков и операционщиков, уничтожив вечные конфликты и улучшив качество программного обеспечения. Но как всегда в жизни IT, за блестящей фасадом кроются свои тайны и интриги.
DevOps стремится объединить отделы разработки и операций, создавая одну сплоченную команду. Пропадают стены и преграды, и, казалось бы, наступает эра гармонии.
CI/CD вводит понятие непрерывности, ускоряя процессы интеграции и деплоя. Программное обеспечение выходит быстрее, и бизнес получает больше возможностей.
Автоматизация тестирования внедряет в процесс жесткие стандарты. Релизы становятся более стабильными, а качество программного обеспечения поднимается на новый уровень.
Но внедрение DevOps часто требует культурных изменений, социальных. Кажется, что все объединено, но на практике столкновения культурных различий могут создать напряженность в коллективе.
Операционщики и разработчики начинают борьбу за власть. Кто управляет инфраструктурой? Кто принимает решения о конфигурации? Интриги взаимоотношений становятся частью повседневной жизни.
DevOps стремится стереть границы между ролями, но это может привести к неопределенности. Кто отвечает за что? Каждый член команды должен быть универсалом, что вызывает недовольство и непонимание.
Бесконечные циклы CI/CD создают интенсивный рабочий процесс. Разработчики и девопсы оказываются в постоянном напряжении, сталкиваясь с недопониманиями и усталостью. Иногда словесные конфликты переходят в физические, после работы сотрудники много пьют и хулиганят.
Не всегда удается создать идеальное единство, и иногда DevOps становится всего лишь маской, скрывающей реальные проблемы и неурядицы.
DevOps, словно двуличный персонаж в драме, вносит смуту в мир разработчиков. Интриги, борьба за власть, культурные различия – все это часть сложного пасьянса, в котором каждый ход вызывает новую волну неопределенности и возможных конфликтов.
На пути к гармонии и стабильности, девопсы учат нас жизни в постоянном состоянии перемещения и адаптации. Они перетягивают одеяло на себя, мнят себя пупом земли, иногда объединяясь с спецами по ИБ, которые вообще по своей природе предельно порочны и способны не только обматюкать и навешать тумаков, но и "заказать" в даркнете, где они постоянно общаются с преступниками(хакерами, кардерами, наркоторговцами и тп.).
7. Ну и подходим к самому важному изменению последних десятилетий, рост важности soft skills, по сути полное перекрытие хардов софтами. Да, помимо технических навыков, стало понятно, что для успешной разработки программного обеспечения важны коммуникация, управление проектами, способность работать в команде. Soft skills стали неотъемлемой частью культуры программистов. Но всё зашло слишком далеко и куда то не туда.
Мы вступаем в период, где навыки общения и лидерства важнее кодинга! Стоп, стоп, стоп! Но разве это не сулит нам проблемы в долгосрочной перспективе?
Важность soft skills перекрывает технические навыки? Разве нам не говорили, что код – это кульминация всего профессионализма? А вот теперь, словно магия, мы увлекаемся софтами, призывая дух профессионализма из бутылки?
Коммуникация, управление проектами – словно новые религиозные обряды. Но что же случилось с культом кода? Теперь важнее, чтобы ты правильно выразил свою мысль, чем чтобы твой код был шедевром.
Это даже не революция, это сглаз! Программисты словно забыли, что код – это их хардварный актив. И вот теперь, вместо того, чтобы ковыряться в битах и байтах, они учатся делать комплименты и мирно разрешать конфликты.
Куда делись наши архетипы гиков? Где магия кода, где те, кто живет в мире алгоритмов и математических формул? Все поглощены обучением эмпатии и внутренними тренингами по саморазвитию.
На горизонте маячит тенденция, словно зловещий призрак. Мягкие навыки становятся центральными, и программисты словно толпы следуют этой волне, забыв, что иногда программирование – это искусство, требующее отдачи и страсти, пророй вытесняющее всё остальное, особенно гуманитарное, такое как коммуникабельность и умение быть приятным для окружающих.
Это не просто смена приоритетов, это атака на душу программирования! Мы теряем часть себя, предаваясь вихрю межличностных отношений и культуре встреч.
Где теперь те звезды программирования, чьи кодовые шедевры заставляли уважать их мастерство? Они теперь затерялись в толпе безликих демагогов и маркетологов.
Согласно новому курсу, программирование – это не только о коде, а о совместной работе, людях и общении. Но возможно, в этом стремлении к балансу мы теряем суть, забывая, что программист – это в первую очередь творец, ваяющий собственное произведение искусства на пустом холсте байтов. Вероятно нужен баланс, очевидно смещенный в сторону хард-скилов, нежели софтов, если мы не хотим стагнации индустрии. Превращении некогда инновационной индустрии, растущей по закону Мура, в "банку с пауками", соревнующихся в интригах и политике.
Всё… надоело писать. 10 минут итак потратил, на этот глупый форум.