Hacker News new | ask | show | jobs
by behnamoh 697 days ago
It's interesting to see how different programming languages approach building software.

Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint. But modern tools and visual programming often take a more piece-by-piece approach. You build smaller parts first and then connect them together, gradually building up the whole thing.

This bottom-up method feels more natural to how we solve problems in real life. Visual tools make it even easier because you can just drag and drop components instead of worrying about complex code structures.

I wonder if this kind of visual, incremental approach could make programming more accessible to everyone. It might help bridge the gap between our everyday thinking and the formal world of code.

2 comments

> Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront

Languages in the Lisp family are good for prototyping and exploratory, interactive programming in situations when you don't know the solution upfront.

Bottom up from small pieces is ancient; it is not a modern technique.

> Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint.

Lisp seems like a poor example because the emphasis there is building incrementally in an interactive REPL session. I think this style of programming would be very amenable to visual programming.

I was referring to the fact that in Lisp everything is an expression, so technically Lisp doesn't stop you from writing something like this, whereas in Python you'd have to define distinct variables and nest them afterwards:

    ((if (< 1 0) + *) 42 100)
Now imagine if this were a bunch of deeply nested expressions...
Technically this works in Scheme, but not in Lisp.

In Common Lisp one would need to write

    (funcall (if (< 1 0) (function +) (function *)) 42 100)
You're right, the example I wrote was in Racket. I didn't know "everything is an expression" wouldn't work in CL.
Everything is still an expression in CL, but you have to account for different namespaces.

Also, the above can be further shortened to:

  (funcall (if (< 1 0) #'+ #'*) 42 100)
I guess I just don't see the problem that you are seeing for expression-based languages + visual programming. Are you saying that it would be cluttered if there were too many things without names?
I'm saying that expression-based languages encourage a style of programming which would resemble deep hierarchies in a visual language. They don't enforce abstractions via statements and whatnot.
You seem to be supporting your original comment about Lisp code requiring a lot of upfront planning by arguing that it is Python that requires more planning.