Hacker News new | ask | show | jobs
by hga 5913 days ago
Microsoft funds a lot of fairly pure research with some of it slipping out into the real world, e.g. Simon Peyton-Jones http://research.microsoft.com/en-us/people/simonpj/ of Glasgow Haskell Compiler fame (and perhaps the most interesting interview in Coders at Work, although that has a lot to do with my familiarity of the work of others in the Lisp and PARC worlds).

One of the biggest complaints about Microsoft Research (or whatever it's called) was how little gets out of the lab into the "real world", with things like F# being recent exceptions, and their funding of the GHC is another example of how they indirectly ship code. Although this mostly legit complaint is precisely your complaint about "not just research shops".

I'm pretty sure IBM is still doing some tech R&D, how much in the coding area I'm not sure, let alone for how long.

Hmmm, has such a beast other than Sun for a brief time ever existed? Obviously Bell Labs, and the UCB Unix project (and some other DARPA projects that had useful code as a required deliverable, e.g. their general VLSI infrastructure push: http://en.wikipedia.org/wiki/VLSI_Project). MIT's exokernel project found itself reified in the real world as Xen, through yet another university lab.

Plus today there are other business models, e.g. look at Clojure (admittedly a one man project for the first few years), the cost of doing a R&D project that ships real world code is fantastically lower than it used to be when e.g. XEROX PARC was doing most? of its work on bit slice (i.e. not too fast) 16 bit Altos with 1-4 banks of 64KB RAM.

I came to the conclusion in the early '80s that some of the differences in the granularity of traditional Lisp and Smalltalk objects (the latter are larger) is in part due to the machines these people did their work on. Lisp has always gone for a big flat address space, Smalltalk had bank switching to contend with an I think that encouraged larger objects (larger than a cons cell, atom, numeric immediate, etc.

The architecture of X has a lot more to do with GAO "most preferred customer" rules/law than anything else.

1 comments

I'll make sure to re-read that interview (Simon Peyton Jones), thanks!

There's certainly something to be said about it being possible -- more so now than ever -- for hackers to work alone, without affiliation with a large R&D organization or academia. Rich Hickey's work has been amazing and will be influential (the persistent immutable data structures are beginning to spread beyond Clojure). It's also interesting that Hickey was able to "bootstrap" himself from consulting rather than full-time work, regaining full rights to his work (not being subject to the all-too-common agreements which require one to give the fruit of all of their ideas to their employer).

Academia is still doing well (Scala from EPFL, some fairly interesting distributed systems work going on at Berkeley) and there are also university-based spin-offs e.g., Stonebraker start-ups (even though I disagree with some of his approaches, it's still great to see companies built to solve difficult and interesting problems). Historically these have been big on the West Coast: Google, Inktomi, Ousterhout's start-ups (Scriptics, Electric Cloud). I haven't seen any emerge recently, but perhaps I haven't been looking in the right places (or have been too cynical about what I saw).

You're welcome.

And to take this further, the recent explosion of new and successful languages shows something right is going on. Around of the turn of the century I was about to give up on this one field in pure CS I like, we seemed to be in a Dark Age where almost everything I could use in practice was of 1960's origin (maybe repackaged and improved a bit ... and, well, it helped (hurt) that I don't like Perl, despite learning it on my own for my own DP, and never took a liking to tcl).

Since then Python really broke out, need I mention Ruby, Clojure has given Lisp a new hope, Haskell is simply fascinating, the ML world is moving out of academia (e.g. F#), and those are just some of the big names (I don't know much about Scala, especially its trajectory).

In terms of getting new stuff into people's hands, this is probably the best period since the '70s for language geeks (I'm not counting C++ and Java, which are firmly based in the '60s/very early '70s).

I also "blame" the dot.com bust, which has required people work smarter (e.g. use Ruby on Rails), not harder (e.g. J2EE).

Re: Scala

This is off topic, I'd suggest playing with Scala. In addition to ML family influences (immutability, pattern matching, tail recursion, static typing with type inference, optional lazy evaluation, etc...) it's also very true to the Smalltalk/Ruby vision: everything is an object, there are Mixins (one can mixin multiple traits, which can contain implementation code unlike Java's interfaces), it's really easy to write your own control structures (despite the lack of macros).

Afaik, one of the implementers Clojure's collections was also Odersky's student at EPFL. So there's talk now if seeing them back in Scala (it can also be done directly e.g., http://github.com/codahale/yoink)

OCaml had shown to me that statically typed languages can still be very expressive and succinct. Scala shows that OO + static typing combination has been unfairly tainted by C++ and Java.

The only "issue" with Scala is that it does aim to be entirely backwards and forwards compatible with Java. There are countless obvious benefits (e.g., being able to use tools such as Jetty's websocket support, freely mixing actors together with j.u.concurrent, using mixins to enrich/"de-boilerplate" existing libraries/APIs), but it does mean that some features aren't as robust as they are elsewhere in ML family (pattern matching is better in OCaml).

It's interesting if F# had to do the same "Faustian Bargain" (perhaps the CLR allows for more flexibility?), I'll have to play with it under Mono.

That being said, there is one 70s/80s concept that I'd like to see more widely used: dynamic typing, with optional static type hints -- to allow for judicious optimization. Common Lisp does this beautifully (at least with SBCL and CMUCL you can actually examine assembly code and see it match what you'd write by hand). Some Smalltalk VMs had been able to do this as well.

Clojure does do type hints, at least for Java interop. Interestingly, HotSpot VM is based on Strongtalk (one such Smalltalk VM). With Clojure re-awakening Strongtalk's ideas while running on what was once its VM, we may be coming full circle :-)

Hopefully off topic but interesting is OK on HN:

I've developed a strong "allergy" for "traditional" OO; perhaps/probably unfairly, since it's based on a lot of C++ work I did in the '90s, and it's as anti-dynamic (not just in typing :-) as you can get in the OO world (insert Alan Kay's comment here (I think it was about C++)) ... but it's also based on my recoiling in distaste from seriously learning Java for some Clojure related stuff, too much accidental complexity. My tastes in languages run a lot more to the Scheme end of things (T may remain my favorite Lisp dialect and language of all time) so my current language interests are more like:

Play with Haskell since there's so much ferment there.

Learn a pre-OCaml ML so that I can grok all the ML based FP literature from the period before Haskell's ascent.

Help liberate Clojure from Java: as part of the Clojure in Clojure effort, work on what I call Turtle Clojure ("It's turtles all the way down"). While a Lisp traditionalist, I'm willing to "Get rid of cons!" (http://news.ycombinator.com/item?id=814632) but I'd like to see what can be done without Java in the middle. I can't imagine that Java tuned GC is optional for something so seriously functional as Clojure, so that's what I'm looking at the most. Maybe an Appel-Ellis-Li GC can be efficient under Xen (it uses VM for read barriers, but traditional OSes don't optimize that path (10,000 cycles circa 1990)).

The thing I find most interesting and challenging in the area of programming is the single address space multi-core SMP problem, which Clojure is very most focused on and is obviously very relevant at a time when I can buy a x86-64 4 core 8 MB shared L3 cache server class chip from Intel for as little as $200.

I have done the mixin thing with Flavors (proto-CLOS) and C++, and, yeah, the pure Java people don't know what they're missing.