Occam.

Specifically, http://transterpreter.org

Yes, the language it runs (Occam) is 20 years old. But the language was designed for programs running on dozens to thousands of nodes, and in the transterpreter implementation, there's the possibility of doing this on heterogeneous hardware, where the fast nodes do things like splitting and merging the data set, and the smaller "grunt compute" nodes do the actual work.

Parallel programming is hard, but that's inherent hardness. You can't get around things like memory bandwidth and latency at a programming language level, no matter how much you try. You can only get away from those things by dealing with the fact you have thousands of machines, or tens of thousands.

It's only going to get worse from here on in, as "faster" comes to mean more processors, not higher clock rates. You'll see this: 2 core! 3 core! 4 core! 8 core! and pretty soon (within 10 years) we'll see 64 and 128 core desktop machines, maybe even a revival of unusual architectures like wafter scale integration with 3D optical interconnects (i.e. upward pointing tiny lasers and photocells fabricated on the chip) to handle getting data on and off the processors.

We've seen unambiguously that GIGANTIC data sets have their own value. Google's optimization of their algorithms clearly uses enormous amounts of observed user behavior. Translation efforts with terabyte source cannons. Image integration algorithms like that thing that Microsoft were demonstrating recently... gigantic data sets have power because statistics draw relationships out of the real world, rather than having programmers guessing about what the relationships are.

I strongly suspect that 20 years from now, there are going to be three kinds of application programming:

1> Interface programming

2> Desktop programming (in the sense of programming things which operate on your personal objects - these things are like pens and paper and you have your own.)

3> Infrastructure programming - supercomputer cluster programming (Amazon and Google are supercomputer applications companies) - which will provide yer basic services.

One of the concepts I'm pitching to the military right now is using the massive data sets they have from satellite sources to provide "precision agriculture" support for the developing world. Precision Agriculture in America is tractors with GPS units that vary their fertilizer and pesticide distribution on a meter-by-meter basis (robotic valves consult the dataset as you drive around the land.)

In a developing world context, your farmers get the GPS coordinates for their land tied to their cell phone numbers either by an aid worker, or by their own cell phone company.

Then the USG runs code over their sat data, and comes up with farming recommendations for that plot of land. If the plots are small enough (and they often are) the entire plot is a single precision agriculture cell.

But if you think about the size of the datasets - we're talking about doing this for maybe 20 - 30% of the planet's landmass - and the software to interpret the images is non-trivial and only going to get more complex as modeling of crops and farming practices improves...

Real applications - change the world applications - need parallel supercomputer programming. Occam was right in the same way that Lisp is right but for a different class of problems. That's because Occam is CSP (concurrent sequential processes) and those are a Good Thing. There may need to be refinements to handle the fact we have much faster nodes, but much slower networks, than Occam was originally designed for - but that may also turn out to be a non-issue.

I'm also working on similar stuff around expert systems for primary health care - medical expert systems are already pretty well understood - so the notion is to develop an integrated set of medical practices (these 24 drugs which don't require refrigeration, don't produce overdose easily, and are less than $10 per course) with an expert system which can be accessed both by patients themselves to figure out if their symptoms are problematic or not, and by slightly trained health care workers who would use the systems to figure out what to prescribe from their standard pharmacopoeia.

It's not much, but for the poorest two or three billion, this could be the only health care service they ever see. None of the problems are particularly intractable, but you better bet there's a VAST - and I mean VAST - distributed call center application at the core of this.

Of course, the Right Way to do this is FOLDING@HOME or SETI - we've already proven that public interest supercomputing on a heterogeneous distributed network works.

Now we just need to turn it to something directly lifesaving, rather than indirectly important for broader reasons.

Remember that the richest 50% of the human race have cell phones already, and rumor has it (i.e. I read it on the internet) that phone numbers and internet users in Africa have doubled every year for the past seven years. 10 years from now the network is going to be ubiquitous, even among many of the very, very poorest.

We get a do-over here in our relationship with the developing world. We can't fix farm subsidies, but we can ensure that when they plug into the network for the first time, there is something useful there.

You need to get voted up. And a good way to get voted up is to say something wise or, better yet, funny. The more the better.

That means it pays to be a karma karma karma comedian.

I guess you didn't read this one where I rip a Microsoft lawyer for dumping on Google? http://dondodge.typepad.com/the_next_big_thing/2007/03/micro...

I have been in the software business for 25 years and been on the management teams of 5 startups. I have been at Microsoft less than 3 years and haven't drank the Kool-Aid. However, I don't buy the Microsoft is evil argument either.

I rarely write about Microsoft. In fact I write about Google and lots of startups about 80% of the time. That said, if you want to disagree with my point of view anytime...that is fine. It is a free country.

Don

i dont think marketing to end users is the way to go. like someone said, no one cares about an emergency until they are in one.

market to hospitals. get integrated into their website. when someone calls their ER, make sure the nurse tells them to register on the website.

i think going white label is your best bet.

but yea, this is probably the best "Ask YC about my idea" i've seen since i've joined. you're not selling ER software. you're selling software that helps people wait in line.

think of other markets that could use these tools, and then sell it to them as well.

It's real. We made this in the winter of 2006. Graphic design by Kevin Hale of Wufoo.

Yeah, the reflections are all wrong. Definitely photoshopped.

We advertised in Facebook once. We never met anyone who saw either this ad or the FB ad, so we never bothered again.

Concurrency in web languages is a non-issue, because each request is independent (or should be, if you have a proper shared-nothing architecture). You simply run multiple processes and give each process a full core. Most FastCGI/SCGI webserver modules have functionality built-in to multiplex among backend processes.

Concurrency in the database is more interesting, particularly since that's where the bottleneck is in many web apps. But that's a C/C++ problem, and many DBMS vendors have already invested a large amount of effort into solving it.

Much better!

That part is basically true - to a VC, a person with "substantial industry experience" means an ex-founder or key employee that has already taken a company to tens of millions in revenue. That doesn't mean that only rich founders can start new successful companies (if it did, it'd disqualify Apple, Facebook, Microsoft, HP, etc). It means that you'll have a really difficult time getting VC funding if you don't have that track record, unless you demonstrate some other factor, like massive traffic or stellar recommendations from a founder who does meet those qualifications.

You are 100% correct, the domain name is horrid. ;-) It was chosen at the insistence of the hospital; eventually, we want to promote the service nationally at www.inquicker.com. Is that one any better? :p

I hope no one on reddit hears about it. Would be terribly confusing an overexciting for them.

Users of this service aren't allowed to "get ahead of" anyone. This service only allows people to wait at home rather than waiting in the ER; the wait time is still the same, it's only a bit more comfortable.

Thanks for your input. ;-)

I think 'race' is one way of looking at it. Another way to look at it is that there will be more than one 'winner'. Just like today, I think in the world of tomorrow people will use more than one programming language. So all of the languages that expect to be around tomorrow will need to evolve into languages for controlling concurrent systems on massively parallel architectures.

You are correct in saying that some languages are simply given as winners.

Erlang is a VERY impressive language from a performance standpoint. That said, it really needs to be used in conjunction with some front end UI language to present the results of all of its processing. Make no mistake about it, if one has so much data that one will need say 32 cores to process it, then a clever presentation layer is a must. Another drawback here is that, for those Erlang programmers who are something other than elite, Erlang will handle all of the locking and synchronization on its own. I think experienced senior programmers see where that one is going. That said, the way Erlang implements concurrency is cool. I like simple!

In my opinion, Java is another clear winner here. From Wall Street systems with US$900,000,000,000 a day in transactions flying through them, to medical imaging systems rooting out cancerous pathologies, to petroleum exploration systems trying to find the precise limits to all of that new Cuban oil, Java is at the center. When it comes to handling massive datasets in a maintainable fashion, Java is second only to the C,C++ languages. Some would even say that C or C++ code is less maintainable than Java. I would say they should hire new C programmers.

Lastly, C, C++ and Assembly will always be around because there will always be someone,(Carmack) who wants to outshine everyone else. And we can all agree that nothing flies like an assembly routine. As a bonus, we can get exacting control over concurrency, synchronization and locking. It may be difficult to believe, but this option is attractive to a certain class of hacker.

Concurrency in todays web darlings, Ruby, PHP, and Python will be challenging. I think someone out there will simply come up with a new language. Or the web guys will switch to Erlang over time. They will run into a data size problem though due to the way Erlang implements concurrency at a low level. It will be interesting to watch them problem solve that.

On the front end, it's easy . . . Microsoft wins. Anyone who understands concurrency in an intimate fashion knows the challenges of getting a scripting language like JavaScript to support it in a satisfactory fashion. Do you lock and synchronize for the developer? Do you let him/her? Do you copy the heap and send messages? What about client side memory in a tabbed browser? The questions go on and on. Java may have somewhat of a chance here, depending how things go, but basically Microsoft will continue to have the majority lock.

Oh boy George, here we go again.

For me: n <= ~10,000.

This isn't a very enticing wager--it seems like I have a lot more to lose than to gain. If I set n at, say, $1M, then I might win $1M, which would be nice, or I could end up with basically nothing, which would be devastating. You might have a more interesting wager if $5000 were changed to something more substantial, like $250k.

Is this Trevor's sense of humor, or did he leave his computer unattended in YC's waiting room?