Hacker News Reader

Comment by steego | Hacker News Reader

Oh noes! Don't give people these bad ideas! :)

In all seriousness, I worked with a bright guy who was a lot of fun to work with, but every once in a while his exuberance for this sort of thing would find itself in code that other people had to read/maintain. One particular example, he implemented a small subset of Lisp encoded into PHP arrays and it was used throughout some test code.

He effectively proved you could write PHP in a Lisp style and that PHP programmers overwhelmingly hate PHP flavored Lisp.

View on HN

Greenspun's Tenth Law [0] is a humorous aphorism that applies here.

>> Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

[0] http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming

What would be some recent examples of this. (In the spirit of generosity I will accept a substitution of c++ for c and a reasonably-fortranish language for fortran).

glib offers much of what Common Lisp offers as part of the language (and more, of course).

I'm not horribly familiar with glib, could you expand?

glib[1] is a library for C which provides things like portable file I/O (in Common Lisp); error reporting (in CL); hook functions (part of CL); a reader (in CL); a lists, sequences, strings & hash tables (in CL) and so forth. Common Lisp mostly has a fuller implementation of all of these.

It also has some things CL doesn't provide as part of the language: threading primitives; URL-handling; advanced calendrical calculations; basic crypto and so forth.

[1] https://developer.gnome.org/glib/

Hm, I don't think you can say that an optional, third party library is a "part of a language". Each language has a some standard library, which can be considered "part of a language", but other libraries shouldn't be. This way you could say that all npm, pypi and gem packages are part of the relevant languages.

Other than this, however, it's a good example.

Scala the language ;). Or every time someone reinvents "programming in XML" (and yes, so-called "behavioral trees" in game development, at least in their basic form, also count).

How is scala a large c-ish or fortran-ish project?

Greenspun's Tenth Rule is a joke (there aren't even any other rules numbered 1-9). It's not meant to be taken literally.

The point is that low-level languages like C and Fortran (and today, Java) are underpowered, and any sufficiently large project will evolve to the point where someone builds a (often vaguely Lisp-like) scripting language on top of it to allow developers to raise the level of abstraction, maybe without even realizing that's what they're doing.

I have seen this in action, a lot of companies build internal, proprietary scripting languages on top of their low-level programs. They may start out as configuration files, a build system, preprocessor macros, or a DSL, but over time as features get added they accidentally become Turing-complete, and eventually someone writes an interpreter and now you've invented something that serves the same purpose as Lisp, only worse.

More here: https://sites.google.com/site/steveyegge2/the-emacs-problem

> will evolve to the point where someone builds a (often vaguely Lisp-like) scripting language

No, that's not what it is about. It's not about programs needing a scripting language.

It's about the program (its framework, libraries, architecture, ...) itself. It will acquire features like:

  * late binding
  * symbols
  * dynamic data structures
  * serialization format
  * a plugin architecture with loading of code
  * advanced error handling
  * first class function objects
  * automatic memory management
  * specialized numeric datatypes (large integers, ...)
  * a dynamic object system
  * more...

The implementation language will be extended by some framework, software layers, libraries with such features ... so that over time it will implement many of the standard features of Common Lisp

Note that platforms like the JVM, .net and others nowadays provide many of that (and much more). Also language on top of those do: Java/Scala/... See for example how for Java dynamic loading of code has been implemented on top of custom class loaders.

The yolo PHP framework deliberately invokes this rule:

http://yolophp.computer/

I discovered recently that one part of the Pusher javascript library does basically this (using arrays of javascript strings, just as in the article). And this isn't test code, it's the actual code they use for connection fallback logic. Utterly bizarre.

https://github.com/pusher/pusher-js/blob/2.2/src/defaults.js...

parser in https://github.com/pusher/pusher-js/blob/2.2/src/strategies/...

I wrote that code, there were some reasons why we did it that way. First, before the 2.0 release, we ran several experiments with the connection strategy to figure out the fastest way for the clients to connect to Pusher. We haven't had much experience with HTTP fallbacks, so it was important for us to make the learning process easier. This DSL helped a little bit.

The main reason was that we were thinking about helping clients with server-supplied connection strategies. We could gather some metrics and tell the client in advance that, for example, WebSockets won't work due to some network issues. We also thought it could be useful for orchestrating migrations and working around potential load balancing issues. Injecting JavaScript was out of question, so I wrote this JSON DSL for connection strategies.

We haven't done that and it's probably never going to happen. The Internet has moved on, we dropped support for some ancient browsers, connectivity has improved and we haven't really felt a need for that feature, to be honest.

I agree that at the moment it's unnecessary.

Thanks for the explanation. Interesting to hear the reasoning behind it.

That sounds really horrible, but as a lisp enthusiast that worked on a substantial live system in PHP for a couple for years, I do believe it's possible to write a fair amount of PHP in a functional style. Making use of array reduce, map and filter for example.

It is possible. I actually ended up doing it, partially because I was sick of PHP already and partially because I was the only programmer on the project anyway. array_map and family, however, don't make PHP a scary Lisp. Try writing something along the lines of destructuring-bind "macro", on arrays; I'm still both happy about how it worked and happy that noone else will ever see it; non-lispers would probably gouge their eyes out.

Why did you stick with PHP, if you were the only programmer and clearly prefered other languages? Too much legacy code?

Because the job came easy and I liked it initially. With money inflow temporarily secured I focused on dealing with other areas of my life. I didn't notice how much I'm burning out at first. By the time I did, I started having financial difficulties, because my salary started following my work performance, which was decreasing because of the progressing burnout, which... well, I managed to escape that feedback loop after spending over an year in it, but not unscratched. So basically at first I didn't leave because I liked the stability, and later I couldn't because of a sense of duty.

I was originally in a team of 4-5 programmers, but the company slowly got rid of everyone except me. At that point I tried to leverage the situation and institute some changes in the programming languages, web stack and workflow automation; most of them were rejected by the boss on the grounds like "sure, we could switch to something better - like say, Ruby - but Ruby programmers are much more expensive than PHP."

It took me a lot of work and pain to eventually leave. My two biggest mistakes:

1) Not noticing when was the best time to go. There was a moment when the old project ended and they wanted to get me into a next one. Building it solo. From scrapped bis of metal. I should have left right there.

2) Being too afraid of changing jobs. I know that with my skills I can land a new programming job very quickly, but the process of job interviews scares me.

Oh, and 3) Singing that exit-level contract that ended up with me working my ass off in the evenings to finalize some contracted components.

Thanks for the write-up!

Job interviews are a nuisance, but easily trainable. :)

Another example is the somewhat obscure language LPC [1], which has a C-like syntax except that you write anonymous functions (called "lambda-closures") in an ugly Lisp-ish DSL [2]:

      x=filter(a,lambda(({ 'o }),
                              ({ (#'>),
                                 ({ (#'call_other),
                                    ({ (#'environment),'o }),
                                    "query_level"
                                 }),
                                 WL_APPRENTICE
                              })));

[1]: https://en.wikipedia.org/wiki/LPC_(programming_language)

[2]: http://lpc.psyc.eu/doc/LPC/closure_guide

Oh god, haha. I've been tempted to do this before. I ended up just writing a parser in PHP. The idea was to compile the code to phar and then bootstrap the compiler in Liphp (I chose Liphp because of the mashup AND to tease my mrs about her childhood lisp in an original way).

Before the bracket-syntax for arrays, this would have been awful to maintain.

Drupal "theme arrays" are not entirely different. They wanted expressions covering what to be themed and how to theme those things and to allow nesting of this information - S-expr flavored PHP. I wish I knew if this had been done on purpose or if it was (just) a sad accident.

I'll guess theme() was inspired by s-expressions, whether consciously or not. The theme() function dates from when Dries was a CS student writing a lot of the code himself.

(It's also worth noting that theme() hasn't worked this way since 2011; it now takes a more PHP-style associative array of named options.)

I'm not sure you understand. theme() appears to just be a pretty simple observable ("hookable") delegator... I mean the extreme flexibility (and great potential for large amounts of slow synchronous processing from abuse) of using nested trees of elements with '#theme' function set as passed to drupal_render().

Related: Scriptor has created what some would call an abomination, but I consider a hell of a lot of fun to play with -- Pharen, an entire Lisp in PHP :)

http://scriptor.github.io/pharen/

Reply on news.ycombinator.com