sreque

23 ms·

151.
by sreque 10y ago
My point exactly. The issue isn't java the language. The issue is the flexibility of the JVM runtime and how people are abusing it. Also, if load-time aspect-weaving and classpath-scanning-based autodiscovery don't count as magic
152.
by sreque 10y ago
Take a look at a java codebase that uses: * Complex DI frameworks (Spring Bean*Processors, event listeners, XML config) * classpath scanning-based autowiring (See Spring @Component) * aspect weaving-based autowiring (See Spring @Con
153.
by sreque 10y ago
From what I've read, until recently this wasn't actually the case for the field updater classes. Instead, Java does things like not trusting your fields' finality and not treating anything as constant. Let me see if I can fin
154.
by sreque 10y ago
In this sense VarHandle also relies on generics when updating references, which is completely meaningless, just as it is meaningless to say AtomicReferenceFieldUpdater "relies on generics".
155.
by sreque 10y ago
This isn't correct. The atomic updater classes don't rely on generics to do anything. What they do is perform safety checks on every access to ensure you don't segfault your JVM, resulting in heavy performance losses compared
156.
by sreque 10y ago
The "consequences on some processors" simply means that a conforming java compiler/VM may need to insert memory barriers to enforce the memory model for constructors, resulting in a performance penalty. A conforming compiler
157.
by sreque 10y ago
It's actually not possible to get a hold of partially-constructed thing in this manner, assuming the thing only has final variables. See http://g.oswego.edu/dl/jmm/cookbook.html . "The initial load (i.e.,
158.
by sreque 10y ago
a couple of examples in RA mode involving constructors and final fields look unnecessary to me. I thought the java memory model already guaranteed a release/acquire fence at the end of constructor for final fields. Basically if a threa
159.
by sreque 10y ago
Many things pointed out in this article apply to just about every managed language runtime. Implement a TreeSet in any language and you'll see the same overhead from object headers, memory alignment, etc. Java has some oddities that ca
160.
by sreque 10y ago
I think the Scala community's aims have been higher than what you've suggested for a while. For example, from what I've seen, Scala.js has been wildly successful, yet according to you it should never have existed. Scala.js le
161.
by sreque 10y ago
They should. The article basically throws in some FUD to convince people that they don't want what they think they want. Except, we do want it! The JVM ecosystem's general aversion to native code and native system integration is w
162.
by sreque 10y ago
The JVM itself doesn't add a huge memory footprint. I remember Charles Nutter of JRuby fame calling it the "20-30 MB memory tax" (see http://blog.headius.com/2008/11/noise-cancelling.html ). A lot of
163.
by sreque 10y ago
I'm not involved with this project in any way, but I would expect performance to be overall worse with Scala Native. The advantages of Scala native are likely: 1) Much faster startup times 2) smaller memory footprint for small programs
164.
by sreque 10y ago
There actually is some basic runtime support for generics, just enough to avoid breaking the runtime. For instance, if I create a class MyList extends ArrayList<Double>, there actually is some runtime information that says MyList is a
165.
by sreque 10y ago
I purposely left out templates because I do not consider them to be the same as generics. Their is no "runtime" support for templates; templates are basically a glorified macro engine for creating new code based on type parameters
166.
by sreque 10y ago
It should be plain to see that it would be much easier to implement your programming language on top of the CLR or JVM if you didn't need to request new features from Oracle or Microsoft to be added to the runtime. I remember one time
167.
by sreque 10y ago
>And this is the first time I've heard that the JVM is easier to target for non-Java languages https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e... Here's a post from a JRuby developer saying
168.
by sreque 10y ago
Just about every programming language expert I've seen who's talked about Java generics says Java did a better job than C#. In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. Exa
169.
by sreque 10y ago
You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community. You can call things via reflection, therefore the language is dynamic?
170.
by sreque 10y ago
I agree with cle, and I care enough to give examples of painful XML coding in Java: * Spring startup config (this is basically coding in another XML-based language) * JSPs (again, programming in a new XML-based language) * Maven Config (IMO
171.
by sreque 10y ago
There's a reason I put the phrase in quotes. I'm referring to the kinds of programmers that create popular libraries that people can make jabs at with words like "AbstractSingletonProxyFactoryBean". There has been excell
172.
by sreque 10y ago
The problem here is that "best java developers" really aren't that good. And why is that the case? Is it the community's fault? The language's? I think it can be seen as both to some extent. The mentality and philos
173.
by sreque 10y ago
I'm not familiar with MacWire, but I believe it's powered by macros. You can think of a macro as a function that runs at compile time. It's input is a syntax tree representing some code, and it's output is an arbitrary s
174.
by sreque 10y ago
I don't think you're understanding what the author was saying. The author is advocating for constructor-based dependency injection, which incidentally, I also advocate for. There is a macro-based library in Scala, MacWire, that he
175.
by sreque 10y ago
As someone who is currently having to deal with a monolithic Java app built on spring, hibernate, aspect weaving, code drenched in null checks, and other questionable architecture choices, this article makes me want to switch to Scala, and
176.
by sreque 10y ago
As a counterpoint, all other things being equal, if I were building a software team I'd hire a candidate who could pass a basic algorithms interview over a "OOP design" specialist who couldn't.
177.
by sreque 10y ago
This fallacy props up surprisingly often. We should not treat programming language writers as a separate class of people from programming language users. We often have the same needs and require the same solutions. My Master's adviser
178.
by sreque 10y ago
If the interviewer is in a position where he/she seems willing to listen and learn, then by all means impress. However, correcting an interviewer is always a dangerous gamble, and it is downright foolish to keep arguing with him or her
179.
by sreque 10y ago
I think the candidate made a simple mistake: the interviewer is always right. Your job in an interview isn't to be right or to teach the interviewer. Your job is to make the interviewer like you foremost, and second make the interview
180.
by sreque 10y ago
You get impressive performance out of python the same way you get impressive performance out of any dynamic language (with few exceptions): make sure your hot paths are executed by code written in C. The nice thing about PyPy is that it mak

More ›