On Dec 23, 3:10 am, James Iry <[email protected]> wrote: > > 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?
This really isn't too hard. C is a light syntax sugar over standard assembly. Haskell isn't anything like it. > > 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 Do you take everything literally? Sex in the City must have been a real disappointment. Okay, so, the C preprocessor isn't turing complete. An IDE is still massively hampered by its existence. > > All valid points. Let's stop talking about whether haskell and java are more or less different than java and C++. You seem absolutely intent on being right, so, here you go, I'll throw you a bone: Haskell is more different from java that Java is different from C++. Happy now? Doesn't make one lick of difference to the the original point: The differences between Java and C++ are enormous. > > 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. I'll admit I sort of baited you into stating this, but that was my point!! Java is a very different language but a C++ program at least sort of knows what to do and where to go. If you want to be an enterprise language this is an absolute requirement. Scala's ability to give java folk a running start isn't that good. In my opinion it wouldn't have been too hard to make this aspect better. > It's not that simple. Yes, yes it is. Search this forum. Check my blog. I've written up a 100% capable null handling type system for java. It's not really that hard; it's no more complicated than generics. It's really nullness solved the way generics solves it. The premise is simple: Any given type, anywhere (be it as a type itself, or as a type parameter to a generics parameter for example), has a nullity state: Definitely can not hold null. Definitely allows holding null. Could be either way because I really don't know. Could be either way because this is legacy stuff. Those 4 are roughly equivalent to java generics situations: definitely type A. Definitely type B. a type bound (? super T or ? extends T). Raw type. You can handle virtually all situations with no ambiguity. Personally I'd consider no nulls at all with Maybe types and each class knowing its own default value a lot easier on the eyes, but that only works if 'null' is not already established in existing libraries as a valid signal flag for any number of conditions, such as 'not found'. If I had trust in the JSR system being sufficiently open that you can get someplace without dedicating a year of your life to marketing the heck out of your idea, I'd write it up according to the JSR template and submit it. For the full writeup, see: http://www.zwitserloot.com/2008/10/23/non-null-in-static-languages/ Note that the above system is essentially complete and unambiguous for java. That is all that was needed for scala to eliminate null in its own language. > > Eh? Scala has evolved. Yup. And then Martin Odersky wrote a book, and then he said he can't evolve it all willy nilly like he has. On the posse, no less. Whoops. He closed the door on breaking compatibility before scala had a system to gracefully evolve itself without doing so. D'oh. From here on out, a change is either fully backwards compatible (which generally leads to suboptimal implementations of ideas, such as java's generics without reification, which was done only because it was so much easier to do in a backwards compatible fashion), OR, it's a big deal that causes massive stinks and disconnects in the community. Such as py3k. > > 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? No, but I get the feeling you are. > Yes, you can do that. But it would be contrary to the goal of > seamless integration. Scala's goal is 'seamless integration'? Boy, they bungled that one, then. > Scala had generics before Java did. It's hardly surprising if they > were incompatible for awhile. They are compatible now. What's your > point? That Scala's 'seamless integration' schtick isn't that important to scala, evidently. > > Didn't say it was hard. Just said it constrains the design of a > language. I don't get your point about CLI. I typoed, meant to say CLR (Common Language Runtime, .NET's VM). > 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? 'beat up on'? I merely named it as an example of a more important thing, especially to enterprise folk, than shorter syntax and DSL style syntax flexibility. > 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. 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. > > 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 Yes. Again with the 'scala is better than java' bit. Sure, it seems like it might be. It's not nearly as good as what could be, and it's not enough to convince enterprise folk. The goal isn't to be slightly better than java. The goal is to be a kick ass language. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
