Rhinos and Tigers

Nice talk. I'm currently taking a masters on languages engineering just wished some (any?) of my teachers would go anywhere near all this juice you always show in your presentations.

Kind of wonder why you never referred to yacc or antlr in your blog :) Really agree with you on learning new languages. I love it. Ruby, java, python, erlang, haskell, ruby again, prolog, perl. I'm not a guru at haskell but i like it a lot and I'm really thinking in trying scala.

Scala is like ruby and erlang and haskell all together. Sounds delicious.

Rhino on the server? This has been in Ogoglio for two years, though it is limited to the simulator scripts.

You may also find my new project, the Ignant server, interesting.
Concepts: http://tinyurl.com/5nwz24
Prototype:
http://tinyurl.com/5lwtja

rhino.010.jpg:


function assertIntEquals(msg, x, y) {}
testBasic: function() {
assertIntEquals(4, 2 + 2, "addition broken!");
}



That's why you need static typing!

Just kidding :-)

Microsoft is working on the DLR to get dynamic languages talk to each other.

As for Javascript talking to Java and back, IE had this undocumented functionality way back in '99 I think...

Good and long post as usual...

Hello 2008, 1996 is calling, they want their appserver back. Welcome to BroadVision 1998
Been there done that.... Except in 1998 everyone wanted Java and we already had an entire application system that could be scripted in JavaScript

http://www.internetnews.com/dev-news/article.php/55431

Also, ASP has had JavaScript on the server-side since the beginning of ASP. Which is like 15 years or so now. But of course there is no embedded XML, or plans for it either. But through COM you can optimize with C++. Several smart companies do this still today even if this kind of ASP is considered "classic".

Aren't scheme and smalltalk classic? Is it a refusal to die, or withstanding the test of time?

page_failed: actually Scala is a pretty cool language. It's amazingly clever, and as far as I can tell it has all the hallmarks of being written for "real" programming use. I love the implicits and the case classes. But the language is frighteningly huge, so I'll stick with my assertion that it's going to have trouble taking off.

ANTLR's cool - I've been doing stuff with it for years, and I may even try writing an elisp backend for it at some point.

trevorfsmith: sorry, I should have mentioned that lots of folks have been doing it for years.

ajai: check out "LiveConnect" - I think IE may be using something like that, and yes, it's been around a while.

bleached: your url is cut off - can you try resubmitting?

bleached_anus: are you trying to cause me flashbacks?

I'd about convinced myself that I was crazy, thinking I used to write server-side javascript.

I can see it now...

Introducing the Google Web Server Toolkit. Now you can write your server code in Java and have it compiled down to Javascript so you can run it in Rhino on the JVM. Need access to raw platform APIs? Just use JJSJSJNI!

I better stop. I'm getting dizzy...

Hi Steve, love your talks, love your posts.

I wanted to ask if you have actually used Scala for anything semi-serious (a couple thousand kloc)? I have, and while the description of the type system is scary, it is pretty intuitive to use and seldom seems to get in your way. I mean, I like dynamic languages as much as the next guy, but I gotta say Scala's type system works pretty well if you're into that kinda stuff.

Personally, my biggest beef with the language is actually that so much is implicit, it makes it hard to read sometimes.

All the best to you!

You know that you can see the talk on video.
Just go to the conference site, click videos and search for steve yegge.

Steve: thsnks for the transcript. Your blog posts often give food for a language developer's thought.

My question: have you changed your opinion on Groovy since the sokoban shootout, how and why?

This shit rant almost triggered me to respond to the overwhelming amount of under-qualified nonsense... almost.

sigh I guess you'll leave it up to people like us (e.g. the Scala IRC channel, Haskell community, etc.) to respond to all the misconceptions that the learners come to us with sourced from 'guess who'.

The straw man was a delightful classic.

Here's a quiz for you Steve. I have a terminating function that has this signature:

forall A. A -> A

Now write some unit tests for it. You can't, can you? That's because this type signature is called 'once type inhabited'. There is only one implementation for this function. This is called a proof of correctness Steve. Yes, unit tests are a poor man's type system Steve. However, sadly, there is a well known problem which I expect you do not understand called the 'Turing Halting Problem'. This means we cannot obtain a proof for the correctness of the *general* program Steve. So, for some programs we can, but not for all.

That's why we unit test Steve - to get a failed proof of the contraposition of a property of a function; the next best thing after proof of correctness of a function - they serve the same purpose. Now you might dilute your unit tests with some impoverished method (assert this and assert that perhaps?), but this does not take away from the fact that you are indeed seeking out properties of your function.

Quick Steve, which function am I talking about:

f :: forall a. List a -> List a
f [] <-> []
forall x. f [x] <-> [x]
forall x. forall y. f (x ++ y) <-> f y ++ f x

Have you ever looked at automated testing Steve? You know, QuickCheck or Reductio (No, JUnit is not automated Steve, despite the hijacking of the adjective). There is a lot to learn there Steve. You do embrace learning don't you? Are you interested in learning about software correctness verification?


Have you ever seen a type-safe sort Steve? You know, it fails to compile if the result of the function is not a sorted list. Think about it Steve. This is a proof of correctness as opposed to a failed proof of incorrectness (unit tests). Would you like me to elaborate Steve? I'm more than happy to, but it is going to challenge most of what you believe, because it is wrong; vastly wrong and this is fine Steve; I'm not out to correct every idiot in the world, but please think of the noobs; PLEASE, they don't deserve to be misled by an amateur posing to the contrary. It's just not fair to them.

My patience is running thin; I wish you'd get a clue before opening your trap Steve. Please stop it. No really, I am begging you to learn "some stuff" before making wildly erroneous claims about it. It's only fair don't you think?

http://dev.helma.org/ng/Background+and+History/

Helma - java web application server using Rhino for server-side scripting. "Started life in 1998..."

Bernard Devlin

Steve: I think actually trying using Scala a bit more might colour your opinion a bit more favourably. In essence the language specification is complex because of the way that the language works - largely the static typing issue - but also because the language hides so many of those complexities from the coder.

Generally speaking I'd say that Scala's language complexity stems mostly from its focus on being practically useful - the language spec is complex because it lets you use a static language in more-or-less the same way as you use a dynamic one. I don't think the spec document is a good introduction to the language - the best I've seen is the book that is coming out soon (available on one of those pre-release PDF schemes) being written by Odersky and others on the language. It comes much more from the perspective of how you use the language, rather than how its guts work under the hood.

"We can actually get around the problems in practice that you guys say your type system is solving through Good Engineering Practices."
That one made me laugh.
Oh, sure, I'm sure I will not forget to use the fuzzy "Good Engineering Pratices" thing because I'm such a good programmer !
Seriously !
But here's the thing : as a programmer you CAN'T trust yourself ! You can't trust others neither. That's the n. 1 lesson of good engineering !
You need a way of eliminating the basic errors of your code *automaticaly*. Basic error means : things like adding an integer and a string.
That's why you need a type system. Simple.

It's so painful that people, the Java... community, the Java world, has evolved around it. OK? They've said: "Don't use constructors. Constructors are baaaaad."

Steve, interesting post, but I'm not sure that this quote is accurate. There may be some people who take this view, but I don't think they constitute a majority.

Personally, I'm all for constructors. Constructor-based dependency-injection is preferable to using setters.

" 1. you write the code
2. you compile the code
3. you load the code
4. you run the code
5. it doesn't work
6. you back up
7. you change it again"

Hmm. Not when I write Java code. It's more like.

1. you write the code
2. the IDE complains
3. you fix the code
4. you run the code
5. it works

The IDE finds syntax errors, type errors, unused code, null references.

Optionally you have

0. write a test

Peace
-stephan

For those that always bitch about Steve's long posts (I love them long!), I found the video for this talk on Google Video, http://tinyurl.com/6z3ozf

Keep up the good work Stevie :)

Most of the arguments for a JVM are arguments for libraries, maybe like the DLR. Generational garbage collection and threads can mostly be in libraries. Yeah, the generated code has to be written to be compatible with the GC and threads, but that's doable.

The exception is JIT. But if you like JIT, why not just compile to machine code in the first place? Eval will be slower, of course, but for long-running services, machine code is smaller and faster than an app + JVM, often enough.

You might like to take a look at Clojure, as well, if you haven't already. It's a weird Lisp-1 for the JVM, and has both an STM system and something vaguely similar to Erlang message passing. It has also recently become rather fast, and it someone has written a backend for the (Common Lisp) SLIME Emacs thing for it.

Some of the domain-specific language bits you talked about remind me of a PDF on Steps Toward the Reinvention of Programming (First Year Progress Report)I read recently from the Viewpoints Research Institute (headed by Alan Kay). The kind of stuff they talk about suggests that programmers should create their own languages to express the problem domain at hand, and then go solve that problem in the domain itself. For a first year, they have some very intersting, concrete results (e.g. TCP/IP in 200 lines, and Cairo in 500 lines).

Why are you so insecure, dibblego? The condescension didn't make your comment any more convincing dibblego, I promise.

Ah, I was GOING to comment on the whole repeating 'Steve' twice per sentence; I thought it was a cheap shot, though.

Interesting, as always.

(BTW: There's more to Internet Computing than finding The Next Great Language. Visually, thins thing blows chunks. It's difficult enough to encourage people to read the erst of the comments, without the "Leave your comment" box being in the upper left-hand side. But I digress.)

You kinda miss out "beauty."

Now, I'll admit that C++ isn't beautiful. Hell no. Given two years or so (and it's still relevant in the real world, so two years is quite possibly what you'll get), it has an ethereal almost beauty. Which ECMA/Javascript derivatives don't have. They're just plain butt-ugly. We're left with a choice of the most beautiful language that anybody out there will let us program in -- which I would suggest is Python, with all its faults -- or dealing with crap.

Java is full of crap.

Javascript (in all its flavours) is full of crap.

I think you're missing at least two points about Scala.

(1) Like C++ in 1985 or so, you don't have to suck the whole lot up in one go. Nobody but you cares whether the language reference manual could be used as a door-stop for the palace at Nineveh.

(2) There's a huge number of Java prorammers out there who are looking for something slightly less brain-dead. Scala seems to me to be the first realistic JVM language that can give them the option. Think Perl, think Python, thin Ruby if you will. I predict that Scala will do this for the JVM inside the next eighteen months.

I also predict that your version of Rhino will die inside the same period. (Nothing personal -- I just don't see the point of it. Well-crafted, JIT, optimised, server-side glue for morons? Huff it up...)

And you really, really, should stop posting links to things like http://en.wikipedia.org/wiki/Greasemonkey.

That's an exceptionally bad idea for somebody working at Google.

On further prdiction: inside two or thrree years, Google's business model will be dead, precisely because people will block out advertisements.

I am not insecure Michael. I am annoyed when an innocent beginner comes in to the Scala IRC channel with a question that makes no sense whatsoever, because he read some rubbish claims on Steve's blog. I also wish Steve would clue up a bit on the topics he talks about since I expect he is also misleading others. I don't think Steve realises how out-of-his-depth he is, so strong language is necessary to somehow ram the point home.

I hope he will think about my questions and perhaps have a couple of "oh crap, I'm so wrong" moments and subsequently shift position.

All of his arguments have been debunked over and over (mostly because they are so easy to do due to their lack of sophistication), though he continues to ignore them - assumingly because he doesn't understand them - he seems capable of mocking the fool's arguments. I think a bit of brutishness is in order.

If it means I am condescending because I claim that Steve is full of shit and his under-qualified words are detrimental to the programming community, then I accept the charge. I assume the best of Steve and that he will address the truth value of my propositions (though they are very weak at the moment - he ignores the evidence, so I'd I'll only be preaching to the choir) rather than worry about whether his feelings have been hurt by hitherto "condescension".

Aah, the age of pragmatism and anti-intellectualism.

dibblego: I can, off the top of my head, think of two Haskell functions with that type signature. Furthermore, GHC compiles them both without errors (I have tested this).

However, one of them is almost certainly not what you want.

Hi Miles, consider a terminating subset of Haskell. Note that I qualified with "terminating". If I didn't there are infinite implementations.

Anocka said "Basic error means : things like adding an integer and a string."

You obviously haven't ever used C :-)

dibblego: SteveY doesn't need to qualify the things he says, because of the title of his blog: Stevey's Blog **Rants**

You're SUPPOSED to take them with a pinch of salt.

It's a bit like taking Wikipedia articles as their sole source of information - something that some people do, even though they shouldn't.

Chris, That is a very poor excuse for making wildly false claims. I sure hope Steve doesn't try that one.

Can you please inform those who are untrained on this topic that it is nothing more than "a pinch of salt"?

Okay, I'm about halfway through the video, but this obviously needs to be said before I continue:

"It's... you guys know about those talismans? The ones, where, "What's it for?" "To keep tigers away"?"

http://www.snpp.com/episodes/3F20.html
===========================
[Later, a full-force Bear Patrol is on watch. Homer watches proudly.]

Homer: Not a bear in sight. The Bear Patrol must be working like a charm.
Lisa: That's specious reasoning, Dad.
Homer: Thank you, dear.
Lisa: By your logic I could claim that this rock keeps tigers away.
Homer: Oh, how does it work?
Lisa: It doesn't work.
Homer: Uh-huh.
Lisa: It's just a stupid rock.
Homer: Uh-huh.
Lisa: But I don't see any tigers around, do you?
[Homer thinks of this, then pulls out some money]
Homer: Lisa, I want to buy your rock.
[Lisa refuses at first, then takes the exchange]

Alright, you've convinced my to give rhino a whirl. Javascript on the server sounds like a lot of fun.

So I have rhino up and running, and I've played around with the shell for a good 10 minutes. It seems pretty rough compared to say irb or python's shell. No history or tab completion is pretty weak. Also there doesn't seem to be any good builtin introspection tool.

Do you have any suggestions on how to make this better? Are people working to improve the shell, or could it use some more attention?


By the way, thank you for js2-mode. It has significantly improved the javascript development experience at my company (all the developers live emacs).

Hi Mongoose,

Yeah, it's a little rough. I think the very latest version of Rhino may have history and completion, but it's a pretty new addition.

If you're already a JRuby aficionado, then I'm not going to try to sell you on Rhino. It's really more suitable for people who are most familiar with Java and JavaScript syntax.

I'm hoping to open-source some stuff this summer that should improve the interactive shell situation for Rhino a bit. We'll see.

What's your current take on Groovy (& Grails), the coding is very simple & also has success stories (LinkedIn...).Definately deserves attention from you.

dibblego, once you've calmed down a bit, please share with us:

- what the user on the IRC channel asked, and exactly how their question was my fault.

- which of my claims are "erroneous" and "wildly false".

I'm assuming you know the difference between an opinion and something that's formally provable. So I ask you: which of my claims is formally provably false? We're all ears.

Right now it sounds to everyone reading, and I do mean everyone, like you're throwing a tantrum because of a perceived slight, and it isn't helping your credibility.

As it happens, I like Scala, so far at least. But I actually got a note verging on a death threat from a colleague for considering using it at work. This was a smart person at a smart company. In other places I suspect I'd have encountered even harsher resistance.

There's far more at stake here than you realize. For every person trying to advance the cause of Scala, there are a thousand who will fight it to the death. People won't listen to academic arguments over something they feel threatens their livelihood, and most folks feel that new languages (especially complicated ones) do just that.

I've been beaten up and down by coworkers at enough companies over trying to use languages like OCaml and Haskell that I'm not about to stick my neck out for Scala. I'm done with being the flag-bearer for academic static languages. If everyone starts using it, sign me up. But Scala enthusiasts have a much longer road ahead than they could possibly imagine, in trying to make this thing successful.

My primary advice to you, and I'll assume you deserve it, is this: learn marketing. Learn everything there is to know about it. Then learn sales. A good salesman doesn't freak out. A good salesman is calm, funny, friendly, inviting, and persistent as all hell.

You're not off to a good start, but it's not too late to make a change.

We are using helma (helma.org) since 2000, which provides a server side javascript framework (using rhino). I also started to grow the idea of porting the rails framework to helma/rhino, and i was excited about reading about your efforts at google. Would be nice to learn from your project, which is pretty hard as long as it's just "something you would like to open source". maybe there are other ways than open sourcing the whole thing. maybe you could start to share just some parts of it. Would be realy interesting to learn from your work. If you are interested you can take a look at my efforts at: dev.helma.org which relies on helma-ng

I'm sorry, but the Scala argument in Paper Tigers is incorrect. If Java-style static typing catches 90% of the bugs that can be caught with 5x more complex type system, I would say some trade-off for simplicity is acceptable and it is reasonable to just use the simpler type system.

I think types should be optional. ECMAscript actually supports optional types, doesn't it?

The whole argument of static vs dynamic typing seems wrongheaded. It should be all about minimal code size. Normally you want the shortest program possible. But you also want some confidence that your program works, hence you write unit tests. If tigers are too scary, than you can use the optional static typing, write more unit test, etc - all at the cost of increasing code size.

Hi Steve,

We've been trying to write testable javascript at http://guardian.co.uk/ for the last six months, and have come up with some good results (see pluck.js, included on most pages).

I was wondering how you write your tests? I ended up writing a unit testing framework which can be found at [shameless plug]

http://code.google.com/p/rhinounit

If you had a chance I'd appreciate any feedback on that project (marketing or code), or on how you do your stuff.

I also wondered what your approach was to object definition/construction in JS. We ended up going with a quite Java like construct, mainly so the devs didn't have to venture too far from their comfort zone, mixed in with a bunch of object literals.

Finally, what would you do to fix the language? I'd love to get rid of 'this' defaulting to global, and things like that.

Cheers,
Tiest

On the security front, there are actually some very elegant solutions to the problem of running arbitrary untrusted code, namely POLA and capabilities. Check out:

E (http://www.erights.org/): The majority of the modern work on objcap systems has been done with E (it also offers some very nice solutions to distributed computing).

Joe-E (http://code.google.com/p/joe-e/): Objcaps for Java

Caja (http://code.google.com/p/google-caja/): Objcaps for JavaScript (I'm surprised you don't know (or at least didn't mention) this one, as it is an ongoing Google project)

Mark Miller (now at Google Research) wrote a great thesis that is well worth reading.

I find, as both a Scala library author (lift) and a Scala library consumer (a bunch of apps), there's a material difference in how much time and effort the type system takes.

As a library author, the type system requires a lot of work and I often spend a whole day writing very little code, but define complex types (this is especially the case when I'm designing DSLs.)

On the other hand, I find that when I'm consuming libraries, I spend very little time knowing or caring about the type system... it's a lot like coding in Ruby or JavaScript.

I also see lines of code numbers for apps similar to those I saw when I was doing hard-core Rails coding. I see tests that are actually shorter because I'm testing for logic, not for types, method names, etc.

Like Ruby's meta-programming, Scala's type system is complex and powerful. It's used by people who spend time and effort designing things.

On the other hand, library consumers rarely have to care.

Thanks for the blog, which is very entertaining, as always. Let me just take the opportunity to correct a couple of inaccuracies:

You write: Scala is a very strongly typed language for the JVM. It's from researchers in Switzerland; they're professors.

No. Scala is from one EPFL professor and his team. Besides being a professor that person has also done a lot of Java stuff. Among other things he wrote the javac compiler that almost everybody in Java-land uses to this day.

You write: It's from sort of the same school of thought that static typing has evolved with over the last fifteen years in academia: Haskell, SML, Caml, these sorts of H-M functional languages.

Not really. Scala does not have H-M type inference. It adopts closures, pattern matching, and a lot of the other constructs of functional programming, but very little of their types. The bit that tends to scare people (like your Prog Lang doctorate friend) is that it has a very advanced *object-oriented* type system. That's something rather new, so I'm not surprised some people are scared.

You write: The language spec is, like 90 percent about the type system. That's true, but it does not mean what you imply. First, the spec is intended for compiler writers, not for programmers wanting to learn the language. It therefore trades readability for precision. If you want to learn Scala, there are some books coming out soon, including one I co-wrote.

Second, Scala's spec is built around types, because types are the mechanism we chose to speak precisely about programs. Since a spec should do that (speak precisely about programs) types are the natural vehicle for that. Other language specs cover the same ground, but in different terms. I give you an example: Other languages talk about methods and their signatures. The Scala spec talks instead about method types. That's just a notational vehicle, because that way we could get more uniformity in the spec. There are no method types that you can write down in a Scala program; they are purely internal to the spec and the compiler.

You write that there are many types in Scala. Again that's true, but I believe it's conceived to be scary only because people are not used to them. It's a superficial reaction, that usually disappears pretty quickly when people get to know the language a bit better.

People usually are not scared of many different forms of statements or expressions in a language. There's no reason to be scared of many different forms of types either, in particular, because most of them are just abbreviations. For instance, you need not be scared of a ``pair type'' such as
(Int, String) because that's just an abbreviation for the parameterized type Tuple2[Int, String]. Now, if you'd rather not learn new notation you might prefer the parameterized Tuple2 type over the shorthand, but then your programs would look more bloated and ugly. It's a tradeoff between specialized notation / short programs and minimal notation / long programs. Because Scala takes types seriously, it offers specialized notation to make their notation convenient.

Even if you omit all shorthands, the type system of Scala is still pretty powerful. It's certainly nontrivial to specify and to implement. Dynamic languages are much, much simpler to define and to implement (at least as long as performance is secondary). But is that a reason to shun static languages? In the end, it comes down to the question whether one should refuse a powerful tool because one finds it hard to understand all the inner workings of the tool. Other industries have made the step from craftsman to engineer, where more formalized learning lead to higher precision and productivity. It remains to be seen whether the software industry will do the same transition.

-- Martin Odersky

Martin: I totally agree with your corrections, and Steve maybe exaggerated a bit in his presentation (remember that it's actually a transcription of a talk. I know that I for one have a tendency to be more inaccurate while talking, then when writing).

The one part I take offense to is your implicit assumption that dynamic languages equals craftsmanship and Scala equals engineering. I dislike it even more when you polarize the question on a one dimensional value scale.

Yes. Scala is an extremely powerful tool. It has definitely got the potential of being useful in many places . But it's not the end all of computer languages, and it's not a replacement for many of the existing paradigms. Languages without compile time type verification fulfill a very different niche, and I don't see much gain in trying to put them in competition with languages like Scala.

You pose the question if it's valid to shun a powerful tool if you don't understand all the inner workings of it, and yes, in many cases I think you should.

When you need to understand how the exposed type system of Scala works to understand a line of Scala code, and that line utilizes lots of Scala features, it might sometimes be too much. In contrast, dynamic languages generally are very easy to reason about and understand intuitively how they will act, meaning it's easier to be productive both while reading and writing it.

I'm not really arguing about absolutes here, but there are definitely circumstances where Scala should not be used, because of the complexity of the language. The main problem is that a language is never a complete black box. You can't completely separate the inner workings from the outwards behavior, and if you could, then what's the point of having the complicated inner behavior?

Ola, I did not mean to imply that dynamic language programming equals craftsmanship (besides, I have a lot of respect for craftmanship!). What I was aiming at was the all-too-common sentiment that all of programming needs to be dumbed down to be understandable without any intellectual effort. That's not at all the same as programming in a dynamic language. In fact, some aspects of these languages (such as Ruby's meta-programming) look pretty intricate by themselves to be.

You write: You pose the question if it's valid to shun a powerful tool if you don't understand all the inner workings of it, and yes, in many cases I think you should.

I would also refuse such a tool if it meant I could not understand how my program behaves. But for a static type system, I essentially have a theorem prover that tries to find inconsistencies in my program. I need not be able to understand the intricacies of the prover to profit from the error diagnostics it provides.

Let me compare to bridge building: Even if I am not an expert in numerical analysis, I might still use a finite elements package to prove that my bridge will not fall down. I need not understand the intricacies of that package, it's sufficient to trust the people who wrote it.

Likewise, an application programmer can simply trust the type checker to find trouble spots in his or her code, without needing to understand the precise reasoning that led to the diagnostics.

However, as David Pollak has pointed out a couple of messages earlier, things change when you progress from application programmer to library designer. Then you might need to spend more time to get the types right, and you might save time using a dynamic language instead. However, your statically typed library tends to provide more to your clients than the dynamically typed version: Not only the basic functionality but also a set of proven properties (embodied in types) which your clients can use to guide their coding and to find problems in it.

dibblego: Show me a terminating subset of Haskell, and I'll show you a language in which 95% of programmers can get no useful (read: billable) work done. Or better yet, try to explain the difference between structural recursion on data and guarded recursion on codata (and the monads which wrap it all up in a pretty surface syntax) to your average web developer. Then, watch them either ignore you, or die painfully as their head explodes.

Regardless, my sense was that Steve was not attacking Scala so much as he was pointing out how the Scala type system's formality provides the reductio ad absurdum counterproof to the Java's community's long-held disdain for dynamic languages. Arguing for even further adherence to mathematical purity disregards the basic thesis Steve puts forward in almost all of his writing (at least as I read it): namely, that simplicity of mechanism wins over almost everything.

Exposed type systems, aspects, compiler annotations, pragmas, etc., all increase the mental overhead involved in programming. There may be cases where the trade-offs are worthwhile, but every bit of attention taken away from implementing programs is precious, and should be carefully and actively defended.

Martin: OK, now I'm feeling a bit like mr negative here. You might not have done it intentionally, but in your last paragraph you wrote "Other industries have made the step from craftsman to engineer, where more formalized learning lead to higher precision and productivity. It remains to be seen whether the software industry will do the same transition." just after doing a comparison between dynamic languages and more advanced statically typed systems. It came off as the correspondence was intentional, and the part I quote also makes it include a value judgment.

"But for a static type system, I essentially have a theorem prover that tries to find inconsistencies in my program. I need not be able to understand the intricacies of the prover to profit from the error diagnostics it provides." Now, this statement is totally true, as long as you have no failures. But as soon as you have a failure, you need to understand the theorem checker sufficiently to understand why it gives you the failure message and how to correct it. This can be partially rectified with good error messages, but not completely. This brings to mind the lovely examples from H-M style systems where you can get things like "expected signature Int*Int->Int but got Int*Int->Int".

Having a theorem checker that you don't understand why it fails on you means that the benefit is quite small.

The same thing is totally true with your bridge example. Yeah, if you use your finite elements package and it responds negatively, that is just an indication that your bridge probably will fall down at some point. If you don't understand the mathematics behind it you have no idea how to actual fix the problem and strengthen the bridge where needed, or change the angle, or whatever.

Finally, I find that making a distinction between applications and libraries are getting to be more and more of a disservice. If you design an application and don't think like a library designer, you will almost guaranteed write worse code, that someone else will have to maintain. I think that fundamentally there shouldn't be a difference. An application is just a number of libraries glued together, and that means that when writing the components of the application you should approach it as any library development.

Finally, I agree with the sentiment that programming should not be dumbed down. That doesn't mean that you need to complicate the tools. The interactions between seemingly simple components give rise to extreme complexity and possibility for expression - just look at the Lisp family as an extremely simple model.

(And incidentally, the main difference between something with internal complexity, and without it: Ruby's metaprogramming capabilities are extremely simple to understand based on understanding the internals of Ruby (which is quite simple in this area), while understanding the type system of Scala is the inverse: easy on the surface, but gets more complicated if you look at the all the corner cases and the implementation of these.)

Thank you Steve for your response. I will address your points below.

> once you've calmed down a bit

I was never not calm. That you think I was is worrying, because it means you have sidestepped what I have said in favour of how you'd like to perceive my current emotional state.

> what the user on the IRC channel asked, and exactly how their question was my fault.

Let's not concern ourselves with this unless you *really* are interested. It was one example of many. To be honest, this shit rant is far less offensive to the scientific community than many of your others. I'd rather address false claims than attribute blame. I'm merely bringing it to your attention that it is happening (as are other things that you seem unaware of - see below).

> which of my claims are "erroneous" and "wildly false".

Well this is the key point; where shall I begin? I'd like to start right at the beginning; try answering a couple of my questions above. You need to realise that you are significantly undermining a huge body of scientific knowledge here mate. I'm more than happy to introduce it to you. I think Chris Smith said it most succintly in his document "What to Know Before Debating Type Systems". Have you read that? I strongly suggest you do and adopt its recommendations.

> I'm assuming you know the difference between an opinion and something that's formally provable. So I ask you: which of my claims is formally provably false? We're all ears.

This would be fun. Before I get started, could you please find a tutorial of your choosing on formal logic, Goedel's Incompleteness Theorem and the Curry-Howard Isomorphism (off the top of my head - just to get started). I am not being sarcastic here Steve; I love teaching and learning and I hope you do too. A good dose on the topic of the type lambda calculi (of which the untyped lambda calculus is one instance) would also be helpful.

> Right now it sounds to everyone reading, and I do mean everyone, ...

No you don't; you mean "everyone in your little circle". There are many counter-examples to your claim because I am talking to them right now, on IRC, in my office, etc. All of us agree on my position except they believe that I am foolish to bother with pursuing the issue as I am where I am being more optimistic. They seem happy to shrug it off as "just another fool making silly claims on his blog" and I am taking the position of "a smart person making a silly mistake".

Steve, I want to make it clear, I am not referring specifically to this blog post (though it is one that has misled at least one learner), but all of your claims collectively - especially about static type systems and specific programming languages (which brings up a misunderstanding that you have - see below).

That people think I am throwing a tantrum is what I hypothesise to be a symptom of the ages in which we live. I reject this culture completely as do many people who I consider to be of intellect higher than my own. They are just words; use their English meaning instead of imposing the idea of "if I were using those words, I'd be throwing a tantrum, therefore, this person must be too". This narrow-mindedness fills me with sadness.

> As it happens, I like Scala, so far at least. But I actually got a note verging on a death threat from a colleague for considering using it at work. This was a smart person at a smart company. In other places I suspect I'd have encountered even harsher resistance.

Yes Steve, I have worked in large corporations too. They are full of stupid people who are afraid of exercising their brain. You're not one of them Steve - clearly - but you're making a grave mistake and perpetuating this form of anti-intellectualism by failing to acquire the required level of understanding to make the claims that you do. Your intentions are good; your execution is incredibly poor.

> There's far more at stake here than you realize. For every person trying to advance the cause of Scala, there are a thousand who will fight it to the death. People won't listen to academic arguments over something they feel threatens their livelihood, and most folks feel that new languages (especially complicated ones) do just that.

No Steve, I am perfectly aware of "what is at stake". I simply have no ambition whatsoever to have the world use Scala or Haskell or whatever you decide is the so-called "NBL".

Here is how I see it. This industry is full of people who have very sophisticated neurological mechanisms that they employ when faced with "something they don't understand". This is because they have a heavy investment in their self-worth so that the proposition "I don't understand much at all" is threatening to their well being. This is when the aforementioned mechanism is deployed in a variety of forms. Psychologists have spent a great deal of effort studying this behaviour. I concede that this will always be the case and have no ambition to change it.

However, the industry also has some inquisitive people who turn to people like you and I in order to attain a higher understanding. I embrace these people. My most favourite job ever was as a university lecturer; not during class but after class when the truly curious students would probe me for knowledge. They loved it and a couple of them today can even teach me a thing or two; how wonderful!

This is my objective Steve. I don't care about the various programming language memes; "oh, I know how to use Scala or Haskell or O'Caml; they are the best!". I couldn't give two hoots about this behaviour. You might, but I do not. I care about knowledge sharing and I am bothering here because your silly rants prevent this. People internalise and repeat what you say like little myth spreaders. They are not capable of thinking for themselves; again, a symptom of the ages in which we live.

> I've been beaten up and down by coworkers at enough companies over trying to use languages like OCaml and Haskell that I'm not about to stick my neck out for Scala. I'm done with being the flag-bearer for academic static languages. If everyone starts using it, sign me up. But Scala enthusiasts have a much longer road ahead than they could possibly imagine, in trying to make this thing successful.

You are doomed so long as you stay at Google. It is an inherent attribute of these large corporations to perpetuate a culture of anti-think. (btw, please don't give me this "yeah, but Google is different" nonsense). Just wtf is a "Scala enthusiast"? Why are some people so ready to assign a memetic membership? Am I a Scala enthusiast? I use the language quite a lot as I do many other languages, including Java even! I wish to be relieved of any subscription to these silly little clans as do many others that I know for that matter. It's simply a misnomer perpetuated by an overhwhelming majority of amateurs.

> My primary advice to you, and I'll assume you deserve it, is this: learn marketing. Learn everything there is to know about it. Then learn sales. A good salesman doesn't freak out. A good salesman is calm, funny, friendly, inviting, and persistent as all hell.

Thank you for the advice Steve, but please be aware that it would violate my intention. Indeed, I spend a great deal of time in my armchair reading about various topics that I expect are most appropriate to marketing, but to employ them in a way that you intend, would not assist me at all.

> You're not off to a good start, but it's not too late to make a change.

I'm off to a great start; I've asked that you stop making false claims and you have responded in such a way to indicate that you are open to the possibility. I'm wondering if you're ready to take the next step?

PS: rcoder, you have missed the point completely

Either-or fallacy. Static type systems do not prohibit REPL-style iterative programming and testing.

Secondly, I had a presentation at Google I/O as well that provides a counter point. Javascript may well be great for the server, but ironically, if you want the smallest possible download code, that starts up the quickest in the browser with the least latency (that is, best user experience, as opposed to developer experience), than GWT shows how Java does a much better job than Javascript. See http://www.youtube.com/watch?v=2ScPbu8ga1Q, where I demonstrate the reduction of a jQuery-like API from 100+kb down to just 712bytes of compiled Javascript.

dibblego, you may have noticed that Steve asked you if you, dibblego, have any specific points to refute. But dibblego, you evaded and gave Steve a reading list instead. How are we supposed to take you seriously, dibblego, if you can't answer a direct question like that? Well, dibblego?

Honestly, based purely on the overriding tone of condescension I'm inclined to believe dibblego's a troll. Especially the bit about the terminating subset of Haskell. Har! You had me going for a moment there... dibblego.

Yitz,
Steve did ask that and I answered; the answer is yes. I'd like Steve to understand that refutation.

I also asked Steve some questions which are yet to be answered. I hope he will try.

I'm not sure about your comment regarding a terminating subset of Haskell. Do I need to change the example for you? The point is, to provide an answer greater than "one" requires someone to draw on something that does not exist (i.e. _|_). The language is inconsequential. Programming language theorists talk about terminating subsets of turing complete languages all the time.

Ola: Again, I'm sorry to have given the impression that I equated dynamically typed languages with craftsmanship and statically typed languages like Scala with engineering. Believe me, that's not what I wanted to say. The phrases before this comparison said that dynamic languages are simpler to define and implement that statically typed ones. Simplicity is good, and we should go for it whereever feasible. But sometimes we need to invest in a more complex solution, to achieve a goal. For me, a sign of engineering is that one can ponder and evaluate such solutions without dismissing them out of hand as being overly complex.

Martin: thank you for the corrections and overview. I am in the process of learning Scala and look forward to using it more.

Dibblego: Thank you for the slightly less incensed, albeit no less condescending response.

You and I live on different planets, that much is clear. I do know far more about your pretty formalisms than you realize; I've made a detailed study of them for many years. They're just lovely. But I consider their current type-system reifications to be little better than Security Theater in the real world.

Your attitude betrays you as the programming equivalent of a neocon. Your basic mode of operation is fear tactics: trying to scare people into thinking they can't live without your straitjackets, without curtailing their "civil liberties" as programmers; for instance, the liberty to run a program containing code the compiler doesn't like or doesn't understand. Real-world systems are large, and messy, and very much alive. They are living things. Rigorous type-checking is almost always an impediment at some point in the evolution of any system. Yet you advocate refusal to compile!

This approach is not "human-scalable": in systems with hundreds of people contributing code, the daily build will be broken perpetually. This is already crippling many C++ and Java-based organizations; your neoconservative approach would kill them outright. This, I believe, is why your camp has never produced any meaningful real-world software. Oh, you have? Show us! Name *any* ubiquitous piece of software written in one of your languages. The glove is off; the gauntlet is down; the ball is in your court.

We all know what your answer will be.

It's certainly not the case that all static typing aficionados share your fundamentalist bigotry, but there are enough of you out there to poison the well pretty thoroughly.

You have tried to give the impression that you represent all academics, and that they represent all the smart people. As it happens, and I say this for the benefit of our readers, there are many academics who loathe "the static typers", as they're called. The practical utility of the "huge body of scientific knowledge" you refer to is a subject of some controversy even in academia. Your lack of successful software outside ICFP contests doesn't help your cause.

Though for what it's worth, you haven't articulated your concern clearly enough for us to identify a cause. I'm inferring from your outrage that you believe strongly statically-typed languages are much better than their freewheeling peers. But you've also complained indirectly that I'm somehow responsible for decreased student interest in type theory classes. If that's your main complaint, well, we have no disagreement: I think they should take the classes.

But I think your objection is more to my general claim that your languages will never be widely adopted. That's the heart of it, n'est-ce pas?

I stand by my assertion.

I live and work in the real world. It's ugly, but I'm happy there. And I will continue to present real-world viewpoints. I'm not educating people; I'm echoing them! It's a genuine opportunity for you to hear what real people think, what they're saying. But you want me to stop talking, as if somehow I'm the source. Once again, this is a pretty clear neocon-style sentiment: silence those with whom you disagree.

The picture you've painted of "industry's" neurological mechanisms that trigger when one's self-worth is threatened is quite accurate, and, ironically, is also an equally accurate portrayal of your own reactions. Funny how that works, isn't it?

I will continue to treat static type systems as an interesting experiment until you folks have done something interesting and compelling with them. I'm not talking about a shorter way to write QuickSort. Lord knows we have enough of those. When you guys write the world's most popular web browser, or the next iTunes, or a great video game, or a web service my friends and I simply cannot live without -- then I'll pay more attention to you.

And now, I'm happily heading back to my far-left commie pinko liberal Lisp programming.

The problem of many programmers out there is that they did not do enough maths. They lack rigorous thinking. They're the kind of people that say : let's just call the method, i'm sure it's here !
What we need is reliability. The real reliability is the mathematical one. Functional programming brings us closer to it.
Here's a real world example : the electric flight control of the Airbus A380 series is a C program, but the whole code is checked by ASTREE, an ocaml static analyser, to PROVE the absence of Run Time Errors.
You may argue that such a strong reliability is not needed in the "Real World", but I think that the fact that personal computer software is crippled with bugs today is due the industry's inertia.
The thing is, Steve : you are the conservative one. As a no-type-system advocate, you are to static typing programmers what alchemists are to scientists.

I'm confused, how does "ocaml" as an implementation language for a static checker matter to the project language, which was C?

Peace
-stephan

Martin, very good. In that case I totally agree with you.

anocka: very nice fear mongering. Good to bring airplane software in when you want to make it extra scary, even though those systems account for an infinitesimally negligible percentage of all software.

I can't help but look around at all my applications and notice they're not crippled with bugs. In fact, I'll bet you used a computer to enter your comment. And I'll bet even more than NONE of the software between your keyboard and my screen (a long, long path) is written in a strong validating language.

You people are making the whole static-typing camp look bad. You need to keep your trap shut and let Martin do the talking for you; it's the best thing you can do for your cause.

If I get any more of this nonsense from the far-right wing of static typing, I'm closing the comments. I don't want you people hurting yourselves anymore.

Defending scala:

I imagine this comment is belated enough that it will be completely missed. And on top of that, it's responding to a (very long) aside and not the main topic.

But still. You weren't very fair to scala, Stevey.

The big one is that you judged scala based on its specification document, which is indeed very long and complex. However, compare to Ruby, which shares w/ scala a huge syntax in the name of useful & readable shorthand. (Insert crickets chirping here.) Ah, that's right. Ruby never had a formal (or informal) specification! How about Python? Ah, hmmm. I'm not as familiar with the Python community, but I believe no spec exists there either. Javascript -does- have a spec, and a reasonably simple one... but does anyone learn/judge javascript based on its spec? No, they write some code in it.

Since I have, unlike you, written code in scala, here's my assessment:
- The language is a superset of Java. You can restrict yourself to the java-like portions of it and produce the exact same code, but with many, many, fewer keystrokes. If you do this, the big scary type system stays completely out of your way.
- If you wish to go beyond, it has some stupendously useful tools for doing so. E.g.: The (unfortunately-named) "pimp my library" pattern, which gives you the benefits (and then some) of ruby-style open classes over any/all java APIs. Which means you can, with a small amount of work, wrap those hugely verbose enterprisey libraries into a succinct and to-the-point form.
- If you go too far beyond "basic java", you will have to wrestle with understanding some somewhat tricky type issues that have a quite steep learning curve. (In particular: covariance & contravariance.)
- The existence of strong types enables a fantastically powerful style of programming that I will hand-wavingly call 'type-directed metaprogramming.' The most useful and practical example of this, ironically given your opinion that static typing impedes it, comes into play with unit testing: scalacheck (a haskell quickcheck clone) uses static type information to automatically and reasonably-exhaustively test correctness properties. 1000% awesome and way, way better than handwriting unit tests when it's applicable.
- The language is still young, probably too young to be promoting widely. They are still tweaking syntax & semantics from time to time.
- There is an unfortunately huge gap between writing 'novice' business logic code (essentially java w/ a nicer syntax & type inference) and writing 'wizard' library code.
- The community is being settled mainly by static typing Haskell wizard immigrants, because the language allows that style of programming. I think this is unfortunate as their heavy leaning towards monads, category theory, and the like artifically steepens the learning curve.
- Scala's really, really, sweet spot: writing complicated algorithms (particularly functional ones) for the java ecosystem.
- Of course, since it's a kitchen sink language, it has many 'sweet spots'; another is wrapping APIs up into a vastly simplified embedded-dsl-ish form.

Enough rambling from me, although to match your output I'd have to go for another several pages.... ;)

Steve,
I have explicitly asked to be admonished from your agenda and do not accept any assignment to your artifcial cliques. I am not a "static typer" or a "Scala programmer". I use the less well-typed languages too. I also know the purpose of a type system. It is becoming quite apparent that you do not. I implore you to read the aforementioned Chris Smith's take on the "debate" that you think is raging. It is most accurate.

I am beginning to give up; my colleagues can have their laugh at my expense. You throw straw man arguments like it is perfectly acceptable and reasonable. Keep your head in the sand; I'll take care of your victims.

I read about Appjet has built their own virtualization engine for running untrusted code in Rhino. Could you elaborate on the implementation of the sandboxing model that you were talking about?

Excellent talk; it's a shame one has to get assaulted by overzealous, closed-minded types when sharing information on the web, though.

It still amazes me that there's so much religion and so little pragmatism in selecting tools (languages, frameworks, etc.) for software projects. A strict, proven-formally-correct type system might be ideal for a mission-critical flight system. but it's probably too cumbersome for a twitter client. How hard was that?

It's like telling everyone to wear a 50lb. bulletproof vest every day because we should have that kind of protection. But the day you build that protection into my t-shirt, sure I'll wear it every day.

Don't get me wrong, I'm not discounting so-called 'academic languages' at all; I adore them. I've studied my lambda calculi and my Curry-Howard isomorphism, I just don't think we need to tell gymnasts, for instance, to wear bullet-proof vests.

Steve, regarding the advantages of VMs - runtime info available to the JIT etc - I'm surprised in light of this blog of yours that you haven't already put forward this pithy formulation:

Machines are not acceptable machines.

dibblego:

Anyone discounting you is likely doing so because your writing style recommends it, not because they're "anti-intellectual". Ad hominem attacks--among which I include your quite silly claim that Steve, an advanced software engineer with a strong computer science background, doesn't know the Halting Problem--don't really bolster your point, to him or anyone else.

It reminds me of a thread over on Lambda the Ultimate, where a poster was lamenting that he had given a talk and someone had asked him what covariance and contravariance were. This was clearly a guy with an advanced CS degree or two, and I got the distinct feeling that his idea of "properly educated" was that someone should know what he knew, and be able to discuss it at his level. And for CS graduate students, I'm sure he's right; but not for the other 987238974 people who write code.

Unfortunately, that's not really how the world is, nor does it need to be; and it's a lot more helpful to respect what people *do* know and the level they *can* engage on. I think Steve knows quite a lot, even if he lacks your expertise and probably wouldn't always agree with you if he did. So maybe entering the discussion with calmness and courtesy, with a starting premise other than that you are inescapably correct, might generate a more productive conversation.

I'm one of those Java programmers who clings to the static typing even though you rail against it in every post (roughly: "a small codebase is more important than static typing").

Three thoughts that I'd enjoy a response to:

1. A new principle: PAT. "Protect Against Typos." At least 10 times a day I type "nmLevels" instead of "numLevels". I want a language that tells me immediately that I have a typo. I want a wavy red line under the variable name that tells me "TYPO". Eclipse has that. Perl in strict mode at least makes it possible, though I've never seen the red wavy line (although types allow another level of red wavy: type mismatch, which catches more of my typos). What do dynamic languages do about PAT and red wavy lines?

2. Unit tests guard against mistakes at runtime. Programs have a large number of possible runtime paths .. combinatorially many. So, to produce enough unit tests to protect myself against typos (PAT) I potentially have to fight the "curse of dimensionality" (i.e. write a lot of damn tests). However, a compiler has a damn fast way (linear, small-polynomial .. whatever, fast) of protecting me against all possible typos of a certain class. Type checking seems faster and more complete than unit tests.

3. Cross-cutting changes in code. Several times I've had to change a fundamental behavior in a reasonably large system. When it's in a dynamic language (e.g., Python), I grep like a madman and hope that I've stumbled on enough of the runtime paths to be reasonably safe, but there can often be painful misses. In a dynamic language, I can change a signature or make something private, and all of a sudden there's a helpful nag forcing me to at least examine every one of the 500 places that change. How does one gain comfort in cross-cutting changes?

DF

I think Steve's point, that dynamically typed languages can be made to run fast was significantly diluted by his "bash static languages" tangent. Had he stuck to the subject at hand, I don't think people would disagree with his points. I think the entire line of Scala bashing simply was not needed and did not serve to enforce his JS/Rhino on server-side Java VM subject matter.

I also think that there is too much myopia in these static vs dynamic wars. Steve wants to beat back FUD from the static camp that dynamic languages are slow, by saying "look, write a sufficiently advanced JIT and most of the issues go away", but then he adopts a similar myopic attitude that static typing requires batch compilation. The sort of interactive incremental development, the equivalent of evaluating lisp in emacs, he advocates is not outside the realm of typed languages. You can use scala-mode.el today in Emacs and hit ctlr-c/ctrl-b to eval Scala in a running interpreter for example. It's just not available with Java, because no one has bothered to engineer a sufficiently advanced IDE/VM, but the problem is tractable.

Even the issue of "dynamic with optional static typing" and "static typing with optional dynamic" isn't an either-or situation. I could certainly imagine a language, where the type-check policy is library or module specific.

Too often people want to category languages into polar opposite categories, when it's more of a continuum, and it doesn't help to cherry pick anecdotal examples and claim that X is impossible in a static language, or a dynamic language, simply because it hasn't been done, or is hard.

Scala may turn out to be too complex for the Joe Sixpack programmer, but if so, it isn't an indictment of static typing, and claims that "static typing has failed" just seem ludicrous.

"Welcome to BroadVision 1998... we already had an entire application system that could be scripted in JavaScript"

I'm curious. Did anyone get to use this? My employer circa 1999-2000 announced they'd be migrating to it, and I'd just recently learned enough Javascript to be excited about the idea ("Hey! First-class functions! And this prototyping stuff is cool! And objects can be hashes!").

The actual adoption process was slow and pointy-hairedness was becoming endemic, so I left, but I always wondered.

I found Rhino about 18 months ago. Wish I'd found it earlier. I'm excited about its prospects.

Welcome to 1997 :), I was using Netscape Enterprise Server and Server-Side JS ("LiveScript") back then. We were even using it in a 3-tier architecture, with presentation rendered by JS libraries (View/Controller) and making RMI/CORBA calls from JS to Java for the middle tier. This was partially done to work around the memory limits of NES (max-heap of the NES JVM was fixed at something ridiculous like 16mb and unchangeable) We had a Swing-like set of widgets written in JS that would swallow up Swing-like models returned by the RMI calls, e.g. a RMI DAO call would return a TableModel, which would be consumed by a paginated JS table widget.

I do remember being frustrated that LiveScript, IIRC, had a compile step, so you had to recompile JS, and restart the server everytime you made a change. :(

Chris,
I admit that I may have had a jerky knee. After all, I am usually one of those people who just sighs and thinks "oh no, Yegge is talking nonsense again". It is the fact that another newbie came looking for help because he had been misguided that provoked my response.

However, I did not use ad hominem fallacies. I've had to point out what an ad hominem fallacy is before and I'll happily do it again. It should be noted that a statement of the form, "you are clueless" is not an ad hominem. However, a statement of the form "you are clueless, therefore, q" (for some q) is ad hominem. However, it is not to be confused with the converse "p, therefore, you are clueless", which is *not* ad hominem. I may have made statements of this latter form. I'll expand if required

Second, you are using a logical fallacy where you state that (paraphrased) "I should expect Steve to have knowledge of the halting problem because he is advanced/experienced/etc.". It may be true that Steve possesses the properties, however, it has no bearing on the truth value of the proposition at hand.

Steve's gross misunderstandings of proof/correctness verification systems have a direct implication that convinces me that Steve has no idea about the fundamental implications of the halting problem. Not that I wish to pick on Steve at this point; I merely wanted to give him a term that is related to his misunderstanding so he can explore it further if desired.

Of course, it may be the case that Steve has a thorough understanding of the topic at hand and exists in a state of "double-think" i.e. holding two contradicting positions at once, however, although double-think is often a good default candidate on many issues, I have assigned it to "improbable" it out in this case (though, I think it is highly probable that there is double-think in some other context here on this blog).

In any case, I want to put it to rest. Steve has his head comfortably in the sand and I have spent more effort here than I have dealing with Steve's victims. There is nothing more to be gained.

dibblego writes:

It should be noted that a statement of the form, "you are clueless" is not an ad hominem.

You're wrong:

"ad hominem: marked by or being an attack on an opponent's character rather than by an answer to the contentions made"

By the way, you sound remarkably like Tony Morris, you know? If you're not him, you guys should definitely hang out.

Let's all just put some time into learning APL since it solves all these syntax, type, and speed issues by computing rather than programming.

Interesting talk; I hadn't considered the interoperability benefits of the JVM before.

It'd be nice to see your compiler/interpreter work open-sourced; for one thing, more eyes and brains on it might bring it closer to Java speeds, which would promote adoption, since lots of people reject possibly-superior languages due to relative slowness even when it doesn't actually matter in the code they end up writing.

p.s. dibblego:
"It is the fact that another newbie came looking for help because he had been misguided that provoked my response."

I haven't seen the 'misguided' position held by this newbie, in any of your comments (= vitriolic diatribes).
So it's not really fair to say with no qualification at all that "some newbie was misguided and specifically because of you".

Post the misconception he came to you with, as well as a reasonable proof that it is Steve's fault (for apparently promoting incorrect ideas/assumptions).
Otherwise, you'll just continue to sound like a rude, arrogant twat.

http://axiomstack.com/

This is a fully-functional, standalone app server with server-side Javascript using the Rhino interpretor, including built-in data storage with Lucene.

Static typing advocates may be the neocons of the programming world ... but I could swear I just saw you "swift-boat" Scala, no?

Programming language pundit numero uno, Steve Yegge, has a big readership and he knows it. And if JavaScript is going to be the NBL, then something had to be done about this young upstart, Scala.

But unlike John Kerry in the 2004 US presidential election who failed to respond to the Swift-Boat ads, Martin Odersky was on the case, responding in measured tones in a dignified and scholarly manner, striking just the right contrast with the semi-serious rant-style of pundit numero uno.

One can almost hear a slight quaver in the normally cocksure voice of a slightly chastenend super-pundit:

"Martin: thank you for the corrections and overview. I am in the process of learning Scala and look forward to using it more."

What Scala really needs right now is name identification and buzz. All publicity is good publicity, at this point -- even a little swift-boating helps the Scala cause.

Point Scala.

Turning into a nasty biz ... this.

Java has struck the right balance or compromise between static vs. dynamic in terms of performance, dynamic meta-data reflection, re-factoring tools, etc. not too complex (except maybe ??generics??).

Have you tried scala-mode in emacs? You can write scala code and instantly eval/test it, just like elisp. No compile step, no refresh browser step.

Although you say that it will take 10 years of work to get language interoperability, I'd just like to point out that the i OS (formerly the AS/400, or System i) from IBM has what is called an Integrated Language Environment (ILE) that provides a framework within which you can make all kind of cross-language calls, share data, etc. Here is a link to the public documentation.

http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/books/sc415606.pdf

Thank you for this article.

Wonder if Flow-based Programming will help with the language communication issue - Justin Bozonier pointed me at your talk (which he must have attended). I have posted a conversation about this with him at http://www.jpaulmorrison.com/cgi-bin/wiki.pl?JustinTalk . I'd be interested in your reaction to FBP.

That's wiki.pl?JustinTalk - looks like it got chopped :-)

This is a nice talk. Steve does highlight some of the best features provided by Rhino.
He also tries to convince his audience that Javascript is a great language (having himself being convinced). It's a pity that he fails to mention another opensource (built on top of rhino)
called seppia. (http://www.seppia.org)


In my opinion the topics should not always revert around javascript on the serverside vs.
javascript on a web-browser but it should just be emphasized how javascript can well combine its strengths with java.
For example, Seppia uses their relationship to provide an environment to build up applications. But unfortunately not many people know about it...

Steve- I think I've read everything you've written, both here and on the old rants site. I'm a CS major interested in languages and systems programming, and I find that nothing inspires my interest in the field more than your posts.

I imagine that the negativity and rudeness from commenters can be very discouraging, so I'd just like to humbly thank you for your work. I eagerly await your next post.

Thanks! That worked perfectly.Dvd Box Wholesale Tin Containers Cd Box Supplier Flash Drive| Flash Card

good post! -

Waiting to see JavaScript on the GAE via V8

Netscape pioneered server-side JavaScript (called LiveWire) in their Enterprise Server 3.0 product (released in 1997).

http://cgi.netscape.com/newsref/pr/newsrelease334.html

Js being actually nice is a very intriguing idea.

Personally, I haven't seen a language or a web framework as nice as python and django yet.

Jython is being supported by sun (and already has alpha support for 2.5, soon ctypes) and django just hit 1.0, so I'm curious to see how RnR and Jython+Django stack up.

And about threads, shared memory concurrency is very low-level and error prone. Share nothing message passing works great, in both erlang and stackless python and hopefully will get more mainstream.

Flow-Based Programming is also a message-passing approach - using a separately defined network...

I desperately hope that dibblego will have the strength, dedication and goodness of heart, to protect the poor innocent victims of Steves lies and secret agenda.

And, I would like to thank dibblego for helping me understand why trolls are so disdained. I have heard of these trolls, and seen their activity, but never fully grasped how annoying they could be.

And Steve, despite this illusion of being entertained, informed and a tad inspired from your talks, etc, I now must try to figure out how to purge my brain from your filth...wish me luck.

Maybe this has already been addressed, but I've been feeling the need to ask.

You've made reference to developing Rhino on Rails as the framework for a a huge web project. Was that project Google Wave? If not, what the heck kind of project are you doing that it needs a bigger, more powerful framework than Wave does?

The problem of many programmers out there is that they did not do enough maths. They lack rigorous thinking. They're the kind of people that say : let's just call the method, i'm sure it's here !
What we need is reliability. The real reliability is the mathematical one. Functional programming brings us closer to it.
Here's a real world example : the electric flight control of the Airbus A380 series is a C program, but the whole code is checked by ASTREE, an ocaml static analyser, to PROVE the absence of Run Time Errors.
You may argue that such a strong reliability is not needed in the "Real World", but I think that the fact that personal computer software is crippled with bugs today is due the industry's inertia.
The thing is, Steve : you are the conservative one. As a no-type-system advocate, you are to static typing programmers what alchemists are to scientists.
seslisohbet

dibblego:

I know this is an old thread.

You and Tony Morris(are you the same person? You both have the same condending and boring approach to beating down heathens) are a big reason why FP hasn't taken off. The community flat out sucks. It is full of arrogant, self-important, psuedo-intellectuals.

Funny how you can't name a single FP program that is successful. Even two years later, there is nothing noteworthy from the Haskell and Scala camps.

Actually, it is not funny it is sad. You guess are so busy circle jerking to your self-importance to actually do anything of substance.

Yeah. Java as a language sucks, not as bad as PHP, but still quite sucky. But at least there are more than a few significant and successful projects written in it. Scala and Haskell programmers can't say that.

Rhino on the server? This has been in Ogoglio for two years, though it is limited to the simulator scripts.