Timeline for What does this statement about C# and Java being half of a language mean?
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11, 2017 at 5:20 | comment | added | Wes Toleman | @JörgWMittag the original source does not mention any language features, the missing half is not specified however I have elaborated on what that half may have been. | |
| Nov 11, 2017 at 3:39 | history | edited | Wes Toleman | CC BY-SA 3.0 |
added 224 characters in body
|
| Nov 10, 2017 at 18:15 | comment | added | JimmyJames | @Quentin Right, you can support these things but the language becomes more and more complex and that makes it harder to understand. And this is not contrived. I've made Map classes that wrap ResultSet instances or use reflection to call underlying methods on arbitrary objects. It's OK for different languages to have different design philosophies. I like Python but most of the things I like about it I would never want added to Java. | |
| Nov 10, 2017 at 17:40 | comment | added | Quentin | @JimmyJames interesting, I didn't think about that. This could still be done with a proxy object and some operator overloading (did I rant about operator overloading yet? ;)), but this is getting contrived. I think I've largely made my point :) | |
| Nov 10, 2017 at 17:34 | comment | added | JimmyJames |
@Quentin A map doesn't need to be a container. For example, I can implement a map that has no local memory storage. Perhaps each put is sending data to a web service. What would at() provide in that implementation? You are assuming a concrete implementation but Map is an abstraction.
|
|
| Nov 10, 2017 at 17:25 | comment | added | Quentin |
@JimmyJames hence the "by the way" and parentheses. I'm not the last one to rail against Java, but in all fairness I have used it for some time and have spent most of my time frustratingly bumping into missing stuff that I'm used to, especially references and templates. I don't see how the reference would "break encapsulation" though. A map is just a container, why wouldn't I be able to access and modify my object that I put in?
|
|
| Nov 10, 2017 at 17:19 | comment | added | JimmyJames |
@Quentin 'yuck' would seem to be a judgement, no? Anyway, putIfAbsent would seem to do the trick there. The merge method doesn't seem to be indicated by your use case. Honestly I've long found the Map interface to be deficient. Being able to retrieve the MapEntry by key would eliminate the need for these special-case methods. It's really beyond the scope of comments, but what your approach does is break encapsulation. I think you are missing that these kinds of things create problems on large scale development projects with long lifetimes.
|
|
| Nov 10, 2017 at 17:02 | comment | added | Quentin | @JimmyJames but whether or not the absence of (C++-style) references in Java is a wise choice, the question was "why would womeone call Java half of a language", and this kind of missing pieces is the answer. | |
| Nov 10, 2017 at 17:01 | comment | added | Quentin |
@JimmyJames Indeed, the complete case would be something like auto &v = map.at(key); if(v.something()) v = ...; -- this couldn't be done before merge without performing two lookups, and with merge it requires a complex higher-order function. Not something I'd expect to wield when a reference would have done just fine.
|
|
| Nov 10, 2017 at 16:56 | comment | added | JimmyJames |
@Quentin James Gosling was absolutely aware of this feature and deemed it unnecessary/undesirable. You are free to believe it was a mistake but his peers are few. The best way to set values in a map isn't something I spend a lot of time thinking about but I am curious as to why you need map.at(key) = value when (as far as I can tell) map.put(key, value) would do the exact same thing. The merge method encapsulates a lot more logic than simply setting a value. Is there something about this that I am missing?
|
|
| Nov 10, 2017 at 16:38 | comment | added | Quentin |
@JimmyJames being able to simply write map.at(key) = value instead of stuffing all of your logic backwards in a lambda sounds far from a "fancy trick" IMO. Maybe the fact that something as basic as a reference-to-reference is seen as a "fancy trick" is a problem in itself.
|
|
| Nov 10, 2017 at 15:18 | comment | added | JimmyJames | "In Java you just have the pseudo-object-pointer. By conflating these and eschewing true pointer semantics the object model is less clear." I believe the opposite. Because Java's model is simple, it's more clear. You also need to realize that this simplification allows for things like moving objects around in memory. I don't think Java is perfect. I am aware of it's warts but the simplicity of references passed by value is a plus in my book, not a problem. | |
| Nov 10, 2017 at 15:12 | comment | added | JimmyJames | @supercat I'd like to see a little more clarification on "In C++ it is not unreasonable to expect a reference to be valid and non-null." This seems to imply it's an expectation and not a guarantee but then you imply is a guarantee in the next sentence. On a side note, a non-null constraint is available in java. I wouldn't blame you for considering it a hack. | |
| Nov 10, 2017 at 15:07 | comment | added | JimmyJames | @Quentin Fancy tricks like having references to references can make you feel cool but in real professional software development, these types of 'programming in the small' features (or the lack thereof) have very little impact. | |
| Nov 10, 2017 at 1:32 | comment | added | Wes Toleman | @JimmyJames, I've added more about the semantics of pointers, objects and references. Is that clear yet or should I expand further? | |
| Nov 10, 2017 at 1:30 | history | edited | Wes Toleman | CC BY-SA 3.0 |
Added more about pointer and object semantics
|
| S Nov 10, 2017 at 1:11 | history | suggested | Peter Mortensen | CC BY-SA 3.0 |
Copy edited (e.g. ref. <http://en.wikipedia.org/wiki/C%2B%2B>). (its = possessive, it's = "it is" or "it has". See for example <http://www.wikihow.com/Use-Its-and-It%27s>.)
|
| Nov 10, 2017 at 0:11 | comment | added | Jörg W Mittag |
Can you provide some quotes to support your answer? For example, AFAIK, the page doesn't mention const. It does mention "functional programming", however, the language he uses as example is Scheme, which is not a pure functional language (in fact, the designers of Scheme are careful to avoid the use of the word "function" and talk about "procedures"), so it seems he is using the "first-class subroutines" interpretation of FP and not the "referential transparency" one.
|
|
| Nov 9, 2017 at 21:57 | review | Suggested edits | |||
| S Nov 10, 2017 at 1:11 | |||||
| Nov 9, 2017 at 21:39 | comment | added | supercat | @JimmyJames: On the other hand, some of the more fundamental restrictions of Java and "safe-mode" C# let them offer a very useful guarantee that C++ can't: any reference (what in C++ would be a pointer) that is ever observed to identify a particular object will never be observed to identify anything else. | |
| Nov 9, 2017 at 21:35 | comment | added | supercat | @JimmyJames: Some kinds of useful guarantees cannot be practically offered without imposing certain restrictions. Further, some useful optimizations may require imposing some restrictions. Some languages, however, impose pointless restrictions which don't offer any useful guarantees to programmers and shouldn't be required to perform useful optimizations. Some restrictions are simply bad. | |
| Nov 9, 2017 at 19:29 | comment | added | Quentin |
@JimmyJames the phrase means that, even though all java classes have implicit (yuck, btw) reference semantics, you can't have an actual pointer. For example, there's no way to get a "reference" to a reference. This cripples the language in several places, sometime requiring insane workarounds (see Map.merge when you simply want to update a value in a map).
|
|
| Nov 9, 2017 at 18:02 | comment | added | JimmyJames | This is very confused. Pointers (in the logical sense exist in Java) you just can't screw around with them. The whole point of simplifying the model is to allow for more guarantees. The logic that you can assume more about code in a language will less restrictions is backwards. More restrictions -> more guarantees. | |
| Nov 9, 2017 at 16:52 | review | First posts | |||
| Nov 9, 2017 at 19:15 | |||||
| Nov 9, 2017 at 16:49 | history | answered | Wes Toleman | CC BY-SA 3.0 |