Thinking before coding

Started by
27 comments, last by solacedagony 15 years, 8 months ago
Here are some references on Haskell:

Learning Haskell - http://www.haskell.org/haskellwiki/Learning_Haskell
Haskell in 5 steps - http://www.haskell.org/haskellwiki/Haskell_in_5_steps

You might even find the time to look into Natural Deduction - http://lambda-the-ultimate.org/node/1892

I have no experience with F# or O'Caml, and have only briefly passed upon some Haskell (It was assumed knowledge for a course I'm doing), but I would definitely recommend it.

Hope you find the time to read the material, as there are only benefits to gain.
Advertisement
@Luctus: Mathematical modeling sounds like it will be too complicated for me, but I'll take a look at it.

About Haskell - can you recommend a resource for learning the language?

Thanks again to everyone for their suggestions.

EDIT:

@Chu: Just saw your post. Thank you for the links.
Off-topic of Haskell, but on the topic of functional programming, there's a paper titled "Why Functional Programming Matters", it's an interesting read.

Here's a link to the .pdf (I hope it's free!) - http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf
We used The Craft of Functional Programming in our introductory course in programming. It's okay as a reference, but we barely used it as a teaching aid so I can't really comment on it as a learning resource.

I've heard good things about Write Yourself a Scheme in 48 Hours, haven't read it myself though.
-LuctusIn the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move - Douglas Adams
I'll second the sit away from the PC suggestion. Grab a pencil and paper, and go somewhere else to draw boxes and lines on it describing what you want to do.

I actually used to make entry-level engineers write up a paragraph describing how they were going to solve a problem before I would let them write a single line of code. It did two things: 1. improved their writing communication skills, and 2. forced them to think through the problem before diving into the code.

Admin for GameDev.net.

You might find this free book helpful. It uses Scheme / Lisp though to illustrate the points but I think it is still a highly regarded book.

Structure and Interpretation of Computer Programs.
Quote:Original post by Luctus
We used The Craft of Functional Programming in our introductory course in programming. It's okay as a reference, but we barely used it as a teaching aid so I can't really comment on it as a learning resource.

That is also the "recommended reading" text for my "Formal Methods in Software Engineering" course.

I have read the first 9 chapters, although the only thing(s) I have gotten out of it are list comprehension and recursive functions, but I am slowly getting through it.

It's quite friendly to the reader (I really need to drill things into my head, I am a slow learner :)), and covers material in short, easy to understand paragraphs, which ultimately means the sections are fairly short and to the point (which is an excellent quality for a programming text!).
Quote:Original post by Gage64
A couple of questions:

1) I heard that Haskell is a pure functional language. Given that my goal is to learn a different way of thinking and not really a particular language, do you think that it might be a better choice?

2) I heard that F# is basically O'Caml minus a few features but is somewhat easier to work with (in particular, it's error messages are less cryptic). Do you think that would be a better choice? (again, for my purposes)

Finally, while learning functional programming sounds interesting, I'm sure it will be time consuming, so I would also like to hear some other suggestions.

Thank you both for your suggestions so far.


1) OCaml has imperative features but their use is frowned upon and they are not really obvious to use. you will actually have to hunt to find weird concepts like ref and magic. Just dont use the imperative features like loops and assignment, its simple.

2) (a) I think F# will be the better choice because. It is easier to work with since it is on the .NET framework and has the visual studio IDE. In addition to the massive BCL you get access to loads of libraries released for the .NET framework like SlimDX , SDL.net or the neoaxis engine which are CLS compliant.

(b) It definitely does not have less cryptic errors than OCaml. Because the language is not yet released properly About 40% or more of my errors give the highly descriptive syntax error. The supposedly cryptic errors of functional language will come to become vital to you. stuff like expecting type blah but given type bleh, type this and that are not compatible is actually nice and gets you thinking about what you are doing.

(c) F# is different from OCaml. Although they share the same large core subset, the following are different. F# has an optional lighter whitespace based syntax. This will be important because keeping track of semicolons and let bindings was hard for me when I started.

Most importantly F# does not have Polymorphic Variants nor Parametrized modules. F# does not have row polymorphism, it uses as is aproppriate on the .NET framework subtyping. Essentially F# classes and objects are very not the same as OCaml classes. This will likely be unimportant to you. What F# does have that is different is ad hoc polymorphism aka overloading, interfaces, Object Expressions, Quotations, Computation Expressions,reflection, Active Patterns/Extensible matching and I think that about covers the main differences between the two.

Finally F# has been getting alot of press since it is an official .Net language now but there is another OOP functional language called Nemerle* which I feel does a number of things better than F# (other things worse but I use both since on .Net using multiple languages in one project is no different than using multiple classes).

*That twice today Ive posted that. heh.
1. Away from the computer is good.

2. Have you read through a design patterns book? I found that knowledge helped me abstract problems into more well defined chunks; even for things that are not the traditional patterns.

3. While it is useful to think in abstract terms and ignore the specifics of a language, phrasing your thoughts in pseudo-code or even mostly proper code of a particular language is practical. The goal is to get a good grasp of your problem and its solution. Thinking wholly abstractly is better, but don't lose sight of the goal. You'll construct things better and better with practice.
With regards to sitting away from the computer:

Invest a little bit of money on a whiteboard and some dry-erase markers. You can even get one on wheels, if you want to be able to refer to your notes while coding. Just wheel it back into the computer room when you're ready!

Back in school, during our more challenging tasks (and especially when our courses stopped being courses, and became open-ended semester-long projects), whiteboards were a most desired commodity. People greedily clung to study rooms with whiteboards, they hoarded dry-erase markers, and they tried to hide whiteboards on wheels in the library, so they could retrieve them later. My groups would spend hours in front of a whiteboard for days at a time, just planning.

Now at work, you literally can't find an office that doesn't have a whiteboard. And every one is filled to the brim with notes and sketches.

Definitely worth the investment. I need one at home. So do you.
Deep Blue Wave - Brian's Dev Blog.

This topic is closed to new replies.

Advertisement