Tom Stuart

In case anybody is reading this post and wants an idea of how to get started with the basics of logic programming (upon which one might build toy constraint solvers) I recommend this: https://codon.com/hello-declarative-world#programming-paradigms

Tom Stuart did a seriously great talk about this, which really helped my understanding of monads. You can read it as a blog post, but I recommend watching the video. It's worth finding the time for. https://codon.com/refactoring-ruby-with-monads

I'd recommend http://www.michaelnielsen.org/ddi/lisp-as-the-maxwells-equations-of-so… . A couple of "lower level" explanations - http://stevelosh.com/blog/2013/03/list-out-of-lambda/ (a somewhat easier start) and http://codon.com/programming-with-nothing - show where part of the power comes from.

That would be the best of both worlds indeed. Hope we get this for Ruby https://codon.com/consider-static-typing

Because he has a lot of experience in one very specialized area of programming which very much doesn't reflect the wider profession. It's the same problem as e.g. http://codon.com/the-dhh-problem I'd recommend beginners listen to a wide variety of "big names", but only those who are clear about the scope and limits of their experience.

I found this to be a great practical introduction to monads: http://codon.com/refactoring-ruby-with-monads. It holds your hand the whole way, so it gets a bit long and tedious, but it's great at showing how three different common monads can clean up similar looking code in similar ways. I'm sure the Haskell purists out there can find 20+ different things wrong with it, or will scoff at how it's in Ruby, etc., but if you ask me those are tiny prices to pay in an introductory context for how pragmatic, explicit, and helpful it is.

The write-up was excellent, if you prefer a blog format: http://codon.com/refactoring-ruby-with-monads

Jim Weirich was an excellent speaker, and this was one of his best presentations. I thought his method of building up to the purpose of combinators (not just the Y) was much better than just an explanation. He references [1] (note url change) which does something similar and is also a good read/view. [1] - http://codon.com/programming-with-nothing

Some resources that I've found useful: http://nathansuniversity.com/, "Compiler Design: Virtual Machines", "Compiler Design: Analysis and Transformation", "Programming Language Pragmatics", https://github.com/kvalle/diy-lisp, http://codon.com/, http://www.itu.dk/people/sestoft/pebook/. A few more I don't remember but that's a good selection both for beginners and intermediate practitioners.

For me the best introduction to unification was creating a microKanren[1] implementation based on the "Hello, declarative world" article[2], but even just reading the article can help enormously to understand how unification works. Basically if you have unification then you already have a simple query engine, which can handle simple equality constraints that is usually used in SQL WHERE clauses. For example "select * where pokemon = pikachu" can be simply achieved by such a system. Of course this only gives a bare bones query engine, so if you want something more advanced then you will need to implement a constraint system on top of this base unification system. cKanren is a good example of such a system. Few years ago I had the same kind a of curious question about the relationship between databases and logic programming languages like microKanren and as a result I created LogikalDB[3], which is an embedded query language for FoundationDB. 1: http://minikanren.org/ 2: https://codon.com/hello-declarative-world 3: https://github.com/MechaRex/logikaldb

I have some bad news for you (and for Edsger W. Dijkstra, who you would probably be a fan of)- In the "real world" of programming work, you will likely rarely encounter most of those things. Real-world dev is NOT about "computer science proper". (Unless you're building a language from scratch. Which is like 0.01% of all programming work.) You should of course be aware of them and what they do, and when you think you need them you should Google them and learn them then (and of course be able to do so). Sometimes you need to switch languages- Perhaps you want the "look and feel" of pencil art which you can't do with pen-driven art without A LOT of work. You can implement immutable data structures in Ruby- for example, see the Hamster gem here https://github.com/hamstergem/hamster - but 1) it is much, much slower, 2) none of the other gem code you will call into will use Hamster 3) you actually have to code differently to Hamster data structures than to the built-in Ruby ones. Just because you CAN make pencil-art with pens, doesn't mean that's the "happy path." And just because you can represent every possible computer operation as a series of lambda functions (see "Programming With Nothing" here, great article: http://codon.com/programming-with-nothing) doesn't mean you should.

I have a degree in mathematics from the University of Chicago. Want to talk about self-adjoint algebras of compactly supported continuous functions? I'm your man. I also think teaching this using mathematical notation would be a mistake. People only learn things when they relate in part to something they already know. The original lambda calculus syntax is not only abstract, it was invented before programmable computers existed. Unless someone is either already comfortable with mathematical notation or has a background in a programming language with similar concepts (Lisp, Haskell, etc.), it's going to be a stretch to teach someone the lambda calculus -- really teach them -- unless it's framed in terms of a language they already know. JavaScript is a great language to use for this because it has C-like syntax, which virtually all programmers understand, and first-class functions. You could use Ruby, too, but the syntax would be even more opaque. Here's someone building the lambda calculus using only Procs in Ruby: http://codon.com/programming-with-nothing Then using Ruby 1.9's "stabbby lambda syntax" you get -> x { -> f { f[x] } } Not sure that's any better. The key is explaining it in terms of something the ready already understands well. If they're not already thinking mathematically a straight-forward introduction to the lambda calculus would be ineffective.

To add to other comments, things the author could have expanded upon: * vararg keyword arguments (kwargs) * Keyword-only arguments (Python 3) * help, vars, a few other nice introspective builtins * Assignment unpacking (multiple names as left-hand side of an assignment) * The strangest "first blush" difference between Ruby and Python, or at least the one which I found oddest when I first started switching, is that a new Ruby class is defined from the `class {Name}` line, the whole body executes in the context of the already-created class. Not so in Python, the class object will only exist once the body has finished executing. * No mention of generators? Also outer v inner iteration is a pretty big split between two otherwise similar languages. Mistake-ish * obj.__dict__ -> vars(obj) * obj.__class__ -> type(obj) * Python's lambdas are not one-line, they're one-expression. The reason you "can't do [this] in Python" is that if:elif:else: is a statement, so doesn't fit in lambdas. But you can have arbitrary complex code in lambdas aside from that, by following http://codon.com/programming-with-nothing. For instance you can (although you should not) write: map(lambda num: 0 if num % 3 == 0 else num * 2 if num % 4 == 0 else num, range(1, 6)) * Author talks about methods a lot. They're not methods, a method is part of an object. They're functions. Granular functions, inner functions, ... * We generally don't say Python…

In my experience it’s easiest for people to understand monads when they’re presented as an abstract data type (e.g. what I wrote at https://codon.com/refactoring-ruby-with-monads#abstract-data-types) rather than a programming pattern, because despite having “abstract” in the name, abstract data types are a relatively concrete thing that programmers already know how to use.

Tom Stuart, the author of the post, also has written an interesting article called "Programming with Nothing" in which he demonstrates how to use first-class functions in Ruby to explain the Lambda Calculus.[0] [0] https://codon.com/programming-with-nothing

Slightly more approachable intros to this topic: Hello, declarative world: https://codon.com/hello-declarative-world Reasoned PHP: https://igor.io/2014/08/06/reasoned-php.html

Programming with nothing by Tom Stuart https://codon.com/programming-with-nothing

Discussions like this are always helpful for people with more experience in dynamic languages. My first experiences with Monads, like the one in LYAHFGG[0], left me with the sense that Monads were a tool primarily used in statically-typed languages. After much searching, I stumbled across Tom Stuart's _Refactoring Ruby With Monads_[1] talk, which helped describe Monads as just another useful programming abstraction independent of the language. (Jim Duey's _Monads in Clojure_[2] also helped.) Monads now make sense to me as a general-purpose programming paradigm, like recursion or immutable data structures. [0] http://learnyouahaskell.com/a-fistful-of-monads [1] http://codon.com/refactoring-ruby-with-monads [2] http://www.clojure.net/2012/02/02/Monads-in-Clojure/

Reminded me about good old https://codon.com/programming-with-nothing

Here's a longer article (http://codon.com/consider-static-typing) with more background / history about static typing and Ruby. This topic has been knocked around in Ruby-land for a while; I remember seeing Michael Edgar's LASER (https://github.com/michaeledgar/laser) static analysis tool including some work around optional type annotations, but seems like development there has stopped.

I enjoyed this explanation of monads in Ruby: http://codon.com/refactoring-ruby-with-monads

This is the detailed text version http://codon.com/programming-with-nothing

Tom Stuart used various Church encodings in his presentation "Programming with Nothing" [1] [2]. He used nothing in the Ruby language but creating procs and calling procs. He demonstrated this by implementing the fizz-buzz program in nothing but procs. [1] http://codon.com/programming-with-nothing [2] http://computationbook.com

One of the answers towards the bottom linked to an incredibly interesting read on programming using nothing but Procs[1]. I found it to be incredibly fascinating, and it even goes into implementing FizzBuzz under these constraints. [1]: http://codon.com/programming-with-nothing

Our professor in first semester (computer science) briefly touched lambda calculus in a lecture, but of course back then all you see is a bunch of strange things with no idea what it actually is. What's needed to understand is probably a little background in functional programming and a little interest in the topic to dig deeper. I once came across a nice example that gradually transformed a normal Ruby program into such a monstrosity, while explaining everything along the way: http://codon.com/programming-with-nothing Side note: I roughly understand some principles of all that but in no way good enough to actually write code that way. Specifically I still cannot come up with a Y combinator definition (and right now work time limits my opportunity of reading the article completely).

Technically, he uses modulus. Technically. http://codon.com/programming-with-nothing

If you are interested in ideas that can arise from putting some hard restrictions in the same vein, see "programming with nothing"[1]. SICP also explores this topic slightly in the exercise about Church numerals and thought experiments on how you could try to reimplement special forms using functions. [1] http://codon.com/programming-with-nothing

> from CompSci Maybe I'm missing something, but I don't see much that I would consider CS. This is an attempt at an engineering-style workaround. > malware They explicitly include support for spyware with the mouse{over,out} (etc) events. > "ADsafe makes it possible to quickly and reliably determine that script is safe" That's incredibly hard. It's easy to hide arbitrary code even if all you have is a lambda expression[1] ("function () {}" in JavaScript). There are so many sharp corners and inconsistent gotchas in JavaScript - multiplied by the variations between browsers - that identifying a "safe" subset of the language is extremely difficult (or maybe undecidable). Douglas Crockford has been warned[2] almost a decade ago about the insecurity of mixing foreign JavaScript. The language simply wasn't designed with a security model sufficient for running untrusted code. [1] https://codon.com/programming-with-nothing [2] https://www.youtube.com/watch?v=qfBL2sc2zUU

I don't think looser typing is the current trend at all. I think the opposite is true: there's a movement towards more typing, particularly among the languages that have traditionally been the most dynamically typed. - Type hinting is a significant new feature in PHP 7.x: http://php.net/manual/en/migration70.new-features.php - Python 3.5 introduces type hinting: https://docs.python.org/3/library/typing.html - Ruby is talking about possibly adding a static typing system to Ruby 3.x (this is very early stage, but there appears to be interest): https://codon.com/consider-static-typing. Also 24 days ago Matz talked about possibly adding type inference to Ruby3x3: https://bugs.ruby-lang.org/issues/9999 - Flow and TypeScript add types to JavaScript. - JavaScript is adding more structure to its type system with ES6 classes. - Newer languages such as Swift and Dart are certainly more typed than the Python/Ruby/JavaScript generation. - Rust is typed to the max. I guess what I'm saying is that if you like type systems, the future is bright. :)

It's been done: https://codon.com/programming-with-nothing