Хотите прямо сейчас получить бесплатный видеокурс по программированию для начинающих?

Принцип скрытия механизма работы среды разработки

Апрель 24, 2013

clipart_of_11154_sm_2Здравствуйте.
Сегодня хочу поговорить с вами о том принципе по которому работают многие современные среды разработок (IDE). Дело в том что многое они скрывают от программиста. Как правило это все рутинная работа и скрыта она для благих целей — чтобы облегчить работу программиста. Однако тут есть свои минусы о которых я хочу с вами сегодня поговорить.

Вы помните, насколько интересным было программирование на простейших системах типа spectrum , на различнейших пакетах Бейсик, Паскаль и Ассемблер?
А сейчас? Весь интерес и удовольствие от творчества куда-то испарился!

Возникает вопрос: почему? Ведь и сами компьютеры, и программные пакеты стали неизмеримо разнообразнее и лучше! Ответ кроется в выбраном всеми способе развития программных технологий!

И это касается в равной степени как IDE так и библиотек.

Именно концепция сокрытия кода от того, кто использует продукт привела к подобным последствиям. Судите сами: как может программист получать удовольствие от написания программы, если он толком не понимает что она делает? Вернее он понимает, но неясно как это реализуется в реальности….

Программист вместо адресов памяти, ячеек, условий, и безусловных переходов контактирует с цветными табличками, туманными библиотеками непонятного действия и процедурами к содержимому которых производитель умышленно закрыл доступ. Можно сказать: вот, просто это все надо изучить – безусловно – изучить можно! Но все дело в постановке вопроса – либо изготовитель программного продукта предлагает к изучению содержание – либо ПЫТАЕТСЯ скрыть это.

Это видно на конкретном примере: возьмем продукт Visual Studio C++ и посмотрим, что мы увидим при его запуске. Концепция прозрачности предполагала бы, что нам предложат то, что должны предложить: укажите пусть к имеющемуся файлу , который компилятор должен загрузить ну и так далее. То есть программист сразу бы увидел: вот, все просто – это файл моего проекта, вот он – весом и ощутим — лежит здесь и здесь – и его сейчас компилятор откроет!
Вместо этого мы видим гламурно залитую градиентом табличку, где написано: имеющиеся проекты – такие то – щелкните для открытия. А какие проекты пакет считает имеющимися, где он их хранит , какие расширение, какие имена файлов – все это скрывается от пользователя – якобы для удобства. А в реальности это выливается в двойную работу – человек должен
И учить интерфейс И ему нужно знать все эти подробности про файловую систему(как программисту ему, естественно необходимо это знать).
В результате либо он исполняет двойной, а иногда даже тройной объем работы – потому что иногда под одним слоем абстракции другой, и так далее . Либо он оказывается оторванным от реальности которая замаскирована ничем!

Или возьмем другой пример: пусть программисту надо подключить дополнительный модуль к программному проекту – что может быть проще: программисту всего лишь надо создать файл с необходимым расширением в папке проекта, программный пакет определит его и при необходимости запишет туда данные и так далее…. Но нет! В нашей среде мы должны выбрать опцию добавить модуль, после чего нам показывают список из всех(!!!) доступных вариантов – причем сначала главных разделов – мы обязаны знать в какой группе лежит наш тип модуля, потом открыть эту группу – листать услужливо положенные туда сотни вариантов с описаниями….. И хорошо еще если при выборе модуля он нормально добавится в проект – потому что оказывается при начальном создании проекта выбирался тип проекта и компилятор ставил внутри себя в неведомых опять же глубинах – галки – какие модули могут присутствовать, а какие – нет!



4 Комментариев к записи Принцип скрытия механизма работы среды разработки

  1. Alex on 24.04.2013 at 19:07

    ААА! Артем ну вообще же лажа. Убирай нафиг статью. Ну так же нельзя. Твоя мысль понятна. Но она ни какого отношения не имеет от IDE. Мне например одно время было лень устанавливать делфу. Точнее она была установлена, но не запускалась из-за ошибок. Так я несоколько лет программировал в тестовом редакторе FARа…. IDE просто редактор с чуть расширенными возможностями.

    Ну а про мысль. Пусть будет, но с оговоркой. Для новичка, который учится без всякого плана. КТо не понимает, что и зачем нужно учить. Когда это становится профессией — библиотеки (а именно они виновны в сокрытии,а не IDE) экономят массу драгоценного времени.

    • Артём Кашеваров on 24.04.2013 at 19:26

      НУ так, я и пишу же для новичков а не для профи, профи и сами все знают без меня ;-). Просто дело ведь не только в библиотеках. А вообще в том как все устроено в современных IDE, в разных IDE все слишком по разному. Нет ни стандартов, везде какие-то свои ухищрения. Привыкшему человеку они совсем незаметны и тебе, Alex, в твоей IDE думаю тоже уже все привычно и понятно.

      Однако современные IDE сииильно отошли от простых блокнотов. Много инструментов, много новых настроек, встроенный компилятор, дебаггер, и еще куча хрен знает чего все это переплетено в такой клубок кошмара, который сходу отпугивает новичков, и простых пользователей. А иной раз думаешь «АААА! Ну почему эту, столь нужную мне настройку нельзя было вывести поближе и не прятать в такие дебри этой самой IDE!!»

      Все-таки хочется как-то проще, как раньше было — один листинг, один файл, одна программа(ну если программа большая то несколько листингов). А сейчас что? Посмотрите на Eclips в связке с Android SDK — это же кошмар как ерундовый проект можно было так размазать по всем этим папкам. Конечно потом понимаешь что все сделано продумано и удобно (в Eclips в частности) но когда начинаешь кодить в новой для тебя IDE появляется много возмущений, жалоб о неудобстве и пр. В результате учим не язык а IDE. Спрашивается нафига?

      Ну а библиотеки — это конечно необходимое зло ;-)

  2. Alex on 24.04.2013 at 19:10

    Ну, а на счет библиотк к которым производитель закрыл доступ… Это не для всех…. C++, C, boost (а из него много потом чего перекочевывает в очередной стнадарт С++), qt, php и многое другое — вещи с открытыми и доступными исходниками ;)

  3. Alex on 24.04.2013 at 22:21

    НУ так, я и пишу же для новичков а не для профи, профи и сами все знают без меня.
    ====
    Нет в таких вещах надо быть точным. Замени IDE на «наборы библиотек» и пусть будет. А так получилось из серии «Интернет»==»Браузер».

    Просто дело ведь не только в библиотеках. А вообще в том как все устроено в современных IDE, в разных IDE все слишком по разному. =====
    А это сказываются пробелы в знаниях. И тупая программа по информатике. На самом деле идеология построения очень одинаковая.
    Да после Delphi VS кажется сложной….

    Привыкшему человеку они совсем незаметны и тебе, Alex, в твоей IDE думаю тоже уже все привычно и понятно.
    ====
    Ну, а как не заметна. Я например использую целый ряд IDE. Заметна. Только я ориентируюсь в любой программе не по аналогии, а по логике.

    Однако современные IDE сииильно отошли от простых блокнотов. Много инструментов, много новых настроек, встроенный компилятор, дебаггер, и еще куча хрен знает чего все это переплетено в такой клубок кошмара, который сходу отпугивает новичков, и простых пользователей.
    ====
    Ну так это вообще то профессиональные инструменты. Что вы скажите о пилоте ругающем современные пассажирские самолеты за количество кнопочек. Нужен то руль да педаль газа :)
    Кстати компилятор вовсе не встроенный. Просто фоном запускается. Может и сами так делать в консоли(командной строке). Кстати я релизы всегда из командной строки собираю.

    Все-таки хочется как-то проще, как раньше было — один листинг, один файл, одна программа(ну если программа большая то несколько листингов).
    =====
    Да не было ни когда так. Было в ученических проектах да. Было. В реальных дебрей было море. Я писал на паскале под дос САПР грозозащиты объектов с редактором в трехпроекциях. Уверяю и файлов там было море и кода…
    Да у каждого уважающего себя программера был свой набор библиотек, и самописных и подареных. Вот уж где было буйство интерфесов — кто во что горазд. Так что либы сыграли свою роль в пане именно стандартизации.

    Посмотрите на Eclips
    ====
    Эклипс очень универсальный проект. И Андроид не основное.

    Спрашивается нафига?
    ====
    Очень просто. Вопрос из серии а зачем нам куча браузеров? А зачем нам куча разных марок машин? Основные функции везде стандартны. Остальное как удобно автору, что и логично.

    Ну а библиотеки — это конечно необходимое зло
    ====
    Это не зло. Это добро. Написали вы один проект, приступили ко второму. Что опять все по новой будете менюшки выводить, окна…..

    А что функции языка тоже ведь хранятся в библиотеках. Только в машинных кодах в библиотеках нет смысла… В остальных языках везде есть библиотеки. Это инструментарий. Очень важный. Сложность некоторых проектов очень высока а траить время на написание в 100ый раз ГУИ — зло. Опять же если бы не было либ. То те же ИДЕ различались еще больше.

    Я помню общался с очень интересным человеком, многим мне помог в ассемблере. Так у него куча была библиотек. Своих. Самописных….

    Кстати сейчас все консольные приложения и серверные час и пишу в текстовом редакторе. Только в качестве плагинов к нему подключены и дебагер, и компилятор, и средство работы с SQL базами….. ;)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Поддержите проект

Хит продаж:

Случайный анекдот

Моя вторая книга

Что это???

Программирование для Android:

Мы вконтакте

Помощь сайту

Понравился сайт? Он сильно нуждается в раскрутке.

Чтобы помочь в раскрутке - опубликуйте ссылку на сайт (или любую его страницу) на любом другом сайте в интернете. Тогда сайт станет чуточку популярнее.

Или просто нажмите на кнопки социальных сетей которые стоят в конце каждой статьи

Вместе мы сможем сделать программирование более популярным и более понятным для всех!

Заранее спасибо!
Артём Кашеваров.