Ever little while I come across some self-important dumbass who explains why XXX is an evil language and should not be used, the worst go on to invent another unusable language that never gets real code written in it, they Range from Nicklaus Wirth [ETH, Zuerich](Alogol-W, Pascal, Modula 1-12345) and come in churches of Functional, Procedural and Object.
Exactly like Climate Alarmists don't know what they are doing, the Theory (Universal Turing Machines), the Practice (writing, debugging and maintaining a large, say 1M line program).
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).
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.
Programming and System Design is one of the most Complex and Challenging Tasks there are and no wonder it can't be done by deserving people with room temperature IQ and an indifferent BS or PhD from the University of Nowhere.
Keep this up and all innovation will be done by asians who havnt been taught by progressive idiots that it can't be done.
Posted Apr 17, 2012 2:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
>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,
Like http://www.azulsystems.com/ ?
>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.
>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!
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.
Not Again
Posted Apr 17, 2012 2:27 UTC (Tue) by szoth (guest, #14825)
[Link]
You racism has no place here or anywhere else.
Not Again, Racism
Posted Apr 17, 2012 4:03 UTC (Tue) by brianomahoney (subscriber, #6206)
[Link]
What racism, a view that American (Caucasian, unstated, but if the cap fits, wear it) Lefty Progressive shits replay the same nonsense every 10 years is some how racist?
Take your head out your ideology for long enough to see that my post is IDIOTist, not RACist.
Not Again, Racism
Posted Apr 17, 2012 4:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
I'm a card carrying member of the Communist Party of Russia I can state that the US 'lefties' are non-existent. The US has a right-wing and an extremely-right-wing party.
PS: yes, I really have a membership card, it makes a great conversation starter :) That's why I got it in the first place.
PPS: What? Politics on LWN?!? Are we turning into Slashdot?!??? Help!
Not Again, Racism, Communism
Posted Apr 17, 2012 4:45 UTC (Tue) by brianomahoney (subscriber, #6206)
[Link]
Your membership of the Communist party of the erstwhile CCCP is interesting but I would advise keeping your sins from Putin, but is not germain to the discussion except that you are simply unaable to see a point of view other than your own, which is naive and arrogant in the extreem.
No one is telling you what to write in, ML, Lisp ... C++, that is Libertarian just to STFU about others, but we know, and most of us now simply ignore your nonsene.
Thank you for starting the firestorm of intolerance that I wanted to illustrate!
Not Again, Racism, Communism
Posted Apr 17, 2012 6:06 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
I'm perfectly able to see others' view, if it's reasonable.
We can argue about usefulness of DSLs or about the ways to extend JS. I can see that ML and Haskell people have some great arguments in favor of their language.
However, your arguments in favor of PHP can be summed as: "Basic is worse than PHP, so PHP is good".
That's kinda... weak.
Not Again, Racism, Communism
Posted Apr 17, 2012 20:10 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246)
[Link]
Or to phrase it as a political joke I've heard here in the states, "Both parties are bad, so vote Republican." (I don't, BTW.)
Looking through that (lengthy) article, I think Edsger Dijkstra's comment on BASIC may also apply to people who've only coded in PHP:
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
Granted, this is coming from the same person who said gotos are bad without exception. I think reality is a bit more subtle than such stark pronouncements.
PHP's suckiness, though, appears to be anything but subtle. Glad I stayed away from it.
Mentally mutilated
Posted Apr 18, 2012 15:59 UTC (Wed) by man_ls (subscriber, #15091)
[Link]
I am probably tainted by my humble beginnings with Amstrad BASIC, but I have programmed in Pascal, Perl, Python, C, Java, JavaScript, PL/SQL, even Bash; but I kind of like PHP. It lets you do what you want quickly and it is not so full of itself as Python.
That is all. I just wanted to add a Leftist vote for PHP. Please don't flame me.
Mentally mutilated
Posted Apr 18, 2012 18:11 UTC (Wed) by juliank (subscriber, #45896)
[Link]
You started with BASIC? You know, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Mentally mutilated
Posted Apr 18, 2012 18:34 UTC (Wed) by man_ls (subscriber, #15091)
[Link]
Well, what can you do. At least it was not Visual Basic; and my first programs were really Spectrum Basic. Actually I have very fond memories of GFA basic. When I recoded the 3D graphic application I did for the Atari ST in 68k assembler, for speed gains, I was ultimately unable to debug it, probably due to the massive brain damage inflicted by the various Basic dialects.
That was when I was young and agile, now that I am older I have learned not to do anything too clever in my code.
Not Again, Racism, Communism
Posted Apr 17, 2012 11:19 UTC (Tue) by AndreE (subscriber, #60148)
[Link]
I think I know whose nonsense most of us will be ignoring from now on.
Not Again, Racism
Posted Apr 18, 2012 16:13 UTC (Wed) by tjc (subscriber, #137)
[Link]
The US has a right-wing and an extremely-right-wing party.
That's an interesting perspective. Placing myself into your view of the U.S. political system leaves me pining for an extra extreme right-wing party. :)
Not Again, Racism
Posted Apr 19, 2012 14:03 UTC (Thu) by nye (guest, #51576)
[Link]
>That's an interesting perspective. Placing myself into your view of the U.S. political system leaves me pining for an extra extreme right-wing party. :)
I'm confused - are you saying that you want a party even more right-wing than the US Republican party or have I misunderstood?
(BTW from the UK perspective I believe the US Democrat party would probably be unelectably right-wing.)
Not Again, Racism
Posted Apr 19, 2012 14:51 UTC (Thu) by mpr22 (subscriber, #60784)
[Link]
I'm not sure the Democrats are that much to the right of Maggie's incarnation of the Tories.
Not Again, Racism
Posted Apr 21, 2012 15:47 UTC (Sat) by tjc (subscriber, #137)
[Link]
> I'm confused -
You said it, not me. ;)
> are you saying that you want a party even more right-wing than the US Republican party or have I misunderstood?
Yes. A party that runs up 4.9 trillion dollars in debt in just 8 years (2000-2008) is not conserving anything.
please cut the politics
Posted Apr 21, 2012 16:24 UTC (Sat) by dlang (✭ supporter ✭, #313)
[Link]
this isn't the appropriate place for such things
please cut the politics
Posted Apr 22, 2012 22:12 UTC (Sun) by tjc (subscriber, #137)
[Link]
Fear not: I shall not don my hairy breeches and begin preaching, at least not this time. :)
Not Again
Posted Apr 17, 2012 2:36 UTC (Tue) by Doogie (guest, #59626)
[Link]
It's an international Communist conspiracy to sap and impurify all of our precious bodily fluids!
Not Again
Posted Apr 17, 2012 3:41 UTC (Tue) by cmccabe (guest, #60281)
[Link]
Your comment is a fractal of fail.
Not Again
Posted Apr 17, 2012 16:55 UTC (Tue) by nix (subscriber, #2304)
[Link]
It is quite remarkable how well that comment fits with the thesis of the blog post it's responding to. Fractal of fail, indeed. (Perhaps this was intentional... but I kind of doubt it. The inclusion of climate-change denial in there makes me wonder again though: it's so out of place...)
Not Again
Posted Apr 17, 2012 3:47 UTC (Tue) by dvdeug (subscriber, #10998)
[Link]
Personally, I tend not to take advice from people who abuse others as being stupid and yet can't write a coherent post. How do you program if you can't get simple things like spelling and capitalization right in English? (The first is why they invented spellcheckers; you just have to learn the rules for the second, but they're not that complex.)
Not Again
Posted Apr 17, 2012 4:52 UTC (Tue) by brianomahoney (subscriber, #6206)
[Link]
English, UK US, De, Fr, It, Es, BPT
Oh well, I am so stupid! And you are a Lefty, first all to resort the 'ad homs'.
Not Again
Posted Apr 17, 2012 5:54 UTC (Tue) by edomaur (subscriber, #14520)
[Link]
I don't see the link between your answer and his question... Well, color me stupid.
More seriously, if I could erase PHP from my life, I would do. It's a mess as a language, and this has no link whatsover with my political preferences, my skin tone, the things I know as a learned human, and any other non-software related themas.
However, you have the right (and the left) to choose your programming language of preference, and to beeing offended by the negative views some other people will have about it.
But you have to be realist.
Not Again
Posted Apr 17, 2012 16:14 UTC (Tue) by k8to (subscriber, #15413)
[Link]
Seriously Brian, attacking everything as 'lefty' when totally irrelevant to this degree is a warning sign of schizophrenia. Please talk to a mental health professional.
Not Again
Posted Apr 19, 2012 14:27 UTC (Thu) by jschrod (subscriber, #1646)
[Link]
Thanks for giving the information that you can be ignored for all times on LWN.net.
Not Again
Posted Apr 17, 2012 10:49 UTC (Tue) by mpr22 (subscriber, #60784)
[Link]
How do you program if you can't get simple things like spelling and capitalization right in English?
First, English spelling is sufficiently non-simple that a spellchecker can't save you from howlers.
Second, a former (English!) co-worker of mine could design and write sane, coherent software despite being unable to reliably internalize the spelling of "receive".
Not Again
Posted Apr 17, 2012 14:34 UTC (Tue) by pboddie (subscriber, #50784)
[Link]
If the compiler keeps telling you that you're wrong, eventually you'll step up and give it something it can work with, and then you'll always have the executable and a debugger. There isn't such a toolchain for English.
Not Again
Posted Apr 17, 2012 16:18 UTC (Tue) by HelloWorld (guest, #56129)
[Link]
I guess it depends on what you consider sane.
> Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
(Edsger Dijkstra)
Not Again
Posted Apr 17, 2012 16:38 UTC (Tue) by sorpigal (subscriber, #36106)
[Link]
Yeah. Even Ritchie couldn't spell "create" right.
/me ducks
Not Again
Posted Apr 17, 2012 22:34 UTC (Tue) by tjc (subscriber, #137)
[Link]
I think that was Thompson, and I *think* he said that if he could change one thing about Unix, that would be it.
Not Again
Posted Apr 18, 2012 12:50 UTC (Wed) by sorpigal (subscriber, #36106)
[Link]
I recall it was Ritchie, but I could be wrong. And yes, that's the quote I was thinking of.
Not Again
Posted Apr 19, 2012 11:00 UTC (Thu) by jwakely (subscriber, #60262)
[Link]
Posted May 12, 2012 1:54 UTC (Sat) by Max.Hyre (subscriber, #1054)
[Link]
Back in the day, I was programming a custom multiplexer board for the HP 2100. Obviously I had to have a testbed that would cause it to transfer data in either direction. :-)
Being lazy, most of its commands were single letters: `s' for send, `h' for halt, &c. But to get it to listen for incoming, I had to type in the entire word `receive' correctly. By the end of the week I had no further trouble remembering the spelling.
Not Again
Posted Apr 17, 2012 6:05 UTC (Tue) by juliank (subscriber, #45896)
[Link]
> If ORACLE win at trial Java is DEAD
If they win the patent stuff, then maybe. If they win that copyright argument, then Oracle is dead, and almost every programming language.
Not Again
Posted Apr 17, 2012 22:39 UTC (Tue) by tjc (subscriber, #137)
[Link]
If it gets to the point where we have to start using non-words for API function names, named constants, etc, all to avoid copyright problems, then pre-processors are going to become essential.
Not Again
Posted Apr 18, 2012 15:43 UTC (Wed) by man_ls (subscriber, #15091)
[Link]
Then makers of competing preprocessors would quickly get sued, and so on.
Not Again
Posted Apr 18, 2012 16:18 UTC (Wed) by tjc (subscriber, #137)
[Link]
Not if the copyrighted API symbols were part of the input. We would all have to carry around keyword translation lists sewn into the liners of our jackets. This proposition is only slightly more absurd than Oracles actual claim.
Not Again
Posted Apr 18, 2012 16:50 UTC (Wed) by man_ls (subscriber, #15091)
[Link]
Ah, back to the golden era of quilt-driven programming. Those were the days.
Not Again
Posted Apr 17, 2012 6:09 UTC (Tue) by juliank (subscriber, #45896)
[Link]
> predictable (C, Perl);
C and predictable? If you do f() + g(), the order in which f() and g() are called is undefined. Furthemore, if you were to write a stack machine, and you want to operate on two elements, and you use an expression involving to pops such as: fun(pop(stack), pop(stack)), the same problem arises; you cannot even know which argument to fun() is the top of the stack.
Not Again
Posted Apr 17, 2012 8:49 UTC (Tue) by deepfire (subscriber, #26138)
[Link]
Are you sure?
Not Again
Posted Apr 17, 2012 8:50 UTC (Tue) by deepfire (subscriber, #26138)
[Link]
> If you do f() + g(), the order in which f() and g() are called is undefined.
Are you sure?
Not Again
Posted Apr 17, 2012 9:02 UTC (Tue) by HelloWorld (guest, #56129)
[Link]
Posted Apr 17, 2012 9:12 UTC (Tue) by juliank (subscriber, #45896)
[Link]
OK, formally it's not undefined but unspecified. But for evaluation order, that basically doesn't make much difference. The draft I have (N1256, which is basically C99 + TC3) specifically says so in section 6.5:
"The grouping of operators and operands is indicated by the syntax.74) Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified."
Not Again
Posted Apr 17, 2012 20:24 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246)
[Link]
Yep, and that bit me when I ported Doom to one of our DSPs. The code used the idiom P_Rand()-P_Rand() all over the place to get signed random numbers that were roughly normally distributed. GCC evaluated left-to-right, DSP compiler right-to-left.
While it wouldn't really affect the game play much, it was enough of a change that the prerecorded demo loops didn't function properly, because they expected the engine to be 100% deterministic. Once I found and fixed this error, they started working.
C is predictable when your program is bug free and relies on no implementation defined, unspecified or underspecified behavior. Such a program is extremely tedious to write, and next to impossible even for experienced practitioners. That's because implementation defined behavior is pervasive and useful.
I remember coming across a long, tiresome thread in comp.lang.c once where the goal was to bit-reverse a large integer array in 100% portable ANSI C. I don't recall if anyone succeeded, but the thread went far longer than I expected. Everyone made subtle assumptions about the environment, despite the guarantee that unsigned int is at least guaranteed to provide modulo-wraparound 2s complement arithmetic.
Not Again
Posted Apr 19, 2012 14:19 UTC (Thu) by nye (guest, #51576)
[Link]
>C is predictable when your program is bug free and relies on no implementation defined, unspecified or underspecified behavior.
Okay, I know what 'undefined' means (nasal demons, etc.); I think I know what 'implementation defined' means; I guess 'underspecified' means that the standard writers didn't consider something quite precisely enough? But what - exactly - does 'unspecified' mean?
The first few Google hits don't distinguish sufficiently clearly for my liking between 'implementation defined' and 'unspecified'.
I'm guessing it's something like "a given compiler implementation can do whatever it likes, including behave non-deterministically, but your program remains valid so all other well-defined constructs remain well-defined", whereas 'implementation defined' is the same but without "behave non-deterministically"?
Not Again
Posted Apr 19, 2012 14:43 UTC (Thu) by anselm (subscriber, #2796)
[Link]
»Implementation-defined« means that there are various options out of which the implementation needs to pick one and adhere to it. For example, an implementation can set the size of »short« arbitrarily (as long as it is not smaller than that of »char« and not larger than that of »int«) but the choice, whatever it turns out to be, must be consistently enforced.
With undefined behaviour the implementation can do anything it wants and doesn't have to do the same thing twice even in the same situation.
Not Again
Posted Apr 19, 2012 17:22 UTC (Thu) by nix (subscriber, #2304)
[Link]
... and doesn't have to do what the Standard says elsewhere in the program either, as you are clearly no longer using the Standard as reference. (Or that's what it says, though as a QoI issue compilers try not to produce a program that reformats the disk on every little error.)
Not Again
Posted Apr 23, 2012 8:37 UTC (Mon) by ekj (guest, #1524)
[Link]
Why are compilers not FORBIDDEN from compiling programs that contain instructions which are "undefined". Given that a valid program can format the hard-disk when containing undefined instructions, what are the odds that the programmer actually intended to say: "at this spot, do whatever random thing" ?
Not Again
Posted Apr 23, 2012 9:48 UTC (Mon) by mpr22 (subscriber, #60784)
[Link]
With regard to your first sentence: because people want to be able to compile programs which contain functions that perform arithmetic on signed integers, and the results of signed integer arithmetic overflow may be outside the implementation's reasonable ability to control. (Unsigned integer arithmetic, on the other hand, has strictly-defined overflow behaviour summarized as (UINT_MAX + 1) == 0)
With regard to your second sentence: given a contradiction, everything is true.
Not Again
Posted Apr 23, 2012 9:57 UTC (Mon) by ekj (guest, #1524)
[Link]
Wouldn't arithmethic operations on signed integers that overflow be unspecified rather than undefined ? I was thinking mostly of constructs that are by themselves -always- undefined, not subject to "undefined *if* the sum of these two overflow" which the compiler cannot generally know about beforehand.
What is the rationale for letting "void main(void)" compile and produce a program that you can run (if you dare!) despite the fact that it means, according to the C-spec: "Do nothing, or anything whatsoever."
Not Again
Posted Apr 23, 2012 10:40 UTC (Mon) by anselm (subscriber, #2796)
[Link]
What is the rationale for letting "void main(void)" compile and produce a program that you can run (if you dare!) despite the fact that it means, according to the C-spec: "Do nothing, or anything whatsoever."
According to the C standard,
the prohibition on prototypes for »main« other than »int main(void)« and »int main (int, char **)« applies only to what the standard calls a »hosted environment«, i.e., an operating system like Linux. The standard makes certain stipulations about how such an environment is supposed to call into a C program, and this is where the restrictions on »main()« come from.
The output from a C compiler could, however, be useful in what the standard calls a »freestanding environment«, where – among other differences – the implementation defines how a program is actually started. It could force a different prototype for »main()« or call a differently-named function altogether.
(An obvious example of a »freestanding environment« would be the Linux kernel, which runs on the bare machine, without the benefit of an underlying operating system, since of course it is supposed to be the operating system that would make up part of a »hosted environment« for ISO C.)
Having said that, it is probably safe to say that 99%+ of programs compiled with, say, GNU C, are intended to be run in the hosted environment, which is why, in the highly recommended »-Wall« mode, gcc emits warnings complaining about non-conforming definitions of »main()« unless the »-ffreestanding« option is specified on the command line. If you're serious you could use the »-Werror=main« option to turn this warning into an error.
Not Again
Posted Apr 23, 2012 10:42 UTC (Mon) by mpr22 (subscriber, #60784)
[Link]
The result of void main(void) is only formally undefined if you're targeting a hosted implementation (which, admittedly, application programmers generally are). If you're using a freestanding implementation, then both the type and the name of your program's entry point are implementation-defined, so main might not be magic and even if it is, it might legitimately have a return type of void.
(Note to self: check whether it's definingvoid main(/*whatever*/) or returning from main having done so, that crosses the undefined-behaviour threshold on hosted implementations.)
Not Again
Posted Apr 20, 2012 5:19 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)
[Link]
Implementation defined: We expect implementations to pick a behavior, tell the user about it, and stick to it. It's something you can rely on, but only in that implementation. Example: whether unadorned char is signed or unsigned.
Undefined: Here lie demons. An implementation is entirely within its rights to call system("nethack") or something else equally capricious when it sees one of these. Example: void main(void).
Unspecified: The environment must behave "reasonably", as in, it's not allowed to reformat your hard drive. But, it doesn't have to document its choices, and it can behave differently compile-to-compile. It can do whatever is convenient with best effort. Example: f() + g() Which gets called first?
Make sense?
Not Again
Posted Apr 24, 2012 10:56 UTC (Tue) by nye (guest, #51576)
[Link]
>Make sense?
Yes, thank you.
Not Again
Posted Apr 17, 2012 22:42 UTC (Tue) by tjc (subscriber, #137)
[Link]
That's a feature -- it gives the compiler more opportunities for optimization. If you're going to write tricky code in C, it's important to understand sequence points.
Not Again
Posted Apr 18, 2012 1:10 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
[Link]
It does, but it's so easy to forget some of these rules that it can lead to subtle, mind boggling errors -- errors that may not show up until you change compilers or compile flags, and may never evoke a warning from the compiler. The P_Rand() - P_Rand() example I gave elsewhere is a prime example, and I don't think anyone would have called John Carmack (or whoever wrote that idiom at id) an amateur.
So, while it's all well and good to say "Write tricky C only if you understand sequence points," there are plenty of non-tricky sequences that are nonetheless ill defined and subject to implementation defined or undefined behavior.
Throw in modern hardware and multithreading, and it's.... exciting. Sequence points only barely help you there. The Linux "memory barriers" document is an informative read.
Not Again
Posted Apr 19, 2012 22:12 UTC (Thu) by BenHutchings (subscriber, #37955)
[Link]
The most important things to understand about sequence points being that they are not points and do not generally define a sequence. :-)
Not Again
Posted Apr 21, 2012 15:50 UTC (Sat) by tjc (subscriber, #137)
[Link]
What would you call them then?
Not Again
Posted Apr 21, 2012 16:23 UTC (Sat) by BenHutchings (subscriber, #37955)
[Link]
I would refer to a partial ordering of operations. Anyway, this was fixed in the latest standard (though unfortunately multithreading and atomic operations make this a lot more complex).
Not Again
Posted Apr 18, 2012 19:07 UTC (Wed) by jthill (guest, #56558)
[Link]
From the standpoint of software maintenance I'll argue that's a good thing: when you're changing code, the single most critical question you can ask is "is this change safe?". In common cases leaving expression-evaluation order unspecified when the math doesn't require it limits the spelunking necessary to answer that question to the code in front of you.
Or, shorter: relying on undocumented API implementation details and unnecessarily specifying implementation details both produce bad, fragile code.
Not Again
Posted Apr 19, 2012 22:10 UTC (Thu) by BenHutchings (subscriber, #37955)
[Link]
You're hardly beginning to scrape the surface of unpredictability.
macro expansion, signed overflow, weird operator precedence, complex coercion rules, bitfield layout and signedness, external linkage name limits, char signedness, errno, the whole mess of #include paths and name conflicts, functions you can never safely use (tmpnam(), gets(), atoi(), signal()), ...
Not Again
Posted Apr 20, 2012 17:23 UTC (Fri) by juliank (subscriber, #45896)
[Link]
Of course. I just wanted to point out something that most people most likely don't know about.
Not Again
Posted Apr 17, 2012 11:02 UTC (Tue) by dskoll (subscriber, #1630)
[Link]
Wow... you are so far off base I have no idea where to begin. Did you even read the article? It pointed out the myriad of ways in which PHP is absolutely horrible. Why don't you argue with the article using technical arguments? Oh, right... because there aren't any technical arguments for PHP...
Not Again
Posted Apr 17, 2012 14:53 UTC (Tue) by davide.del.vento (guest, #59196)
[Link]
> Java, If ORACLE win at trial Java is DEAD
You'd better document yourself before spitting non-sense. Most of the crap Oracle was claiming has been already proved invalid, or not applicable. Google in a sense has already won.
Posted Apr 17, 2012 18:51 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
Yes, but what remains is that Oracle is claiming that they control the library API and anything that closely resembles the API, not just their implementation of it.
If they actually do control any use of the API calls, they own every program ever written in JAVA.
Not Again
Posted Apr 17, 2012 21:10 UTC (Tue) by brianomahoney (subscriber, #6206)
[Link]
Spitting nonsense? Just see how long the enterprise puts up with the "Our business plan is to sue our customers" and see how that worked out for SCO and Sonny.
This wont be over, with Ellison's ego till it is heard, en blanc, by the Supreem Court. I know, they should withdraw and slink away but they have also wrecked the JCP and alienated Apache.
Not Again
Posted Apr 18, 2012 19:07 UTC (Wed) by jthill (guest, #56558)
[Link]
Thank you for explaining why C++ is an evil language that should not be used.
Not Again
Posted Apr 20, 2012 3:53 UTC (Fri) by IanJ (guest, #84238)
[Link]
Right, not again. You start with "Ever little while I come across some self-important dumbass who explains why XXX is an evil language"
Later you accuse someone else of being the first to descend into ad hominem attacks. Well, what do you understand by the phrase "self-important dumbass"?
You seem to have very little idea of reality or history. ALGOL came out being careful to make a real structured language avoiding all the mistakes of FORTRAN and discarding machine dependence of machine language. It really was about making processors that execute our programs, rather than using programs as a mechanism to instruct computers (that thought due to Dijkstra... another dumbass).
C came along and put some structured programming over a machine language, but put back in the faults of FORTRAN (using = for assignment), and machine language. It was a big step backwards but has been successfully defended against better alternatives by launching angry attacks against any and all improvements.
C is not an evil language. But because of its flaws it can be used in an evil way - viruses, worms, etc are all possible because of lack of bounds checking. C is just a bad tool.
Yes programming is hard, we need all the help we can get. It's not just a matter of saying "trust programmers they know what they are doing". The best programmers admit it is difficult and too often there are things we don't spot and can use the help of automatic type checking.
I'll say no more. C and C++ are languages that are really lacking:
It's time to move on and get real programming principles back.
Not Again
Posted Apr 20, 2012 10:42 UTC (Fri) by dgm (subscriber, #49227)
[Link]
> C is not an evil language. But because of its flaws it can be used in an evil way - viruses, worms, etc are all possible because of lack of bounds checking. C is just a bad tool.
Absurd. There any _many_ ways a program can be thwarted into running attacked controlled code, improper bounds checking is just one of them.
C is a superb tool, just not for everything. It's a very powerful tool that requires skill and knowledge, but so do most computer languages (even Logo!).
And everything can be used in evil ways. Can you point out any (Turing-complete) language that is not capable of doing bad?
Not Again
Posted Apr 20, 2012 11:17 UTC (Fri) by mpr22 (subscriber, #60784)
[Link]
C and C++ continue to thrive partly because their detractors seem to be incapable of agreeing on what the replacement should be. Alice likes D. Bob likes Java. Charlie likes Ada. Deirdre likes Haskell. Eddie likes Forth. Francine likes Python. George likes Modula-3. Henrietta likes Oberon. (etc)