[ajaxian]

It probably doesn't matter much to Oracle to stay on good terms w/ the technical community since technical people aren't their customers.

The people who have the budgetary authority to buy Oracle's very expensive products very likely haven't been doing anything technical for many years, if they ever did. Programmers in organizations that use Oracle aren't asked if they want to use Oracle, they're told they're going to use Oracle...

Unless you get your kicks from working on a 30-year-old database written in 80's style C, I don't think there's much appeal to working for Oracle as a programmer.

[scorpion032]

Working for Oracle as a programmer _most often means_ working for innumerable number of ERP and middleware solutions they offer, not the database itself.

[rbanffy]

I don't think that has too much appeal either. Quite frankly, I would prefer the 80's C to that.

[scorpion032]

I don't disagree. :) That was why I quit it, in the first place.

[varjag]

Not arguing with the rest of your post, but what would you write a large-scale DBMS with, these days? Surely not jpython?

[rbanffy]

Perhaps with 2010 style C ;-)

But maybe, just maybe, I would first connect Oracle's prodigious moneyduct into a team writing a kick-ass Lisp compiler and then writing the best RDBMS using Lisp.

One can dream...

[mahmud]

Not an RDBMS, but AllegoGraph is in Lisp and is the most high-end NoSQL out there. Literally, the Oracle of object stores.

[gaius]

If you have an Oracle to hand, have a look at TNSNAMES.ORA and LISTENER.ORA. Greenspun's law applies...

[ajaxian]

Fair point. I didn't intend to diss C, and if one were to write Oracle from scratch today, C is (sadly?) still probably the best option given its performance and portability constraints.

What I had in mind was that for anyone who is technically capable of maintaining the core Oracle DB code base, there are more interesting and rewarding things they could be doing instead.

[b-man]

I would use something like typed racket or haskell for all the critical parts to increase safety. Then I would check the performance bottlenecks and rewrite them in C if needed.

Then I would use a more programmer friendly language on top of that. Something like Scheme, Ruby, Python and the like.

Stratified design, basically.

[rbanffy]

> I would use something like typed racket or haskell for all the critical parts to increase safety

I am not sure about Haskell, but, from my limited experience, Erlang runs at levels very close to C (my C, at least)

[davidw]

In terms of speed? Erlang's not even in the ballpark that C is in. I'm pretty sure Haskell significantly outperforms Erlang as well.

http://shootout.alioth.debian.org/u32/which-programming-lang...

[rbanffy]

Well... At least my C is regarded as very readable ;-)