Manifold: Java typesafe metaprogramming with IDE support by abusing the compiler | Hacker News Reader

Manifold: Java typesafe metaprogramming with IDE support by abusing the compiler

manifold.systems

65 pointsgoranmoomin34 comments

Manifold is an amazing piece of technology.

It grew out of the "open type system" of Gosu:

https://guidewiredevelopment.wordpress.com/2010/11/18/gosus-...

The open type system was a simple API for adding new types to Gosu, allowing you to surface non-native types in a type safe way. A really nice way to do metaprogramming for a statically typed languge.

Unfortunately Gosu never really went anywhere as an open source langauge, and Scott moved on to exploring javac plugins that let you accomplish the same thing in java.

Amazing stuff.

I love the “properties” bit. You can get the same functionality by just defaulting the fields on your classes to public. 99% of the time, the getters and setters aren’t doing anything, just proxying the variable.

Yes, 99% they don't do anything, but the 1% of cases in which you want to add something extra, you're glad you're using properties. For example if you want to convert the data to other format/unit before returning, or to log all usages of a variable.

As long as this is your code, refactoring to introduce getters and setters if ever needed would be a cinch.

I’d rather have functions as they work quite well with method references and streams. Additionally ORMs require methods to do dirty tracking. If your class isn’t a entity pojo just use a record and get the getters for free.

Seems like Kotlin but using a preprocessor approach instead of a whole different compilation process. I wonder if that allows to use newer javac features and be better optimized than kotlin's equivalent.

YMMV but to me it seems like most Java features are better optimized than the Kotlin equivalent.

while this may seem "fun", it's not recommended for production

https://www.reddit.com/r/java/comments/q97el0/comment/hguoch...

Most of what this offers can be replicated in Java with properly set up build-time code gen plugins and Lombok (or a bunch of standard annotation processors).

The remaining operator overloading and naive C-style preprocessor are from the wish list of someone who never had to understand or maintain software using those.

Finally, reliance on Javac's internals guarantees brittleness across JDK updates. This is much more than just a plugin, it should provide it's own compiler, even if 95% would be lifted from an existing Javac implementation.

Hard pass.

Why anyone may need this? Don't we have Scala?..

At first I thought it was cool but then starting with operator overloading it basically rolled down a very steep slippery slope...

I never understand the hate operator overloading gets. Why is it collectively decided that date.plus(1, ChronoUnit.DAYS) is 100% fine and dandy, but date + ChronoUnit.day(1) would be like introducing longjmp.

I don't understand it either. It's just yet another Java limitation that better languages simply don't have and which must be constantly worked around. There's no reason why we can't have a method named + which adds the receiver to the argument. It's just a simple symbol.

  x + y
  x.+(y)

The root cause of this is the distinction between primitive and object types. Simply put, not everything is an object in Java and this causes numberless problems. One of them is the need for special syntax cases for the mathematical operators of the primitive types.

This is exactly how scala does it

Yeah. It's also how Ruby and Smalltalk do it. Lisp also does similar things. In these languages it doesn't even make sense to talk about operators. They don't exist. There are only methods, functions. General ideas represented by a few universal concepts. No special cases. Of course they can be overridden... It would have been strange if they couldn't. They're just normal methods or functions.

No special cases; apart from the special cases ;-)

Some Smalltalk methods are "compiled in-line" special —

  ifTrue: alternativeBlock
    "If the receiver is false (i.e., the condition is false), then the value is the
    false alternative, which is nil. Otherwise answer the result of evaluating
    the argument, alternativeBlock. Create an error notification if the
    receiver is nonBoolean. Execution does not actually reach here because
    the expression is compiled in-line."

    self subclassResponsibility

That's just the implementation though, isn't it? In the language proper, the method still exists. The implementation just compiles it away.

How would — "Of course they can be overridden..." — work when the method is:

  ifTrue:

Most devs probably know operator overloading from C++ and Scala, which both go way overboard with them.

Operator overloading on a limited set on operators, like in Kotlin is fine.

C#’s limits are much more reasonable than Kotlin’s. The former allows overloading comparison operators with return values other than Booleans (eg if you want to return wrapped Boolean types), the latter does not (so Kotlin EDSLs rely on eq, lt style infix operators). C# on the other hand doesn’t (or didn’t?) allow for operators to be defined via extension-type overloading.

Not that limitations are bad, Kotlin is just weird in them.

Operator overloading is great for library authors, bad for basically everyone else. What operator overloading buys you is fewer keystrokes to express a concept. For someone intimately familiar with a codebase, like a library author, this is awesome. It is a great save if you can write a + b + c instead of a.concatenate(b).concatenate(c).

However, as a regular old user, operator overloading can be a drag. Let's say you come across the expression a + b. Are a and b numbers and are you adding them? Are they strings and are you concatenating them? Are they vectors and are you appending them? As a programmer, you don't know, so when you see this expression you have to go on a fact-finding mission to figure out what's going on. For a typed language like C++ this is not so bad; you just need to look up the types of a and b. But that isn't always straightforward due to type inference.

The fact is that the symbol + has a well-defined meaning in mathematics. Operator overloading takes a very clear and well-defined symbol and turns it into a fuzzy enigma. In my opinion, it's better to have N well-defined, clear, and unique semantics for N symbols in a PL rather than having a single symbol that is overloaded for N purposes. Writing the code may take longer, but code is read more than it's written, so that doesn't seem so bad to me.

Just the same with a.concatenate(b).concatenate(c), how can you be sure what concatenate() is actually doing?

One has to go through the same analysis the function called +.

With proper cross referencing tool support it can be the same, but in the past most IDEs didn't help you finding which function would be called in case of operator overload.

>The fact is that the symbol + has a well-defined meaning in mathematics.

+ can refer to different functions in math, such as addition of integers or matrices. Hell, number and matrix multiplication are written in the same way even though one is commutative and the other isn't!

I write my algorithms in Matlab and Mathematica, no need for it in my production language. I agree with the parent that the code should be readable and operator overloading can become problematic.

D kinda fixed this issue by adding a concatenation operator ~. When you see a ~ b ~ c you know you are concatenating, not adding.

This is an argument against overloading, not just operator overloading.

This is all true, but all these argument are 98% the same for a.plus(b), which is common in widely used libraries and the Java stdlib.

So why is a.plus(b) better than a + b? What would be the problem of translating "a + b" automatically into a.plus(b) like how Kotlin does it?

Since the day when the language Java was first advertised, more than 20 years ago, these discussions about whether operator overloading is good or bad have appeared, just because the authors of Java had an aversion for operator overloading.

All the arguments that I have ever seen against operator overloading are just various ways of formulating one single argument and this argument has nothing to do either with operators or with overloading.

The argument is that some programmers are stupid and they give names that are misleading, because those names mean something else than what most people would expect them to mean.

I agree that this is true, but it happens with any kinds of names, of variables, of functions, of macros and of course also with the operator symbols when it is allowed to define functions whose names are operator symbols.

I do not agree with this kind of arguments that some people are stupid and they might do something bad with a kind of tool so let's forbid to all people the right of carrying such a tool.

In my experience, the ability to understand complex programs depends a lot on whether you can see the entire relevant part of the code on the screen simultaneously. Few people have such a good memory that they are still able to understand the code if they are forced to flip constantly through multiple pages of text.

So there are places in a program where long descriptive names can make the program easier to read and understand, but there are also programs with complicated formulas, where a compact notation makes the code much easier to read and understand.

Many years ago, about at the same time when Java was launched, I worked at a program that computed the radiated electromagnetic field for some systems. The model required a large number of custom types corresponding to various physical quantities, and most of them had values that were vectors of complex numbers.

The code contained a large number of very complicated formulas, corresponding to multidimensional integrals of various functions.

The initial version had been written in C, and the text of the program was huge and extremely difficult to read and understand.

Rewriting it in C++ with overloaded operators resulted in a dramatic reduction in size and it became possible to understand what happens in the code by just reading it.

At the same time, the Java propaganda against overloaded operators began, but obviously, after my experience, I dismissed it as misguided.

I agree that C++ is not an example of how it is best to handle operator overloading, because C++ allows the overloading of some operators for which overloading should be forbidden, because the compiler should be able to generate them for any custom type in a way that would guarantee the expected operator properties and there is no advantage in allowing the programmer to implement those operators with functions having a different behavior.

While criticizing the excesses of C++ is fine, forbidding operator overloading completely makes a programming language unsuitable for some applications.

Operator overloading is nothing new, it has always existed for the base types provided by a language, since Fortran, then it was proposed for user-defined types in 1964 by John McCarthy and then it was allowed in various languages before C++, e.g. Algol 68 or Ada.

The aversion of the Java authors against operator overloading, which was very explicit since the first Java presentations, is quite weird because it is inconsistent with the Java love for OOP.

The essence of OOP is dynamic overloading caused by inheritance, which has the potential to be much more confusing than the static overloading of operators.

If I see an "object + object" I might not know what the "+" does, but I can find by searching in the source code. When I see an "object.plus()", then the possibility that the member function does something completely different than I expect is much higher, because the actual function that is invoked will be determined only at run time.

In Typescript with VSCode just hovering over a variable shows its type and any doc comments with click-to-def. In that case, I don’t really see this being a problem.

Same here, specially since they exist since Lisp.

Personally I like the approach of Haskell: no overloading of any functions whatsoever (except in a restricted way through typeclasses), but you can define new operators yourself. That allows the certainty which comes with the absence of overloading, but also the concision which comes with using operators rather than functions. (Not that concision is everything, mind you; code gets difficult to read if there are too many custom functions. But at least the option is there.)

Not to mention that operator (and function) overloading is absolutely unavoidable when you are dealing with generics. A generic type may itself define an operator, which, of course, becomes overloaded due to its origin, or such a type may require that an operator on another, parameter type, exists and satisfies certain “axioms” (such as associativity).

I believe the Java people have done that in reaction to what was being done in c++ land. IMO operator overloading is fine when the operator is well behaved (i.e. respects some kind of law, plus should be at least a monoid etc).

Reply on news.ycombinator.com