Pure lambda calculus does scratch a weird itch I never knew I had. Someone recently made a super tiny language runtime based on these concepts. https://justine.lol/lambda/
Not sure if that's completely true, but I have read somewhere that Haskell is nothing but a little bit of syntactic suger on top of pure lambda calculus.
It's true-ish, in many of the same ways Lisp can be described similarly. Pure lambda calculus is impractical except for pedagogy, so both Haskell and Lisp add enough knobs to make LC practical.
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.
I'm sure you already know this, but for the benefit of the uninitiated, Haskell's type inference isn't powered by the Hindley-Milner, but with a more advanced system called System F. It's a fascinating bit of computation to dig into, so I encourage anyone interested in typing to explore it further!
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).
To be even more minimal, you can get rid of custom definitions, and encode everything as calls to the following two functions:
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.)
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.
I've always had a vague interest in learning a bit of ruby based on reputation. But my (equally vague) impression is that it's past it's peak and on the downslope of popularity. Is this accurate? Is it still worthwhile to learn, or have other languages mostly supplanted it?
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.
The value is more hobby-ish, I like learning languages with different syntactic structures, it builds out the types of abstractions that I can hold in my head. But I also like what I spend time on in this way to potentially have some practical utility if I ever needed to ramp up my level of knowledge quickly.
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 definitely not hyped any more. Time will tell whether it's a stable plateau or a decline. If you're looking for a language to boost your CV there are definitely better choices at the moment.
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.
Fantastic language for like, personal use random scripting, exploratory work, glue type stuff. It has a large and consistent standard library and third party packages for most things. The community generally values testing, good documentation, and easy-to-pick up APIs.
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.
Rails is still an awesome and mature choice for web development. That it is past the hype cycle is actually a strength not a weakness.
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.
The main benefits of Ruby are its "clean" syntax, and it doesn't have function colors. It's a poorly designed language otherwise. If you've gotten used to good features of other languages, such as any sort of static analysis, you will find Ruby unpleasant to work with. It's also a dangerous language to choose for real world projects because of the community love of metaprogramming. This article shows off one of the weirder design flaws: Procs. There are blocks, procs, lambdas, Bindings, Methods, and UnboundMethods, most of which are classes (wtf?).
I think the peak hype of ruby was just the peak hype of rails. I don't ever think it was that popular outside of it.
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).
I love ruby, built my first business on Ruby/Rails as a Monolith and it purrs along all day, every day. Easy to use and maintain, but I'll never do it again.
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.
seems like artistic license, instead of "here's how to do lambda calculus in Ruby" it is more "How to program with nothing / lets ruin Ruby and still write programs....". Which is fine, though I agree I think it would benefit with more of a shout out to lambda calculus. Just for anyone who is interested, back in about 1990 I got "The Emperor's New Mind" by Roger Penrose, maybe I'm biased since that was my first exposure to the idea, but it has a great description of lambda calculus. In fact it has a great description of many of the fundamentals of computability
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).
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...
1. https://www.youtube.com/watch?v=VUhlNx_-wYk
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.
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.
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.
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.
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).
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.