I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs.
> Java allows null objects… that ship has sailed
Not necessarily, with project Valhalla, it should be possible to have generic Value Types in the language that would allow things like Optional to be defined on the stack where it would be non-null and then all it’s methods for checking if the Object it references would make sense, and actually work. This would be in contrast to today where the Optional type isn’t as useful as it seems since it can also be null.
I've seen many other developers trash java because of the same reasons, often citing Go as a great alternative.
The problem is, for every org I've seen, saving memory is not the goal of the program. "Making debugging harder" is subjective, and most people I've heard use this argument are taking about "magic auto configuration". Maybe this isn't intuitive at first, but the knowledge comes quickly, and from my experience the java app with unit and integration tests is far easier to debug than the Go app with less testing and less readable syntax.
The memory argument is also way less applicable when using the author's framework, because your app is built into a native image.
I know you didn't mention Go, but that's where I always see this argument headed, and it always makes me wonder whether the writers have ever had to maintain or take over an app written in Go, or if they can happily write-and-forget.
Forget the interface vs data structure (for which they provide little support), the final keyword is the horrific standout. Conspiring with the compiler to remove programmer agency, in the misguided effort to protect programmers from themselves, is ridiculous.
Reading these comments, it's strange to see that the "Java" paradigm/context issue still exists after all these years.
I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc.
And for the record it's not just Java (it just seems to be more pronounced in the Java-development ecosystem). For every person who waxes lyrical about the joy of working with C# (for example), there are 3 more that will tell you anecdotes about "assembly hell". Or how Visual Studio is slow and a massive memory hog. Or that there is no proper Forms support on XYZ-os.
Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. IMO, I think it's usually far more productive to try to understand the discussion in context than to veer off into irrelevant semantic issues or tangential anecdotes.
> Reading these comments, it's strange to see that the "Java" paradigm/context issue still exists after all these years.
> I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc.
This is something I've been saying for years.
Java, as a language, is great. But Java paradigms are fucking awful, and I don't understand why people use them. However, I'll confess that I'm naive, as I've never had to build anything larger than about 1,000 lines.
Like...one of the patterns that I absolutely despise is the "Handler". So often, code is peppered with "MyHandler handler = new MyHandler(); handler.invoke(...);". If you have an object that consists of only a constructor and a single function, and is merely instantiated, called once, and then thrown away, why is this its own object?
I see Java developers complain about stack traces that are 50+ function calls deep with half the functions in the stack named ".invoke()" or ".run()", and all I can think is how those wounds are self-inflicted.
There have been at least two mostly disconnected "Java"s for the last 15+ years. The job descriptions used to be very clear about. There were "Core Java" positions and "Enterprise Java" ones. Very different communities, different libraries (remember the revelation that the LMAX Disruptor was for example?) etc. The developers spoilt by the experience with Scala/Kotlin probably count as a third group now.
You choose weird examples. I don’t know how VS can be considered slow when it only has one real competitor - JB Rider - and that competitor offers C# support. Also, I’d there a language that competes with C# that doesn’t also have some form of “assembly hell”?
I really don't like Quarkus approach. It's full of magic. It's everything I'd love to get rid of. I'm using Spring which is kind of full of magic but I spent 15 years learning to deal with this magic, so it's bearable to me. But it does not mean that I like it.
I liked Helidon SE approach (not MP, MP is the same EE crap). It's 100% code, no magic. What I didn't like is reactive, I don't need reactive, so I don't use Helidon SE for my projects, I still endure Spring. But if someone enjoys reactive programming and wants zero-magic approach, I can recommend it.
Helidon Nima might be a saviour to me. I didn't research it yet.
I can't stand any magic, it always inevitably feels like a massive liability to me and always bites me in the ass sooner or later.
I use http://sparkjava.com in my projects. It's as tiny as web frameworks get, it only handles routing and request/response, and you get to do everything else manually. Only thing I had to hack into it was response streaming. The one most internally convoluted and enterprise-y dependency I use is, surprisingly, the official MySQL driver. GraalVM complains about it as well.
I agree with you about both magic and reactivity (meaning, IIUC, asynchronous rather than blocking APIs). Helidon Nima looks interesting.
But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1].
I'm not sure the point of Quarkus. Its an easy way to get started with GraalVM development, but pre-compiled Java isn't any use for dev work. The autoreload classes is easy in most dev environments already too.
I like SmallRye Config and I feel it's designed this way because of the problems it tries to solve. The following is an excerpt from the MicroProfile Config standard which SmallRye Config is an implementation of:
> The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged.
> The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used.
> Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for microservices running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed.
One reason we don't know whether SmallRye Config is reading from a file or querying a database at development time is because that choice has been deferred to the system administrator at deployment time.
Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure.
What are you suggesting? That one should read the documentation? And have a level of understanding why things are the way they are? Blasphemy! Zero ignorant screeds would be written! Productivity would increase 10 fold!
I agree. Java has improved as a language quite a bit in recent years. And I don't even mean that in a "Java has followed the cargo cult of what's fashionable in programming languages"-sense. I mean that things like Records to define value types have "always" been desired in Java- at least in the 10 years that I've worked with people on Java code. If Java didn't automatically make everything equatable/hashable, it would be a different story.
Anyway, Java still has baggage that I doubt will go away any time soon. My biggest two complaints with Java are that null exists outside of the type system and that they mix runtime type reflection and non-reified generics. The latter features being actually incompatible with each other makes working with Java libraries/frameworks a minefield.
But, aside from those issues, the OP is totally right that so much of Java's bad reputation comes purely from library design and culture. Even when I preferred OOP architectures, I hated the fact that so many Java libraries and frameworks required a bunch of annotations for everything, even when it really wasn't necessary. I get that Java code can be verbose, but if you don't like it, use something else- don't just throw away compile time safety and information for a janky runtime-checked "DSL" where a bunch of the features don't even actually work together (I'm mostly looking at you, JacksonXML, but also Spring, et al).
Everyone praises the Java ecosystem as some kind of selling point, but I find that while the ecosystem is indeed broad, the actual quality and productivity of many of the popular libraries and frameworks is fairly low. And by "quality", I don't necessarily mean number of open bug reports, I mostly mean that the APIs are really difficult to understand and use correctly. In some sense the devs are "off the hook" when my app doesn't work correctly because "this is documented behavior", but that makes me think I should just start writing documentation for my apps' bugs and seeing what my boss thinks... ;)
Is it just me or is understanding those examples virtually impossible if you're not intimately familiar with that particular framework? Then again... I guess that's the author's point.
The examples use CDI (dependency injection through annotations) and yes, these annotations become hardwired to the business objects... Java has some kind of traits now through interfaces so it's not much of a problem today.
This is why I left Java. Everything "looks nice" on the surface with annotations, but you loose the flexibility of code and a lot of the available tooling. Plus you need to be a real expert to debug issues and solve problems; understand framework architecture and read reflection code. You can't just put a breakpoint in there and start debugging. It's optimizing for the wrong thing.
The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over.
This whole attitude is IBMs fault. They tried to get into the Java market by applying their big iron terminal thinking to create Java EE.
Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.
Java EE was created by Sun themselves, it was reborn from a Objective-C framework for OpenSTEP called Distributed Objects Everywhere, better get your history straight.
The article is talking about Quarkus, a framework that uses the same annotations but which generates Java code at build time. So there's no reflection and you can navigate with your IDE or debugger into the framework code to understand what it does.
The things you hate about working with Java, that you mention in the first paragraph, are the basic things that Java devs have to do, or actually any dev in any language.
It makes me laugh how people mention that C# or Java has "magic", which is just the lack of understanding a feature of the language, but in the same breath says that Rust doesn't have this problem. I rather be able to debug a C# attribute than a Rust one.
Can we maybe also talk about FP’s cultural problem: that lots of people with a functional programming background just don’t get object orientated programming and instead of trying to understand it, dismiss it as crap and enterprisey.
The very idea that FP programmers don’t understand OOP is absurd on its face. You point to an undergraduate CS program that is teaching FP before imperative and OOP paradigms; you find me an FP zealot who hasn’t written more OOP than FP code.
This is a nonsense “reverse racism” argument rehashed to be about programming paradigms, and I won’t stand for it.
That is also OOP cultural problem: that lots of people with a object oreinted programming background just don’t get functional programming and instead of trying to understand it, dismiss it as crap and too pure, unpractical, over-engineered and too theoretic.
I am a C# fanboy semi-greybeard with a very extensive OCaml university background and FP advocate (in C#) and I am still struggling with monads every single time I have understood them for a second.
Functional approach is always under consideration and a default.
OOP is useful in certain contexts (e.g. GUI elements) or simulations, otherwise it's better to use OOP in a dependency-injection way to construct the process then let the relationships be static while performing computation processes with them. The full dynamic reconfigure objects willy-nilly in an area where that doesn't reflect the problem itself is doomed to be a mess. Especially with threads using mutexes or collections that do.
I agree with the general sentiment of the article.
It is clearly possible to write a straight forward Java code. See: Sparkjava, Javalin, or Vert.x. Hell, even Minecraft Java code is pretty easy to read.
Too bad Java culture is dominated by consultancy-like culture, which promotes as many obfuscation as possible.
The world will not end if you don’t use annotations and DI frameworks.
It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach, I don't see why we should listen to "any FP developer" criticisms.
It's not that I have anything against FP - let's just admit that side-effect pure FP is a "futuretro" of today. A future that never was.
The author is using field injection and claiming that the field cannot be private. As far as I know he should be using constructor dependency injection and make the field private and final. That way is also easier to write unit tests and maybe make use of interfaces in case he wants to avoid using a mocking framework.
Not only that but if I recall correctly quarkus resolves dependencies and config files at compile time and not at runtime using reflection as spring does.
It must be said that this coding style may be the norm with Quarkus (and with Spring which it is trying to replace on graalvm/native-image), but isn't required by Java itself. As always, Spring-like Java buerocrats have chosen to chase and over-engineer trivialities because it's so much easier lol; well until using your framework becomes a study in psychology or software archeology.
Update: what I don't get with Quarkus though is why did they set out in Spring factory style only to have to immediately limit this for native-image's "closed world assumption"
I'm pretty sure Quarkus tries to stick as close as possible to Java EE APIs with some limitations to accommodate the lack of runtime reflection, being Red Hat's answer to application containerization for which JBoss isn't a good fit, if it looks like Spring it's mostly because it's a popular style in Java.
I'll take java any day for server side, I don't know why but when I use java things just tend to be much more stable and It does not take me more time to write code at all.
I haven't programmed in Java in many years, except for making DAGs for Storm and a authorization metalibrary that none of the "real" Java programmers liked. Paradoxically the most sccinct statement of dislike concerned my choice of arraylike class: "THAT'S WRONG!". The Java programmers had source control, just like the rest of us. But their Maven configs weren't under source control, and they wouldn't help the rest of us with ours. I've concluded that I'm indifferent to Java, but not so good with Java programmers.
There's a big ball of puzzling contradictions in the above.
Have you heard of Lacan or Zizek? Well. Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis". In my opinion: remember that.
They've build a lot of ritual around notions of control and deliberativeness (that array problem). They're Catholic or Orthodox, really. The JVM is supposed to be "safe", and I have to ask: does the communion wine really turn to the blood of Christ?
My father was a psychiatrist. I am well aware that Dr. Tim Leary was a pioneer in personality diagnosis, having found "The Interpersonal Diagnosis of Personality" on my father's bookshelf. I analyzed precinct level voting patterns, and they exist; but the question "is it something in the water, or new car smell?" remains vexing and unsolved.
There is something that happens when people program in different languages with different tools, especially in groups. It's not just languages: how does Docker culture compare to NanoVMs on the Leary radar chart?
But what I have for you is a (hopefully) playful personality diagnosis of some of the major programming languages. Make some popcorn. This is for entertainment purposes, but maybe it'll give you something to think about.
Java doesn't have a cultural problem. People need to understand that Java culture is almost entirely enterprise culture. Don't want a language influenced by that for your project? There are plenty out there, pick one
It has a culture of over-engineering, just look at Log4J or Spring with its AbstractSingletonProxyFactoryBean's. More complicated and far more adhoc than any abstraction should be.
This is just an angry rant by someone describing themselves as a “functional programming enthusiast”. The post is only tangentially about Java and is really about a framework called Quarkus.
If there’s a culture problem it’s the “Look at me. I learned something new and now I’m going to do my best to burn down everyone else”. If you want to program in Haskell or whatever have a great time. Think it’s so great? Prove it by writing great software with it.
The way I see it, is people searching for a better way, after years of trying to actually use Java. And what does Java's chief architect think?
"It is my belief that the best direction for evolving Java is to
encourage a more functional style of programming. ... We're not going to turn
Java into Haskell, nor even into Scala. But the direction is clear."
I'm still waiting for ASP.Net-like framework in Java where all configs are explicit and the framework doesn't require hundreds of confusing annotations just to display a hello world page.
This is a dumb rant about something the author doesn't know anything about and hasn't bothered to understand or research.
Dependency Injection is not functional programming. Dependency Injection solves a lot of problems and entire classes of bugs around application state, but with far more approachable stepping stones than something like pure functional languages.
Pure functional languages solve state problems as well but are far more complicated and difficult to grok because of the paradigm shift.
Whatever one chooses for a team of developers, the most important thing is being able to use the tools at hand. It's pretty easy to explain to someone what Scope is and how CDI has some standard scopes.
The author doesn't even seem to understand how Java annotations even work.
[+] [-] bluejekyll|3 years ago|reply
> Java allows null objects… that ship has sailed
Not necessarily, with project Valhalla, it should be possible to have generic Value Types in the language that would allow things like Optional to be defined on the stack where it would be non-null and then all it’s methods for checking if the Object it references would make sense, and actually work. This would be in contrast to today where the Optional type isn’t as useful as it seems since it can also be null.
Anyone know the status of this? https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_langu...
[+] [-] willsmith72|3 years ago|reply
The problem is, for every org I've seen, saving memory is not the goal of the program. "Making debugging harder" is subjective, and most people I've heard use this argument are taking about "magic auto configuration". Maybe this isn't intuitive at first, but the knowledge comes quickly, and from my experience the java app with unit and integration tests is far easier to debug than the Go app with less testing and less readable syntax.
The memory argument is also way less applicable when using the author's framework, because your app is built into a native image.
I know you didn't mention Go, but that's where I always see this argument headed, and it always makes me wonder whether the writers have ever had to maintain or take over an app written in Go, or if they can happily write-and-forget.
[+] [-] democracy|3 years ago|reply
[+] [-] Supermancho|3 years ago|reply
[+] [-] ilitirit|3 years ago|reply
I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc.
And for the record it's not just Java (it just seems to be more pronounced in the Java-development ecosystem). For every person who waxes lyrical about the joy of working with C# (for example), there are 3 more that will tell you anecdotes about "assembly hell". Or how Visual Studio is slow and a massive memory hog. Or that there is no proper Forms support on XYZ-os.
Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. IMO, I think it's usually far more productive to try to understand the discussion in context than to veer off into irrelevant semantic issues or tangential anecdotes.
[+] [-] Sohcahtoa82|3 years ago|reply
> I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc.
This is something I've been saying for years.
Java, as a language, is great. But Java paradigms are fucking awful, and I don't understand why people use them. However, I'll confess that I'm naive, as I've never had to build anything larger than about 1,000 lines.
Like...one of the patterns that I absolutely despise is the "Handler". So often, code is peppered with "MyHandler handler = new MyHandler(); handler.invoke(...);". If you have an object that consists of only a constructor and a single function, and is merely instantiated, called once, and then thrown away, why is this its own object?
I see Java developers complain about stack traces that are 50+ function calls deep with half the functions in the stack named ".invoke()" or ".run()", and all I can think is how those wounds are self-inflicted.
[+] [-] 62951413|3 years ago|reply
[+] [-] jimbob45|3 years ago|reply
[+] [-] dvfjsdhgfv|3 years ago|reply
> Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion.
but earlier you noted that:
> you can't really dissociate the language from the environment
So it seems like a self-contradictory position.
[+] [-] vbezhenar|3 years ago|reply
I liked Helidon SE approach (not MP, MP is the same EE crap). It's 100% code, no magic. What I didn't like is reactive, I don't need reactive, so I don't use Helidon SE for my projects, I still endure Spring. But if someone enjoys reactive programming and wants zero-magic approach, I can recommend it.
Helidon Nima might be a saviour to me. I didn't research it yet.
[+] [-] grishka|3 years ago|reply
I use http://sparkjava.com in my projects. It's as tiny as web frameworks get, it only handles routing and request/response, and you get to do everything else manually. Only thing I had to hack into it was response streaming. The one most internally convoluted and enterprise-y dependency I use is, surprisingly, the official MySQL driver. GraalVM complains about it as well.
[+] [-] BenoitP|3 years ago|reply
> Helidon Nima might be a saviour to me
Well, Helidon Nima is getting a Loom-based implementation; so you'll get to keep performance without the reactive headaches.
[+] [-] mwcampbell|3 years ago|reply
But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1].
[1]: https://javalin.io/
[+] [-] rr888|3 years ago|reply
[+] [-] tofflos|3 years ago|reply
> The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged.
> The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used.
> Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for microservices running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed.
One reason we don't know whether SmallRye Config is reading from a file or querying a database at development time is because that choice has been deferred to the system administrator at deployment time.
Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure.
You can load configuration programmatically if don't want to use dependency injection and/or want something that is easier to test. See https://download.eclipse.org/microprofile/microprofile-confi....
[+] [-] le-mark|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] ragnese|3 years ago|reply
Anyway, Java still has baggage that I doubt will go away any time soon. My biggest two complaints with Java are that null exists outside of the type system and that they mix runtime type reflection and non-reified generics. The latter features being actually incompatible with each other makes working with Java libraries/frameworks a minefield.
But, aside from those issues, the OP is totally right that so much of Java's bad reputation comes purely from library design and culture. Even when I preferred OOP architectures, I hated the fact that so many Java libraries and frameworks required a bunch of annotations for everything, even when it really wasn't necessary. I get that Java code can be verbose, but if you don't like it, use something else- don't just throw away compile time safety and information for a janky runtime-checked "DSL" where a bunch of the features don't even actually work together (I'm mostly looking at you, JacksonXML, but also Spring, et al).
Everyone praises the Java ecosystem as some kind of selling point, but I find that while the ecosystem is indeed broad, the actual quality and productivity of many of the popular libraries and frameworks is fairly low. And by "quality", I don't necessarily mean number of open bug reports, I mostly mean that the APIs are really difficult to understand and use correctly. In some sense the devs are "off the hook" when my app doesn't work correctly because "this is documented behavior", but that makes me think I should just start writing documentation for my apps' bugs and seeing what my boss thinks... ;)
[+] [-] nilsb|3 years ago|reply
[+] [-] matsemann|3 years ago|reply
[+] [-] ris58h|3 years ago|reply
[+] [-] throw_m239339|3 years ago|reply
[+] [-] strictfp|3 years ago|reply
The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over.
This whole attitude is IBMs fault. They tried to get into the Java market by applying their big iron terminal thinking to create Java EE.
Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.
[+] [-] pjmlp|3 years ago|reply
[+] [-] mike_hearn|3 years ago|reply
[+] [-] moondowner|3 years ago|reply
[+] [-] metaltyphoon|3 years ago|reply
[+] [-] democracy|3 years ago|reply
[+] [-] ncmncm|3 years ago|reply
https://blog.plover.com/prog/Java.html
[+] [-] throwaway4good|3 years ago|reply
[+] [-] vonwoodson|3 years ago|reply
[+] [-] oaiey|3 years ago|reply
I am a C# fanboy semi-greybeard with a very extensive OCaml university background and FP advocate (in C#) and I am still struggling with monads every single time I have understood them for a second.
[+] [-] tempodox|3 years ago|reply
Also, are you insinuating that those who “get” OOP can't find FP a superior approach for certain problems?
[+] [-] karmakaze|3 years ago|reply
OOP is useful in certain contexts (e.g. GUI elements) or simulations, otherwise it's better to use OOP in a dependency-injection way to construct the process then let the relationships be static while performing computation processes with them. The full dynamic reconfigure objects willy-nilly in an area where that doesn't reflect the problem itself is doomed to be a mess. Especially with threads using mutexes or collections that do.
[+] [-] didip|3 years ago|reply
It is clearly possible to write a straight forward Java code. See: Sparkjava, Javalin, or Vert.x. Hell, even Minecraft Java code is pretty easy to read.
Too bad Java culture is dominated by consultancy-like culture, which promotes as many obfuscation as possible.
The world will not end if you don’t use annotations and DI frameworks.
[+] [-] thriftwy|3 years ago|reply
It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach, I don't see why we should listen to "any FP developer" criticisms.
It's not that I have anything against FP - let's just admit that side-effect pure FP is a "futuretro" of today. A future that never was.
[+] [-] HiIAmIlNano|3 years ago|reply
Not only that but if I recall correctly quarkus resolves dependencies and config files at compile time and not at runtime using reflection as spring does.
[+] [-] tannhaeuser|3 years ago|reply
Update: what I don't get with Quarkus though is why did they set out in Spring factory style only to have to immediately limit this for native-image's "closed world assumption"
[+] [-] absove|3 years ago|reply
[+] [-] tomerbd|3 years ago|reply
[+] [-] m3047|3 years ago|reply
There's a big ball of puzzling contradictions in the above.
Have you heard of Lacan or Zizek? Well. Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis". In my opinion: remember that.
They've build a lot of ritual around notions of control and deliberativeness (that array problem). They're Catholic or Orthodox, really. The JVM is supposed to be "safe", and I have to ask: does the communion wine really turn to the blood of Christ?
My father was a psychiatrist. I am well aware that Dr. Tim Leary was a pioneer in personality diagnosis, having found "The Interpersonal Diagnosis of Personality" on my father's bookshelf. I analyzed precinct level voting patterns, and they exist; but the question "is it something in the water, or new car smell?" remains vexing and unsolved.
There is something that happens when people program in different languages with different tools, especially in groups. It's not just languages: how does Docker culture compare to NanoVMs on the Leary radar chart?
But what I have for you is a (hopefully) playful personality diagnosis of some of the major programming languages. Make some popcorn. This is for entertainment purposes, but maybe it'll give you something to think about.
https://www.youtube.com/watch?v=mZyvIHYn2zk
[+] [-] docmechanic|3 years ago|reply
'Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis".'
[+] [-] fedeb95|3 years ago|reply
[+] [-] grumpyprole|3 years ago|reply
[+] [-] fulafel|3 years ago|reply
[+] [-] zcw100|3 years ago|reply
If there’s a culture problem it’s the “Look at me. I learned something new and now I’m going to do my best to burn down everyone else”. If you want to program in Haskell or whatever have a great time. Think it’s so great? Prove it by writing great software with it.
[+] [-] grumpyprole|3 years ago|reply
"It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. ... We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear."
https://mail.openjdk.org/pipermail/lambda-dev/2011-August/00...
[+] [-] dmitriid|3 years ago|reply
I'm still waiting for ASP.Net-like framework in Java where all configs are explicit and the framework doesn't require hundreds of confusing annotations just to display a hello world page.
[+] [-] tannhaeuser|3 years ago|reply
[+] [-] exabrial|3 years ago|reply
Dependency Injection is not functional programming. Dependency Injection solves a lot of problems and entire classes of bugs around application state, but with far more approachable stepping stones than something like pure functional languages.
Pure functional languages solve state problems as well but are far more complicated and difficult to grok because of the paradigm shift.
Whatever one chooses for a team of developers, the most important thing is being able to use the tools at hand. It's pretty easy to explain to someone what Scope is and how CDI has some standard scopes.
The author doesn't even seem to understand how Java annotations even work.