On Dec 23, 6:08 pm, James Iry <[email protected]> wrote: > Haskell does not specify a VM.
Yes, but whether or not a language specifies a VM makes such an enormous difference in writing code in that language. Coding close to the metal vs. coding very far away on it, on the other hand.... > > Hmm. So when you say "the C preprocessor is Turing complete" you mean > something entirely different from "the C preprocessor is Turing > complete" and I'm supposed to understand that because....how? It was quite obvious from context. I would be grateful if you'd put down the sniper rifle and instead dove into the meat of the argument. > > baiting is another word for trolling. > The socratic kind of trolling. That is the say: The useful kind. I doubt you were going to publically admit that Java was so much easier to adjust to from the previous mainstream enterprise language without resorting to that. > > [Snip: trivial example of a Point class in scala] > That's the problem with your incessant demand for examples: These trivial examples are exactly what's wrong with the groupthink in the scala camp. That trivial example is somewhat similar in either language (though, by your own admission, they really aren't; in java you'd have setters and getters and in scala you don't really do that). It's also not even remotely close to real world scenarios. Even for real world scenarios, there is pretty big syntactic overlap between C code and its java equivalent. > > Yes, and languages like Haskell and ML that don't have to deal with > Java integration skip on null entirely. Idiomatic Scala code doesn't > use null except when integrating with Java libraries that use it. > Even then, we tend to apply a little sugar to convert nullible values > to Maybes. But none of this is representable in scala's type system, so its just convention. Convention is not something that works very well in enterprises. You can attempt to push stuff like 'types are TitleCased, variables are camelCased, constants are ALL_CAPS), but you won't get much farther. > > That's right. The pace of backwards incompatible changes has to slow > down. So? Nullibility type shouldn't be backwards incompatible > because the design already has to be compatible with Java. That particular one you can probably do. But others, not so much. Let's say for whatever reason that /: and :\ are disliked, and in retrospect it is decided that it would have been better if you manually have to lexically patch in an alias for foldLeft and foldRight. Whatever - some change that is fairly simple, unanimously liked, but not possible without breaking old code. There isn't a (practical) programming language in the world that has avoided that situation, with the arguable exception of lisp. For language level changes, this is ridiculously easy; so easy in fact that javac can do this perfectly well: The -source parameter to javac. However, that is very hard to integrate into your example code (because it implies example code must necessarily include batch files / shell scripts to compile it). A simple 'version' keyword is all that's needed. Simple change. Having versionable libraries is the hard problem here. But even just being able to version the syntax is helpful. Less helpful to everything-is-in-a-library scala, sure, but helpful. Even a limited library versioning scheme only for scala's core libraries is a very easy problem to solve. Generalizing the solution is hard. > Have I made false statements in order to bait you into saying > something? Making false statements is not the only way to troll. In fact, most trolls explicitly do not engage in making false statements. Just misleading ones. The way you've sniped at me about slight factual errors that have virtually no bearing on the point being made is a standard tactic in the troll book. There's your evidence. Links? Just scroll up. > Again, links, evidence, point to the pain spots. > [about scala not being as compatible with java as could have been.] Scala's Lists aren't compatible with java's lists. Scala needs 'views' because without them things aren't properly compatible. Your own say so: > And again, let me repeat, there in fact are incompatibilities. > The > fact that you don't know what they are indicates that you haven't > really looked at the language. Logical fallacy. I've seen more than enough to make valid points. Just because I'm not as good as Odersky at Scala doesn't mean I can make observations about the things I have seen. In fact, I'll turn this around: BECAUSE I've gone through the experience of learning scala whilst having programmed loads of java right before trying to switch, I have more hands on experience for the topic at hand than you do. Perhaps you and other serious scala enthusiasts are a bit too far removed from the java->scala learning curve. > > I understood that. CLI is the open specification for the core of > CLR. Fine. But what was your point about CLI/CLR/.Net/whatever? > That supporting it as well as the JVM inevitably leads to rewriting libraries in a way that makes it harder for java people to adjust. Easier to focus when you're only targeting one JVM. It's a choice one has to make, and I can see good arguments for either situation (focussing on just the JVM vs. cross-compiling to both JVM and CLR). Thisis a simple piece of evidence that java compatibility certainly isn't a holy grail for scala. If it had been, they wouldn't have shot for CLR compatibility. There's some evidence. Here's a link, too: http://www.scala-lang.org/node/168 > > You keep saying this like it was a big deal that they didn't solve > this problem. Links, Evidence. > > Yeah. Which makes scala's decision to allow DSL compliant syntax > > anywhere, complicating its ability to discern programmer's intent when > > the programmer makes mistakes, such a head-scratcher. > > Again, links, evidence. Let Scala be it's own prosecutor. You want links and evidence that Scala supports DSL compliant syntax? Are you serious? Okay. http://www.scala-lang.org/docu/files/ScalaReference.pdf --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
