Slashdot Mirror
Your Java Code Is Mostly Fluff, New Research Finds
itwbennett writes In a new paper (PDF), researchers from the University of California, Davis, Southeast University in China, and University College London theorized that, just as with natural languages, some — and probably, most — written code isn't necessary to convey the point of what it does. The code and data used in the study are available for download from Bitbucket. But here's the bottom line: Only about 5% of written Java code captures the core functionality.
Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.
And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.
Anyone who doesn't think Java is verbose is an idiot.
I'll admit I just read the summary article and not the paper itself, but I wouldn't say that this is overly surprising.
Right off the bat due to this preoccupation we Java types seem to have with accessor methods (which I think if we admit, do something besides just set or get a private member variable like 1% of the time, why the hell we still do this I don't know..), and the frequent necessity for hash, clone, and equals methods, most of which is auto-generated, you end up with a bunch of small methods that do very little but up the code count.
Beyond that, I think good design usually works out this way. You (or at least I like to) build up in layers, each layer using the previous layer at a higher level, until you get to the top where you have a few seemingly simple bits of code that pull it all together. When you get big complex functions doing a bunch of stuff vs the described small functions adding little bits of functionality along the way, I think you are doing things wrong.
That's not to say people (and this is common in Java) go way overboard and end up with huge chains of methods that just pass the buck and complex control structures where you need a debugger to figure out whats going on, but if done right it can make for easily maintained and readable code.
This is what happens when you replace talented coders with some H1-B visa shithead that is payed a few shekels a week.
This article uses a lot of words to say absolutely nothing.
I guess it's time we started reducing the amount of comments, in order to rectify this.
BAN ALL COMMENTS! (And white-space)
Java is 95% boilerplate and 5% project-specific. We already know this. This is what Java is. Lots and lots and lots of long strings of stock API objects separated by dots.
In my experience, 80% of my code deals with checking for user error and thing like that (i.e not enter a string where i expect a number, does this socket really exist). This is important functionality, but indeed, it is not 'core'...
If an experiment works, something has gone wrong.
No. This is what happens with a language with an extremely verbose API and extreme boiler-plate requirements. The best Java developer in the universe isn't going to be able to get around this.
Imagine a language with no fluff, no cruft, no boilerplate. Everything is essential and concise. You have something akin to either assembly or too-clever Perl. The fluff is necessary. The fluff provides context, readability, and maintainability.
Hey has this occurred to anyone during a Top Secret Clearance investigation by the government? All this happened to me in the last three years and my life is basically ruined. What happened to me is profiled on the blog address below: https://dictatorialgoverment.w... I've tried contacting as many law firms as possible but none would take my case. Also all Federal Government agencies including the Department of Justice, U.S. Attorney's office, and the FBI declined to take my case. Does anyone know what I can do to notify the public and the world in general what a vicious and horrible government the United States has and officials there could physically hurt someone and commit felonies and get away with it.
But I shoot to make 100% of the code I write fluff.
Democracy Now! - your daily, uncensored, corporate-free
There is a old phrase about code being poetry. Java's the flowery kind rather than that Haiku.
A couple of important points to keep in mind here. First, the MINSET itself is not executable; itâ(TM)s merely the smallest subset of the code which characterizes the core functionality. Some of the other 95% of the code (the chaff) is required to make it run, so itâ(TM)s not useless.
So, we can do a computer transform on it to make it into something a computer can express efficiently, but we ignore the fact that the other 95% of the code is the error checking and other shit which you can't do without.
The whole premise of this "study" has nothing to do with code, how to write it, or what that entails.
I once had a co-worker who kept telling me that lisp or scheme would magically make it so you just wrote a two line program -- something like "getReady; justDoIt".
When I asked him who the hell would write "getReady" and "justDoit", he seemed to think it would be some magic step which sorted itself out. The hard parts don't just magically happen. I can write main() in C which says "getReady(); justdoIt();" -- that doesn't mean that I don't need to implement those parts.
This sounds equally stupid.
Since when have coders started subscribing to wishful thinking where you just wave your hands and the computer does all the hard stuff?
Lost at C:>. Found at C.
Really? Are they just pointing out that source code is meant for human readability, and the actual instructions are more concise? Is anyone surprised by this? Even a quick compression test shows me 80% reduction without even removing the most obviously human-oriented stuff like comments and long variable names.
Can I get some of this research grant money? I've got a theory about sparse matrices mostly containing zeros.
Stop-Prism.org: Opt Out of Surveillance
90% of the time is spent executing 10% of the code. But when something goes wrong you want that other 90% of the code to be there so that you don't l lose 100% of your work :)
Did you know that only about 5% of the average house is actually load bearing? The rest is just fluff. Why are we wasting so much valuable material in houses?
After reading the article, the research looks interesting, but it also based on code written in the Summer Of Code (SOC). So is it the Java that's most of the fluff or the samples? I would venture to say you could basically get the same information out of compressing the code, or equivalently, that the technique is basically a compression technique, and that SOC code compresses better than code written by more 'expert' coders.
If every single program in the universe contains the same boilerplate strings... They are indeed unnecessary. Java is just about the worst for this. Python requires drastically less redundant meaningless fluff.
I'm curious as to why this matters. When I write functions I write lots of other code that doesn't pertain specifically to the objective but is required to provide stable reusable code. E.g. Re-working the data that was input so it can fit within the mold that is the core isn't representative of what the program's objectives BUT is required to achieve the final goal. Same goes for the interface and the validation routines. They don't depict the core function of the software but are critical to the successful use of said core code.
Am I surprised by the 5%? The answer is no. In most of my projects, lots of work goes into presentation and input validation. After all, making machine compatible with people isn't always easy.
but I am a C/C++ guy so I was seen as biased!
Now perhaps the "researchers" can tell us something that isn't totally obvious from a single glance at Java code. Extreme verbosity has always been one of its worst points.
For Java, or any other language, removing a lot of boilerplate code would drastically increase the cost of code maintenance. If there's a linked library I already know which functions it includes and I'm free to pick and choose when modifying the code. Furthermore its inclusion allows commonality between code segments.
Of course spaghetti code is bad and plugging in arbitrary lines without understanding them tends to create spaghetti code. But what would be way worse is reducing every program to its core functionality.
Other extra lines of code serve to make a program easier to maintain. Separating functions where you don't really have to, following some expansionary coding rules, and the like create a little inefficiency to avoid creating a good deal more inefficiency for other reasons. Then there are API's, as someone else mentioned, and comments. Good code should contain a large percentage of nonfunctional lines.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
I learned how to do 90% of the work in a week, but the other 10% you never finishing learning how to do. Of course, that last 10% is the difference between a professional/expert and a rank amateur.
I think this is due to the mental capacity of human beings. If the job is so complex you can't learn how to do most of the work quickly, then we split the job into two or more sub-jobs.
The same guy that plants the food no longer transports it or cooks it. Why? Because those jobs have gotten so complex.
But back to the main point, the simpler stuff may not get the applause, but it is still a large part of the work. Just because someone doesn't think that declaring the variable counts as relevant to the program, it doesn't mean it shouldn't 'count'.
excitingthingstodo.blogspot.com
Until we can read and write in huffman encoding, that's the way programming languages will always be.
It seems like the Java ecosystem is fine tuned for producing a high signal to noise ratio as far as intent of code is concerned. So much of the ecosystem stresses templates, massive IDEs and other automated tools that make the production of thousands of lines of unnecessary boilerplate incredibly easy. Besides, isn't this the nature of Java anyway? It seems like it's designed to produce the most verbose code possible in the hope that if everything is explicit more bugs can be diagnosed since the compiler has more to work with. It's almost a troll article, seriously, it's like the guy is just tryiing to piss people off.
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
Sure, I could throw out a huge amount of the java code I write.
I could use import package.* instead of import package.classname . And for the code I'm writing I could put all of my classes in the same package and eliminate importing any of them.
Next I could also throw out all the logging and error handling.
There's also the ditching of the corner cases, which aren't "core functionality" either.
But that's not exactly useful for anything other than an academic project now is it?
I am sure it depends on a chosen technology, though (partly because technology defines selected group of authors).
This percentage would probably go up to low %20-30s in C++/Objective C and the like and well over %50 in C. Assembly would surely be virtually %100.
I wonder what Perl or Python would get, though (probably would fare only a bit better than Java)
Pure speculation, of course.
A lot of what mathematicians do is reduction. In math, you've got the time to arrive at a formula that's elegant. Software is math; but in software, the next train wreck coming down the tracks usually runs you over before you can think about elegance. It doesn't seem too odd to me that they'd find room for reduction. Either that or they're just noticing that Java has a lot of boilerplate, in which case it's even more of a "duh!" study.
OpenSSL, for instance.
But contrary to python or ruby code, for example, most Java code is not written by hand. No one ever writes import statements for example. Eclipse is so excellent at understanding Java code structure that the writing efficiency is comparable. It brings other benefits too -- I have found re-factoring of large code bases is substantially easier in Java than any other language. This is thanks to the strong structure implied by the language, which can be exploited by tools. In other languages this is prohibited, e.g. Ruby, where every word can mean something different and you can not know until runtime, or C when cluttered with macros.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
This might be slightly off-topic, and if you actually RTFA it's significantly deeper than the headline, but of late (as in, for a couple of years) it seems a lot of software-related research just points out things that when distilled to a few lines are blatantly obvious to anyone in the field.
This week alone, this is the fourth time I've seen a paper mentioned where this was the case, and I don't work or have anything to do with academia. This one isn't quite as bad as the following example, though:
Yesterday I encountered two separate PhD research papers (they were a year old already, though) covering Wi-Fi security that I gave a read front to back. Both of them stated nothing new that anyone working in-depth with Wi-Fi wouldn't know, and the core points of the papers were already clearly documented by others (though not academics...) long before these researchers came around.
I am just a lowly engineer without a PhD and who has never published anything, but the more I encounter these things, the more I feel a lot of the academics in computer science are just prettifying the rather obvious into paper format, without adding anything new, just for the sake of claiming academic prowess. Yes, I have met people who have proclaimed superiority due to their published papers, and when you read those papers you can only go "no shit, sherlock".
People will be people, of course - I also know someone with a PhD in ethics who got through college being paid for getting into other people's email accounts, for example - but I've never had this "academics are bloody useless" feeling with any other field (though I am obviously less versed in those other fields, so maybe I just don't realize it).
This sounds like the same hand-wavy BS that spawned our current infestation of Agile consultants.
They aren't even trying to be scientific here; this is just baldfaced click-bait, likely commissioned by some unproductive company who wants to look like a "thought leader." What are they even defining as "wheat" and "chaff"? Who decides which lines of code are which? Who decides who gets to decide that? What does it even mean to describe what code "does"?
Smart people can disagree about best practices and what constitutes "good" code - ultimately, I think most of it boils down to personal taste rather than any notion of objective correctness or big-picture productivity. Personally, I feel most productive in Java - but that's because of an interlocking mesh of many subtle reasons and has nothing to do with how many bytes my code files take up.
The original paper is here: http://arxiv.org/pdf/1502.0141... What they effectively do is create a set of all the tokens and punctuation in a method and then compress that set to include only those tokens that are "useful". They then compare the length of this set with the original method. I don't see how this is any more useful than compiling the method, looking at its bytes, and stating this method is mostly chaff since it can be reduced into a single 0 and 1, i.e. its BINSET is {0, 1}.
An example threshed set they provide for java bubblesort is: int, length, =, array, ., for, (, 1, 0, , ;, if, ++, ), {, [, j, 1, ., |, ], temp, }. If you're a programmer, you can probably see how silly this is just from looking at that set.
Really it is a culture who have been mining in a pit for so long that they reason that getting to China is the easiest way out. They might be right.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
Even comments about C++ have memory leaks.
Why don't these idiot researchers analyze how much fluff is in assembly code.
Your Java Code Is Mostly Fluff
Nope. Not mine. Coming from C and C++, I know what I'm doing.
Slashdot, fix the reply notifications... You won't get away with it...
The purpose of java is to keep legions of mediocre corporate coders from doing too much damage to each other, and it does pretty good at that. Tediously spelling everything out is one way to try to force some context for code you don't see often. Think COBOL.
http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html
Sample line of code using this:
RootBeanDefinition aspectFactoryDef=new RootBeanDefinition(SimpleBeanFactoryAwareAspectInstanceFactory.class);
Three things:
- First, Java is needlessly wordy - consider the necessity of explicity writing getters/setters for any class where you want access control. What a pile of code for nothing.
- Second, you can write cryptic code or you can write understandable code. Understandable code involves a few more newlines, so what?
- Lastly, depending on your developers, yes, you can have overly long code. Someone who re-implements the same functionality 10 times instead of defining an abstract class and implementing it once - such developers exist. if you have one in your team, I do feel sorry for you. How prevalent is this? No idea...
Of course, TFA wasn't really about any of this. It is about a semantic analysis that determines the number of unique concepts in a method, reducing it to a "minset" which is no longer executable. This is an interesting theoretical analysis, but doesn't have a lot to do with real programs designed to actually perform actions with those concepts. Some methods are wordy because you want them to be clear, others are wordy because of what you are doing, and still others are wordy because of characteristics of the language you are working in.
Enjoy life! This is not a dress rehearsal.
Well, I could have told you this for free. I think in some cases, particularly legacy codebases, 5% is pretty generous too.
Well, no. They're doing none of that.
From a quick skim through the paper, they more or less conclude that java program text compresses really well, since it's full of redundancy, scaffolding, and so on, and so forth. I'd say they need quite a few words to beat around the bush and imagine all sorts of more or less related things, but this is the core of their findings.
This finding is fairly obvious since well-known, certainly compared to certain other languages, but now in some light science sauce made with questionable methodology. That last bit again from skimming.
The piece written around it is equally fluffy and even the things mentioned to "improve" on this mostly involve writing more code, of which we already have a lot containing a large percentage of this "chaff".
The real question is whether or not this scaffolding is a waste of time. One might say obviously yes, yet the market says no:
There's a large market for (mediocre and therefore easily replacable) java programmers, and by extension a lot of money in grinding out this scaffolding, since without java programs are not complete and therefore won't do anything.
Another point: There is also a large market for PHP "programmers" grinding out excreable code in an excreable language, with lots of padding to make up for obvious deficiencies in the fabric of the language -- as in PHP such things are very rarely the result of deliberate design choices, as they not unlikely are in java, instead usually the result of some incompetent code contributor missing a point or other while adding yet another misfit misfeature.
There are other languages around that more easily facilitate much more concise code (such as lisp, mentioned as 'List' in the paper) but those aren't half as popular.
Thus, if there is wisdom in markets and crowds, then this chaff must add some desirable property to the services of (mediocre) programmers. Therefore, the obvious follow-up on noting that this here programming language is rather verbose, the search for expressivity, is not something the market puts a premium on.
IMO these people were having a good time crunching source in some number crunching tool and are mostly in search of more funding. This too is not unusual in that environment. IOW, dime-a-dozen study trotting out a well-known fact for great funding. What else is new in academia?
"all programs can be optimized, and all programs have bugs; therefore all programs can be optimized to one line that doesn't work"
I'm in my right mind and I have the answer to everything!
http://www.somethingofthatilk.com/index.php?id=135
'nuff said.
If I break my core functionality down into simple methods ( less than 50 tokens ), as one is meant to, then their silly method will toss those methods out, so it is ignoring my core functionality and measuring nothing.
FFS.
The first response to this kind of it is 'So what?'. They made up a metric and found that in Java it's 5%. Whoop. They didn't even examine any other languages to see if the metric varies (if they had, perhaps it would be in someway interesting, though I doubt it would be particularly enlightening.)
There's nothing you can do with this information. Total waste of time.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
ALL SHALL SEE ME AND DESPAIR
This is old news folks.
Frederick P. Brooks Jr. wrote an excellent paper (No Silver Bullet: Essence and Accidents of Software Engineering) back in 1987 (link: http://www.cs.nott.ac.uk/~cah/...) that highlights how so much of the complexity that exists in software is *accidental*. This problem is in no way specific to Java, but the language and the supporting eco-system of conventions, libraries and the various supporting "enterprise" tools certainly contribute to the situation. As a language that champions OOP (note: the paper calls out OOP specifically), it makes sense that Java's mainstream-status would lend itself towards being a poster-child for Accidental complexity.
Having worked in the software industry, on various Java code bases, for the past decade: I have observed this curious phenomenon first-hand, repeatedly. It really is quite unfortunate, as it is very possible to write elegant, and concise Java code: one simply has to adopt a more functional programming style and limit mutability within their code. The problem is: most Java developers who appreciate the value of functional programming and immutable design, have already moved on to other languages that have a syntax, standard library and an eco-system that is centered around these principles. I've moved on to Scala largely for this very reason: I grew tired of spending an hour frantically searching through a mountain of convoluted procedural code and XML configs: just to to see why a boolean flag I set was not "seen" by a particular class method.
Which is supremely expressive, but ends up looking like line noise an hour after you write it.
The researchers from UC David et al officially win the No Shit Award!
I'm not sure anyone is surprised. Most people have been saying this for years... even Java "experts"
can we say that 95% Java coders are fluffers?
PKZIP.EXE and PKUNZIP.EXE, together, are about 80 kilobytes.
The current version of WinZip for Mac is 26 megabytes, or 26,000 kilobytes. That's a 32,500% size increase for the same basic functionality.
However, I don't see a lot of people preferring the command-line versions. Why? Because it's easier to drag-and-drop a bunch of files into a dialog box and select an output location and folder, than to type all of that crap into the command line WITH the right flags AND no typos.
Things like menus, options / configuration panes, and nicely formatted help documentation are also preferable to "pkunzip.exe -?", and then remembering that you have to pipe the output to MORE in order to read the six pages of help text spewed out to your terminal window.
UI code is bulky, because it's extraordinarily detail-oriented. Think of all of the operations that your application UI has to support: windows, and resizing, and hotkeys, and scrolling, and drag-and-drop, and accessibility features and visual themes and variable text sizes and multithreaded event loops and asynchronous event handlers and standard file dialogs and child window Z-ordering and printing and saving application configuration info... etc.
If our IDEs didn't include visual UI designers and auto-generate like 99% of that code for us, app development would be horribly stunted AND much more preoccupied with hunting down bugs in UI code.
But all of this UI code is bulky and verbose and nitpicky because the UI is extremely important for any modern app. Thousands of apps exist that feature excellent functionality that is impossible or painful to utilize because the UI sucks.
Computer over. Virus = very yes.
You can probably guess what a *correct* code does from 5% of it. But the other 95% are very much needed for those 5% to actually do that correctly.
These violent delights have violent ends
And in their triump die, like fire and powder
Which, as they kiss, consume
->
Boy meets the wrong girl, they die for love.
->
Boy, girl, dead.
->
people.forEach(die)
I mean, sure it gets the job done, but man, might as well just pay someone in India to write and read it.
your 'article' is as well...
/. doesn't think my title conveys my message clearly.)
(repeated because
A lot of the comments seem to be defending the necessity of the "chaff." That seems to miss the point of the article. The authors aren't criticizing the extra code (much of which IS necessary to make the code functional, readable, and maintainable), they're suggesting that recognizing that only a small subset of the code defines the core functionality can be used in interesting ways. Programmers already take advantage of this in a variety of ways: we have auto-complete in our IDEs, we use web frameworks that write a lot of glue code so we can focus on the problem at hand, and we (sometimes) use newer languages that remove the need for a lot of scaffolding code.
Their application section gives an idea of what they really have in mind: natural language programming for simple tasks, search for common tasks across diverse code bases, and summarizing code functionality using auto-generated "minsets." There are probably a lot of other tasks we could accomplish if we were reliably able to distill a large block of code to its semantic core.
the code written, in the summer of 2012 the researchers downloaded 1,000 of the most popular Java projects from Apache, Eclipse, GitHub, and SourceForge. From that they got 100 million lines of Java code and tossed out simple methods (those with less than 50 tokens).
So they tossed methods that were wrtten well. (methods that only do one thing) So if you wrote a simple 2 line validation of an input field. Field must be populated. Field must match regex. They tossed that as chaff?
in the language that CS professors are oddly convinced will make your code more reliable.
What they miss is that forcing the programer to spend 95 percent of his time jumping through pointless hoops, working around type restrictions making up types and putting down boilerplate makes the code too full of cruft to read, too long to understand, too unwieldy to change.
This is why I prefer to write in Ruby or Lua or Python or Scheme. Scheme may have an unreadable syntax, but it's the most powerful of the bunch and you can implement the most advanced things in the shortest code. It turns out the functionality is more important than syntax... Still its syntax is unacceptably bad. Ruby is unacceptably slow and needs more straighforward metaprogramming but it's the second most powerful in the list.
as java
And then butchered in the article's start for shock value. Often the case.
If you RTFA, it isn't that 95% of code is useless. That other 95% is necessary for compilation.
They are saying that it can be logically reduced to a MINSET which can have uses in the form of enhanced search and productivity.
Although fluffy code was nearly ubiquitous in all code samples examined, the researchers found that the best quality code could be found at http://www.ioccc.org/
They found something that everyone knows. But then again "without the fluff your car doesnt move".
Let us be specific. Within todays car electronics just 2 signals "stacked" give you car the signal to start thats clamp S and clamp 15 (30*). The core function behind both is clear. If both clamps are on, the car is up and running including all electronics. If both are off its practically "off". Here comes the fluff which includes everything between both ON and both OFF. Most engineers refer to it as timed processing of electronics and engine.
The fluff will take care that your electronics starts up and shuts down without problems, it also fluffs your engine so it never overheats and it will take fluffy care of your windows, air conditioning, signal processing/timing and door locks.
Fluff is what turns the world. The 5% core is just the mass sitting in the middle of it.
At least it runs fast on all platforms!
There's a lot of flamebait here. I wonder if it would be as much if the example language was something other then Java?
Why is Snark Required?
That's why I only program in Brainfuck - all wheat, no chaff. There's a 100% correspondence between lexemes and critical functionality.
my, your, his/her/its, our, your, their
I'm, you're, he's/she's/it's, we're, you're, they're
Did anyone else read the abstract (yes, I know the answer's No, this is Slashdot, I must be new here yada yada) and find themselves reminded of Peter Sellers' character in Being There? All that threshing and winnowing made me wonder whether these guys weren't really just a bunch of famer dudes, and someone had fed them some lines....
President "Bobby": Mr. Gardner, do you agree with Ben, or do you think that we can stimulate growth through temporary incentives?
[Long pause]
Chance the Gardener: As long as the roots are not severed, all is well. And all will be well in the garden.
President "Bobby": In the garden.
Typing speed is nearly insignificant in GuB-42's coding.
FTFY.
I've fallen off your lawn, and I can't get up.
Actually, Psychology Today had an article one about the 'primary emotion', and all other emotions were combinations
and varying intensities.... sounds like a quantum-mechanical hilbert space to me...
very mathematical!
I think you can tell how much of a language is "fluff" by looking at the length of "Hello World"
Java is nice, robust, and great for building enterprise applications with a lot of other developers. It is, however, known for being verbose.
My favorite hello world so far:
cat Hello World
After actually reading a lot of the paper, the conclusions of commenting programmers (above) is mostly raw ignorance. It appears some of commenters (I refrain from calling them "readers" because most seem not to have take the time to "read" and "understand") minimally read the introduction (abstract) (if at all) and think or thought they "knew" what the article was about. If one reads the article completely with the goal of understanding it, then one discovers how the goal of the work is to provide a means of doing several interesting tasks (that I'd like to see done in Eiffel and placed into the IDE):
1. Code search: In my universe, is there any code that ________? -- some form of "wheat-keyword(s)" query that can be quickly matched against a database held as metadata about the code universe, resulting in suggestions for where to look for code that does what I need instead of rewriting and re-inventing.
2. Code completion: As I am hand-coding my feature (not just the line or even token I am typing), is there some other feature that looks like what I have already typed, where the remainder of that feature (or some portion of it) can be applied to the one I am typing to "auto-complete" it?
3. Code reduction: Is there a common language subset, such that a reduced keyword language could be hand-coded minimally and then the "fluff" or "chaff" filler be computed rather than typed, essentially making for a smaller and more powerful programming language and paradigm (when linked to #1 and #2 above)?
These are very powerful and interesting questions! They are not implying that Java is 5% meaningful and 95% meaningless. It is simply implying a systematic means of code-reduction in an effort to make tools that do #1, #2, and/or #3 above!
Fine article and good find. Thank you for sharing!!!
Its time for these people, and the ones who voted him an award to go back and retake their Intro to Computers course.
Looks like this joker, and a lot of others missed the entire point of Source code: by his definition source code is fluff because he's stripping out everything that makes it readable, or for that matter compilable.
Congratulations dude, you just discovered what source code is!
You don't need to touch type to be productive as a software dev. I'm in my 50's and can't touch type to save my life, it has not been a problem for the last 25yrs. I have never been asked about it at interviews and I have no problem keeping up with the work. I'm not the only older dev in Oz who can't type, during the 70's boys were often not allowed to learn typing at school since "only girls grow up to be typists". When I went to uni as a mature age student in the late 80's it was simply assumed everyone could touch type. Touch typing was not taught as part of my degree (or any other CS degree I've heard of) for the reason the GP stated - it's an insignificant skill for the purpose of writing code and since I can peck away with 2-4 fingers at ~35wpm it would be a complete waste of my time (and my employer's money) to start learning it now.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
In human language, redundancy is important for separating the signal form the noise. Esperanto, which has less redundancy than organic languages, is harder to understand in a noisy environment.
With programming languages, a lot of the redundancy is for things like meaningful identifier names and type safety. Hey, I've developed compact programming languages before. They're impossible to read and debug.
This is news? A bit more one ups man ship for the script bunnies. I prefer to know at compile/edit time if I have a syntax issue - not after deployment.
There is also a big difference between hand cranked and present but generated.
And this was for Java5 back in the day a decade ago in college.
I am sure it is more complex and huge frameworks like hibernate are popular now. People do not have time to dwell into javadoc when they can prototype stuff fast or use a tool to generate some code for a UML app which does not use the full java apis.
http://saveie6.com/
Groovy
Really, I don't want to write another line of boilerplate Java again. But for those who do, Groovy doesn't stop you.
If you post it, they will read.
After actually reading a lot of the paper, the conclusions of commenting programmers is raw ignorance. It appears some of them read the introduction (abstract) and thought they "knew" what the article was about. If one reads it, one discovers that the goal of the work is to provide a means of doing several interesting tasks (that I'd like to see done in Eiffel and placed into the IDE): 1. Code search: In my universe, is there any code that ________? -- some form of "wheat-keyword" query that can be quickly matched against a database held as metadata about the code universe. 2. Code completion: As I am hand-coding my feature (not just the line or even instruction I am typing), is there some other feature that looks like what I have already typed that the remainder of that feature can be applied to the one I am typing to "auto-complete" it? 3. Code reduction: Is there a language subset, such that a reduced keyword language could be hand-coded and the "fluff" or "chaff" filler be computed rather than typed, essentially making for a smaller and more powerful programming language and paradigm (when linked to #1 and #2 above)? These are very powerful and interesting questions. They are not implying that Java is 5% meaningful and 95% meaningless. It is simply implying a systematic means of code-reduction in an effort to make tools that do #1, #2, and/or #3 above! Fine article and good find. Thank you for sharing!!!
Screw all that crap. Just use Lombok and all of a sudden, your code gets considerably more concise while (the intellegent developer) still knows precicely what's happening behind the scenes.
Bye!
No that was COBOL......
The Truth is a Virus!!!
So it's you Phil Johnson—if that's even your real name—who is the last-sentence-gnome for every story posted at Slashdot for the past several years now.
I see an opportunity here to promote my Hello World! Java enterprise software suite! Features include Singleton, Factory, and Strategy. This library incorporates advanced programming paradigms with modules that can be found in many top tier major player agile dynamic business enterprise organization synergistic application software shops! (Note that this is not the thread-safe version.) I would just paste it below, but apparently Java can't get past the "lameness filter" anymore... figures.
Available also on a coffee mug. Support free software!
At least it lets you type an s without an apostrophe before it.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Any average Desktop-PC: 3% CPU, 97% Fluff
From the article:
Good coding style is to decompose your problem thoroughly, so your methods will be very small. Indeed, using this methodology, the more you refactor the greater proportion of so called 'chaff' you'll get.
I'm not arguing with the general propositions that
But this study doesn't show it, because it arbitrarily tossed away the better-written code and then analysed the remainder.
I'm old enough to remember when discussions on Slashdot were well informed.
Programs in OO languages, in my experience, seem to be mostly fluff. The goal seems to be to make sure to use the OO paradigm, whether or not it is well suited to the problem at hand.
Java, .net and windows are mainly means to make your shinny 4GB core i7 seem slow.
If Oracle cared at all about safety, Java wouldn't have so much security updates every month. It's riddled with bugs, cause they never cared about making it secure. If they did, they wouldn't stuff it with so much bloat its pretty much impossible to inspect all of it for bugs in the first place.
The difference between Java a good languages like Python or Ruby is huge. These guys have finally hit the nail on the head. Java is a huge fat fluffy monster that wastes a massive amount of code.
Sure, all languages have a fair amount of redundancy. But who do you write the code for? Hint: its not for the compiler. Its for the poor schlub who has to "maintain" or "enhance" the code in the future. You want to make sure they know what the code does.
COBOL was successful for 50+ years because the code had value after decades.
Am I missing something? isn't all code 99% fluff before compiling?
I write an application, be it in Java, C++, whatever. Insert Object-Oriented language of choice here.
.JAR files, frequently megabytes in size and that's WITH compression) which I can use. I may use a few classes from that library. And those classes may use a few more. But I can't extract the classes I need and create a new library. I have to bundle their ENTIRE library, with all of the associated classes, regardless of how many/few I actively use. And this library has dependencies in those libraries. And that library has dependencies in those libraries.
.bar() method.
I need to do I/O. So I use an existing class. Which is, more often than not, bundled into a large library of classes. And the classes in this library depend on classes in that other library. So I need my new class, and the classes it uses and the classes they use, all the way down.
If I'm writing an app which uses data persisted to/queried from a SQL database, there are libraries (for Java, usually
By the time you write something for a website which will use Hibernate to handle the ORM duties, Spring framework to handle the web duties, etc. you end up with an application that's > 10 MB in size. The code which I, actively, wrote is
Furthermore, if I choose to extend that other class, I may create a method which overrides a method in that class, and my method may not use theirs at all. As such, I still have to include their class, and its associated library, IN ITS ENTIRETY, but parts of it not only aren't being used but aren't even REACHABLE. Because calling foo.bar(), where foo is an object of my class, can't even reach the extended class's
Object Oriented programs are built in layers, by accretion. As the number of layers increases, the amount of unused and unreachable code grows. Until, voila! we're down to 5% of the code in the app actually getting used, even if you exercise ALL of the functionality in the app.
Java is merely one of the worse offenders in this. When you have a stacktrace with 30 layers in it, that's a LOT of code. A significant fraction of which is NOT getting used by your app.
... by the Dew of Mountains the thoughts acquire speed, the hands acquire shakes, the shakes become a warning
Java is an extremely bloated language requiring a ton of boilerplate that exists for no other reason than to please the almighty compiler.
Java was written by top programmers for use by average programmers. Hence, all the needless boilerplate.
It isn't just the accessor/mutators, that is small potatoes. It is all the:
Casting
Interfaces(Gosling himself said this was an error)
Factories
Runtime exceptions(yes, this causes a ton of boiler plate to deal with things like interfaces that do not throw any exception).
The need for a dozen sort() methods(sane languages can get by with exactly one sort method and it works on all iterable types) which is caused by:
A broken type system(it is allegedly strongly typed but is filled with casts and autoboxing, making it weakly typed - compare to Ruby where an object will only ever be one type and can never be coerced, that is strongly typed) that is the cause of all that nasty XML and annotations just to get around the broken type system. An H-M type system would do so much by itself to rid Java of needless boilerplate.
Properly implemented OO systems like Smalltalk and Ruby have very little need for most design patterns, in fact they disappear entirely making them redundant.