8,009 reputation
12037
bio website
location
age
visits member for 3 years, 5 months
seen 1 hour ago

Mar
22
comment Why did the Sun engineers decided to make Java only call by value?
@JörgWMittag ... I do agree that variables and values are distinct entities (clearly 1 is not a variable). But I consider variables of value type values. As far as I can tell, this is a standard view, and it does not appear to lead to any faulty conclusions. And thus, when I say "int is mutable", I do not claim that all values of type int can be changed, I claim that some such values (namely those that are variables, fields, array slots, etc. and not final) can be changed, by replacing them with a copy of another value.
Mar
22
comment Why did the Sun engineers decided to make Java only call by value?
@JörgWMittag It appears you are using a very different, less common (and IMHO less useful) definition of "value". When I say "the value 1" I don't refer to some platonic mathematical entity; I mean any part of memory that equals the constant 1. That includes variables of type int, because (unlike with reference types such as your MutableInt) the variable actually holds that value, not a reference to a value elsewhere. In other words, x is as much of an int value as y in MutableInt is a reference. Which brings me to the gist, which only illustrates that int is a value type...
Mar
21
comment Why did the Sun engineers decided to make Java only call by value?
@RobertHarvey But it's a lot closer than C++. As in Lisp, Java has no concept of memory or memory management, it only has values/objects. As in Lisp, everything's a reference type (with the ugly exception of primitives, a concession to performance).
Mar
21
comment Why did the Sun engineers decided to make Java only call by value?
@JörgWMittag x is not a reference to an int object. It is an int, but it is not the number 1. x = 1 meant "copy the value 1 into x", not "make x refer to 1". There are thirty two bits somewhere in computer memory, they used to be 00...001 and now they're 00...010 - sounds like mutation to me. Expecting mutation of the concept of the number one would be a bit silly, wouldn't it? (Though I've heard anecdotes of the very first FORTRAN compilers allowing such fun.)
Mar
21
comment Why did the Sun engineers decided to make Java only call by value?
In what sense of the word are primitives immutable? int x = 1; x = 2; works, doesn't it?
Mar
20
comment Is a genetic algorithm needed when computation is infinitely fast?
Well, unless weird physics like closed timelike curves (near the end) turn out to work and can be exploited for general-purpose computation.
Mar
17
comment Complete immutability and Object Oriented Programming
@Revious Yes, reading would be slower, though not as slow as changing a string (the traditional representation). A "string" (in the representation I'm talking about) after 1000 modifies would be just like a freshly created string (modulo contents); no useful or widely used persistent data structure degrades in quality after X operations. Memory fragmentation is not a serious problem (you'd have many allocations, yes, but fragmentation is well a non-issue in modern garbage collectors)
Mar
17
comment Complete immutability and Object Oriented Programming
@Hyperboreus I lean towards Robert Harvey's answer, but would like to actually try using such a language (or at least think long and hard about how it would work) before making a judgement call.
Mar
17
comment Complete immutability and Object Oriented Programming
@Revious Any persistence "sequence" data structure works, really. For example, Finger Trees of chars would support efficient (in the amortized time complexity sense) concatenation, splitting, removal at any index, insertion at any index, etc.
Mar
17
comment Complete immutability and Object Oriented Programming
@MichaelT Feel free to point out anything I missed, but you only seem to make a case for immutability being sometimes beneficial, not for "complete" immutability, and not whether mutability is sometimes beneficial or even necessary.
Mar
17
comment Complete immutability and Object Oriented Programming
@MichaelT The question is not about making specific things mutable, it's about making all things immutable.
Mar
17
comment Complete immutability and Object Oriented Programming
Frequently modifying immutable data does not need to be catastrophically slow as with repeated string concatenation. For virtually all kinds of data/use cases, an efficient persistent structure can be (often already has been) invented. Most of those have roughly equal performance, even if the constant factors are sometimes worse.
Mar
17
comment Complete immutability and Object Oriented Programming
@RobertHarvey Yet mutability is a core feature of all object oriented languages I, and presumably OP, are aware of. The question, as I understand it, is whether mutability is a "core part of object-orientation" or not. What you're saying is a potential answer to the question, not an obstruction to it.
Mar
17
comment Why was “goto” originally supposed to be included in Java?
I know of one example where goto produces tidier code, and that's error handling/cleanup-on-return in C. Java (and virtually all other modern languages) has different solutions for that problem (try {} finally {} and try-with-resources in Java's case) that are least as satisfactory, arguably even better.
Mar
11
comment Disadvantages of scoped-based memory management
I don't think Stack Exchange comments are the right medium to give a tour through a language. If you're still interested, you can go straight to the source (#rust IRC, rust-dev mailing list, etc.) and/or hit me up with a chat room (you should be able to create one).
Mar
10
comment Disadvantages of scoped-based memory management
Tasks (semantically, roughly equivalent to threads) do not share memory by default; Rc<T> is the standard task-local (and hence non-atomic) RC pointer type, then there's Arc<T> (immutable, atomic refcount) and RWArc<T> (mutable, read-write lock) for sharing data across tasks. There are owning references (e.g. ~T) and non-owning references (e.g. &T, &mut T), the former can be turned into the latter and a combination of type system features makes sure borrowed references don't outlive the owner. (Other) smart pointers fit into this seamlessly (or at least will before 1.0).
Mar
10
comment Disadvantages of scoped-based memory management
@Philipp At least in the Python world, this is considered an implementation detail of CPython, not a property of the language (and virtually every other implementation eschews refcounting). Moreover, I would argue that catch-all no-opt-out reference counting with backup cycle GC does not qualify as SBMM or RAII. In fact, you'd be hard pressed to find RAII proponents that are consider this style of memory management comparable to RAII (mostly because it isn't, cycles anywhere can prevent prompt deallocation anywhere else in the program).
Mar
10
comment Disadvantages of scoped-based memory management
@Philipp I use "ref counting" to mean "naive ref counting", since in practice almost all implementations use that. Smart refcounting might be an alternative to smart tracing GCs. Notes about that the paper though: (1) At least some of the techniques (didn't read the entire thing) use a backup precise GC (nominally for cycles only) and assign it crucial rules, e.g. StuckRestore RC. (2) These optimizations trade some of the collection promptness for performance, especially for young objects, making them less deterministic even without cycles.
Mar
10
comment Disadvantages of scoped-based memory management
@MSalters "Value" also implies ownership (namely, unique ownership). You still have to decide whether to use a value or something with different ownership.
Mar
10
comment Disadvantages of scoped-based memory management
@MSalters What's your point? I've drawn the reference connection myself. I did not say C++ lambdas are exceptionally unsafe, I said they are exactly as unsafe as references. I did not argue that C++ lambdas are bad, I argued against this answer's claim (that C++ got closures very late because they had to figure out how to do it right).