Ask HN: Why don't languages such as Java support json-like object literals? | Hacker News Reader

Ask HN: Why don't languages such as Java support json-like object literals?

11 pointsrajnathani14 comments

Note: This is a sort of a technical question which I'd ideally like to ask on stack overflow, however if asked there the question might be closed due to being too broad (upon my inference of programming language design questions of similar nature asked in the past).

Why don't GC languages such as Java support json-like object literals? (For reference check out the code snippet on this stack overflow question: https://stackoverflow.com/questions/34727831/create-a-json-literal-in-java-without-need-for-existing-class)

My conclusion is that the processing would be solely at the parsing stage and not at the runtime stage of the program, so there shouldn't be any conspicuous perf hit in including this feature.

Note that this is all assuming that the programmer would in any case use the type Object to be agnostic of types specified within their json-like object even if they didn't have access to an object literal.

Are there some unforeseen issues (perf and non-perf related) to accommodating such object literals?

FYI this question is not just about Java, but extends to other GC languages (such as Golang, etc).

Why should it? Is it really a good idea or perhaps you've done loads of Javascript, considers it an important feature and would like to see it there?

I've had this a few times with other programming languages, why doesn't it have guard clauses like erlang, or macros, or X and Y?

I think the reason is that the people who maintain a language got already plenty of work and you try hard to avoid 'Feature creep', meanwhile still satisfying most of the people who uses it(or not...).

You could as well implement the feature yourself, see if people like it.

But just as you've mentioned Java, I have to tell you something. Java took like a decade to implement lambdas(or more). They need to reach consensus, agree a lot of things. Implementing things is easy, agreeing is hard. Most of programming languages got a lot of people with very different interests.

There is a performance hit on having this feature in the compiling phase. It's yet another feature they will need to support. The work to handle this is a huuuge language such as java is absolutely huge, again, not so coding wise, but also the whole ecosystem. People would even have to update their books...

Like if I had a programming language, I would never implement what you said. I don't find it a nice feature.

> already have plenty of work and try hard to avoid 'Feature creep'

It seems a basic thing though. Like String and Number and Array literals (these are also Objects in JavaScript).

I think the answer is more likely to be age and stagnation.

Object literals would be weird in Java. My guess is that they would probably be implemented as essentially calling a no argument constructor and then a bunch of setSomeVar functions. Overall the no arg constructor and a bunch of setter functions often isn't a good pattern in Java in my experience

There are many other "basic things", for example maps and sets, regular expressions, XML... I am sure others could add more examples... trying to support everything by special syntax would indeed be feature creep.

Well yeah, finding patterns in text, and unique lists are pretty common too. It's not special syntax, it's batteries included.

C# has features close to this, property initialiser syntax [1] and dynamic object literals [2].

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[2] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

In type-checked languages, object literals are fairly obtuse because an object literal is an anonymous class with only one instantiation point. For example, suppose you have syntax to create an anonymous class like this:

    { x: 123, y: 456, z: 789 }

What type would it have and what would you do with it? The only use for it would be to upcast it to Object. You're better of using Map classes instead. One can then wonder why Java doesn't have Map literals. The reason for that is inertia. When Java was designed in the early 90's maps and sets weren't thought of to be as useful as arrays in everyday programming.

There are two solutions to this:

1. Take the type definition from the point of use, not the declaration. For example, if the object literal is being assigned to a variable, its type is the type of the variable. If it's being passed to a function, its type is (a subtype of) the type of the function parameter. If it's being returned, it's the return type of the current function. C/C++ and Kotlin do this, as does Scala (I think; I don't know the language well).

2. Use structural subtyping. In the type system, allow the possibility of expressing "HasField x && HasField y && HasField z". Then the type of the object literal is simply an anonymous type that includes those predicates. Ocaml and (I think) Go do this.

Ah, you're right in case the syntax is for instantiating objects of existing classes/structs. My take was that the OP wanted the object literals to be able to create new types. In Javascript, var a = { x: 123, y: 456 } is meaningful without a prior class declaration.

It's just syntax suger, no? A dictionary from string keys to objects, which could be arrays or dictionaries or primitive types.

Will the JSON be still used in 30 years later? The answer is maybe. We don't know.

For a programming language like Java which is used in really serious places like banks, medical equipment, and all systems which last more than 30 years from now on, it can't remove the feature once added because it break the existing code.

So the it's reasonable for the Java to be conservative at adding a feature just because it's trending right now.

Pretty sure you can do it in Groovy, which integrates very well with Java, if you need that.

Java is a pretty rigid and verbose language in general.

Common Lisp supports almost any literal, because you can reprogram the reader on the fly, and there are many types of reader "macros" available to the Lisp user. It's awesome.

Java was one of these Ivory tower languages created at a big corporation, Sun Microsystems. Not unlike Go is today with Google. They will never add obvious features because of corporate bureacracy. And, adding a feature is admitting the language is not perfect. Usually it takes several decades after the language creators are long gone to add obvious features. There is no issue with literal a, just dogma. They are evaluated at compile time in Java, so how could there be perf issues. Most people use something other than Java to get list, map, an set literals.

Reply on news.ycombinator.com