| |||||||||||||
Not AgainNot AgainPosted Apr 17, 2012 2:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)In reply to: Not Again by brianomahoney Parent article: PHP: a fractal of bad design (fuzzy notepad)
>Competent Programmers, most of whom have have very simple simple tastes, we like stuff that is simple (C, Perl); powerful (Perl, Python); predictable (C, Perl); understandable, and suscinct (not Cobol, Java); and do not contain so many syntactic and semantic traps that you need 3+ boots and a 2000 page spec to document the gotchas (C++); and not captured by a Library eco-system that invites patent suites (Java, If ORACLE win at trial Java is DEAD).
Wow! You've managed to nail EVERYTHING. In reverse.
Perl and C are hardly 'simple' or predictable. While Python is good, it's not that powerful (still no way to use real multithreading or do system-level programming). Java _wins_ in 'understandable' category (along with COBOL, really) though it's not succinct. Etc.
>Now I don't expect this comment to do anything but attract a fleet of arrogant newbies and pack of stupid religeous experts, but each time I find an idiot proposing Java for rael-time or high frequency systems,
>or telling people that they can't use PHP or JavaScript because they are not TYPE SAFE I wonder what the Universities are really doing.
>Keep this up and all innovation will be done by asians who havnt been taught by progressive idiots that it can't be done.
I work with quite a few Asians and most of good Asian software developers hate PHP with a passion. PHP simply transcends cultures.
Oh, and should we mention Ruby which is made in Japan?
PS: I love the smell of flame-roasted bacon in the morning!
(Log in to post comments)
Not Again Posted Apr 17, 2012 3:14 UTC (Tue) by fest3er (guest, #60379) [Link]
>>or telling people that they can't use PHP or JavaScript because they are not TYPE SAFE I wonder what the Universities are really doing.
> Duh. They're right.
Really? When did it become socially fashionable for anyone to disparage another for her choice of programming language?
To attempt to add a bit of perspective to the issue, consider maintaining a 1700-program suite written in business basic over the past 30 years with one-letter var names, few comments, data packed every which way into ISAM files, and with data stored in the ISAM keys. In comparison, PHP is a fantastic and robust language and ECMA Script is a joy to use.
Competent programmers write efficient and stable software in the languages they are most skilled at using.
Decorum prohibits me from sharing my opinion of folks who tear down rather than build up.
Not Again Posted Apr 17, 2012 4:02 UTC (Tue) by dvdeug (subscriber, #10998) [Link]
> When did it become socially fashionable for anyone to disparage another for her choice of programming language?
My first instinct was to say 1957, when FORTRAN came out; but there were probably earlier instances after assembly languages came out that people still hacking machine code were disparaged for not switching.
> Competent programmers write efficient and stable software in the languages they are most skilled at using.
I don't think so. Competent programmers know the art of picking a reasonable tool for the job; e.g. unless you really need to use something else, write Android programs in Java. Not only that, competent programmers in real life have to work with other programmers; you may be the best ML or Modula-3 hacker in the world, but if someone else has to work with you or will have to maintain it after you, those probably aren't the best languages to use.
Not Again Posted May 25, 2012 15:46 UTC (Fri) by dashesy (subscriber, #74652) [Link] you may be the best ML or Modula-3 hacker in the world, but if someone else has to work with you or will have to maintain it after you, those probably aren't the best languages to use. Very very true, but same can be said about most other languages as well. C++ is more popular but some boost-like paradigms should be avoided in a not so technical company that does not get many job applicants with high level of skills (not Google so to speak). If it is in a library that no body is going to see the source then it might be OK. I had to remove so many Functors+for_each statements recently and replace them with simple for loops, because over time they had evolved into ugly monsters passing and changing state. A simple rule of thumb (for work-place I described) is to try to avoid what a language does not provide naturally (not highlighted by IDE is a good sign); no lambdas for C++ even for skilled programmers, please just switch to C++11 if you need them. A competent programmer who does not work in an elite workplace (Google, RedHat, ...), should think ahead, if working on the next Google, then even inventing a new functional language might be worthwhile let alone using Haskell, otherwise please keep it as simple as possible.
Not Again, Bacon Posted Apr 17, 2012 4:29 UTC (Tue) by brianomahoney (subscriber, #6206) [Link]
If you don't think C or Perl are predictable you don't understand their semantic model.
As to multi-treading, and micro-kernels, as an OS developer I do not understand the fascination with multithreading in USER SPACE, it simply brings all the cpmplexity of non-sequential programming into the app space for no visable gain:
.. Stop/Start latency can be better managed without threads,
.. Pre staged processes anyone?
.. The kernel, and only the kernel knows it the context switch needs register save/restore, cache flush or page table flush and dosn't need user space to second guess it.
.. Fast locks can be done better in shm.
You are too dumb to see that I was not defending PHP and JavaScript, I was not, and you are right that they are very poorly designed by language designers from Europe and the US. Exactly what I was doing was attacking knee jerk language fascists who are dumb enough that they have discovered the holy grail!
There is a lot of PHP and JavaScript out there doing very useful things that cannot now be replaced.
Bleagh Posted Apr 17, 2012 6:52 UTC (Tue) by jd (guest, #26381) [Link]
C is not "predictable" for many reasons, not least that no two system C libraries implement identical semantics. Different C libraries implement different malloc strategies, different levels of sanity-checking, and even different levels of detail in errors. That means that the same C program will run differently in different environments.
Sometimes you want that, sometimes you don't. You don't want real-time systems to run programs exactly the same way as high-performance systems, mission-critical systems or highly secure systems. It's good if programs can acquire some of the characteristics of the environment.
In part for the above reason, but also in part because of some really sloppy compilers out there, C is notorious for Heisenbugs, where different compilers will produce different Heisenbugs for the same code.
This is something you definitely Do Not Want.
Ok, what about user-space threading?
Have to disagree here, too. M:N threading in the Linux kernel was abandoned because it wasn't achieving any good results - even though it's not obvious as to why the extra complexity was overwhelming the reduction in bottlenecks.
I am also an ardent supporter of Occam, *THE* language for user-space parallel processing (IMHO, anyway). Completely 100% explicit userspace threading, no room for discretion by compiler or OS, explicit synchronization and explicit affiliation between threads. It's so explicit, even the compiler needs to be over 18 to read it. It is also mindboggingly fast. Nothing, bar assembly, comes close.
On the Transputer, the system Occam was originally written for, Occam was about the same level above Transputer machine operating instructions as C was above the machine operating instructions of the systems it was designed for.
And that makes my final point:
The power of a language will ALWAYS be dictated by the translation needed to convert it into native form. Something will ALWAYS be lost in translation when making paradigm shifts and you will ALWAYS introduce bugs and performance issues. When running a consistent paradigm from start to finish, that might still happen (if the language is merely badly designed, or if either the compiler or processor are defective) but the chances are good that it will not.
C will NOT run well on a Transputer. Occam does NOT run well on an Intel. If anyone actually built a true Object Oriented Processor, neither language would work well on it at all but C++ and Java probably would work just fine.
Bleagh Posted Apr 17, 2012 7:26 UTC (Tue) by mpr22 (subscriber, #60784) [Link] How well C++ would work on an "object-oriented" processor would depend very heavily on what style of C++ the programs were written in. (Also: what does the apparent buzzphrase "mission-critical systems" mean that is somehow incompatible with "real-time"? I'd argue that a significant subset of real-time systems are mission-critical, and I'm sure that NASA, General Dynamics, and Boeing would agree with me.)
Bleagh Posted Apr 18, 2012 0:01 UTC (Wed) by jd (guest, #26381) [Link]
Definitions are close to what are usually used:
"Mission Critical" - seven 9s reliability as being a minimum
"Secure" - B2 or EAL5 as a minimum, can't have known exploits, security kernel must be amenable to being provably correct (whether or not it has actually been proven)
"Real-Time" - I'll accept "fixed number of CPU cycles in a given window, doesn't matter when in that window", -or- "fixed start and end times in which the program will be running, doesn't matter exactly how many CPU cycles were used", soft real-time is not really "Real-Time".
And so on. Real-Time has multiple definitions, so I simply ORed the two usual ones together and excluded the one that should never have existed.
Some of these are orthogonal, some have trade-offs and some are mutually exclusive. Which is what has changed, as new techniques and methods are discovered. "Mission-Critical" is orthogonal to "Real-Time" up to the point where sufficient validation of pre-conditions permits deadline guarantees to be met.
Where it is NOT possible to validate pre-conditions to the extent needed to ensure the probability of an error resulting in a failure condition is below the threshold guaranteed (99.99999% reliability = 0.00001% probability of a catastrophic error) THEN you cannot have something that meets both requirements, you have to trade off.
However, for most practical purposes (and I include NASA's rocketry, Boeing's military aircraft, etc, to be a practical purpose), well-written software, developed using an established and recognized software engineering technique, properly tested, is very unlikely to require validation that is so extensive that real-time guarantees can't be met.
Bleagh Posted Apr 19, 2012 13:49 UTC (Thu) by nye (guest, #51576) [Link]
>Definitions are close to what are usually used:
> "Mission Critical" - seven 9s reliability as being a minimum
I'd say that's pretty far from 'usually used'. Nearly nothing has seven 9s reliability. That's 30 seconds of downtime per decade - even applications which are literally life-or-death don't generally manage that, and the overwhelming majority of people using the phrase 'mission critical' would mean at least two orders of magnitude less reliable.
'Real-time', as you (sort of) say, has too many definitions to be especially meaningful without qualification. I've always been a little confused by 'soft real-time'. It generally seems to mean vaguely 'low-latency'; which is largely orthogonal to real-time. I guess it's really intended to mean 'general purpose' as opposed to 'batch mode'.
Either way it sounded like your earlier post said that a system can't be both 'real-time' and 'mission-critical', but then later you seemed to say that they can, which is confusing.
Bleagh Posted Apr 19, 2012 20:32 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
"Mission Critical" just means that the organization can't function without it, it says nothing about the required uptime.
for many businesses e-mail is mission critical, but if it's up between 9 and 5 it could be down the rest of the day and not matter. And if it is down during the day and business is crippled, it hurts, but the business doesn't go under.
I can't think of very many companies that electrical power wouldn't be considered "Mission Critical", but very few companies (outside of ones focused on Internet accessible servers) have backup generators and UPS systems, and those don't come anywhere close to 7 9's of availability.
Bleagh Posted Apr 17, 2012 10:11 UTC (Tue) by dgm (subscriber, #49227) [Link]
> Different C libraries implement different malloc strategies, different levels of sanity-checking, and even different levels of detail in errors.
Come on. The last one is false (errors in libraries?), and none of the three is part of the semantics. C has it's quirks, certainly, but they are not those you listed.
Take for instance the many operations that can trigger undefined or platform specific behavior. *That* can make code unpredictable. One has to take into account, though, that such code is considered buggy, or at least fragile, and they are well documented.
There are also some obscure points in the language that should have been left out. The comma operator, for instance. But all in all, C is very pleasant and predictable. For some reason, more pleasant than more orthogonal languages like Pascal (hey, that's _my_ personal opinion).
> That means that the same C program will run differently in different environments.
That means that _buggy_ C programs _may_ run differently in different environments. Which is not surprising, if you ask me.
Bleagh Posted Apr 17, 2012 19:58 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] C will NOT run well on a Transputer. Occam does NOT run well on an Intel. If anyone actually built a true Object Oriented Processor, neither language would work well on it at all but C++ and Java probably would work just fine. Anyone with an iAPX432 box care to try and find out? ;-) Actually, slightly more seriously, some of the LISP machines of the 80s provided a true object floor. Objects were first-class at the instruction level. LISP apparently ran great on it. I wonder if Java or C++ would work there? I suspect straight C++ wouldn't because it allows too much low-level monkeying about.
Not Again, Bacon Posted Apr 17, 2012 8:42 UTC (Tue) by renox (subscriber, #23785) [Link]
> If you don't think C or Perl are predictable you don't understand their semantic model.
About C, you should really read this blog: http://blog.regehr.org/ which contains lots of article about software correctness and C.
Do it and then we'll discuss about C's "predictability" which isn't so good..
Not Again, Bacon Posted Apr 17, 2012 16:03 UTC (Tue) by k8to (subscriber, #15413) [Link]
Did you actually read the article? It wasn't "lol php sucks", but in fact a pretty good dissection of what the problems are.
Based on some of your own criteria, it provides all the evidence that it's a poor choice for nearly any situation, and that's good information for future decision making. Nowhere does it tell you to replace all your php right away. That's your invention.
|
|||||||||||||