That one's a cooler hack because it runs in old awk, from before they supported user-defined functions. The whole read-eval-print composition is a straight-line series of loops, with the recursions unrolled into explicit stack manipulation. If you want to see how to write fairly readable code within those restrictions, it's instructive. It even has a cooler name. (I said so when bringing it up in my documentation.)
On the other hand, awklisp has some value as a readable Lisp interpreter in a lower-level but still reasonable language, in between the usual Lisp-in-Lisp and Lisp-in-C tutorials.
Yep, that's pretty much how you have to do it. (If all you need is increment/decrement, though, you can actually do it pretty concisely with decimal-digit strings. Skipping the binary-to-decimal conversion greatly simplifies displaying numerical values.)
The GNU sed manual has examples like that at the end. It always seemed odd to show examples of things that are so awkward and inefficient. If they meant for sed to do those things, presumably they would have made commands for them.
Would someone mind giving a quick explanation of how this works? I have only used sed to replace text in files and directories. How do people write interpreters and game loops with this unix utility?
I started playing with the idea of making a programming language out of sed at one point, but then I decided that, even if I succeeded, it would be a waste of time.
the sed language allows conditional jumps to labels. That makes it powerful enough to write programs in.
If you had to just write programs by running a series of sed substitution expressions to a file over and over, and not use conditionals... it might still be possible to program in. Much harder to think about, though.
s2p: expression #1: extra characters after command (d)
Thankfully, I've never had the job of porting a sed script to Perl, so I'm not exactly sure what that's all about. The docs mention this error, but don't explain what it means,
The way you can nest conditions in sed, like /foo/ { /bar/x }, is pretty powerful, and I knew a good bit of sed before I realized you could do that. It's not readily obvious from the manual.
It will be a challenge to make an interpreter for a better language faster than dead slow.
I would bet on a compiler for a better language instead. That way, only one person would have to wait ages and ages. I doubt the result would be fast, but it wouldn't be insanely, insanely, insanely slow, either.
I would much rather hand assemble machine code than program in sed. I imagine most people have a better understanding of how computer architecture works than how to do arithmetic and logic with sed.
One theory that people often bring up vis-a-vis readability of lisp is that people seem to have a harder time parsing symbols than words (so all the parens makes it harder to look through a file).
Compared to python or coffeescript, it feels like there's a lot less noise
i am not particularly gifted at computer science and especially not programming languages. by necessity, the only languages i know are JavaScript and lisp. so I am always surprised to hear lisp is "unreadable" as opposed to "unfamiliar".
I think that Lisp got a reputation for being unreadable because some Lisp programmers have the tendency to get too far into macros to extend the language, resulting in a language that other developers have not seen before.
I think that's pretty much a straw man. Where is all this terrible macro-laden Lisp code? Well, it's probably not totally made up, but you run into overcomplicated abstractions in every language.
Somehow it seems more likely that people are put off by the slightly "isolationist" culture of Lisp, or the historical clash between Lisp and Unix, or whatever, and then this "unreadable" idea is like a rationalization for not liking the language? This is just a hunch...
You could make all kinds of arguments for the difficulty and obscurity of Haskell, yet it's winning ground quite effectively. I think this basically started with the success of GHC and Cabal/Hackage in creating an infrastructure that's familiar and efficient.
The Lisp world always had good infrastructure engineering. The main compilers (SBCL, CMUCL, etc) are very impressive! But it takes a very intensive kind of community engagement nowadays to stay up to date.
I still think Lisp could have a renaissance. Maybe it's already going on with Clojure. And of course Emacs is quite strong.
The ideal of programming seems to be software architectures based on layers of coherent abstraction. That's very, um, abstract, and there are different ways to do it. With OO, you imagine objects cooperating in layers. With Haskell-like functional programming, you use a mathematical style of abstraction, trying to find theories and algebras that make sense and compose, building applications out of combinations of well-typed values, etc.
Paul Graham describes the Lisp style in his texts on Lisp. You can see it in Emacs's various DSLs (for defining customization parameters, for traversing buffers, etc). It encourages abstraction layers built so as to form mini-languages. So a library can easily provide custom syntactic forms. Instead of having a small number of syntactic forms (if, for, etc) and an expression language based on function application, Lisp is syntactically extensible.
Programming is not a solved problem! We still aren't really sure about how to design programs, how to create coherent abstraction layers. The Haskell approach is very interesting, but not totally fleshed out. People are still working out the best way to structure concurrent I/O pipelines with error handling, for example. I sort of lost my train of thought, but Lisp is very interesting!
It's not a straw man for me -- it's what I think of a lot of Lisp code.
I think it's really instructive to compare things written in the early days of Clojure to Clojure right now. Some times I just want to find the author of some code block, shake them, and yell "No! The only reader macros you are allowed to use are ', `, and #() !". Absolutely beautiful language, but way too easy to make unreadable.
I'm not justifying Lisp's reputation, I am trying to explain it. Whether Lisp's reputation is justified or not is immaterial to my comment. Personally, I believe that the reputation is not justified.
I like scheme to be honest, especially the racket style of preferring define over let. Combined with well chosen variable names, list comprehensions, pattern matching and optional square brackets, all but the trailing ))))) becomes not a problem.
My theory is that it has to do with not having any operators, except parentheses, and using exclusively prefix notation, where other languages allow infix for doing arithmetic. Also, in Scheme loops are usually recursion, which means they have no standard form and they are upside-down from usual (the loop condition and increment are near the bottom, where the recursive call is).
Say what? Both replies are saying that macros can make it tough to read. (Though, personally, I don't have a problem with most macros -- just reader macros.)
