Инструмента́льное програ́ммное обеспе́чение — программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ, в отличие от прикладного и системного программного обеспечения.
Один из наиболее известных языков программирования, используется для обучения программированию в старших классах является Pascal.
Бе́йсик (Basic) — семейство высокоуровневых языков программирования. Был разработан в 1964 году профессорами Дартмутского колледжа Томасом Курцем и Джоном Кемени.
Word — текстовый процессор, предназначенный для создания, просмотра, редактирования и форматирования текстов статей, деловых бумаг, а также иных документов.
PowerPoint- программа для созданий презентаций
Вответ:
Кто-то создает программное обеспечение с открытым исходным кодом, а я провожу много времени размышляя над тем, как сделать программное обеспечение лучше. Бесконечный поток о на форумах Stack Overflow, GitHub, Slack, в электронных письмах и личных сообщениях неизбежен. К счастью, в итоге вы знаете многих людей, которые добились определенного успеха и сделали фантастические вещи, и знание о том, что вы приняли в этом участие благодаря вам и вашей , является хорошей мотивацией для новых достижений.
У вас возникает вопрос: какие качества программного обеспечения приводят разработчика к успеху или к неудаче? Как я могу улучшить свой софт и бо́льшему количеству людей стать успешным? Я могу ясно сформулировать некоторые основные принципы или полагаюсь на интуицию в зависимости от конкретного случая? (Рождение и воплощение одной мысли это два совершенно разных действия).
Возможно это что-то вроде принципов Дитера Рамса качественному дизайну программного обеспечения?
Хороший проект является инновационным.
Хороший проект делает продукт полезным.
Хороший проект эстетичен.
Хороший проект делает продукт понятным.
Хороший проект ненавязчив.
Хороший проект честен.
Хороший проект длителен.
Хороший проект продуман до мельчайших деталей.
Хороший проект безвреден для окружающей среды.
В хорошем проекте дизайна настолько мало, насколько это возможно.
Общая картина, вероятно, является более важной, чем то, о чём я сегодня пишу, но я знаю, что ее "советы" иногда непрактичны или вовсе неприменимы, или, чего хуже, являются трюизмами. Это как сказать: "Сделай это настолько просто, насколько возможно, но не слишком простым". ("Make it as simple as possible, but no simpler". Оригинал прим.). Понятное дело, что все мы хотим, чтобы вещи были более простыми. Но иногда мы не знаем, что именно нужно сделать для достижения данной цели.
И даже если у Вас сложилось правильное "общее представление" о том, что вы делаете, нет никакой гарантии того, что Ваш проект будет успешен. Методы претворения идеи в жизнь имеют такое же важное значение, как и сама идея. Дьявол кроется в деталях.
Я не могу дать эффективный универсальный совет, но, возможно, существует менее другой путь. Вдохновили меня Томас Грин и Мэриан Петре, чьи “когнитивные размерности” определяют набор “дискуссивных инструментов”, для “повышения уровня дискурса” о пригодности таких "информационных артефактов", как код.
Абстрактный градиент;
Близость отображения;
Последовательность;
Размытость;
Склонность к ошибкам;
Сложные умственные операции;
Скрытые зависимости;
Преждевременное обязательство;
Прогрессивная оценка;
Ролевая выразительность;
Вторичное обозначение;
Вязкость;
Видимость.
Ни одна платформа не является совершенной. Она (какая-то абстрактная платформа) была создана для изучения визуальной среды программирования, и в некоторых случаях для специфических приложений. (Рассмотрим ситуацию, которая моделирует наблюдение всего кода одновременно. Любое программное обеспечение сегодня достаточно маленькое, для того, чтобы быть видимым во всей полноте на одном экране? Возможно модульный принцип был бы лучше?). Я считаю, что трудно присвоить некоторые проблемы юзабилити той или иной размерности. (Как скрытые зависимости, так и ролевая выраженность (role-expressiveness) предусматривают, что при этого кода будет делаться нечто иное, отличающееся от того, что делалось раньше). Тем не менее, это хорошая пища для размышлений о “когнитивных последствиях” проектирования программного обеспечения.
Я не буду определять "общие рамки". Но у меня действительно есть некоторые наблюдения, которыми я хотел бы поделиться, и это столь же подходящее время, как и любое другое, для выполнения апостериорной рационализации года: примерно столько я потратил на D3 4.0.
Я не возвращаюсь к “крупномасштабному” проекту D3. Я вполне доволен такими понятиями, как соединение данных, масштабы и разметки, отдельные от визуального представления. Здесь также есть интересное исследование и это не последний мой фокус. Я разбиваю D3 на модули чтобы сделать его пригодным для использования в большем количестве приложений, чтобы его было проще расширить для остальных приложений, и проще разрабатывать — но, в процессе работы с ним. я также выявляю и фиксирую большое количество дефектов и недостатков API. Эти вещи легко можно упустить из виду, но в то же время, они во многом ограничивают действия людей.
Иногда я переживаю о том, что данные изменения тривиальны, особенно если рассматривать их индивидуально. Я надеюсь, что смогу убедить Вас в обратном. Я волнуюсь, потому что я думаю, что мы (т.е. люди, которые пишут программное обеспечение) склонны недооценивать юзабилити интерфейсов программирования, вместо этого рассматривая более объективные качества, которые проще измерить: функциональность, производительность, правильность.
Объяснение:
