Slashdot Mirror

Don't get me wrong: safer programming languages and runtimes definitely help, especially with buffer overflows (thanks C++!), but it's one aspect of many that impact security.

it won't prevent devs from concatenating SQL with user input

You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.

Granted, I lost interest in Haskell somewhere around hitting the Functor/Monad point, but if devs can send raw SQL to the database, they will do so.

misusing threading primitives

You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.

Yes, you can.

So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc.

Good luck spreading that attitude. Makers of device drivers, SCADA, etc., dearly need it.

Basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.

That helps get us closer, certainty. The language and runtime can help catch/eliminate common, elementary mistakes. It's not the silver bullet though: wherever creative work is being done, therein lies the potential for new vulnerabilities.

Well I am still reading about Haskell
      http://book.realworldhaskell.org/
Customers need well written applications that work correctly.
Maintenance programmers ($$$) need to be spending their considerable
time and effort on code that can be clearly and quickly understood also
quickly repaired should a bug slip in.

Work through this over the next 3 months. http://book.realworldhaskell.org/

A tenth? What Internet are you using?

My my estimation based on the scroll bar position after counting for a while, I've got about 250 websites listed with site-specific preferences; some of those will just have plugins enabled so I can look at PDFs, but most are to enable JavaScript.

They range from a couple dozen sites that I want to watch some Flash video on (enabling plugins but leaving JS off doesn't seem to work) to online stores (NewEgg and Best Buy both need JS for nearly essential features) to two of my banks (one of which doesn't actually need it I think, but it adds a few neat features; the other I think needs it) to some discussion-centric sites (even /. by default, but also things like Blogspot if you want to add comments) to the social networking sites to sites like this.

I can't say for certain what percentage of the sites I visit I have whitelisted, but rarely does a day go by when I don't discover some new site to add.

I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ? ;-))

Whether it works or not depends on what your task is and how you try to solve it. There are several ways to do concurrency in Haskell, and they're each appropriate in different instances. If you're just calling a lot of pure functions, then "par" and "seq" might be what you need. If you need shared, mutable state, then STM might be a good approach. If you want to do message passing or traditional locking, then using Chan and/or Mvar in the IO monad might be the right thing.

I'd recommend looking at Real World Haskell chapters 24 and 28.

You can think of monads in general as a way to formally define types of computation that may have a context in which they operate.

See, you are part of the problem. Is that supposed to be an explanation? If you cannot explain it in plain English, you do not really understand it yourself (I think I am quoting Feynman). Your explanation is also wrong (as most "explanations" about monads): Maybe has no context, and neither do lists. The general definition of monad has nothing to do with context, only with chaining.

Try reading Real World Haskell? The text is available online.

Read, until chapter 15 where I gave up around the Reader monad. I read the Thompson before. See below for horror example.

OK. Let's take the simple example of map:

f becomes function, e first, es rest.

However map is pretty easy to grasp. For the promised RWH horror code, here is one from chapter 14:

bindSt :: (SimpleState s a) -> (a -> SimpleState s b) -> SimpleState s b
bindSt m k = \s -> let (a, s') = m s
in (k a) s'

There are multiple issues: the SimpleState is not a state (problem common to the State monad), but a state processor, a function. I really would like to inflict pain on whomever decided the name. The authors use m presumably for a monad, then (the gods knows for which reason) k for a function. They also use a single apostrophe (the smallest character they could find, arguably) to distinguish the new state from the old. Funny thing, they actually try to follow up with a more "readable" version, in which they make a sorry attempt at readability, which fails hopelessly (step seems a noun, but is actually meant as a verb).

[...] helps keep the code using the combinators reasonably short [...]

Argh, no, you must not keep the damn code short! The alpha and omega is keeping it readable. Ideally good code should read almost as plain English. Operators are not English, and should be used sparingly (I once thought it was silly to limit the operators in C++... now I see the wisdom). Surely you can be too verbose, but at a minimum the code must be self-explanatory. Well that's the professional coding world, where Haskell does not belong, and never will.

Funny thing, I discovered that "terse" has a different meaning in English from what I expected. In my language (from which the word comes) it means clean, transparent, so I extrapolated "readable". Guess what, it took people praising Haskell for being "terse" for me to figure out that something was amiss.

Functional purity makes I/O a major mess. Monads are complex, unintuitive and unwieldy. I think I spent over one month only trying to warp my mind around that. It does not help that Haskellers keep repeating that "monads are really simple", there is a reason why they are the most asked-about topic in newsgroups.

I'm suspecting that's because they really are quite simple. You can think of monads in general as a way to formally define types of computation that may have a context in which they operate. There're error monads like Maybe, where the computation may fail at a step, aborting the rest of the computation. State monads like State, where the computation has access to implicit state. Non-determinism in List, which computes all possible results. And IO, which is a bit like a state monad where your state is the whole of the rest of the world.
Try reading Real World Haskell? The text is available online.

The worst thing is the Haskell community's coding standards. Single-letter variables are common, and I actually read some delirious rant about this being necessary "because it's so abstract you cannot name it". If it's so abstract you cannot name it, you abstracted too much, or you don't understand what you are doing. There seems to be a proliferation of operators, since Haskell foolishly allows to define new ones, even completely useless ones like $. Coding function with undocumented one-liners seems to be considered a virtue.

OK. Let's take the simple example of map:
-- | Gives the list obtained by applying the given function to each element of the given list.
map :: (a -> b) -> [a] -> [b]
map f (e:es) = f e : map f es
map _ [] = []

What longer variable names would you use there and would those really make it more understandable?

Presence of one-letter variable names generally indicates that the function doesn't care about the internal details of the value in that variable. That could be due to either the function being polymoprhic (where it can't access the internals) or operating on simple types like numbers (where there are no internal details to care about).

$ is occasionally handy when creating a partial application. For example:
fs :: [a -> b]
v :: a
map ($ v) fs

That's in addition to cutting out extra parens when you're applying multiple functions:
f1 (f2 (f3 (f4 v)))
  vs.
f1 $ f2 $ f3 $ f4 v

One of the places where custom operators are very usefull is with combinator libraries. Making the most commonly used low-level combinators operators helps keep the code using the combinators reasonably short and thus more readable than if they were bloodyLongNamesFullySpelledOut.

Learn you a haskell is certainly a good place to start. Real world haskell is also available on the web, if you want more detail than LYAH provides, particularly as it pertains to building applications that deal with IO, networking, interaction, etc...

Please check out such books as Mercurial: The Definitive Guide and Real World Haskell. They were freely available when being written and remain such, but in the same time both books were published as usual (on paper) by O'Reilly:

http://oreilly.com/catalog/9780596800673/
http://oreilly.com/catalog/9780596514983/

The source code used to create the books is also available. So you may use the same work flow.

He can even try before he buys.

There's definitely a big learning curve. In haskell, a lot of the things you'd normally do with loops can be achieved through standard library functions, but you have to know a lot of functions to get anything done.

Bad analogy: C is like DOS, whereas Haskell is like Linux. In DOS you could do just about everything there was to do with about 8 commands (cd, edit, md, rd, dir, del, copy, move). On my current ubuntu box, there are 1931 programs in /usr/bin. Of course, I don't need to know them all to get stuff done, but it helps to know more than 8.

So, instead of iterating over a data structure with a loop, you use maps and folds. It's a different way of doing things.

IO is a particular stumbling block for many who would learn Haskell. IO itself isn't really any trickier than it is in any other language, but to do IO you also need at least a rudimentary understanding of the whole monad thing. I think the only solution is to find one of the several good books on programmin in haskell. (Real World Haskell just came out, and is focused particularly on making useful programs that interact with, say, files and databases.) From my experiences, Haskell IO makes a lot more sense than it did when I started. It seems like a lot of work initially, but it's nice to be able to look at a several thousand line program you wrote and not have calls to read and write, and mutable global variables everywhere.

Since as long as you're running on the same hardware, you use the same instruction set regardless of what higher level language you program in, yeah, there will probably always be optimizations available in assembler that aren't available in HLL's. The question is how much extra work are you willing to do to get at them. Functional programming languages (FPL's) like Haskell are simply higher level languages than imperative languages like C or Java. Here is a Haskell program to print the sum of the squares of the first million integers, using multicore parallelism: print $ psum [| x*x | x http://www.cse.unsw.edu.au/~dons/blog/2007/11/29 Again, yeah, you could do that with Posix threads but it would be hellish by comparison. And we haven't even talked about the STM (Software Transactional Memory) library, which lets you share data between threads without messing around with locks (the compiler's type system automatically makes sure the sharing is thread safe). Check out the book http://book.realworldhaskell.org/ (text is online) for more info about this. Note it doesn't include the DPH stuff which is very new.

Python has some features inspired by FP languages including Haskell, but is not anything like real functional programming. Haskell is far more powerful and serious, but also a heck of a lot more difficult to use. Python has a "practicality beats purity" mantra; you could think of Haskell as "purity strikes back".

Stuff Haskell gets you:

Serious native-code compiler whose output can beat compiled C code for some programs (and does darn well on average, see the Alioth shootout)

Ability to use multi-core parallelism, with a library module that treats shared memory as a transactional database, allowing use of shared data between threads while getting rid of all the lock management headaches of languages like Java. This can work because Haskell's functional purity guarantees that the threads won't clobber each other except under circumstances precisely controlled by the library.

Data parallelism allowing computations of list comprehensions to automatically be done in parallel on multiple CPU's

Rigorous type system (nothing like the broken ones like in C or Java that you might be used to) lets you express complex invariants in your datatypes so that errors can be caught by the compiler. This greatly decreases the amount of runtime debugging required.

I could go on, but you get the idea.

Good tutorial: http://learnyouahaskell.com/

More detailed book (full text online): http://book.realworldhaskell.org/

Haskell has a very steep learning curve compared with other languages (or "unlearning curve", as some put it, since you have to forget everything you knew), but learning it (a still ongoing process for me) is one of the most interesting and mind-expanding things I've ever done as a programmer.

And multi-threaded is hard. It's not a matter of the language, it's a matter of having to remember that other things may have their fingers in your data, or of designing things so they don't. That's what gives most programmers fits, and I don't see FP making that any easier because it happens before you've gotten to the code.

Many functional languages do not allow the program to manipulate shared state, which removes that whole class of problems; information sharing is limited to letting the run time system fork threads and copy function arguments and return values back and forth.

However, if you really do need shared mutable state (and there are plenty of algorithms that do), in Haskell there's software transactional memory, which provides a restricted API for manipulating shared mutable state with the STM monad. Since the code within an STM transaction is not allowed to cause side effects or access any shared mutable state outside of STM, the runtime system is able to stop and replay transactions whenever it detects conflicts. This is one area where FP actually can make things easier, by enabling the same sorts of operations you might do in an imperative multithreaded program, but doing it in a much safer way.

And, if you don't need shared mutable state, sometimes parallelism can be achieved just by replacing "map" with "parMap" in the right places and recompiling with the appropriate options. It doesn't get much easier than that.

au_contraire :: String -> String
au_contraire "Scheme" = "Haskell"

While pure functional code isn't allowed to manipulate mutable, shared state, functional languages often provide some mechanism to mix "pure" and "impure" (stateful, imperative code).

In the haskell world, there is the IO monad, which is sort of a sandbox where anything is allowed. Functions within the IO monad (often called "IO actions") are allowed to invoke other IO actions or call pure code, but the reverse is not true; pure code cannot invoke an IO action. Also, due to laziness, pure functions that were passed an unevaluated "thunk" as an argument might trigger deferred IO, but this is (usually) transparent to the programmer.

So far, this doesn't sound any better than a pure imperative language, but there is also an STM monad (for software transactional memory) which is like pure code except that you're allowed to access shared mutable data through a restricted API. STM is based on the idea that if two processes race and manipulate the same shared data structures at the same time, the conflict can be detected by the run time system, which can stop and replay the transaction one after the other.

The reason STM transactions can be safely replayed by the run-time system is that the language guarantees that the STM transaction doesn't have any hidden state somewhere, that might cause problems if the transaction were replayed. This is not a guarantee you can make in C, C++, Java, or any other popular language that I am aware of.

Note 1: It is possible for STM transactions to livelock if they continually conflict and are replayed, so you can still shoot yourself in the foot. However, it does make avoiding certain other problems much easier.

Note 2: I'm not really a haskell guru, so everything above should be taken with a grain of salt. Real World Haskell has a chapter on STM, which is the basis of my current understanding (I haven't yet had cause to use STM in any program I've written.)

Fortunately, people are also getting better and better at the comparably diffficult task of writing good books about FP. ;-) See the new book on Haskell.

Probably not what you're looking for, but Real World Haskell is soon to be released and has chapters on concurrent and multicore programming and software transactional memory. Even if you're not interested in Haskell per se, STM is kind of an interesting idea.

Probably not what you're looking for, but Real World Haskell is soon to be released and has chapters on concurrent and multicore programming and software transactional memory. Even if you're not interested in Haskell per se, STM is kind of an interesting idea.

When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all. (With Erlang it's "Use our custom database", so they've an answer, of sorts.)

For haskell, you might want to look at System.Posix.IO. I haven't had to do arbitrary seeking in haskell, but that's what I'd probably try first if I did. Of course, all this has to happen inside the IO monad, so you'll need to be prepared to deal with monads. You might find the IO chapter in real world haskell helpful.

The second thing I look for is "How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL. Erlang has a custom approach that is decent for drawing buttons in boxes, etc., but not really sufficient for what I want. Most functional languages don't seem to even consider the matter. (Perhaps they do, but it doesn't seem to appear in the documentation.)

Both haskell and ocaml have pretty good OpenGL bindings, called Hopengl (tutorial) and LablGL respectively. Ocaml also has a simpler built-in graphics library, and haskell has an (I believe) windows-only graphics library that is used extensively for examples in the book "The Haskell School of Expression".

A separate, but related problem is that the community doesn't seem interested in practical use of it
Really? That's why there's a new book called Real World Haskell. The IRC channel on freenode is one of the largest on the entire network, and full of people doing real world things with haskell.

there aren't lots of bindings to libraries to make easy things easy.

I call FUD. The Hackage databasehas literally hundreds of libraries sat there ready for you to use. And if you really need something that isn't there, the FFI is mature, and very easy to use.

The book "Real World Haskell" coming out next month should help with that quite a bit. Even better the text of the book is available online .

This has also been an interesting experiment of sorts: as each chapter was written it was put online so that people could read it and help find errors and problems. I don't know how the authors feel, but it looked like it worked pretty well indeed.

Programming in Haskell by Graham Hutton is a good introduction to the language. I'm waiting for Real World Haskell too.