On Tue, Nov 25, 2008 at 8:55 AM, Reinier Zwitserloot <[EMAIL PROTECTED]> 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. > 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. You would think that if SAP pushes it into their hordes of consultants 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! I don't mind that sentence that much. It is a bit waffly, but it seems 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. I think the available Docu is actually quite good, it's the lack of 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 > On Nov 24, 12:18 pm, "Peter Becker" <[EMAIL PROTECTED]> wrote: >> 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 >> >> >> >> On Mon, Nov 24, 2008 at 8:52 PM, Reinier Zwitserloot <[EMAIL PROTECTED]> >> wrote: >> >> > 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. >> >> > On Nov 23, 2:21 pm, Hairless_ape <[EMAIL PROTECTED]> wrote: >> >> I want some talk about Haskell in the Java Posse! >> >> >> Screw Scala, talk about Haskell instead. >> >> -- >> What happened to Schroedinger's cat? My invisible saddled white dragon ate >> it. > > > -- What happened to Schroedinger's cat? My invisible saddled white dragon ate it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
