Posted on

Book Club : IFPuH Section 1.1

I pushed sample and exercises for section 1.1.

Here is some of what I learned, only a bit from the book:

  • Rudimentary cabal (Haskell build / package util)
  • Rudimentary HUnit (Haskell version of JUnit)
  • Rudimentary Haskell function definitions

I haven’t figured out the naming / script files yet. I feel like I should have better test names than ‘testN’. Still, I’d like to differentiate between sample code and problem set, and maybe have the section name in the test. That may allow fewer files, to the extent that the sample code / solution code remains conflict free.

Barely learned any Haskell yet, but this was productive learning the dev tools needed to build and test the projects. A fulfilling start. The most complicated Haskell was in the HUnit tests, and that was nearly all cut and paste from google searches to get the HUnit tests to compile and run. 

One thing I don’t care for regarding HUnit as run by cabal: the shell output is not what I expected.

$ cabal test

Preprocessing test suite 'tests' for funcprog-0.1.0.0..

Building test suite 'tests' for funcprog-0.1.0.0..

[2 of 2] Compiling MainTest         ( app\test\MainTest.hs, dist\build\tests\tests-tmp\MainTest.o )

Linking dist\build\tests\tests.exe …

Running 1 test suites…

Test suite tests: RUNNING…

Test suite tests: PASS

Test suite logged to: dist\test\funcprog-0.1.0.0-tests.log

1 of 1 test suites (1 of 1 test cases) passed.

The thing is, I had 13 tests cases spread across multiple test groups. To me, the (1 of 1 test cases) passed is misleading. The .log file does show the more typical xUnit runner output, so there is that.

The next most complicated bit I learned was about cabal, the Haskell build and package tool. It took a bit of work to modify the templates / samples I’d seen to match some to the directory structure and names I chose. I am not at all sure how to handle multiple libraries / modules or binaries or test suites. I suspect it will be additional stanzas or possibly nested .cabal files. I expect I’ll find out soonish.

Posted on

Project Creation IFPuH

I added source, test and build info to kholvoet/funcprog-haskell.

I believe it is the first project I have created on GitHub with any kind of forethought (I searched for outlines and sample projects). In this case, I have a “Hello Haskell” program, and a trivial HUnit unit test file.

I am not quite sure how much of the deep reading of the book will be in the ghci interpreter, the app or the HUnit tests. I expect I will be using the HUnit both as test driven development (TDD) and a way to capture what I am thinking about. And prototyping in the ghci interpreter, only putting things in the app or library module as I move on.

I haven’t decided yet how many modules to create. I am tempted to do one per chapter, but that may be an unnatural partition. I will start with one, and see when / if I get the intuition that I should break things up.

Posted on

Book Club – Introduction to Functional Programming using Haskell

I have decided to start learning a new language, Haskell, and to improve a neglected area of study, Functional Programming. I will be using the book Introduction to Functional Programming using Haskell (2ed)  (hereafter, IFPuH) by Richard Bird.

Why? Among other reasons, learning to think about problems in a different way. Functional programming is hip. As in old enough to be cool again. Everyone is doing it!

More seriously, one of my favorite classes was an Automated Deduction class I took at UNLV back in the mid-90’s from Dr. Minor. We used LISP and I wrote both a propositional logic and first order predicate logic prover. 

(A painful aside: Years back, but years after I completed the course, I formatted the Linux partition with my theorem provers source. I have a print out of the predicate logic prover, which may not have actually worked adequately. I recall I got less than a 90 out of 100 on it. Please, back up your work, preferably using both local and remote backups.)

I loved the style for many reasons. My undergrad degree was in Mathematics, and for a brief time I was enrolled in a Mathematics PhD program. Then I learned while I liked it, I wasn’t particularly creative at math, which is a severe defect while that kind of program. In fact, I recall complaining to my girl friend (now wife) that I did poorly on an assignment. She basically said, ‘If you’d spent as much time studying and working on the assignment as you do messing around with your computer, you’d ace it”. I responded, “But I don’t want to.” Then she asked me the key question, “Then why are you in a math program rather than computer science?” 

Anyway, currently, the practice of software development is struggling with large, distributed software. It is hard and quality isn’t much better now than before (arguably worse), though it is much prettier for the most part. One of the “new” silver bullets is the idea that immutable state makes distributed computation easier because sharing immutable state is safe. Since functional programming (in a pure form) revolves around immutability (more on that later), functional programming is now cool again. 

It also requires a very different mindset than procedural or object oriented software. That is the main thought I am chasing. Learning how to see, reason about and solve problems from a different vantage point will, in theory, help me be a better developer all around. 

Craftsmen may prefer certain tools, but the more tools they know how to use well makes completing projects easier, and increases the chance of good results while retaining all his fingers.