11 ms·

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 hi

by steego 11y ago

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.

lotyrin 11y ago
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.
- ksenzee 11y ago
  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.)
  - lotyrin 11y ago
    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().
justinhj 11y ago
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.
- TeMPOraL 11y ago
  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.
  - eru 11y ago
    Why did you stick with PHP, if you were the only programmer and clearly prefered other languages? Too much legacy code?
    - TeMPOraL 11y ago
      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.
jwdunne 11y ago
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.
daniel-levin 11y ago
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 http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming
- GFK_of_xmaspast 11y ago
  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).
  - TeMPOraL 11y ago
    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).
    - GFK_of_xmaspast 11y ago
      How is scala a large c-ish or fortran-ish project?
      - kyllo 11y ago
        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 https://sites.google.com/site/steveyegge2/the-emacs-problem
SEMW 11y ago
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#L87 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/strategy_builder.js https://github.com/pusher/pusher-js/blob/2.2/src/strategies/...
- ludvik 11y ago
  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.
  - SEMW 11y ago
    Thanks for the explanation. Interesting to hear the reasoning behind it.
girvo 11y ago
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/ http://scriptor.github.io/pharen/
tomjakubowski 11y ago
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) https://en.wikipedia.org/wiki/LPC_(programming_language) [2]: http://lpc.psyc.eu/doc/LPC/closure_guide http://lpc.psyc.eu/doc/LPC/closure_guide

by steego 11y ago

lotyrin 11y ago

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.

ksenzee 11y ago
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.)
- lotyrin 11y ago
  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().

justinhj 11y ago

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.

TeMPOraL 11y ago
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.
- eru 11y ago
  Why did you stick with PHP, if you were the only programmer and clearly prefered other languages? Too much legacy code?
  - TeMPOraL 11y ago
    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.

jwdunne 11y ago

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.

daniel-levin 11y ago

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 http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming

GFK_of_xmaspast 11y ago
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).
- TeMPOraL 11y ago
  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).
  - GFK_of_xmaspast 11y ago
    How is scala a large c-ish or fortran-ish project?
    - kyllo 11y ago
      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 https://sites.google.com/site/steveyegge2/the-emacs-problem

SEMW 11y ago

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#L87 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/strategy_builder.js https://github.com/pusher/pusher-js/blob/2.2/src/strategies/...

ludvik 11y ago
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.
- SEMW 11y ago
  Thanks for the explanation. Interesting to hear the reasoning behind it.

girvo 11y ago

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/ http://scriptor.github.io/pharen/

tomjakubowski 11y ago

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) https://en.wikipedia.org/wiki/LPC_(programming_language) [2]: http://lpc.psyc.eu/doc/LPC/closure_guide http://lpc.psyc.eu/doc/LPC/closure_guide