SCRIPTS vs. REAL CODE

Така като те чета, май мислиш че основното в програмирането е да спазваш дисциплина, да знаеш какво се случва под кода ти и да го контролираш напълно. Видял си, че при скрипт езиците тези неща нямат голямо значение, и сега това те притеснява

Според мен дисциплината от този вид, както и да ти се налага да мислиш на едно ниво под кода който пишеш, са странични ефекти от несъвършените средства (вкл. езици) за програмиране. Налага се да го правиш, но колкото по-малко ти се налага, толкова по-добре. И основните умения на един програмист са по-скоро да имаш някакво алгоритмично мислене (т.е. да можеш да формулираш последователност от действия за решаване на проблем) и да изразяваш абстракции чрез средствата на езика.

Ако се замислиш, на какъвто и език да пишеш разчиташ страшно много на такива абстракции. Дори да пишеш на асемблер, не знаеш как са реализирани инструкциите на процесора (и това е различно при Интел и АМД например). Ако си мислиш че познаваш TCP/IP стека, вероятно се лъжеш: отново разчиташ на абстракции като това че TCP надеждно ще ти достави данните, или ще получиш грешка; без да се интересуваш от рутирането на пакетите например.

Скрипт езиците обикновено имат типове данни, те просто се проверяват по време на изпълнение, с някакъв набор от правила за неявно преобразуване. Ако тези правила са твърде много и твърде inconsistent, както е при PHP, това е проблем, да. Най-доброто за мен е да имаш право да указваш типа, без да си задължен, и езика да има механизъм за type inference...

П.П: Каквото и да си мислиш че е предикатен език, Лисп не е такъв.

Съгласен. Именно затова има различни туулове и езици (ИДЕ-та, фреймуъркс, прочие), които са удобни за различни цели. Идеята е да си най-близко до решението, това често НЕ означава, да си най-близо до нулите и единиците, които минават през процесора.

Иначе щяхме да сме на ниво перфокарти, 0/1 и най-много асемблер.

--
Increasing Performance By Lowering Expectations.

Всъщност, казвам само ще производителността на сървъра също има значение. Каквито и оптимизации да правиш в крайна сметка пак ще си остане съществена работа за процесора. И пак ще изникне въпроса: къде е по-изгодно да дадем парите: за заплати на програмисти или за хардуер (плюс заплати за админи).

Разбира се, тази дилема стои сериозно само за натоварени сайтове, каквито в България все още няма.

Добър довод - аз бих казал хардуера е по-евтин при комерсиални платформи където е лесно да си сглобиш клъстер без да правиш ядрена физика.

Но дори и това не е супер довод - по-принцип най-големият bottleneck при уеб хави са заявките към базата с данни и там няма значение дали правиш заявката със С или PHP. Ако имаш добър начин за репликиране и синхронизиране на базата данни + лесен начин при overload да добавиш нов сървър без големи олелии, С / PHP - все ще ти е тая (ако говорим за бързина).

--
Increasing Performance By Lowering Expectations.

В отговор на:

---

И пак ще изникне въпроса: къде е по-изгодно да дадем парите: за заплати на програмисти или за хардуер (плюс заплати за админи).

---

за хардуер ... че порграмисти такива бози могат да напишат, че и 10 заплати да им платиш пак нито те нито някой след тях ще се оправи .... то май е имало една тема, че е най-добре да се пише неразбираем код :))

Това за истинските програмисти е като истинските фотографи - истинските фотографи не снимат с дигитални апарати, а само с лента. Не може да си истински фотограф ако снимаш с дигитален апарат - завинаги си оставаш аматьор, колкото и хубави неща да изкарваш с него.

Аз пък съм уеб дивелопър(тази така мръсна дума) и правя неща, които се ползват всеки ден от хиляди хора. И предпочитам да виждам резултата от работата си, отколкото да бича анонимно месеци наред по някой модул на нещо, което в крайна сметка я направи релийз, я не. Само за да бъда истински програмист.

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

И в двата случая ще се дават пари на програмисти, и в двата случая ще пишат бози, и в двата случая ще се плаща на кюеи да ловят бозите.

Досега в тази тема всички изхождаха от хипотезата, че писането на PHP е по-бързо и с по-малко грешки. Това е вярно само когато се започва от нулата и се разработва изключително за уеб.

Но да видим следната ситуация: имаш ентерпрайз система написана на С++ и трябва да и се напише уеб модул за да могат клиентите да пускат заявки през браузер. Директна връзка към базата няма да има, всичко ще минава през приложен сървър. В такъв случай ще е по-ефективно да се пише на С++ или поне С#

написваш един модул на Ц за РНР за комуникиране между уеб модула и приложен сървър и пак си пишеш уеб модула на РНР, но това е друга тема която е с мерене на пишки. Предлагам да не се задълбаваме там, че ще стане мазало.

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

А за грешки .. някои успяват и в 5 реда да направят 100 бози без значение дали е "скрипт" или "код".

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

[линк]

За С++ и какво се слува в Амазон е изключително забавно:

C++
C++ is the dumbest language on earth, in the very real sense of being the least sentient. It doesn't know about itself. It is not introspective. Neither is C, but C isn't "Object-Oriented", and object orientation is in no small measure about making your programs know about themselves. Objects are actors. So OO languages need to have runtime reflection and typing. C++ doesn't, not really, not that you'd ever use.

As for C: it's so easy to write a C compiler that you can build tools on top of C that act like introspection. C++, on the other hand, is essentially un-parseable, so if you want to write smart tools that can, for example, tell you the signatures of your virtual functions, or refactor your code for you, you're stuck using someone else's toolset, since you sure as heck aren't gonna parse it. And all the toolsets for parsing C++ out there just plain suck.

C++ is dumb, and you can't write smart systems in a dumb language. Languages shape the world. Dumb languages make for dumb worlds.

All of computing is based on abstractions. You build higher-level things on lower-level ones. You don't try to build a city out of molecules. Trying to use too low-level an abstraction gets you into trouble.

We are in trouble.

The biggest thing you can reasonably write in C is an operating system, and they're not very big, not really. They look big because of all their apps, but kernels are small.

The biggest thing you can write in C++ is... also an operating system. Well, maybe a little bigger. Let's say three times bigger. Or even ten times. But operating system kernels are at most, what, maybe a million lines of code? So I'd argue the biggest system you can reasonably write in C++ is maybe 10 million lines, and then it starts to break down and become this emergent thing that you have no hope of controlling, like the plant in Little Shop of Horrors. Feeeeeed meeeeeee...

If you can get it to compile by then, that is.

We have 50 million lines of C++ code. No, it's more than that now. I don't know what it is anymore. It was 50 million last Christmas, nine months ago, and was expanding at 8 million lines a quarter. The expansion rate was increasing as well. Ouch.

Stuff takes forever to do around here. An Amazon engineer once described our code base as "a huge mountain of poop, the biggest mountain you've ever seen, and your job is to crawl into the very center of it, every time you need to fix something."

That was four years ago, folks. That engineer has moved on to greener pastures. Too bad; he was really good.

It's all C++'s fault. Don't argue. It is. We're using the dumbest language in the world. That's kind of meta-dumb, don't you think?

With that said, it is obviously possible to write nice C++ code, by which I mean, code that's mostly C, with some C++ features mixed in tastefully and minimally. But it almost never happens. C++ is a vast playground, and makes you feel smart when you know all of it, so you're always tempted to use all of it. But that's really, really hard to do well, because it's such a crap language to begin with. In the end, you just make a mess, even if you're good.

I know, this is Heresy, with a capital-'H'. Whatever. I loved C++ in college, because it's all I knew. When I heard that my languages prof, Craig Chambers, absolutely detested C++, I thought: "Why? I like it just fine." And when I heard that the inventor of STL was on record as saying he hated OOP, I thought he was cracked. How could anyone hate OOP, especially the inventor of STL?

Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you're most familiar with.

So if you don't like what I'm saying about about C++, go become an expert at a better language (I recommend Lisp), and then you'll be armed to disagree with me. You won't, though. I'll have tricked you. You won't like C++ anymore, and you might be irked that I tricked you into disliking your ex-favorite language. So maybe you'd better just forget about all this. C++ is great. Really. It's just ducky. Forget what I said about it. It's fine.

--
Increasing Performance By Lowering Expectations.

Писането на РНР и не само на него е по-бързо само ако знаеш какво ти трябва, имаш опит в подобно писане и знаеш езика.

Точно това имах предвид и примера си: Ако имаш 50-100 програмиста на С++ и ти трябва да напишеш някакъв относително малък уеб модул (не да пренаписваш софтуера), трябва да си луд да го правиш на PHP (няма достатъчно работа за екип или даже човек, появява се въпроса с подръжката на кода, и т.н.)

А да, и за писането на модула дето го предлагаш пак ти трябват хора дето знаят как се пишат подобни модули, т.е. или нови хора или обучение, но и двата случая забравяш за срокове.

В отговор на:

---

А да, и за писането на модула дето го предлагаш пак ти трябват хора дето знаят как се пишат подобни модули, т.е. или нови хора или обучение, но и двата случая забравяш за срокове.

---

чакай де, срокове се определят преди да започне проекта.

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

Python

Well gosh, what about Python, a nice language that has patiently been waiting in the wings for all these years? The Python community has long been the refuge for folks who finally took the red pill and woke up from the Perl Matrix.

Well, they're just like the Smalltalk folks, who waited forever to replace C++, and then Java came along and screwed them royally, and permanently. Oops. Ruby's doing exactly that to Python, right now, today. Practically overnight.

Python would have taken over the world, but it has two fatal flaws: the whitespace thing, and the permafrost thing.

The whitespace thing is simply that Python uses indentation to determine block nesting. It forces you to indent everything a certain way, and they do this so that everyone's code will look the same. A surprising number of programmers hate this, because it feels to them like their freedom is being taken away; it feels as if Python is trampling their constitutional right to use shotgun formatting and obfuscated one-liners.3

Python's author, Guido Van Rossum, also made some boneheaded technical blunders early on — none quite as extravagant as Larry's blunders, but a few were real doozies nonetheless. For instance, Python originally had no lexical scoping. But it didn't have dynamic scoping either, and dynamic scoping may have its share of problems, but it at least sort of works. Python had NOTHING except for global and local (function) scope, so even though it had a "real" OO system, classes couldn't even access their own damned instance variables. You have to pass a "self" parameter to EVERY instance method and then get to your instance data by accessing it through self. So everything in Python is self, selfself, selfselfself, selfSELFselfSELF__SELF__, and it drives you frigging nuts, even if you don't mind the whitespace thing.


Etc.

But in my opinion, it's really the frost thing that killed Python, and has prevented it from ever achieving its wish to be the premier scripting language, or the premier anything language, for that matter. Heck, people still use Tcl as an embedded interpreter, even though Python is far superior to Tcl in every conceivable way — except, that is, for the frost thing.

What's the frost thing, you ask? Well, I used to have a lot of exceptionally mean stuff written here, but since Python's actually quite pleasant to work with (if you can overlook its warts), I no longer think it's such a great idea to bash on Pythonistas. The "frost thing" is just that they used to have a tendency to be a bit, well, frosty. Why?

Because they were so tired of hearing about the whitespace thing!

I think that's why Python never reached Perl's level of popularity, but maybe I'm just imagining things.


P.S. Този откъс е взет от същото место от където си цитирал за C++ ... А болднатият текст мисля казва всичко

Интересно. А сървера на базата на който направи това заключение (което си е вярно) на кой скриптов език е писан казваш?

Чеки и аз да се изакам.
Задаваш глупави въпроси.
Все едно овчарите да седнат да спорят коя гега е по-яка.
Все едно градинарите да спорят коя лопата или мотика са по-добри.
Все едно багеристите да се чудят кой багер е по-добър.
ЩОМ ТИ ВЪРШИ РАБОТА нема значение скриптов ли е, мриптов ли е или е реал-цоде. Ай ако си велик ми направи десктоп приложение на асемблер пък аз ще маам на Ц#. Или ако си още по-велик ми направи драйвер за USB ама на Визуал Базик или на Ц#. Аз ще пиша на Ц. И ако наистина си минал по пътя, който си описал би трябвало да знаеш, че за всеки влак си има пътници и че както в света хората не говорят само английски така и в програмизма езиците са толкова, колкото са нуждите на хората. Всичко зависи от това какви са ти възможностите - пари и време. Останалото зависи от теб.

Човека е тръгнал по вьпросния пьт, но май още не го е иминал...

под скрипт езици имаш предвид интерпретирани езици или? че кое му е unreal на скрипт кода?
разликата е може би, че по-бързо излиза изпечен продукт и по-малко пишеш нещо на интерпретиран език отколкото на (недайбоже да пишеш същото) c/c++, но пък и сферите на влияние са различни.
иначе и аз съм минал/минавам още по пътя дето си го минал и ти.

флуктуации в нивата на абстракция

Ползвайки С/С++ може да достигнеш леснотата и простотата на писане която имаш при скрипт езиците... (това разбира се става с подходящи библиотеки; ако тръгнеш от нулата доста пот ще видиш докато стигнеш това ниво...)

Ползвайки скрипт език няма да можеш да стигнеш "достатъчно близо до желязото", както може да стигнеш с С/С++...

Общо взето добро решение е да омесиш С/С++ и някой скрипт език...