Lisp and Haskell (2015)
51–60 of 173 posts
Re: Lisp and Haskell (2015)
#52Earlier quoted context omitted.
In Haskell, it's both common and idiomatic. There's always a tradeoff between the usefulness of having static guarantees, and the complexity of the type system features that enable those guarantees. In some cases it's more trouble than it's worth to enforce certain static properties - you have to weigh the costs and benefits on a case by case basis. But it's nice to have the option, and Haskellers make use of it freq…
You don’t need Haskell to do this however.
You need a type system that is expressive enough to allow you to encode logic in the types. Of course, Haskell is not only language with such a type system: PureScript, F#, Rust, OCaml, Scala have similar features, although not all.
Re: Lisp and Haskell (2015)
#53Clojure and F# are my two favourite languages and I have similar experience. It is much faster to develop F# code because I can rely on the type system to help me handle all the edge cases, pass in the right things and avoid nulls.
I really like both of these languages but don’t work in either and find that I struggle to manage these two totally different platforms for hobby work. Both communities have strong tooling norms such that I feel stuck either burning side project time getting up on tools or burning time fighting “the way” assumes by most online materials. Any tips on how to have just a little bit of Clojure/JVM and f#/CLR in your life…
Babashka (https://github.com/borkdude/babashka) is the new gateway drug for Clojure
Essentially you can use it in most places you'd currently use bash scripts the install footprint is small and the startup time is fast
It's kind of like Clojure without the JVM, very easy to justify for one off bits and pieces
Re: Lisp and Haskell (2015)
#54Common Lisp could evolve into totally parenthesis-free language. By expanding the "powerfull and versatile" Loop-macro into full powerfullness and versatileness. Unfortunately two parenthessis needed, but you can redefine the language having those by default around every file.
A lisp without brackets is no longer a lisp.
Re: Lisp and Haskell (2015)
#55Clojure and F# are my two favourite languages and I have similar experience. It is much faster to develop F# code because I can rely on the type system to help me handle all the edge cases, pass in the right things and avoid nulls.
I've always been curious about F#. Is it true that the F# compiler can be super slow especially on larger codebases? I always wonder: why use F# when you can use OCaml? OCaml has pretty decent third party libraries... (Yes multicore support in F# would be a good reason but apart from that)
In my experience it isn't much worse than equivalent C# solutions, perhaps a fraction slower.
Having .NET CORE as a foundation means that whatever improvement the platform gets, F# gets.
This means that not only gets to interop with all the NET frameworks and such (good or bad), but also enjoy the massive performance improvements that's been going into CORE lately (compared to old NET).
Re: Lisp and Haskell (2015)
#56Every once in a while, there's a post on front page HN about Haskell and/or Lisp. Sometimes these posts get a lot of traction, but what confuses me is despite the apparent popularity of these languages among developers, still they are seldom used in serious software. I know there are exceptions (esp. with regards to Lisp), but still these languages never come close to other languages such as Java, JS, C, or even Scal…
Combination of somewhat high barrier to entry (they're unlike most other languages so experience isn't as transferable), and network effects - those in charge of choosing a technology for a project generally make the subjectively prudent decision to use technology that is already in common use, leaving the less common languages in a catch 22.
I doubt this explanation really captures the gist of the phenomenon. Many current and upcoming trends (containers/Kubernetes, machine learning and Rust, for instance) have suffered in varying degrees from either of those problems, yet their adoption among companies is ever-increasing. I suspect they suffer from an issue also shared by the likes of cryptocurrencies: they don't have a "killer benefit"; a concise, persuasive reason that using them is a discrete improvement over current practice (like "high-level systems programming!", or "self-driving cars!").
Re: Lisp and Haskell (2015)
#57Every once in a while, there's a post on front page HN about Haskell and/or Lisp. Sometimes these posts get a lot of traction, but what confuses me is despite the apparent popularity of these languages among developers, still they are seldom used in serious software. I know there are exceptions (esp. with regards to Lisp), but still these languages never come close to other languages such as Java, JS, C, or even Scal…
I'm writing serious software in Lisp.
Other developers working in related areas are using Ruby and Python but my software runs a lot faster.
Re: Lisp and Haskell (2015)
#58Just tried the code in SBCL and it definitely gives a compiler warning even without executing the function: This is SBCL 1.5.6, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distributi…
Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from https://sourceforge.net/projects/sbcl/files/sbcl/ and check there. The Common Lisp implementations and compilers keep on getting better with time and they produce more and more compile-time warnings (especially SBCL).
I know, I just wanted to make a counterpoint in case somebody is deterred from the article.
Re: Lisp and Haskell (2015)
#59I played around with Hackett (a parenthesised Haskell) quite a lot, and I really enjoyed creating my own syntactic abstractions in a haskell-like language. I find I would rarely reach for macros in Haskell, but that I sometimes would like to. Lisp macros do overlap with what you can achieve with Haskell things like typeclasses, laziness, monads and template Haskell, but the overlap is far from 100%. The author of Hac…
Hackett would be pretty much the argument for me to choose Racket - but the development is dead at this point.
Re: Lisp and Haskell (2015)
#60Earlier quoted context omitted.
I frequently have to defend why I hate Python but the foremost reason is that lack of static typing (which also makes reading other peoples codes harder than it need be). Static typing, especially in a rich type system like, e.g. Haskell and Rust, doesn't guarantee you don't have bugs, but it almost guarantees the ones that remain are better bugs, that is, application level bugs. However in my experience, I can usual…
Which is absolutely bizarre to me because most of my experience with Python has been with people who are effectively scientists who don't give a rats-ass about good coding practices and yet I rarely had issues with receiving the wrong type. Don't get me wrong though, I spent the first 10 years of programming with C and Java so I understand the comfort that a statically typed language provides. I just haven't found it…
> Frankly, if you were to ask me what the top 3 sources of my headaches in Python are, number 1, 2, and 3 would be, receiving a None value when I expected something else
Curious example, because that's absolutely something a sufficiently advanced and well-thought-out static type system can completely solve.
You're right that the type systems of C and Java do not meet this bar, however.