Is it my imagination, or has there been an upswing of interest in F# on HN recently?
My sense is that the root cause of a lot of it is missing features in the Java language itself. There are a lot of cases where in C# I'd have used an extension method, or been able to lean more heavily on generic programming or Expression<T>, but, since Java has no good equivalents of these things, instead I have to break out a design pattern to accomplish the same task.
And, once you've cracked that seal, it's sort of an, "In for a penny, in for a pound," type situation. Next thing I know, I'm neck deep in it, and I don't even know how I got there.
It's true that, in a single dispatch language, I sometimes need to use the visitor pattern. And the visitor pattern is a little bit annoying to implement, it's true. But the implication of that Norvig quote is that every single language should implement multiple dispatch, and I simply cannot agree with that. And I suspect that a lot of people who like to invoke that sentiment would not prove to have the courage of their convictions when presented with a situation where Haskell needs a design pattern (sorry, "idiom") in order to work around the fact that it doesn't have dynamic dispatch at all, multiple or otherwise.
In general, it's OK for languages to be small and focused, or even to be large and multiparadigm but still draw the line at adding some features. That's not my criticism of Java. My criticism of Java is more along the lines of, Java's a kitchen sink language, and there's nothing wrong (aside from perhaps aesthetics) with being a kitchen sink language, but there are other kitchen sink languages that did a better job of cramming more random crap in more cleanly.
The interest has always been consistent, it's just not vocal.
I haven't run into any real problems as a result but it does make me nervous.
There are those who would argue that making an incompatibility between the database schema and the code that interacts with it a compile-time error instead of a run-time error is a huge win for software quality.
I suppose there are situations where you simply can't have access to a database that mimics the structure of the production database during development. In which case, the SQL provider is definitely not the right tool for the job. But it might be worth looking into ways to change how you do things in order to make it the right tool for the job. A SQL database with an unpredictable schema makes me much more nervous.
That's why you don't normally compile against the production database. You version control the database schema and use it to create a local database to compile against. This way you can also test potential future migrations using branches.
Compiling against the production database should be done separately, as a kind of free integration test (usually in CI).
Looks like somewhat of an increase but a very spiky baseline.
https://hn-trends.eliot-jones.com/Home/Trend?id=f%23&allword...