2 ms·

do you struggle with bottom-up-Haskell? I always associated Haskell with a very opinionated top-down process

mark_l_watson 5y ago
I like Haskell, but my Haskell skills are weak. I experiment in the REPL to see what works and then write functions in an editor. Also, I like writing pure Haskell code, and when I need to do network or file access, etc., then I find appropriate code on the web that I can learn from. So, my use of Haskell is fairly simplistic. I even wrote a very short book using the small subset of Haskell that I am comfortable with and use for my own projects.
- exdsq 5y ago
  When I worked in Haskell I always found a type-driven top-down approach helped me work out what I needed to do literally starting from something like App :: Input -> Output Out of interest where are you working such that you're using Lisp? Pretty sure I've actually asked you before ha, but can't remember. Every-time I get burned out with frameworks and polygot development I end up daydreaming of using a stable language like common lisp for the remaining ~40 years of my career.
  - mark_l_watson 5y ago
    I have used Common Lisp for a ton of paid work since 1982. That said, in the last 7 years people have paid me to do deep learning work, so that work uses Python. Follow the money. I am deeply bound up in Common Lisp because of my history. However, if I may make a suggestion: you might want to take a careful look at Racket: easy to make standalone apps, good libraries, large community, and if you don't like Emacs, the Racket IDE is really pretty good. Sit in on one of the online Racket conferences to see many kinds of cool applications and libraries people use Racket for.
tikhonj 5y ago
I've done a lot of Haskell, and my approach tends to be a mix of the two. There's a natural split: • types let me play with the architecture and interfaces top-down • the REPL lets me write more complex logic bottom-up Usually there are a few "hotspots" in the codebase that require a lot of logic and are easier to develop bottom-up; the rest of the codebase is focused more on organization, domain modeling and information flow, where top-down design works really well. In actual practice I expect my mode tends to vary even more than that, but this division seems like a good approximation of how I think about it.

I like Haskell, but my Haskell skills are weak. I experiment in the REPL to see what works and then write functions in an editor. Also, I like writing pure Haskell code, and when I need to do network or file access, etc., then I find appropriate code on the web that I can learn from. So, my use of Haskell is fairly simplistic. I even wrote a very short book using the small subset of Haskell that I am comfortable with and use for my own projects.

exdsq 5y ago
When I worked in Haskell I always found a type-driven top-down approach helped me work out what I needed to do literally starting from something like App :: Input -> Output Out of interest where are you working such that you're using Lisp? Pretty sure I've actually asked you before ha, but can't remember. Every-time I get burned out with frameworks and polygot development I end up daydreaming of using a stable language like common lisp for the remaining ~40 years of my career.
- mark_l_watson 5y ago
  I have used Common Lisp for a ton of paid work since 1982. That said, in the last 7 years people have paid me to do deep learning work, so that work uses Python. Follow the money. I am deeply bound up in Common Lisp because of my history. However, if I may make a suggestion: you might want to take a careful look at Racket: easy to make standalone apps, good libraries, large community, and if you don't like Emacs, the Racket IDE is really pretty good. Sit in on one of the online Racket conferences to see many kinds of cool applications and libraries people use Racket for.

tikhonj 5y ago

I've done a lot of Haskell, and my approach tends to be a mix of the two. There's a natural split: • types let me play with the architecture and interfaces top-down • the REPL lets me write more complex logic bottom-up Usually there are a few "hotspots" in the codebase that require a lot of logic and are easier to develop bottom-up; the rest of the codebase is focused more on organization, domain modeling and information flow, where top-down design works really well. In actual practice I expect my mode tends to vary even more than that, but this division seems like a good approximation of how I think about it.