bkil vs. programming

-- The first version can output a row of Pascal's triangle : import System.Environment(getArgs) pas 0       = [1] pas n | n>0 = let l = pas (n-1) in zipWith (+) (0:l) (l++[0]) main = do     [s] <- getArgs     print . pas $ read s -- The second revision can output a certain number of rows of the triangle: import System.Environment(getArgs) pas = iterate nextline [1] where     nextline l = zipWith (+) (0:l) (l++[0]) main = do     [s] <- getArgs     putStr . unlines . map show $ take (read s+1) pas -- And the last monolith solves a very simple homework assignment: import Data.List(intersperse) import System.Environment(getArgs) pas 0 = [1] pas n = let l = pas (n-1) in zipWith (+) (0:l) (l++[0]) strPas s = do     let n = read s     if n<0 || n>30 then         fail ...

We had a discussion on programming language preferences last week with a friendly undergraduate guy. He strongly prefers C++ and Qt, also showing enthusiastic interest in studying Concurrent Clean, while showing great dislike of Java, C# and Ada. I won't go through the whole argument here, but the most interesting aspect of his mentality is disliking the last one. He went on to demonstrate the inferiority of Ada with examples that prove true even in the case of Clean or Haskell! In favor of C++, he mentioned the forgiving nature of the type system. As an issue against Java, he named garbage collection, and against Ada, he listed many issues like instance derivation of type classes and the obscure syntax (I think he used a word like incongruent). He was desperate even after I told him that he will face with very similar issues under Clean. Well, in my opinion, he will have a great time after getting hang of all that! ;-)

edit2: added Real World Haskell link via Mr. baja :-) (edit1: tiny formatting correction) Chapter 25. Profiling and optimization from Real World Haskell by Bryan O'Sullivan, Don Stewart, and John Goerzen Acovea (Analysis of Compiler Options via Evolutionary Algorithm) - this is compatible with virtually all compilers Evolving faster Haskell programs via Acovea - 18% runtime reduction in one case, even for hand-tuned code! Haskell as fast as C: working at a high altitude for low level performance - this shows that introducing higher abstractions shouldn't automatically cause a slowdown Map fusion: Making Haskell 225% faster a similar article HaskellWiki: Performance/GHC optimization tricks and tips to apply by hand And a little reminder about the secret option used during our discussion on performance analysis: ghc -ddump-simpl $FILE > core.txt

The following paper illustrates that you don't always need to decide: Expressivity of Functional-logic Languages and their Implementation by Juan José Moreno Navarro, LSIIS - Facultad de Informática, Universsidad Politécnica de Madrid It first shows simple problems in which one or the other is superior. Then it goes on to plot a possible implementation of a hybrid language in detail.

edit: tiny formatting correction I usually browse the web with many instances of the graphic links2 (my own patched version) and Epiphany concurrently, depending on the complexity of the site in question. When I was on Firefox, I used flashblock to lighten the load on my rusty old processor. I did hack it up for Epiphany around the time I made the switch, but gave up on it sometime later, as the exact blocking scheme looked pretty inefficient. I.e., I could sometimes observe an embedded object loading and taking up a lot of CPU time until the blocker has hidden it from sight. I never cared to come up with Java blocking similar to NoScript on this browser. As I rarely used it anyway, I simply removed the Java plugin package from my system, and extracted the Flash plugin to a subfolder of my profile directory. A hackish script of mine deleted or recreated a symbolic link to the plugins on demand, which was basically the only course-grained way I have been controlling this up until today....

I happen to share Joel Spolsky's view on the question of whether it's worth it to rewrite from scratch . He goes into great detail to show that you'd be almost always better off to reuse and refactor as much as you can from an evolutionarily tried and mostly working solution. He puts it as follows: The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. He then goes on to analyze some of the most prominent issues that could lead the development team to consider a rewrite, and how to solve them without throwing away code. Nevertheless, would you be surprised if I shared that, according to my limited information, some modules of a certain programming language refactoring tool go through regular rewriting from scratch? It seems that not all eat their own dog food.

You may have noticed that I mostly use <code> tags instead of the more conventional <pre> to signal source code. Although the <code> tag was invented to show HTML markup, and mostly one-liners of those too, I find them more convenient for two good reasons. One is that I usually publish source code instead of prose, so using <code> is the semantically more appropriate one of the two. The second is a practical one: by definition, preformatted text does not support reflowing by the end user. Although that does make sense in most cases, especially for layout-based languages like Haskell, however, introducing scroll-bars in small windows or on embedded devices is a major nuisance. Your layout is toast even if you only have one or two lines that are too wide in the source. Though, I do try to prevent the former case as much as possible. This question is a usability issue, as in my opinion, it's much better to fiddle a bit with deciphering the one or two lines ...