UProLa

Неокріпші думки

Принципи програмування нового покоління Ч.1

with one comment

Згадаймо початок ери програмування.

Люди рвались робити все, що можна було – ігри, мат. програми, штучний інтелект, ОС, компілятори, бізнес-програми. Перші наробки були дуже непов”язані між собою як кодом, так і принципами. Кожен намагався придумати щось своє, на його думку – краще. В кінці кінців з”явилось багато негативних наслідків – проблем з кодуваннями, різними платформами, версіями програм, версіями файлів-даних, багами несумісності, а також позитивних – багато різноманітних ідей, альтернативи, вільна конкуренція(прогрес), можливість вибору кращого.

Зараз ми знаходимось в такому проміжку часу, коли ще згадуємо старе покоління програм типу Windows 98, платформ з процесорами 1,7 ГГц, 256 МБ ОЗУ, мнизькоємнісними вінчестерами, але, разом з тим бачимо майбутнє – .NET, Open Source сервери, поєднання ГрІн(Графічний Інтерфейс) та командного рядка, простір 3Д, мультипроцесорність, нові пристрої. І в цей час необхідно визначитись з напрямком розробок програм – продовжувати натягувати стару школу(oldschool) на сучасний світ чи програмувати на принципах нової (newwave) з розрахунком на майбутнє.

В даному пості намагатимусь описати основні “фічі” та принципи програмування майбутнього (тут гра слів, ні про яке програмування часу мова не йдеться).

1. Пріоритети
Що таке програмування? Процес написання програм. Для чого призначені програми? Для вирішення проблем, які людина не бажає вирішувати сама. Для кого потрібні програми? Для авторів програм та/або для інших людей. В майбутньому, кожна програма буде мати пріоритети в виконанні обов”язків. Програма, яка призначена тільки для розробника буде сильно відрізнятись від програми, призначеної для користувачів. Також, програма призначена для, наприклад, запису дисків, буде сильно відрізнятись від тривимірного шутера. Кожна програма буде мати свої функції, які і будуть записані в пріоритетах. Самих пріоритетів/класів може бути багато, і тільки питання часу, скільки їх буде. Приклади в сучасному світі – програми для MacOS зачасту цілком детерміновані з своїм призначенням і мають певні поля у собі, які це описують.

2. Розділеність типу
Всі програми мають певні спільні риси, але набагато більше різних властивостей. Тому терміни, застосовані до одних можуть бути неправильними для інших. В майбутньому, розподіленість типів (як і пріоритетів) повинна бути високою, інакше термінологія може зайти в тупік. Приклади: програми для великих організацій, операційні системи, воєнні розробки сильно відрізняються від програм утиліт, невеликого “софту” і тим більше відрізняються від програм навчальних; приницпи їхнього програмування неможливо об”єднати одним законом.

3. Взаємодія
Хоч програми і повинні виконувати сугубо певні дії, часто необхідна взаємодія між ними. Багато розробників покладаються тільки на ресурси ОС по обміну інформацією, але розробники ОС фізично не можуть передбачити всі можливі бажання інших авторів додаткових програм. Тому програми повинні в майбутньому навчитись самотужки обмінюватись інформацією між своїми копіями, схожими по роботі програмами та зовсім різними по призначенню. Також це означає, що програма повинна вміти крім своєї основної функції виконувати багато другорядних, тобто бути альтернативою іншим програмам за їх відсутності. Всі дії повинні бути пов”язані між собою і слідувати певній логіці, тоді користувачу не доведеться довго заучувати можливості кожної з програм. Приклади: наразі я зустрічав в основному тільки зв”язок між програмами через ОС, але надіюсь, що в майбутньому все зміниться на краще.

4. Комп”ютер та периферія
Автори ОС пішли по правильному шляху – облишити програмерів проблем з так званим “залізом”. І правильно, чим цих проблем менше, тим краще майже усім – і розробникам фізичних частин (уніфікація), і розробникам програм для ОС (менше турбот не по програмі), і користувачам (інтуітивно і просто). Страждають тільки девелопери ОС, але це їх робота ))). В майбутньому і материнські плати, і процесори, і вінчестери і відеокарти і тд будуть розроблятись відповідно принципів HotPlug, Lesser Size, MorePower&Speed, UnifiedControl, etc. В кінці-кінців, домашній комп”ютер перетвориться в щось на зразок конструктора, який легко можна буде перетворити в потужний сервер. З програмної сторони, повинна бути прозора підтримка для даних пристроїв. Окремо повинен сказати, це відноситься не тільки до “життєважливих” частин комп”ютера. Контроллери, носії інформації, принтери/сканери, планшети, різні види курсорів, а також нові засоби вводу інформації повинні працювати на всіх програмах і не призводити їх до виліту. Приклади: флешки, SATA вінчестери, деякі види принтерів уже мають зачатки HotPlug. Дуже надіюсь що всі майбутні ОС зможуть правильно обробляти такі ситуації та повідомляти програми про нове обладнання.

5. Багатопоточність
Якщо розбити програму (процес) на кілька окремих частин (потоків), то потім можна легко ними маніпулювати – швидко переключати, щоб здавалась паралельна робота кількох програм. Але сьогодні ні для кого не є сюрпризом використання багатопроцесорних систем, тобто НАПРЯМУ робити паралельні обчислення. Тому майбутні програми повинні вміти розділювати себе на логічні частини, які згодом можуть бути виконані паралельно, а не поручати цю роботу тільки на операційну систему. До терміну “багатопоточність” я б також відніс і GRID-системи (не мережі) – розподілення себе між кількома компьютерами. Звісно, основну частину повинна робити ОС, але програма повинна хоча би знати про це. Приклад: більшість великих систем, які вийшли в 2009 році уже чудесно справляються з багатопроцерністю, існують також методи для реалізації розбиття на потоки програмно. Але все ж таки, це не популярна оптимізація, яка в майбутньому займе біьшу чашу.

6. Взаємодія з мережею
До мережі я відношу глобальну – Інтернет, локальну та будь-які інші – допоміжні. Програма не повинна бути в шоці, коли їй задають в аргумент файл на іншому комп”ютері або просять оновитись до нової версії. Наявність Інтернет в наші часи – не рідкість, тому необхідно використовувати усі можливості мережі. Перечислюванням можливостей я займусь в якійсь іншій статті, бо їх можна придумати дуже багато: від оновлень та новин, до GRID-мереж. Приклади: приклади існують, але основна суть в тому, що УСІ програми повинні навчитись взаємодіяти з інтеретом, а до цього ще далеко.

7. Командний рядок та ГрІн
В сучастності існують фанати обох напрямків “юзер інтерфейсу”. Кожен з напрямків має свої переваги та недоліки. Тому кожна програма майбутнього повинна сприймати обидва методи вводу. Звісно, тяжко представити собі Photoshop в командному рядку, але деякі речі (типу конвертування типів та розмірів файлів) він зможе зробити і без великого ГрІн. Так само ping здається виключно консольною командою, але разом з тим наявність великої кількості опцій-перемикачів можна зобразити графічно в вигляді кнопочок. Тому майбутнє за подвійним інтерфейсом.

8.а) ГрІн, дизайн
Одна з найнеприємніших частин розробки програми – графічний інтерфейс. В ідеалі він повинен бути компактним, інтуітивно зрозумілим, естетичним, не тормозити. Все це важко забезпечити, оскільки затрати часу і ресурсів (грошей на програмістів) будть рівноцінні затратам на основну частину програми. Тому цим часто нехтують (або взагалі переходять на командний рядок, де все уніфіковано). Хоча, варто було би попрацювати трохи. Програми майбутнього будуть проектуватись разом з прекрасним інтерфейсом, який підійде для більшості людей. Для тих, кому не підійде – повинен бути вбудований редактор “дизайну”, зовнішнього вигляду. Як він буде реалізований – залежить від програміста, але його наявність тільки покращить саму програму.

8.б) Віджети, скрипти
Оскільки у різних людей різні думки, погано було би нав”язувати свою усім. Наявність скриптової вбудованої мови а також можливість написання так званих, “віджетів”, “аддонів” та “додатків” покращить, можливо не саму програму, але ставлення до неї і її стан в світі. Навіть самому автору потім легше буде писати оновлення в вигляді додатків. Як правило, це відноситься до графічного інтерфейсу, хоча можна і зробити, для прикладу, додавання нових опцій в консольну команду.

9. Відкритий та закритий код, платформи
Як могла прийти в голову ідея писати для інших відриті програми – невідомо. Адже існує поняття – інтелектуальна власність, яку хочеться тримати на висоті і отримувати за неї гроші. Хоча тепер ці питання не актуальні – “Open Source” існує і з цим треба щось робити. Як правило, опенсорс зв”язаний з одними платформами, закритий код – з зовсім іншими. Тому пора зтерти ці межі і почати випускати закритий код для відкритих систем, і відкритий – для закритих. Ось така тавтологія. Якщо вам це здається уже лишнім, то просто згадайте – необхідно прямувати до розподілення, але з можливостями зв”язку, а не повного відособлення. Тобто на всіх платформах повинні бути спец. частини для роботи як з відкритим кодом, так і закритим. В сьогоденні це досить реалізовано, але ще можна покращити. dotNET, Java – передові частини в інтерпретації закритого коду.

На цьому закінчу першу частину своїх прогнозів щодо майбуття.

Written by danbst

Вересень 21, 2009 at 19:54

Оприлюднено в Програмування

Одна відповідь

Subscribe to comments with RSS.

  1. Цікавий термін ГрІн. Сам придумав?

    >>Програма не повинна бути в шоці, коли їй задають в аргумент файл на іншому комп”ютері або просять оновитись до нової версії.

    По моєму це ОС, не має бути в шоці. А програмка собі працює, і не нагружається зайвим кодом. Один для всіх менеджер пакетів, це було просто геніальне рішення.

    >>розробники ОС фізично не можуть передбачити всі можливі бажання інших авторів додаткових програм.

    Розробники протоколу мусять передбачити всі можливі повідомлення які будуть передаватись по ньому. І якщо вони мають бути дуже різні, то протокол має бути низький.

    Приклад – текст в *nix.

    Хотів сказати що ти щось не згадав, а потім вирішив дочекатись другої частини.

    bunyk

    Вересень 22, 2009 at 06:44


Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: