Programming with Nothing
tomstu.art
tomstu.art
The big differences are:
1. Haskell is lazy while most Lisps are eager.
2. Haskell automatically curries; Lisp doesn't.
3. (1) and (2) enable Haskell to have a very different syntax from Lisp which is largely free of parentheses. And they remove some of the need for macros in Lisp. Not all but some.
4. Haskell has static type analysis with Hindley-Milner. Lisp does type checking at runtime, and optionally a little bit at compile time but it's by no means a global type inferencer like H-M. So Lisp potentially runs a bit slower because of this, but Lisp can also handle edge cases for types that static analysis cannot (because of the halting problem).
5. Haskell encourages a side-effect-free programming style; Lisp neither encourages nor discourages side-effects.
Correct me if I’m wrong, but aren’t types so-called “trivial properties “, on which Rice’s theorem doesn’t hold (and my thinking is that thus neither does the halting problem?). Though this perhaps depends on the type system in question (with dependent types being obvious counter-examples).
k =
-> x {
-> y {
x
}
}
s =
-> x {
-> y {
-> z {
x[z][y[z]]
}
}
}
For example, 'k[x][y]' returns 'x', so TRUE = k
FALSE is a little trickier, so we'll need to calculate its implementation based on the definition. It can't be 'k' (since that behaves like 'TRUE'), and 's' requires three arguments rather than two. Let's assume it's 'S[A]' for some argument 'A': Let FALSE[x][y] = s[A][x][y]
= A[y][x[y]]
We need to find a value for 'A', such that 'A[y][x[y]]' returns 'y'. We can use 'k', hence 'FALSE' can be implemented as 's[k]': FALSE[x][y] = s[k][x][y]
= k[y][x[y]]
= y
We can follow a similar procedure for the other sections of this article (numbers, lists, etc.)https://en.wikipedia.org/wiki/SKI_combinator_calculus
Note that there are alternative systems with only one definition, like https://news.ycombinator.com/item?id=31473127 , but those single definitions are quite complex, compared to s and k.
And also, as you imply, iota: https://github.com/tomstuart/computationbook/tree/master/uni...
Rails is still a fantastic way to build a web application. Better than most of the Node.js server frameworks I’ve seen. Plenty of lessons to be had there.
Ruby (and JavaScript) is also where we learned about the pitfalls of monkey patching. Or at least, the most recent place we learned about the pitfalls of monkey patching.
Ruby is mature, like Python, Perl, and Java. You can find very reliable, well-tested libraries to perform almost any task you want in Ruby. These libraries have been through iterations, they’ve been redesigned and replaced with newer libraries over the years, and those newer libraries have matured, evolved, and become the standard way of doing things.
In some ways it’s a breath of fresh air compared to, say, Rust. I’m not trying to pick on Rust here, but it’s just the nature of a new language that its libraries are not as mature or well-thought-out as the libraries for older languages. The library authors for Ruby libraries have time on their side, and it’s interesting to see Rust libraries go through the evolution process all over again. History repeats itself. Library authors make the same mistakes twenty years later, or make completely new mistakes.
But if it's libraries are matured as you say then I suppose I could easily learn a bit the next time I have to write a small utility or one-off project. It has a reputation for data processing so I could probably port a small python project to it to dip my toes in a bit.
It's probably not going to be like career-defining or anything at this point. But if the other languages you know are strongly optimized for specific use cases and you're looking for a broadly useful language for other things, it's as good as any and better than most at that.
Also the joke that "if you speak english and know any other programming language you know ruby" is like, half true. It's a big language with a lot of nuance but the basics are easy to pick up.
If you don't already know a dynamic/scripting language then it's definitely worth knowing one. But if you already know Python, Perl, or even TCL or JavaScript, I would prioritise learning something more radically different that's going to expand your skillbase more.
That said, now that PHP-based frameworks have caught up on Rails and PHP is heading in a pretty awesome direction, I don't have personally any use for Ruby at the moment. Using PHP I get a much easier deployment, better performance and probably the best optional typing story of any mainstream language.
Sure deploying Rails apps isn't that bad either, especially when using Docker-based setups and Ruby is a beautifully designed language that is worth learning for fun but for me the advantages are simply not as big as to justify the little bit of extra resistance. Probably would rather go for Elixir or something if I am already going for a more niche language.
Though were might be stuff outside of Rails that might of interest.
Hiring is just too hard. I'm currently building my next product on Typescript. It's much easier to find talent that knows JS/TS, and having the same language across the entire stack cannot be overstated.
The lack of types is also something that I just don't want to deal with anymore.
The JS ecosystem is no where near as stable or mature as ruby's, but it still has everything I need and I have enough experience to avoid the bad parts.
I love ruby as a developer, but not as a business/product owner.
That having been said - it's still the most practical scripting language IMHO. Expressive, nice sized std library, like 10x faster implementations that it used to have an its heyday. And rake is an amazing tool for doing stuff you might use make for, but actually works in the modern world (filenames can have spaces in them).