On Dec 22, 4:11 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > In other regards, haskell and java have far more in common than C++ > and java. Running on a VM is a big one.
You just make stuff up, right? The Haskell spec says nothing about running on a VM and GHC Haskell, the de facto standard, emits machine code as its default. Or do mean interpreters like ghci and Hugs? What are you talking about? >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. You keep making stuff up. The C preprocessor is not Turing complete without reprocessing. http://www.ioccc.org/2001/herrmann1.hint. The C++ template system is Turing complete. http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf > Garbage Collection. Pointer math being a fundamental way of doing > things vs. pointer math not even being allowed. I could go on. All valid points. But Java and C++ are both strictly evaluated, imperative, class based, single dispatch object oriented languages with some procedural features, some RTTI and dynamic casting. Haskell is a pure, lazy, functional language with no RTTI and no dynamic casting (tags on algebraic data types are not RTTI). > different skillset vs. being a good C/C++ programmer, excepting those > programming skills that are useful regardless of language. Take your C++ skills and you have a running start in Java. Take your C ++ skills to Haskell and be lost. Take your C++ skills to Mercury and be so lost you're not even sure there's a map. > 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 I've posted links for most of my existence claims, but naturally had very few for negative universal claims. So far you've had one link to a bug in a tutorial. The bug didn't support your claims about Scala's syntax requiring AI in its compiler error message and you've since not remade that claim. Lists were never broken due to race conditions. They've always been completely immutable. At one point some of the methods had stack issues, but never any race conditions. You might be talking about Streams, which could have race conditions in some library functions because deep in the guts laziness has to be implemented imperatively. > don't think either of us has), and be a little more lenient on > demanding stringent proof. If you make a claim that can be backed up, back it up. It's not that hard. If nothing else it would allow me to know what you're talking about half the time. > 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 It's not that simple. There are deep issues around nullible types and the core calculus of Scala's type system. Here's a discussion on LtU on the general subject (not Scala specific): http://lambda-the-ultimate.org/node/3132. Annotations are one of many ways to deal with the syntactic issue, but syntax is only skin deep - its the semantic issue that's the challenge. > 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 Eh? Scala has evolved. It didn't support annotations, but now it does. It didn't have higher kinded types, but now it does. There's work afoot to support full blown named and optional parameters. 2.8 will likley have virtual classes to simplify a certain style of using abstract types. Here's a change log so you don't make up more FUD about Scala not being able to evolve: http://www.scala-lang.org/node/155 > 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 Shiny right associative methods are a trivial parser thing. Type system changes require careful thought lest you end up with something unsound. Are you trolling? > 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 Yes, you can do that. But it would be contrary to the goal of seamless integration. > 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. Again, see "seamless integration" > Also, scala does loads of things, including (at least for a while), > its own generics, without being compatible with java. Not to mention Scala had generics before Java did. It's hardly surprising if they were incompatible for awhile. They are compatible now. What's your point? > the whole 'we want to deploy to the CLI too!' issue, which makes your > 'but integrating with java is hard' explanation unsatisfactory. Scala Didn't say it was hard. Just said it constrains the design of a language. I don't get your point about CLI. > has already chosen being 'better' over 'being java compatible' for so > many other things. Why should null handling be an exception? Where has Scala team said "screw Java compatibility." Link. Evidence. If there are "so many other things" you should be able to find them quickly. There are a few incompatibilities actually. You should have no trouble finding evidence. And I just said that they're working on a decent nullibility system. > I've mostly figured this out on paper. It's not too hard, because most > libraries don't change API compatibility very often. Really? I can't wait until you publish. That'll be awesome. Maybe the Scala team can use your original work. But until you publish this fantastic finding, is it fair to beat up on Scala because they didn't predict your brilliant contribution to the subject of versioning? > language supported it. Another change that would have been soooo much > more exciting than 'we're DSL compatible!'. The largest amount of time spent in defining, specing, and building Scala has to do with its type system. "DSL compliant" is a syntactic issue and syntactic issues are much easier to deal with. Speaking of which, did you know Scala's formal grammar is slightly smaller than Java's and significantly smaller than C#'s? http://www.reddit.com/r/programming/comments/7evke/scala/c06heaw --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
