9 ms·

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think i

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?" It let's you recognize and apply common patterns and implement them in abstract ways without having to think about what kind of values you actually have at runtime. In that way Haskell is the most powerful language I know. Have a tree/list/whatever? Need to apply a function to each of the elements? Make your tree/list/whatever an instance of the Functor type class and you're done. Need to accumulate a result from all the elements? Make it foldable. Something depends on some state? Make it a Monad. You either get a result or you don't (in which case any further computations shouldn't apply)? Use the Maybe Monad. You need to compute different possible results? Use the List Monad. Need to distinguish three different possible values that are different compositions of elementary types? Make yourself your own type and pattern match the behavior of applying functions. Need to output in a certain way? Make it an instance of the Show class. Most concepts that are used every day have some kind of idea behind them that is abstract and implementation independent. Haskell kind of forces you to reference those ideas directly. The downside is that you actually have to know about those concepts. However, knowing about the such concepts makes you also a better programmer in other languages, so it's not like it's a bad thing.

kaeluka 11y ago
IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.
- sordina 11y ago
  It's not a pretty-printer. It's fine for printing stuff when you don't care what it looks like most of the time. Pretty printing is a vague term though. There are certainly many ways to pretty-print in Haskell, some of which are bi-directional pretty-printers/parsers.
- QuantumRoar 11y ago
  Yeah, technically I agree. But I must confess, I used it in the past to have a convenient way to print out something like: 'Add "x" "y"' as "x + y". I didn't care about using read to turn it back into the internal representation since expression parsing is kind of difficult. I used Parsec instead. So I had show to output and a parser as the inverse.
- inglor 11y ago
  A lot of things are supposed to work certain ways but in fact I never really used `Read` for anything more than reading simple user config in scripts. Usually my data is serialized/deserialized from more common formats such as JSON.
- tel 11y ago
  More typically, "Show" is whatever you want it to look like in the repl and "Read" doesn't get used. It's still useful for Show to be essentially Haskell syntax though so you can copy and paste into the repl.
- Tyr42 11y ago
  This split was learnt from in Rust, and Rust has both the Debug class (which is the inverse of Read) and a Display typeclass for showing nice versions of things.
1971genocide 11y ago
And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ? I am sorry, haskell is just a huge roadblock to get things done in the real world. In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !". I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections. You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes ! I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell ! I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My ! I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe. my anecdotal experience. (( btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell ))
- baldfat 11y ago
  You have two flaws to your argument that are non-technical. 1) You try a straw man argument (Your failed project in place of the presented argument) We aren't talking about music models https://yourlogicalfallacyis.com/strawman https://yourlogicalfallacyis.com/strawman 2) Anecdotal definition - not necessarily true or reliable, because based on personal accounts rather than facts or research. I have found out that whenever I complain about a language someone will always have an answer that I thought was unanswerable.
- bigpeopleareold 11y ago
  I am learning Haskell. Could you describe an example/s of Haskell and music theory not working together? I am genuinely curious about this.
- 11y ago
imakesnowflakes 11y ago
>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"... Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results. So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....
- dllthomas 11y ago
  In my experience, to borrow seanmcdirmid's terminology below, one can use Haskell as a "program to think" language - and in fact Haskell brings some significant tools to the table that I miss when I'm using Python to feel around a problem, to the point that I often choose Haskell for this. In both languages, writing small pieces of code and examining their shape and their output can be helpful in growing my understanding of the solution space, but I find that Haskell tends to let me ask more complete questions with less complete code.
- jplahn 11y ago
  I think that's an interesting point, _if_ people actually do that. That said, I'm wary of the claim of 1/10th time and being able to iterate 3 or 4 times per every one iteration with Haskell. Sure, maybe when you're starting out, but once you become proficient I don't think that would be the case anymore. And, there's no guarantee that 3rd or 4th iteration will be as good as the well thought out Haskell code, since the first iterations may be prohibitively complex.
  - seanmcdirmid 11y ago
    The point is that a scripting language is a "program to think" language, while haskell is often seen as a "think to program" language (at least when described as in the top level post). That you have to do more thinking and planning when using haskell (supposedly) doesn't help when the problem you are working on is not well understood and requires exploration (where you are forced to do exploration in your head...or on a whiteboard, rather than in code).
ffn 11y ago
Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinking up front and therefore requires a programmer of a certain logical / organizational maturity in order for the process not to be frustrating and painful (or even traumatizing). Haskell (like C, Lisp, and the arcane slog known as Erlang) should rarely be someone's first language. And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex. After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.
- QuantumRoar 11y ago
  I agree, except for the sex analogy. You could've easily went with something like: Haskell is to programming what bugs are to food. Both are functional, an acquired taste and look scary from the outside.
- nbouscal 11y ago
  > they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex. This may be true for you, but it is not true for everyone. You assume that learning Haskell as a first programming language would be more difficult, but you don't present any evidence to support that claim. People who have done so disagree with you.
hyperpallium 11y ago
Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen. I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off. Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.
- tel 11y ago
  To be honest, I think Haskell is the best language I know of for fast iteration as well. You can successfully create and manage far worse, yet working code when you've got a good type-driven guardrail. A common pithy quote, which I agree with wholeheartedly, is that "`IO` is the best imperative language out there today". There's definitely a lot of missing documentation about this folk practice of "fast, loose, shitty Haskell" due to the strong culture of pretty code that's also enabled by Haskell. I remember seeing a video presented at CUFP that went into the merits here, though. Essentially, this is a "tricky" concept because you want to design your types to be exactly as restrictive as you can afford without having to think too much. It probably requires a good grasp of the Haskell type system applied in full glory in order to bastardize it just right. So, tl;dr? I think types are the ultimate fast iteration tool, but this is not a well-documented practice.
- avmich 11y ago
  "Civilization advances by extending the number of important operations which we can perform without thinking about them." A. N. Whitehead. It's often said that a Lisp advantage is to be able to write sloppy - without fully understanding what's needed. I guess you can model that degree of "less constraints" in Haskell as well? Otherwise constant forcing "understand what you're doing" can sometimes be a burden.
- munro 11y ago
hyperpallium 11y ago
Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. I predicted that the natural resolution would be languages with both (optional static types, especially at important interfaces) - but while this feature exists, it hasm t taken off. such languages
munro 11y ago
Ability to fiddle isn't tied to static or dynamic programming, it's just every static language platform I've seen including The Haskell Platform neglects making it easier to fiddle. When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle. This is definitely possible. Not compiling is great for production, but not while developing. Software is built in pieces, if I'm working on one piece, another statically unrelated piece shouldn't prevent me from working. In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it's not intrinsic. I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check. Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn't mean the code works. Automated testing is still more useful for writing software that works. Haskell isn't as safe as many people think [1]. sort a = a ++ a -- it compiles, so it must sort [1] http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude.html#v:head http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude...
- gmartres 11y ago
  > What I wish would happen is GHCi allowed me to load just the things that type check Use `-fdefer-type-errors` (should work with both GHC and GHCi), all errors become warnings, and if you try to use a function which was compiled with an error, you get a runtime error.
  - DannoHung 11y ago
    Thus perfectly illustrating Cunnigham's law.
- semigroupoid 11y ago
  Of course compiling successfully does not imply a correct program with the desired behavior. Nobody claims that GHC is able to verify the behavioral correctness of your program and it also can't tell you if your function actually sorts a list or if it does not. However, if you claim in your definition of "sort" that it takes a list and returns a list, then GHC can verify if that is actually true. That is the power of types. They are no magic things that write correct programs for you.

kaeluka 11y ago

IIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.

sordina 11y ago
It's not a pretty-printer. It's fine for printing stuff when you don't care what it looks like most of the time. Pretty printing is a vague term though. There are certainly many ways to pretty-print in Haskell, some of which are bi-directional pretty-printers/parsers.
QuantumRoar 11y ago
Yeah, technically I agree. But I must confess, I used it in the past to have a convenient way to print out something like: 'Add "x" "y"' as "x + y". I didn't care about using read to turn it back into the internal representation since expression parsing is kind of difficult. I used Parsec instead. So I had show to output and a parser as the inverse.
inglor 11y ago
A lot of things are supposed to work certain ways but in fact I never really used `Read` for anything more than reading simple user config in scripts. Usually my data is serialized/deserialized from more common formats such as JSON.
tel 11y ago
More typically, "Show" is whatever you want it to look like in the repl and "Read" doesn't get used. It's still useful for Show to be essentially Haskell syntax though so you can copy and paste into the repl.
Tyr42 11y ago
This split was learnt from in Rust, and Rust has both the Debug class (which is the inverse of Read) and a Display typeclass for showing nice versions of things.

1971genocide 11y ago

And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ? I am sorry, haskell is just a huge roadblock to get things done in the real world. In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !". I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections. You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes ! I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell ! I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My ! I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe. my anecdotal experience. (( btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell ))

baldfat 11y ago
You have two flaws to your argument that are non-technical. 1) You try a straw man argument (Your failed project in place of the presented argument) We aren't talking about music models https://yourlogicalfallacyis.com/strawman https://yourlogicalfallacyis.com/strawman 2) Anecdotal definition - not necessarily true or reliable, because based on personal accounts rather than facts or research. I have found out that whenever I complain about a language someone will always have an answer that I thought was unanswerable.
bigpeopleareold 11y ago
I am learning Haskell. Could you describe an example/s of Haskell and music theory not working together? I am genuinely curious about this.
11y ago

imakesnowflakes 11y ago

>While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?"... Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results. So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....

dllthomas 11y ago
In my experience, to borrow seanmcdirmid's terminology below, one can use Haskell as a "program to think" language - and in fact Haskell brings some significant tools to the table that I miss when I'm using Python to feel around a problem, to the point that I often choose Haskell for this. In both languages, writing small pieces of code and examining their shape and their output can be helpful in growing my understanding of the solution space, but I find that Haskell tends to let me ask more complete questions with less complete code.
jplahn 11y ago
I think that's an interesting point, _if_ people actually do that. That said, I'm wary of the claim of 1/10th time and being able to iterate 3 or 4 times per every one iteration with Haskell. Sure, maybe when you're starting out, but once you become proficient I don't think that would be the case anymore. And, there's no guarantee that 3rd or 4th iteration will be as good as the well thought out Haskell code, since the first iterations may be prohibitively complex.
- seanmcdirmid 11y ago
  The point is that a scripting language is a "program to think" language, while haskell is often seen as a "think to program" language (at least when described as in the top level post). That you have to do more thinking and planning when using haskell (supposedly) doesn't help when the problem you are working on is not well understood and requires exploration (where you are forced to do exploration in your head...or on a whiteboard, rather than in code).

ffn 11y ago

Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinking up front and therefore requires a programmer of a certain logical / organizational maturity in order for the process not to be frustrating and painful (or even traumatizing). Haskell (like C, Lisp, and the arcane slog known as Erlang) should rarely be someone's first language. And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex. After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.

QuantumRoar 11y ago
I agree, except for the sex analogy. You could've easily went with something like: Haskell is to programming what bugs are to food. Both are functional, an acquired taste and look scary from the outside.
nbouscal 11y ago
> they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex. This may be true for you, but it is not true for everyone. You assume that learning Haskell as a first programming language would be more difficult, but you don't present any evidence to support that claim. People who have done so disagree with you.

hyperpallium 11y ago

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen. I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off. Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.

tel 11y ago
To be honest, I think Haskell is the best language I know of for fast iteration as well. You can successfully create and manage far worse, yet working code when you've got a good type-driven guardrail. A common pithy quote, which I agree with wholeheartedly, is that "`IO` is the best imperative language out there today". There's definitely a lot of missing documentation about this folk practice of "fast, loose, shitty Haskell" due to the strong culture of pretty code that's also enabled by Haskell. I remember seeing a video presented at CUFP that went into the merits here, though. Essentially, this is a "tricky" concept because you want to design your types to be exactly as restrictive as you can afford without having to think too much. It probably requires a good grasp of the Haskell type system applied in full glory in order to bastardize it just right. So, tl;dr? I think types are the ultimate fast iteration tool, but this is not a well-documented practice.
avmich 11y ago
"Civilization advances by extending the number of important operations which we can perform without thinking about them." A. N. Whitehead. It's often said that a Lisp advantage is to be able to write sloppy - without fully understanding what's needed. I guess you can model that degree of "less constraints" in Haskell as well? Otherwise constant forcing "understand what you're doing" can sometimes be a burden.
munro 11y ago

hyperpallium 11y ago

Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. I predicted that the natural resolution would be languages with both (optional static types, especially at important interfaces) - but while this feature exists, it hasm t taken off. such languages

munro 11y ago

Ability to fiddle isn't tied to static or dynamic programming, it's just every static language platform I've seen including The Haskell Platform neglects making it easier to fiddle. When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle. This is definitely possible. Not compiling is great for production, but not while developing. Software is built in pieces, if I'm working on one piece, another statically unrelated piece shouldn't prevent me from working. In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it's not intrinsic. I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check. Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn't mean the code works. Automated testing is still more useful for writing software that works. Haskell isn't as safe as many people think [1]. sort a = a ++ a -- it compiles, so it must sort [1] http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude.html#v:head http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude...

gmartres 11y ago
> What I wish would happen is GHCi allowed me to load just the things that type check Use `-fdefer-type-errors` (should work with both GHC and GHCi), all errors become warnings, and if you try to use a function which was compiled with an error, you get a runtime error.
- DannoHung 11y ago
  Thus perfectly illustrating Cunnigham's law.
semigroupoid 11y ago
Of course compiling successfully does not imply a correct program with the desired behavior. Nobody claims that GHC is able to verify the behavioral correctness of your program and it also can't tell you if your function actually sorts a list or if it does not. However, if you claim in your definition of "sort" that it takes a list and returns a list, then GHC can verify if that is actually true. That is the power of types. They are no magic things that write correct programs for you.