Little things that matter in language design

Posted Jun 17, 2013 10:44 UTC (Mon) by erich (guest, #7127)
In reply to: Little things that matter in language design by mathstuf
Parent article: Little things that matter in language design

Oh wow. Avoiding curly braces by parentheses. That is a great feature.
I wonder if Lisp programmers can read their own code a month later...
And finding a misplaced ) in Lisp code is a masochists job.

http://readable.sourceforge.net/

Now if we could come up with a language that requires both S-expression paramtheses, C-style braces *and* python indentation (maybe also add in brainfuck/whitespace and some visual basic for applications) then we can finally build the ultimate programming language of hell.

to post comments

Little things that matter in language design

Posted Jun 17, 2013 20:03 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

Don't forget Malbolge's semantics, MUMPS's whitespace[1] and abbreviations, and INTERCAL's "PLEASE" keyword!

[1]Arguments to functions use exactly one space between them (two spaces passes as the second argument).

Little things that matter in language design

Posted Jun 20, 2013 13:02 UTC (Thu) by jzbiciak (guest, #5246) [Link]

... and INTERCAL's "PLEASE" keyword!

I would have thought COME FROM would be a better choice for such a language. That, and ABSTAIN to allow for conditional COME FROM.

MUMPS's whitespace¹

¹ Arguments to functions use exactly one space between them (two spaces passes as the second argument).

I forgot how evil MUMPS was, despite multiple articles on TheDailyWTF about it.

Little things that matter in language design

Posted Jun 20, 2013 6:12 UTC (Thu) by dakas (guest, #88146) [Link]

And finding a misplaced ) in Lisp code is a masochists job.

It's rather an editor's job. Lisp does not have a program syntax, it has a read syntax: programs are just "evaluated" standard data structures (lists, usually).

The read syntax is simple enough to be amenable to a lot of automated processing. Emacs has something like M-x check-parens RET to find file-wide problems, but paren matching and indentation is also quite helpful. Even non-LISP aware editors like vi at least offer paren matching via %.

Now this is a language design choice: using macros is so much more dependable, powerful and coherent than with C/C++ that it is not funny.

Evaluating a macro call means taking the unevaluated arguments, calling the macro on it, and evaluating the result. Evaluating a function call means evaluating the arguments and calling the function on it.

Orthogonal, straightforward, powerful. There are is no technical "parser" barrier between input and code. Instead, there is a cultural barrier between code and programmer as humans are used to plenty of interpunction and semi-graphical representations (one of the reasons people prefer mathematical formulas in composed form rather than computer-language versions of them).

It is a tradeoff at a language conceptual level. It's not actually giving in to the machine (programming in assembly or machine language is that) but rather finding a common expressive ground easily manipulated by programs themselves.

Making it human-accessible involves optical patterning via programming styles and proper indentation. It's not the same as punctuation, but then punctuation without proper indentation does not really work all too well, either, and the worst case for programs generated by programs is meaning-carrying whitespace like in Python: you can't just write the program elements without knowing indentation context, running an indenter on the result if you need nice human readability.

LISP/Scheme is a superb environment for writing code that generates and/or analyzes code, because programs are not represented by a grammar but rather directly by their parse tree which has a computer- and tolerably human-readable and -writeable representation.