Коментари - Четири тенденции в разработката на софтуер | IT.dir.bg
назад

Четири тенденции в разработката на софтуер

Четири технологични тенденции ще влияят върху работата на софтуерните разработчици през 2017 г., според прогноза на компанията Progress.

Обратно в новината

Коментари - Четири тенденции в разработката на софтуер | IT.dir.bg

17-11-2017 20-11-2018

Коментари

Интерпретаторният JavaScript е в основата на хаоса, работещите бавно приложения, malware и е минал много далеч от основата на iOS и Android - по-точно е влязъл в тях през задния вход - заради мързеливи "програмисти", които не искат да учат технологии в университет, а да почнат да изкарват пари веднага, като си мислят (грешно подведени от Doodle), че всичко може да се направи на JS. Това върши работа за примитивни сайтове и App-ове, но не и за корпоративни разработки.

C# и Java са цвете щото...и са най-сигурните решения... :)

Езиците са за определени цели. JavaScript е съвсем смислен за целта - динамичната част на страници. В последствие измислят неща като Node.js (нещо като сървър на JavaScript), които отдалеч приличат на извращение. В последствие става модерно да се ползва браузерен тип приложения, които си ползват HTML, CSS, JavaScript. Такова е дори Скайпа. Ако се обнови на стара ОС, ще се оплаче примерно, че IE-то ти е старо и иска да го обновиш и откаже да се отвори. За мобилно приложения е по-просто (тъй наречените хибридни приложения), но се получава, че приложенията са реално браузери. Получава се множество от браузери, което е тъпо. Искаха после да ги уеднаквяват. Предимството е, че има еднаквост в частта представляваща страницата. Не да пишеш едно за Android, друго за iOS, трето за страница и така нататък. Лесно се прави дизайн. Колкото и неподходящ да е даден програмен език, то той често може да прави нещата от другите езици, колкото и да е нетипично за него. Например на JavaScript съм попадал как се претърсват директории. Или с него се компилират програми за сенки за 3D на OpenGL/WebGL. Езиците често не са самостоятелни, а се мешат. Един език може да извиква друг да му свърши работа. С web програмни езици може да правиш някакви нормални приложения, както обратното с езици за приложения да правиш страници. Може би гледат да уеднаквят нещата, но не бих казал, че се получава. Всяко е за сферата си.

На някакъв сървър е цвъкната Java за приложение и той като средно натоварване не пада под 10%, при положение, че няма никакви обръщения към него. Всичко различно от 0% на ненатоварен линукси сървър е странно. Макар това с процентите да не е много ясно нещо на линукски сървър, там са някакви стойности на колко време процесорите са били заети, свободни и чакащи процеси. Макар на много места да важи принципа, че колкото по-бедна е дадена програма, толкова по-малко товари.

Нека да позная, не работиш като програмист, нали?

тоя Скайп преди да го предложиш, не го ли компилирш?

Жестоко се бъркаш. Особено за web езиците е нормално да се ползват по много, особено ако броиш и маркиращите езици, ако разбираш за какво говоря. Web програмиста трябва да знае поне 6 езика сигурно. Езика избран за сървъра, на базата, HTML, CSS, JavaScript, XML. Това е абсолютният минимум. Разновидностите на XML са много и е като стандарт. После трябва да може да боравиш в командния ред, примерно bash-а. Може да ти се наложи да пишеш скрипт на тях. Чак сървиси на ОС-а едва ли. Може да ползваш от там друг език (примерно Perl), защото най-бързо изпълнява нещо. Може да ползваш AWK, което също се води език. Може да намериш стар сайт писан на обикновенно С/С++, на който частите се компилират през Makefile. Може да имаш друг сървър с Java, на който е някакво приложение. И почва комуникация с приложения при теб и външни. После през приложение може да компилираш хибридно приложение за Android и iPhone, не да пишеш някакъв XCode. Там се запазва протокол през който си комуникира JavaScript от страница със самото приложение - пример - дай контактите му. Това не учебното учене на С и разновидности, преди Паскал, Пролог, Асемблер и други, което са самостоятелни. Web програмирането е по-скоро комуникация между неща. Както пускат например чат-бот изкуствен интелект Тау на Майкрософт в Туитър, дето стана нацист за 24 часа и го спряха. ;) В повечето случаи не е нужно да знаеш какво става от другата страна, а само знаеш какво е възможно да прави и връща като отговор. Дори има понятия като ръкостискане мужду сървъри за типа метод на комуникация по https. Без значение дали от едната страна е браузер, Apache, NginX, IIS или нещо друго.

Скайпа дори само на външен вид прилича на генерирано тип страница. А това с отказа да се отвори, че IE-то е старо, ми се е случвало лично на мен! При положение, че самият аз съм правил такива хибридни приложения, то какво друго мога да предположа? Скайпа ще е вид хибридно приложение. Да не говорим, че и аз съм правил чат и е лесно да си го представя отпред. Така че ако ще ме питаш, как се прави отпред, отговора е - вече съм го правил.

Във вътрешната част на Скайпа, без рамката и менюто горе, няма нито една част която да е проблем да се направи на страница. Дори представата да се прави не нещо друго изглежда сигурно много по-сложна. Няма нито един едиствен елемент, който да представлява нещо трудно. За разните иконки се намира или фонтове (например font8) или SVG-та (графично описани картинки) или просто картинки. Разни закръглени картинки се правят със стил - border-radius. Просто всичко изглежда елементарно. Вече как комуникира и какво има отдолу е друг въпрос.

Работата на сървърът е да работи а не да седи на 0%. Хардуерът е за да се ползва, не за да събира прах... ЕЕ сървърите е нормално да консумират ресурси защото те държат "жива" архитектурата на приложението (модулите са заредени в паметта за постигане на оптимални резултати). Същата система за кеширане се ползва навсякъде където се търси производителност. А ако някой го влече node.js да си дращи на javascript, като му е толкова акъла...

М/у другото - ЕЕ приложение не значи сайт който да "работи" само при входящи заявки. В едно EE приложение може да има безброй модули които да работят във фонов режим дори когато към приложението няма закачен потребител.

Не разбрах, тоя роман за какво го изписа - човека каза, че javascript е лайно и той наистина е лайно. Най голямата причина за това е, че javascript е силно нетипизиран език. Това, че javascript е лайно е причината микромеките да изобретят typescript който се "компилира" до javascript но поне позволява да се ползва типизиране (което прави лайното по малко мирилизво). Погледни как започна постът си - езиците са за определини цели. Javascript е създаден да работи в браузер при клиент (и е масов, защото няма алтернатива там). Това е. Лайното там се търпи, но като почнеш да го мажеш по сървър вече става страшно.

Честно казано типизацията въобще не ми пречи. Сигурно си свикнал на такива езици, но точно твърдото дефиниране на променливи е огромно неудобство. ;) Едва ли не проверявам тип данни в JavaScript само след Ajax, за което и много други неща си ползвам jQuery (библиотека), за по-лесно и единно. След Ajax не знам какво ще ми върне, например ако няма интернет, но и там може просто да отиде на грешка. Иначе почти винаги знаеш точно какво връща. Ако не правиш нещо от рода 0.1+0.2, заради закръгляването. Обикновено за нещо излизащо на страница, изобщо не се изисква точност. Слагаш един try-catch и ако ще гърми, да си гърми. Ползват го и за приложения, защото се прави лесен дизайн, функционалност, и да го променяш, когато ти скимне. Много по гъвкав е сигурно. Както бе рекламата на jQuery, направи повече за по-малко време. И в JavaScript има неща като шаблони на дизайн. А и е бавен май за неща тип графика, но те са нетипични за него. Иначе в сървърни езици точно удобството е, че може напълно да променяш променливи - от число на масив, обект или друго. Например взимаш някакъв обект и вкарваш в друг обект (вид затваряне) и този затваряш обект имитира предния. Така например по-едно време контролиах обект за база и и слагах самоанализиращ автомат. Какви ли не глупости съм правил, но точно те са интересни и предизвикателство. ;)

Типизирането ти гарантира голяма надеждност на приложението. Именно заради липса на типизиране в js (и не само де) са въведени смехотворните оператори като === (сравнение на стойност и тип). Да не говорим за извикването на функции, където мoжеш да правиш всякаква мацаница с параметрите. Реално, точно в това му е силата на typescript предлага типизиране (всичко останало си е javascript). Слабо типизираните езици допадат повече на хора без опит или с малко такъв, защото са по-лесни за научаване и употреба (което е и довод горе - за мързеливите програмисти).

Свикнал си на такива езици. Много неудобно е да дефинираш типове и размери на променливи. Много по-удобно е е да имаш СВОБОДА! ;) Дори за резултати от база предпочитам да са ми на прости обекти резултатите. Така мога да ги подминя на други. На някакви гетери. Там вече може като напишеш object->param или object.param, както ти е на езика, дори да се обърна и извадя резултат от друг сървър. Не е дефинираното нещо в базата. Освен това в други езици не се борави с пойнтери, а вид названия. Различни да сочат към една стойност в паметта. Твърдото дефиниране е по-скоро остатък на по-старите езици. Някога дори са гледали в кой блок в паметта да записват. Асемблера може би още се ползва за драйвери, но приключват до там.

Не ми се спори за глупости. Щом за теб true и "true" значат едно и също, то няма как да те убедя че не са. Затова умните хора са ти дали операторът === та да имаш някакъв шанс да пишеш що годе читав код. А относно асемблер - ми ползва се дори за web.

То и аз съм компилирал стар сайт на С през Makefile, обаче си е много шантаво. То си се знае кое на кое е вярно в условия - false,0,'',null и разни други изписвания, в JavaScript и undefined. Един вид променливите държат типа си и накъде сочат. Аз в условия "if" си слагам за сравнение, приемане на стойност, паттерни, обработки и така нататък. Или един return може да ми съдържа същото, за което друг би писал 10 реда. Спокойно на ред мога да имам =, ==, === едновременно и само трябва да се внимава за скоби, че приемането е на цялото назад. Спокойно може да пишеш неща от типа долу, но тук понякога режат символи и не е ясно какво ще излезне. return ((v=(function(){func=function(){return 5;}; return {'name':'My name','func':function(){return func();}};}))&& v.func()==5); Дори в JavaScript има private функции и тук кръстената func е такава, а първата неименувана. Същото може да се напише в if.

Изпуснал съм изпълнението на неименувата функция: (function(){})() Не е важно, но показвам свободата за която говорех.

Човек, защо се напъваш да спориш за неща които са ясни на цял свят. Javascript е лайно. Имаш ли идея какво ще върне това (пробвай се да кажеш, преди да го тестваш)? function Name() { return 5; } Анонимни инстанции и ламди има във всеки съвременен език. Има и други екстри като полиморфизъм, шаблони и т.н. Не слуайно микромеките създадоха typescript - ако не си го ползвал се ориентирай на там, че angular 2 залага сериозно на него. А това трябва сериозно да те накара да се замислиш - библиотека на гугъл с език на микромеките... Между другото, в новите версии на js все повече и повече се залита към типизирането.

След като го пишеш, ми напомняш, че новият ред го счита за край в JavaScript, а и не само и от там връща реално нищо. Все едно си написал: return; 5; В други езици обаче не е така и ще си върне 5. Може да се напише с избягване на нов ред за JavaScript, но тук ще ми изреже символа ако го пусна. На ангулара съм попадал с разните зареждания на скриптове, но не ми е трябвал. Само защото нещо е модерно, не значи, че е добро. Има и други подобни - например в cordova phonegap. От новаторство съм виждал как се сриват сървъри. Има и по-тъпи езици - например Visual Basic, където само ако погледнеш как се закоментирва, ще ти стане лошо. ;) А JavaScript е на С конвенция и с това прилича на повечето ползвани програмни езици, включително Java. Така че ако пишеш на някакво С или Java, то JavaScript като основа трябва да ти е ясен. Вече имат особености. А и не може да се обобщи JavaScript, макар те да са на библиотеки. Например на старото IE едно слепване на дълъг текст с плюсчета, може да му отнеме половин минута! Един от бъговете му на който съм попадал, но това не важеше за другите браузери. Във всеки браузер който ползвах бях откривал някаква грешка. За мен вероятен проблем на JavaScript, е че е бавен. Например отмного години има WebGL и никой реално не го ползва, заради натоварването. И сложноста де. Там трябва и много математика и да умножаваш вектори по матрици. ;) Иначе съм си играл да пускам видео на 3D обект и подобни.

А и основното паказване бе, не какви функции има, а че може дори да я дефинираш на ред в "return" или "if" условие. Понеже се възмущаваше на ===. А за нередности, моят пример с 0.1+0.2 бе по-добър и той няма да върне 0.3 . Но това е генерален проблем в езиците с тяхното битово представяне на плаваща запетая/точка и другите просто правят закръгление при по-преден символ.

В bash-овете е още по-неудобно, че един спейс може да направи кода счупен или не. И там между другото ";" е равно на нов ред. Например: v='value';echo $v Е аналогично на: v='value' echo $v Има още по-прости езици, като AWK. Простите езици обаче понякога дават бързина която се търси.

Погледни какво е анонимна инстанция или ламда израз и ще разбереш, че js не дава нищо като функционалност, което да го няма в другите езици. Например, в С тая концепция е въведена под формата на указател към функция. Примерите които коментираме идеално илюстрират защо js е скапан език.

"И там между другото ";" е равно на нов ред." Спец!