James, I have some advice. Zwitserloot is very clever at constructing a discussion in such a way as to appear to have some clue. He doesn't. Not a bit. He doesn't know the first thing about Scala, Haskell or even Java for that matter. I have evidence of this fact which you (and I!) require before accepting these claims.
The advice is this; don't fall for it. It may look like he is curious, provoking a meaningful discussion where your strong, coherent arguments are certainly going to have him change his mind in light of his extremely poor, sidestepping arguments. It won't happen. The fraudulence will continue. We might speculate why he does this i.e. (?) stupidity, (?)perverse form of pleasure. I don't really know why, but I don't care too much either. I want to warn you that this is an invariable trait of Zwitserloot the moment a little bit of heat is on. His dishonesty in intellectual discourse - while saddening - should be accepted, despite your optimism. Best wishes in future discussion. On Dec 24, 3:08 am, James Iry <[email protected]> wrote: > On Dec 23, 7:39 am, Reinier Zwitserloot <[email protected]> wrote: > > > This really isn't too hard. C is a light syntax sugar over standard > > assembly. Haskell isn't anything like it. > > First, that's not true in spite of everybody saying it. C, for > instance, imposes a strict regime about the stack that assembly > doesn't. Second, when did the discussion become about C. I was > talking about C++, an entirely different language and emphatically not > a sugaring over assembly. But even that doesn't matter because third, > Haskell does not specify a VM. Period. It's an example of you making > false statements either because you don't know or because you're > trolling. > > > 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. > > 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? > > > > > I'll admit I sort of baited you > > baiting is another word for trolling. > > > 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. > > Java: > public class Person { > // normally make these private and add getters and setters but > whatever > public String name; > public int age; > > } > > public class Employee extends Person { > public long employeeId; > > } > > Scala: > class Person { > // can be made private with getters and setters...or not ... Scala > generates that for you > var name : String > var age : Int > > } > > class Employee extends Person { > var employeeId : Long > > } > > Except for surface syntax, the Java programmer is running full speed. > > > 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 > > Have you made any effort to demonstrate its soundness? Do you know > how it integrates with Scala's type system? How do you integrate it > with higher kinded types, and when you do have you opened a can of > worms? Is there a way we can specify nullibility at definition site > instead of usage site? Or is that a bad idea? How does this play > with type inference? Is there a way to only specify nullibility and > let the inferencer figure everything else out? Or would that break > type inference? > > I'm not literally looking for the answers to all those questions. I'm > just saying that they all need thought, and design, and > experimentation. > > If it's as easy to do as you think it is then the Scala team will be > happy to look at a patch. > > > 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 > > 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. > > > 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. > > 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. > > > No, but I get the feeling you are. > > Have I made false statements in order to bait you into saying > something? Links. Evidence. Only one person in this conversation > has done so so far. > > > Scala's goal is 'seamless integration'? Boy, they bungled that one, > > then. > > Again, links, evidence, point to the pain spots. Don't make broad > accusations. Just link. Give examples. Let Scala damn itself. > > 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. But lest I leave everybody in > suspense, there aren't very many and Scala supports a mixed Java/Scala > code base so unless and until those incompatibilites are ironed out, > there are well known ways to create bridges in Java in the few cases > where you run into a problem. > > > > > > 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. > > Please read again. Slowly. Scala had generics before Java did. When > Java's finally came out there was an incompatibility in how they > represented generics in the class files. The Scala team fixed it by > changing how they generated class files. That's how important > integration is to the Scala team. They broke their own backwards > binary compatibility in order to stay binary compatible with Java. > Read that to yourself over and over and over again. And then tell me > how it supports your thesis that "seamless integration" is unimportant > to the Scala team. > > > > > > 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). > > I understood that. CLI is the open specification for the core of > CLR. Fine. But what was your point about CLI/CLR/.Net/whatever? > > > '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. > > You keep saying this like it was a big deal that they didn't solve > this problem. Like somehow it's something that's been widely figured > out and the stupid Scala chumps can't get their act together to bring > something so trivial and obvious into their language. That they've > spent inordinate amounts of time on mere DSL (who needs that?) crap, > when just a couple of those hours could have been allocated to a minor > little API versioning fix. > > > 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. Show > everybody in this group the weak points. Let them judge. They're > adults (mostly). > > > 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. > > Scala is one of a very few languages that has a complete answer to the > expression problem. That's kick ass right there. Scala unifies FP > and OO. That's kick ass. Scala supports a far richer form of modular > composition (function composition and self types and mixins and > abstract type members and soon virtual classes) than the vast majority > of languages in existence. That's kick ass. Scala makes even Java- > style code shrink by a rough factor of 2 and enables a style of coding > that can shrink your source by a factor of 10 where it fits. That's > kick ass. > > Is there another, more elegant language possible? Sure. If it were > to sacrifice a bunch of Java interop then there certainly is. Or if > you want 100% type inference there is. Or if you want functional > purity there is. If you think logical backtracking and unification is > core, then there's another elegant language. Maybe data flows and > parallel streams are the best way to tackle your problem: that'll be > an elegant language there. If you think syntactic metaprogramming is > where it's all at then there's a well known, elegant, syntactic trick > for that; two actually. > > This is it for me in this conversation with you. You've admitted to > making false statements in order to bait a response. I've been > feeding a troll and shame on me for it. > > To everybody else in this group: I can't predict whether Scala will > conquer the enterprise. If I had to bet I would say it will have a > fair amount of penetration, but it won't replace Java. > > The language that replaces Java won't win because of inherent > advantages in the language, but because of a sea change in the kind of > code that has to be built. Historically that's been true. For > instance, sweeping language changes have followed the move from batch > processing to multi-user terminals, from greenscreen terminals to > workstations and desktop apps, and from desktop apps to web apps. > The big change arriving, multi-core programming will have a serious > impact, especially in hard-core data processing, but typical web apps > can already use multiple cores pretty easily and don't really do much > data processing beyond slinging stuff back and forth between SQL and > HTTP. Scala has some advantages in multi-core (both actors and > futures in its core library, a general emphasis on immutability, etc) > but that won't be enough for Scala to take over the world. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
