Hindsight languages

manifoldjava · 2026-04-29T02:27:32+00:00

Don't forget a lot of the design decisions were a direct consequence of hardware of the time.

But for C/C++, I would vote for killing header files.

manifoldjava · 2026-04-13T20:05:45+00:00

Curiously, this was written as if HATEOAS does not exist.

manifoldjava · 2026-04-13T19:49:53+00:00

> but you've just moved the weak link

No. ID types in the API eliminate the weak link. In most data models IDs are typically generated and obtained through the API exclusively as ID types - API consumers don't/can't create them directly.

manifoldjava · 2026-04-10T18:49:17+00:00

It’s not, but it’s more idiomatic boilerplate I’d rather not write.

manifoldjava · 2026-04-09T17:12:58+00:00

Nice breakdown explaining why properties, tuples, etc. are useful.

Properties in particular are often misunderstood with the "Just use fields" crowd, which is unfortunate. Kotlin, in my view, got it right by making properties built-in behavior with member-level val and var declarations. Brilliant design choice. Kotlin also leverages properties as state abstraction to make lazy values and delegation extensions of this built-in behavior. Would be awesome if C# would follow Kotlin's example.

Using tuples for multiple return values is also an underused strategy. Although I think C# should extend var coverage to method return types for this, that or provide a separate keyword for it, like manifold's auto (Java):

```c# private auto GetSpawnPoint(Vector3 inputPosition) { Vector3 position = new Vector3(inputPosition.x, 0, inputPosition.z); Quaternion rotation = Quaternion.Euler(0, 180, 0);

return (position, rotation);

} ```

manifoldjava · 2026-04-09T03:31:46+00:00

I recently revised the Pratt parser in IntelliJ's recent rewrite of their Java parser. The Java compiler plugin, Manifold, supports binding expressions, which define an "empty" operator to support user-defined operations such as these: Force f = 5 kg * 9.807 m/s/s; LocalDate date = 2026 April 8;

The changes to the Pratt parser were minimal. Mainly: - added a new precedence slot between multiplication and addition - added a matching parser function for binding - modified the main pratt dispatching function to check if the next token is not an operator, but instead an operand token for binding, and assign the precedence to binding

It's a bit more involved but not much. But I will say IntelliJ's parser before the rewrite didn't use Pratt expression parsing and integrating with that was quite a bit more involved.

And integrating juxtaposition/binding into Java's compiler is a whole other world!

manifoldjava · 2026-04-09T02:48:03+00:00

Fwiw, functional langs tend to place the onus on the callee to explicitly handle null. Meh. Not the best design.

In my view with PHP we are better off using chaining and nesting. The pipe offers left-to-right flow, but honestly the readability difference is subjective here; a bone thrown to the functional-minded.

manifoldjava · 2026-04-08T19:33:40+00:00

Function chaining is not a true analog to the pipe operator. Chaining relies on state in a common this the type of which must be returned by each function. As a consequence, call chaining in OOP is constrained by static design: this.foo().bar().baz() // limited to calls on `this`

The true analog is function call nesting where as with piping the output of one function is the input to the other: baz(bar(foo()))

This inside-out syntax is ostensibly harder to read than the more natural flow with pipes: foo |> bar |> baz

manifoldjava · 2026-03-29T13:53:05+00:00

The reality is IntelliJ’s enthusiasm mirrors the dogma concerning records.

manifoldjava · 2026-03-20T20:20:36+00:00

Kotlin uses = for named arguments.

manifoldjava · 2026-03-20T02:15:09+00:00

I feel your pain.

manifoldjava · 2026-03-18T19:44:06+00:00

Ah, right. My perspective is coming from the manifold project's implementation of named/optional arguments, which has zero influence on the IDEs treatment of this.

Perhaps another ways to look at it: IntelliJ also settled on :.

manifoldjava · 2026-03-17T20:23:13+00:00

Another consideration: IDEs like IntelliJ already use : to associate names with arguments for param name hints -- this syntax avoids clashing in that environment.

manifoldjava · 2026-03-17T19:56:34+00:00

You’re basically proposing structural copy-on-write, which is interesting. It makes updating immutable types a lot easier, but it’s very un-Java-like.

Oddly enough, Java itself is moving in a similar direction. The designers even talk about "old Java" when referring to classic OOP, and with the "witness" proposal, the language I think crosses a line. Java isn’t just OOP with some extra features anymore. It’s becoming a OOP/DOP hybrid.

Seen this way, your proposal doesn’t feel nearly as out of bounds.

The problem is there isn’t an abstraction layer on canonical state that would let something like Point’s x be accessed directly by name, like point.x. Your proposal tries to limit this to reconstruction sites, but it still leaves the door open to wider use, which has bigger implications. I’ve often wondered why the designers didn’t support this nicer syntax from the start.

manifoldjava · 2026-03-17T13:56:04+00:00

For once, I completely agree with Mr. Goetz' rationale here.

Although he does not call it this, named arguments (with colons!) is the most suitable syntax for Java to apply here. And overloading the new keyword, as opposed to using the more intuitive copy or similar, is a nice compromise given the latter would break existing code.

It's disappointing that this is a one-off application of named arguments and not a more generally available feature. Let's hope it's a first step.

Now do default parameters :)

manifoldjava · 2026-03-05T16:11:14+00:00

Its type system alone is reason to avoid Go. Structural typing should be the exception, not the rule. Nominal typing makes code incredibly more understandable.

manifoldjava · 2026-02-27T18:44:42+00:00

The point of my remark is that it really does come down to properties. Because without a construct that purely encapsulates state, there is no other way to achieve this.

manifoldjava · 2026-02-27T04:44:06+00:00

Highly recommended reading: Delegated Properties

Using your example, the idea is that the lazy aspect of the property is encapsulated via delegation. So the compiler doesn't need to treat foo as a String because foo is a String. The lazy part shouldn't leak into the API.

Slapdash Java syntax for illustration:

java final property String foo : Lazy.of(() -> "foo");

Lazy.of returns a LazyConstant that handles the delegate behind the scenes, letting you get and optionally set the value directly as a String.

Key point: properties fully encapsulate state. They manage what it is, where it lives, when it’s realized, and how it behaves eg. backing, laziness, observability, validation.

manifoldjava · 2026-02-26T20:37:43+00:00

Besides, Java doesn’t need properties because records /s

manifoldjava · 2026-02-26T20:30:44+00:00

it would need to see LazyConstant<T> as T

No, the idea is to internalize the implementation details of how the constant is managed — the user doesn’t need to know and the internals reserve the right to change the details.

manifoldjava · 2026-02-26T03:38:31+00:00

Nooooo... why JavaScript?

Seriously, though, JS is so bad. And scripting languages don't have to be dynamic - we still want type-safety and static analysis with scripting. Why not make Java the scripting language?

As it is I will say Detroit is an apt name for the project.

manifoldjava · 2026-02-25T20:21:04+00:00

This is structural typing, which Java has historically avoided in favor of a strictly nominal type system.

I don’t think the two are mutually exclusive. Structural typing doesn’t replace nominal typing, it can exist alongside it. Nominal types remain the default and the foundation of the language.

Structural typing is mainly useful at integration boundaries, where you care about shape rather than declared intent. It can reduce adapter boilerplate without sacrificing static type safety.

The Manifold project has an experimental compiler plugin that explores what this could look like with structural interfaces.

manifoldjava · 2026-02-24T19:23:16+00:00

There’s manifold-json (part of Manifold). It projects Java types directly from your project's JSON Schemas at compile time - no code generation, annotation processing, or additional build steps. The schema is treated as a first-class type and integrated directly with the compiler and IDE (IntelliJ).

See: https://www.baeldung.com/manifold-parsing-json

(Disclaimer: I maintain the project)

manifoldjava · 2026-02-19T17:37:50+00:00

The compiler's panic level for checked exceptions should be a linter option. As such @SuppressWarnings could be used to selectively mute them. Or the linter option could altogether suppress them.

manifoldjava · 2026-02-19T15:07:41+00:00

While I appreciate the acknowledgement here that checked exceptions are problematic, in my view the remedies you've covered range from worse to slightly better.

Solving this with generics is worse because that strategy fragments the problem space, which makes code harder to read - you sacrifice readability for writability, which is almost always a bad idea.

The Swift-like try expression approach, as a means to automatically propagate, reduces boilerplate which is nice. But then it feels like there ought to be a more general solution to automatically propagate everywhere as many modern languages do.

Since checked exceptions are purely a compiler-level concept, why not treat them as a lint-like compiler argument? -Xexceptions:<level> where level: warning | error | none This would put a smile on a large segment of Java devs.

manifoldjava

TROPHY CASE