12 ms·

Wow. I've been searching for my next language and this could be perfect. I loved Haskell and really miss static typing, type inference, etc, but got tired of

Wow. I've been searching for my next language and this could be perfect. I loved Haskell and really miss static typing, type inference, etc, but got tired of living in mondads. I've been looking at Clojure a lot anyways, but really dislike dynamic typing. If I could have Clojure with static types, I'd be done searching. Though BODOL mentions static typing, I didn't see any examples... What did I miss?

tieTYT 13y ago
From Bodil on IRC: No, it's not implemented yet. I'd say I'm planning to do it over the weekend, but I doubt it's a two day job. :)
runT1ME 13y ago
>but got tired of living in mondads Why? Too limiting, syntax too cumbersome, transformers suck?
- CoffeeDregs 13y ago
  Kind of all of the above, but I started to realize that I was writing code in a very imperative fashion, since, although I do understand monads and how they keep IO pure, I felt weird writing very imperative feeling code. e.g. pseudo: do f <- openFile 'somefile.txt' r <- read f s <- doSomethingToR r Kinda looked like every other language. Except no one else spoke it and the libraries (at the time) was of highly varying quality.. Also, while I was comfortable with monads, I never got comfortable with monad transformers. I had one monad that was a stack of something like 4-5 monad transformers and I started to feel as though I was losing touch with the beauty of Haskell.
  - dchichkov 13y ago
    How about Python? You can write IO in a relatively functional fashion in Python: print sum(float(line) for line in open('somefile.txt'))
    - CoffeeDregs 13y ago
      Agreed. Python is my language of choice... ;) Though I'm really starting to look for a statically-typed, compiled language...
      - dchichkov 13y ago
        I'm curious, what for? Performance, type safety or compile errors? If type safety, then in my opinion it is overrated. A side effect of using dynamically-typed language is that developers keep their naming conventions consistent and in check. Because that's the only sane way to avoid stupid typos in a language that doesn't have a compiler. It is not so in the compiled language world. What I often see in the code, where type safety is enforced, - is that developers get sloppy with names! And as a result, there is a significant increase in bugs caused by logic errors. sad
        CoffeeDregs 13y ago
        Performance, type safety or compile errors? Yes, yes and yes. A side effect of using dynamically-typed language is that developers keep their naming conventions consistent and in check. I've not found this to be the case. I just discussed method naming in Javascript with a developer today while I was reviewing his code. He's a very good developer and this is an A+ codebase (no, it's not a pile of jQuery plugins...). But he hadn't really thought about how to name some methods and didn't realize the confusion that would be caused in 6-18 months. We left it as he had written it because it would have been a pain to hunt down the dependencies. Were we working in a compiled world, we would have refactored and the compiler would have caught any missed dependencies in a second. What I often see in the code, where type safety is enforced, - is that developers get sloppy with names! I've definitely not seen that. I maintain the same rigor w.r.t. hygiene whether I'm working in statically or dynamically typed languages, but I really miss the compiler when I'm working in dynamic languages. At the risk of sounding really rude, can I ask whether your anecdotes are informed by work with competent developers?
        dchichkov 13y ago
  - michaelochurch 13y ago
    As I get older, I realize that the functional/imperative debate is far from over. To say that functional code is "more intuitive" is not only off the point but, I would argue, wrong. Here's a reddit post I wrote about it a few months ago: http://www.reddit.com/r/programming/comments/14hhwa/program_imperatively_when_needed_and_functionally/c7d73tl http://www.reddit.com/r/programming/comments/14hhwa/program_... Imperative code is much more intuitive in the small. That's why we lose when we make side-by-side code snippets of small toy programs and call it a case for FP. The 25-line imperative method is often more intuitive than the highly-dense 6-line functional one. The problem is that imperative code composes very poorly.
    - vorg 13y ago
      > The 25-line imperative method is often more intuitive than the highly-dense 6-line functional one. The 25-line functional program will typically include a 6-line imperative one (with all that imperative code in one place if it's Haskell).
    - runT1ME 13y ago
      >Imperative code is much more intuitive in the small. In a single threaded, deterministic environment yes. But when you're talking multithreaded, I'd disagree. if (user != null) user.company = getCompanyByName("google") being a NPE waiting to happen (in a multithreaded environment) is certainly non-intuitive.
  - Peaker 13y ago
    Imperative code looks like imperative code. Most Haskell code isn't though. Also, a 5 layer transformer stack is typically wrapped in a newtype, so it looks like an ordinary monad with the operations you need.
  - tome 13y ago
    Yes that is indeed unpleasant style. That's why you should write doSomethingToR <=< read <=< openFile instead.
goldfeld 13y ago
Exactly, I have been searching for my functional language and have always felt that neither Haskell nor Clojure quite cut it, so I've been putting it off. The former because, well, it's not Lisp and I'd really like to learn myself a Lisp. The latter because of how the Java relationship overall ruins it for me, especially as it takes a lot of functional purity out of it. You always have to be aware not only of your coding style but that of the number of third party code you'll read both to learn from and to use. Also, not static and I have myself enough dynamic languages. I considered Roy and may yet begin using it in some places I currently use CoffeeScript, but then again it's not Lisp. BODOL could indeed be the perfect piece I've been missing.
spicyj 13y ago
It's not really functional, but you may be interested in Rust if you haven't seen it already: http://www.rust-lang.org/ http://www.rust-lang.org/.
- CoffeeDregs 13y ago
  I've definitely been watching Rust. It's doesn't have the beauty/purity of Haskell or Lisp, but I'm getting close to giving up on that... And I really like Rust's feature list.
sultezdukes 13y ago
I've always wanted the core semantics of Clojure - immutability, the core abstraction of Seq over lists, vectors, and maps, with some strong type inference, and a nice python-like syntax.

tieTYT 13y ago

From Bodil on IRC: No, it's not implemented yet. I'd say I'm planning to do it over the weekend, but I doubt it's a two day job. :)

runT1ME 13y ago

>but got tired of living in mondads Why? Too limiting, syntax too cumbersome, transformers suck?

CoffeeDregs 13y ago
Kind of all of the above, but I started to realize that I was writing code in a very imperative fashion, since, although I do understand monads and how they keep IO pure, I felt weird writing very imperative feeling code. e.g. pseudo: do f <- openFile 'somefile.txt' r <- read f s <- doSomethingToR r Kinda looked like every other language. Except no one else spoke it and the libraries (at the time) was of highly varying quality.. Also, while I was comfortable with monads, I never got comfortable with monad transformers. I had one monad that was a stack of something like 4-5 monad transformers and I started to feel as though I was losing touch with the beauty of Haskell.
- dchichkov 13y ago
  How about Python? You can write IO in a relatively functional fashion in Python: print sum(float(line) for line in open('somefile.txt'))
  - CoffeeDregs 13y ago
    Agreed. Python is my language of choice... ;) Though I'm really starting to look for a statically-typed, compiled language...
    - dchichkov 13y ago
      I'm curious, what for? Performance, type safety or compile errors? If type safety, then in my opinion it is overrated. A side effect of using dynamically-typed language is that developers keep their naming conventions consistent and in check. Because that's the only sane way to avoid stupid typos in a language that doesn't have a compiler. It is not so in the compiled language world. What I often see in the code, where type safety is enforced, - is that developers get sloppy with names! And as a result, there is a significant increase in bugs caused by logic errors. sad
      - CoffeeDregs 13y ago
        Performance, type safety or compile errors? Yes, yes and yes. A side effect of using dynamically-typed language is that developers keep their naming conventions consistent and in check. I've not found this to be the case. I just discussed method naming in Javascript with a developer today while I was reviewing his code. He's a very good developer and this is an A+ codebase (no, it's not a pile of jQuery plugins...). But he hadn't really thought about how to name some methods and didn't realize the confusion that would be caused in 6-18 months. We left it as he had written it because it would have been a pain to hunt down the dependencies. Were we working in a compiled world, we would have refactored and the compiler would have caught any missed dependencies in a second. What I often see in the code, where type safety is enforced, - is that developers get sloppy with names! I've definitely not seen that. I maintain the same rigor w.r.t. hygiene whether I'm working in statically or dynamically typed languages, but I really miss the compiler when I'm working in dynamic languages. At the risk of sounding really rude, can I ask whether your anecdotes are informed by work with competent developers?
        dchichkov 13y ago
- michaelochurch 13y ago
  As I get older, I realize that the functional/imperative debate is far from over. To say that functional code is "more intuitive" is not only off the point but, I would argue, wrong. Here's a reddit post I wrote about it a few months ago: http://www.reddit.com/r/programming/comments/14hhwa/program_imperatively_when_needed_and_functionally/c7d73tl http://www.reddit.com/r/programming/comments/14hhwa/program_... Imperative code is much more intuitive in the small. That's why we lose when we make side-by-side code snippets of small toy programs and call it a case for FP. The 25-line imperative method is often more intuitive than the highly-dense 6-line functional one. The problem is that imperative code composes very poorly.
  - vorg 13y ago
    > The 25-line imperative method is often more intuitive than the highly-dense 6-line functional one. The 25-line functional program will typically include a 6-line imperative one (with all that imperative code in one place if it's Haskell).
  - runT1ME 13y ago
    >Imperative code is much more intuitive in the small. In a single threaded, deterministic environment yes. But when you're talking multithreaded, I'd disagree. if (user != null) user.company = getCompanyByName("google") being a NPE waiting to happen (in a multithreaded environment) is certainly non-intuitive.
- Peaker 13y ago
  Imperative code looks like imperative code. Most Haskell code isn't though. Also, a 5 layer transformer stack is typically wrapped in a newtype, so it looks like an ordinary monad with the operations you need.
- tome 13y ago
  Yes that is indeed unpleasant style. That's why you should write doSomethingToR <=< read <=< openFile instead.

goldfeld 13y ago

Exactly, I have been searching for my functional language and have always felt that neither Haskell nor Clojure quite cut it, so I've been putting it off. The former because, well, it's not Lisp and I'd really like to learn myself a Lisp. The latter because of how the Java relationship overall ruins it for me, especially as it takes a lot of functional purity out of it. You always have to be aware not only of your coding style but that of the number of third party code you'll read both to learn from and to use. Also, not static and I have myself enough dynamic languages. I considered Roy and may yet begin using it in some places I currently use CoffeeScript, but then again it's not Lisp. BODOL could indeed be the perfect piece I've been missing.

spicyj 13y ago

It's not really functional, but you may be interested in Rust if you haven't seen it already: http://www.rust-lang.org/ http://www.rust-lang.org/.

CoffeeDregs 13y ago
I've definitely been watching Rust. It's doesn't have the beauty/purity of Haskell or Lisp, but I'm getting close to giving up on that... And I really like Rust's feature list.

sultezdukes 13y ago

I've always wanted the core semantics of Clojure - immutability, the core abstraction of Seq over lists, vectors, and maps, with some strong type inference, and a nice python-like syntax.