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
-~----------~----~----~----~------~----~------~--~---
