Replies inline. On Dec 21, 11:59 pm, James Iry <james...@gmail.com> wrote: > > As compared to Mercury and Haskell and Piet, C++ and Java are nearly > the same language :-)
Not really. In certain regards, such as for example the imperative nature of the languages, C++ and Java are more alike to each other than to e.g. lisp or, say, prolog. In other regards, haskell and java have far more in common than C++ and java. Running on a VM is a big one. Having a preprocessor (which makes a HUGE difference: With a preprocessor in place, it is almost impossible to have a serious toolset, because preprocessors, at least the one C/C++ use, are turing complete. There's a reason java IDEs are far better at introspective stuff than C/C++ IDEs. The language). Garbage Collection. Pointer math being a fundamental way of doing things vs. pointer math not even being allowed. I could go on. The point is: C<-->Java is a major gap, period. Perhaps Java<-- >Haskell is 5005 meters wide whereas C<-->Java is merely 4950 wide, but that's semantics. These aren't even remote close to dialects of each other, and being a good java programmer takes a completely different skillset vs. being a good C/C++ programmer, excepting those programming skills that are useful regardless of language. > > In Java, xor has an operator (^). It was inherited from C. Me, I > would MUCH rather that be exponentiation. Xor as an operator might > have made sense in C, I suppose, but in Java? Not so much. Sure. Java is guilty as charged here. When did 'java does it, so if only I can prove that my language is not crazier than java, it'll be the next big thing' become a valid way of reasoning? I know java. I have absolutely no intention whatsoever of switching to a language that aspires to be about as good. Telling me that Scala fell into the same trap but "It's okay, java's just as screwed up" really isn't going to get you any new souls. Shame. I want scala to become more popular than it is now. (I want a better scala to be created and become more popular even more, but you can't always get what you want, as someone once said). > > When do we get to throw C's operators out and put in new operators? > When can a language recognize that the way it's used is fundamentally > different from the way C is used. Do we seriously have to drag C with > us forever? As java completely broke the ranks with C in almost all ways except superficial syntax rules, the answer is: DUH! Of course we don't. We aren't even doing so now. However, that doesn't mean you can toss learning curve concerns out the window. Just like java left enough common ground for beginners to at least know what they were doing, so should a language that wants to seriously cut into java's market share leave common ground. A language that overhauls the syntax thoroughly and adds a few useful concepts, such as closures, but leaves it at that, certainly seems like a winner to me. By that point in time that language doesn't carry much baggage from C anymore. I don't chalk up 'It's mostly imperative' to C baggage; there are loads of languages, many invented well before C, which are imperative. > > Vals have never been broken. But lists have been. I haven't seen you quite any links either, so lets just both agree not to talk too much bullshit (which so far I don't think either of us has), and be a little more lenient on demanding stringent proof. This is an internet forum, not a thesis submission. > Null is a pain in the ass. It doesn't belong in a statically typed > language. I'll take that banner up with you any day. Unfortunately, > null, with all its ugliness, is necessary for Java integration. Is it? You could toss a proper null-handling typing system into java classes using e.g. annotations (yah, I know, those weren't even a glimmer in someone's eye when scala was designed, but this is part of my point: Scala is not capable of properly evolving itself without breaking itself, which is a missed chance, because it is certainly possible to design such a language. Adding that would have been a far more useful exercise than having shiny operator-looking methods that can right-associate). Once you can analyze classes and adapt their types internally (if not outright 'fix' the class file), then its much easier to just wrap java-originating objects into a Maybe. If that's too complicated, requiring scala users to be explicit about whether or not a java-side reference might have null in it is also a solution. Also, scala does loads of things, including (at least for a while), its own generics, without being compatible with java. Not to mention the whole 'we want to deploy to the CLI too!' issue, which makes your 'but integrating with java is hard' explanation unsatisfactory. Scala has already chosen being 'better' over 'being java compatible' for so many other things. Why should null handling be an exception? > Scala team is working on ways to extend the type system to include > something like Nice's nullable types. That's excellent news. > Nobody, and I mean nobody has figured that out. Not OSGI, not > the .Net platform, not your favorite Linux distribution, not Python, > nobody. If you eliminate languages due to this problem then you're > stuck with nothing. I've mostly figured this out on paper. It's not too hard, because most libraries don't change API compatibility very often. It's a big deal. Thus, forcing API developers to write special code that is capable of creating an older API 'view' of a newer API object, is perfectly reasonable. Write this, or be backwards incompatible (that's what you had before this shiny new language / language update). Fair choice. Given the insane amount of work that goes into core libraries, authoring such as 'backwards API view' is an afterthought. If only the language supported it. Another change that would have been soooo much more exciting than 'we're DSL compatible!'. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
