Update: watch the video
In this series on Scheme: Intro, Basics, Closures.
Here’s a presentation I did recently, on the basics of the Scheme programming language.
Update: watch the video
In this series on Scheme: Intro, Basics, Closures.
Here’s a presentation I did recently, on the basics of the Scheme programming language.
Update: watch the video
In this series on Scheme: Intro, Basics, Closures.
Here’s a presentation I did recently, introducing the Scheme programming language (a dialect of Lisp).
Metaprogramming is very powerful, but is usually so hard that we shy away from it. In Scheme, most metaprogramming is just “normal” programming – you can do it in the same language, and in a macro language that is very similar the normal language.
I recently did a presentation at work on “surprising” things you may encounter in JavaScript. I present it here for your delectation:
Sorting arrays was the one that wasted me the most time. Arrays in JavaScript are a neat hack on top of objects. Given that, presumably, all modern implementations have a separate type for an array as opposed to an object, you would hope that at some point they would grow up into something really different in the language.
Posts in this series: Syntax, Deployment, Metaprogramming, Ownership
The fancy word for what I’m talking about here is Deployment. How easy is it, once you’ve written your code, to get it running on someone else’s computer? What barriers are there to someone else using your program?
Examples of potential barriers include:
Anything that can be done to remove these barriers makes my life as the supporter of the program easier, and makes it more likely people will use it.
Here are some things I like:
One way to handle dependencies is to package them together with your code. This is what most corporate Java software does – the specific Java runtime that is known to work is packaged with the program itself. This makes for big downloads, and defeats the concept of providing a single package for all platforms, but it does work. It also makes for huge headaches to do with licensing, and is often impossible for software producers who don’t employ legions of lawyers. It also feels bad and wrong.
When packaging and deploying software, I subscribe to the philosophy of “Find the dependencies – and eliminate them“. Until someone can click a single button and have your software running, you haven’t finished.
In this series I will comment on what I like in some of the languages I use. I will cover things that I find convenient, things that might lead me to write correct code, things that tend to make my code more readable, and possibly other things that I just like for no clearly-articulated reason. The purpose of this series is to help me think about what features I would put in a language if I created my own.
Posts in this series: Syntax, Deployment, Metaprogramming, Ownership
What aspects of syntax and layout – how the code appears in your text editor – do I like? This is entirely irrelevant to the computer that is running the code, and an implementation detail of the language compiler or interpreter, but is extremely important to me.
Of course, there are trade-offs in all these points. Using fewer symbols can make programs verbose (although I find Python feels very concise). The lack of an end-of-block symbol makes short Python snippets look clean, but can make longer sections hard to understand (perhaps better editor support would help with this?). Scheme’s use of brackets for everything means there are a lot of brackets, so working out which does what job can be difficult.
Nevertheless, the goals of reducing the number of symbols with special meaning, allowing humans and computers to use the same ways of understanding code, and being as simple as possible are good goals to have.