HN Theater @HNTheaterMonth

Yeah... a couple GIFs would.

If I was them I would've just embedded this video from "Emacs Rocks!":

https://www.youtube.com/watch?v=D6h5dFyyUX0

It shows how incredible paredit is.

⬐ losvedir

Wow! That looks pretty amazing. Makes we wish I used both a lisp and emacs... Does anyone know if there is anything similar that works for non-lispy languages (using syntax like do/end, {}, etc?) and in VSCode?

not op but for me structured editing is one of the biggest pluses when it comes to editing lisp code. here is a good example of what i mean [0]. btw autolisp standard formating is kind of an anti-example of good lisp formating. in emacs lots of excellent tools exist to make parantheses an extremely helpful feature [1]

[0] https://m.youtube.com/watch?v=D6h5dFyyUX0

[1] http://www.loper-os.org/wp-content/parphobia.png

⬐ 0x445442

What I don’t like about the LISP syntax is not the parens but the inside out nature of a lot of LISP code. It’s the same reason I don’t care for NodeJS code. However, a lot of the imperative Common Lisp code I’ve seen is not nearly as jarring.

⬐ kazinator

Lisp must be read outside->in to understand what it is saying. Given (foo (a) (b c)), if you don't know what foo is and just start reading (b c), which is inside, hoping that later you can work out what is foo, you could be going down a blind alley. foo could be a macro or special operator which entirely controls what (b c) means, and so if you have no idea what foo is, it follows that your guess about what (b c) means could be completely wrong.

To understand what is calculated in Lisp, given that you understand what the syntax means, the evaluation is inside->out (that is, if the syntax is an ordinary expression made of nested function calls, and not something with a custom evaluation order).

That's no different from math. In any languages that have math-like nested expressions with bracketing, you have inside-out evaluation.

The alternative are catenative languages and such, which have never been mainstream.

There are assembly languages which go line by line.

Imperative languages with statements and expressions tend to have small expressions where evaluation is followed inside-out; the rest of the control flow is just top down, with some forward and backward skips.

Lisp has all of the above in it. Lisp can be assembly language. For instance, in this source file from Clozure Common Lisp:

https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-h...

  (defarmlapfunction fast-mod-3 ((number arg_x) (divisor arg_y) (recip arg_z))
    (mov imm0 (:lsr number (:$ arm::fixnumshift)))
    (smull imm2 imm1 imm0 recip)
    (mul imm0 imm1 divisor)
    (sub number number imm0)
    (sub number number divisor)
    (mov imm0 (:asr number (:$ (1- arm::nbits-in-word))))
    (and divisor divisor imm0)
    (add arg_z number divisor)
    (bx lr))

It's just ARM code, ending in a "bx lr" and everything.

The Lisp can be anything requires a jump in intellectual maturity and mental flexibility. You have to approach everything you might see in an unfamiliar Lisp project with an open mind, prepared for anything.

Now that's true in any large system --- but not in a way where it is rolled into one unifying syntax.

If a non-Lisp project has ARM assembly in it, it might just be conventional syntax. So you are hit on the head with a hammer: "this is obviously not the Foo language; it looks totally different". Suppose you are some newbie and don't know what ARM assembly language is; you still know that the files are something special and different.

If you're a newbie not knowing what ARM assembly is and see that in Lisp code, you just think that it's just more indecipherable Lisp weirdness. You just barely learned car and cdr and now you have (bx lr) and smull. Man, Lisp is weird!

you could take a look at this in action here:

https://www.youtube.com/watch?v=D6h5dFyyUX0

The parentheses end up serving as a tool to speed up the development process with tool like paredit. You end up manipulating the "tree" of code vs the characters on a line. Check this out: https://www.youtube.com/watch?v=D6h5dFyyUX0

⬐ bryanlarsen

paredit doesn't require parentheses to do it's magic.

Emacs has ParEdit minor mode which is a general-purpose tree editor.

https://www.emacswiki.org/emacs/ParEdit

edit: paredit demos:

Productive Emacs: Paredit https://www.youtube.com/watch?v=T1WBsI3gdDE

Emacs Rocks! Episode 14: Paredit: https://www.youtube.com/watch?v=D6h5dFyyUX0

⬐ problems

It also has org-mode which seems fairly similar, but offers additional (optional) features for doing things like tables and due dates within the tree.

I pretty much just use indented text trees for all but the most complex parts of software design and I find it works very well.

⬐ vram22

>indented text trees

You mean points and sub-points?

>all but the most complex parts

And what do you use for those?

⬐ bitexploder

Don't forget org mode or mind mapping software. Both are quite able with hierarchical data.

⬐ charlieflowers

Can you (or anyone) name some good mind mapping software (other than org mode)?

⬐ 50CNT

When I'm not using orgmode I usually use yED[0] for diagrams and graphs. Not specifically mind-mapping software, but close enough for my purposes.

[0]https://www.yworks.com/products/yed

⬐ bitexploder

Freemind is alright. Java. Does the basics. Runs everywhere. Open source.

⬐ tolas

Mind maps are really just nested lists right? https://workflowy.com/ is one of the best nested list (tree) editors I've found for mind-mapping and note-taking.

⬐ jamesrcole

How good is it?

I've never used it and I'm genuinely curious.

⬐ m1el

It depends on your requirements. ParEdit limits you to only perform AST transformations, which could be very good if you edit s-expressions or explicitly tree-like structures.

If I was working on lisp-like languages, I would definitely use it. But ParEdit didn't stick to me, even after a few attempts. I didn't like the key bindings, and I think that the interface is too complex for me.

⬐ mej10

It is amazing for working with Lisps. I use it for Clojure and it is great -- highly recommend to anyone using a Lisp to learn it. Though you'll miss having it in other languages.

Not sure what it is like for other tree structures.

⬐ torrent-of-ions

It's definitely written with the intent of using it to edit Lisp code, and for that it is great. It is now hard for me to imagine writing Lisp by editing S-expressions directly.

⬐ TeMPOraL

Pretty good, it almost make you feel you're working on trees and not text. Takes a few moments to get used to. I recommend what I did: take a bunch of Lisp code, strip it out of parenthesis (M-x replace-string, replace ( and ) with empty strings), and then use Paredit commands to restore the original tree structure. I spent less than an hour simply doing this exercise again and again, and it was enough to become a proficient user.

⬐ kovek

Good exercise. Thank you!

Also, there are alternatives. What do you think about them?

⬐ TeMPOraL

Don't know of any (could you name them?), so I don't have any opinion.

⬐ None

None

⬐ throwanem

Maybe link to the Emacs Rocks demo in future - just a thought. I share it because I've known about paredit for years and just kind of gone ¯\_(ツ)_/¯ and not bothered - but seeing that demo has sold me on the idea in a super big way, to the extent where it's going to impair my productivity today, or would if we weren't in a post-crunch breather.

By comparison, the Emacs Wiki article is a poor introduction, because introduction is not its purpose; it's there to collect resources for people who already use paredit, and a good introduction answers the question of why someonr would want to start.

That said, thanks so much for posting about it here! I'm really looking forward to learning it today.

⬐ m1el

Thanks. Added links to paredit demos.

⬐ tambourine_man

You mean this?

https://youtube.com/watch?v=D6h5dFyyUX0

Emacs's structured editing, in the style of paredit[1], sounds very similar to a text-based version of syntax-directed editing (SDE). Designed for Lisp and S-expressions, it's a system that lets you edit and navigate around nested expressions at a syntactic rather than textual language. As you type, the correct level of nesting is maintained and there are commands for moving and editing code in terms of s-expressions rather than characters.

In practice, it's very easy to start using and very powerful... but requires using Lisp. It'll seem odd if you're not regularly a Lisp user.

Happily, this idea can generalize well enough to distinctly non-Lisp languages. Structured Haskell mode[2] does this for Haskell, which has a less regular and sparser syntax than s-expressions. The documentation has a bunch of handy animations showing the various features, giving you an idea of how it works without having to install it yourself.

This doesn't address the meat of the blog post—composing languages and grammars by taking advantage of structured editing—but it shows that the necessary foundation is possible with a perfectly normal text editor. It would be interesting to see if some of the ideas from Eco could be added to structured editing modes like this without requiring you to use an external, self-contained editor.

[1]: http://www.emacswiki.org/emacs/ParEdit

[2]: https://github.com/chrisdone/structured-haskell-mode

Also, here's a great video of Paredit in action:

https://www.youtube.com/watch?v=D6h5dFyyUX0

⬐ dgellow

There is the web-mode for emacs [1] to manipulate files with different languages. It is oriented for editing templates but something more general should be possible.

Currently I am using it a lot to write React's JSX which combine javascript and XML.

[1] http://web-mode.org/

⬐ kazinator

... and of course, in Lisp you can embed other languages in terms of their syntax trees, so the composed language problem goes away. Your HTML just looks like (html (head ...) (body (h1 ...))) or whatever; no "language box for HTML" needed.

⬐ mtdewcmu

>> Your HTML just looks like (html (head ...) (body (h1 ...))) or whatever; no "language box for HTML" needed.

In your example, the language composition is smooth because there's only one language there: Lisp. HTML has capitulated.

⬐ willismichael

That's the point, HTML is just a hobbled lisp with an awkward syntax. If you're building a template engine in a lisp, it's much nicer to just use the native lisp syntax instead.

⬐ judk

HTML is a subset of lisp with a different syntax. The rest of your point holds without lashing out at HTML.

In different environments, different syntaxes show strength. What happens if you misplace a ) vs misplacing an </tag> ?

⬐ kazinator

What happens when you misplace a tag, and it's around 1995, is that browsers somehow parse it anyway without complaining, rendering the page anyway. Users then believe that this is the correct syntax: closing tags is optional, as is the order in which it is done. Twenty years later, you end up with a mess of a situation where every browser has to support not only its own historic buggy behaviors but those of other browsers.

You cannot "misplace" a closing parenthesis, at best you can have too many of them not enough. Of course, you can enclose the wrong amount of material, but to see what is being enclosed, you just need parenthesis matching support in the editor. This is more common than XML tag matching support. E.g.

http://stackoverflow.com/questions/500989/jump-to-matching-x...

⬐ klibertp

> with a perfectly normal text editor

That's... a bit unfair characterization of Emacs. It is built for extensibility, built as a development platform for Elisp packages - and that's not how most editors are designed and coded.

Anyway, it's probably completely possible to adopt many or most proposed features into Emacs but it could be prohibitively hard to adopt them into some other editors.

Add ParEdit if you don't have it yet.

(Quick overview of most it's features here: https://www.youtube.com/watch?v=D6h5dFyyUX0)

If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time.

When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily.

I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: http://stevelosh.com/media/images/blog/2010/09/rainbow.png

And here is a short minute paredit mode explanation: http://www.youtube.com/watch?v=D6h5dFyyUX0

When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs.

If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).

⬐ aetherson

I'm not advocating accepting an editor or IDE default, I'm advocating a standardized environment for a company. If rainbow parens are super-useful, then they can be super-useful for everybody.

And that's another thing that a standardized environment does: it gets techniques out there for the whole team. Because honestly I don't really believe that all that many people are truly getting their environments perfectly optimized for themselves. I think that most people in a shop where everyone does their own thing end up with high un-optimized environments.

Good environments for all, that everyone can use is better than perfect environments for a few, and mediocre environments for most, plus lack of interoperability.

⬐ JackMorgan

I could see this for a small team _in the right circumstances_ but for a whole company? That seems difficult if you are larger than 20. Imagine the headache trying to get a tool approved for even a 100 person office. And who would approve it, the manager? I see the logic that says everyone should use the best, the problem is now you take the power from the individual who best knows his job and give it to some central person who might not understand people's needs as well.

⬐ aetherson

Pivotal Labs, for example, does it with much larger than 100 person offices. They've got a repository here ( https://github.com/pivotal-sprout/sprout ) with their recipes for setting up their workstations. They have 72 contributors to the repo, so I guess it's not just a centralized manager.

⬐ JackMorgan

Do they dictate things like emacs settings? I thought sprout was for stuff like ruby version and git configs.

There's a structured editing mode for Emacs called Paredit, to use for s-expression languages like Lisp, Racket, Clojure.

Since the AST for such languages is s-expressions, and some people struggle with parens, this is an interesting "fun size" example of editing the AST.

The thing is, paredit is quite challenging for most people to adopt, due to what you mentioned about the "flow" they've already learned. Magnar Sveen has a great video about this at http://www.youtube.com/watch?v=D6h5dFyyUX0

Best quote: "If you think paredit is not for you, then you need to become the kind of person that paredit is for."

EDIT: To clarify, Magnar is quoting technomancy a.k.a. Phil Hagelberg.

⬐ MBlume

Available for vim as well. This is one of the things that consistently makes my life better. http://www.vim.org/scripts/script.php?script_id=3998

⬐ calibraxis

Yes, Paredit's not really a straitjacket, but your editor having new concepts — verbs which operate on code units.

It overrides some deletion commands to maintain your code well-formed, but there's simple ways (like cutting text) to break those rules, so it's ill-formed. (Currently, paredit won't start if it sees you're editing ill-formed text. But if it's already started, it'll continue running.)

⬐ 6cxs2hd6

Right, I realize it's not an inescapable straitjacket, and I'm definitely not putting down paredit; upvoted your comment.

I mention it because it's an example of structured editing of an extremely simple AST. And even people who want to use it (who want to leverage the so-called "straitjacket"), often find it quite hard to change their flow and adapt it.

That seems not to bode well for this being enthusiastically used generally. OTOH I suppose you could argue that a lot of people like auto-completing IDEs, and/or hate to type, so who knows.

I'll be honest with you: I'm maybe not the one to give proper advice on paredit. I'm using C# on my day job, and as such have no use for paredit (I do use ViEmu for VS though, which makes VS bearable) for most of my programming tasks.

Also, I've never done anything in clojure. I expect it to be a similar experience to CL, but the different types of parenthesis might have an effect on using paredit efficiently.

That said, I found that the following mapping really makes a huge difference when working with sexps & evil-mode:

C-l: paredit-forward-slurp-sexp C-k: paredit-backward-barf-sexp C-j: paredit-backward-slurp-sexp C-h: paredit-forward-barf-sexp

Your mileage may vary, of course. I mapped it this way because my fingers dictated it, and it plays well with vim/evil.

As to how to actually use these commands: Try them out on a few sexps, it'll be clear to you pretty soon. Also be sure to check out Emacs Rocks! ep14 (https://www.youtube.com/watch?v=D6h5dFyyUX0), it's well worth the 3:40.

I actually find learning paredit to be very similar to learning vim: You start with almost nothing (maybe hjkl in vim, but even that takes a while to get used to), and slowly add new tricks to your tool belt. Also like with vim, everyone has their own style of using the tools.

Of course, there's a ton of other things in paredit which can improve your efficiency which I haven't added to my muscle-memory yet. It's just that I found barfing/slurping to be the most bang for the buck, so I added them first.

For those not familiar with Emacs, IntelliJ IDEA with La Clojure is also an okay choice. I use IDEA for Python, Java and Scala; and still switch to Emacs when I code in Clojure. The reason is that Emacs has really strong toolset for LISP, where many of the features are missing from other environments, or implemented partially.

Slime/swank (nrepl replaces it, but I'm just slowly transitioning to it), provides code completion, documentation lookup, REPL, macro expansion and even live code updates on a running application; which can be a bit of a pain to setup on other editors. And the integration in Emacs is really great, as the repl buffer is really just a text buffer, the same as the one you are coding in.

But the biggest reason for me to code LISP in Emacs is paredit. It really makes all the trouble with balancing parenthesis and moving around the sexps really easy. It might seem counter intuitive and a bit troublesome at first, but I really recommend you to try it. For a short and enthusiastic video on paredit, see http://www.youtube.com/watch?v=D6h5dFyyUX0 -- and maybe the other Emacs Rocks! videos to learn more about modern Emacs.

⬐ peatmoss

So much slurping and barfing. I hear this guy's voice in my head every time I manipulate sexprs in paredit.