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."

Comments

Yes & the sheer amount of existing code/framew

[Anonymous Coward]

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.

"Easy to read" is non-sense

[Anonymous Coward]

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.

Re:"Easy to read" is non-sense

[jfdavis668]

His point is that it doesn't contain strange syntax that isn't easy to follow at first glance. One of the original purposes of Java was to eliminate the complexity of C++ has from its C legacy. When you use a command in Java, it does what its supposed to do. They are not using it as some obscure purpose to take advantage of some quirk in the hardware. Java did this by defining its own hardware of sorts, the JVM. It moves the complexity of the actual system to a group of programmers who specialize in that arena, the JVM developers. It's not that all Java is readable, we maintain one system we inherited that was developed by a poorly trained group of developers. The names of classes provide no help in understanding the code. One of the main classes is "M". They also put things together in classes that have nothing to do with each other. We are re-developing that system from scratch to fix it. Even with this, there are no commands in the system that we don't understand when we read them.

Re:"Easy to read" is non-sense

[jareth-0205]

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.

Clearly a language can be easy or hard to read - Or do you think well-written Brainfuck is easy to read? Since programs are written by actual flawed humans who make stupid mistakes or have weird style preferences sometimes, it's generally a good idea to have a language syntax that doesn't let them shoot themselves in the foot.

Re:"Easy to read" is non-sense

[jfdavis668]

That would make sense, but the system I am referring to doesn't. There is a "Q" class, but it is not a queue. I don't think the people who wrote this know what a queue is. Took us a while to figure out that "rlogic" was the actions initiated from the right side of the screen. Doesn't tell us what they do, but it made some sense. The amazing thing is the system works, even if we don't know what the parts do. The naming standards look more like algebra than Java. We think the whole system must be trying to solve for "x".

Re:"Easy to read" is non-sense

[Hognoxious]

Is there one called DTN?

Re:"Easy to read" is non-sense

[funkymonkjay]

I am wondering if that code was decompiled. Actually, I am pretty sure class names are kept intact in the byte code. Not so much for internal variable names. If it was done on purpose, maybe there's a speed benefit when searching for a class. Or it was as you said it was coded by a math nut who is incapable of naming things with more than 2 letters.

Re:"Easy to read" is non-sense

[DuckDodgers]

Java doesn't have obscure syntax - part of that is the language itself, part of that is the fact that it explicitly doesn't support operator overloading and that prevents people from making incomprehensible DSLs ( Scala's SBT, anyone? )

On the other hand, in terms of "readable" I still think calling Java readable assumes a familiarity with C style syntax. I think 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.

One of the biggest reasons C++ became popular was that it was a relatively small step away, in terms of syntax, from C. I really think Java became popular mostly because the syntax is a small step away from C++.

Re:"Easy to read" is non-sense

[Giant Electronic Bra]

You really cannot refactor something like this with a modern IDE and change the class names to something sensible? Ugh.

I totally agree with you about Java though, its quite readable. I have a LARGE code base and I can hand pieces of it to people and they can grasp what it does. I won't pretend its a model of perfect design, like any large old code base it has plenty of stupid in it, but the classes make sense, the overall organization and design is pretty good, and even if some of the APIs and such aren't exactly what I would do today and certain practices are sub-standard on the whole it works well, survives refactoring without too much pain, and does what it is supposed to do. It will almost surely be in production for decades hence.

Re:"Easy to read" is non-sense

[Giant Electronic Bra]

Right, but I would argue it extends far past easy to read. Java is easy to grasp. It is very clear which method will be invoked when you make a method call. It is very clear what the lifecycle of a memory allocation is and there's no question about who is responsible for managing that chunk of memory, etc. Its just VASTLY easy to code in Java. Now, the development tools/environment may not be as simple as scripting languages, which tends to push untrained 'do-it-yourselfers' into things like PHP where they can see some results on day one, but for the organization which has real business needs and develops code to meet them, Java is an excellent choice because in all respects its clear what things do and how they work. I can look at virtually any piece of decently-written Java code and understand it. At the very least I won't find out that it does something totally different than it appears, which is COMMON in C++.

Re:"Easy to read" is non-sense

[darkwing_bmf]

I think Ada and Pascal are the most easily readable.

Re:"Easy to read" is non-sense

[Anonymous Coward]

Mod parent up, code readability is a trait of the programmer, not the language.
the reason Java stays is, imo, because it was every educator and manager's wet dream. Yet I still have to find a single coder that knows more than 5 languages who prefers writing Java over anything else.

Personally, I'd rather have my nutsack removed without anesthetic than write java

Re:"Easy to read" is non-sense

[oh_my_080980980]

Lot of "ifs" in that statement of yours. But your fundamental assumption is flawed, it is not easy to read code period. It's easy if you developed it and it's easy if you routinely code in that language but when you are not the developer and you don't routinely use that language, then it becomes difficult. Not too mention programmers suck at documenting their code. The point of high level languages is that they would be readable like the english language. Java is pretty close to that.

Re:"Easy to read" is non-sense

[fulldecent]

Yes, and if you gave someone who never read or wrote code before and gave them a printed sheet of Perl... they might wonder if the sheet is upright or upside down.

Re:"Easy to read" is non-sense

[Megol]

Are you joking? Ada is easy to understand because it was designed to be. It is verbose and partially redundant by design as that is known to 1) increase understanding of programs 2) decreases some types of common errors.
Pascal wasn't really designed for ease of use (even though it is), one big problem is the use of semicolon as a separator: it isn't always obvious where they should go and misplaced semicolons can generate errors.

Re:"Easy to read" is non-sense

[Capt.Albatross]

If a piece of code is well written...

This is not an article about what is possible, it is about what actually happens. I have seen incredible abuses of operator overloading, for example. I have also seen some highly confused Java, but its pedestrian syntax seems to make it a little harder to write cryptic bad code in.

Re:"Easy to read" is non-sense

[peppepz]

No, it wasn't... in the old times it allowed you to skip whitespace in order to save memory, so programs used to become wall of characters, and you couldn't even call a variable "sprint" because it contained the reserved word "print". And its later incarnations were full of puzzlers. Just the first ones that come into my mind: "On Error Goto 0" means "throw an exception"; functions and procedures have a different invocation syntax and invoking a procedure as a function doesn't fail but results in a different operation; the assignment operator is different between objects and non-objects; function parameters are passed by reference by default...

Re:"Easy to read" is non-sense

[__aaclcg7560]

When I took "Introduction to Java" in college, two students got into trouble for having submitting identical code with one slight variation. The variable used by the first student was "x" and the variable used by the second student was "y". Being cute doesn't get you a passing grade.

Re:"Easy to read" is non-sense

[LWATCDR]

I disagree that it is because java is easy to read. Java is easy to write. A good programer can write an app in Java and have it work really well. A bad programer can write an app in java it will work.
With C++ a good programer can write an app and it will work but you really have to watch for a lot of gotchas. A bad programer can not write a program that works in C++ because it will leak memory, stomp on memory, and have issues with pointers.
Java is better at stopping the little brain farts from blowing up in your face.
C++ is a lot more fun to write in IMHO.

Re:"Easy to read" is non-sense

[budgenator]

Perl definitely is hard to read as normally practised, but you can write very legible Perl with little added effort. If you avoid regular expressions and use English.pm and can't read the code, you'd probably have trouble reading even COBOL.

Re:"Easy to read" is non-sense

[__aaclcg7560]

When I went back to school to learn computer programming after the Dot Com bust, the community college couldn't afford to renew the Microsoft site license for a few years. All the required courses was taught in every flavor of Java. The dean taught some C/C++ programming in his Linux administration courses. After the site license got renewed, we had Visual Studio to learn C/C++ proper (as in a job skill). I haven't touched Java since I graduated from college. These days I use Python at home and PowerShell at work.

Re:"Easy to read" is non-sense

[wonkavader]

I'd put it differently: When you keep legibility and understandability in mind as a goal when writing in perl, the many syntax constructs available in it which are not in Java (for example) allow you to write much more understandable code in perl than you could in most other languages.

The fact that it also allows you to write stuff non-perl people cannot fathom is a problem, and any coding projects started in perl need a day-two code review and some conversations with the people involved. They need to know they're coding for the next user of the software more than they're coding for themselves. If they have trouble with that, then they're too young to be trusted with your business.

Re:"Easy to read" is non-sense

[Anonymous Coward]

"When you use a command in Java, it does what its supposed to do."

Does it? Because I don't think it does.

Foo bar1;
Foo bar2;

bar1 = bar2;

int bar1;
int bar2;

bar1 = bar2;

One of these is a copy assignment, the other one is not.
No way to tell by the syntax.

foo(bar); where bar is an int vs foo(bar); where bar is an object - pass by reference, and again no way to tell by the syntax.

The _exact_ same syntax, often means two completely different behaviors.

In c++, if you want a pointer or a reference you have to explicitly say so.

When I make a function taking a Bar&, I want a reference to some damn Bar.
I'm explicitly telling you I do not wish for you to give me a null pointer.
No 30 lines of boilerplate null checking required.

In the same way, if i'm calling a Foo( Bar bar ), I do not expect for the function to change the state of my bar.
In java, there is no way to be sure of this.

In Java you have to be constantly on the lookout for someone to screw your objects up in a way you did not anticipate.

I don't call that "doing what it's supposed to do". /end of rant

Re:"Easy to read" is non-sense

[RockGrumbler]

I do not think english is particularly good at unambiguously specifying the steps necessary for algorithms. I do not think that making computing languages resemble english is intrinsically good.

Re:"Easy to read" is non-sense

[anarkhos]

It's not nonsense, it's bullshit.

Not only is Java NOT easy to read, it clearly has nothing to do with its popularity.

The reason it's popular is for the same reason smalltalk was not: vendor support. Java was free with multi-platform compilers and corporate support. It was pushed heavily in universities which is how this foul language spread. There is nothing inherent about Java which made it popular.

You could say the same thing about UNIX.

Re:"Easy to read" is non-sense

[ttucker]

int things[10];

things[11] = 47;

What is that supposed to do?

Re:"Easy to read" is non-sense

[rnturn]

``...they might wonder if the sheet is upright or upside down.''

Um... surely you're thinking of APL.

Re:"Easy to read" is non-sense

[0bject]

Identify code as being programmed by a moron.

Re:"Easy to read" is non-sense

[DMUTPeregrine]

Well, even when you can refactor it you have to figure out what the classes do before you can give them sensible names.

Re:"Easy to read" is non-sense

[Anonymous Coward]

It's not nonsense, it's bullshit.

Not only is Java NOT easy to read, it clearly has nothing to do with its popularity.

The reason it's popular is for the same reason smalltalk was not: vendor support. Java was free with multi-platform compilers and corporate support. It was pushed heavily in universities which is how this foul language spread. There is nothing inherent about Java which made it popular.

You could say the same thing about UNIX.

Boy are you a victim of mis-moderation. People are modding you down because they don't like the way you said something that others have said above and been modded 5, Insightful. What a crock! Sorry, I tried to mod you up from a 3, but when I finished the cooks had modded you to -1 Flamebait. I wish someone that disagreed would put some effort into explaining why, because I think you're spot on with the reason why Java got popular. It was heavily lobbied for by Sun, not only in industry/corporate circles but in academia where it took off because of its gradual on-ramp to use (like a lot of scripting languages). It was easy to teach to people that had minimal experience with languages that came before it (BASIC, Pascal, C/C++ and Fortran) and its syntax and grammar made it more difficult to botch things up. Plus, it hand a sandbox in the JVM (that was actually riddled with holes and vulnerabilities early on) that provided JIT compilation so you could run apps quickly to test functios as you went along and debugged them. There were some features that made it compelling for corporate and academic use, but human readability of the source code wasn't one of them.

Re:"Easy to read" is non-sense

[AuMatar]

Don't worry- Java people are learning how to make up for that by creating whole incomprehensible sublanguages based on annotation processing that make C macros look good.

Re:"Easy to read" is non-sense

[plopez]

I was once complimented on the clarity or my Perl code. I posted some and got several stero-typical responses fo 'well it could be written better as....'. Then someone piped in and said something like, "screw it, It's clean and easy to read. There's nothing wrong with it". And that is what my experience as a maitnence programmer taught me. If no one can read it to maintain it, it is crappy code.

Re:"Easy to read" is non-sense

[ttucker]

It is supposed to fail, but instead does something terrible. I guess the whole C++ is more sensible than Java thing is called into question by counterexample.

Re:"Easy to read" is non-sense

[orlanz]

Doesn't the end if and end loop become the same crap but more verbose once you have nested ifs and loops?

Re:"Easy to read" is non-sense

[malacandrian]

I agree that var is bad, and that if you use it you are a bad person; but used well lambda expressions can greatly enhance readability - particularly when used with LINQ queries. Consider the following two tests (code written from memory, it's been a long time since I've done this, there's probably mistakes)

Assert.IsTrue(list.Any(item => item == value));

against

bool matches = false;
foreach(Type item in list) { if(item == vale) { matches = true; }}
Assert.IsTrue(matches);

The first one is obviously a lot shorter, but its real advantage is that it actually looks like what it does with no need to parse loops or introducing tracking variables.

Re:"Easy to read" is non-sense

[Cro Magnon]

COBOL is a very readable language. That didn't stop people from writing code that could rival the worst Perl code as far as understanding it went.

I agree that writing Java is not much fun.

Re:"Easy to read" is non-sense

[styrotech]

Also as a non Java coder who used to be able to mostly read Java, I found Generics have put a stop to that.

Java might've been kinda sorta easy to read a decade ago, but it isn't now.

Re:"Easy to read" is non-sense

[vilanye]

foo(bar); where bar is an int vs foo(bar); where bar is an object - pass by reference, and again no way to tell by the syntax.

Java is always pass-by-value. ALWAYS

What gets mistaken for pass-by-reference behaviour is really just a mutable object getting changed in a method call.

Primitive or object, Java is always pass by value.

swap(Type arg1, Type arg2) {
        Type temp = arg1;
        arg1 = arg2;
        arg2 = temp;
}

Type var1 = ...;
Type var2 = ...;
swap(var1,var2);

Those semantics fail in Java, because Java is always pass by value

In the same way, if i'm calling a Foo( Bar bar ), I do not expect for the function to change the state of my bar.
In Java, there is no way to be sure of this.

Sure there is, if an object passed is mutable, the state of the object might be changed. That's it. Check the method docs to see if it does change it. If the object is immutable, it obviously won't change.

It is not that complicated.

Some day, Java might even be acceptable. It finally got a real lambda, too bad Swing is dead or it would really benefit from not having all those inner-classes making a mockery of proper programming.

Re:"Easy to read" is non-sense

[anonymous_wombat]

I really think Java became popular mostly because the syntax is a small step away from C++.

It's simpler, and more portable than C++. Also, it interacts seamlessly with other JVM languages.

Re:"Easy to read" is non-sense

[shutdown -p now]

part of that is the fact that it explicitly doesn't support operator overloading

I would argue that this creates as many problems as it solves. E.g. when working with BigInteger or BigDecimal, a.multiply(b) is less readable than a*b.

Re:"Easy to read" is non-sense

[DuckDodgers]

Excellent point. Perl is a fantastic language. But like C++ and Scala, the problem isn't in the well-written code. The problem is that it's too easy for someone to write unintelligible crap with abuse of syntax corner cases, macros (for C++ and Scala) and operator overloading.

Re:"Easy to read" is non-sense

[DuckDodgers]

The non-overloaded code has a readability problem, I agree. But for example the Scala Built Tool, SBT, has operator overloading abused to hell and it makes complex build files useless to read for all but really experienced SBT users. The XML-driven Java build tool Maven, the Groovy-driven Java/Groovy build tool Gradle, and the Clojure-driven Java/Clojure build tool Leiningen are all much easier to read. Though to be fair, Groovy supports operator overloading, the Gradle team just chose not to abuse the feature for build management.

Look at some SBT examples, for example https://github.com/playframewo... In that file we have %, +=, :=, , none in a mathematical context, all on top of normal Scala operator syntax =, ==, =>, _, etc... I'm surprised I didn't see ")*&%()*$&%&&*XR&R^NO CARRIER" at the end of the file.

Re:"Easy to read" is non-sense

[DuckDodgers]

Dammit, Slashdot nixed half the funky characters I put in my message because they used a less than sign.

Re:"Easy to read" is non-sense

[shutdown -p now]

Scala's problem, I think, is not that it has operator overloading, but that the conventions around the language encourage its use for DSLs. C++ also has this problem, but to a significantly smaller degree, and C# doesn't have it at all.

Re:"Easy to read" is non-sense

[DuckDodgers]

But contrast that with Lisp or one of the Lisp dialects like Clojure - you can use macros to make a DSL, but no matter how you slice it the code is bone simple to read if you know regular Lisp syntax.

Re:"Easy to read" is non-sense

[shutdown -p now]

I disagree. "Lisp syntax" is almost a misnomer, as there's so little of it. Pretty much the only thing you're guaranteed is that () are for grouping, and spaces are separators (and even that is not necessarily true in CL). Everything beyond that is up to the DSL in question, and people can and do get overly "creative" with the syntax such that it's not simple or obvious to read at all.

Re:"Easy to read" is non-sense

[DuckDodgers]

The fact that Lisp syntax is so simple is a strength of the syntax, not an absence. Instead of spending days to grasp all of the syntactic quirks of a language, you can grasp the whole thing in just a few hours.

The parenthesis inherently give you grouping, so there are no operator precedence rules to grapple with. And often you don't need a fancy DSL for a syntactic map to your data structure, you can use Lisp data structures as-is.

Re:"Easy to read" is non-sense

[squiggleslash]

If you avoid regular expressions and use English.pm

True. Similarly French is very easy to understand if only words that are common to English and French are used, and if the speaker speaks them with an English accent...

Re:"Easy to read" is non-sense

[shutdown -p now]

In my experience with Lisp, its absence of syntax is only beneficial for macros, but both writing it and reading it is a pain (comparatively to other languages with more rich syntax). People claim that this is subjective and you get used to it, but I find it hard to believe that human brain can't do better with more and easier to grasp clues when parsing things. Someone should make a study on how easy it is to parse Lisp vs, say, Scala.

In any case, we have deviated from the original point, which is the readability of custom DSLs. I don't see anything special about Lisp that makes them any easier to understand.

Not as easy to read as Python though

[mann17]

Not as easy to read as Python though

Re:Not as easy to read as Python though

[Christian Smith]

Not as easy to read as Python though

Properly, consistently indented Java is. It's just that python has to be correctly indented to work, which is great, BTW!

Re:Not as easy to read as Python though

[gatkinso]

Two words: tabs, spaces.

Re:Not as easy to read as Python though

[AchilleTalon]

BTW, in case you haven't noticed, Python syntax is similar to Fortran syntax which is among the oldest, if not the oldest programming language still alive.

Re:Not as easy to read as Python though

[engun]

Exactly. Having used Java in an enterprise setting for many years, and having had the good fortune to move to Python, I couldn't be happier. I realised how much more verbose Java was than its Python equivalent. Even if you overlook that - there's an inherent structural complexity that Java engenders to its code - one only need look at the Python equivalent to see why. For example, take a look at a basic Hadoop WordCount example here: http://wiki.apache.org/hadoop/... Now compare a rough Python equivalent here: http://mrjob.readthedocs.org/e...

It's not just stuff like the lack of lambdas (it looks like Java 8 has fixed this), or the static typing that contributes to this complexity. I suspect that the culture that has sprung up around Java favours over-architecting and over-engineering, which is exacerbated by its statically typed nature. The Java language itself is simple enough.

In contrast, there is a cult of simplicity around Python, and the language itself has a high-level of expressivity, allowing for a clearer exposition of one's intent - instead of burying it in layer upon layer of abstraction built to please the language and its type system. C# is a language that fares much better than Java in this regard - it's a lot cleaner. For starters - no type erasure!

Re:Not as easy to read as Python though

[TeknoHog]

BTW, in case you haven't noticed, Python syntax is similar to Fortran syntax which is among the oldest, if not the oldest programming language still alive.

This. I think Fortran (and now Julia) strikes the best balance, because it doesn't have the tab/space issue that may produce problems, especially when sharing code. Like Python, it lacks the ugly {} ; punctuations, but it needs something to denote the end of a block, so it uses the English word "end" to keep things simple and clean.

Re:Not as easy to read as Python though

[jellomizer]

Except when you are trying to debug code where the indents are mixed with Spaces and Tabs.

Re:Not as easy to read as Python though

[Marginal Coward]

I agree: that seems to be the thing that Python does better than any other language, IMO. That also points out a fallacy of the premise in TFS: it doesn't really make sense to attribute the success or failure of a given language to any single factor. Instead, programmers evaluate each on a combination of factors, and each has strengths and weaknesses compared to others. Therefore, each language fits into different areas, and a language thrives and prospers according to how many such areas there are and how important those areas become.

IIRC, the original strength of Java was supposed to be "write once, run anywhere." I think it was the first language to feature that as the primary selling point, though others have followed. It's surprising that its primary initial selling point would now be eclipsed (tee-hee) by supposedly being "easy to read" - especially since that could be said about several other languages, depending on one's personal preferences in that regard.

Re:Not as easy to read as Python though

[Anonymous Brave Guy]

I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.

Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.

Re:Not as easy to read as Python though

[pr0nbot]

I frequently find myself digging into some Python library for some reason, only to be surprised at how little code there actually is. Python somehow seems to be concise and expressive. I can't say the same for the Java code I've looked at.

Re:Not as easy to read as Python though

[wonkavader]

Two more words: pretty print.

Re:Not as easy to read as Python though

[__aaclcg7560]

Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.

Let's see... 1927... had the first working TV. I guess you can't edit something without seeing it first.

Re:Not as easy to read as Python though

[tbttfox]

If Python encounters mixed indentation, it raises an IndentationError and points you to the exact line the error occurred. If you've got an editor that will run a linter on your code, it'll catch it even before you run. I use vim, so I just use retab, and go on with my life.

Re:Not as easy to read as Python though

[Anonymous Brave Guy]

And in development I have seen lots of python programmers who printed out their own code to meditate on where the one bug is they could not find on screen - only to waste another few hours because the tab/space bug was obfuscated by a page break in the printout.

Good for you. The last time I saw a programmer do that was... also never in my entire career, actually. If your programmers have trouble meditating on a print-out of a language with syntactic whitespace, you might suggest they instead use any modern text editor and a macro/plug-in that makes mismatched whitespace show up in bright red. Then they can become enlightened, spend less time "meditating" like programmers who work with punch cards, and spend more time making useful software.

Curious, which editor from 1927 would you recommend?

I doubt that there was any text editor available in 1927 that got tabs/spaces wrong when working with Python code. Take your pick.

Re:Not as easy to read as Python though

[TeknoHog]

Have you ever looked at the Fortran sections of CHARMM (MD package)? You want something hard to read that will make your head explode, go look at some of that mess! Not only is everything in CAPS there are space indents in the code and if you don't match those up, WHAMMO! error time!

I haven't had a look, but from your description I assume it's Fortran 77 (or even older, though that's unlikely). It's a good point, though; everything good I've said about Fortran refers to F90 or later. I agree that F77 is a mess and it lacks a lot of the modern niceties, for example with vector/matrix types (imagine writing auto-parallelized matrix math in the 1990s).

I'm pretty sure that all the bad things people generally say about Fortran are because they're only familiar with the horrible old versions. The change to F90 didn't exactly happen overnight with all the legacy code around; the only time I've worked with F77 was at CERN in 2001, but fortunately I got to write my part in F90, only using the legacy bits as reference for the data format.

Re:Not as easy to read as Python though

[mattventura]

I've never actually seen issues with that. Establish an indentation style for your project, whether it's tabs or X spaces (4 being the typical Python style), and enforce it. If someone can't commit code with the right indentation style, they shouldn't be writing code in the first place.

Re:Not as easy to read as Python though

[engun]

I don't disagree. Static typing shines for the tasks you mentioned, and I have felt its absence in Python on several occasions. I have wondered about Python's scalability in larger projects - but I think the lower cognitive burden in Python counteracts any losses incurred from the lack of static typing. Plus, test cases can take care of that to a great degree too.

In Python, people rarely use code generators. It's hardly ever needed. I think that says something too. There's often a lot less boilerplate.

WRT to your comment on the two examples - yes, the boilerplate could have been reduced. Yet, it hasn't been - why is kind of my point. If you work with Python libraries for an extended period of time, you will see this simplicity recurring again and again and wonder why the Java equivalent is almost always more complex. In fact, I would be happy to throw down the gauntlet and say that for any given piece of Java code, the equivalent Python code would often be easier to grok. (One way to test this would be to compare equivalent code using the standard libs)

Re:Not as easy to read as Python though

[DrVxD]

"python -tt" is your friend.

Corollary: It's difficult to be "clever" in Java

[Anonymous Coward]

And that's a good thing.

verbose enough to be easy to read

[antiperimetaparalogo]

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").

Not easiest to read, but forgiving...

[CraigCruden]

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.

Re:Not easiest to read, but forgiving...

[Anonymous Coward]

You made me google "cylindrical reference".

Re:Not easiest to read, but forgiving...

[invid]

A problem with Java and C# is that it is possible to create memory leaks in those languages, but since people rely so much on garbage collection they don't think about it and get bit in the ass. Event handlers shared across processes are particularly dangerous.

Re:Not easiest to read, but forgiving...

[Daniel Hoffmann]

I think he means circular reference ( http://en.wikipedia.org/wiki/C... )

Re:Not easiest to read, but forgiving...

[dimeglio]

Hard for me to agree that a language is forgiving when it avoids syntax pitfalls other languages might contain. Forgiving implies it let's things go. In this case, Java by its design and nature, helps avoid problems you would otherwise need to deal with when using another language.

Re:Not easiest to read, but forgiving...

[asylumx]

Give him a break, he's been programming in java for 15+ years.

Re:Not easiest to read, but forgiving...

[Chris Mattern]

A cylindrical reference is like a circular reference, except it happens when your code is three dimensional.

Re:Not easiest to read, but forgiving...

[Anonymous Coward]

Hmmm. I enjoy driving my modern car because it has an fuel injection and an engine management CPU. I guess I'm just not a real "driver" because I drive such a forgiving car. If I really knew what I was doing, I would drive a car more like a Ford Model A with a crank start, manual choke, and manual spark advance on the steering column.

Machines (I'm including computers in this category) that provide useful abstractions that relieve the machine's users from having to be concerned with details of the machine's operation that are not germane to their primary purpose in using the machine are valuable, not props for the weak-minded.

If we all still coded by hand in machine language or (slightly better) assembler, we would not be able to produce code at anywhere near the rate we do. Languages that are forgiving in the sense that they take care of the details that machines are good at taking care of, and allow the programmers to focus on solving the real problems are a tribute to our ability to continually improve. The implication that programmers using such a language "don't really know what they are doing" naively assumes that what programmers should be doing is worrying about memory management instead of understanding the actual problem to be solved using the computer.

Re:Not easiest to read, but forgiving...

[Xest]

Maybe it's where you create an array of circular references?

Re:Not easiest to read, but forgiving...

[pr0fessor]

You have just described why java has been such a pain in my neck. Otherwise nice looking software that functions until the memory leaks cause it to crash.

As for c# events, delegates, and event handlers in the msdn documentation is a mess it's not surprising it's a issue. I've read a few of the tutorial and I'm not sure the people writing them even understand what they are doing.

Re:Not easiest to read, but forgiving...

[Giant Electronic Bra]

Yeah, but they are a class of leaks which are generally not that hard to sort out. Now, I've seen a few ugly leaks in my time that had no really obvious source, but even then it was very easy to determine WHAT was leaking and HOW, even if the exact explanation of WHY was rather obtuse. Your average programmer can understand most of the common cases though, like "gosh I created a static list of unbounded size and put 9 billion object references in it, that won't work!"

Re:Not easiest to read, but forgiving...

[Anonymous Coward]

C# is like a cleaned-up, easy-mode Java. It's really difficult to not know what you're doing if you actually paid attention in your 101-level programming courses in college.

C# delegates are just, in C terms, typedef'ed function pointer prototypes. Now, C doesn't really have those. But you know what a prototype is, you know what a function pointer is, and you know what typedef-ing does. Now combine these ideas. "This is a name for a specific format of a function pointer that I'm going to use over and over later." Due to the C++ influence, it also has an object protection level specified.

The format is: {protection level} delegate {return type} {typedef name} ({parameter list});
Example: public delegate int Foo(int a, int b);

Now, when you want to use one (for a callback, probably), you simply accept a parameter of your delegate type. (Example: void DoSomethingAndCallAFoo(int blah, int blah2, Foo callback))

And to provide that delegate, you would write a function in a class somewhere that has the same signature as the delegate, then pass it as the argument to DoSomethingAndCallAFoo. So, if you had a function named Bar that matches the Foo delegate's signature, you could call DoSomethingAndCallAFoo(blah, blah2, Bar); or optionally, you could make it slightly more obvious what's going on by calling DoSomethingAndCallAFoo(blah, blah2, new Foo(Bar));.

As for events, they're just function pointer lists that only(*) accept pointers to delegates with an expected signature: public delegate void Whatever(object sender, EventArgs e). (EventArgs is covariant, so derived EventArgs can be passed in as well.) Those pointers-to-delegates-with-an-expected-signature are called event handlers. The EventHandler generic handles all of this for you. Declaring a member event as public event EventHandler ShitHappened; will accept the Whatever delegate above (and you don't even have to declare the delegate, since the signature-matching happens anyway at compile-time). All that's needed now is a dispatcher function, typically named On{event name} (in this case, OnShitHappened), and accepting only the appropriate EventArgs as a parameter. It should check for a non-null event pointer list, and call the event handler with a this-pointer and the event args parameter it was supplied with.

You shouldn't really have tricky memory leaks to watch out for unless you're doing threaded stuff (due to the way thread memory allocation works, you can abandon a thread in a messy way and leave a bunch of un-GC-able stuff lying around that won't get cleaned up until the process goes away). Just using delegates and events shouldn't cause any trouble.

(*) "only", if you're sane. You can force events to use non-standard delegate signatures, but you're an idiot if you do. Nobody will be able to maintain your code. Not even your 6-months-future self. Especially if I'm your boss and catch you using that unmaintainable crap, because your 6-months-future self won't be working near me or that code anymore.

Re:Not easiest to read, but forgiving...

[jareth-0205]

A problem with Java and C# is that it is possible to create memory leaks in those languages, but since people rely so much on garbage collection they don't think about it and get bit in the ass. Event handlers shared across processes are particularly dangerous.

I mean, yes, you can't get away with not knowing anything at all about memory management in Java, but singling out edge cases that are a problem vs the vast majority of cases where it's superior is sort of missing the point. Rather like saying that wearing shoes is a problem because you sometimes get a stone in them, far better that you should always go bare feet and constantly make sure you don't step on anything sharp.

Re:Not easiest to read, but forgiving...

[invid]

I was just saying it was a problem. As it just so happens I'm plugging up someone else's memory leaks right now in a C# program. I worked in C and C++ for decades, so I love garbage collection. Just because I point out a problem doesn't mean I want to dump Java or C#.

Re:Not easiest to read, but forgiving...

[nitehawk214]

I had a spherical reference once...

Re:Not easiest to read, but forgiving...

[Anonymous Coward]

Yeah, but in Java/C# if you have a leak it might take days for the program to consume all the RAM and make the system run sluggish. Whereas in C/C++ since there is no bounds protection, you get random crashes and buffer overruns exploits every minute of every day.

Re:Not easiest to read, but forgiving...

[FranTaylor]

Otherwise nice looking software that functions until the memory leaks cause it to crash.

if you approach java with the concept that it does not suffer from memory leaks, you're just deluding yourself.

Re:Not easiest to read, but forgiving...

[pr0fessor]

I don't have a problem with it but we can't assume that everyone took 101 programing that was c because that just isn't the case those in their 30s or 40s probably did.

Re:Not easiest to read, but forgiving...

[shutdown -p now]

Ironically, you have actually got a few things wrong here.

First of all, delegates are not just function pointers. They're bound method pointers, meaning that they can capture the receiver of the call in addition to the method itself. This makes it possible to create a delegate to an instance method, which is not something you can do with function pointers alone in C++ (there, you need to define a data structure that combines the function pointer with the object pointers; or use something like mem_fn or bind that'll do it for you).

More importantly, when you say that "events are just function pointer lists", this is actually what delegates are, rather than events. Given your definition of Foo, for example, it is possible to say:

Foo f = ...
Foo g = ...
Foo h = f + g; // look, a delegate that references two different methods!

In the most common case, at least when passing them around as arguments, a delegate object will refer to a single method. But it can refer to arbitrarily many methods of different objects, and it's still denoted by the same delegate type. The rules defining what happens when you invoke such a delegate are not obvious (in particular, with respect to return values and out/ref parameters) - order matters, for example, and so do repeated inclusions of the same method (i.e. it's not a set, it's an ordered list).

(In theory, it is possible to have delegate types that are not lists, if you define them as inheriting from Delegate rather than MulticastDelegate on IL level - this is legal per CLI spec. But no .NET language that I know of provides the ability to define such types in practice, so you'd need to use something like ilasm.)

Events, on the other hand, are an entirely different concept altogether. The most crucial difference between an event and a delegate is that event does not define a type, nor is it an object. An event is simply a pattern of two accessor methods - one to add an event handler (represented as a delegate), the other to remove a handler - formalized on language level. When you write something like:

public event EventHandler ShitHappened;

what it does is define two methods named add_ShitHappened and remove_ShitHappened, both taking an argument of type EventHandler. Because you didn't specify the implementation of those methods, it will also automatically generate them as if you wrote it like this:

private EventHandler ShitHappened;
public event EventHandler ShitHappened {
add { ShitHappened += value; }
remove { ShitHappened -= value; }
}

(In practice it actually uses atomic operations to ensure that handlers can be registered concurrently from different threads without one overwriting the other, but I've omitted that for the sake of simplicity. For single-threaded case, the above code is equivalent.)

You can't actually write it like that yourself, because it's not legal to have the same name for the field and the event - but for automatically generated accessors it is legal, and distinguishing between them depends on the context where it's done. If you're referencing ShitHappened from the same class, then you're accessing the field. If you're accessing it outside the class, you're accessing the event.

Either way, the important part is that, regardless of whether the event has implicitly defined accessors or not, users of the class only see the add/remove accessors, and do not have access to the backing storage. This means that they cannot, for example, raise the event from the outside, or enumerate the list of subscribers and directly invoke some of them, or remove a delegate from that list that they haven't themselves added (or obtained from elsewhere, which is why it's a good idea to make all event handlers private).

And that is the so

Re:Not easiest to read, but forgiving...

[DrVxD]

+1 - YOMANK

C++ Template Syntax

[glennrrr]

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.

Re:C++ Template Syntax

[Anonymous Coward]

The syntax isn't what makes C++ templates hard. They're hard because they're templates.

However, they're powerful because of it. There's no "generics meta programming" because generics don't offer any sort of comparable power. That said, the reason template meta programming is so useful is because C++ lacks reflection.

Re:C++ Template Syntax

[shutdown -p now]

Generics can absolutely offer comparable power. The extremely limited versions of generics that exist in e.g. Java and C# do not do so, but if you just add structural typing to them, you can get the same expressive power as C++ templates.

Re:C++ Template Syntax

[rdnetto]

The syntax isn't what makes C++ templates hard. They're hard because they're templates.

However, they're powerful because of it. There's no "generics meta programming" because generics don't offer any sort of comparable power. That said, the reason template meta programming is so useful is because C++ lacks reflection.

I disagree. Take a look at D templates (and compile-time function evaluation) - that syntax will be easily readable to anyone familiar with a C family language, because it's the same syntax (just with 'static' or 'pure' peppered everywhere).

C++ template meta-programming is hard for two reasons. The first is that templates use a syntax of their own, which is one more thing to learn. The second is that the template language is functional, which is quite alien to most C++ programmers. D uses native D syntax to do the same thing (with the requirement that functions be pure), and that's much easier to read.

Stability

[Anonymous Coward]

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"...

Re:Stability

[DickBreath]

Not only do you have to re-learn basic elements every decade, you might have to rewrite very old code to work on current systems.

The people who make these incompatible changes vastly underestimate the cost of such incompatibilities.

The sheer amount of working Java code is not only why the language will stay around for a long time, but economically represents a very large amount of wealth.

Re:Stability

[drerwk]

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"...

No kidding - especially the socket libraries that let me write network code in the later 90s that would work on Sun, Mac, Windows, and Linux. Getting cross platform network code to work in C at that time was quite painful. And I don't recall any C++ libraries that I found pleasant to use before boost, and now Qt. And even now, while I consider boost essential, it's really only pleasant in the same way as no longer having to get your braces tightened qualifies as pleasant.

Re:Stability

[_xeno_]

Hell, I've run into Java code that only runs on 32-bit versions of Java.

I'm not sure how they did that, but it absolutely requires you to have 32-bit Java 6 prior to a certain patch level.

Thankfully the part of IT demanding we run that software eventually caved to the part of IT demanding that the software running on every computer was, y'know, not full of security holes.

Verbosity is easy?

[DJ Rubbie]

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.

Re:Verbosity is easy?

[Anonymous Coward]

Your mindset is exactly what causes problems with other languages. What you expect isn't readability but a higher power density. If you push this too far, you get too much implicit functionality, and that makes code difficult to read, because you can no longer understand what's going on if you're not familiar with all the idioms.

There are fundamental differences between a stream and a string (hence the existence of separate classes), so something has to give if you want to use a stream where a string is expected. If you make this implicit, then someone who doesn't know the semantics first has to realize that there is something implicit going on, and probably look up what it is, while in Java the conversion is explicit. Java isn't "surprising".

Re:Verbosity is easy?

[Daniel Hoffmann]

Well, this implicit functionality is rather useful, that is why you see libraries like Apache IOUtils (like IOUtils.reafLine()) that bring some of that magic back. But the fact that you can go to the lower level is a good thing, I just wish the Java designers had these kind of utilities backed into the core of the language.

Re:Verbosity is easy?

[bwwatr]

I agree with this guy. Java forces you to acknowledge and address subtle differences between different types of objects. Yes, sometimes code is overly verbose, but overly compact code that does a lot of "magic" for you, is far worse. I unfortunately work in PHP a lot, and you can pretty much treat any value as any type and usually get away with it, until you suddenly don't. Strong typing and an IDE that whacks you with a stick every time you forget it, is far preferable, even if your code is a few lines longer.

Re:Verbosity is easy?

[Pastis]

> I mean intuitively shouldn't toString() on a stream get back a string?

Yes it should return a String (enforced by polymorphism) but not the String you imply.

From the API

Returns a string representation of the object. In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read.

So your String should be a description of the InputStream, not its contents.

For example: "InputStream for URL: http://google.com/" or whatever satisfies the concise informative representation that is easy for a person to read.

Re:Verbosity is easy?

[TheSunborn]

Why would you expect toString() to work on a InputStream?

There is no general safe way to create a String from an InputStream, because mapping from a byte stream(Which is what a InputStream is) to a string is not 1:1.

That is: The same string can be encoded as different bytes, depending on the encoding such as UTF-8, UTF-16 iso-8859-1).

The funny thing is that Sun did not think about this when they first created Java, so there are a bunch of deprecated methods which create strings from bytes, trying to guess the encoding or reading in from the systems default locale.

Re:Verbosity is easy?

[a_claudiu]

A Stream is not a String. A Stream is a pipe which can serve you bytes as soon as some of them available.
If the InputStream.toString() will give you the full content of the stream you will have some very nasty errors. Eg. A beginner wants to read a file using a stream and is doing a toString() suddenly all the file will be loaded into memory into a big String eating all the memory. Another beginner listens to a tcp port using a stream does a toString() and suddenly the thread hangs until the client closes the channel. Plus you need a reader on top of the stream to have proper String encoding. Stream is for binary Reader is for strings.

“I find it extremely annoying to have to cast things into the right object type” This is by design, Java is strongly typed. If you find yourself casting too much then is something wrong with your code style or the library that you are using.

Re:Verbosity is easy?

[Giant Electronic Bra]

So, what you want is a horribly type-unsafe mess which presupposes a specific type of encoding of the string (Yay ASCII or die!). Instead what you have is a robust type-safe mechanism where you can make it clear in code that you are decoding a string, or accepting a serialized Java object over HTTP if that was what you wanted to do. What you call 'excessive verbosity' I call "Computers are stupid, always tell them explicitly exactly what to do because if you leave it up to them, they'll fuck it up." and that philosophy means the line-of-business code I write is phenomenally reliable and often sails right through major changes in external factors without any problem because it was correctly written on day one. YOUR code OTOH blindly jammed binary data through some unknown default binary-to-text conversion, and when you want to make it work correctly? Now you have to write some hokey nonsense to defeat default incorrectness. That's all fine for the time when you want to write a one-off screen scraper to grab some data and you have one hour to do it. I've written a LOT of perl, but don't mistake Java's strengths for weakness.

Re:Verbosity is easy?

[quietwalker]

Agreed.

The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.

With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.

Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.

Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.

I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing. .. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?

Re:Verbosity is easy?

[phantomfive]

A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc,

lol it fascinates me how common this problem is (and why always choose factory?). And then you half your code is converting from one object type to another.

Re:Verbosity is easy?

[multimediavt]

.. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?

Nope, you're there. Welcome to the club. Now, get off my lawn!

Re:Verbosity is easy?

[quietwalker]

You may know the quote: "Premature optimization is the root of all evil," but the whole quote in context explains why it is so:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth

In fact, it takes an experienced eye to know when and where to optimize, to identify that critical 3%. In the meanwhile, novices are so worried they'll miss it that they try to overoptimize everything, not having the experience of maintaining programs written in that way.

So when you see that sort of pattern abuse, especially naming classes after patterns, like -Facade, -Decorator, -Adapter, -Mediator, (and -Mixin depending on the language) realize that what you're dealing with is a novice's code, written by an amateur with no clear understanding of the entirety of their job, and adjust your expectations accordingly.

Re:Verbosity is easy?

[Twinbee]

A future programming language would simply assume UTF-8 from the start, and not worry about trying to support the other encodings. Such a language would have a lot less bloat attached to it.

Readability is crucial for new languages

[Anonymous Coward]

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.

Re:Readability is crucial for new languages

[DickBreath]

Readability goes along with 'toolability'. The fact that tools can 'understand' Java code and therefore can correctly make so many kinds of automated changes to the source code is a major sign of readability. If it is not possible to make tools that can do precise and sophisticated manipulations of the source code, then chances are that humans cannot understand it easily.

As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.

Re:Readability is crucial for new languages

[Anonymous Coward]

Your comment about renaming a variable is entirely an IDE function. An IDE for any language could be designed to allow for variable renaming in this fashion. If a compiler can understand the code enough to compile it, an IDE can be written that also understands the code to the same level. The difficulty of writing such an IDE might vary between languages, but there's no reason it wouldn't be possible for any language that uses variables.

Re:Readability is crucial for new languages

[DickBreath]

Yes, it is a function of the IDE. But the language itself has something to do with why this was easy enough to implement for Java that it was done long ago and not just recently. I'm sure that even for the Java language it is not easy to implement. But the language is statically typed. You cannot reference members via strings (like in JavaScript). The meaning of an identifier does not depend on anything that happened at runtime prior to that identifier being used. It is possible to statically analyze the code easily without so much research into what might affect the meaning of the code you're looking at. No operator overloading (that also affects readability, or ability to abuse things).

If it aint broke dont fix it

[Billly Gates]

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

Yeah right. Then explain COBOL.

[gatkinso]

That's what I thought.

It was purely serendipity, and now the install base is so large you can;t get rid of it.

It's not that great

[BECoole]

I could sure do without the { }.

Re:It's not that great

[Hognoxious]

Would you rather have begin/nigeb or something dumb like that?

Re:It's not that great

[dunkelfalke]

What exactly makes curly brackets inherently not dumb? They are non-indicative and typing them on many keyboard layouts that are not en-US is quite uncomfortable.

Re:It's not that great

[Hognoxious]

What exactly makes curly brackets inherently not dumb?

Nothing. Why do you ask?

They are non-indicative

They're indicative of the start and end of a block.

typing them on many keyboard layouts that are not en-US is quite uncomfortable.

Doctor, when I do this with my arm, it hurts.

Re:It's not that great

[nitehawk214]

Let me guess, you and GGP write Python? Starting out in C, I can't get my head around any language that doesn't have a bracket system.

I am not saying you can't do dumb things with {}. (I am not sure what the term for the brace style is called.) In fact it makes it easier to do dumb things in some instances. But it also lets you do one liner things to make the code more readable. (such as the parenteticals in this paragraph (of course sometimes they make it harder to read such as this one))

What do you suggest as an alternative?

Re:It's not that great

[Rockoon]

Personally I like {}'s
Its the ;'s that I could do without.

I actually think VB got this one almost right, with linebreaks separating statements, but has both an operator (:) to separate statements within a line when thats advantageous, as well as an operator (_) to continue statements onto the next line when thats advantageous.

Its really easy to write a bunch of C-style code and miss a semicolon. Its really hard to write a bunch of VB code and miss a linebreak, or have an erroneous line continuation or line separator. One of these is obviously better overall.

Re:It's not that great

[shutdown -p now]

Virtually anything; for example, "begin" and "end" as in Pascal; or implicit beginning of the block and "end" as in Lua; or parentheses in languages that don't distinguish between expressions and statements, like OCaml (OCaml additionally defines "begin" and "end" as aliases of "(" and ")", though).

Re:It's not that great

[Twinbee]

That's a problem with those keyboards then. If had my own way, I'd have a single press key for the curly braces, or perhaps move to square brackets instead.

Re:It's not that great

[tepples]

typing them on many keyboard layouts that are not en-US is quite uncomfortable.

Doctor, when I do this with my arm, it hurts.

Rapidly switching back and forth between en-US and the keyboard layout for your native language can be uncomfortable as well. "Doctor, the contortions that I have to make between doing this with my arm and doing that with my arm hurt. I am required to do both for my job."

Re:It's not that great

[Hognoxious]

Stop looking for a heavier screwdriver. Use a hammer.

For the benefit of any self-identifying "makers", I mean right tool, right job.

Re:It's not that great

[Hognoxious]

Virtually anything; for example, "begin" and "end" as in Pascal

Why would you type 8 characters instead of 2?

But at least they're actual words, which means you're likely to type them correctly. Unlike esac.

Re:It's not that great

[shutdown -p now]

I'm not necessarily saying that begin..end is better, just that it's an obvious alternative. Personally, I don't mind {}, though I think that it's really redundant, and the proper way is to treat everything as an expression, in which case semicolon becomes a sequence operator (i.e. "a;b" means "evaluate a, then throw the result away and evaluate b" - like comma in C), and you just use parens to group things where needed.

Re:It's not that great

[swilver]

The semi-colon's mean I can split up a long line of code in nicely lined up parts with just the enter key. Without them, I might be changing what the code does, or I'd need to fix all the parts and add somekind of continue operator.

The fact that those semi-colon's are there is one of those things that makes Java more readable. I don't have to guess that a line will be continued or not (see Javascript). Making it optional just serves to confuse future readers of the code - that's why Java makes these mandatory. You can leave them out, but then you're code means something else.

This and the fact that Java often only gives you one option to write something is exactly what makes the language so readable. Try explaining that though to the Scala / Groovy / Clojure / Hip++ crowd however... they seem convinced that the number of keystrokes it what dictates development speed... perhaps I should sell them Dvorak keyboards...

Re:It's not that great

[tepples]

Then let me rephrase: What's the right tool for entering both native language text and program code?

Sure, easy to read

[ememisya]

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?

Re:Sure, easy to read

[DickBreath]

You'd think that the industrial strength JVM might also have something to do with it.

You can have a JVM with a heap of tens of Gigabytes and with a modestly tuned (not extremely tuned) configuration, have Garbage Collection times in the tens of milliseconds. If you need hundreds of Gigabytes in your heap, Azul can sell you a JVM that can do this with GC pauses of about 10 ms.

The JVM dynamically compiles the bytecode down to native code. Not like a C compiler does ahead of time. But it compiles it for the actual processor and features that your hardware has. The JVM compiler aggressively inlines methods instead of making function calls. So there is no drawback to writing lots of small methods. Even tiny methods like getters and setters. You can dynamically reload a class binary at runtime. But what if the new class has a new implementation of a method that some other foobar method had inlined by the compiler? No problem. The JVM knows this and it de-optimizes the class that had the foobar method so that it no longer has inlined a 'stale' version of the code in the class that was just now dynamically reloaded. If dynamic profiling reveals that the foobar method truly is a hotspot for the cpu, then the JVM will again compile it to native code -- based on the now current conditions of what code is in the overall system. It's like having a global -O 5 optimizer that can dynamically change / recompile any or every thing based on any code changes dynamically made to the running system. Want to change from a carburetor to caffeine injection while driving down the road at 70 mph? No problem.

Call me when a dynamic language or other system can do that.

Is it any wonder that so many languages other than Java also run on the JVM? The JVM might even stick around longer than the Java language.

The JVM and Java run on the smallest systems to big iron. The SIM card in your phone is a tiny self contained secure tamper proof computer -- running Java. It verifies certificates using a private key that was forged inside the SIM and never leaves the SIM. Your Blue Ray player runs Java. You can write a Java program that provides the 'menu interface' for your disk. Old flip phones from 2000 run Java.

Easy to read?

[AchilleTalon]

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.

Re:Easy to read?

[Dog-Cow]

If you confuse easy to read with easy to understand, you aren't a skilled programmer.

Re:Corollary: It's difficult to be "clever" in Jav

[DickBreath]

final T up = (T) throwable;
throw up;

You must be joking

[joseph90]

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.

Re: You must be joking

[Anonymous Coward]

Your Java code reads a line, and parses It as an integer. Without knowing the details, i still understand that it will fail on the input "1abc".

Your pascal code, on the other hand, happily reads the number 1 and moves along.

Re:You must be joking

[Anonymous Coward]

I think you prove the author's point. Where the fuck is your pascal snippet reading from? How does it abstract bytes to characters? Why is there only an input with no output? Is `read` taking an integer and doing something with it? How is data getting out? In the java snippet, everything is laid out. You're reading from standard in. You're line buffering (with default encoding, but that's fine when reading from STDIN and not a file. Usually). You're reading exactly 1 line, then parsing that line for an int value. It's extremely explicit what's going on and has no magic. The whole passing in an outvalue thing that C and Pascal do is an AWFUL KLUDGE OF A DESIGN. It makes code harder to read and harder to understand.

Re:You must be joking

[DickBreath]

Pascal would be 1970's.

The read() function (and writeln()) are not even functions. They are built ins in the compiler. Sure, they compile to calls in the pascal runtime library. But you cannot control where read/write go to except through implementation specific tricks, if at all. In Java there is no behind the scenes magic.

Every part of the operation, the I/O, the parsing, the byte to character conversion (using what char encoding?) is explicit. And all these small pieces can be wired together in infinite ways. You get access to all the small nuts and bolts. In Pascal you don't get access to what ever integer parser that was used by read().

I'm not saying there is anything wrong with Pascal. I loved it for a dozen years covering the 1980's and into the 1990's.

In Java you can in just two or three lines of code make your own simple to use read() function using the basic parts.

Re:You must be joking

[Giant Electronic Bra]

int number = Integer.parseInt(System.in.readLine());

Re:You must be joking

[Ksevio]

In Pascal (1960's) you could just do something like: integer number; read(number);

Unless they changed it in the past 30 years, I believe you'd have to do:
number : integer;
read(number);

Re:You must be joking

[shutdown -p now]

Where the fuck is your pascal snippet reading from?

From the standard input. Which is called "standard" for that exact reason.

How does it abstract bytes to characters?

By using the default conversion that is appropriate for the current locale (note that this is actually implicit in the Java code, as well).

Why is there only an input with no output?

What a stupid question. Because for the purpose of this discussion, we're talking about reading an integer, and nothing more.

Is `read` taking an integer and doing something with it?

Probably the sole valid complaint here. Though the notion of output parameters is not exactly obscure, it's nice when they're spelled out as such at call site, and not just when defined. For example, as in C#: read(out x).

The whole passing in an outvalue thing that C and Pascal do is an AWFUL KLUDGE OF A DESIGN.

Not really, it's just a way to tell the function what type to read. Since you've already explicitly spelled out that type when declaring the variable, there's no reason to repeat it again when reading into that variable. DRY and all that.

Re:You must be joking

[shutdown -p now]

It seems that OP is confusing Algol-60 with Pascal.

Re:You must be joking

[maestroX]

Where the fuck is your pascal snippet reading from?

It's reading from System.in, whatever that is. You'll need to guess or look read() up. Once. After that, you'll know when and how to use it.
You see, because in these Pascal times, there was no IDE with auto completion or snippet compiler (Lambert's ABC was one of the earlier).
After years away from Java, I don't remember or guess to use both InputStreamReader and BufferedReader,
because it's simply anal.
Besides that, there aren't many languages that encourage red tape and overengineering like Java does.

Re:Yeah right. Then explain COBOL.

[Greyfox]

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.

Libraries tools and 3rd party, oh my !

[Anonymous Coward]

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...

Really?

[CaptainDork]

Most of the cost of maintaining any body of code over time is in maintenance ...

obvious much?

[l3v1]

"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.

Re:obvious much?

[tobiasly]

No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.

I thought the same thing when I first read that, but then again we're talking about an architect for the language that brought us "Foo foo = new Foo();" so a bit of redundancy is to be expected ;)

Re:Corollary: It's difficult to be "clever" in Jav

[subanark]

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.

Re:Yeah right. Then explain COBOL.

[DickBreath]

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.

Re:Corollary: It's difficult to be "clever" in Jav

[asylumx]

Yes -- You have to be clever about being clever.

I think it's really ugly

[necronom426]

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.

Re:I think it's really ugly

[PPH]

Not as hideous as curly brackets.

Be careful what you wish for. You could end up with Python.

Re:I think it's really ugly

[Xest]

I see this sort of mindset a lot, but it's illustrative of short sightedness.

If you can't understand the importance of namespaces and structures, then you can't have worked on anything but the most trivial and small of codebases utilising little or no external libraries. If all you know are CS101 examples then sure, having to declare namespaces, methods, and so forth might look relatively bad.

If however you work on anything that actually matters then methods, namespaces and so forth become kind of important.

I don't see how endif is superior to }. Why would I want to type more than I have to to convey the exact same meaning? Curly brackets are meant to be jarring and to stand out, they do that to tell you a block has ended.

Re:I think it's really ugly

[shutdown -p now]

Thing is, there's no reason to have a class for the program (that doesn't actually ever have any instances), and for main to be a static method of the class. That class is completely unnecessary scaffolding, that exists solely because the designers of the language wanted to "simplify" by saying that everything is a method in a class. Every Java application has the same "public static void main" line in it, exactly identical to any other such line. That is a clear indicator that it is superfluous.

In practice, this has an opposite effect for pedagogical purposes, since you have to either explain all those things before getting to something as simple as "Hello, world", or else just handwave them away by saying something along the lines of "you just always type this exact same thing when you want to do this; we'll go over what it actually means later".

In contrast, take something like Python. It does have namespaces, and classes, and objects (and indeed, unlike Java, in Python "everything is an object" is actually true!). But you don't have to know any of that to write or understand "Hello, world", because it also allows for global functions, and for code outside of functions, and it automatically imports the builtins namespace with the most frequently used functions that are useful to get started. So you can explain the basic concepts like variables, conditionals and loops to people first, and then gradually introduce them to procedural programming with functions (and locals and recursion), and then to OOP with classes, and to code structuring with namespaces. And at all levels in this progression, the new skills learned are purely additive - once you learn classes, you can do classes, but things that make more sense as global functions still remain global functions.

It's also nice for app development because you can use the most basic instruments that are necessary for the task at hand. If you're writing a simple console app that reads input, processes it, and spits the result out, you probably don't need any classes, and the language doesn't force you to write any just because.

Re:I think it's really ugly

[Xest]

So what's the alternative? I don't see how having code lumped arbitrarily somewhere, with no clear indication that it's the application entry point is better either.

There needs to be some indication in a project that that's where the program starts, else what happens when you have say 3 or 4 lumps of code in separate files in the project all lumped in the global namespace, where does it start?

It also makes it explicit that there even is a starting point, as opposed to it being, say, a library with no application entry point.

I fully get what you're saying about making things easier for beginners to spew out code, but for a multi-purpose language it also needs to support maintainability too. I'm not even convinced that making it easy for new developers to get used to bad practice even helps them that much. I remember when I learnt C as my first language, I became dependent at the start on the global namespace because that's how the tutorials said it was easy to get started. It took a while to break out of that awful habit, and start writing actual good code. God only knows I've seen others fall into that trap - I had the misfortune of temporarily maintaining a massive VBA based application whilst simultaneously throwing it away to replace it with something that was actually not shit. Everything was a global variable, the list of globals went on for page after page. It was brutal.

Long story short, I'm not convinced that making it easier for beginners to fall right into bad practices is in any way superior to making them learn a bit of boiler plate to keep things structured from the outset. I agree the syntax can be cleaned up and improved a bit, but I don't agree that it's pointless, or that writing straight into the global namespace in an unstructured manner is superior.

Re:I think it's really ugly

[shutdown -p now]

There needs to be some indication in a project that that's where the program starts, else what happens when you have say 3 or 4 lumps of code in separate files in the project all lumped in the global namespace, where does it start?

In case of Java, there's no clear indication where the code starts, either. Any class that has a static method called "main" can be the entry point, which is why you have to provide the name of the class to Java when starting your program. It's not any different in Python - you provide the name of the startup script, and the code that is in that script on the top level is your entry point, starting with the very first line of it. This seems a very straightforward definition to me: when you tell it to run X, it starts to run X from the beginning of X.

BTW, note that there is a difference here between "outside of the class" and "global namespace". There's really no such thing as "global namespace" in Python - every .py file is implicitly a package with its own namespace. If you want to access something from another package, you have to import it and reference things using their fully qualified names (or import those specific things).

I fully get what you're saying about making things easier for beginners to spew out code, but for a multi-purpose language it also needs to support maintainability too. I'm not even convinced that making it easy for new developers to get used to bad practice even helps them that much. I remember when I learnt C as my first language, I became dependent at the start on the global namespace because that's how the tutorials said it was easy to get started. It took a while to break out of that awful habit, and start writing actual good code. God only knows I've seen others fall into that trap - I had the misfortune of temporarily maintaining a massive VBA based application whilst simultaneously throwing it away to replace it with something that was actually not shit. Everything was a global variable, the list of globals went on for page after page. It was brutal.

And Java approach to forcing everything into a class doesn't really do anything to solve that, it just makes it long winded, because now all those globals are statics in some class called "Utility" or some such.

Fundamentally, some kind of global variables is plainly necessary, which is why Java offers them in a thinly veiled form as statics. It's semantically not different from globals at all, except that it forces you to spell out a prefix (class name) every time. And no, it's not there for namespacing purposes, because Java already has packages for that. Static classes just add another useless layer that is kinda sorta like packages but not really.

Consider something like math functions or constants like pi. In Java, these are put into the Math class. Why? That class never has any instance of it created. A proper design would be to put them into something like java.math package, and the only reason why they're in a class instead is because a package cannot directly contain methods and fields. So that restriction is directly contrary to good API design here, and necessitates hacks like introducing a class that is functionally a package for all effective purposes (but still different syntactically, both when defining it and when using it), and the users are forced to write Math.abs, Math.PI etc for no good reason. Later on, because of the verbosity and the disparity, they've added "import static", which is basically another hack - it makes static classes look even more like packages, and finally lets API clients write "abs" and "PI" without qualification, but many differences still remain.

IMO, the proper approach here is rather to educate people as to why global shared state (regardless of its lexical scope) is usually not the right thing for large applications, excepting certain things such as common constants and utility functions.

And, of course, for many small applications (command-

Re:I think it's really ugly

[shutdown -p now]

If you read my post, you'll see that it specifically calls out "import static", and why it's not really good enough.

In the real world you leave under such conditions

[lommetennis]

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.

Re:Corollary: It's difficult to be "clever" in Jav

[jellomizer]

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.

Re:What is Java...

[EmeraldBot]

But a more convoluted, heavy weight Scheme? If we adopted Lisp 20 years ago the world would be a better place.

#1. Java is nothing like Scheme, it's a fundamentally different language.

#2. Scheme is a Lisp, so if Java were a heavy weight one, we would have a widely adopted Lisp.

#3. Why would having Lisp being a widely adopted "make the world a better place"? Does it donate to charity?

And frankly, I personally consider the Lisps to be heavily overrated to begin with.

python white space

[goombah99]

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).

Re:python white space

[praxis]

Not too many Python programmers use an IDE, though.

Re:python white space

[iwbcman]

Pythons inane whitespace conventions make it impossible to simply copy and paste python code. Now for a seasoned python programmer this is a nobrainer, but for beginners, people trying to learn python it is critical. I grew up reading computing magazines and typing in code reprinted in the magazines, later I would copy and paste code bits from webpages/blogs etc. in various languages to try to learn how they work. Yet with python this simply does not work until you have already mastered it's conventions, one bloody misplaced whitespace and the code becomes worthless, unless you already know how it works. Python, from my perspective, would be the last language I would try to use to help people learn to code. I get that its powerful. I get how much you can do with so little code. I can appreciate what you are saying about whitespace in python helping with readability.

Re:python white space

[narcc]

Then I realized how easy it was to read other people programs.

I find it it frustrating. It's unnecessarily difficult to tell where various blocks begin and end, particularly when two or more nested blocks end together.

On top of that, the myth that python is inherently easy to read has lead to some ridiculously illegible python code. I cringe every time I need to deal with anything written in python.

Re:python white space

[penguinoid]

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.

So what? Just set up your programming environment to replace all braces and semicolons to the appropriate whitespace instead.

Re:python white space

[strikethree]

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.

Ever looked at the source for Anaconda, Redhat's installing program? Go ahead, take a moment...

Yeah... about Python being easy to read...

Re:python white space

[goombah99]

yes everyone gets burned by that one time. then it's a non-issue.

Re:python white space

[goombah99]

What about "other peoples code" did you not understand. I'm not talking about reading my own code.

Re:python white space

[penguinoid]

It's just a display thing -- you could set up other people's code to display with whitespace instead of braces and semicolons.

Re:Yeah right. Then explain COBOL.

[gatkinso]

serendipity
serndipd/
noun
the occurrence and development of events by chance in a happy or beneficial way.

The COBOL argument

[pigiron]

"It's Easy To Read"

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."

Re:Umm... the fat lady is singing

[DickBreath]

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.

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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.

Yes, and that's why lambdas are a bad idea

[bradley13]

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.

Re:Yes, and that's why lambdas are a bad idea

[Anonymous Coward]

They're just trying to keep up with C#.

Lambdas in C# are just a shortcut to writing a delegate, which is a "safe" function pointer. I'm pretty certain that Java uses lambdas in a similar fashion.

So think of lambdas as function pointers and treat them accordingly. If you don't need function pointers, don't use lambdas.

Re:Yes, and that's why lambdas are a bad idea

[FranTaylor]

Java is not functional, so lambdas break the paradigm.

Java is NOT not-functional. You have been able to mimic most of the behavior of lambda expressions with anonymous classes for quite some time now. You can most certainly code up functional programs in java if you want to.

Re:Yes, and that's why lambdas are a bad idea

[shutdown -p now]

Lambdas are cryptic in the same way classes are cryptic: it's an unfamiliar concept to many people because they haven't met them yet, but it's also a very powerful concept that makes it possible to write neat, concise and readable code when learned. C# developers were similarly bitching when lambdas were introduced there in 2008, but by now everyone uses them and loves them.

The notion of distinct paradigms is bullshit, anyway. There's no reason why OOP and FP (and other stuff) cannot coexist in the same language.

Re:Well, duh

[DickBreath]

I think you are not understanding the insight behind the maintenance remark.

Tools that work on the Java source code can be exact in what they do. No ambiguity exists. A method call foo() is understood by the compiler to be exactly one certain method. It doesn't matter how many other foo() declarations there are, or that there may also be variables and classes named 'foo'. The tooling makes maintenance tasks like refactoring very easy.

If I am reading some dynamic languages, I might have to do some searching or research to determine exactly what is being called by this foo() function call. Java tools can tell you exactly, prior to compile time, what method is being called -- and that it is declared, and where it is. The tooling doesn't get confused no matter how badly the code might be structured.

Maintenance becomes a big factor on a huge code base. The cost of maintenance can truly dwarf the cost of initial development.

Java is better...

[SpaceCommander]

...says its maintainer. Story at 11. This is bollox.

hand holding and hand forcing

[ezdiy]

obligatory webcomic to explain difference between hand holding (implicit) and hand forcing(explicit)

Dumb Slashdotters

[bigsexyjoe]

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.

Re:Dumb Slashdotters

[__aaclcg7560]

The article does not say people will be using Java in 1,0000 years.

I recently got a new nVidia Geforce 720 video card. The back of the box promised that the video card had a 40 year lifespan for office applications or a 12 year lifespan for video games. The physical electronics may have a 12 to 40 year lifespan. The moment that the newest version of Windows doesn't have a driver, the video card is obsolete and tossed into the trash. This is why I got this new card, as a half-dozen older video cards in my junk box didn't have a Windows 8.1 driver.

I doubt any programming language will last a 1,000 years. A century maybe. But not ten times that.

Re:Dumb Slashdotters

[__aaclcg7560]

I had a Nvidia GeForce 6200, Nvidia Quadro 3400, ATI Radeon 3850 and a few others that were probably AGP. The ATI Radeon 7960 was my newest card out of the bunch when it died from a dead fan. I had to install the Windows Vista driver file to get the ATI Radeon 3000-series motherboard graphics to work under Window 8.1.

Re:Dumb Slashdotters

[H725_IT]

... he is talking about one year, with for zeros after the decimal separator... I'm sure java will still be used then. (in Italy we use , as decimal separator)

The reason is : Corporate buy-in.

[quietwalker]

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.

Re:The reason is : Corporate buy-in.

[FranTaylor]

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.

okay you probably weren't around in the 1960s and 1970s but FORTRAN and COBOL had all of those things back then.

Re:The reason is : Corporate buy-in.

[quietwalker]

That may explain why it's still around even after it's been technologically eclipsed, in a similar vein to Java.

They're not around because they're easy to read or the choice language or any other criteria that would make sense to a developer, but rather because there was a corporate investiture. Money spent means more to a business than other metrics.

Laughable

[theendlessnow]

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.

Re:Laughable

[FranTaylor]

have a ton of easily overlooked side effects. Debugging can be a nightmare.

you're clearly not very famliar with java, it was expressly designed with the intent of not having "easily overlooked side effects"

perhaps you might be able to tell us what some of those "side effects" are?

Re:Corollary: It's difficult to be "clever" in Jav

[firewrought]

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.

BASIC and COBOL are easy too

[ruir]

Honestly,I have seen many, and this one about been readable must be the more strange argument I have seen lately.

Seen enterprise software?

[ThePhilips]

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.

Re:Seen enterprise software?

[FranTaylor]

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.

do you have any actual basis for your comparison? do you have any enterprise-level applications written in any other language that you can compare to?

Re:Seen enterprise software?

[ThePhilips]

Yes. Billing systems.

In a way, the experience is a confirmation of the RTFA. When newhires come, everybody is in the awe of the Java part, and everybody is terrified of the C/C++ part. But the thing is, a year later most change their opinion. Java might look beautiful - but the beauty is skin deep. We have had clients changing project design and architecture because developers were throwing in a white flag: they simply couldn't fix something in the Java part, and the workaround had to be put somewhere else.

With the C/C++, the usual problems tend to keep the development down to the ground. While with the Java, developers very often succumb to the fancy of implementing all the fancy things people on the internet are so fancy about. Like for example the good design practices. No, no, no - only the best design practices! Because that's how it supposed to be!! End result are the huge monstrosities, which are more compliant with the programming books than with the customer requirements.

The saddest part is that good Java pros are acutely aware of the problem. But one can't just swim against the tide.

Re:Corollary: It's difficult to be "clever" in Jav

[Waffle Iron]

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.

Re:Yeah right. Then explain COBOL.

[medv4380]

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.

Inertia?

[snookiex]

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.

Easy to read != easy to understand

[hcs_$reboot]

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 ..........

Java vs. C# amuses me

[msobkow]

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.

Re:Java vs. C# amuses me

[ndykman]

Well, there's some differences that do make C# seem easier and less clunky. They are similar, but not identical, and their differences do matter.

Properties. Yes, Java has getters and setters, but those are methods. C# makes the distinction between a property and method. To be fair, this doesn't really come up until you deal with reflection and more advanced cases, but it is a useful distinction to make.

Generics. Java has type erasure, which has it's issues (you can't do T newThing = default(T) in Java). If look at the lambdas, there's a lot of stuff they have to do around typing to handle primitives versus objects, etc. C# just has a Func and Action types. For APIs that use higher-order functions, this makes things a bit clearer (I want a function that takes a string and returns a bool, for example). Compare this to things like mapToInt in the streams API, and C# is just more consistent and natural in this area.

LINQ. True, Java 8 streams add a lot of this, but they don't expression tree support, which makes things like LINQ to Entities and LINQ to XML, etc. possible. Granted, LINQ has it's own issues (LINQ to Entities code can fire runtime exceptions that LINQ to Objects won't), but this power is really useful. And it requires language and compiler support to transform a lambda to a expression tree versus a closure.

Async/Await. Now, this is newer, but this is a huge difference between C# and Java. Non-blocking code is great, but it can quickly turn into a nest of callback functions. Sure, promises help, but that's a chain of objects. Async/Await provides a much easier to use model that provides many of the benefits of asynchronous programming, but keeping a more synchronous like code base. Scala, JavaScript are all adopting this model because it works well.

In practice, it can be very useful. I was working on ASP .Net MVC 4 project. I bumped it up to five and some improvements. I then just used the asynchronous APIs in MVC, etc. It was a fairly simple change, but boom, less CPU usage and more overhead for concurrent connections. A noticeable gain for little price.

Finally, the libraries do diverge beyond the core. Entity Framework and Hibernate are different. WPF couldn't be more different than Swing, etc, really. Java doesn't have a standard library like Windows Workflow Foundation. And there are Java libraries that C# doesn't really have, of course.

While I agree that Java can get too bad of a reputation, it does show it's age. Also, the JSR process has grind to almost a complete standstill. When C++ gets lambdas before Java, it shows just how slow the process has become.

I think C# embraces newer features much more readily, and that's why some really advocate for it.

Re:Java vs. C# amuses me

[msobkow]

I must admit it's been a few years since I last used C#, and I've yet to shift from Java 7 to Java 8. Both have moved forward.

But at the point I was heavily using both, they were more alike than different. At that point, LINQ had just come out so no one was using it for production systems yet.

Re:Java vs. C# amuses me

[shutdown -p now]

Up until C# 3.5 (when lambdas and LINQ first showed up), C# really wasn't all that different from Java; though it already had non-erased generics, which, I think, are a huge benefit if you use them heavily. It was really 3.5+ that started adding new and very distinct features at a fast pace.

By the way, one thing that GP forgot about (possibly because it's not really used all that much) is "dynamic", which is basically opt-in duck typing.

Re:Java vs. C# amuses me

[ndykman]

Oh, forgot about anonymous types, but Java has anonymous classes which work similarly. And I forgot about the yield syntax. And there's new stuff coming in 6.0.

And I totally agree with the parent.

Re:Java vs. C# amuses me

[shutdown -p now]

Java anon classes aren't quite the same because of the lack of "var" or similar - so you can implement interface members or override base class members, but you cannot introduce new members that can then be referenced outside of that object.

OTOH, C# anon classes don't support base types...

Corollary 2: It's difficult do anything in Java

[Anonymous Coward]

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.

Yeah... it's a pretty genius tautology.

[tlambert]

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.

I hate python

[wonkavader]

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.

Two obvious reasons

[Kohlrabi82]

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.

Just plain wrong

[wonkavader]

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.

Re:Yes & the sheer amount of existing code/fra

[jeremyp]

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.

Is this supposed to be a joke?

[NynexNinja]

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.

Re:Is this supposed to be a joke?

[ADRA]

I beg to disagree. I don't know what your dev env is, but any ORM will cause dynamic table / column labels. This isn't a bad thing. This means you don't spend countless hours hand sculpting selects/updates.

ORM Advantages:
  - Considerably faster to write and maintain queries / persistence
  - Significantly less code / DB coupling
  - Makes DB refactors easier to handle (depends on how much you leverage static DB-metamodels but that's another discussion)
  - Eager/lazy fetching makes foreign relations stupidly easy, like legitimately night and day
ORM Disadvantage:
  - Often less efficient because its harder to pull in subsets of a table row vs. just fetching full rows (though totally doable, people generally don't bother)
  - Depending on the SQL abstraction, you can get some bad JOIN's if you don't know the gotcha (but these are generally poorly constructed large queries, but they do require debugging to fix)
  - Eager/lazy fetching can cause SIGNIFICANT poor performance if you aren't aware of what your queries / related code are doing

If you want to know what's being pushed into the DB, put in breakpoints into the ORM layer or add persistence listeners to trace what's being stored / when (then turn it off for prod). If you're using raw JDBC, you don't have no excuse for traceability. Your problem isn't in the language, its about your ignorance about the framework / libraries your project is using.

Plus, at least with Hibernate, it'd use bind variables, not poor performing literals unless your code itself is being written with native SQL queries in JDBC. The one thing not trivially easy in most ORM's is DB-side batch updates. I generally hand code my SQL in those cases, but it can be done.

Don't blame a language for the mistakes of the developer. Don't blame the language for 'selecting bad developers'. Blame underperforming developers for underperforming, or blame management for not managing / training / filtering them very well.

Re:It's time to round up the Muslims

[HornWumpus]

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.

Easy to read, simple language?

[nitehawk214]

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.

Re:Easy to read, simple language?

[shutdown -p now]

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.

C# went through this in 2008. It's still around, and practice has shown the fears to be unfounded. Lambdas are heavily used in idiomatic C# today, and many libraries (e.g. ASP.NET MVC) rely heavily on them, and it didn't really have any detrimental effect on code quality.

Re:Yes & the sheer amount of existing code/fra

[Gansan]

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."

Re:Yeah right. Then explain COBOL.

[ADRA]

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).

Re:Yes & the sheer amount of existing code/fra

[Parker Lewis]

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.

Re:Yeah right. Then explain COBOL.

[phantomfive]

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.

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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.

Re:Corollary: It's difficult to be "clever" in Jav

[nitehawk214]

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.

Re: In the real world you leave under such conditi

[Billly Gates]

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

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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:

items = [1, 15, 27, 3, 54]
result = filter (<10) items

Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:

items = [1, 15, 27, 3, 54]
result = [item for item in items if item < 10]

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...

python is not easy to read...

[FranTaylor]

...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.

If that is true, OO-COBOL wil rule you all.

[140Mandak262Jamuna]

COBOL was designed to have readability as an end goal, more than even performance. Those days there were countless stories of computer wizards stealing fractions of pennies per transaction and committing million dollar frauds. It was designed to have "functional analysts" who define the business rules, laws to be obeyed and regulations to comply with and the "technical analysts" who will supervise the coding teams. The aim was for the legal and financial expert to read the code and approve.

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.

Re:Yes & the sheer amount of existing code/fra

[helixcode123]

I strongly agree with the parent. My favorite language implements this in a similar way to the parent's favorite:

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 :-) 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.

Re:Corollary: It's difficult to be "clever" in Jav

[Ksevio]

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.

Re:Yes & the sheer amount of existing code/fra

[AuMatar]

Totally disagree. If I see

for(int i: items) {
  if(i<10){
    results.add(i);
  }
}

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.

All code should be readable.

[plopez]

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.

Re:Corollary: It's difficult to be "clever" in Jav

[Kartu]

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).

Re:Yes & the sheer amount of existing code/fra

[skids]

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.

Re:Yes & the sheer amount of existing code/fra

[diamondmagic]

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?

Re:Yes & the sheer amount of existing code/fra

[wues]

Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand.

Are you saying that

256 * 2 = 512

is harder to understand than

two hundred fifty six multiplied by two is five hundred twelve

Re:Yes & the sheer amount of existing code/fra

[Darinbob]

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.

Re:Yes & the sheer amount of existing code/fra

[AuMatar]

No, it comes down to explicitness is always better than explicitness. There is no case in which yours is better, or even usable code.

Re:Corollary: It's difficult to be "clever" in Jav

[DickBreath]

For C users:

#define while if // makes code faster
#define struct union // makes data use less memory

Re:Yes & the sheer amount of existing code/fra

[Pfhorrest]

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]".

Re:Yes & the sheer amount of existing code/fra

[mattventura]

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.

Re:Yes & the sheer amount of existing code/fra

[cheesybagel]

He's probably a COBOL programmer.

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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.

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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.

Re: Yes & the sheer amount of existing code/fr

[mattventura]

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.

Hardly

[vilanye]

It was designed for the mediocre programmer and that is what enterprises hire.

debugging

[senatorpjt]

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.

Re:debugging

[ThePhilips]

Each statement does so little [...]

Also true for the assemblers.

[...] that it is very easy to step through code in a debugger and pinpoint the place that something has gone wrong.

Except that it might take days or weeks to step through all of it.

Except that it theoretically might take even months, if you need to debug problem related to some framework.

[...] Java is exceptionally easy to debug.

It's not. Unless it is relatively small and independent application. But in that case, literally every language is easy to debug. Even C.

Re: Yes & the sheer amount of existing code/fr

[shutdown -p now]

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.

Re:Yes & the sheer amount of existing code/fra

[shutdown -p now]

You're awfully confident about your subjective judgments. I don't see anything non-explicit about his code, and it's perfectly usable.

Re:Yes & the sheer amount of existing code/fra

[undefinedreference]

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.

Re:Well, duh

[undefinedreference]

Only very small programs have less time invested in development than maintenance. Most code has at least 10 times more invested in maintenance than the initial development.

There was an idiom the escapes me that one of my professors used to use (this was almost 20 years ago) that succinctly explained this. It has been well documented for at least 40 years now. Write programs with the realization that they will need to be maintained for perhaps decades on end, because if the code and company are successful, it will be.

Re:No, it fails compilation.

[ttucker]

Whooosh... the code example is in C/C++, not Java.

Re:Yes & the sheer amount of existing code/fra

[Twinbee]

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.

Re:Yes & the sheer amount of existing code/fra

[Twinbee]

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.

Re:Yes & the sheer amount of existing code/fra

[Twinbee]

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?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Cross-platform support is also important

[Shirley Marquez]

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.

Re:Yes & the sheer amount of existing code/fra

[surd1618]

http://stackoverflow.com/a/122...
Quote about filters in Java from this link:

Filter in place or into another collection?

Haskell programmers are crying.

Re:Yeah right. Then explain COBOL.

[Toshito]

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.

Re: Yes & the sheer amount of existing code/f

[shutdown -p now]

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?

Standard input is often redirected

[tepples]

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.

Variable type, name, and constructor should differ

[tepples]

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 dysfunctional

[tepples]

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.

JavaScript

[tepples]

#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.

Re:Yeah right. Then explain COBOL.

[Toshito]

colon? I meant the period!

Sorry for my poor english.

Clear code: Cultural background

[DrYak]

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.
The only language your cat can write legal code in just by walking across the keyboard. :-D

(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.)

Re:Clear code: Cultural background

[DuckDodgers]

C mathematical operator syntax is probably more intuitive for a mathematician or even just someone that completed high school math classes. But the other syntax for pointers and dereferencing pointers, arrays, and curly braces for code blocks is probably still unintuitive, even if you have a mathematician. They would probably still go from "complete novice" to halfway between beginner and intermediate faster with Basic or Python than with C.

I can't speak for Fortran, I've only ever looked at a few snippets of it. As for Haskell - I think Haskell syntax is still puzzling. Yes, the function definitions are mathematical and the case matching mechanism for defining function paths is brilliant and elegant, but until you understand what it means, it looks bizarre.

Re:Yes & the sheer amount of existing code/fra

[swilver]

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)

Re:Yes & the sheer amount of existing code/fra

[Anonymous Brave Guy]

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.

Re:Yes & the sheer amount of existing code/fra

[Bugamn]

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.

Re:Yes & the sheer amount of existing code/fra

[Bugamn]

Depends on how the language does comments. I think it wouldn't work on either Perl or Haskell.

I must not be human

[MoarSauce123]

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.

Whicpaintbrush should I use to drill a hole?

[Hognoxious]

Your poor reading comprehension is perhaps the root of your confusion. I didn't say anything about a tool for all jobs.

Explaining my thought processes: which tools?

[tepples]

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?

Re:Explaining my thought processes: which tools?

[Hognoxious]

The original invention is in doubt, but typewriters first became mainstream in the US. They were designed for English. When they were adapted for other languages with more characters and/or squiggles, dots and the like something had to give because, due to economies of scale, the number of keys couldn't be changed. That something was the less common punctuation marks.

Unix, C and the like came from the US. They naturally make use of characters that are easy to type on a US keyboard.

Seems to me the job design is wrong. It's like complaining that it takes time to get changed when switching twice an hour between cleaning operating theatres and shovelling pigshit. Maybe you could go back in time and lobby for spelling reform in whatever godforsaken babble you mumble in.

For me, I set a UK keyboard to Welsh on the occasions where I've needed to add French or German texts to a program.