As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In the spirit of the other common mistakes in questions, what are the most common mistakes that Haskell programmers make? I've been teaching myself Haskell for a little while and I am starting to feel comfortable enough with the language to start applying it in the real world.
The most common mistake I know of is introducing a space leak through lazy evaluation. There are lots of ways to achieve this mistake, but one that especially nails programmers with other functional-programming experience is to put a result in an accumulating parameter, thinking that the accumulating parameter will take constant space. In many cases the accumulating parameter takes linear space because parameters are not evaluated.
Another common mistake is to forget that let is always recursive. An unintentional
let x = ... x ...
can lead to baffling outcomes.
Most other common bad experiences manifest not as mistakes but as trouble getting programs past the type checker, or difficulty understanding the monadic I/O model. Difficulties with list comprehensions and with do notations occur occasionally.
In general the difficulties faced by beginning Haskell programmers include
Large language with many dark corners, especially in the type system
Trouble getting programs to compile, especially when they do I/O
Doing everything in the IO monad
Great difficulty predicting the time and space behavior of lazy functional programs
A common mistake for beginning Haskell programmers is to forget the difference between constructor and type namespaces. That was such a beginner's mistake that I'm about embarrassed to have my name attached to it, but I'm pretty confident that others will stumble upon that answer when they have a similar problem, so may as well keep it out there.
The difference between [] and [[]]: the empty list and the list with 1 element, namely the empty list. This one especially pops up in base cases of recursive functions.
Use non tail-recursive functions or not strict folds occurring to stack overflow.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I looked at Haskell web frameworks like Snap and Yesod. Most seem to implement an MVC-ish approach reminding me of web frameworks like Ruby on Rails. Yes, MVC can be achieved with FP, but IMHO it doesn't show the great advantages of an FP approach. As HTTP is a stateless protocol, I would have hoped that there might be an Haskell framework that takes a more original, more pure functional approach. Are there any?
I'm not sure which features in FP you would like a framework to utilize, but I think Yesod uses some features to great benefit. (Happstack does as well, but I'm just not as familiar with it.)
Type-safe URLs eliminate an entire class of typo-generated bugs, plus automatically deal with input validation.
Proper typing practically eliminates XSS attacks.
Depending on the scope of data you're dealing with, using either STM or MVars for your storage needs make it easy to avoid race conditions and deadlocks in multi-threaded applications.
I'm sure there's a lot more that I'm not thinking of, but I hope that makes the point. But perhaps what you're looking for is something like a continuation-based framework. I personally think they're a bad idea (I'm a believer in REST), but I suppose it might seem more "functional."
It depends what you're trying to achieve. If by stateless you actually mean stateless, I use the templating framework Hakyll to generate static pages. It has an interesting structure to deal with dependencies and file updates.
I think WardB was asking not about fancy types, but rather about the denotative/stateless semantics of FP, in contrast to imperative/nondenotative (and often nondeterministic) semantics of things like IO and STM.
It's this denotative aspect that supports precise & tractable reasoning.
The term "functional" has been stretched to embrace imperative/nondenotative programming as well, which often leads to confusion.
Peter Landin recommended replacing "functional" with "denotative" to help clear up exactly this sort of confusion.
I don't know of any denotative (nonimperative) Haskell web frameworks.
Getting there would probably require breaking some long-standing imperative mental habits.
Which is to say: interesting work!
I was looking for the same but haven't really found it. Specifically I was looking for a continuations approach that renders traditional HTTP sessions unnecessary. These sorts of frameworks are quite popular in Scheme. The closest that I found was Chris Eidhof's answer to the Arc Challenge :-
https://gist.github.com/260052
It's a sketchy prototype and probably many man-months away from being something that you could use for serious work. If my Haskell skills were better, I might be tempted to try and develop it.
I also believe that WASH also took this approach but that seems to have died. I'm pinning my hopes on mysnapsession as I believe that is also looking at a continuations based session facility which would be exciting because I have been very impressed with the quality of the rest of Snap and the momentum behind it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have a standard project that they use when learning a new language. Kinda like a specification document of a project that includes all aspects of programming. Does anyone use some sort of beginning type project when learning a new language? I guess it also depends on the type of language and what's it's capable of.
Contributing something to an open source project seems to work for me. In addition to getting exposed to some coding habits in the language , you get to work on something useful.
Going through the first few problems of Project Euler is a very good way to get a handle on topics like I/O, recursion, iteration, and basic data structures. I'd highly recommend it.
A friend of mine had a coworker who coded a minesweeper every time when he wanted to learn a new language with GUI.
I like making simple websites for learning.
Pro: you can put it online and show it to people.
Con: the language has to be suitable for web development.
Writing a simple ray tracer:
math functions (pow, sqrt, your own intersection routines)
recursion (because it is a whitted style recursive one)
iteration (for all pixels)
how to write custom types (rays, possibly vectors)
pixel wise graphics
have something to play with compiler's (optimization-) flags
optional:
simple GUI
file reading writing
I've also done so with metatrace.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Please, gurus, give me a detailed explanation of, in the Object-Oriented programming world, what is lightweight object? And in other computer science fields, what does lightweight means then? Is lightweight a design pattern? Is lightweight good, is bad?
There are many meanings for lightweight, but normally it means the object which has less amount of data or which process less amount of data. Sometimes a thread is called as a lightweight process as it does a less things than a process do. Its processing is also fast than the process. A lightweight object is one which has less amount members and which are of basic types (int, float) as member variables. A light function is the one which does very less things compared to others. Normally these are inline functions. (in C context).
There is no such patterns as lightweight pattern. But Normally the systems should be consists of lightweight objects so that the maintaining those objects could be easy.
The advantages are simple debugging, maintenance and easy understanding of code. The disadvantage could be lots of objects.
There is no lightweight pattern as such but the term is fairly used in the industry.
Lightweight X tend to be used in the case where we have a somewhat well known structure X. Lightweight X is then a version of X using fewer resources in some way or the other - or is subtly different from X in some way.
The term, as is the case for most computer science, is not well-defined and is loosely used.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Like most ppl, I started with and still do a lot of imperative code(mostly Java, Ruby, Javascript).
I've never been a big fan of OO, either because I never understood it properly or because I don't think OO.
Got my first glimpse of FP via javascript, passing functions around, closures, etc. Have been in love with FP since then.
Recently, I've developed interest in Clojure (and may be Scala) and someday might even have a go at Haskell. I like what I see in the functional approach, but how do I think functional? I've been doing imperative stuff for the past 3-4 yrs and my brain tends to think imperative while approaching a problem.
How can I unlearn the imperative style(do I need to?) and think more functionally ?
No. Don't unlearn imperative style as you'll still need it. Even many well-done FP libraries look somewhat imperative under the covers. It's better to think in terms of adding FP to your list of tools and techniques rather going full-metal with one technique or the other.
Now, as to how you go about learning the FP style? Toy projects - or utility project you write for your own use. Or hell, write yourself yet another blog - but with a twist! The key thing, as was stated above, is practice. When doing so, avoid shared state. Strive for purity (that is, avoid side effects) in as many places as you can. Use closures, pattern matching (if the language supports it) and lambda functions. Think in terms of functions being first-class data types in your program - take them as input and return them as output. The list goes on, but you'll see the same concepts repeated time and again if you're watching for them.
If you feel you need a gentle nudge in this regard, use a tool (language) that encourages the FP style such as F# or Scala.
If you feel you need more of a "tough love" kind of help, reach for Haskell :)
Otherwise use the tool of your choice and just keep FP concepts (above) in mind. If you decide go this route there's a pretty good book called Real-World Functional Programming that uses F# and C# to illustrate techniques that apply in both a "mostly" FP language (F#) and a "mostly" OO language C#.
Go for Haskell. Because it's pure you are forced to think functional. In F# or Scala you still can write very imperative code. I strongly recommend the book by Graham Hutton on Haskell.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
ok, so is there a programming language that frees you from clarifying your ideas?
I couldn't help asking. But if there is one, what would you say comes closest today?
You mean, a programming language that lets you program without explaining what you want the program to do?
No, how would that work? The compiler needs to be told what program to compile.
Digging out an old, somewhat appropriate quote from Charles Babbage:
On two occasions I have been asked,
'Pray, Mr. Babbage, if you put into
the machine wrong figures, will the
right answers come out?' I am not able
rightly to apprehend the kind of
confusion of ideas that could provoke
such a question.
The compiler can't read your mind. The only way it can create a program to do what you want is to tell it what it is you want.
Of course, there are languages that free you from having to specify things that are irrelevant to your overall problem and are only relevant to the underlying implementation. (an obvious example is that most modern languages free you from having to worry about pointers or many other low-level concerns. Many languages also give you ways to iterate over sequences without having to write a manual for-loop. But you still have to "clarify your ideas", you still have to specify what your program should do. The best a language can do is free you from clarifying the things that are not relevant to your ideas.
That shouldn't be the role of a language, in my view. Instead, the language should help you to clarify your ideas, and let you express those clarified ideas in as intuitive a way as possible.
You could see it from two angles:
High-level languages like Prolog
free you from having to express every
messy detail of your algorithm. You just
sketch the high-level picture, and
prolog fills in the details (e.g.,
how to do search and deduct the
answers to your questions, etc).
On the other side of the spectrum,
low-level languages like C free you
from having to express your ideas in
an abstract way. You can just give a
sequence of very concrete, detailed
procedural steps (although you can
optionally introduce abstractions if
you want to).
So both extremes free you from certain aspects of expressing and clarifying your ideas.
I don't think so, but there are a few that prevent you from clearly expressing those ideas - I nominate BCPL.
For various problem domains, there are languages that free you from having to type a lot of stuff beyond what's necessary to clarify your ideas. But every language fails in some situations, and for some people. Not everybody is comfortable expressing their ideas in an object oriented design (say, C# or Java), as functions and closures (Scheme), as logical derivations (Prolog -- there are some problems for which it fits!), or as declarative statements of the desired result (XSLT, CSS, various DSL's, with varying success) -- yet each of these is the right answer in certain contexts, and most of them overlap to some extent. Indeed, few modern languages are all that purely oriented to single paradigms.
But some languages favour other things over expressiveness: such as having efficient implementations (C), or being easy to learn (say, Python or its scripting kindred).
I hope there isn't a language that frees you from clarifying your ideas. It should be the responsibility of all programmers to do that themselves, not to pass it off to some other person or programming construct.
All good points, was thinking more along the lines of scripting languages, where you can type away in the debugger until it does what you want (I've done that a time or two for some sysadmin wmi scripts).
Yes, Whitespace.