As the article points out, this is not a big cost for the companies involved. Unionisation of the buses is not going to make the slightest bit of difference whatsoever to Google's desire to generate a self-driving vehicle. The market is enormous, so they have all the incentive in the world.

What is going to make a difference to these companies is some degree of collective action. We know that many SV companies have been involved in collection action in the past, with non-compete agreements to keep wages of high-skilled workers low. It is a good thing if the shoe is on the other foot for a while. The only real sad thing is that this is unlikely to spread to where it is really needed -- in the third world sweat shop supply chains.

Nice idea, I suppose, but unfortunately working out whether you really have come up with the goods is complex. Nor is it something that happens all at once; you have many stages of clinical trials, and even after release drugs can get pulled at a later date when we discover that they are not so effective.

So, in practice, there would still be a whole lot of annual reports on how well you're progressing anyway. It's basically the same thing.

TRO I would guess stands for Tail Recursion Optimisation, which is a special case of the Tail Call Optimisation. It is always possible to drop state for the stack after a tail call, even if it not recursive. This allows, for example, implementing mutually recursive functions without blowing up the stack.

Both Scala and Clojure only implement the self-recursive TCO. In general, they both try to compile into Java in a naturalistic way -- so a function call in either compiles to a byte code method call. The JVM is Turing complete, so they could implement anything that they want, but they'd have to loose the close relationship between their language and the JVM. So, they only do this for the tail recursion call. This gets 90% of the benefit for the least effort.

That TCO is implemented by both Scala and Clojure sort of demonstrates the point really. I mean, why would they bother if the Java Compiler did it already?

In fact, both Scala and Clojure implement it in the same way -- they remove the function (method) recursive call. In otherwords, you see a recursive call in Clojure/Scala but there is not one in the byte code. Method calls in Java consume stack. Try the answer that I gave you earlier. Otherwise, can you please show me the part of the JVM spec which describes TCO on the JVM. It has to be there, because TCO changes the way that you program.

There is a nice write-up on Java and how it does not implement TCO here at DrDobbs.

http://www.drdobbs.com/jvm/tai...

RMS never believed this. What he believed is that proprietary desktops would always be less free than Gnu. He's right about this.

I think he is wrong about gud.el, though.

"Stefan"

Nope. It's just not there. I think you mean JVM, anyway, rather than "java language implementation" which is rather ambiguous.

It's not a surprise. Java was never functional. Why have an optimisation which essentially rewrites recursion as a form of iteration, when the programmer is going to use iteration anyway?

This is changing now, I think, that the JVM is becoming more important than Java.

Strictly, Java would never have TCO. It would have to be the JVM. And, no it doesn't have TCO, although, I do believe that there are plans for it. I don't remember where I read that, so don't quote me.

It is for this reason that, for instance, Scala and Clojure both implement their own limited form of TCO (the self-recursive tail-call), which they do by compiling to an iterative form.

It is easy to demonstrate this with a method that calls itself. In java, it will crash with a stack overflow error. With TCO, it should loop indefinately.

"Some one raised in functional programming"

Would a) not have combined a recursion with a side-effect, b) we have been sure to make a tail call and c) probably used higher-order functions anyway.

None of which is relevant. This is poor coding style because this is Java which isn't functional and has no tail call optimisation. But, this is a standard problem with assessment; it can be very hard to come up with good and realistic examples, while limited to the knowledge that the students have at the current time. Try and you might, at times, you show less than optimal code, because to write better code you have to teaching something else entirely.

I am struggling with this. As far as I can say that you are saying you looked at a large code base *once* and you found that it was complicated and you didn't understand it.

Is this not true with most code bases? I mean, I can look back at my own code from a while back, and it takes me quite a while to work out what it is doing. And long-lived code bases can, ironically, be particularly problematic.

The ultimate problem here is the funding problem. Free software is much more adaptable because you don't have to tell anyone what you are going to do with it before you do. But someone still has to pay for it at some time. The strange thing is that people and companies have roads coming to their doors which are maintained by the public, but the same is not true of essential software like OpenSSH.

Yep, it's true there are times when prefix notation is painful. I got used to it years ago, though, so it doesn't really bother me any more. For maths, I agree, it confuses but it's easy to drop that, or use a threading operator for non mathematical code. And it largely absolves me from the hassle of having to think about syntax the rest of the time.

Compromises in lisp as in all things.

Pretty sure that kawa is compiled as it happens, so your distinction between haskell and dynamically typed scripting languages is false.

The parenthesis thing is a bonus for kawa, since it enables advanced syntax tree manipulation of source code both in the editing
environment, and for meta programming. And once nice feature of lisp compared to haskell is that you can do basic I/O without spending
three weeks understanding what the hell a monad is.

Long division -- that is where the divisor is a big number. This is not the same as division in general.

There are quite a few ways (too many, which is an Emacs flaw) of achieving Source Browsing. ECB is a nice example, if you like the full windows environment. Mostly, though, I use ido.el and projectile. It's very quick. Indeed, the ability to move between files with extreme rapidity is one of the things that keeps me on Emacs.

The core of Emacs is very stable, and you get used to do things in certain ways. At times, you need to shake things about a bit and investigate new packages. While this comes with a cost, the benefit of Emacs is that the old ways still work. You won't get forced into a new way of working with each new release, if you are happy with the old.

I do that often, as it happens. I often test my lisp in batch, so I run emacs inside a compilation window. I also use Emacs in batch for some builds of things other than Emacs software. For this, I run make which runs emacs inside a compilation window.

There is a widgetized branch of Emacs which lets you use Emacs as a widget and lets you put widgets into Emacs, so you could probably do it graphically if you really wanted.