Having taken my technical notes in Clojure for the past decade, and with the rapid, dynamic characteristics of Clojure doing such a good job of keeping the language out of the way of the idea, I find that tasks that say “provide answer in pseudocode” are dificult to accomodate because I’ve lost my grip on what pseudocode is; why not just in code? I suppose it just means that I am licensed to use functions I have not written yet (ie (leftmost points) ). The only hangup is that if I present the recipient with Lisp, they are liable to go cross-eyed. Has anyone else had a similar problem – that as familiarity with Lisp/Clojure increases, the concept of “pseudocode” loses definition and value?
1 Like
I find that writing Clojure without implementations feels like pseudocode.
(let [p (leftmost points)]
{:point p
:why-chosen :leftmost})
As long as there’s no (defn leftmost [pts] ,,,) around, no-one can get stuck in the details!
2 Likes
I agree completely. What do you think is the cause of this? I feel it’s a big part of dynamic typing (it’s not very pleasant “pseudo” if I have to type “String” and “Int” all the time). I also have such a tight feedback with the repl that pseudocode seems unnecessary. Now it’s just a question of whether (not-pseudo) can be clojure rather than the python-style they seem to favor
I think the problem is that while pseudocode doesn’t have a formal definition, people do have a specific expectation of what it looks like.
Taken from the Wikipedia article on LZ77 encoding
Almost every line in that example is imperative. You can convert this trivially to Java or python, but turning it into idiomatic Clojure can be a head scratcher. We don’t solve problems this way. I ran into this when implementing URI path resolution in lambdaisland/uri. The algorithm is described in an RFC somewhere, but I couldn’t just translate that directly, i had to basically reverse engineer the pseudocode to reimplement it in a Clojure way.
Another way to think of that is that a Clojure function typically contains just a single form. If you do that in JavaScript you end up with functions that start with “return” and then just a really long form. That weirds people out, and it would make for some strange looking pseudocode 
3 Likes
Excellent points. I’ve taken a stand and am going to start submitting my “pseudocode” as Lisp. The main worries I have are how they’ll respond to the parenthesis (which are a marvel at reducing ambiguity but still confuse people), The PN (the prefix < and > still throw me off, let alone the unfamiliar), and the elegantly abnormal conditionals (e.g. second arg to if is the “else”. Every one of these is a benefit of Lisp, but people usually aren’t expecting them.
1 Like
Pseudo code is just code that is close to real, but wouldn’t actually be executable on any machine. So you can skip details that would be required for a machine, but another person can infer how to fill in.
As such, it’s a communication technique. And so I’d say speak to your audience. The point is to be understood. You want the pseudo code to have just the right details, the ones you’re trying to communicate, and skip the stuff that aren’t critical to whatever you’re communicating.
If you’re talking to Lispers or FP programmers, or are specifically explaining an FP style of code, etc… I’d use a pseudo-clojure or pseudo-lisp notation.
If you’re talking to an OOP croud, and describing an imperative or OO solution, I would switch to pseudo-python or pseudo-ruby notation.
Etc.
There’s no one true pseudo-code notation.
So I wouldn’t say its lost definition, but did I forget how to speak imperative OOP, yup, I did a little. So I think like in any spoken exchange, who you are talking too, they’re level of proficiency in a given language, and yours as well all play into what language you’ll both settle in using. So say I struggle to express something in a pseudo-python I might try a pseudo-clojure and hope the recipient figures that better then my broken pseudo-python, etc. I might even end up in a hybrid 
So anyway, I’d say try and speak to your audience, being understood is the goal.
3 Likes
I thought about something taking in lisp, and displaying as imperative code, for the purpose of showing code in a more familiar way.
I don’t think this should be to hard. For most functions it’s mostly moving the opening parenthesis, and for a few macros like if you need to threat it differently.
1 Like
The point of pseudocode is to convey the algorithm without having to worry about things like whether it compiles, error checking, etc. So, why even include the parenthesis? That’s a Clojure/Lisp specific syntax. You can convey the same meaning without the parens. People would look at you cross eyed if you formatted it like Rust, Elm, Haskell, etc. as well.
Python was designed to look like pseudocode, which is why it is the way it is. I agree about dynamic languages making pseudocode less important. I wrote a lot more of it when C was the most used language and +90% of code was error handling.
When you say "technical notes*, do you mean just about code or about everything?
I take notes on meetings using freemind for mind-mapping and mindmaps are mostly just trees, so I can imagine that might be possible but I’ve never done it. I have been taking notes as I read ‘Living Clojure’ because my notes are mixed with chunks of codes. Do you have any examples, or tips on tooling? I am an emacs learner driver.
I first started taking my notes in lisp during my Master’s, taking technical notes (on paper) in Clojure. It was unambiguous and concise, so taking notes on AI or knowledge structures (including logic) was beautifully clear and consistent.
Was Python really designed to look like pseudo-code? I couldn’t find anything confirming this?
I found that this: https://en.m.wikipedia.org/wiki/ISWIM was the first conceptual language to use indentation as block delimiter, and coined the term off-side rule: https://en.m.wikipedia.org/wiki/Off-side_rule
Python uses the offside rule for statements, but not for expressions.
Also, I’ve seen a lot of pseudo-code written which didn’t make use of the off-side rule. Instead using Begin/End delimited blocks, or honestly I see a lot of curly brace ones.
I personally prefer the special character delimited pseudo-code, like curly braces or parentheses, because I often pseudo-code on whiteboards, and it’s easier to move a small brace around when needed then to re-indent the whole code I wrote, or move a lengthy BEGIN around.
Generally, I’ll start without delimiter, and so it’s true indent and line breaks might at first indicate blocks, and as it gets messier I might add delimiting braces to clarify.
Thanks. How do you represent text, e.g. as quoted strings or as lists or vectors of words? Is the Clojure mostly about providing structure for the ‘data’? Could you possibly answer in Clojure, to illustrate how you do it? This is something I’d really like to learn. Clojure has re-awakened my appreciation of simple tools.
I don’t usually bother with quotes unless I’m dealing with something that differentiates text and numbers. I find the data literals very useful (e.g. if their logic requires order, I use a vector; if no duplicates, a set; etc). I began typing up an example but realized that it was just regular CLJ (I even had a def block with a docstring). I suppose now my notes have evolved a little to be 99% done in orgmode, and literal src blocks for clojure code where necessary (orgmode provides other options for definitions, tables, and export). On paper I utilize PN, if/cond blocks, and the clarifying effects of parenthesis. I don’t have an example on hand, though, as I haven’t taken many notes on paper in a long while.
Thanks for trying. Since I asked you, I’ve revisited my notes on ‘Living Clojure’. I have code snippets that will execute in emacs clojure mode, with Cider, but I discovered I had text both as ; comments
and some just typed but Clojure parens and brackets help me lay out indented lists or vectors. I’ll keep experimenting.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.