Slashdot Mirror
The Reason For Java's Staying Power: It's Easy To Read
jfruh writes: Java made its public debut twenty years ago today, and despite a sometimes bumpy history that features its parent company being absorbed by Oracle, it's still widely used. Mark Reinhold, chief architect for the Oracle's Java platform group, offers one explanation for its continuing popularity: it's easy for humans to understand it at a glance. "It is pretty easy to read Java code and figure out what it means. There aren't a lot of obscure gotchas in the language ... Most of the cost of maintaining any body of code over time is in maintenance, not in initial creation."
Solving problems can be done quite quickly with Java as a lot of the frameworks/tooling for solving common problems have already been built. Including:
- Distributed Configuration
- MapReduce
- Spark
- Large portion of the NS math libraries have been ported (think of all the Fortran libraries)
- Networking
- Embedded devices
- First-class support for many app hosts
- Concurrency libraries (including standard)
- World-class web application serving (Jersey, DropWizard, etc.)
These are things that are proven and enterprise ready with large communities supporting them.
I am tired of hearing languages are "easy to read". If a piece of code is well written and identifiers are well named anyone who is accustomed to the syntax or syntax that is SIMILAR will be able to read it. The point is that C style syntax have been what the majority of programmers have been used to so it has become a staple. However, if it was down to pure logic and an understanding of the English language Ada, Pascal, and (Visual) Basic would be the most readable.. and who here thinks that -- we've all been brainwashed by CS101.
Not as easy to read as Python though
And that's a good thing.
Yes, while verbose, i find Java easy to read - and i think its verbosity helps in this (after a while you know what/how to read Java code, and your reading becomes "smooth").
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
The popularity of Java is not because of it's "easy to read" nature, but because it is fairly forgiving for programmers that don't really know what they are really doing.
I programmed in Java for 15+ years and it is not the best language now (more of a legacy language) that tends to get riddled with boilerplate code which requires code generation and produces an outcome that is not as clear and concise as it could be.
It is however a forgiving language where if you don't understand memory management -- it is not a big problem. For example I remember a system written by programmers in another language that was riddled with memory leaks because of cylindrical references. The code was literally translated into java and all the problems disappeared. The programmers on that project just figured that the language that they programmed in was the problem -- but in reality java saved them from their inability to understand the basics of what they were doing.
Maybe it's improved with the new versions of C++, but I coded in C++ for many years before transitioning to iOS development, and I never wrote my own templated classes, mainly because I would never be able to understand what any kind of semi-complicated template would do. So, I just used STL and Boost, and only with the templates I was comfortable with.
A huge standard library that has been stable for 20 years (backward compatible as much as humanly possible) has a lot to do with it as well.
In other languages, I feel like I have to re-learn basic elements every decade to "how it's done now"...
Really? Having a pile of needless verbosity makes it more difficult to read in the long run simply because one needs to figure out what exactly is being done even for the most trivial client application. To do even just simple fetch of some resource over HTTP requires rather laborious conversion routine from a stream to a string type before most common JSON libraries would be able to use it. In any more modern language it can simply be used right away rather than having to figure out which JSON libraries to use or why toString() doesn't seem to work on InputStream (I mean intuitively shouldn't toString() on a stream get back a string?).
Granted the Apache commons can make this a bit easier, I find it extremely annoying to have to cast things into the right object type just to access some simple JSON object, instead of just doing something like result['collections']['links'][0] which is much easier to understand. Dumbing things down does not necessary make better programmers.
Please direct all bug reports to
It's time to round up the Muslims (Score:0)
by Anonymous Coward on Thursday May 21, 2015 @08:23AM (#49742663)
you know what I mean.
You can try. But we are growing in number every day while you Christians are decreasing in numbers and growing softer and softer in your decadent lifestyle. In two or three generations we will control Europe and in another generation we will control the United States. Then we will have true submission of the world as the Prophet Muhammad spoke of over 1,000 years ago. The funny part is we can speak of our plans boldly, but Allah has our future in his hands and you cannot do anything about it.
Java's readability is part of its staying power, which is part of the reason that Java is able to overcome its severe age and lack of features. As a software developer, I spend 90% of my time reading other peoples' code and 10% of the time writing my own. I also need to read code that I read over 6 months go, which I largely won't remember writing.
This is a major part of the reason why languages such as Scala haven't taken off. Scala, Perl, and other similar languages are largely "write-only" in my opinion. Newer languages must be designed primarily for readability.
Just like IE 6 it is so engrained into our business processes that it won't ever leave. At least here in the office which greatly angers web developers greatly, but operations doesn't care.
Java is around for no technical reasons. It is here because it is already here. Why change for the sake of change and .NET wasn't worth the effort in 2005 as IIS was a steamy piece of poo back then. So now no one wants to take the risk and $$$$ for something that already works. Yes we stayed on XP too until 2014 but my employer is not alone.
My post melts the brains on hipsters lucky enough to be working at .COMs in SV or still in school tinkering. Your souls havent been left yet for the real world yet
http://saveie6.com/
More likely its the nearest thing to C++ that is platform independent.
I use to program in C++, but after switching from Windows to Android, I also switched from C++ to Java, and the transition wasn't such a big deal.
A lot of the libraries I use on C++, are there on Java. A vector is a vector, a float a float, etc. It's not that much of an issue.
The alternative for me was to switch to C# and Winforms or similar, and I decided that I didn't want to end up churning out B grade corporate apps, which is really what that is about.
That's what I thought.
It was purely serendipity, and now the install base is so large you can;t get rid of it.
I am very small, utmostly microscopic.
I could sure do without the { }.
> But we are growing in number every day
Nothing a few nukes couldn't fix.
But you'd think the fact that it works the same on a Mac, Linux, Android or Windows would have something to do with its popularity as well, no?
Almost all programming languages are easy to read. This is not the reason of Java's success at all. A complicate algorithm in first place will not make a program easy to read whatever the language you pick to program it. If you find Java easy to read, it is only because you cope with trivial algorithms.
Achille Talon
Hop!
final T up = (T) throwable;
throw up;
I'll see your senator, and I'll raise you two judges.
Dafuq did I just read?
Since when is java easy to read?
Since 20 years ago.
Can't you read?
Sorry, the wire services missed the instructions.
Most of the cost of maintaining any body of code over time is in maintenance, not in initial creation
That's like saying "most of the cost of the grocery bill is made up by the most expensive item". I couldn't come up with a car analogy this early in the morning.
I am sorry but can I just say:
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in));
input = bufferedReader.readLine();
number = Integer.parseInt(input);
In Pascal (1960's) you could just do something like:
integer number;
read(number);
See if the compiler knows number is an integer do I really have to tell it to create a stream and parse it as an int? seriously?
Java is an abomination.
Well if there's one thing programmers hate more than unreadable code, it's typing shit, and COBOL was an awful lot of typing shit. And for some reason, even though the individual lines were easy enough to read, something about the language made it very difficult to follow overall. Since the language was so overly verbose, functions usually ended up being pretty long, and it was very easy to get lost in them, in any COBOL code I was exposed to anyway. I'm sure there was probably some clean, well written COBOL code in the industry, but I never got a look at it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Libraries tools and 3rd party support in the form of books, articles developer know how, WORA, etc. It's very very fast no matter what people around in the 90s may still think, it has an unbelievable number of extremely high quality, battle proven open source libraries for highly specialized and useful functions and of course the tools supporting it like IDEs are out this world good. So I can do anything I want, I can run in most anywhere, I have vast libraries at my disposal and best in class documentation from multiple independent sources.
Pretty much sums it up.
I use other languages, sure, but I get sick when I see people (evangelists, consultants) ushing some new "better" language because frankly they have positioned to make a ton of money off it shuld demand for it sky rocket. It's software engineering's own secret sin- people reinvent a non-broken wheel in order to profit. It happens all the time. There's gold in them thar hills if you can just "create a buzz" and reach enough developers by co-opting enough "thought leaders" to create a "tipping point" in demand for your new "break-through language / platform / way of programming".
James Gosling recently said it best when he said that new important innovations aren't going to come from inventing new computer anguages, they're going to come from the world IoT and how create devs use languages.
Yes, I am posting the AC for a reason. Let the onslaught begin...
Java is no easier to read than C++, Objective-C, et al. It depends upon how the code is written, and I have read Java code that is as obtuse and ridiculous as any C++ code I have encountered in my 35 year career as a software engineer. FWIW, I got my first Java compiler directly from James Goslin in the mid-1990's, the inventor of the language. His intention wasn't "readability", but portability - the ability to "write once, run anywhere". Guess what? The UCSD-P system did this 2 decades before!
But a more convoluted, heavy weight Scheme? If we adopted Lisp 20 years ago the world would be a better place.
Most of the cost of maintaining any body of code over time is in maintenance ...
It little behooves the best of us to comment on the rest of us.
"the cost of maintaining any body of code over time is in maintenance"
No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.
Anyway, the intention was probably to say that maintaining is more costly than creating. However, since it says "any body of code" I'll just call it the deepest bullcrap. I've seen and heard lots of people talking out of their behinds over the years dismissing the effort going into creating some really nice algorithms and realizing them in applicable and useful code, simply thinking about the whole process as "coding" which is usually the easiest part. Also, maintenance costs a lot mostly when the coder monkeys hacking the code together were crap in the first place. Just stop paying outrageous amounts of money to idiots who put together unmaintainable code and then leave to another company to do this again and again, and by the time their code needs "maintenance" they're already gone and couldn't care less.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
If your going to put in that hack, you might as well just include lombok into your annotation processing and just put @SneakyThrows everywhere. If only Java had gone with real generics like c#, we wouldn't have had all these erasure hacks.
Serendipity could also mean that it was in the right place, at the right time, and that is why the base of code written in Java become so huge. It solved a problem. And did so better than other solutions at the time. And arguably, still does.
Other solutions may look sexy. And for smaller projects, they probably are.
But long term maintainability is important. Does your project still need to work in ten years? Twenty?
Having a compiler is also probably a major factor to Java success. If I make a typo in my code that breaks something, red flags start appearing on files in the source code tree all over the project for files that no longer will be able to compile. Lots of things that dynamic languages don't discover until runtime (or hopefully unit testing) are immediately discovered by the compiler. In a sense, the compiler is the zeroth step of unit testing before you even run the unit tests. The compiler effectively provides the first most basic set of 'tests' on the codebase.
People who don't understand why Java sticks around also don't comprehend the sheer size of some Java code bases. I would like to see what would happen if a dynamic language were used to write a system that had hundreds of different forms or over a thousand; and maybe thousands of different reports it could produce.
I'm not saying there is anything wrong with other languages. Just that Java does have a place. It is a solution to a real problem.
If there were one perfect programming language, then everyone would already be using it.
I'll see your senator, and I'll raise you two judges.
Yes -- You have to be clever about being clever.
I just had a quick look at it and it looks like C to me. Really ugly.
Why do this:
public class HelloWorld
{
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
When you can do this:
Print "Hello World"
What's with all the horrible curly brackets everywhere? What's wrong with endif, next, etc? Bring back BASIC, it what I say!
If I want to write something for myself to use I use Blitz Basic.
At work I've use COBOL quite a bit, and that's nice to read. Full stops are okay. Not as hideous as curly brackets.
I am really sorry to hear about your working conditions, but with todays possibilities as a programmer, why do you even put up with that shit? You are supposed to have a boss to take those battles for you. Where I live they would have no people left if they stuck to their ways like that. Training new employees is expensive, and that is a language your accountists understand. Three months after finishing uni and getting my first job, recruiters started calling me (ooh, experience!). Maybe you are stuck in the only place in rural Kansas that employs programmers, but we leave in a global economy with remote working possibilities, so no excuses.
It is, just as long what you are doing is similar to what everyone else is doing. Sometimes, you may need to break the mold. But that is actually very rare. And you need decades of experience to really know when you really should break the mold.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Minecraft requires it
Like most people I thought pythons enforced white space and avoidance of braces and elimination of semicolons was constricting. Then I realized how easy it was to read other people programs. Python used to be even simpler to read when it only provided one idioms for one job (avoiding a dozen way to do the same thing resulting in dialects). Now it's adding new idioms and genres so it's a little more opaque. But it's still easier to read than any language with comparable expressiveness. (Lua is refreshing for similar reasons).
Some drink at the fountain of knowledge. Others just gargle.
You guys can squirm all you want but he's right. Readability is far from being a Java selling point. Of the several languages I've had the [dis]pleasure of using, and the tens of thousands of lines of code I had to review, Java was, by far, the hardest to read.
It might be strange for today's standards for computer languages, but one of the main COBOL goals was exactly to be readable even for laymen (maybe the military who sponsored its development feared spy programmers).
from wikipedia:
"COBOL has an English-like syntax, which was designed to be self-documenting and highly readable"
serendipity
serndipd/
noun
the occurrence and development of events by chance in a happy or beneficial way.
I am very small, utmostly microscopic.
since people that have only seen java in their lives try to go to other languages rambo-style overconfident in their abilities as programmers.
Ah yes, the old COBOL justification. It was BS then and it is BS now when applied to Java. The hacks at Oracle would have been better off sticking to "write once, run anywhere."
You do not know what you are talking about.
Java has not stagnated. It is one of the top programming languages. You would know this if you had looked at the article. You might not like Java, and that is fine. But at least get your facts right.
Write once run anywhere is also true for large projects. You could move a major web server project between OSes without even recompiling it. I have personally moved installed my employer's web application on a different OS than it is officially deployed on just for amusement. Because it could be done. I also tried it on a Raspberry Pi (prior to the 2) and it 'ran' (in the sense of how a snail can 'run'). But it actually worked and connected to a database server running on a big box running a different OS.
GC on Android is not a problem. Billions of devices are in daily use. What kind of 'problem' are you talking about? Something hypothetical?
Java at Google may be a fork, but it can't be any worse the the multiple dialects of other languages and compilers like C / C++ or Python 2 / 3 and other examples.
Java is not perfect for every problem. If there were a perfect programming language, everyone would already be using it. But at least get your facts right. Java is going to be around for a very long time. The language has just gotten some major new features in the last couple releases. More major improvements are on the horizon. The sheer size of Java codebases alone is proof enough that it will be around for a long time.
I'll see your senator, and I'll raise you two judges.
I'd agree with the ecosystem being a huge factor in Java's success.
More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.
I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yes, Java is pretty easy to read. It contains all the standard control structures, and not a lot more. Aside from inheritance (which, by now, pretty much all developers understand), there isn't a lot of hidden functionality: See the code, understand what it does.
This is one reason that I object to the introduction of Lambda's in Java 8. Lambdas belong in functional languages, where they make sense in the context of the language. Java is not functional, so lambdas break the paradigm. Moreover, they are unfamiliar to most developers, and they are cryptic in a way that hides functionality.
Enjoy life! This is not a dress rehearsal.
Maybe, but the Angry atheists are Pissed Off.
They lose their shit when someone says God Bless You. Imagine what they'll do when you come along and try to make them get on their knees to worship a child molester.
>Maybe you are stuck in the only place in rural Kansas that employs programmers
Maybe it's because he says stupid things like this at interviews:
>Java is around for no technical reasons. It is here because it is already here.
>change for the sake of change
>.NET wasn't worth the effort in 2005 as IIS was a steamy piece of poo back then.
> So now no one wants to take the risk and $$$$ for something that already works.
My post melts the brains on hipsters lucky enough to be working at .COMs in SV or still in school tinkering. Your souls havent been left yet for the real world yet
...says its maintainer. Story at 11. This is bollox.
obligatory webcomic to explain difference between hand holding (implicit) and hand forcing(explicit)
This is an article about why Java has decent staying power, not about why it is the perfect language, nor most readable language possible. The article does not say people will be using Java in 1,0000 years. But Java became popular and continues to have strong staying power for an old language. There are reasons for that, even if it isn't your cup of tea.
Democracy Now! - your daily, uncensored, corporate-free
Granted the Apache commons can make this a bit easier,
Apache software is great, until they go from v1 .to v2 where they completely break compatibility and increase the complexity by an order of magnitude.
Axis 1 to Axis 2 for example. Then there's Log4j 1 to 2.
An speaking of Log4j. from Apache there's: Log4j, Commons Logging, and JULI.
All from Apache.
Then there's Apache CXF which is much more complex than both X-Fire and Axis 2, which it replaced.
I am just happy they didn't get their claws on Hibernate and Spring--they would screw them up by over-complicating and breaking backward compatibility to make them nearly unusable.
Java was the first language on the scene that came with a top-to-bottom marketing rollout. They had certification, training, professional tutorials and classes, sponsored competitions, commercials and corporate branding, full page ads in trade magazines, and a one-size-fits-all modular system of components to mix and match and fit every need, and you could even become certified as a java evangelist - that used to be a real job at some corporations.
Once they got solid buy-in, well, companies are loathe to change unless there's either a pain point or a generational technology gap, and sometimes not even for the latter (see batch processing mainframes running cobol and RPG programs).
So that's what it is. If anything, as the language matures many people actually want to get away from readability; they want annotations and dependency injections controlled by some non-centralized mechanism, such that you must either rely on everyone else who worked on the product getting things 'right' and just magically working without your understanding of other processes (a theoretical goal of good OO development), or more often, you must understand all the code running at all times. Try doing a manual analysis of a good sized project that relies heavily on Spring, or worse, an OSGi project.
Projects using those features are not self-documenting code. Tracing execution or data flow is extremely difficult. All I can say is at least it's not Ruby, Objective C, or Smalltalk.
So, no, it's not readability. There's a good subset of programmers who are strongly against readability. It's money, plain and simple. It's a corporate investment, and that's all there really is to it.
What makes "Java" or anything object oriented difficult to read is that objects tend to produce more spaghetti code and have a ton of easily overlooked side effects. Debugging can be a nightmare. I see more "pitch till you win" code maintainers.... so much so, that some consider it normal to just keep trying stuff until it "works". I'm not saying you can't create "good" object oriented code.... I just haven't seen any yet.
It's difficult to be "clever" in Java
To the contrary, Java's lack of expressiveness resulted in people writing tons of external XML files, code generators, DI frameworks, and build tools to glue the whole mess together. Instead of small, judicious bits of cleverness in the main language/runtime, it's been pushed to very clever tools on the periphery that come with relatively large learning curves. That's not really a win from the readability standpoint.
-1, Too Many Layers Of Abstraction
Honestly,I have seen many, and this one about been readable must be the more strange argument I have seen lately.
It is pretty easy to read Java code and figure out what it means.
Many who deal with the "enterprise" software would simply laugh at the statement.
But hey, the same argument was often made about the BASIC. And I always said that Java and BASIC users are very similar.
All hope abandon ye who enter here.
I was about to post, I had to debug COBOL and FORTRAN as part of a previous consulting stint and COBOL you can AT LEAST guess what's going on just by reading it (without a binder full of docs)
By today's standards COBOL is wordy and nonsensical, like comparing Elizabethan prose to a text message, but you can still READ it
It is not difficult to be "clever" at all. Look at various "bean" frameworks. Use their object marshaling features. Throw in some of their aspect-oriented programming features.
Now you usually have a bloated, incomprehensible mess. Sure you can easily read any couple of lines of code in isolation. But the system as a whole is a huge pile of gratuitous redundant layers of abstraction and confusing action-at-a-distance creepiness.
This isn't news, this is clickbait.
Nothing to see here, move along...
I like C# for the same reasons, or mostly the same. Easy to write, easy to read, powerful, flexible, enough performance, easy to debug, easy to write strict code that makes it hard to use incorrectly.
True, we tried to build in obsolescence with two digit dates to force the banks to upgrade by 2000, and they rather liked forcing COBOL programmers back in at a premium to fix the issue. Even the screams of a coming apocalypse couldn't get rid of it.
The last two major releases (7 and 8) have been awful. I think the only reason why Java still gets so much attention is because there's a lot of time and money already invested on Java applications. As a Java developer and FOSS advocate myself, I have to confess that I'm closely following the results of Microsoft flirting with the open source community. I never thought I would say such thing, though.
Open Source Network Inventory for the masses! Kuwaiba
Nowadays to be part of a Java project you have to speak not only Java, but all the vertical and horizontal layers that are the frameworks. Spring, Struts, Hibernate, Spark, Tapestry ..........
Slashdot, fix the reply notifications... You won't get away with it...
What amuses me is that many people rave on about how great C# is, while denouncing Java. Yet other than a few minor syntax tweaks (like the way you write getters/setters and the "?" indicator for nullable attributes), they are virtually identical right down to the API.
They're both very easy to read and code with, and if you know the packages/libraries of one you'll find the equivalent in the other in short order, with very, very few differences in the details of the APIs.
Yet C# is "great" and Java "sucks".
Go figure.
I do not fail; I succeed at finding out what does not work.
Cobol still runt lots om the worlds it systems. Cobol is readable for anyone with basic English understanding and yet powerful enough for anything.
I worked at a competitor to Sun many years ago. Even though we said a lot of bad things about Sun at the time, it's now quite clear to me that Sun was a great company which was not only so much better than Oracle in my opinion, but was also probably better than the company I worked, in terms of open source, technological excellence, etc. It seems that Sun was too nice of a company and nice guys finish last.
I've watched experienced and skillful Java programmers struggle for days "wiring up the beans" and then spending the rest of the project trying to get it to work.
Any one line of Java is readable, but when you pile libraries on top of jars on top of frameworks it degrades into a mess. And lets not talk about Exceptions.
Well if there's one thing programmers hate more than unreadable code, it's typing shit, and COBOL was an awful lot of typing shit. And for some reason, even though the individual lines were easy enough to read, something about the language made it very difficult to follow overall. Since the language was so overly verbose, functions usually ended up being pretty long, and it was very easy to get lost in them, in any COBOL code I was exposed to anyway. I'm sure there was probably some clean, well written COBOL code in the industry, but I never got a look at it.
Funnily enough, that's the exact same thing I and a lot of other people have to say about Java.
Yeah... it's a pretty genius tautology.
In related news, the major cost of creating new software is in the creation, and the major cost in deploying new software is in deployment.
Python's no fun to work in at all. But it's the right choice for business coding for precisely this reason.
Boring is good. Rigid is good. The next person who works on your code is not going to understand anything you did. He/she will need to pore over your code and figure it out. The easier you make that, the more you can accomplish and walk away from -- leaving a trail of success in your path. Otherwise, you're either bound to the code and swamped with old projects, or trivial issues you missed never get fixed, leaving a trail of unhappy clients/users behind you.
You can look very busy having to deal with all the overhead and boilerplate to get trivial stuff done in Java. Programmers will feel needed and busy, while the superiors can avoid being bombarded by tasks, because everything takes ages.
Another good reason is that non-programmers have very weird metrics for productivity. I remember studies being linked here on /. that measured a programmers productivity by the amount of lines comitted to github projects. This of course makes Java an inherently more productive language than languages where you can simply get shit done.
Java lacks high-level control structures written in simple, understandable ways. This means that java programs are longer than they need to be. YES, you can look at three lines of java code and know just what they do. CONGRATULATIONS. But when the java program is 300+ lines long and only needed to be 30 in R, for example, which one will a person with any competence in a language understand faster?
C# (an MS trap language you shouldn't use) is better than java. It has better syntax and makes things cleaner and shorter.
Java is getting praise here because of its success. If it were put out today, it would be ignored. The fact that we would not have the VM-based code world we have without java is immaterial to an evaluation of the language. We should not lie to ourselves. Java programs are too long. This makes them hard to read and hard to pass on to other programmers. Period.
Actually, it's easy to read because it is verbose and inexpressive as you put it. Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand. There are also relatively few syntactic constructions to get your head around and tokens are not usually overloaded with different meanings. It doesn't take long to learn the whole language, which means that even a newbie has a good chance of reading a piece of code without coming across something they haven't seen before.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I guess we're not talking about working with Java Struts. When you do, turn on mysql logging, and then tail -f mysqld.log, you'll see garbage like this: select column_623 from table_943 where column_142='xxx'; ---- is that readable to you? Is that supposed to improve readability by abstracting so far away from the database that no one can understand what is going. I basically have to grep for values inserted or updated or selected from tables in order to figure out what table stuff is being written to. It's not ugly, its an abomination. Who ever thought up the idea doesnt know what they are doing. Easy to read..... YEAH RIGHT -- its a joke. It takes 5 times longer to reverse engineer this spaghetti mess than any other languages. Straight Java code is easy to read, if you don't intrude abstraction layers on top of the language, like Struts.
Won't be needed. They all own 14 inch dishes.
Their children watch MTV middle east and will behave in ways so gay that they would make emo kids blush. Two generations and it's all over. Right about the same time their oil money will end.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I wonder if with Java 8 and the ability to do lambdas and more complex functional programming techniques will hurt Java in the long run. I do Java as my day job, and have only recently finally been able to do Java 8 at work in the past few months. I am a big proponent of functional programming practices, and we do a lot of Javascript front end.
Pre-Java 8 I was always concerned that the language would decay since it is syntatically decades old, and become the COBOL for the new millenium. I know I can jump into whatever the flavor of the month is, but I have always been happy doing this. Of course, flavor of them month became flavor of the year, then flavor of the decade... and now I have been doing Java for over 15 years. It sill might become the next COBOL, but it is flexible enough that you can do pretty much any business programming you ever need, while being interesting enough to bring in new programmers out of school.
But my work has a small number of highly experienced developers. If I was still working at a big soulless corporation with dozens of bottom tier developers mixed in with the seasoned pros, I wonder if this would result in the code being unreadable? I have seen some terrible code in java 4 and 5, I can only imagine the horrors an idiot could wreak with lambdas. Granted, I am sure most of them are still doing java 6 compatible code, since only small companies can afford to change momentum and upgrade.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Totally agree. The expressive languages that let you do a lot with relatively few lines often count on implicit behaviours that are not at all obvious unless you are familiar with them. It's a drag on coming into someone else's codebase and understanding what's going on. "Oh, I see, you're counting on this to fail in *this* certain way such that *that* happens."
It's.not.even.easy.for.humans.to.find.both.ends.of.the.class.names.frequently.found.in.most.java.programs();
I did a very large COBOL port a few years ago, and I must say it was very well written. We were increddibly lucky that the developers were maintaining the project for decades and wrote their code very consistently (though they significantly lacked in comments) and were quite comfortable with helping learn the in-s and outs of the system. The actual business logic of the product was factors more difficult to grasp than any simple technical issues with COBOL itself.
Much in the same veign as C, COBOL's whole memory model is like a big block of crap, being able to remap memory blocks willy nilly over existing ones, sending memory blocks across programs, etc.. makes tracing memory much more difficult unless you had some sort good static analysis tools for tracing (which we didn't). The processing code was straight forward but obviously very simple, which meant that there was a lot of boiler plate (but completely drop dead simple since the same code was used consistently throughout the project).
Bye!
You're mixing verbosity with understandability. Yeap, of course repeat the type of the object twice, the ugly diamond operators, use else if instead of elif, etc, produces verbosity, but this is not related to be easy or not to understand.
COBOL was relatively readable when it was invented, compared to the other languages of the time. The purpose was to be so readable that even managers could understand it
Well written COBOL is understandable. The biggest complaint is that it's overly verbose (other problems like "no re-entrant functions" aren't problems anymore). In many ways Java seems like a modern version of COBOL.
"First they came for the slanderers and i said nothing."
having read both java and cobol here's what killed cobol:
1) global namespace. All fields are the equivalent of static java fields.
2) periods as end of statements, but not strictly enforced. Imagine if you could write Java and skip the semicolon if the next word is a java identifier.
if(a=b) { if(c=d) {d=a;} else {d=b;} else {c=b;}}
becomes
if a=b if c=d then d=a. else d=b. else c=b.
or
if a=b if c=d then d=a else d=b else c=b.
both mean the same thing but good luck trying to figure out what this does:
if a=b if c=d then d=a. else d=b else c=b.
3) string serialization. It is extremely verbose to write an XML parser in cobol, or regular expression parser, due to the recursive nature of XML, and the global namespace.
For crying out loud... Java is no clearer than C, C++ and a whole host of languages which share the same general syntax. What makes code readable is how the author writes it. Just go look at some obfuscated Perl contest winners.... There are some languages which I think are NOT readable by design, like FORTRAN, JCL, most shell scripts and sometimes python, but all the derivatives of C (C++, C#, Java, Perl, and such) are all about the same. But it depends on the author, not the compiler's choice of tokens... How do you write clear code?
Tips for clear code no matter what language it is in:
1. Use Identifiers which are PLAIN language... Skip type encoding in variable names and choose class that are nouns and method names which are verbs that make sense for what they do or are.
2. Indentation - Always indent at logical edges, I don't care if you indent your braces, put them on the proceeding line, use 3 or 5 spaces, tabs or what, but ALWAYS indent.
3. Comments - Method headers, Class headers should be required, Anything other than just setting a class variable is likely going to need a comment too. Anytime the loop/if logical test may be hard to find, reference it in an easy to understand comment for the end of the loop, the Else etc. Any time you have to think hard about what the code does when you are first writing it, chance are it needs comments to explain it.
4. Use "this" - When you access a class variable, use "this"
5. Be consistent - What ever you do, be consistent in your formatting. Operator overloading should only be done with caution.. If you end up writing something like "cat + dog" by overloading "+" you get what you deserve....
There are more rules for readability out there, but IMHO it is the programmer that makes source readable, not the language being used by the compiler.
Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand.
By that argument, doesn't any powerful abstraction make code harder to understand? Similarly, doesn't any verbose style make code easier to understand, even if the boilerplate contributes no additional meaning? Sorry, but I can't agree with this sort of reasoning at all. If it was that simple, we'd still be writing large software systems in assembly language and no-one would use any sort of libraries or modular design.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
throw up;
That one never gets old. My favorite is:
public void loveYou(long time);
You can add an extra pun by adding a comment // this function takes a long time.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Well the last few places are run the same. If you are not an IT company the MBAs will fight tooth and nail not to touch what works as IT employees are plumbers. A cost center where data moves through pipes. Just reality and consider myself happy to have a job. Some don't or work minimum wage trapped.
One client uses a pre sql database called pic from 1972. It won't ever be upgraded because it works and is too important to change
Java is here because that's what's in house and work's
http://saveie6.com/
With basic training in OOP a "hello world" in java is easy to read, but even small projects easily use hundreds of classes which interact in a way that rarely is documented well.
I am just rewriting a 700+ classes java program in common lisp - 95% of the functionality is there and I have not yet written a 100 LOC. Even if the last 5% need 900 LOC, I'm still 400 lines short of 700 times of a well indented "class X { }".
Yeap, of course repeat the type of the object twice, the ugly diamond operators, use else if instead of elif, etc, produces verbosity, but this is not related to be easy or not to understand.
The thing is, I think it is related to how easy something is to understand.
If I can express an algorithm as a single function of 10 lines then, other things being equal, that will be easier to understand than distributing the same algorithm across 5 functions each of 20 lines. You can see the whole thing at once, instead of jumping around within or between files. You don't have overheads of passing around and returning values.
Similarly, if I can express a simple bit of logic as a clean one-liner, while a verbose style requires 6 lines of manual loop/conditional logic and maybe a function wrapped around it, then I'm thinking about what that logic is doing and it how it fits in with the other logic around it while you're still worrying about loop counters.
Here's a version of finding all the items less than 10 in a list, written in Haskell, a relatively powerful language:
Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:
And in contrast, here is the best Stack Overflow has to offer about implementing this sort of requirement in Java.
Spoiler: There are basically three kinds of replies. Some write out entire functions to implement the filter using a manual loop. Some use a third party library to do a more clumsy variation of the Python and Haskell examples above. And a few recent ones use Java 8 to do a slightly less clumsy variation of the Python and Haskell examples above. The clear trend is to try to get away from classical, verbose Java to something more powerful and expressive. Like Scala, according to the first comment on the original question...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
...if you have vision impairment and you're using some sort of screen reader, the python whitespace syntax rules are completely lost on the screen reader software.
Sun workstations were some of the best machines I ever worked on. The Sun 3/50 had a gorgeous screen with Sunview. The keyboard was sublime. X11R4 ran perfectly on my ELC.
basic and pascal are also easy to read.
When the object oriented craze took off in 1990s, we were joking, next thing you know you would have OO-COBOL. And next thing we knew we had OO-COBOL.
All of us know the staying power and entrenchment of that language designed specifically for readability.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I strongly agree with the parent. My favorite language implements this in a similar way to the parent's favorite:
:-) get my thoughts into code. I used to enjoy coding in Lisp for the same reason (still would, if I could use Lisp at work these days). I enjoy coding in Java also, but the difference is noticeable.
my @items = (1, 15, 27, 3, 54);
my @result = grep { $_ > 10 } @items;
I appreciate coding in a language that allows me to quickly and understandably (yes, Perl can be understandable... or not
In a band? Use WheresTheGig for free.
I think that's one thing that makes Java both desired and despised. There are a lot of "clever" code chunks in other languages that are short AND easier to read. Even if it's not as easy to read, it's much nicer to decipher 4 lines of "clever" code than 100 lines of enterprise code spread over multiple files. To find out what a function does, you sometimes have to dig down through several layers of classes and compare across files. It's straightforward if you have the time to deal with it and you don't have to know too much about complicated theories to do it.
It's easy to believe you know what a given bit of code will do, but really understanding that calling .close() on a connection might throw an exception or whatever (the famous 3 hour airline outage case) and how to handle that situation gracefully is far from obvious or easy for everyone.
Totally disagree. If I see
I know exactly what it does. Anyone who has done any programming in any language can guess what it does. Its simple, easy to read, and if you want can be pulled into a function. Your haskell and Python implementations are unreadable and requires the user to think about each line. They're inferior to straight forward programming by orders of magnitude and should never be used.
I still have more fans than freaks. WTF is wrong with you people?
Fortran, way easier to read than Javascript.
Who the hell can tell anything about a javascript routine once you are 20 levels deep in nested braces.
With a few exceptions such as assembly if your code is not readable you are doing it wrong. Code needs to be maintainable. The maintenance costs and lifespan of code often far exceed development cost and time span. If you are not writing clear code you are writing crappy code.
putting the 'B' in LGBTQ+
Now you can basically officially do your own pre-compilation (check -processor option on javac) if you so wish.
Tons of XML weren't really caused by Java's problems (do you actually remember what was put in them??), more of a fashion thing, now mostly replaced with annotations / cleverly chosen defaults.
Most stuff you were doing with monstrous (my personal opinion) frameworks like Spring are part of the standard Java for quite a while (since 2009).
All I had to do was glance at the haskell to know what it was doing. The python was a liittle hinky, but I got it easily enough.
It really depends on how much experience you have with rich languages. If all you ever talk is C/Pascal/Fortran anything else will be harder to read.
This goes for natural languages too, as well as cultural references. It's Joe Bauers' plight.
The simple fact is that there are times to talk really slow with small words for a large audiences and times to use expressiveness to get thing done fast in a professionally erudite environment. Often, complex software design is a case of the latter, not the former. Management would like it to be the former, because H1B, of course, but that is a short sighted strategy destined to leave the company in the dirt.
Someone had to do it.
Tessst!!
There's a difference between abstracting complexity away; and relying on a cute, obscure, not-quite-feature of a syntax in your program because it saves a few characters.
When I open a TCP stream to another system, I don't muck around with any details of the features negotiation, speed... I just do it. When I write to the stream, it's a one-line operation, and the system takes care of retransmission for me, and when I read, the system takes care of packet ordering for me. I don't even need to know what a packet is. That's good abstraction.
or
var doubled = numbers.map(function(v){
return v*2;
});
See, I can read that.
The bad abstraction is the one that still exposes little-known things to the programmer.
@error_or_die(50)
function connect(**options):
or
if(~q.indexOf("=")){
Like, what the hell is going on here?
Wonder what the public key field is for?
Are you saying that
256 * 2 = 512
is harder to understand than
two hundred fifty six multiplied by two is five hundred twelve
Most of those are libraries. Thus they've been solved with any language with similar libraries. Ie, networking - it's sort of there in Java, however there's no control over the networking and how it's implemented and it reflects a small subset of what you may want networking to do (it's good at web oriented stuff basically). Meanwhile just about any language that allows using POSIX libraries can do your basic networking that Java can do. For embedded devices, Java is still very high level, it does not give you register access to the machines for example, so where it is used most typically in embedded systems is as an application layer with the layers underneath written in other languages.
I agree a lot has been added to solve problems. Which means I meet a lot of Java programmers who don't really program, they just tie together pieces of existing code.
No, it comes down to explicitness is always better than explicitness. There is no case in which yours is better, or even usable code.
I still have more fans than freaks. WTF is wrong with you people?
We have a rather large COBOL codebase which I would consider comparatively clean. Roughly 10 days a year are spent on fixing old errors, and those are mostly logical errors in the design, not in the coding.
No dynamic memory allocation is cumbersome but safe. No recursion forces one to do everything step by step and makes debugging very easy. No concurrency makes debugging a breeze.
After my initial frustration with the language I have found satisfaction in designing clever ways around those limitations. This really forces you to think of the algorithms in use, sometimes almost down to Knuth level.
Although I would very much like to rewrite the math-heavy portions in Fortran...
For C users:
// makes code faster // makes data use less memory
#define while if
#define struct union
I'll see your senator, and I'll raise you two judges.
I've never used any of the three languages in discussion here, and would barely count myself as a programmer at all, and upon initial reading of each of these routines this was my interpretation:
Java (I assume yours is): For every integer (call it "i") in the set "items", if "i" is less than ten, do whatever the 'add' function of the 'results' object does to it. (No idea what that function is, but my first guess would be to do the math of "results" + "i". Upon reflection after seeing the other languages' versions of this routine, I get now that it means "put 'i' as a member into the set 'results', or more loosely, "add 'i' to the set 'results'".)
Haskell: The set "items" contains members 1, 15, 27, 3, and 54. The set "results" contains every member of that set ("items") that passes the filter of being less than 10. (This is the clearest to me, and the one that shed light on the purpose of the other two).
Python: The set "items" contains members 1, 15, 27, 3, and 54. The set "results"... uhh.... assuming this does the same thing as the Haskell function, I'd guess it means that "results" contains every "item", where "item" is any item in the set of items, but only if "item" is less than ten; a roundabout way of saying, in a more Java-like fashion, "for every item (call it 'item') in the set 'items', if 'item' is less than ten [then that is part of what the set 'results' equals]".
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
#define yourMom unsigned int
#define fat sizeof(yourMom)
There's a sweet spot for conciseness versus verbosity. If something gets overly concise, then what you say is true. However, there's a such thing as too verbose as well, where it's so indirect that it becomes difficult to read.
Not to mention, Java has a lot of things that are absent from other languages due to being relatively pointless or having better alternatives like public vs private things. On top of that, the fact that Java best practices dictate using getters and setters whenever possible mean lots of additional code. What's easier to read, "object.x = 5" or "object.setX(5)" plus the boilerplate function that actually does the setting? Yes, I'm aware that IDEs can take care of this, but when a language has so much copy-and-paste boilerplate code that an IDE can eliminate a huge chunk of it, that doesn't exactly reflect well on the language.
He's probably a COBOL programmer.
That means you don't understand the differences.
Here's just some of the things I prefer about C#:
1. Generics: C#'s type information is preserved. Java's generics loses type (type erasure), and can only do a compile-time check.
2. Virtual functions: C# forces to you design a class to be overridden. Java's methods are overridable by default. The @Override attribute helps, but it's an after-the-fact band-aid.
3. Structs (value-types): C# has the concept of stack-based objects, which can reduce GC.
4. Exceptions: Java made a fundamental design error with checked exceptions, since checked exceptions is part of the interface.
This is just off the top of my head. I'm sure I can come up with a lot more.
It's also telling that Java is borrowing many, many ideas from C#.
What Java has going for it is its far richer library (C#'s collections library, for example, pales in comparison).
Your haskell and Python implementations are unreadable and requires the user to think about each line.
Maybe you personally aren't familiar with higher order functions or comprehensions. However, millions of programmers are, and would read and understand those lines without a second thought.
Using filter in Haskell or a list comprehension in Python is as routine as using your for-loop is in Java, and the associated syntax is similarly familiar to anyone who's ever done a significant amount of programming in those languages.
Moreover, these tools are declarative, which means you can use them in languages that better control side effects for safety, and you can use them in languages that optimise based on that extra knowledge for faster performance, and you will be able to use them in the data parallel languages of tomorrow to make more efficient use of modern processing hardware. In other words, in languages designed to take advantage of them, these styles immediately convey more information than the imperative style required by your for-loop version.
Perhaps it was the filter function that confused you, if you aren't familiar with that particular terminology? If so, I would remind you that you just wrote a code example full of integers and an add function that has nothing to do with calculating the sum of those integers. (At least, I think you did. I notice that you missed out several lines of initialisation and type declarations for those variables, making your example code considerably shorter than it otherwise would have been if you'd actually written a like-for-like equivalent.)
They're inferior to straight forward programming by orders of magnitude and should never be used.
I honestly don't understand how any programmer, whatever their preference of language, can claim that an expression that says filter (<10) items and means choose the items that are less than 10 isn't straightforward. I think you're just trolling here.
As for never being used, you're welcome to stick with yesterday's programming tools if you like. No doubt there will be plenty of need for programmers to maintain legacy systems for a long time to come. But tomorrow's programming tools will let us build bigger, more efficient, safer programs, and we'll be doing it faster and with fewer resources. If you're not familiar with these idioms yet, you might want to consider broadening your knowledge, because before long every 21-year-old kid who learned programming by messing around with JavaScript in their browser is going to be using them.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
In C++ it should be a for_each and a lambda.
There's a difference between abstracting complexity away; and relying on a cute, obscure, not-quite-feature of a syntax in your program because it saves a few characters.
Of course there is, but at no point have I (or anyone else I've seen in this discussion) suggested doing the latter just to make the code shorter. The point is that there are plenty of languages that can say in one clean, readable line of code what takes half an editor window in Java. I gave some typical examples in my reply to another post.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It's about code density. If a library abstracts something away, but it does it in a very terse and obtuse way, they yes: that /library's/ code becomes much more difficult to read. But client code that uses that library becomes cleaner and easier to read.
Generally speaking, that's a win all around. You can go back and refactor the library to be more readable, understandable, and therefore maintainable (and likely more reliable due to all that).
You haven't changed the number of tokens, so the complexity is equivalent. Take a regular expression versus a series of String.replace statements for a huge number of characters. The individual replacements are easier to understand for someone who doesn't have regex expertise. Of course regexes are more powerful and generally preferred, but they are a complex beast that one has to understand... because they can be understood.
...and Java is easy to read. Seriously though, have I woken up in some bizarre alternative reality? What next: assembler is great because it's so portable? Basic is amazing because it is such a carefully designed and structured professional language? Smoking is good for your fscking lungs???
Have these people never tried to maintain someone else's dogs breakfast of a java code-base?
Actually, I'd say that particular example is one of the most confusing syntax you could come up with. The only way you can guess what it does is because you're already used to it from coding in Java or in C++ 11, but for someone who isn't familiar with that syntax they are bound to wonder what "i" is: Is it an int, or is it an "items"? They might know that "for" starts a loop if they are familiar with Algol-derived languages, but what does that particular loop do: Does it calculate a sum, or fill an array? The Haskell syntax looks much easier to parse in comparison. Or even if you want to stay in the same family of languages, the C# syntax uses a much clearer "foreach (int i in items) { ... }", although in that language one might replace the whole loop with a single instruction "result = items.Where(i => i10)".
The problem with object.x=4 is that it not overridable, the therefore interferes with both the encapsulation and the specialization concepts within the OO world.
I used to think that accessors and mutators were useless until I started really using classes in the way they were intended to be used.
There's an anecdote about Gosling that goes something like he "thought that all objects in Java should be anonymous and implement well-defined interfaces." That sounds completely insane until you think about it from an OO-purist standpoint. Interfaces have no members, so everything is an overridable function. There would be no constructors (as you know them) and all objects would be created much like they are in the JavaScript world: by simply saying "this is an object that implements IWhatever, and here is its implementation.
Of course, it is in fact insane because then the only way to get more than one instance of the same class would be to call a particular factory method. But then, you could always override the factory method and provide a different implementation.
Some of this sounds truly foolish and, yes, idealistic and in some cases just "stupid OO shit... In my day, we wrote asm with only our pinky fingers because our other fingers were busy holding DIP switches/punch cards/vacuum tubes/our dicks" but there really are good reasons for some of the things seen as useless cruft by some.
Refactoring is /much/ easier if none of the internals members of your classes are exposed to the outside. Especially if you are sharing your code widely. If you have a single huge code base with no dependencies then find: make everything public and have at it. But you'll end up with better code if you pretend that everything you write is a library that could potentially be used by someone in an entirely different setting. (Bonus: it makes u it testing easier, too.). So, wins all around for that so-called useless stuff Java makes you do.
object.x = 5 isn't overridable in Java, but it is in other languages like Python.
Refactoring is much easier when the language is actually conducive to refactoring. Java isn't conducive to refactoring at all, so as a result you have to always plan for the worst case scenario (e.g. use getters and setters for everything). Contrast to Python, which makes refactoring objects quite easy due to the amount of control you have over every aspect of your object.
Fortran where construct
It was designed for the mediocre programmer and that is what enterprises hire.
Any dynamically typed language makes refactoring difficult. Hell it even makes figuring out whats what hard. In Java I can search for references to things and who calls who really easily. I can come into a huge code base and just let the IDE take me to the right places. Try that with an even moderately to small sized python or JS project and you'll see what I mean. The fact that so much shit happens at runtime makes it impossible to even find things until you have a pretty good mental model of the application and how its built. I don't need that in Java (until we get to all the frameworks that things away in runtime stuff through configuration). The same thing makes refactoring hard because I actually have to refactor by hand now. If I so much as rename refactor object.x to object.y my IDE can't rename it in all the right places because it doesn't actually know where all those places even are because its only known at runtime. How can I write clean code by having proper names if I'm basically stuck with whatever shitty name developers before me came up with? If I have to run a full regression just to make sure that a rename didn't break anything, I'll just not rename things.
Your example is NOT easy to understand to someone that doesn't know perl. WTF is $_? Sure i know because I've done perl. Does some kid fresh out of uni know jack squat what your code does? Heck he doesn't even get the grep!
Now obviously $_ is such a basic and important element of perl that everyone doing perl for 5 minutes will understand it easily. Enter leaving out $_ because we can't be bothered to write even those two characters. Now lets assume $_ isn't actually $_ but whatever other implicit thing you can imagine in any of the obscure languages that are in use nowadays. Suddenly I have to know aboutt 100 functions that can operate on "$_" even when you dont explicitly state that. Sorry but that becomes unreadable.
Theres a sweet spot between verbose and too frickin magic and Java used properly is pretty much it. When in doubt I'd rather read 2 minutes longer and delete a bunch of overly verbose java into regularly verbose java than to just not frickin get what that piece of JS does until I debug it at runtime to see that something from somewhere injects a new function somewhere overwriting the source code that I read to do sone funky stuff that ultimately breaks my software and has my boss breathing down my neck.
Why do I have to erite an automated regression test suite if a compiler in a statically typed language like java could just let me know that I missed renaming x to y in one place? Which wouldn't even have happened if my IDE had done the rename as a refactoring for me?
Something I don't hear mentioned a lot is that Java is exceptionally easy to debug. Each statement does so little that it is very easy to step through code in a debugger and pinpoint the place that something has gone wrong.
The problem with object.x=4 is that it not overridable, the therefore interferes with both the encapsulation and the specialization concepts within the OO world.
For starters, as noted, it's strictly a language issue - there's no reason why property-style access cannot be made customizable, and it is in C# (just to pick something that's relatively close to Java).
Furthermore, there's no particular reason why you'd really want object.x=4 to be overridable in general. In a language that is designed well, there's simply no observable difference in that operation (and other treatment of 'x') regardless of whether it's a simple field or a code-backed property. Even C# gets it wrong (can't use properties as 'out' or 'ref' arguments of a function, for example), but other languages do it right. In that case, you always start with a field, and you change it to property accessors if and when you actually need it.
You're awfully confident about your subjective judgments. I don't see anything non-explicit about his code, and it's perfectly usable.
The simple fact is that there are times to talk really slow with small words for a large audiences and times to use expressiveness to get thing done fast in a professionally erudite environment. Often, complex software design is a case of the latter, not the former. Management would like it to be the former, because H1B, of course, but that is a short sighted strategy destined to leave the company in the dirt.
I always believed this, combined with the fact that schools kept churning out zombies that had never touched another language, was the main reason for the popularity of Java. It's an excellent language for teaching OO concepts as it is an exceptionally complete and verbose implementation, but it is an absolutely awful language to use in a business setting. This is why people kept coming up with more and more elaborate ways to work around all of the shortcomings involved in using it for anything more than a school project.
In Python:
results = [i for i in items if i 10]
You're right, your Java example was so clear and simple but as soon as I tried to understand that line of Python my head exploded and there are currently mental health professionals coming to take me away for being so needlessly obtuse that they diagnosed it as a severe disorder.
(this kind of expressiveness cannot be achieved by java standard library)
Test.java:144: error: ']' expected
int things[10];
^
Test.java:144: error: illegal start of expression
int things[10];
^
2 errors
The former is obviously much better. It's not just better to read but also to write without the mind veering off from solving the problem at hand.
Those who harp on about verbosity being a good thing don't realize how good things can be.
Why OpalCalc is the best Windows calc
I've often thought about a programming language where you only need to write the smallest possible amount of code to achieve what you're trying to do. And have it clear too (so not Perl style).
No bloat, no header files, no semicolons at the end of lines, swap functionality of && with & and || with | (colour coding them too), power-of symbol (^), terse Haskell-style functionality, and even no forced declarations (the IDE can colour code variables according to whether they're int, double, string etc. automatically, and the scope is automatically defined as the outermost appearance of the variable). The compiler would do ALL the hard work to optimize the program.
Why OpalCalc is the best Windows calc
On the other hand you can write a huge amount of projects without ever encountering any of these clever libraries. I just love to keep my dependencies minimal.
Having not yet touched Haskell, I love the terseness of the Haskell example. To me it feels like a high level function, like as if it could be rewritten:
items = [1, 15, 27, 3, 54]
result = items.filter(<, 10)
Perhaps all Haskell functionality can be converted like this?
Why OpalCalc is the best Windows calc
Yes, but you have a very narrow view, here. If I change the name of 'x' in the class, I have to change it /everywhere/, unless the language has a way for me to say "by the way, if someone assigns to 'x', really assign to 'y' instead.
Try doing that in library code, where you don't have the ability to re-factor everyone's code that relies on yours and you'll see that property-backed accessors are not sufficient for robust and maintainable code - at least, not code used outside one's own toy examples.
Comment removed based on user account deletion
+1 for your java expression.
I find the groovy addition of the "in" even more readable:
items = [1, 15, 27, 3, 54];
results = [];
for (item in items) {
if (item 10) {
results.add(item);
}
}
Also the lambda version in groovy is not bad at all:
items = [1, 15, 27, 3, 54];
results = items.findAll { it 10 };
Haskell: WTF are the types? .add(int) might be a bit ambiguous, but with Java, we have some damn nice tools called IDEs that'll give us a nice popup telling us results is a collection and the add method adds to it, and that's assuming there's not a line List results = new ArrayList(); right above the snippet you took.
Python: WTF are the types?
Java: items is clearly a collection of integers (dictionary definition of collection - I can be totally ignorant of Collection.class and know that). The for loop clearly tells me I'm iterating through each element. Sure,
Java's cross-platform support is mentioned in passing in the article. But they fail to recognize its importance in a key setting: the academic environment. Not only is Java available for all the important platforms that students may own (Windows, Mac, and Linux), the SAME implementation of it is on all those platforms. That means that students can use any of those platforms to do their assignments, and be confident that their programs will run correctly on the systems used by the graders. That is a key advantage over using C or C++.
Python is also cross-platform, and it has seen substantial growth in academic use in recent years. Vendor-bound languages like Swift and C# aren't in the running for general academic use, though schools offer courses that are specifically about them. (C# may become more usable in the future now that Microsoft is opening up parts of .NET but it has to be considered a Windows-only language for now.) The next frontier may be browser-based programming environments using Javascript; those will offer excellent cross-platform compatibility so long as all students use the same browser (which means one that is available on multiple platforms such as Chrome or Firefox), and probably an acceptable level even if they use a different one.
Quote about filters in Java from this link:
Filter in place or into another collection?
Haskell programmers are crying.
The colon is no longer used, we only put one at the end of each paragraph (procedure).
Parsing XML in COBOL is very easy. You use the XML PARSE command in a loop. Each time the parser finds an XML tag it return control to your program, giving you the tag name, attribute(s) and value. You process it, then call the parser again until the end of the document.
Likewise, generating a complex XML document in COBOL is done by defining the hirarchical structure in a copybook, assigning values, and then calling a single command: XML GENERATE.
It's very easy, and very fast.
Try it! Library of Babel
Yes, but you have a very narrow view, here. If I change the name of 'x' in the class, I have to change it /everywhere/, unless the language has a way for me to say "by the way, if someone assigns to 'x', really assign to 'y' instead.
And how is this different from setX?
Reading from standard input does not mean "reading from the command line". Standard input is often redirected from a file, from another program's output (called a "pipe"), or from data provided by the client that connected to a running server.
Foo foo = new Foo()
Which isn't necessarily good style.
First, the type name in a declaration can and often should be more generic than the constructor. It could be an interface that the constructed class implements or an abstract class that the constructed class extends. For example, you can do Map map = new TreeMap() if you're not going to call any tree-specific methods later on.
Second, why name the variable similarly to the class? Map enemies = new TreeMap() makes the variable's purpose easier to understand.
Java is not functional
Only because Oracle keeps breaking it. The Java virtual machine's security has proven to be Swiss-cheese enough that Oracle is falling back on the traditional video game console security paradigm (reliance on commercial code signing certificate authorities) rather than actually restricting what a program module can do.
#2. Scheme is a Lisp, so if Java were a heavy weight one, we would have a widely adopted Lisp.
We do have a widely adopted Lisp. But it's not Java; it's JavaScript. JavaScript implements Lisp-like semantics, and its syntax is a C-colored fulfillment of the "M-expression" syntax concept originally envisioned for Lisp.
colon? I meant the period!
Sorry for my poor english.
Try it! Library of Babel
if you took someone that never read or wrote code before and showed them 100 line, idiomatic programs in Java, Javascript, Python, Ruby, PHP, Perl, Lisp, Haskell, C, Fortran, COBOL, Basic, and a few other languages that Java would not top the list for readability. My guess is that the winners would be Basic, COBOL, and Python.
Depends. My bet is that it entirely depends on the background of the "someone" you've taken.
- english speaker ? mostly used to litterature and philosophical logic ? yes, maybe as you list them.
- background in mathematics ? The order will probably be reversed, with probably Haskell, C and Fortran near the top. And probably APL topping them all. And the guy complaining that most of them still miss support for greek alphabet.
some people are used to see things written down in plain text, other are better used to see things written with symbols.
plain text has the advantage of being a little bit clearer for a person who happens to be fluent in the language which was used to create the language (say hello to dialects of Logo and Excel macros translated into various languages). Otherwise it's completely useless (most of the language you mention are based around english. useless non-english speakers. when I was a kid, I started learning to code in basic before I knew english).
symbolic notation has the advantage of being more compact (requires less typing, quicker to read)
cf. the well know geeky joke of "add 1 to cobol giving cobol" vs "C++"
And well, Perl, let's forget about Perl. It's a write-only language. :-D
The only language your cat can write legal code in just by walking across the keyboard.
(Disclaimer: I used to code a lot in Basic as a you kid. Started C a bit later, and learned english about this time. I code also regularily in Perl, C++, awk, php, 386 assembler, etc. I know bits of R, javascript, python, FORTRAN, did some Logo in french in school as a kid, etc.)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Ah.. the word "filter" again.
filter (10)...
What does it mean?
1) Filter out every item matching the criteria (ie, discard every item less than 10)
2) Filter out every item not matching the criteria (ie, keep every item less than 10)
I'd agree with the ecosystem being a huge factor in Java's success.
.......................
One ecosystem component must include the cost for a full kit at a school.
SCHOOLS:
At the time Java was hatched and multiple JVMs ported there was little in
the way of a teacher adding it to a class.
It is a worthy and well thought out language and that help.
But I would assert() that the net cost for a class of 120 students
on WindowZ boxes is the reason this worthy language gained traction.
GCC was first out of the gate but it was not novice friendly
for a gosh long time... It gained serious traction with Linux.
As always we can look back with 20/20 hind sight but I watched
it hatch and cost and availability was a critical component.
Yes it helps that it was and is a decent language.
In this case, "filter" means select only those items that match the criteria, i.e., where the given predicate is true.
This usage is about as consistent as anything you'll find in the programming world: languages using it this way include Python, PHP, JavaScript, Java, D, and many well-known functional programming languages including Haskell, several of the ML family, Erlang, Scala and Clojure. Some other well-known languages have related algorithms under other name, but I know of no counter-examples that use "filter" in the opposite sense.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Once when I was teaching Python, it amused me to notice a beginner try to write a function in a way that would be valid Haskell, but wasn't valid in Python. Your own post also seems to find Haskell more natural. I wish I could spend more time with Haskell, it seems very interesting.
Depends on how the language does comments. I think it wouldn't work on either Perl or Haskell.
I started learning Java at the university and found it to be the most complicated and convoluted way of programming. There is a ton of stuff you have to get straight before you can even print your first "Hello World!" to the screen. I dropped the class and changed the major...and apparently I am not human.
Your poor reading comprehension is perhaps the root of your confusion. I didn't say anything about a tool for all jobs.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Rapidly switching back and forth between en-US and the keyboard layout for your native language can be uncomfortable as well.
Your poor reading comprehension is perhaps the root of your confusion. I didn't say anything about a tool for all jobs.
I apologize for imperfectly understanding your comment. I'll instead try to explain my miscomprehension one step at a time so you can help me understand where I went wrong. As far as I understand your comments so far, you're suggesting using one tool for entering code and another for entering native language text. Writing a program includes both code in a programming language and comments in the language of the programmer team. And as I understand dunkelfalke's comment, the programming language is optimized for the en-US keyboard language, but the language of the programmer team is not en-US. If one's responsibilities include rapidly switching between writing code in a programming language and documenting it in a human language, what are you trying to say is the appropriate tool for each job?