h a l f b a k e r y"It would work, if you can find alternatives to each of the steps involved in this process."
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
(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.
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]
[link]
|
| |
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? |
|
| |
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. |
|
| |
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?) |
|
| |
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.' |
|
| |
[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. |
|
| |
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"? |
|
| |
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. |
|
| |
Makes me think of the Sinclair syntax-checking thing,
where you can't enter a line which has a syntax error. |
|
| |
[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. |
|
| |
//The "Do what I mean" language, which doesn't exist yet, would go one step further and correct your error.// |
|
| |
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.") |
|
| |
Oh boy, I sure don't like Haskell, alright. |
|
| |