Визуално програмиране, за или против ?
13 отговора
8 прегледа
Визуално програмиране, за или против ?
Да, точно така, това е въпрос, който си задават програмистите от двата лагера - този на Windows и този на Linux. Защото Windows програмистите създават и управляват софтуера си само с няколко кликвания да речем или имат всички инструменти на разположение описани на английски за ученици в properties палета да речем или подобно свързано с десния бутон или разположено в плаваща палета и всички методи или променливи са достъпни по елементарен начин. Това довежда разбира се до ново разклонение, като двата лагера на програмистите лаици, които също могат да цъкат по бутоните и на програмистите професионалисти, които се ядосват безпричинно от страх некадърници да им вземат хляба. И с право.
От друга страна стоят тези, които максимата "Обичам да ми е трудно" е вероюто в живота. А наистина ли им е по-трудно на Linux програмистите. Да при тях няма начин да се прокраднат и псведопрограмисти, защото трябва непослиен труд и желание. Но все пак мощта придобита от самата ОС ги прави по-добри програмисти...може би...може би. И въпреки че и в Linux излязоха няколко RAD продукта съмнявам, се че човек с убеждения за gcc ще възприеме подхода. Аз също съм от тях. Просто мисля, че американския модел на бизнес и въобще работата в екип с всякакви специалисти от различните области, където не се налага служителя да бъде тип all-in-one, е най-печелившия. На всички е известно, че програмиста (добрия) не разбира въобще от дизайн, камо ли от потребителски нужди, помощна система визуална адаптация и интуитивност да речем. Да може би съм предубеден, но си мисля, че ако оставим визуалната част на специалистите, ще свършим повече и по-добра работа. А вие как мислите ?
Струва ми се, че...
Тук има по дълбок проблем. Всякя една ОС от сортан Уиндус, залага на две
принципиално различни неща.
1. По голямя лекота и разнообразни гъдели (уж) за потребителя. Отива се и на
много шарении. Даже и до натоварване с "облегчения", които за тормозват
ОС, и там камара бугчета....
2. Подават инструментални вьдици за разработчиците. И после, както се
майтапеше (доста добре) Филип- "на ти бета, на ти нова версия".
Тези две позиции, в никой случай да не се смесват!
За това според мен, програмистите се разделят на два лагера.
Едните си правят приложния софт за краен потребител. С навлизането и разв.
на визуалните технологии, това става УЖ по-лесно. Малко ме съмнява обаче.
Прерупванията създават тромавост. А май и камара бугчета и ситуации, в които
софта "май не прави съвсем това.."
Другата група са програмисти, които образно казано създават компонентна
база. (Това не трябва грубо да се смесва с някое от значенията на думата
компонент). Тези хора според мен, са най-вътре в софта.
Що се отнася за Линукс, съм почти гауфон, но съм убеден, че с неминуемо навлизане на "потребителски интерфейс", нещата все повече ще забият в
посока Уиндус. Дай боже да не съм прав. И да остане място за много "чистички
и яки" софт изпълнения...
Поздрави: Любо
Струва ми се, че...
Grafichnata sreda i Linux sa 2 otdelni techenija i njamat nishto obshto (kato programi)
Ne se e nito chulo, nito vidjalo da se _integrira_ grafichnata sreda v kernel-a na OS-a.
Imah slednija sluchaj: sled poredica ot manipulacii s mishkata v/u grafichnite obekti v X-a toj zabi - normalno za edna slozhna programa - i to zabi taka che ne reagirashe na nikakva namesa ot console-ata.
Obache tova po nikakyv nachin ne beshe povlijalo na rabotata na drugite sistemi v nego. prosto vljazoh i kill-nah X-a sled koeto consol-ata raboteshe normalno.
Ne sym siguren che ima Windows kojto da se spravi s tazi situacija - kato zabie zabiva bezuslovno i pylno
tuk struva mi se e predimstvoto v otdel-noto develop-vane na OS-a i grafichnata sreda :-)
Безспорно, това е вярно, но...
с навлизане на много "юзери", може да се стигне до там, че по-големия процент
от консумацията на Линукс, отива натам където не трябва. Ако на някой му
трябват шарениите и лекия интерфейс, то той "потребява" КОМПЮТЪР, в
ежедневната си работа. В другия случаи се "потребява" ОС от професинал.
Малко не разбираемо, какво правят двамата на това място. Тьй както е тръгнало,
май Линукс за да се опази, трябва да се употреби като ресурс, за управление на
други ресурси.
Що се отнася за Уиндус, NT-то е доста стабилно, по смисъла на случая със
забивката която цитираш. Казвам го с доста страх, щото слабо познавам NT.
Но май, като клиентска среда не е никак зле...
Олеле, сетих се нещо...
... Ами аз активно не използувам NT. Неговото GUI не е ли извън кернела?
Не съм се сетил да прочета досега...
Визуално програмиране, за или против ?
Друго имах в предвид приятели (ако позволите така да се обърна, ако не, тогаз колеги). Може би не съм се изразил правилно, но аз исках да засегна проблема от към професионална гледна точка, независимо за коя ОС става въпрос, съгласете се, че ANSI C си е ANSI C, ако ще и хладилник да програмирате. Ако трябва да асоциирам тезата си бих я свързал с една среда наречена Borland C++, в която реурсите се обработваха отделно
и независимо в приложение с прост интерфейс и този Workshop беше напълно подходящ за дизайнерите, художниците, специалистите по символика и семиотика и още незнам какво, а програмистите спокойно си работеха това, което им е работата, да човъркат, да дебъгват, да oптимизират и т.н. За това говоря, за това да ли имаше смисъл новата ера, на т.нар. RAD разработки, бързи да, но не и ефективни. За плануване и структуриране на идеята си струват, но за изграждане на приложение...хммм. Но и не можем да се върнем към асемблер...ползваме го само при нужда за оптимизация. Тогава къде трябва да теглим чертата ? Я си представете, че един ден само ще чертаете диаграми да речем на модулите и те сами ще се компилират и свързват ? Тогава къде ще отиде уникалността на програмите ? Съгалсен съм, че компонентите и изобщо обектноориентирания език е нещо чудесно, но то глези и мами, или както казват старите хора: много хубаво не е на хубаво. Вярно повече време отива но става нещо качествено. Инак добри идеи отиват на вятъра с бъгав
и/или тромав софтуер.
Визуално програмиране, за или против ?
Така, така. Правилно уточняваш темата, защото се започна една дискусия във всички посоки едновременно. Съвсем отделно трябва да се разискват интерфейсите за потребителите, за администраторите, за разработчиците и т.н.
Според мен, най-важното е да видим къде е коня и къде каруцата, за да поставим което трябва отпред. За мен най-отпред трябва да се сложат парите - разбирай комерсиализацията. Преди време излезнаха 3 тома на една страхотна книга наречена "Изкуството на програмирането". Томовете всъщност бяха 4, защото третия излезна и в нова версия. Страхотна книга! Всеки който иска да стане програмист, а не писач на програми би трябвало да я прочете (ако я намери). Искам веднага да поясна, че не съм успял да ги прочета целите, а само части от тях и нямам никакви претенции да съм програмист, но се опитвам да стана.
Д.Кнут казва, че програмирането не е наука, защото никой не може да се научи само от учебниците как се програмира. Трябва да имаш котакти с други програмисти, които да ти предадат част от това, което знаят и разбира се да ти идва нещо отвътре. Не съм чул или видял да са излезнали останалите томове на книгата, а имаше проект те да са 7. Може би и заради това, че програмирането се превърна в бизнес. Не може да се очаква, че някой ще направи пари като губи по 3-4 години за разработването на стабилна, бърза, малка и т.н. програма. Всеки роптае, че изкарват все нови и нови версии със възможности, които я използва я не, но които задължително лапат повече от диска, паметта и времето.
Всеки, които е писал програми ориентирани към краен потребител, знае колко време му отива за програмиране на интерфейса. Представете си колко време ще ви отнеме да напишете на Паскал това, което на Clipper се пише само с GET-READ. Ще загубите скорост при изпълнението и EXE-то ще стане по-толямо, да но ще имате време по-добре да си проектирате базата и алгоритмите. От тук съвсем естествено на човек му идва идеята да си направи готови компоненти и лека полека да стигнем до RAD.
Има и още един проблем - Ентърпрайса (за това май ще открия нова тема). Ентърпрайса иска съвсем различни неща и те наистина му трябват. Всички фирми обаче си съдират задниците да докопат някой Ентърпрайс и да си живеят живота покрай него. На вас ви е достатъчен и DOS, да но Ентърпраиса иска нещо повече и затова край на всякаква поддръжка на старите неща. Вие сте принудени да мигрирате към новите, задължително по-тромави и по-сложни (по-бъгливи) версии.
Друга причина за тази свинска насока на нещата са и практически неограничените ресурси. Когато започнах да пиша първите си програми знаех че имам 64 KB памет и 2 FDD (лукс). Когато пишех нещо по-сериозно трябваше доста да си напрягам мозъка за да се побера в тесните пространства на Apple ][. Спомням си, че заедно с колеги написахме нещо което гръмко нарекохме "Информационна система" за едно здравно заведение. Когато го показаха веднъж на един западен доктор изкушен от информатиката, той 10 минути заляга под бюрата за да види откъде минават кабелите за връзка със голямата машина.
Сега можеш да си пишеш програмата спокойно с каквото си пожелаеш средство.
Върви доста бавно ?! - пишеш, че минималната конфигурация е Xeon 700 MHz с 128 MB RAM.
Файловете стават над 2GB?! - пишеш, че иска NT Server.
Така идва края на изкуството.
Оооп, отклоних се много от темата. В друга тема писах, че всеки влак си има пътници. Никой ни ви пречи да програмирате на ANSI C. За собствено удоволствие, заради спорта или просто от инат. Ами ако компилатора изпорти работата и не създаде оптимален код? Я по-добре на Асемблер, ама и там има нещо като компилатор.
Най-добре е директно писане на машинен код. Да ама става бавно.
Ще си направя някоя подпрограмка, някоя библиотечка, някое обектче, някое engeen-че, някое API, защо не и някое RAD-че.
Да не използвам такива неща, че правят неефективен код?
Да, ама това съм си го правил Аз и съм си го оптимизирал.
Нещата изглеждат познати, нали?
Според мен най-добре е да се качите на влака който ви трябва сега, докато стигнете на нужното място.
Как мислите, самолета винаги ли е по-бърз транспорт от влака?
Визуално програмиране, за или против ?
Разбирам тревогите ти (ако позволиш обращението). Никой не иска да се откаже от сладката баница, макар и да е от развалени ябълки. Но все пак пак бих насочил фокуса не към платформата, езика или каквото и да било там...говоря за това да бъдеш шивач или шивач и дизайнер едновременно. В корпоративна Америка всеки пази ревностно мястото си защото знае, че то е оправдано...да и колегата с близката специалност може да свърши моята работа, но защо ? Не е рентабилно. Повече пари ще отидят за моята заплата допълнително, но тя ще се изплати защото аз съм специалист, а той не е. Той върши неговата работа перфектно и аз я върша тъй. При добра синхронизация се получава продукт възвръщащ инвестициите си за седмици или месеци. Наистина помислете само. Един флагман (случая примера с Adobe) - Photoshop може да повлече цяла плеяда от продукти и тяхната продаваемост да бъде не по-малка ако не и равностойна на лидера. Защо ?
Защото Adobe са създали (с помощта на специалисти дизайнери и семиоти) удобен интрфейс и придвидими функции, така, че независимо дали са с Photoshop, Illustrator, PageMaker или каквото и друго да е, потребителя се чувства в свои води само защото, в Adobe не са нагърбили програмистите с не по-малко сложната задача по създаване на интерактивен и интуитивен интерфейс. А и те самите (програмистите) са си свършили добре работа - бърз, стегнат и чист софтуер. За това говоря.
Визуално програмиране, за или против ?
Ами вижте сега - всеки влак си има пътници...
Например - едва ли е оправдано да се влагат сува човекогодини за създаване на някаква информационна системка, която написана на асемблер и оптимизирана в продължение на 6 месеца ще търси, примерно, с 5 секунди по-бързо, отколкото същата програма, написана на VB, и 3 секунди по-бързо от същата програма, написана на Delphi.
От друга страна, ако работиш за Oracle, там работата става дебела...
Така че моето мнение е следното: По-голямо внимание трябва да се отделя на дизайна на приложението (и тук вече не се намесва Истинският Програмист - все още нямаме езици, сървъри и т.н.) и едва след като се уверим (а най-добре докажем), че този дизайн е подходящ за случая, чак тогава да се пристъпи към програмирането му. И тук вече може да се направи избор на развойното средство - което в общия случай може да не е едно и също за всички модули...
Визуално програмиране, за или против ?
Съгласен съм с това за специализацията. Особено нашата област според мен е невъзможно да не си тесен специалист, иначе трябва или да си гении или да не си специалист. Може да си обаче страхотен специалист и пак естеството на работата ти да налага използването на визуални средства. Никой не може да ме убеди, че невизуалните или да ги наречем неграфични средства дават възможност за по-добра производителност. Един краен потребител на софтуер работи много по-ефективно в графична среда. Като всяко правило и това си има изключения - някой съвсем елементарни дейности, но те просто потвърждават правилото.
Когато разработвам софуер, аз съм също един обикновен потребител по отношение на RAD-a, компилатора, редактора или каквото там използвам и аз също желая като краен потребител да имам производителност и комфорт.
Ще попиташ как ще се разбере каква е разликата между добрия програмист и дърпача на иконки върху десктопа, ами такава каквато е и разликата между програмистите на Adobe и тези от други фирми останали неизвестни. Дърпачите ще направят програмата и ако не работи много добре ще запишат в ръководството:"Трябват ви минимум толково и толкова мегахерца, такъв и такъв диск и едиколко си памет". Програмиста ще се засрами и ще седне да напише някой компонент сам, ще си измисли някой по-добър алгоритъм или ако не може поне ще потърси из дебелите книги и ще има достатъчно знания да разбере какво ще му свърши работа.
Един дърпач ще използва например команда SORT в Clipper-а и въобще няма да се замисли да прегледа например книжката на Кнут III том, защото дори да я има, нищо чудно да не може да разбере какво точно би му свършило работа (не твърдя че SORT не е направен достатъчно ефективно, но понякога се налага да се направи нещо по-добро). Дърпача нищо чудно дори да използва SET FILTER :-)
Големите фирми производителки на софтуер са нещо по-различно. Като студент имах щастието да работя 1 година за такава фирма. Това беше по-време, когато в България малцина работеха на C и още по-малко бяха хората, които знаеха нещо за обектно програмиране (чесно казано аз не бях сред тях). Едно от първите неща които получихме беше фирменният им engeen за бърза разработка на приложения в среда на познай - Windows 2. Всяка стабилна фирма си има подобни машини съобразени с работата им, които се различават от общодостъпните по две наща: не толкова дружелюбен интерфейс и по-голяма специализираност, което води и до по-ефективен код. Саво най-критични части от софтуера се пише по друг начин, обикновенно само се дописва върху това, което е направила машината.
Използвай средствата, които ти улесняват живота. Дори при програми направени с тях си личи кой е дърпач и кой е писач, та ако ще и програмата да пише "Hello World!" :-)
Дозата прави лекарството ...
Или има време за GUI, има време и за асемблер.
Целта на програмиранетои е решаване на проблем.
Проблеми имат user-ите, не компютрите.
User-ите искат удобен и лесен за усвояване интерфейс.
Може да е малко по-бавен, или неоптимизиран, ама следващия P20 или К21 ще решат проблема с оптимизациите ...
И за това Win окупуира такава площ.
Всеки потребител иска по удобен продукт, а потребители са и програмистите (нима не искатe по удобен дебъгер), и системните програмисти (няма ли да е по удобно с грaфичен интерфейс да се настройва IP адрес например) и разбира се огромната маса end user's.
Това е. Ще има и малко място за силно оптимизирани асемблерски и други неща, но много важна част ще си остане и ще бъде GUI. И което е по важно, логиката на всяка програма(или почи всяка) ще трябва да се съобразява с GUI.
Съгласен!
Съгласен съм с всички вас, но моля Ви опитайте да си наемете дизайнер-професионалист, аз го направих и се радвам това промени изцяло виждането ми за нещата. Може би преувеличавам, но който има възможност да го направи, лично аз ви гарантирам успех!
И наслука!
:-)
Само допълнение
За наемането на дизайнер ;-)). Прав си!
И пак тамв Щатите, а и в ISO9000 е описано, че на един системен програмист му трябват още около 15-20 човека, за да пишат заедно с него код. Покрай интерфейсния дизайнер има: на базите данни, на инсталациите на портването към други ОС, quality checking и т.н.
Е, хубаво е да си помечтаем да работим само това което ни се иска ама не винаги става - още по-малко в България. За туй при нас или малки и хубави програмки или участие в големи софт-проекти и там на Ц здраво до полуда. ;-))