I have a hobby project: Humble programming language.
It started as a joke: a Lisp with bullet-lists instead of parenthesis. Later I added every feature I found useful or interesting from other programming languages.
I use it as some form of pseudocode to write code for complex problems I stumble upon. I wrote a translator (to PHP) for it a couple of years ago (thought of using it as an embedded language in a CMS). Nowadays I mostly play with its syntax and don't worry about the implementation.
Humble code looks like this:
// Both *actions* do the same:
- print Hello World
- print:
- Hello
- World
Recently I expanded it to include tables for expressing dictionaries, functions and variable declarations.*
This is an example of how one would define a recursive implementation of a factorial in Humble:
factorial |
|
// Note the usage of function clauses like in Erlang.
On why the tables work so well
I use the same two-column tables to express dictionaries, functions and namespaces (or variable scope), because I think that these things are nearly equivalent in how they work and only differ in what we use them for.
Here is a definition of a function from Wolfram MathWorld and my college maths book:
A function is a relation that uniquely associates members of one set with members of another set.
It looks to me that dictionaries or mapping variable names to their values fit into this definition.
This raises some interesting questions. E.g. why this does not work: [1,2,3].map({2:4})
(in JavaScript)?
Questions like these came to me like some revelation (or idée fixe) a few weeks ago. I wondered if there is a set of operations that should work on different data types (numbers, strings, lists, dictionaries) even if you don't see them often in programming languages or they are expressed in other ways. E.g.:
[2,3] + [1,4]
gives a string"2,31,4"
in JavaScript, but shouldn't this produce[2,3,1,4]
(which is equivalent toArray.concat([2,3], [1,4])
)?
To get these questions out of my head I created myself a table of data types and operations and then could focus on my work again ;-).**
This intellectual journey and reading about Erlang function clauses lead me to believe that tables are optimal for expressing functions.
Is it just a way to let off steam?
Not really. I have found Humble very useful in my work. I use it to design modules and functions which are hard for me to code straight away in the language I am working in.
As soon as I added tables to Humble, I used the new syntax to write a complex JavaScript module at my work. Before that I was stuck with the module and it was hard for me to understand on how it should work.
The reason this is so useful is that I reduced the friction and overhead involved in designing code as much as I could:
I use editors that I am very comfortable with (Zim desktop wiki, Seamonkey Composer).
I used every trick I know to make Humble code more readable and understandable at a glance.
I use a minimal number of code constructs that I am familiar with and/or think they would influence my thinking in a good way.
It expands my ability to solve problems that otherwise would be beyond my reach.
More about it
If you are interested in a more comprehensive description of Humble, see the current spec.
I can't show you the last big piece of code I wrote with Humble here because I don't want to get into misunderstandings with my recent employer. I'll leave you with some code I wrote recently to see if Humble is useful in writing code for problems listed in Rosetta Code.
Examples
99bottles |
|
||||||||
FizzBuzz |
| ||||||||
sequence |
|
Notes
* Previously I used Zim desktop wiki to write my Humble code. Zim does not support tables, so I was just writing bullet-lists. But then I started using Seamonkey Composer for that and was able to write the tables and to create myself a CSS file to make the code more beautiful.
It is interesting to note (and very visible in this case) how the choice of an editor influences what you can and cannot do with your code.
I am once more amazed that the editor I used to create my first web pages 14 years ago is still the most convenient for some jobs today.
** If you are very curious, you can see the table in a raw form, without any explanations here.
Comments
Frank
Emilis Dambauskas
FreshCode
Emilis Dambauskas
Tim
Doug Holton
Øyvind Kolås
Abra Kadabra
...
Sterling Camden