Haskell!
3 views
Skip to first unread message
Hairless_ape
Nov 23, 2008, 8:21:38 AM11/23/08
to The Java Posse
I want some talk about Haskell in the Java Posse!
Screw Scala, talk about Haskell instead.
Screw Scala, talk about Haskell instead.
Vince O'Sullivan
Nov 24, 2008, 4:35:57 AM11/24/08
to The Java Posse
On Nov 23, 1:21 pm, Hairless_ape <gantra...@gmail.com> wrote:
> I want some talk about Haskell in the Java Posse!
>
> Screw Scala, talk about Haskell instead.
Forget Haskell. What about Small..."we've had that feature for
> I want some talk about Haskell in the Java Posse!
>
> Screw Scala, talk about Haskell instead.
years"...talk!
Reinier Zwitserloot
Nov 24, 2008, 5:52:52 AM11/24/08
to The Java Posse
Haskell doesn't run on the JVM and has publically stated that it is a
research language which will always side with ideology instead of
practicality, when forced to choose. I commend this approach, but it
also means that Haskell, unlike Scala, has pretty much no chance of
becoming a viable language for java folk to move to.
I personally think Scala is equally academic, regardless of the
Posse's ravings about it, because Scala is a complete opposite to java
in one crucial aspect:
Compiler Warnings.
Java's compiler warnings tend to make sense - in 99% of the cases you
know where you need to look to fix it. Scala's suck. They tend to
point out a completely unrelated error on a line that isn't anywhere
near your actual typo half the time. And this isn't an issue of
improving scalac or the AST builder either: Its an endemic part of
scala itself. All those shiny implicit defs, cartoon swearing
shortcuts, and extreme lenience and flexibility in operators (such as
the . for method calls being optional, or letting methods that end in
a colon be right-associative) means that the problem is fundamental
and unfixable. Its certainly one way to go, but it means that you must
pretty much figure out on your own dime what went wrong. The compiler
just cannot give you meaningful hints, because even the slightest typo
or misunderstanding results in code that is equidistant from a number
of different meanings. When this is true, no amount of compiler smarts
can help you figure out what went wrong. The best Scala can do, with a
very advance AI, is generate a list of different interpretations that
could all have been realisitically meant by the programmer, and
provide a nice frontend for you to browse through these. You'd have to
change the entire basis of how we work with code now (red wavy
underlines don't make much sense if there's a set of different
locations for them) - lots of productivity loss there.
Haskell actually understands this a little, and has added a number of
seemingly arbitrary rules to reduce the complexity of the compiler.
For example, while Haskells type system is extremely latent (it infers
just about every type. So you still have Strings and Lists, but you
never need to type that, the compiler basically traces the time you
create a List and chases the object reference through the entire code
base to assign types. I'm oversimplifying, but you get the point,
hopefully) - but it does ZERO type coercion. "5 == 5.0" isn't legal
haskell code because you can't compare integers and doubles. You must
cast one of them first.
Haskell's current compiler is just as unintelligble if you screw up as
Scala's, but I see a future where Haskell's compiler can give you some
moderately sensical problem solving hints. I do not see this future
for Scala.
research language which will always side with ideology instead of
practicality, when forced to choose. I commend this approach, but it
also means that Haskell, unlike Scala, has pretty much no chance of
becoming a viable language for java folk to move to.
I personally think Scala is equally academic, regardless of the
Posse's ravings about it, because Scala is a complete opposite to java
in one crucial aspect:
Compiler Warnings.
Java's compiler warnings tend to make sense - in 99% of the cases you
know where you need to look to fix it. Scala's suck. They tend to
point out a completely unrelated error on a line that isn't anywhere
near your actual typo half the time. And this isn't an issue of
improving scalac or the AST builder either: Its an endemic part of
scala itself. All those shiny implicit defs, cartoon swearing
shortcuts, and extreme lenience and flexibility in operators (such as
the . for method calls being optional, or letting methods that end in
a colon be right-associative) means that the problem is fundamental
and unfixable. Its certainly one way to go, but it means that you must
pretty much figure out on your own dime what went wrong. The compiler
just cannot give you meaningful hints, because even the slightest typo
or misunderstanding results in code that is equidistant from a number
of different meanings. When this is true, no amount of compiler smarts
can help you figure out what went wrong. The best Scala can do, with a
very advance AI, is generate a list of different interpretations that
could all have been realisitically meant by the programmer, and
provide a nice frontend for you to browse through these. You'd have to
change the entire basis of how we work with code now (red wavy
underlines don't make much sense if there's a set of different
locations for them) - lots of productivity loss there.
Haskell actually understands this a little, and has added a number of
seemingly arbitrary rules to reduce the complexity of the compiler.
For example, while Haskells type system is extremely latent (it infers
just about every type. So you still have Strings and Lists, but you
never need to type that, the compiler basically traces the time you
create a List and chases the object reference through the entire code
base to assign types. I'm oversimplifying, but you get the point,
hopefully) - but it does ZERO type coercion. "5 == 5.0" isn't legal
haskell code because you can't compare integers and doubles. You must
cast one of them first.
Haskell's current compiler is just as unintelligble if you screw up as
Scala's, but I see a future where Haskell's compiler can give you some
moderately sensical problem solving hints. I do not see this future
for Scala.
Peter Becker
Nov 24, 2008, 6:18:20 AM11/24/08
to java...@googlegroups.com
Reinier,
I'm currently collecting opinions on CAL: http://labs.businessobjects.com/cal/
Do you have one?
It seems interesting, it is inspired by Haskell, it has plenty of
docu, it even has an Eclipse plugin with auto-completion. But it seems
otherwise closer to dead -- at least judging from the discussion list
activity and the Google results. But I just started looking into it, I
haven't really done my share of research yet -- I'm really trying to
get someone else to do it :-)
Peter
--
What happened to Schroedinger's cat? My invisible saddled white dragon ate it.
I'm currently collecting opinions on CAL: http://labs.businessobjects.com/cal/
Do you have one?
It seems interesting, it is inspired by Haskell, it has plenty of
docu, it even has an Eclipse plugin with auto-completion. But it seems
otherwise closer to dead -- at least judging from the discussion list
activity and the Google results. But I just started looking into it, I
haven't really done my share of research yet -- I'm really trying to
get someone else to do it :-)
Peter
What happened to Schroedinger's cat? My invisible saddled white dragon ate it.
Reinier Zwitserloot
Nov 24, 2008, 5:55:42 PM11/24/08
to The Java Posse
Hmm. I hear only bad things about SAP. I have only the vaguest of
recollections about the programming language's name, which is somewhat
bad, because it takes a lot of serendipity and an amazing amount of
personal effort to make a programming language famous enough for it to
gather a community (You could build a web framework and evangelise the
crap out of it - Ruby, -or-, you could make a somewhat unique language
and give talks to whomever wants to hear them (Haskell's co-creater,
Simon Peyton-Jones), but suffice to say, the effort usually isn't
worth it.
This simple fact strongly suggests that CAL is not worth your time.
There's a more fundamental problem, though. This problem makes sense,
it's a SAP thing, but as far as I'm concerned its the death knell for
a programming language:
The main site is filled with bullshit bingo.
Exhibit A: The first sentence on the site: "The Quark Framework was
conceived as a suite of technologies to allow the representation of
certain kinds of business logic as reusable, composable pieces."
a.k.a: The Quark Framework makes specific types of programming
problems which I am incapable of describing succinctly easier to
program in a composable, reusable fashion. A goal that every other
programming language this side of 1990 has claimed.
a.k.a.: The Quark Framework is a bit like OO, as far as I can tell
from that idiotic sentence.
a.k.a.: I, a programmer, am talking as if I'm trying to sell this to
management.
a.k.a.: I'm secretly trying to tell my fellow programmers to run the
heck away from this disaster, right now. Go! Go away! Run!
I admit that it does get better from there, but that -really- isn't a
good sign.
recollections about the programming language's name, which is somewhat
bad, because it takes a lot of serendipity and an amazing amount of
personal effort to make a programming language famous enough for it to
gather a community (You could build a web framework and evangelise the
crap out of it - Ruby, -or-, you could make a somewhat unique language
and give talks to whomever wants to hear them (Haskell's co-creater,
Simon Peyton-Jones), but suffice to say, the effort usually isn't
worth it.
This simple fact strongly suggests that CAL is not worth your time.
There's a more fundamental problem, though. This problem makes sense,
it's a SAP thing, but as far as I'm concerned its the death knell for
a programming language:
The main site is filled with bullshit bingo.
Exhibit A: The first sentence on the site: "The Quark Framework was
conceived as a suite of technologies to allow the representation of
certain kinds of business logic as reusable, composable pieces."
a.k.a: The Quark Framework makes specific types of programming
problems which I am incapable of describing succinctly easier to
program in a composable, reusable fashion. A goal that every other
programming language this side of 1990 has claimed.
a.k.a.: The Quark Framework is a bit like OO, as far as I can tell
from that idiotic sentence.
a.k.a.: I, a programmer, am talking as if I'm trying to sell this to
management.
a.k.a.: I'm secretly trying to tell my fellow programmers to run the
heck away from this disaster, right now. Go! Go away! Run!
I admit that it does get better from there, but that -really- isn't a
good sign.
Peter Becker
Nov 24, 2008, 6:12:38 PM11/24/08
to java...@googlegroups.com
On Tue, Nov 25, 2008 at 8:55 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:
>
> Hmm. I hear only bad things about SAP. I have only the vaguest of
> recollections about the programming language's name,
You might mean ABAP.
>
> Hmm. I hear only bad things about SAP. I have only the vaguest of
> recollections about the programming language's name,
> which is somewhat
> bad, because it takes a lot of serendipity and an amazing amount of
> personal effort to make a programming language famous enough for it to
> gather a community (You could build a web framework and evangelise the
> crap out of it - Ruby, -or-, you could make a somewhat unique language
> and give talks to whomever wants to hear them (Haskell's co-creater,
> Simon Peyton-Jones), but suffice to say, the effort usually isn't
> worth it.
that would have some effect, too :-) But they are probably not the
community-types.
> This simple fact strongly suggests that CAL is not worth your time.
> There's a more fundamental problem, though. This problem makes sense,
> it's a SAP thing, but as far as I'm concerned its the death knell for
> a programming language:
>
> The main site is filled with bullshit bingo.
>
> Exhibit A: The first sentence on the site: "The Quark Framework was
> conceived as a suite of technologies to allow the representation of
> certain kinds of business logic as reusable, composable pieces."
>
> a.k.a: The Quark Framework makes specific types of programming
> problems which I am incapable of describing succinctly easier to
> program in a composable, reusable fashion. A goal that every other
> programming language this side of 1990 has claimed.
>
> a.k.a.: The Quark Framework is a bit like OO, as far as I can tell
> from that idiotic sentence.
>
> a.k.a.: I, a programmer, am talking as if I'm trying to sell this to
> management.
>
> a.k.a.: I'm secretly trying to tell my fellow programmers to run the
> heck away from this disaster, right now. Go! Go away! Run!
to state a requirement for the language design that I believe I
understand. Of course you probably won't find "business logic" in a
dictionary, but I'm happy to accept that there can be logic to the way
people do business.
And since it's functional "composable" isn't as blurry as the
OO-version. Not only do you have a composition operation to begin
with, you also don't suffer from the side effects that hurt OO-style
composition.
> I admit that it does get better from there, but that -really- isn't a
> good sign.
community activity that concerns me. From what I've heard it used to
be under a closed source licence and going OSS can mean that the
owners either saw the light or just dumped it.
Peter
Reply all
Reply to author
Forward
0 new messages