I wonder if they might condescend to utilize the JVM so I don't have to compile JMC myself for another 5 months, or maybe at least they'll remove their circular links that infuriatingly obscure the fact JMC binaries don't currently exist. For the past 5 months.
Java 12
261–270 of 478 posts
Re: Java 12
#262Earlier quoted context omitted.
> There's many valid critisicms of Java... Yes there are. ...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing…
May be I am living in a bubble... it's always hard to tell from inside the bubble. But this is not my impression at all. All of the major tech companies have major Java footprint which is not going anywhere. This is not only the older tech companies (FB, Goog, Amazon etc.). Even newer companies like AirBnb, Uber rely heavily on Java. Startups often start with fancy esoteric languages but eventually do come around to…
I see the same in major enterprise companies I and my peers have worked in. Java is being used for a lot of large greenfield projects I am aware of.
Re: Java 12
#263Earlier quoted context omitted.
I'm not sure if you're trolling so I'll try to keep this short. Java is old, it's crufty. Yes. But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff. The JVM is also extremely reliable. I've seen apps run for years straight. And the tooling is better than basically anything. Profiling, debugging, realtime code generation and modification. Libraries for…
I mostly agree, except: > But Spring is dated and not often used for new projects. Spring Initialzr ( https://start.spring.io ) is used millions of times per year.
Fair enough. The Java ecosystem is huge and I try to keep up but many things slip through the cracks, you'll find many in my furious comment history on the thread.
Thanks, looking it ip
Re: Java 12
#264Switch expressions prepare the way for pattern matching ( https://openjdk.java.net/jeps/305 ), instead of `instanceof` checks and casts. But (in my naive opinion) double dispatch seems a more elegant and java-ry solution, i.e. polymorphism on argument classes, so different methods are invoked for different object runtime classes (instead of using the compiletime type of the variable). The switching could be optimised…
That kind of multiple dispatch would be far more disruptive at several levels, and still wouldn’t really get you where you want to go without a lot more compiler and JIT magic. Sure, you could match on types, but you wouldn’t be able to extend that to destructuring patterns, or regsxps as patterns on strings, or so many other ways patterns may be extended in future releases.
My comment's a little out of place. I'm not against pattern matching, but for double dispatch; we can have both.
Their initial motivating examples was bare instanceof, but I now see they extend it.
How would destructuring fit this model ?!
Re: Java 12
#265Re: Java 12
#266Earlier quoted context omitted.
Yeah, I do wonder how Unity deals with the GC. Maybe there's an algorithm like this one, maybe the engine's core systems (physics and graphics) are written in native code. C# as a language does tend to be nicer than Java, but its VM doesn't have as rich a family of languages.
My limited understanding is that high end Unity devs code their stuff not to make garbage. Unity has a very nice system for profiling that sort of thing. Also, CLR has F#, which I like much better than Scala (and, no type erasure in CLR), Clojure which is ... just like Clojure on JVM, and C#, which as a Java dev since 1.1 I have come to prefer as a language even as I remain JVM ecosystem preferring on the server side…
Is Clojure on CLR actively maintained?
Re: Java 12
#267Earlier quoted context omitted.
> There's many valid critisicms of Java... Yes there are. ...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing…
I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading. But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run…
Like COBOL in the sense of its purported future niche in the industry, not in the sense of syntax and language power.
Re: Java 12
#268Earlier quoted context omitted.
I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading. But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run…
Like COBOL in the sense of its purported future niche in the industry, not in the sense of syntax and language power.
Yes perhaps that's true. I ask you to consider some c++ to java conversions though. Usually the syntax is almost identical, whereas COBOL is clearly terrible
Re: Java 12
#269Earlier quoted context omitted.
I am not sure what else are you looking for, Spring boot/cloud has pretty much all you need to build any application.
I know Spring and Spring boot are very popular, but I don't understand why. The Spring Boot home page says, "Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run"." What does that mean? What does Spring Boot give me that Tomcat doesn't?
What code are you writing that Tomcat runs? Are you coding against the servlet spec? Or are you using something like dropwizard?
Tomcat is a servlet container that implements various Java EE specifications, such as the servlet spec, jsp spec, etc.
Spring encompasses many different libraries. The most widely used is probably Spring MVC, which builds on top of the servlet spec to make building web applications easier. After that Spring Security is probably most widely used, which adds things like auth, CSRF tokens, etc. Spring Data and Spring Cloud are also somewhat popular. There are many more Spring libraries, but I have little to no experience with them.
You can really give or take what you want here. You can use Spring MVC with Spring Data, or Hibernate, or JPA, JDBC, or whatever you want really. One place I worked used Spring MVC with home grown security and ORM layer.
Spring Boot brings "convention over configuration" to Spring. Because Spring is so configurable it can take a lot of boilerplate. Spring Boot removes much of that boilerplate for certain use cases and has, generally speaking, more user friendly defaults.
Spring Boot also runs off a server embedded in the jar. That's why you can "just run" it. You create a "Main" method. You can choose from several embedded servers, including Tomcat. But this isn't exactly special for Spring Boot because you could do this even if you didn't use Spring Boot.
Re: Java 12
#270Earlier quoted context omitted.
> OO in general is not fine. I smell a zealot or a troll.
Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code an…
> It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing.
Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.
> Pretty much all of the OO languages are walking back OO features
About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.
> and trying to add type classes (contracts)
In most OO languages, these typically naturally evolve out of interfaces.
> functional pieces, mapping and filtering a la linear data transformations.
This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.