SCRIPTS vs. REAL CODE

Ако не се лъжа, "достатъчно близо до желязото" не е много добра идея, от гледна точка на мултиплатформеност например.

Just a genius

Ахм. Това за гегите ми хареса!

Въпросът е стар, ако не като света, то поне като компютрите. Някогаш, когато днешните джаваджии още не са били запланувани и когато се появиха първите персонални компютури се използваха предимно интерпретатори. Е, и асмеблер - самостоятелно или съчетан с тях. Има тук сигурно хора, на които примерно редът

1000 DATA .....

няма как да не им навява сладки спомени за дъъъълго писане и пищене на магнетофонни ленти.

След това се появи догмата "Интерпретаторите съкс!" и се говореше, че ще останат само компилаторите, щото интерпретаторите били бавни и ненамсиквоси още.

Сега спиралата пак се врътка - на мода са "скриптовете", които реалише са си пак същите интерпретатори, ама понеже "интерпретатор" все още е мръсна дума тъй им викат. Пък и мегахерците станаха гигахерци и трудно се фаща разлика в бързодействието "на око". Да не говорим за това, че голяма част от компилаторите вкарват много малко собствен код - повечето са обръщения към системата. Който нявгаш е дебъгвал програма писана на ВБ ще ме разбере.

След някоя и друга годинка пак ще излязат на мода компилаторите.....

Същата работа като при модата - тая година къси поли, догодина дълги.

Пък за прословутата "универсалност" и "мултиплатформеност" - не нам тия! Бил съм се достатъчно с "многоплатформености", та ги знам колко са многоплатформени. Още от времето на вградения Бейсик.

Кой на квото му аресва - на това да пише. Пък и универсален език няма, няма и да има.

оф поредното повърхностно изказване

ми скрипт езици са писани на С/С++ и ако гледаш на тях по друг начин може да се каже че те са тези библиотеки които дават простотата на писане в С/С++ за която говориш

също така към скрипт езиците може да се добавят компоненти/модули/функции писани на С/С++
но това почти не е необходимо...

колко ще платиш за това че те светнах този очевидни неща за които сам не можа да се сетиш?



simplistic design and scalability rulz

С/С++ не едостатъчно мултиплатформена комбинация?
Или определени библиотеки не са мултиплатформенни?

Скриптовите езици в повечето случаи са езици от високо ниво, разликата е в производителността на програмиста... Имам предвид че на скриптов език би написал нещо което прави същото което и на "реален" език - само че за критично по малко време. Това в реалния свят е нещо изключително важно. Един ден ако си поставиш за цел да не си програмист за цял живот а да направиш бързо пари и да прогресираш (дори да се пенсионираш), ще ти е по лесно да направиш това със скриптов език... а и най вече чрез Уеб интерфейс. Казвам това от личен опит, където конкурирах приложения написани на Делфи и Си++ чрез приложение писано на Пърл (за 30 пъти по малко време). Също бих казал в заключение - целта не е да мериш езици и да ги делиш на видове а да гледаш с кое ще направиш повече и по бързо пари.

А за това кой е Реал и кои е скрипт - няма никаква разлика - и скрипта и кода са код и в крайна сметка са компилирани до машинен език - тъй като не е измислен процесор който да разбира Ц или Пърл

В интернет има достатачно истории на успеха ... на скриптовите езици които ше бъдат по полезно четиво от писаници по форуми.

Съгласен съм с теб, че има много пиейчпьори, които си мислят, че щом могат да направят сайтче с пехашпе и майескюел автоматично стават програмисти.

Обаче процесът на създаване на софтуер не зависи толкова от използвания език, а от знанията и уменията на хората, които го ползват. Виждал съм много кодери на C например, които не ползват система за контрол на версиите, не пишат unit тестове и не автоматизират процеса на развръщане!

А езиците с динамични типове (като Ruby, Python, Lua и т.н.) в крайна сметка ще надделеят над силно типизираните езици (като Java, C# и т.н. ) при разработването на бизнес приложения, просто защото както казва Рандъл Шварц, приложението, което е написал на Perl, може да бъдат внедрено още преди Java програмиста да е компилирал за пръв път своето. Проста икономика.

"А езиците с динамични типове (като Ruby, Python, Lua и т.н.) в крайна сметка ще надделеят над силно типизираните езици (като Java, C# и т.н. ) при разработването на бизнес приложения, просто защото както казва Рандъл Шварц, приложението, което е написал на Perl, може да бъдат внедрено още преди Java програмиста да е компилирал за пръв път своето."

Точно така батка, то затова в момента най-много бизнес-приложения има на Perl, а не на Java, C# и т.н. силно-типизирани умиращи езици Точно па извращението Perl ! А това чудо Lua има ли поне едно бизнес-приложение написано и някоя реална компания да го ползва това приложение

А това чудо Lua има ли поне едно бизнес-приложение написано и някоя реална компания да го ползва това приложение

Lua се използва за писане на разширения и конфигуриране на сървърите на World of Warcraft, направен от Blizzard. Месечните печалби на компанията от този MMORPG са около € 3 500 000, така че можеш да сметнеш сам колко би била загубата, ако за целта беше използвана Java.

Точно така батка, то затова в момента най-много бизнес-приложения има на Perl, а не на Java, C# и т.н. силно-типизирани умиращи езици

Най-много бизнес приложения в света вуйче има на COBOL, и сигурно за тебе това един жизнен и процъфтяващ език. Ако беше прочел статията, към която дадох връзка в предишната ми публикация, щеше да разбереш защо езиците със статични типове се съотнасят към езиците с динамични типове така както COBOL се съотнася към първите.

Вуйче, COBOL също и старите версии на RPG са legacy приложения. Аз питах в днешно време на какво се разработват бизнес-приложенията и то не е COBOL нито Perl. Статията я прочетох и ме напуши смях момента където някъв Пърл-гуру си мери пишката със някакво студентче че щял да си пусне програмата на Пърл преди студентчето да успее да си компилира Джавата ?!? Голям аргумент, машалла.
И откога add-ons и scripting functionality към някоя игра се води "бизнес-приложение" ? Че те игрите си имат такива шукарии от 100 години (отпреди да излезе Lua). Скриптовите езици си имат своето място, но така както кърнъл на ОС не става на Джава така и скриптовите езици не могат да изместят С#/Джава от големите бизнес-приложения. Динамичните типове + липсата на ООП (или кофти/идиотски реализирано ООП - think Perl ) могат да докарат такива лайна в една голяма система че после времето за дебъг/фикс ще е 2 пъти повече от спестеното време.