(This idea will probably only make sense to those who like Haskell.)

Write a combinator library for Haskell allowing you to perform system administration tasks. This would allow you to take advantage of Haskell’s natural strengths: fewer bugs; simple APIs; fast, side-effect free, computation separated from real-world effects. All the standard UNIX utilities could be re-written to return proper Haskell data structures so you don’t have to do nearly as much string parsing.

I think sys admin is actually very well suited to a functional programming language such as Haskell because, if you think about the types of things you actually do (sorting, filtering, selection, statistics, parsing) these are all very natural to functional programming. Indeed, whenever I’ve done these things in scripting or OO languages it has been somewhat awkward.

I think a lot of this library probably already exists out there in Hackage (big open-source haskell repo) and just needs to be amalgamated and into a cohesive whole.
-- ojsx, Apr 12 2011

Learn You a Haskell for Great Good! http://learnyouahaskell.com/
Haskell primer that I'm just starting to work through. [zen_tom, Apr 12 2011]

Halfbakery: Commercial Database OS Commercial Database OS
On the assumption that SQL is a 'functional' language, my take on shifting from procedural into functional implementation of an OS. [zen_tom, Apr 12 2011]

Haskell http://en.wikipedia.../wiki/Eddie_Haskell
[normzone, Apr 13 2011]

What's Haskell, and what's stopping this from already happening?

Also, how can it (presuming it's a programming language) have a natural strength of "fewer bugs"? Isn't bugginess an inherent property of programming in general, rather than any particular language? Are some languages buggier than others, or is it more a case of different strokes for different folks?
-- zen_tom, Apr 12 2011


Haskell works because its always so polite to Mr. and Mrs. Cleaver.

I suppose that languages that deviate further from natural linguistic contructs in more difficult-to-decipher coding would lead to more bugs. Consider trying to write any long program in BASIC.
-- RayfordSteele, Apr 12 2011


I don't recognise that distinction - in fact, I'd have thought the opposite applies. Natural language is great for describing things at a day-to-day level of precision, but as soon as you need to describe something exactly, it starts revealing its flaws (puns, no strict standard meanings,differences in tense, and general ambiguities to mention a few)

I'd say BASIC is in fact a little too-close to natural language constructs in that a lot of the low level stuff (say around the management of collections) is sort of hazed over and can result in the system doing stuff that you wouldn't necessarily expect.

Also, BASIC allows you to send parameters through function and procedural calls, allowing you to build up your own high-level forms, abstracting the detail, and allowing the programmer to concentrate on program flow - that's just good programming practice.

Back to the idea - I'm used to procedural programming, i.e. telling my computer what to do in a series of commands - but I've thought before that functional type of operating system might be interesting - though my example of choice was SQL - (is that a functional language?)
-- zen_tom, Apr 12 2011


BASIC was my example of a bad language format, due to its lack of structural organization and poor variable treatment. I wasn't referring to Visual Basic.

Perhaps I should've said 'natural logic contructs.'
-- RayfordSteele, Apr 12 2011


[ojsx] Unix shell syntax does resemble Haskell, a bit, and the classic Unix sysadmin way of combining tools with pipes, backtick syntax, xargs, etc. has a rather functional flavor, which (to me) leads naturally to the idea of a collection of utilities (grep-alike, sed-alike, etc.) that you combine in a similar but more rigorously functional way. (Is that what you're proposing?)

But that leads quickly to problems. Most sysadmin tasks require side effects. Normally, you're altering the contents of some file or other, no? It's all about altering the state of your system. Of course, one of the jaw- dropping things about modern functional programming is that it can handle state without sacrificing functional purety, but wouldn't you have to put the entire computer within a "system" monad? Or something?

[RayfordSteele] Haskell belongs to that class of programming languages that have very few bugs because (by design) it's so damn hard to get your program to compile without errors that, by the time you've gotten over that hurdle, there's a very high probability it produces correct results.
-- mouseposture, Apr 13 2011


I presume this is named after Haskell Curry. Beyond that, i know nothing. Why are there fewer bugs? Is it because of something like flexible syntax or "Do What I Mean"?
-- nineteenthly, Apr 13 2011


If it's anything like Ada, there are fewer bugs because the syntax is _not_ flexible. You must specify what you want with great precision and detail. There is some redundancy, and the compiler spits the dummy if there's the slightest inconsistency. It's therefore relatively hard to write code which compiles but does not do what is intended.

Python, for example, does the opposite. There is very little redundancy, so code is relatively simple and readable. This also helps reduce bugs. They are both valid strategies, in each case implemented well and without compromise, and as a result Ada and Python are amongst my favourite languages.

However, I would choose Python over Ada as a SysAdmin language, because simplicity is good there. I have no experience with Haskell, and so can't say how that relates.
-- spidermother, Apr 13 2011


Makes me think of the Sinclair syntax-checking thing, where you can't enter a line which has a syntax error.
-- nineteenthly, Apr 13 2011


[ninteenthly] No, it's not syntax checking; plenty of languages allow you to write syntactically correct code that doesn't produce the correct result, or the one you want: that's a runtime bug, as distinct from a compile- time bug.

Imagine you were solving a difficult problem in algebra. First you divide both sides of the equation by a common factor, then you combine terms, then you factor a polynomial, yadda, yadda. You can imagine (can't you?) a piece of software which, although too stupid to solve the problem itself, could verify, at each step of your solution, that you'd broken no rules?

Languages like Haskell are like that. They have very strict rules (in Haskell, they're called "the type system"), cleverly designed such that, during the writing of the program, the compiler's apt to say "I'm not sure what you're trying to do, buddy, but I'm pretty sure you just made a mistake."

The "Do what I mean" language, which doesn't exist yet, would go one step further and correct your error. Until then, it's pretty much a matter of taste whether you like "strict" languages like Haskell, or more permissive ones, like Python, where the first version of the program runs without errors, but generates wrong output, and you now have to debug it.
-- mouseposture, Apr 13 2011


//The "Do what I mean" language, which doesn't exist yet, would go one step further and correct your error.//

Like Perl.
-- Loris, Apr 13 2011


No, Perl *anticipates* what you mean. Provided you think a certain way, of course, but many do.

(By the way, the first partial implementation of the Perl 6 interpreter was in Haskell. And after 10 years, there is still no complete implementation. Ya gotta love a language where the official standard is "whatever the interpreter does, is, by definition, the standard.")
-- mouseposture, Apr 14 2011


Oh boy, I sure don't like Haskell, alright.
-- rcarty, Apr 14 2011



random, halfbakery