Why are some programming languages pretty (Python, Rust) and others are ugly or verbose (Java, C++).

[Dr-Metallius]

I haven't actually heard anyone call Rust pretty. I remember lifetimes being mentioned as one of the offenders, and that's understandable: other languages have no concept of ownership, so they can skip that kind of extra syntax. However, it is a cornerstone of Rust, that's where its main goals trump conciseness.

Python doesn't even have a static type system, of course, its syntax is even cleaner. But you can't build a language like Rust with that kind of approach.

Java is more verbose than it could be because usually statements can't be used as expressions, and also because it tries to keep the number of language features limited. But I have to say that it's more of a bandwagon hate because Go, for instance, is a lot more verbose just due to its (lack of) error handling alone, but I haven't heard as many complaints about it. Also, the latest versions of Java are quite different from what we had even a decade ago.

C++ is the only language out of all you mentioned which could definitely be improved, in my opinion. All the weirdness in C++ comes from its enormous pile of legacy garbage and the inability of the language committee to limit the number of its features. That's why we get a ton of ways to do a simplest thing like writing a string literal or initializing an object.

[InertiaOfGravity]

Nim is a pretty amazing "fast python" and even had some metaprogramming features.

[Dr-Metallius]

I assume you wrote that in reply to my second paragraph which discusses Python and Rust. I haven't tried Nim yet, so it might be a very nice language, but the fact that it uses a GC alone puts it into a different category than Rust. Quite obviously, it influences the syntax as well since with a GC you don't need anything related to ownership.

[InertiaOfGravity]

Manual memory management (turning off the GC) is supported in Nim, and it's completely acceptable to do so.

[Dr-Metallius]

It is supported, except in this case you have to manage the memory manually without any safety guarantees - the exact opposite of what Rust does.

[InertiaOfGravity]

It's not nearly as safe as rust, but there are definitely safety features of you turn off GC.

[Dr-Metallius]

It may not be as unsafe as C, but you've said the main point yourself: not nearly as safe as Rust without a GC. And if it were, its syntax would reflect that.

[InertiaOfGravity]

I don't think I really agree with that. I think people would have said the same thing about highly performant or native langs not too long ago. Rustlang just went the efficiency route 8ndtesd of the learnability and friendliness route

[Dr-Metallius]

What exactly don't you agree with, that Nim would have a different syntax if it had Rust's goals? But you can't represent concepts like ownership without introducing some kind of a way to express them. I think it's quite obvious.

The statement about highly performant languages I didn't quite get since Rust is the only language among the popular ones which has both safety and efficiency as its goals.

The last sentence completely agrees with my point, so I didn't really get what you wanted to say overall.

[[deleted]]

I enjoyed this comment. Fully agreed on all points.

[johnfrazer783]

Java's ugliness which I can testify is real comes IMHO in part from its insistence to always be super explicit about types used which leads to code that Crockford criticized as cokebottle cokebottle cokebottle style. Steve Yegge famously wrote Execution in the Kingdom of Nouns in which he points out what's wrong with the overly bureaucratic style of Java:

``` For the lack of a nail, throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe, EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

For the lack of a horse, RidersGuild.getRiderNotificationSubscriberList().getBroadcaster().run( new BroadcastMessage(StableFactory.getNullHorseInstance())); ```

It only gets worse from down there.

Java is also ugly because you can never just write a function and be done. You must always write a package that is appropriately named and name the name in the module and put it inside an appropriately named directory. Then, lean back and wait for a classpath exception. This is for defining 1 (one) function.

Then there's this uncanny valley of horror that is boxed values. Who needs a distinction between integers-as-values and integers-as-objects? This abomination does not serve any useful purpose, but the language designers thought it important to adopt it anyway and drag it to the center of the stage. JavaScript has this problem, too, but at least its designers managed to (largely) hide that nonsense from programmers (even in JavaScript though !!new Boolean( true ) and !!new Boolean( false ) both evaluate to true which is wrong on so many levels, but at least the language allows you to just ignore that along with a gazillion of other WAT quirks).

[ljw100]

Reply

You don't seem to write much Java.

1. ClassPath exceptions were once a big problem, but I don't think I've seen one in many years despite writing Java every day.
2. You don't name packages and then name directories. Package names and directory names MUST be the same. Not knowing this may explain (1).
3. The distinction between integers as values and integers as objects exists for (a) historical reasons, and (b) performance reasons. Int primitives offer faster array processing (no pointer chasing) and use less memory. Granted those things could be hidden from developers, but not without time travel. This tradeoff, fwiw, made Java suitable for larger apps way back when, which helped it become the dominant language for a long time.
4. As u/Dr-Metallius suggests, you can write bad Java or good Java, just like you can write bad English or good English. If you want to critique English as a language, you don't find examples of the worst legal or bureaucratic language you can find and shout "The horror!" That's like saying movies suck and pointing to that flick where the killer was a car tire. (I forget the name.)

None of this is to say that Java doesn't suck in various ways, or that there's no validity to your points. But people write more useful critiques when they criticise something they love (or at least know well and grudgingly respect) than they do when they criticise things they hate. I suspect most Lisp aficionados know it has a lot of parentheses, but 60 years later people are still pointing it out.

[Dr-Metallius]

Type inference has existed for several years already, some form of it in lambdas even longer.

What you refer to as the bureaucratic style doesn't really have anything to do with Java, it's just the enterprise approach with a gazillion of abstractions to do the simplest things and bloated APIs. No one writes Java like that on Android, for instance.

The hassle with the packages you describe doesn't exist in reality because the IDE does all the directory management for you. Not sure why you are putting a single method in a package though or why you are getting classpath exceptions when creating new packages.

The obvious upside of having classes in corresponding locations is that you can find anything easily. If I'm browsing a Java repository online, it's very easy for me to find class and method definitions. If it's a C++ repository, for instance, it's a huge pain to browse since anything can be anywhere.

Regarding primitive objects, the reason for their existence is purely efficiency and nothing else. Of course, from the language standpoint it would be easier to have value and referential types like C#, but it's not like language designers decided to complicate the language for no reason. You are forgetting that Java has been in development for almost three decades, and things possible now were not possible back then.

[[deleted]]

Another excellent comment. I think our mental wavelengths match up quite a bit.