Doradus

7 ms·

1.
by Doradus 8y ago
Your history is a little mixed up there. The original author of Turbo Pascal, and Chief Architect of Delphi, became the Lead Architect of C#. It’s not like Microsoft came out of nowhere and ate Borland’s lunch.
2.
by Doradus 8y ago
His youth is remarkable, so they remarked on it. I'm not sure what about this troubles you.
3.
by Doradus 9y ago
Depends on the elevation of the horizon.
4.
by Doradus 9y ago
> I expect discriminating by amount of relevant experience is fair, but that's not the same as age. As someone who started coding at age 9, I agree. :-) It's not about hiring someone in their 40s per se, but rather about recog
5.
by Doradus 9y ago
Agreed. I remember being in my early 20s, watching my more experienced colleagues, and realizing this. I had had a different (incorrect) mental model: I had thought intellect was as good as experience, so Ability = Intellect + Experience.
6.
by Doradus 9y ago
It seems absurd that an article claims to disprove a hypothesis linking structure to communication patterns without even the slightest mention of trying to observe those patterns. But they go even further: they claim to have determined the
7.
by Doradus 9y ago
This. I used to work at IBM, and I can't tell you how many different (mutually inconsistent) narratives about "how IBM is".
8.
by Doradus 9y ago
Huh? That's funny--I would have said the opposite. It was from watching Obama's speeches that I learned that silent pauses can be much less annoying than "umms". If you want to see someone using a lot of "umms&quot
9.
by Doradus 10y ago
It doesn't take long to get used to that style. It took me maybe three weeks of playing with Java 8 streams in my spare time before I got quite comfortable with it.
10.
by Doradus 10y ago
Easy, there. Librarians aren't the bad guys in this story.
11.
by Doradus 10y ago
Nope. Transactions, in the sense of the article, bear no relation to goroutines. The right answer is that Java's generational collector supports this transaction lifetime reasonably well in many cases.
12.
by Doradus 10y ago
RAII is using one C++ misfeature (destructors) to work around another misfeature (inability to do cleanup when leaving a lexical scope). Go has a far more elegant solution to the latter; if you're not familiar with the defer statement
13.
by Doradus 10y ago
I'm not sure you've grasped the write barrier part. That's the really new part.
14.
by Doradus 11y ago
Did you read the article? It answers your question. Take a look at the section that begins with this: The problem is called a paradox because two analyses that both sound intuitively logical give conflicting answers to the question of wh
15.
by Doradus 11y ago
(Whoops, I've misunderstood you twice. I think my other reply answered the wrong question. Let me try again.) I didn't say synchronization can prevent EA. I said that calling a finalizer on an application thread can defeat the
16.
by Doradus 11y ago
I must have misunderstood you. You made a statement that I parsed as follows: "If (this stuff isn't escaping) then (the JIT can prove that it isn't using a lock)." That is logically equivalent to: "If not (the JIT c
17.
by Doradus 11y ago
Your argument proves that the time taken can be no less than O(n) in the number of object references in live objects. The (potentially billions of) unreachable objects are never touched. I agree that limited RAM environments are important.
18.
by Doradus 11y ago
I seem to have hit a nerve here. Perhaps I haven't been clear about some of the points I'm making, which I don't think are all that contentious. I'm not saying a fast GC can reduce the cost of allocation. I'm sayi
19.
by Doradus 11y ago
Well, it's hard to deny that the work done by the program is O(n) (or even Ω(n)) in the number of objects created by the program. That's almost tautological. The thing that is interesting about the asymptotic complexity of garbag
20.
by Doradus 11y ago
The JVM doesn't release the memory to the OS when garbage is collected; only when the heap shrinks. Any zeroing the OS might do is proportional to the size change in the heap, not to the number of objects freed.
21.
by Doradus 11y ago
I think you're referring to a mark and sweep collector. Java's garbage collector uses better algorithms. The collector never even looks at objects that are not referenced from the root set, and an allocation operation is nothing
22.
by Doradus 11y ago
Actually, synchronization is not an escape. Objects can be stack-allocated in methods that do synchronization.
23.
by Doradus 11y ago
"Go compiles to native code. Java, ultimately, does too, but compilation happens at runtime, which is an overhead that Go doesn’t have, so in principle Go should be faster." Oh boy. It pains me every time I hear this. In a micr
24.
by Doradus 11y ago
Poof! There goes finite automata, and therefore regular expressions. :-)
25.
by Doradus 11y ago
It's hard to say. The finalization spec is subtle. To make this work, the JIT would need to perform escape analysis on the finalizer too (since the finalizer can make an object escape). If that analysis succeeds, then I suppose the o
26.
by Doradus 11y ago
Me too. I would fully expect the JIT compiler to remove this call unless it's more complicated than it sounds. I don't think this is a real fix. I work on IBM's JIT compiler. We had to do something similar to fix this prob
27.
by Doradus 11y ago
"I wish that when GC encountered a cycle it would just tell the programmer that they now have a leak..." Wow. Overreact much? :-) Garbage collection works great for one use case: managing heap memory. Please, let's not ret