So the top 64bits, or as we like to call it in the modern age "one native integer" (on now-default platforms) is the network part, and "one native integer" is the customer part of the address.
(Okay, its a "long long" on a commodity PC as of the date of standardization, but they were kind of planning for the future).
Oh the horror.
It's actually quite elegant. No real netmasks, just two integers. Very easy to detect the special addresses by examining the first byte (easily done in FPGA and embedded CPUs). Zero crowding.
The cost savings of being able to load a raw integer into a register and do math on it (a fast lookup table won't even care about the "Real Byte Orderingâ" because there is no promise of "ranges" so no question of adjacency.
So a natural size (two integers), natural math in a platform agnostic way, easily automated and easily aligned (as opposed to shifting bytes etc.)
Your annalysis is shallow. In trying to save bytes you add significant instruction/processing overhead. The bandwidth will shrink the presumed burden of communicating the extra octets to approximately nil, while the fast hardware can be faster by virtue of the natural ordering.
Friends don't ask Friends to "open" programs that pretend to be documents, that are run by interpreters that pretend to be office productivity applications, that have full access with administrative privileges, let alone on machines that have any data that anybody actually cares about...
Microsoft... Where do you think your data _didn't_ go _today_?
It occurs to me that Google is approaching a perfect moment to strike against software patents utterly. Having very few of their own and having a clearly innovative product that is much in demand, they are in the perfect position to show that software patents are harmful to innovation "even for a large company like us.'
Were they to now begin, in each of these cases, a concerted affirmative defense that software, when executing on a "general purpose computer" can not possibly be in violation of any patent.
The argument would have to be two-fold:
First, one can not make a "specific machine" out of a "general machine" by adding functionality. Just as putting a single copy of Moby Dick on a book shelf (or indeed filling a bookshelf with copies of Mobey Dick) does not divest the bookshelf of its bookshelf-ness and convert it into a "Mobey Dick location structural support machine", putting software on a PC or a phone doesn't reduce the nature of the PC or phone to convert it into a "specific machine".
Second, the demonstration of excessive burden and harm that can be brought to bear on a individual device, and makers there of, when the "specific machine" theory is applied as is, given that the one "specific machine" is getting sued 37 times for more than one patent per time, because the individual android device(s) are apparently being forced into a quantum superposition [<==turn that into lawyer speech] where they are each individually transformed by software int dozens or hundreds of individual specific machines.
The very fact that in each law suit the patent needs must read "what is described" is "a machine where" and yet it is sure as rain that the individual pantents don't reference one another in scope. (That is, two patents on say a automobile brake system can be inclusive of one another if one is for say, an actuator and the other is for a caliper, since both will mention the existence of the others collateral components; whereas a "web status update specific machine" would be exclusive of a "local document indexing specific machine").
The fact that in each case Google can reference the other cases as demonstration of cumulative harm caused by the current misinterpration of the precident would give them perfect grounds to argue before the court(s) that software simply cannot rationally or legally be patent material, particularly under the "promote the useful arts and sciences clause".
The ultimate goal would be to get a ruling that software running on, or that can run on, a general purpose computer can not, by definition, be in violation of any patent. Barring that, getting software classified the same as 'perpetual motion machines' as a 'we don't do that' clause of all patent law whoudl be just as ideal.
I have spent my time with many languages. Yes, to get exactly the behavior I want without throwing excessive memory or language overhead I have to make a whole template class that meets the requirement. The horror.
Note that you are simply wrong. Your assumptions are flawed in terms of what is possible and they remain flawed in terms of it being "a royal pain in the ass". You take a contrived-for-example sample code and get all "well mine is easier". Well dude, mine will run in linear time and involves none of that executable data on a stack frame (e.g. the number one vector for buffer over-runs and system smashing, one so pervasive that hardware manufacturers actually changed the way me make CPUs in order to defeat that hole that your language _requires_).
You want to get into a measuring contest? I can whip out boost::qi and write an entire recursive descent parser in overloaded operators like "source >> double_ % ','" to parse and store a list of one or more floating point numbers separated by commas. But unlike your interpreted language it can be fully optimized at compile time, long before it sees the first line of input or a single CPU cycle on my production hardware.
I can write a six-line functor that will recursively express an entire tree to any complexity and depth with visual indentation.
Of coures it takes marginally more effort to make a finely crafted expression of algorithm; just as it takes more effort to hand-craft a piece of fine-crafted leather and hardwood furniture than it takes to assemble a press-board and wing-nut ikea bookshelf.
Now understand I put together a heck of a lot of bookshelves as well. The number of little scripts I make each week or month is legion. I match the available tools to the job at hand. The other day I had to slap out a six-line event driven serial terminal program in tcl (it can be done 8-) because I couldn't change the software load on the classified device that was the only thing near the other classified device that I needed to talk to using a USB to serial dongle. [quite annoying too, because every time I pressed ctrl-break I had to type the program in again.]
The facts are thus: Every language has a purpose and a fan base. No language is the be-all or end-all of languages. Many languages have features that are not as unique as the fan base believes them to be. Once you know how to program, the language is pretty much just a choice of _which_ _way_ you want to have your hands tied. I am "fluent" down to "workable" in C, C++, Erlang, Ada, TCL, BASIC, Pascal, COBOL, Bash, Lisp, awk, SQL, expect, chat, a few specialty languages of my own invention (to stretch the point a touch), Forth, Postscript, Perl, NetExpert (lord save me from that), Php, a little Java (but eeew), lua, and I am sure there are others I have forgotten.
The way your pet language applies one set of data to another is not going to impress me very much. Honestly "array slicing" in Ada was the last paradigm that really impressed me, especially as a way to create and destroy tasks. Not because it was somehow unbelievable but because the syntax was so elegant.
Then again the use of matching in Erlang is right up there too. Erlang would be my favorite interpreted language today if it weren't such a puzzle language (pick up a piece of erlang a year after you last looked at it... blarg! 8-). I am still having fun with erlang, but it isn't gonna make me set aside my C/C++ primary.
And yes, I can be won over by elegant syntax. Your closure syntax isn't it. Ruby sure wasn't it. Java and the JVM hasn't been it for a very long time.
And don't even dare try to lecture me about Managing Complexity and then say "hoping library X makes use of it". In a compiled environment we _know_ which library is going to use what. It's your interpreted languages where you toss data into a resolver and then have to hope. It's impossible, more or less, to write C++ that will fail to dispatch a method when a method is called. Not so for Java and other interpreted lang
template<class D> struct Closure {
const D Datum;
Closure(const D & datum): Datum(datum) { return; } };... if (test) return Closure(cruft); else return Closure(other_cruft);
God, you are so right... I wish I could do this in C++... well maybe someday...
oh wait...
Well its not possible in C though right? bzzzt... wrong... see [ http://grub.enbug.org/NestedFunctions ] though in this case the "closure" only lives for the duration of enclosing composite expression vial the "thunk" mechanism.
Or "for_each(x.begin(),x.end(),functor_type(takes,these,four,args));" to apply an instance of functor_type(initialized with four values at runtime) to each element of sequence x.... oh the freaking humanity, writing all none of those nested loops in C++ just killed me to death...
(now I left off all sorts of syntatic and semantic sugar from a fully body of ready to use code, but _seriously_ dude, this is not that hard. that new. or that special. _Every_ functor of complexity greater than O(1) is likely to be a closure. By the time you are using smart_ptr, Function Pointers. References. Carrying references through iterators, and tons of other possibilities, well doggie, you have it all with none of the waste.
Your language was written in my language dude, if my language couldn't do it yours wouldn't be able to do it either. Like smoke and mirrors it is all memory and pointers. The fact that _you_ don't know how to do it doesn't mean that it isn't done every day. That whole thing you dismiss about the nature of this language inside language _remains_ _true_ whether you dismiss it or not.
Really, your shiny new toy is nothing special... sorry.
Those things Java calls references are actually _pointers_. If you can write "VariableName = null_value" then its is a "pointer" because it "may point at something". A reference _always_ references something valid for its entire lifetime. That is the the _definition_ of the difference. Since a "Java reference" can be null, its a pointer not a proper reference. [Most people who "don't get" pointers think the status has something to do with being able to move the pointer relative to its previous value, but they are wrong. The fact that you can "walk a tree" using the *ahem* reference *ahem* until the reference is null... well that's what pointers are son.]
But you are right in one thing, interfaces are NOT multiple inheritance and I made that clear in my post. They are, as stated, the ugly side-on hack that had to be grafted into Java because the single inheritance tree being fixedly rooted in "Object" prevented them from "un-making" their original mistaken belief that an object never needs to have common ancestry with more than one family tree.
To put it in biological terms, Java was built around the asexual reproduction paradigm, but over time most (but not all clearly) living systems discover that sexual reproduction is superior and nine-out-of-ten organisms in the ecosystem end up benefiting from the genetic line of multiple ancestors. So to with objects, but since Jave has no gametes, they had to introduce parasitism by creating a way to graft on shriveled little side-definitions to the objects linage.
So you sir, are a fan boy who needs to read up on the technology before you go correcting people who have done.
It sure is throwing memory at problem. A closure is a snapshot of memory from a context so that you can peer back into that moment of time to the values in place at the time, to arbitrary depth.
In C++ you have to return the information explicitly. That is you have to decide at the "moment of closure" what memory you are going to save rather than having the environment do a graph completion of rechable data and store it.
By the way if you know the data you are actually going to use you can construct a functor, or (terribly) collect that data in a function and then return a pointer to a nested function that "can see that outer scope"... eeeew...
So yea, in some language you can get the non-select clone of memory to arbitrary depth so that you don't have to selectively save the information yourself.
That's is the very definition of throwing memory at a problem.
(I know the technologies quite well, and I know their implications. Closures in your language of choice were implemented in C so by definition you can implement them in C. But like I said its just the latest secret sauce...)
The fact that Ruby to C produces code "neck and neck" with ruby running inside the JVM is pretty much a universal indictment of Ruby, which makes Mirah doubly pointless.
See the plain truth is that the JVM is a least-common-denominator. It is an interpreter for gawd's sake, and one that knows it is sufficiently crap that it has a "just in time compiler" so that it can set itself aside whenever it realizes that it is too much crap for the code it is running. But it still suffers from the conceit that it is ever _not_ too much crap... why not just JIT the entire code base? And if that, why not just compile the code base once to begin wiht? Yes, then it woudlnt' be a "VM" but come on, competing with runtime to run a compiler? Really? Because you know that compiled code would be "better"? But "not always"? REALLY?
Keep in mind that this whole byte-code compile thing running inside a virtual machine definition is the UCSD P-System (circa 1975 or so). Its reliable, the voyager space craft are running the P-System even as we speak. But claiming it is new, novel, "a work of art" or any other damn thing is overselling the cow.
Ask yourself why none of the "good" math libraries are written in java bytecode? Ask yourself why JINI had to be invented? Ask yourself why JIT?
The whole "compile once, run anywhere" thing is a _lie_ for two reasons. (1) the results "run anywhere" but only for _extremely_ constrained definitions of "anywhere" and (2) you "compile once" so the JVM can compile it again and again during runtime.
If Ruby, the language, wasn't full of... um... "crap"... the ruby-to-native-C translations would _naturally_ run much faster than the ruby-to-JVM JRuby just by virtue of not being in the VM. But lo and behold, that's not the case Ruby is _modeled_ on the mistakes of Java and its ilk. Perl-to-C has many of the same problems, and likely Python would as well. They just don't labor under the misapprehension that if they could just find the right platform things would be better. They make themselves the best version of themselves possible. Perl does a damn good job of being Perl, and Python "does okay" for being plagued by that stupid white-space thing, and having a completely unstable incompatability between V2.X and V3.
But Ruby? Its a mess. A wash. An over thought and inconsistent pile of -blarg!-. No matter how many places you try to stick it, you will never find the magical context where it isn't overblown and too ugly to mainstream. The best you could hope for is getting adopted by Apple and re-branded iRuby since those apple fans will seemingly buy into anything as long as someone in a black turtleneck tells them to. iRuby won't be any less craptacular than Ruby, but it will have a home...
So calling it Mirah or JRuby isn't going to matter... it deserves the JVM and good luck to it I say.
(For prospective, I learned my "C" using "cc" on Unix System Vr3...)
I agree that most of the C++ I have seen has been pretty abysmal, but that's not the paradigm's fault, nor a fault of the language. The average professional in _any_ field is, by definition, pretty average, and tautologically therefore not "excellent".
I can say the same thing for overly clever C programmers. There is a reason that the Obfuscated C contest is more popular than the obfuscation contests of any other language.
The problem is, of course, that if you only have a hammer every problem looks like a nail. C++ is object oriented, but unlike other object oriented languages, it is not _limited_ to pure object oriented behavior. There is nothing C can do that C++ cannot. (It is, of course, not optimal to use the C++ compiler to compile purely straight C since it will bring along some plumbing etc, but thats not a killer if you use GCC anyway as.)
So yea, you get a lot of people who learned languages instead of programming and you get a mess that focuses best on one limited paradigm. Knowing when to object and when not to object in C++ is a non-trivial task. Throwing away the object ability because you either are not good at it yet or have never seen it done right is just a sign of stagnation (IMHO of course).
So I am sure we all feel safer if you stay where you are and don't over-reach your understanding. We fully wish more people woud just stop venturing out, making a mess, and then blaming their tools.
Your disdain for "the whole object oriented thing" is quite different from my disdain of Java and the JVM for being irredeemably flawed. After all, every time you have put a function pointer inside a structure or built a set of libraries that use a specific set of structures you have been using "the object oriented thing", if only dimly in your own awareness.
The problem with most "object oriented programmers" and their "object oriented programming sucks" counterparts is a limit of comprehension in the form of overly literal thinking. They see/hear the inevitable, and massivly flawed "car analogies" a then they roast on that spit. They try to put "drive" in "car" when they full well that cars do not drive themselves. That is the fail because they, having picked a metaphor for a block of code, fail to use that metaphor consistently. Once they violate their own designs they find themselves trapped, beached if you will, on a shore of mismatched functional domains.
The hardest thing for an author to learn is that writers block is what happens when you write words you love that just don't fit the story. The only cure is to start hitting paragraph delete until you are back to where the story makes sense.
The hardest thing for a programmer to learn is that you likewise have to toss out bad code instead of trying to fix it when you get to a place where the code you wrote, or inteed your object designs and functional signatures, don't properly fit the job you are tying to accomplish.
Once I learned to delete my mistakes I became an outstanding "object oriented" programmer. Likewise for "functional programming" and "procedural programming". Its all the same skill.
Only a poor craftsman blames his tools. Only a fool uses a tool he knows is broken. Only an idiot things those statements are in conflict.
I _massively_ use destructors for doing more than freeing memory, particularly in multi-threaded code.
Iet's see...
closing files.
Releasing, e.g. _unlocking_ regions of files shared between applications (e.g. matching flock() calls between constructor and destructor to lock and release records at precise times).
Terminating protocols semantically and _then_ closing sockets instead of just closing sockets.
Issuing signals on the _last_ release of a mutex that is coupled with a condition variable instead of on every release of a nested mutex.
Unlocking and dismissing shared object libraries (e.g. undoing dlopen()) when, but not before, the last instance of any/every object dependent on the shared object file goes out of scope.
Preventing "Cruft" in my heap by doing "deep" memory frees of complex structures as soon as I no longer need them instead of at "some random time in the future if ever".
Changing modes and states on devices using ioctl() etc. (e.g. when the last "raw" use of the controlling terminal goes out of scope you put the terminal back into line mode until/unless you need to bring it back into raw mode.)
Resetting hardware on last use.
Emulating devices and subsystems that, by definition, reset themselves on last use.
Doing all of the above with "exception safety" without having to write a ass-ton of "finally" blocks (though I _do_ whish C++ had "finally" 8-).
Doing all of the above in "deep structures" so that my objects are true active objects instead of just nested hunks of memory.
You are like a blind guy asking "when was the last time you really used your eyes for anything but reading" because you have never heard of art, when you presume destructors are "really just for freeing memory" you demonstrate a horrific limitation in your understating of object, functional, and event driven programming.. Just because you don't understand the non-beginner ways to use a construct doesn't mean the construct is only used the way a beginner would use it.
Meanwhile:
I lived through the "P-System" and "P-Code" the shortcomings and costs overheads and raft of annoying assumptions built into the JVM are a "given" to me. Sorry for not doubling the size of my rant to make you happy. I work with too many system internals to think the JVM is a win. You go back to treating your heap as executable, and over-stressing your CPU translation look-aside buffers, and leave me alone... 8-)
In counterpoint:
I think closures are overrated, but I don't disparage them because I recognize that the fact that just because "they have never been particularly necessary or useful to anything I have done" doesn't mean that they are unnecessary or useless to persons other than I. Plus you can pull the same thing more or less in C and C++, for a limited number of variables, by returning a pointer to a nested function, but like eeew.... Closures do typically require an executable data segment, which I find impure, but all of java requires an executable data segment so who am I to judge. Closures are just the latest brand of secret sauce to allow people to throw memory at a problem instead of logic. 8-)
g() wont compile because "std::vector" inside g(), is not explicitly coupled to the template definition of g() so it could be anything. Add "typename" and then it is unambiguous. Might as well ask why "any car" and "every car" are not the same sentiment in English.
struct s is in no way dependent on class T, so there would be no difference between an s and an s, so the "template " has no meaning or purpose. The fact that you have to remove the syntatic no-op noise is not that complex and every language will fail you for it. Might as well ask why "float char x;" will not compile in Java.
Not all tools are intended for use by people unwilling to learn how to operate them correctly, in fact none are. And all tools and procedures have a "Deep end" unless thy are inherently too shallow to be useful. Not everybody should or will be happy out beyond the breakers just because some people are. That doesn't mean we should put up chain fences to keep people going out there because "the shore-huggers would be made to feel inferior when they see others exceed them".
You can only dumb-down the planet so far before it becomes counter-productive.
[but thanks for reminding me about typename... 8-)]
The JVM is not that much more than the old P-System and P-Code reinvented by people who didn't learn from the past. It is "art" sure, but it isn't "fine art" that has advanced the human condition by any stretch of the imagination. It just had better P.R.
Prepend is a neologism true enough, but it has a clear meaning and a unique definition, said definition being easily accessible to both inquiry and contextual meaning.
Now lets look at "performant", it seems to be an adjective. Adjectives ending in -ant, -ance, or -ent (depending on the preceding consonant) generally mean "meets a minimal requirement". See "conformance" and "compliant" etc. These words also carry a requirement of a secondary reference to an external entity. One must be conformant or compliant with respect to something.
So does the speaker mean to say that the language barely meets some minimum requirement of performance? And if so where is the standard of that performance documented?
I have no problem with the coinage of this usage. It is, incomplete and therefore meaningless. It might as well say "new and improved". It is pure marketing speech designed to manipulate the reader into assigning gravitas to the statement without meeting any of the requirements necessary for clear communication or concise meaning.
So in this case "performant" is pure "word fail" by a want-to-be intellectual.
Slashdot, Wikipedia, and Google are "proper nouns" as such they have a definition based on their usage. Names (e.g. proper nouns) are magical in languages. They define themselves. That is, there is no uncertainty when a new string of letters or phonyms are assigned as the proper name of a unique entity.
As used, "performant" is apparently an adjective. When used without a proper preceding or trailing contextual definition it has no actual meaning. We are left to infer a meaning because of the similarity of the word to other words, but that has no warrant of being the actual meaning intended by the speaker.
Now you can "coin a word" any time you like in English, thats true, but when you do so coin a word you need to provide a proper definition. If I write "Java is gafault" is that "absent of faults" or "chock-full of faults"? The suffix "-ant" and "-ent" ("a" vs "e" depends on the preceding consonant) when used in an ajective context usually caries a "minimum required" leading to the state being described. Being "complaint" does not bring along, for instance, a promise of anything more than minimum acceptability. Look at all the -ant and -ent ajective words, compliant, complacent, etc. none imply excellence.
So did the poster mean "it grudgingly meets minimum required performance parameters" or what?
The problem with this word not being a word is that it doesn't have a common meaning to the audience. Its marketing speech. It sounds like it has gravitas but you can't be held to it having any absolute value. Its like if someone said "100% faster". Is that twice the speed by some measure? Is that "now it is instant"? is it twice its old speed or twice the speed of some external metric. e.g. faster than what and when?
So performant sounds all serious and impressive, but it doesn't _mean_ anything at all (yet).
Why are people so obsessed with plot? Movies should just be sound-bytes, special effects, and explosions, just ask Michel Bey. (however you spell his name.)
Seriously dude, syntax is _everything_ in any language for any purpose. Study up man. What is the first pass the compiler makes? What is the first thing a programmer has to parse when reading someone else's code? If it weren't for syntax this post would could be a sorted list of words and repetition counts, but it would have no meaning.
"kill not I" from Star Trek original series... what does it mean as wrtten? the plea for mercy: "kill I not", or the promise to behave: "I not kill"...?
He did share them... stop trying to "solve" the problem of programmers needing to know how to program by writing languages that try to cover for dummies. We have plenty of languages that dummies can use safely. The problem has been solved.
Computer languages are like power tools. They can be "so safe, but no safer" before they start losing function. They just _don't_ make a band saw that any 12 year old can use in complete safety. Same for joiner, circular saw, planer, or just good old knife.
Tools are _not_ supposed to be _safe_. They are only supposed to be "no more dangerous than necessary". We make cheap plastic toy versions of tools for kids to practice with, but eventually they either go away or they have to learn to use the real thing.
I will believe in these "for dummies" versions of language the day a contractor shows up at my house with a Fischer-Price nail gun that will actually hold up sheet rock but is safe enough to hand to my neighbor's 5 year old.
The "clever new idea" is that people don't _deserve_ to operate in fields where they are unwilling or unable to learn the skills required. This is just as true of my profession (programming etc) is it is true that my programming acumen doesn't mean that I should be able to walk into CERN and have a go at the LHC even though I know squat about high-energy physics.
Read the signature line (v v v v v v v v), it is a truism.
I am a guy who loves computer languages. I had a lot of fun with Ada for gawd's sake. I am pursuing erlang at the moment. Thought about haskell but it was just too big to play with...
So keeping that in mind?.... Java and the JVM was a non-starter for me.
Every time a new object oriented language comes out the purists start with "we don't need multiple inheritance" and so on, and they always end up having to hack it back in as some half-conceived junk (see "interfaces" providing, at a later date, all the much shat upon "complexity" of multiple inheritance with none of the ability to provide a default implementation, so then you add delegation which is all the default implementation with none of the inheritance etc...). "Java doesn't have pointers" my pasty white behind, every object is a pointer in java, you just can't use them properly, but they do manage to use pointers to prevent first class object copying, so then they added clone() etc.
Then they "didn't need" proper destructor behavior, we have a finalize that would run at some time in the future, but really the code out to know when the last object reference is going out of scope so it can call a destructor manually if it wants. That was a stopper for me.
See they coded their "every other language should have remained pure" hubris into their virtual machine, they encoded it into their hardware, from inception they designed their system to be limited and resistant to repair. So no thank you. So now Ruby fans want to take their niche language and cram it into the fundamentally flawed Java VM. Ooooohhh sign me up!
I swear the language feels like it was designed on a dirty napkin by someone who had no grasp of scope or symmetry.
Might as well be Python (I am old enough to remember RPG and COBOL Coding Forms, saving one apparent character, e.g. "}", (because in Python ":[newline]" is the same as "{" so what did we save again?) for the privilege of using white space, and counting tabs, as a control structure. And save the "but now we have editors to help us so that doesn't matter" tripe, we had coding forms to "help us" etc. And I suppose its okay to hack off a foot because you can alwasy get a peg-leg to help you too?
Why is it that each new generation of "language designers" insist on reinventing the same old square-wheels of the previous generation and calling it new?
Now get of my damn lawn... (yes, this rant makes me feel old, but come on people, imagine where we would be going if you would just stop trying to reopen the same tapped out mines...)
Thank you for your informative analysis (or at least your ability to go read project web site, which can be quite rare here. 8-)
This whole article _still_ seems like a big steaming pile of "who cares" to me. Ruby lost its slot in the language wars, so they brought us "rails" which lost again. Now they want to lose again by moving their syntax and whatnot into Java and the JVM, which is busily being "monitized" (e.g. sued into niche status) by Oracle after their acquisition of Sun.
Do you honestly think that after taking on Goggle for the non-Java-but-Java-like innards (I forget the name... Davlik?... something like that) of Android they are gonna let cacao or any of the other JVMs slide?
Talk about chasing rainbows into a sewage pumping station...
Have the Ruby people made a run at reviving their "nicer" niche syntax inside "mono" a.k.a. C-pound (=that was the troll I warned you about 8-) yet? If not that is clearly their next stop on this tour of "eh, whatever" they are taking.
F5 Networks scratches off the serial numbers of Red Hat enterprise and produces CentOS so that they don't have to license Enterprise from Red Hat. They started this (CentOS) because every one of their Big-IP boxes was running Red Hat and they needed a stripped version to avoid paying the license fees for Red Hat's work. They explained this to me and then gave me the in-house extension to call if I found any Red Hat branding back when I worked there. (Yes, I have first-hand knowledge of these facts.) It's wrong at a moral level, but so what.
Most people who get Red Hat kernels end up applying all the patches anyway. Why is it more efficient or reasonable to release the kernel to all those people as straight-source plus patches, when they all want patched source in the first place. From an efficiency standpoint releasing the patches source is good for everybody but the leaches.
If F5/CentOS was going through the trouble to bundle and test all the packages form the same sources as Red Hat is getting them, then this wouldn't be a issue. It isn't about the sources of the sources, its about the testing and integration that Red Hat does that F5/CentOS has chosen to use with less than a nod.
So F5 is too cheap to pay for Red Hat's work, and they are too cheap to _duplicate_ Red Hat's work, and they are too cheap to build a distribution that _only_ contained what they actually needed, so where _exactly_ is Red Hat wrong for the very human response of saying "blow off, you freeloaders..."?
Besides, I bet if you pay support, or ask nice, you can get the patches anyway. The fact that the default distribution is fully patched instead of making you spend the time to patch it yourself is actually a _win_ for the paying customers.
And all of these actions from both companies are fully GPL compliant.
I briefly worked at F5 Networks. They are "the community" behind CentOS. They had an in-house extension to call whenever you found any RedHat Branding in CentOS. The entire "distribution" was created so that they could put Red Hat into their enterprise load balancers without having to do that pesky licensing and fair dealing thing.
I am all for Red Hat doing whatever they want in this respect to CentOS, as CentOS is an unfair deal in the first place (IMHO of course).
Nohting in the GPL requires the source to be delivered as base plus patches. Red Hat was bing a good citizen. Others were being less so. Red Hat decided to play the field provided.
It is a loss to the honest people, but dishonesty is always a loss to the honest people eventually. If CentOS et al were engaged in something more than just scraping the serial numbers off of other people's work, then I would be more upset.
Stealing other peoples earned reputation by re-marking it as your own with little-or-no attribution is bound to invoke human nature against you eventually. It was only a matter of time. I bet Red Hat will _also_ make the patches available to those who ask. That is, just because their default distribution is a pre-patched blob, and lets face it, everyone was applying the whole patch set by default anyway, doesn't mean that the patches are going to be kept in a vault somewhere. Maybe "asking for it" will require a support contract. Maybe it will just require asking. Who knows.
But if Red Hat manages to make F5 pay what they should have paid in the first place instead of spending a like amount on "running a distribution" chop-shop maybe the fair dealing would have never caused this sort of thing in the first place.
Php showed up as perfect because it is almost perfectly comment free.
This is an indictment of the language, not the programmers, since well-commented php is drastically slower (like.5% tomg!) than stripped down and nearly obfuscated code. That fraction really adds up when you have all those unnecessarily dynamic web pages to generate.
Now if someone were to do a comparison on the ratio of active code, to code that is commented out but not removed because the author doesn't use version control... In that category PHP would freaking rule!
Slashdot Mirror
So the top 64bits, or as we like to call it in the modern age "one native integer" (on now-default platforms) is the network part, and "one native integer" is the customer part of the address.
(Okay, its a "long long" on a commodity PC as of the date of standardization, but they were kind of planning for the future).
Oh the horror.
It's actually quite elegant. No real netmasks, just two integers. Very easy to detect the special addresses by examining the first byte (easily done in FPGA and embedded CPUs). Zero crowding.
The cost savings of being able to load a raw integer into a register and do math on it (a fast lookup table won't even care about the "Real Byte Orderingâ" because there is no promise of "ranges" so no question of adjacency.
So a natural size (two integers), natural math in a platform agnostic way, easily automated and easily aligned (as opposed to shifting bytes etc.)
Your annalysis is shallow. In trying to save bytes you add significant instruction/processing overhead. The bandwidth will shrink the presumed burden of communicating the extra octets to approximately nil, while the fast hardware can be faster by virtue of the natural ordering.
Well... no one else will date me...
8-)
Friends don't ask Friends to "open" programs that pretend to be documents, that are run by interpreters that pretend to be office productivity applications, that have full access with administrative privileges, let alone on machines that have any data that anybody actually cares about...
Microsoft... Where do you think your data _didn't_ go _today_?
It occurs to me that Google is approaching a perfect moment to strike against software patents utterly. Having very few of their own and having a clearly innovative product that is much in demand, they are in the perfect position to show that software patents are harmful to innovation "even for a large company like us.'
Were they to now begin, in each of these cases, a concerted affirmative defense that software, when executing on a "general purpose computer" can not possibly be in violation of any patent.
The argument would have to be two-fold:
First, one can not make a "specific machine" out of a "general machine" by adding functionality. Just as putting a single copy of Moby Dick on a book shelf (or indeed filling a bookshelf with copies of Mobey Dick) does not divest the bookshelf of its bookshelf-ness and convert it into a "Mobey Dick location structural support machine", putting software on a PC or a phone doesn't reduce the nature of the PC or phone to convert it into a "specific machine".
Second, the demonstration of excessive burden and harm that can be brought to bear on a individual device, and makers there of, when the "specific machine" theory is applied as is, given that the one "specific machine" is getting sued 37 times for more than one patent per time, because the individual android device(s) are apparently being forced into a quantum superposition [<==turn that into lawyer speech] where they are each individually transformed by software int dozens or hundreds of individual specific machines.
The very fact that in each law suit the patent needs must read "what is described" is "a machine where" and yet it is sure as rain that the individual pantents don't reference one another in scope. (That is, two patents on say a automobile brake system can be inclusive of one another if one is for say, an actuator and the other is for a caliper, since both will mention the existence of the others collateral components; whereas a "web status update specific machine" would be exclusive of a "local document indexing specific machine").
The fact that in each case Google can reference the other cases as demonstration of cumulative harm caused by the current misinterpration of the precident would give them perfect grounds to argue before the court(s) that software simply cannot rationally or legally be patent material, particularly under the "promote the useful arts and sciences clause".
The ultimate goal would be to get a ruling that software running on, or that can run on, a general purpose computer can not, by definition, be in violation of any patent. Barring that, getting software classified the same as 'perpetual motion machines' as a 'we don't do that' clause of all patent law whoudl be just as ideal.
I have spent my time with many languages. Yes, to get exactly the behavior I want without throwing excessive memory or language overhead I have to make a whole template class that meets the requirement. The horror.
Note that you are simply wrong. Your assumptions are flawed in terms of what is possible and they remain flawed in terms of it being "a royal pain in the ass". You take a contrived-for-example sample code and get all "well mine is easier". Well dude, mine will run in linear time and involves none of that executable data on a stack frame (e.g. the number one vector for buffer over-runs and system smashing, one so pervasive that hardware manufacturers actually changed the way me make CPUs in order to defeat that hole that your language _requires_).
You want to get into a measuring contest? I can whip out boost::qi and write an entire recursive descent parser in overloaded operators like "source >> double_ % ','" to parse and store a list of one or more floating point numbers separated by commas. But unlike your interpreted language it can be fully optimized at compile time, long before it sees the first line of input or a single CPU cycle on my production hardware.
I can write a six-line functor that will recursively express an entire tree to any complexity and depth with visual indentation.
Of coures it takes marginally more effort to make a finely crafted expression of algorithm; just as it takes more effort to hand-craft a piece of fine-crafted leather and hardwood furniture than it takes to assemble a press-board and wing-nut ikea bookshelf.
Now understand I put together a heck of a lot of bookshelves as well. The number of little scripts I make each week or month is legion. I match the available tools to the job at hand. The other day I had to slap out a six-line event driven serial terminal program in tcl (it can be done 8-) because I couldn't change the software load on the classified device that was the only thing near the other classified device that I needed to talk to using a USB to serial dongle. [quite annoying too, because every time I pressed ctrl-break I had to type the program in again.]
The facts are thus: Every language has a purpose and a fan base. No language is the be-all or end-all of languages. Many languages have features that are not as unique as the fan base believes them to be. Once you know how to program, the language is pretty much just a choice of _which_ _way_ you want to have your hands tied. I am "fluent" down to "workable" in C, C++, Erlang, Ada, TCL, BASIC, Pascal, COBOL, Bash, Lisp, awk, SQL, expect, chat, a few specialty languages of my own invention (to stretch the point a touch), Forth, Postscript, Perl, NetExpert (lord save me from that), Php, a little Java (but eeew), lua, and I am sure there are others I have forgotten.
The way your pet language applies one set of data to another is not going to impress me very much. Honestly "array slicing" in Ada was the last paradigm that really impressed me, especially as a way to create and destroy tasks. Not because it was somehow unbelievable but because the syntax was so elegant.
Then again the use of matching in Erlang is right up there too. Erlang would be my favorite interpreted language today if it weren't such a puzzle language (pick up a piece of erlang a year after you last looked at it... blarg! 8-). I am still having fun with erlang, but it isn't gonna make me set aside my C/C++ primary.
And yes, I can be won over by elegant syntax. Your closure syntax isn't it. Ruby sure wasn't it. Java and the JVM hasn't been it for a very long time.
And don't even dare try to lecture me about Managing Complexity and then say "hoping library X makes use of it". In a compiled environment we _know_ which library is going to use what. It's your interpreted languages where you toss data into a resolver and then have to hope. It's impossible, more or less, to write C++ that will fail to dispatch a method when a method is called. Not so for Java and other interpreted lang
template<class D> ...
struct Closure {
const D Datum;
Closure(const D & datum): Datum(datum) { return; }
};
if (test)
return Closure(cruft);
else
return Closure(other_cruft);
God, you are so right... I wish I could do this in C++... well maybe someday...
oh wait...
Well its not possible in C though right? bzzzt... wrong... see [ http://grub.enbug.org/NestedFunctions ] though in this case the "closure" only lives for the duration of enclosing composite expression vial the "thunk" mechanism.
Or "for_each(x.begin(),x.end(),functor_type(takes,these,four,args));" to apply an instance of functor_type(initialized with four values at runtime) to each element of sequence x.... oh the freaking humanity, writing all none of those nested loops in C++ just killed me to death...
(now I left off all sorts of syntatic and semantic sugar from a fully body of ready to use code, but _seriously_ dude, this is not that hard. that new. or that special. _Every_ functor of complexity greater than O(1) is likely to be a closure. By the time you are using smart_ptr, Function Pointers. References. Carrying references through iterators, and tons of other possibilities, well doggie, you have it all with none of the waste.
Your language was written in my language dude, if my language couldn't do it yours wouldn't be able to do it either. Like smoke and mirrors it is all memory and pointers. The fact that _you_ don't know how to do it doesn't mean that it isn't done every day. That whole thing you dismiss about the nature of this language inside language _remains_ _true_ whether you dismiss it or not.
Really, your shiny new toy is nothing special... sorry.
Those things Java calls references are actually _pointers_. If you can write "VariableName = null_value" then its is a "pointer" because it "may point at something". A reference _always_ references something valid for its entire lifetime. That is the the _definition_ of the difference. Since a "Java reference" can be null, its a pointer not a proper reference. [Most people who "don't get" pointers think the status has something to do with being able to move the pointer relative to its previous value, but they are wrong. The fact that you can "walk a tree" using the *ahem* reference *ahem* until the reference is null... well that's what pointers are son.]
But you are right in one thing, interfaces are NOT multiple inheritance and I made that clear in my post. They are, as stated, the ugly side-on hack that had to be grafted into Java because the single inheritance tree being fixedly rooted in "Object" prevented them from "un-making" their original mistaken belief that an object never needs to have common ancestry with more than one family tree.
To put it in biological terms, Java was built around the asexual reproduction paradigm, but over time most (but not all clearly) living systems discover that sexual reproduction is superior and nine-out-of-ten organisms in the ecosystem end up benefiting from the genetic line of multiple ancestors. So to with objects, but since Jave has no gametes, they had to introduce parasitism by creating a way to graft on shriveled little side-definitions to the objects linage.
So you sir, are a fan boy who needs to read up on the technology before you go correcting people who have done.
Thank you for agreeing with me, even if you wrote it like a correction...?
I tend to use smart pointer so that I never have to call delete, except in those rare cases where I want to.
Hence the whole list of other things I actually use destructors for.
It sure is throwing memory at problem. A closure is a snapshot of memory from a context so that you can peer back into that moment of time to the values in place at the time, to arbitrary depth.
In C++ you have to return the information explicitly. That is you have to decide at the "moment of closure" what memory you are going to save rather than having the environment do a graph completion of rechable data and store it.
By the way if you know the data you are actually going to use you can construct a functor, or (terribly) collect that data in a function and then return a pointer to a nested function that "can see that outer scope"... eeeew...
So yea, in some language you can get the non-select clone of memory to arbitrary depth so that you don't have to selectively save the information yourself.
That's is the very definition of throwing memory at a problem.
(I know the technologies quite well, and I know their implications. Closures in your language of choice were implemented in C so by definition you can implement them in C. But like I said its just the latest secret sauce...)
The fact that Ruby to C produces code "neck and neck" with ruby running inside the JVM is pretty much a universal indictment of Ruby, which makes Mirah doubly pointless.
See the plain truth is that the JVM is a least-common-denominator. It is an interpreter for gawd's sake, and one that knows it is sufficiently crap that it has a "just in time compiler" so that it can set itself aside whenever it realizes that it is too much crap for the code it is running. But it still suffers from the conceit that it is ever _not_ too much crap... why not just JIT the entire code base? And if that, why not just compile the code base once to begin wiht? Yes, then it woudlnt' be a "VM" but come on, competing with runtime to run a compiler? Really? Because you know that compiled code would be "better"? But "not always"? REALLY?
Keep in mind that this whole byte-code compile thing running inside a virtual machine definition is the UCSD P-System (circa 1975 or so). Its reliable, the voyager space craft are running the P-System even as we speak. But claiming it is new, novel, "a work of art" or any other damn thing is overselling the cow.
Ask yourself why none of the "good" math libraries are written in java bytecode? Ask yourself why JINI had to be invented? Ask yourself why JIT?
The whole "compile once, run anywhere" thing is a _lie_ for two reasons. (1) the results "run anywhere" but only for _extremely_ constrained definitions of "anywhere" and (2) you "compile once" so the JVM can compile it again and again during runtime.
If Ruby, the language, wasn't full of... um... "crap"... the ruby-to-native-C translations would _naturally_ run much faster than the ruby-to-JVM JRuby just by virtue of not being in the VM. But lo and behold, that's not the case Ruby is _modeled_ on the mistakes of Java and its ilk. Perl-to-C has many of the same problems, and likely Python would as well. They just don't labor under the misapprehension that if they could just find the right platform things would be better. They make themselves the best version of themselves possible. Perl does a damn good job of being Perl, and Python "does okay" for being plagued by that stupid white-space thing, and having a completely unstable incompatability between V2.X and V3.
But Ruby? Its a mess. A wash. An over thought and inconsistent pile of -blarg!-. No matter how many places you try to stick it, you will never find the magical context where it isn't overblown and too ugly to mainstream. The best you could hope for is getting adopted by Apple and re-branded iRuby since those apple fans will seemingly buy into anything as long as someone in a black turtleneck tells them to. iRuby won't be any less craptacular than Ruby, but it will have a home...
So calling it Mirah or JRuby isn't going to matter... it deserves the JVM and good luck to it I say.
(For prospective, I learned my "C" using "cc" on Unix System Vr3...)
I agree that most of the C++ I have seen has been pretty abysmal, but that's not the paradigm's fault, nor a fault of the language. The average professional in _any_ field is, by definition, pretty average, and tautologically therefore not "excellent".
I can say the same thing for overly clever C programmers. There is a reason that the Obfuscated C contest is more popular than the obfuscation contests of any other language.
The problem is, of course, that if you only have a hammer every problem looks like a nail. C++ is object oriented, but unlike other object oriented languages, it is not _limited_ to pure object oriented behavior. There is nothing C can do that C++ cannot. (It is, of course, not optimal to use the C++ compiler to compile purely straight C since it will bring along some plumbing etc, but thats not a killer if you use GCC anyway as.)
So yea, you get a lot of people who learned languages instead of programming and you get a mess that focuses best on one limited paradigm. Knowing when to object and when not to object in C++ is a non-trivial task. Throwing away the object ability because you either are not good at it yet or have never seen it done right is just a sign of stagnation (IMHO of course).
So I am sure we all feel safer if you stay where you are and don't over-reach your understanding. We fully wish more people woud just stop venturing out, making a mess, and then blaming their tools.
Your disdain for "the whole object oriented thing" is quite different from my disdain of Java and the JVM for being irredeemably flawed. After all, every time you have put a function pointer inside a structure or built a set of libraries that use a specific set of structures you have been using "the object oriented thing", if only dimly in your own awareness.
The problem with most "object oriented programmers" and their "object oriented programming sucks" counterparts is a limit of comprehension in the form of overly literal thinking. They see/hear the inevitable, and massivly flawed "car analogies" a then they roast on that spit. They try to put "drive" in "car" when they full well that cars do not drive themselves. That is the fail because they, having picked a metaphor for a block of code, fail to use that metaphor consistently. Once they violate their own designs they find themselves trapped, beached if you will, on a shore of mismatched functional domains.
The hardest thing for an author to learn is that writers block is what happens when you write words you love that just don't fit the story. The only cure is to start hitting paragraph delete until you are back to where the story makes sense.
The hardest thing for a programmer to learn is that you likewise have to toss out bad code instead of trying to fix it when you get to a place where the code you wrote, or inteed your object designs and functional signatures, don't properly fit the job you are tying to accomplish.
Once I learned to delete my mistakes I became an outstanding "object oriented" programmer. Likewise for "functional programming" and "procedural programming". Its all the same skill.
Only a poor craftsman blames his tools. Only a fool uses a tool he knows is broken. Only an idiot things those statements are in conflict.
I _massively_ use destructors for doing more than freeing memory, particularly in multi-threaded code.
Iet's see...
closing files.
Releasing, e.g. _unlocking_ regions of files shared between applications (e.g. matching flock() calls between constructor and destructor to lock and release records at precise times).
Terminating protocols semantically and _then_ closing sockets instead of just closing sockets.
Issuing signals on the _last_ release of a mutex that is coupled with a condition variable instead of on every release of a nested mutex.
Unlocking and dismissing shared object libraries (e.g. undoing dlopen()) when, but not before, the last instance of any/every object dependent on the shared object file goes out of scope.
Preventing "Cruft" in my heap by doing "deep" memory frees of complex structures as soon as I no longer need them instead of at "some random time in the future if ever".
Changing modes and states on devices using ioctl() etc. (e.g. when the last "raw" use of the controlling terminal goes out of scope you put the terminal back into line mode until/unless you need to bring it back into raw mode.)
Resetting hardware on last use.
Emulating devices and subsystems that, by definition, reset themselves on last use.
Doing all of the above with "exception safety" without having to write a ass-ton of "finally" blocks (though I _do_ whish C++ had "finally" 8-).
Doing all of the above in "deep structures" so that my objects are true active objects instead of just nested hunks of memory.
You are like a blind guy asking "when was the last time you really used your eyes for anything but reading" because you have never heard of art, when you presume destructors are "really just for freeing memory" you demonstrate a horrific limitation in your understating of object, functional, and event driven programming.. Just because you don't understand the non-beginner ways to use a construct doesn't mean the construct is only used the way a beginner would use it.
Meanwhile:
I lived through the "P-System" and "P-Code" the shortcomings and costs overheads and raft of annoying assumptions built into the JVM are a "given" to me. Sorry for not doubling the size of my rant to make you happy. I work with too many system internals to think the JVM is a win. You go back to treating your heap as executable, and over-stressing your CPU translation look-aside buffers, and leave me alone... 8-)
In counterpoint:
I think closures are overrated, but I don't disparage them because I recognize that the fact that just because "they have never been particularly necessary or useful to anything I have done" doesn't mean that they are unnecessary or useless to persons other than I. Plus you can pull the same thing more or less in C and C++, for a limited number of variables, by returning a pointer to a nested function, but like eeew.... Closures do typically require an executable data segment, which I find impure, but all of java requires an executable data segment so who am I to judge. Closures are just the latest brand of secret sauce to allow people to throw memory at a problem instead of logic. 8-)
Lets see...
g() wont compile because "std::vector" inside g(), is not explicitly coupled to the template definition of g() so it could be anything. Add "typename" and then it is unambiguous. Might as well ask why "any car" and "every car" are not the same sentiment in English.
struct s is in no way dependent on class T, so there would be no difference between an s and an s, so the "template " has no meaning or purpose. The fact that you have to remove the syntatic no-op noise is not that complex and every language will fail you for it. Might as well ask why "float char x;" will not compile in Java.
Not all tools are intended for use by people unwilling to learn how to operate them correctly, in fact none are. And all tools and procedures have a "Deep end" unless thy are inherently too shallow to be useful. Not everybody should or will be happy out beyond the breakers just because some people are. That doesn't mean we should put up chain fences to keep people going out there because "the shore-huggers would be made to feel inferior when they see others exceed them".
You can only dumb-down the planet so far before it becomes counter-productive.
[but thanks for reminding me about typename... 8-)]
The JVM is not that much more than the old P-System and P-Code reinvented by people who didn't learn from the past. It is "art" sure, but it isn't "fine art" that has advanced the human condition by any stretch of the imagination. It just had better P.R.
Java is a waste of cpu and, if carefully optimized, it can _almost_ be nearly about as good as the same code written, unoptimized, in C++.
And now Oracle "owns" Java and has announce Jihad on the Infidels, it will only get worse.
Java is now, and has always been, a comfortable fur-and-satin trap for the unwary.
Prepend is a neologism true enough, but it has a clear meaning and a unique definition, said definition being easily accessible to both inquiry and contextual meaning.
Now lets look at "performant", it seems to be an adjective. Adjectives ending in -ant, -ance, or -ent (depending on the preceding consonant) generally mean "meets a minimal requirement". See "conformance" and "compliant" etc. These words also carry a requirement of a secondary reference to an external entity. One must be conformant or compliant with respect to something.
So does the speaker mean to say that the language barely meets some minimum requirement of performance? And if so where is the standard of that performance documented?
I have no problem with the coinage of this usage. It is, incomplete and therefore meaningless. It might as well say "new and improved". It is pure marketing speech designed to manipulate the reader into assigning gravitas to the statement without meeting any of the requirements necessary for clear communication or concise meaning.
So in this case "performant" is pure "word fail" by a want-to-be intellectual.
Slashdot, Wikipedia, and Google are "proper nouns" as such they have a definition based on their usage. Names (e.g. proper nouns) are magical in languages. They define themselves. That is, there is no uncertainty when a new string of letters or phonyms are assigned as the proper name of a unique entity.
As used, "performant" is apparently an adjective. When used without a proper preceding or trailing contextual definition it has no actual meaning. We are left to infer a meaning because of the similarity of the word to other words, but that has no warrant of being the actual meaning intended by the speaker.
Now you can "coin a word" any time you like in English, thats true, but when you do so coin a word you need to provide a proper definition. If I write "Java is gafault" is that "absent of faults" or "chock-full of faults"? The suffix "-ant" and "-ent" ("a" vs "e" depends on the preceding consonant) when used in an ajective context usually caries a "minimum required" leading to the state being described. Being "complaint" does not bring along, for instance, a promise of anything more than minimum acceptability. Look at all the -ant and -ent ajective words, compliant, complacent, etc. none imply excellence.
So did the poster mean "it grudgingly meets minimum required performance parameters" or what?
The problem with this word not being a word is that it doesn't have a common meaning to the audience. Its marketing speech. It sounds like it has gravitas but you can't be held to it having any absolute value. Its like if someone said "100% faster". Is that twice the speed by some measure? Is that "now it is instant"? is it twice its old speed or twice the speed of some external metric. e.g. faster than what and when?
So performant sounds all serious and impressive, but it doesn't _mean_ anything at all (yet).
Why are people so obsessed with plot? Movies should just be sound-bytes, special effects, and explosions, just ask Michel Bey. (however you spell his name.)
Seriously dude, syntax is _everything_ in any language for any purpose. Study up man. What is the first pass the compiler makes? What is the first thing a programmer has to parse when reading someone else's code? If it weren't for syntax this post would could be a sorted list of words and repetition counts, but it would have no meaning.
"kill not I" from Star Trek original series... what does it mean as wrtten? the plea for mercy: "kill I not", or the promise to behave: "I not kill"...?
syntax is _everything_ in every language.
He did share them... stop trying to "solve" the problem of programmers needing to know how to program by writing languages that try to cover for dummies. We have plenty of languages that dummies can use safely. The problem has been solved.
Computer languages are like power tools. They can be "so safe, but no safer" before they start losing function. They just _don't_ make a band saw that any 12 year old can use in complete safety. Same for joiner, circular saw, planer, or just good old knife.
Tools are _not_ supposed to be _safe_. They are only supposed to be "no more dangerous than necessary". We make cheap plastic toy versions of tools for kids to practice with, but eventually they either go away or they have to learn to use the real thing.
I will believe in these "for dummies" versions of language the day a contractor shows up at my house with a Fischer-Price nail gun that will actually hold up sheet rock but is safe enough to hand to my neighbor's 5 year old.
The "clever new idea" is that people don't _deserve_ to operate in fields where they are unwilling or unable to learn the skills required. This is just as true of my profession (programming etc) is it is true that my programming acumen doesn't mean that I should be able to walk into CERN and have a go at the LHC even though I know squat about high-energy physics.
Read the signature line (v v v v v v v v), it is a truism.
I am a guy who loves computer languages. I had a lot of fun with Ada for gawd's sake. I am pursuing erlang at the moment. Thought about haskell but it was just too big to play with...
So keeping that in mind?.... Java and the JVM was a non-starter for me.
Every time a new object oriented language comes out the purists start with "we don't need multiple inheritance" and so on, and they always end up having to hack it back in as some half-conceived junk (see "interfaces" providing, at a later date, all the much shat upon "complexity" of multiple inheritance with none of the ability to provide a default implementation, so then you add delegation which is all the default implementation with none of the inheritance etc...). "Java doesn't have pointers" my pasty white behind, every object is a pointer in java, you just can't use them properly, but they do manage to use pointers to prevent first class object copying, so then they added clone() etc.
Then they "didn't need" proper destructor behavior, we have a finalize that would run at some time in the future, but really the code out to know when the last object reference is going out of scope so it can call a destructor manually if it wants. That was a stopper for me.
See they coded their "every other language should have remained pure" hubris into their virtual machine, they encoded it into their hardware, from inception they designed their system to be limited and resistant to repair. So no thank you. So now Ruby fans want to take their niche language and cram it into the fundamentally flawed Java VM. Ooooohhh sign me up!
I swear the language feels like it was designed on a dirty napkin by someone who had no grasp of scope or symmetry.
Might as well be Python (I am old enough to remember RPG and COBOL Coding Forms, saving one apparent character, e.g. "}", (because in Python ":[newline]" is the same as "{" so what did we save again?) for the privilege of using white space, and counting tabs, as a control structure. And save the "but now we have editors to help us so that doesn't matter" tripe, we had coding forms to "help us" etc. And I suppose its okay to hack off a foot because you can alwasy get a peg-leg to help you too?
Why is it that each new generation of "language designers" insist on reinventing the same old square-wheels of the previous generation and calling it new?
Now get of my damn lawn... (yes, this rant makes me feel old, but come on people, imagine where we would be going if you would just stop trying to reopen the same tapped out mines...)
Thank you for your informative analysis (or at least your ability to go read project web site, which can be quite rare here. 8-)
This whole article _still_ seems like a big steaming pile of "who cares" to me. Ruby lost its slot in the language wars, so they brought us "rails" which lost again. Now they want to lose again by moving their syntax and whatnot into Java and the JVM, which is busily being "monitized" (e.g. sued into niche status) by Oracle after their acquisition of Sun.
Do you honestly think that after taking on Goggle for the non-Java-but-Java-like innards (I forget the name... Davlik?... something like that) of Android they are gonna let cacao or any of the other JVMs slide?
Talk about chasing rainbows into a sewage pumping station...
Have the Ruby people made a run at reviving their "nicer" niche syntax inside "mono" a.k.a. C-pound (=that was the troll I warned you about 8-) yet? If not that is clearly their next stop on this tour of "eh, whatever" they are taking.
There are always leachers, big and small. There are always griefers, big and small. The system works inclusive of the leaching and whatnot.
Progress and cash are not inextricably linked in open source. Not even close.
Measuring things by the outliers is never correct.
So you just soak up the dumb while you soak up the smart.
But if you hide from the extremists of any ilk you give them a chance to sneak up on you.
F5 Networks scratches off the serial numbers of Red Hat enterprise and produces CentOS so that they don't have to license Enterprise from Red Hat. They started this (CentOS) because every one of their Big-IP boxes was running Red Hat and they needed a stripped version to avoid paying the license fees for Red Hat's work. They explained this to me and then gave me the in-house extension to call if I found any Red Hat branding back when I worked there. (Yes, I have first-hand knowledge of these facts.) It's wrong at a moral level, but so what.
Most people who get Red Hat kernels end up applying all the patches anyway. Why is it more efficient or reasonable to release the kernel to all those people as straight-source plus patches, when they all want patched source in the first place. From an efficiency standpoint releasing the patches source is good for everybody but the leaches.
If F5/CentOS was going through the trouble to bundle and test all the packages form the same sources as Red Hat is getting them, then this wouldn't be a issue. It isn't about the sources of the sources, its about the testing and integration that Red Hat does that F5/CentOS has chosen to use with less than a nod.
So F5 is too cheap to pay for Red Hat's work, and they are too cheap to _duplicate_ Red Hat's work, and they are too cheap to build a distribution that _only_ contained what they actually needed, so where _exactly_ is Red Hat wrong for the very human response of saying "blow off, you freeloaders..."?
Besides, I bet if you pay support, or ask nice, you can get the patches anyway. The fact that the default distribution is fully patched instead of making you spend the time to patch it yourself is actually a _win_ for the paying customers.
And all of these actions from both companies are fully GPL compliant.
So where is the "problem" really?
I briefly worked at F5 Networks. They are "the community" behind CentOS. They had an in-house extension to call whenever you found any RedHat Branding in CentOS. The entire "distribution" was created so that they could put Red Hat into their enterprise load balancers without having to do that pesky licensing and fair dealing thing.
I am all for Red Hat doing whatever they want in this respect to CentOS, as CentOS is an unfair deal in the first place (IMHO of course).
Nohting in the GPL requires the source to be delivered as base plus patches. Red Hat was bing a good citizen. Others were being less so. Red Hat decided to play the field provided.
It is a loss to the honest people, but dishonesty is always a loss to the honest people eventually. If CentOS et al were engaged in something more than just scraping the serial numbers off of other people's work, then I would be more upset.
Stealing other peoples earned reputation by re-marking it as your own with little-or-no attribution is bound to invoke human nature against you eventually. It was only a matter of time. I bet Red Hat will _also_ make the patches available to those who ask. That is, just because their default distribution is a pre-patched blob, and lets face it, everyone was applying the whole patch set by default anyway, doesn't mean that the patches are going to be kept in a vault somewhere. Maybe "asking for it" will require a support contract. Maybe it will just require asking. Who knows.
But if Red Hat manages to make F5 pay what they should have paid in the first place instead of spending a like amount on "running a distribution" chop-shop maybe the fair dealing would have never caused this sort of thing in the first place.
(And yes, I have a problem with F5.)
Php showed up as perfect because it is almost perfectly comment free.
This is an indictment of the language, not the programmers, since well-commented php is drastically slower (like .5% tomg!) than stripped down and nearly obfuscated code. That fraction really adds up when you have all those unnecessarily dynamic web pages to generate.
Now if someone were to do a comparison on the ratio of active code, to code that is commented out but not removed because the author doesn't use version control... In that category PHP would freaking rule!