41–50 of 156 posts
A cleaner/simpler alternative was Kobalt, but it’s now abandoned. A simple, official build tool would make the ecosystem easier to learn.
Earlier quoted context omitted.
C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.
It's not optimising for Hello World. It's optimising for a new student's learning experience, so that concepts can be introduced in a more reasonable order.
And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated.
Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.
I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…
You can't really mock static methods though, so it makes testing harder.
I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…
Recently I tried another take on the same idea: using default methods in Interfaces. It has nice properties, as it enables ~mixins in a way not dissimilar to what Scala provides, and enables overriding (e.g. for tests). Give it a try, it's ... refreshing :)
Earlier quoted context omitted.
You can't really mock static methods though, so it makes testing harder.
Static methods should be treated like functions. Same input same output. Keep them small. If you find yourself needing to mock them they are doing too much.
Small nitpick :p
Earlier quoted context omitted.
You can't really mock static methods though, so it makes testing harder.
Static methods should be treated like functions. Same input same output. Keep them small. If you find yourself needing to mock them they are doing too much.
I wonder - why he has not take it a step further and propose to get rid of return type (void) also? It would look even more slick (add optional semicolons and we will get javascript out of this :)). main() { println("Hello World"); } I know that this notation is traditionally reserved for constructors but I'm not 100% sure why we cannot differentiate between methods and constructors just by looking at class name?
I see very little gain for quite a high price here. It would break the grammar quite a bit, potentially causing even breaking changes, for something that is usually not absent even in languages that do strong type inference. The proposed changes don’t have these negatives, while still provide benefits.
And i do not buy your argument that it will break the grammar, the parser of javac consider constructors as methods.
I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…
You can't really mock static methods though, so it makes testing harder.
Earlier quoted context omitted.
Static methods should be treated like functions. Same input same output. Keep them small. If you find yourself needing to mock them they are doing too much.
That will only work when your functions don't have side effects. So no database access, no network calls etc. You could work around that by passing in your database client as parameter but when you have a DAO class with lots of functions this quickly becomes tedious.
> I write functions using ‘static’ all the time. I prefer that a function be static.
This, however, does not mean that all the functions should be static. IMHO, the more static stuff you can extract from your instance methods while keeping parameters count to max 3 (magic number that works for me), the better.