I'm not sure if the concise way to write code is enough to actually get a large set of people to switch from one programming language to another. When java came along it provided a solution to me for my main problems in my programming life: I need a set of good API's that provide me with an easy way to deal with the requirements of the applications I have to build.
Java did that by providing me with an easier way to build web applications, with a common UI framework that was simpler to understand than the MFC framework and was not a mixture of C and C++ code at the same time. Today, my coding challenges are different. I need to write applications that can run in a browser or on the desktop and work with/without specific features on the browser (javascript enabled/disabled, flash availability, java availability). I also need to be able to change aspects of an application quickly (at runtime) and be able to show a clear and easy path to maintain the application in the future without or with limited development efforts (we should not have to deploy the application every time there is a change on some form/etc). Lastly, I need security at a fundamental low level of my programming model so my developers do not have to think about security that much and still develop a secure application. If a new programming language supports these (and potentially other) aspects through the language and the APIs that come with the language I would be thrilled to switch and enthusiastic to learn that new language because it is going to provide me what I need. Ruben On Sun, Dec 21, 2008 at 10:53 AM, peter <[email protected]> wrote: > > plus you can dress up your existing java libs too: > > http://technically.us/code/x/pour-some-sugar-on-httpclient/ > > http://technically.us/code/x/the-awesomeness-of-scala-is-implicit > > > On Dec 21, 12:43 am, Jorge Ortiz <[email protected]> wrote: >> "Scala is a better Java: closures, interfaces that can implement >> methods, Erlang-style concurrency, user-defined control structures, >> and more" >> >> --j >> >> On Dec 19, 8:35 pm, Weiqi Gao <[email protected]> wrote: >> >> >> >> > As long as you smart people are having discussions like this, us >> > enterprise developers will just wait. :) >> >> > I have tried Scala, and felt uncomfortable with it >> > (seehttp://www.weiqigao.com/blog/2008/03/24/scala_still_uncomfortable_aft...). >> > I'm not disagreeing with all the principles behind Scala, but to make >> > it a viable enterprise language requires a lot of investment, retraining >> > of personnel, and integration work, etc. >> >> > The question is very simple: What is Scala? What do I gain by >> > switching to Scala? >> >> > The trick is, you have to distill your answer to fifteen seconds or 140 >> > characters, whichever is shorter. And you have to keep saying it for >> > fifteen years or until everyone agrees with you, whichever is earlier. >> >> > As an example, the message for object-orientation was: "OO is >> > encapsulation, inheritance, and polymorphism. It lets you reuse your >> > code." >> >> > -- >> > Weiqi Gao >> > [email protected]http://www.weiqigao.com/blog/ >> >> > Reinier Zwitserloot wrote: >> > > Replies to everyone, specifically: Michael, Peter, Casper, Gabriel, >> > > Jorge, and James. >> >> > > MICHAEL: >> >> > > I am confused about your continued insistence that 'enterprise folk' >> > > aren't relevant to this discussion. See the name of the topic. But not >> > > just that: >> >> > > enterprise folk are also the main bastion of java. (enterprise folk >> > > are people who program solely because it is their job. They don't toy >> > > with new languages as a hobby, and for them looking into another >> > > programming language isn't worth it unless it has a positive effect on >> > > their paycheck and/or their political power at work.) They aren't just >> > > the majority of programmers, but they are also an untapped market. 90% >> > > of them do Java, 10% of them do Microsoft stuff, and that makes 100%. >> > > Other languages do not intrude here, except maybe a tiny smidgen of >> > > PHP. That's way less competition, compared to the folks who look into >> > > programming languages for fun. Then you've got python, ruby, groovy, >> > > haskell, lisp, lua, fan and many more to compete with. If scala is >> > > going to grow into something big, it either has to be so amazingly >> > > incredible it can handily beat ALL those languages in coolness. That's >> > > a hard sell. If not, then it has to make inroads into those >> > > 'enterprise folk'. Scala is sort of intended as a drop in replacement >> > > for java in many ways (a big one is its compatibility with not just >> > > the JVM, but the way it tries to integrate with Java (the language) by >> > > e.g. generating a nice class with a constructor, toString, equals, >> > > hashCode, and getters, for case classes. No other JVM languages go >> > > this far). It therefore seems that scala is trying to go after this >> > > crowd. >> >> > > And therein lies the relevance of this discussion: It seems they don't >> > > realize they don't have a snowball's chance until someone sits down >> > > and really thinks this one through. >> >> > > PETER: I think you completely missed the point. Sure you can write >> > > ugly code in Scala. If you couldn't do that, it wouldn't be turing >> > > complete :P. But when you do, and we all invariably screw up, scala >> > > bites your head off. This isn't good. And I _claim_ that it isn't easy >> > > to fix. My point -isn't- about 'complicated code'. You could have a >> > > programming language that is unbelievably complex but that still gives >> > > you useful pointers when you make mistakes. As I said, I don't buy >> > > into the 'keep it simple' train of thought, but I do, strongly, buy >> > > into the thought that a real programmer works with an IDE and has >> > > better things to do than debug by eyeball. >> >> > > CASPER: The coalesce operator is an abomination. It should not exist. >> > > Instead, you should have something like: coalesce(a, b, c, d, e), >> > > where coalesce is just a utility method defined in a library. Possibly >> > > a library in java.lang, possibly something that is import staticed by >> > > default, but a library nonetheless. Relegating that stuff to operators >> > > is sillyness - where would you possibly draw the line if 'coalesce' is >> > > useful enough to warrant an operator? Incidentally, scala is one of >> > > the few languages that can completely do coalesce in method form, >> > > because scala has lazy evaluation for parameters (you could write one >> > > in java, but every parameter would be evaluated, whereas in coalesce, >> > > like in e.g. || and &&, when an earlier parameter is not null, the >> > > rest isn't even evaluated). It's also not nearly as common as you >> > > might think. In a language with some closures and a Maybe construct, >> > > for example, it hardly ever happens (because 'null' is then not used >> > > to signal 'not found'). >> >> > > GABRIEL: But you CANT get the car out of sports mode. Scala is set to >> > > sports mode out of the box and you can't fix this (another MAJOR >> > > problem with Scala I tend to harp on about). Stuff like /: and :\ are >> > > always imported. Unless you want to write a boatload of import >> > > statements to 'unimport' these, and include that in every single scala >> > > file you write, you're stuck with those. You're also stuck with the >> > > double-edged sword of operator flexibility, and the use of 'implicit >> > > def' is pretty much forced on you anytime you use certain libraries. >> > > There's no way to tell scala: Not right now with that advanced stuff, >> > > I'm not ready for that. Please don't use those, I'll write just a >> > > little more boilerplate. Or I'll import what I need instead of >> > > starting with a list of cryptically named operators and methods as >> > > long as my leg. As you yourself said, you haven't written much Scala >> > > code. You won't run into these issues until you've written a little >> > > more. >> >> > > JORGE: You make many valid points but few of them are relevant to my >> > > issue. For example, why does it matter that scala produces java >> > > bytecode? I'm complaining specifically about the way scalac doesn't >> > > help you very much. The bytecode produced by scala when your code does >> > > happen to compile, but not the way you imagined it, is sufficiently >> > > 'magic' that it is very difficult to use that to figure out where >> > > things went wrong. You need an intimate understanding of scalac to >> > > even begin to make sense of it all when scalac doesn't do what you >> > > think you meant. (with all due respect to the scalac team, they've >> > > done an AMAZING job making scala code run fast eventhough it really >> > > isn't a way of coding that the JVM was ever designer for!). I'm not >> > > talking about scalac producing 'incorrect' bytecode in the sense of >> > > 'bug'. I'm talking about scala reading your code, which just so >> > > happens to be valid, legal, scala, but it isn't what you think it >> > > means. For example, you swapped a fold operation around but due to a >> > > bunch of implicit defs, the List<Foo> gets translated to a List<Bar> >> > > and the Foo gets translated to a Doohickey<Baz> and those are foldable >> > > as well, and because of all the latent typing, the bad types percolate >> > > up so far that the point where it goes wrong is miles away from the >> > > problem and you just sit there scratching your head. How do you debug >> > > this one? >> >> > > I mentioned that scala has a better type system. The problem lies in >> > > scala's extensive auto-casting AND extensive auto-typing. Those two >> > > together spell trouble. Scala's typing system is very good. But it's >> > > not very explicit, quite unlike java's. Then there are the simple >> > > gimme's that scala does NOT have, such as a 'version' keyword to >> > > specify which scala language version you want to compile with. >> >> > > JAMES: Yes, java's generics inference can create some pretty crazy >> > > error messages and they often point to the wrong place. Touché. Your >> > > specifc mention of 'generic array is created for varargs' is a point >> > > I've harped about, mailed Sun about, mailed java engineers about, and >> > > so far everyone in this newsgroup eventually agreed that javac is >> > > effectively buggy on the topic (you're right, it's in the wrong >> > > place), but everyone at sun just didn't get it and explained to me the >> > > danger. I tried to reply that that wasn't the problem, but no luck :( >> >> > > As far as a practical example, here's one that is so complicated that >> > > a core scala developer (Martin himself?) screwed it up in the official >> > > docs. Trying to make sense of what's going on took me about 30 minutes >> > > of reading specs and chatting about it with the kind folks in >> > > FreeNode's #scala: >> >> > >http://lampsvn.epfl.ch/trac/scala/ticket/1188 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
