h a l f b a k e r yChewable.
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 Haskells 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 dont 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
Ive
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.
Haskell
http://en.wikipedia.../wiki/Eddie_Haskell [normzone, Apr 13 2011]
[link]
|
|
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. |
|
|
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. |
|
| |