Slashdot Mirror

A microkernel like MINIX 3 has about 10,000 lines of code. The Linux Kernel has about 20,000,000 lines of code. If you mainly focus on getting only 10,000 lines right, you will have a lot less stress than trying to herd cats on 20,000x more code.

Ideally, for a core kernel maintainer, drivers should be mainly someone else's responsibility (with a separate vetting process) and should be firewalled from any service they don't absolutely need access to. A monolithic kernel just provides too much surface area for mischief to hide (whether intentional or unintentional).

See the list of "reliability policies" here for MINIX (I just included the titles of each section): https://en.wikipedia.org/wiki/...
* Reduce kernel size
* Cage the bugs
* Limit drivers' memory access
* Survive bad pointers
* Tame infinite loops
* Limit damage from buffer overflows
* Restrict access to kernel functions
* Restrict access to I/O ports
* Restrict communication with OS components
* Reincarnate dead or sick drivers
* Integrate interrupts and messages

Focusing a microkernel on a very small number of core services more closely adheres to Single Responsibility Principle compared to the Linux Kernel. That makes the overall kernel simpler to understand even if it may manage many drivers. See:
https://www.infoq.com/presenta...
"Rich Hickey emphasizes simplicity's virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."

It is probably harder to write a microkernel line-for-line compared to the same number of generally less sophisticated lines on average in a monolithic kernel -- but overall the system is much simpler and thus more reliable because the focused microkernel is easier to audit and test separate from all the drivers.

My suggestion is that if Linus Torvalds was focused primarily on the code quality of 10,000 lines of microkernel code he would be less stressed than worrying about the quality of 20,000x as much monolithic kernel code where any badness in those 20,000,000 lines of Linux kernel code could (if you load the driver) infect the whole. Even if Linus still used the same amount of profanity per line of hypothetical Linux microkernel code, his profanity level would still be reduced 10,000x and so essentially round to zero! :-)

A Slashdot story from 2000 on this idea:
"Could Linux Become A Microkernel?"
https://ask.slashdot.org/story...

Reduce bugs + Retain performance... Quite often those two are not aligned.

Apple live in a world where the real value of their product is dependent on 3rd party developers.

(1) iOS apps crashed more than android apps. The common causes for application crashes on iOS and noticed that the majority of crashes are based on poor coding due to legacy syntax which can be corrected. Shown below are some extracts from 2016.

(2) Typical of any virtual machine is the initialization cost of the VM. This means that you need to take a fully compiled approach otherwise you lose perceived performance advantages. JVM code is often more performant than a typical C, written at the same skill level, once the VM is warm/hot and great for server workloads however initialization costs are unavoidable.

Everyone forgets history.

FYI - ios apps crash more than android apps: https://www.techspot.com/news/...

FYI - some infoq: 47% of apps crash more than 1% of the time: https://www.infoq.com/news/201...

Android 2.3 'Gingerbread' had a crash rate of 1.7%, for example, while iOS 6 apps crashed 2.5% of the time.

FYI - AppCoda: https://www.appcoda.com/apteli...

3 Most Frequent iOS Crashes , 23rd May 2016

SIGSEGV (50%) - This signal occurs when your app attempts to access memory that has not been allocated by the program.
NSInvalidArgumentException - This crash occurs when a method is being called on an object that can’t respond to it.
SIGABRT - You’ll see this in your debugger when there is an unhandled exception (see #2). However, in a deployed app SIGABRT appears when there is an assertion failure or abort method called within the app or the operating system. Often raised during asynchronous system method calls (CoreData, accessing files, NSUserDefaults, and other multithreaded system functions).

Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs.

This is what they choose to complain about, fixing the "billion-dollar mistake"? They actually want the language to implicitly accept all messages sent to nil as no-ops with a default return value, regardless of the intended interface, and to allow nil to be passed for any reference parameter even when it makes no sense for the parameter to be omitted?

I would be among the first to promote language-agnostic APIs and allowing the developer to choose the language best suited to the problem domain. However, complaining about the parts of Swift that Apple got right is not very likely to make me more sympathetic to their cause.

Around the 90s is when software development was truly in its prime, despite the shit languages and lacking hardware.

Have you heard of the Software Crisis? It didn't magically go away in the 90's. CASE, RUP, SDLCs, CMM/I, ISO, and project management were all trying to fix the software crisis... and didn't. Based on actual data, Agile is the only thing so far that has had an impact (albeit small):

1995 Data - 17% successful software projects (none "Agile").

2015 Data - 11% successful with waterfall, 39% successful with Agile.

LOL. Here is an example I wrote of what I am talking about that uses those approaches:
https://github.com/pdfernhout/...

The overall discussion here general reminds me of many health discussions on the internet about relative merits of different complex interventions and prescription drugs for various chronic diseases while avoiding discussing the root causes of so much chronic disease from poor nutrition, lack of sunlight, lack of exercise, and various other lifestyle issues (i.e. "Blue Zones" and a "Whole foods, mostly plants diet").

In the same way, people can write decent web apps, but you have to focus on the basics and then build from there. Learn JavaScript (with all its quirks and good parts), learn CSS, and learn HTML. Then use some tools at just the right level of abstraction over that base with some discipline after learning some basic design principles -- including emphasizing simplicity: https://www.infoq.com/presenta...

It is a tribute to Leo Horie's ( https://github.com/lhorie ) brilliance in using his (negative) experience with AngularJS to make something so much simpler as Mithril to address those sorts of root causes. And likewise for innovation by others with inventing HyperScript, Tachyons and Flux.

Complex frameworks (e.g. Angular) typically promise they will let people shortcut all of that learning and choosing -- and the end result is often overly complex systems maintained by developers with limited understanding of both the basics and the framework. And then when things go wrong with bugs in the framework or edge cases the framework does not cover, it can be a painful experience for everyone involved -- until eventually developers go back to the basics.

I went through that myself with Dojo/Dijit, which I though would save me time and ended up costing me more time. Although in the Dojo's toolkit's defense, it originated back when browsers were far less standard-compliant than now, and a lot of innovations in it later became integrated into standards and other libraries and best practices. So there were some good reasons to choose it a decade ago, even if those reasons are much less compelling now. New overly-complex frameworks have no such excuse.

Here is an essay I wrote on my experience moving from Dojo to Mithril:
http://www.pdfernhout.net/on-m...

Yes; thus Rich Hickey's talk on "Simple made Easy": https://www.infoq.com/presenta...
"Rich Hickey emphasizes simplicity's virtues over easiness, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."

I agree on Angular having a lot of "accidental complexity".

I've also run into the "leaky abstraction" issue you reference, like with the Dojo Toolkit and Dijit -- where I ended up spending large amount of time trying to understand why Dijits behaved unexpectedly and to make kludgy workarounds. People hope some frameworks will spare them from learning details of CSS and JavaScript, but in the end, edge cases and bugs mean you still need to learn all that -- as well as an arbitrary framework with its own quirks.

I much prefer the combination of using JavaScript/TypeScript with Mithril/HyperScript, Tachyons, and a Flux-like one-way-data-flow architecture. You need to know JavaScript and CSS somewhat well to use those libraries -- but they are simple enough that they rarely do unexpected things, require long debugging sessions, or get in the way of doing anything advanced that you want to do. Those libraries are not perfect -- just a lot better than something like Angular (which I have to deal with for my day job; see also my related comment below). And those libraries are simple enough that any reasonably good developer could maintain them on their own if absolutely required.

One of the reasons such libraries don't as much attention as they should is precisely because they are so reliable and simple to use. Unlike Angular, neither Mithril or Tachyons *requires* thousands of StackOverflow questions to learn how to use it, debug it, or upgrade it. In a way, picking libraries based on numbers of SO questions or blog posts on it is kind of like picking a car based on how many complaints are filed against the manufacturer with the Better Business Bureau. That's not a 100% valid comparison -- but there is more truth there than one might think at first.

Rust is getting a deal of traction because it stops C or C++ bugs by design. For example the null pointer has been described as the billion dollar mistake. Rust doesn't use pointers in normal safe programming, and so at a stroke it eliminates an extremely common runtime error. Memory allocation is via lifetime tracking in the compiler, so memory leaks and dangling pointers are another problem gone. And things like threads, file io & sockets are RAII so they close when they come out of scope. Lots of things like this add up to less bugs.

Laymen don't need to care. For them it makes writing simple programs just more complicated.

A module is a library, aka jar file, that exports a part of its classes, and keeps the other classes private. Unlike ordinary "private classes" non exported classes are basically invisible for everyone outside of that module.

While you can do that with OSGi, too, OSGI is configured via the .MANIFEST file in a jar file and modules in java 9/project Sigjaw are configured via semi Java looking source code processed by the compiler.

Modules can have dependencies and have version numbers, so module x-1.0 can depend on module y-1.2 etc. How the dependency resolution works and how they support maven or similar repositories, I don't know. I did not bother to "learn" that stuff, as it is now postponed to be released since about 5 years .... yawn.

If you are bored: https://www.infoq.com/java9+mo...

This isn't necessarily an argument against Scala, using it well will have it's challenges, but this is true for most languages. Linkedin went through the same.
Some of the tradeoff's Twitter has had to make have changed. They moved away from Ruby, and for Ruby developers, Scala might actually have been easier to pickup than someone who has been doing Java since 1.4. You have to unlearn more OO practices to use Scala well, but you can write very rubyish or pythonic code in Scala. If I look at a project like finagle now from twitter (compared with gRPC from google), I can sort of see Krikorian's point, but finagle is still one of the best or the best RPC libraries out there if you know Scala. As far as language features, pattern matching, expressive types with inference, var/val immutability are all huge helps to write more concise programs. There are more CS-y features like tail recursion, laziness, um.. monads (any typelevel library), which can hurt or help the complexities in your program. As the Scala community has matured, developers and the language has gotten better at using/refining these features (specializations come to mind) and a few of the good and safe features have become more widespread (swift, rust, jave 8 lambdas)

The learning curve is steep for an OO developer to use the language well, but I like what this article says about the challenges:
https://www.infoq.com/articles...
"As explained in this article all these features are already available in Scala. Developers who want to try them out can explore early builds of Java 8 on most platforms. Alternatively, we recommend taking a look at Scala as a way of preparing for the paradigm shifts to come."

What's being discussed here are platforms that need features SWIFT simply doesn't have, like inline assembler to manipulate hardware specific features

That's not so; the assembly language of Swift is bitcode - which you can embed in Swift code for customized performance.

manual allocation schemes for shared memory (EG reserved blocks that are processed by hardware interrupts)

Although the link is not exactly that case you can use UnsafeMutablePointers for that purpose. Swift is not a garbage collected language, it uses ARC which is already deterministic as to when memory is allocated and released - but you can disable that for code and manually manage memory used.

To use SWIFT you'd need to develop entirely different custom libraries for each platform

Ask Apple how they support various ARM architectures...

No not everything is quite there, but Swift is moving rapidly and the underpinnings were built with the explicit goal that Swift COULD replace C as a language for any purpose, not just another higher level language that really can't apply for low level development. At this point the language is basically locked in but more features will be added over time, including stronger device programming support. That's why taking the time to learn it now means that by the time you understood it well you could probably start doing some hardware development with it... pretty sure LLVM at least and possibly Swift will be involved in some way at Tesla for example. When you are writing code that MUST be stable, like code that controls a car, C is just not going to cut it long term.

Object-oriented is a fad!

I'm sure you meant that as a joke, but it's more correct than you know: https://www.infoq.com/news/201...

Reviewing Microsoft's Automatic Insertion of Telemetry into C++ Binaries

This, I believe, is the story of EVERY migration. It's not necessarily that older is better, or "they don't make them like they used to", but that software development is a bug-prone and arduous process that you will not get right the first time.

This is absolutely the case. Software projects are still incredibly risky. You only have to read the Standish Group's CHAOS report to see how risky these sorts of projects from a management perspective.

The fact that the system is still there doing it's job means that the original project was one of the lucky ones that made it through to a somewhat successful conclusion. You need a very good reason to run that risk again.

In general, just upgrading your dependencies and tool-chain is probably not a sufficient excuse. You need some other compelling reason.

It was pretty darn hard to parse that article to understand what library the author was talking about, but after some research, the issue seems to be a vulnerability in the Apache Commons Collections library.

I don't understand why the OP calls it "Java commons" or why the author of the article goes out of his way to not mention the name "Apache", using it only when copying and pasting code lines but never stating it in prose. Sure, there are lots of people who may have Java, but if the security vulnerability is of the magnitude that is claimed, properly identifying where it is located would be the logical first step.

There is a somewhat better article at InfoQ.com that parses out the original article and describes it more clearly.

Surprised they got modules so quickly. Someday modules will eventually make it into C++ ...

* 2006 http://www.open-std.org/jtc1/s...
* 2014 http://www.open-std.org/jtc1/s...
* 2015 http://www.open-std.org/JTC1/S...
* 2015 (April) https://isocpp.org/files/paper...
* http://www.infoq.com/news/2015...
* http://stackoverflow.com/quest...

I see the "use strict" HACK is still optional ("An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. ") but at least in the case of a class is mandatory ("A ClassBody is always strict code.") Someday Javascript will stop being a shitty language. Sadly it won't be this year ... :-/

I've studied Java (and C#) a little, and have generally been interested and see some value there. But I have never actually had an explicit need for Java, so I never stuck with it long enough to become proficient in it. In particular, mastering Java's libraries is a daunting task. So, if I can live my life without it, I wonder how much worse off the rest of the world would be if it had never been invented?

Like any hypothetical history, we can’t ever know. As TFA says, Java didn’t introduce any new technology. It just bundled them together and marketed them. If not Java, then another language could have done that. However, I think the world would have been a lot better off if this hypothetical language didn’t bring with it Tony Hoare’s Billion Dollar Mistake.

For your life, I think Java validated the idea of building significant systems on a VM. Python was around before Java, but it was considered a slow language for scripts. Java showed that a slow language could be fast enough, and it also made Jython possible and was part of the environment when PyPy was created.

The containers aren't like full-fledged VMs - they're generally running only the processes they need. If you enter it & bring up top, you're quite likely to see 3 processes in there - one for top, one for your shell, and one for your actual app.

You're going to have a slightly larger footprint, yeah - I don't believe you can take advantage of shared libraries to reduce RAM usage (though... possibly in some cases. I'm not sure) - but it's much lighter than running a VM.

http://www.infoq.com/news/2014... if you want some more gory details.

PyPy selectively uses LLVM

Actually you are thinking of Unladen Swallow, the canceled project. They canceled it because they weren't getting the performance boost they for which they had hoped.

http://www.infoq.com/news/2011/03/unladen-swallow

PyPy uses a JIT.

http://pypy.org/features.html

PyPy is a whole new thing, Python written in Python. Their idea was to write a really smart optimizer by taking advantage of the powerful features of a high-level language (Python).

everything in git can be undone

No, not everything can be undone.

In fact it's trivial to permanently trash a Git repo, using nothing but standard commands. We're not even talking about bugs, this is a feature of Git.

This, beyond anything else, is what sets Git apart: Every other source control system created bends over backwards to make sure you never, ever lose history. Sure, some fail but not for lack of trying. Git OTOH, makes blowing away history a feature rather than a bug.

Use the Force, Luca - Jenkins Developer Wipes out a Month of Commits on GitHub

Docker is a different, lightweight layer of abstraction

FTFY. (It's not another abstraction layer on top of VMs. I know you meant that.) The first link above is a pretty good introduction, actually.*

so you instead create a Docker container

You can also create (a) docker-file(s) and build it on the 1000 instances. Sometimes it is easier to distribute 1000 almost the same, but a bit different docker files than preparing a container that parses arguments.
*contrary to the information in the article, you can run more than one service/program in a docker container.

Well, one way, you can monitor heap usage and trend the usage immediately following full GCs.

The other way to look at it is as a function of time.

None of that applies to modern server-centric garbage collection (GC1). "Stop the world while I collect garbage" makes a server worthless if you have 64 GB and GB takes minutes, which is why the default GC for the server SDK hasn't worked that way since mid Java 7.

That's not quite true; even without a "stop the world" collector, you can still look at the amount of time the parallel GC thread is busy. In fact there seems to be quite a bit of information available with tools such as jstat. Perhaps this could help you better understand actual heap use (this is also a problem I face at work -- processes that run out of heap after many hours, expectedly... argh).

Some info about jstat: http://www.cubrid.org/blog/dev...
Info about G1 (although you already seem very familiar with it): http://www.infoq.com/articles/...

From page 1 on a Google search:

http://www.infoq.com/news/2013...

https://www.coursera.org/cours...

There clearly seems to be a failure of communication here. Since you did not like my dumbed down explanation, perhaps you would prefer to hear what Eric Brewer has to say. He seems to have gotten a whole lot of awards for someone who is a "NoSQL nutter".

Eric Brewer on Why Banks are BASE Not ACID - Availability Is Revenue:

Myth: Money is important, so banks must use transactions to keep money safe and consistent, right?

Reality: Banking transactions are inconsistent, particularly for ATMs. ATMs are designed to have a normal case behaviour and a partition mode behaviour. In partition mode Availability is chosen over Consistency.

There are more details here and in many other places.

Acquainting a traditional RDBMS with a phrase like 'lower availability' just highlights to kind of twilight zone you start getting into when talking to any of the NoSQL crowd.

Are you saying you think the CAP theorem is false? I'm assuming large distributed data sets so partitioning is inevitable. According to CAP this means there is a trade off between consistency and availability. RDBMS provide strong consistency so they cannot also provide high availability when there is partitioning.

You didn't work on Mt Gox's systems at any point did you?

Sarcastic ad hominem attacks are an extremely poor substitute for reasoned debate.

I also suggest you read CAP Twelve Years Later: How the "Rules" Have Changed by Eric Brewer. He concludes with:

In general, because of communication delays, the banking system depends not on consistency for correctness, but rather on auditing and compensation. Another example of this is "check kiting," in which a customer withdraws money from multiple branches before they can communicate and then flees. The overdraft will be caught later, perhaps leading to compensation in the form of legal action.

You can claim Eric Brewer is a fucking idiot as much as you want. Eventually all you will do is destroy your own credibility.

Since no one answered this question, I did a simple google search which threw up these results :-

Nimrod: A New Systems Programming Language
Category:Nimrod
Consider the Nimrod Programming Language
What I like about the Nimrod programming language
Araq/Nimrod
Nimrod: A New Approach to Metaprogramming
Nimrod: A new statically typed, compiled programming language which supports metaprogramming

I am just a layman when it comes to Wikipedia editing, but it looks pretty substantial to me. It would appear that the complaint that notability requirements are too strict has just cause.

I believe they also used to use custom chips with extended instruction sets designed to interop well with their custom JVM. Not sure if they still do that.

I could've sworn I'd read that they'd stopped with their hardware work, but I think I was wrong: Appendix A of this page gives the impression (though I can't see it explicitly stated) that they're still doing custom hardware, but their software will work on ordinary Intel/AMD chips as well.

GC doesn't have to suck.

Indeed. It's Sturgeon's Law, but I think the '90%' part might be too low in this case. Major interpreters/'VMs' - even the ones with optimised native-code compilation - have awful GCs. Up until quite recently, Mono was using the Boehm GC. The GCs in OCaml and D show no signs of improving any time soon.

You might want to rethink that: http://www.infoq.com/news/2011...

https://chrome.google.com/webs...

I just wrote a completely open ended HTML5/CSS/JavaScript app on my Samsung $250 Chromebook using the regular user mode and "Caret". I saved versions of the files on the Chromebook and ran them locally from Chrome. The app I wrote uses IndexedDB for local storage of snippets of HTML (which can include JavaScript). The app is intended to support boostrapping a better app by supporting experiments with HTML5/CSS/JavaScript. You can edit text and have it included as a section of HTML on the page. From start to finish (well, it's not really "done") I wrote it on the Chromebook.

I just put the code up on GitHub as an example for you (again using only the Chromebook) :
https://github.com/pdfernhout/...

You can try a demo version here which will store data in your browser: http://rawgithub.com/pdfernhou...

Here is a direct link to the bootstrap.json content to paste in as a start: https://raw.githubusercontent....

See the GitHub repo for basic instructions on how to use it.

Granted, to do C compiling I'd need some tool that converted C to JavaScript in a special way, but more and more such tools exists.
https://github.com/kripken/ems...
http://www.infoq.com/research/...

So, more and more things are possible with Chromebooks or similar devices.

I'm voting for (a) with a helping of very-not-(c), given:

- the comments on https://issues.apache.org/jira...
- this story http://www.infoq.com/news/2014...
- and this twitter conversation https://twitter.com/gstein/sta...

The author who says that this is 'most alarming' is missing one key thing; sometimes people use computers that belong to someone else.

Any company that needs it's employees to be able to use the internet, but also want to be able to detect any employee that is sending documents via the internet to outside of the company would love to use this, as well as have every permission to install this on their own computers. They could then have the employees computers trust the SSL proxy, and it could easily detect any documents being transmitted.

Poul-Henning Kamp covers this at the end of his talk at http://www.infoq.com/presentat... from 14:40 .

I don't think you can credibly claim a big name consultant like Robert C. Martin is not a TDDer, but when you watch interviews like this it seems pretty clear that he would object to your claim. See also the infamous Sudoku contrast between Ron Jeffries' TDD attempts and Peter Norvig's version, assorted comments by Kent Beck ("It's an analysis technique, a design technique, really a technique for structuring all the activities of development."), etc.

I recommend InfoQ.

Looks like that's what's happened to Slashdot. Microsoft seems to own the front page now.

Does anyone know where we can go to discuss real tech?

I am but glad that Microsoft stuff is occasionally featured on the Slashdot front page too. It is as important company as Apple, Samsung, Red Hat, Intel or whatever. I want to hear about MS too: both their successes and embarrassing mistakes.

However in addition to Slashdot I also read a site called InfoQ, they have pretty good stuff too.

Chrome will remove the whole plug-in API:

http://www.infoq.com/news/2013/09/NPAPI-Depricated

So it won't be able to run Java at all.

You could probably download, decompress and process that in Javascript. You might find that if you optimize certain parts with asm.js that it would be about 2x as slow as in native or Java. That might, or might not be acceptable.

Anyway, you can even turn on Java on a per-site basis in Firefox.

Chrome ? I wouldn't count on that:

"By the end of 2014 Google intends to completely remove the Netscape Plug-in API."

http://www.infoq.com/news/2013/09/NPAPI-Depricated

After using JDeveloper and Oracle Middleware for the past 4 months my opinion of Oracle has greatly lowered. Not to mention the forms for EBS don't work with any Java after Oracle changed the vendor name. https://blogs.oracle.com/ptian/entry/solution_for_error_frm_92095

As much as I'd love to give Oracle hell over such a stupid mistake... the Eclipse Foundation (which includes contributions from the likes of Google and IBM) made the same mistake... relying on the java.vendor field to detect which JVM is running.

Or wait for Java 8 to come out, as it has a new date time system (which essentially "rips off" JodaTime, meaning it should be relatively easy to pick up if you have experience with that framework):

• Introducing the New Date and Time API for JDK 8
• Java Time API Now In Java 8

The power of a modern processor to get work done is dominated by cache misses. I mean by a factor of a hundred or more to one unless every bit you are computing lives in cache and nothing ever kicks your code or data's cache line out (including another line of code or data that you need. Because of the way that cache works you can't map every address to every line in cache).

Don't take my word for it though, take Cliff Click's: http://www.infoq.com/presentations/click-crash-course-modern-hardware

Here is a good presentation on what to do: http://www.infoq.com/presentations/Erlang-Scalability

But there is a short description, if you want to innovate you have to write prototype code. If you want somebody else to be able to work on it then you have to make it more beautiful. Then you can have somebody come in and make it fast.

If you break it down and segment who works on what face then you will be able to convince somebody in charge of change, unless he's pointy haired and then your screwed :)

I don't think you'll find many public connections between F# and Haskell.NET/Mondrian. The teams involved were both part of Project 7 (porting 7 different languages to .NET to prove its suitability for various kinds of languages), but the people involved were different - in particular, Mondrian was headed primarily by Eric Meijer. It was more of a spiritual connection - Don Syme picked up the tab of getting an academic functional language on .NET after Haskell guys wrapped it down, and of course it's not the same code at all. Here is an interview with Don where they ask this exact question and he explains the connection. The relevant quote:

Q: I've heard that there was a project where Microsoft started to integrate Haskell on .NET and then it was replaced with the F# project. Is that true? If it's true, why?

A: ... I took what I learned from .NET Generics and saw that there was a chance to do a ML like language fitted very closely with .NET. During this time we [Project 7] had a go doing Haskell for .NET, we actually got a long way in doing that, but in the end there is quite a lot of dissonance between Haskell and .NET. The purity is one aspect of that so you are writing monadic code whenever you use the .NET libraries, which would be perhaps unusual, would lead you to writing more monadic code than you would like. Also, Haskell didn't have any tradition of adding object oriented extensions to Haskell. ...

I've seen it as well, and I recommend seeing everything Rich Hickey on the web. He's incredibly insightful and a great presenter. However, if someone only watches one talk of his, I think the talk from Strange Loop would be the best. Second talk I'd recommend is Are We There Yet?

Rich Hickey's keynote talk from Strange Loop: Simple Made Easy. Unlike the posted fluff article, this talk is easily the most insightful talk you've seen this year, or your money back.

Yes, I think the biggest and foremost problem would be upsetting the status quo. After I wrote the above comment, I researched a bit and found this link, which is somewhat inline with my view.

First, an actual link to the language's site.

Second, isn't it time we stop reinventing the same language over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Are We There Yet?.

First, an actual organism is making a reply.

Second, isn't it time we stop breeding the same species over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Creationism Evolved.

( Good luck with your Stagnation & resulting Extinction, I choose to Adapt and Evolve -- Even if this means some small efforts are wasted in dead ends along the way. )

First, an actual link to the language's site.

Second, isn't it time we stop reinventing the same language over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Are We There Yet?.

drink the maven kool aid, and you worries will be beyond you.
To use hadoop :

        org.apache.hadoop
        hadoop-core
        0.20.205.0

in your pom.mxl

Then write 2 classes like those one:

class MyMap extends MapReduceBase implements Mapper<K1, V1, K2, V2 >...
class MyReduce extends MapReduceBase implements Reducer<K2, V2, K3, V3>...

Feed instances of those to a JobConf and feed that instance to a JobClient.

The rest should be obvious to a seasoned programmer, just by looking at the nomenclature of the classes hierarchy.

The great Ward Cunningham, is right, put two days into studying something and you are already half way to expert.

According to this page, RiverTrail "adds the ParallelArray data type to JavaScript [...] accessible by functions like combine, filter, map, reduce, etc. which perform work in parallel." Hope that saved you some searching.

I feel sad that they didn't find some way of trying to unify the desktop and Metro. Sure, space can be limited for some apps, but other apps which are small in size may be able to run on a phone and desktop with little or no change.

However, as a C# developer the below looks interesting from this site: http://www.infoq.com/news/2011/09/WinRT-API

C#/VB: The end of P/Invoke

Calling native functions from .NET usually involves building up structures and manipulating pointers. Under WinRT all APIs are exposed as objects that C# and VB can consume directly. This puts .NET developers on level footing with C++ developers.

I also work in the finance industry analyzing and testing performance software performance. I would love to hear more about how you do 1/5th of a microsecond price feeds if you're game. This is clearly not possible without some custom hardware (you mention VHDL). Could you please tell us more about this hardware and what kind of logic resides in it vs regular software running on the hosts cpu(s)? BTW, this is a terrific presentation on HPC Finance using Java: http://www.infoq.com/presentations/LMAX

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.