8 ms·

DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.

by Grue3 10y ago

agumonkey 10y ago
When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.
- marcosdumay 10y ago
  My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.
  - agumonkey 10y ago
    Possible that most people really like to have distinct level encoded as syntax.
  - mordocai 10y ago
    Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming. For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish. I don't think the problem was metaprogramming.
    - agumonkey 10y ago
      Not the same level of metaprogramming. Ruby Python try but it's less idiomatic or batshit crazy. C macros are glorified sed scripts, you're at the byte buffer level; it's cute but not good either. To me lisps sit at a nice middle ground where metalevels are as close as possible while still being usable. That's my take based on what people said in the 60s, after all sexps weren't supposed to be used.
    - marcosdumay 10y ago
      When I see people talking about Closure, I don't see them talking about the power they get from metaprogramming. It's almost the opposite, people talk about the safety of FP, and power from Category Theory. For C++ templates, you get that impression and multiply by a few googols. Now, Ruby and Python communities do claim to gain power from metaprogramming. I can say that Python metaprogramming is something completely different from Lisp's one, but Ruby's is more similar. Yet, both communities put a hard limit on the amount of "magic" you should use on your programs (where Ruby's limit is way higher than Python's), so it can not become the panacea that it is in Lisp. Metaprogramming is one of the main selling points of Lisp, the only other being how easy it is to implement. Other languages have other features to show.
      - kenko 10y ago
        What people talk about category theory w/r/t Clojure? Since it has almost no type system to speak of, I'd be very curious to know what in the world they're on about. Macros and the repl were, to me, the best part of clojure.
        marcosdumay 10y ago
        I see people talking about monads and applicatives all the time. I don't know Clojure, but I got the impression it has a powerful implicit type system.
  - jdmichal 10y ago
    This is pretty much exactly the argument made by The Lisp Curse: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html That basically every program written in a Lisp becomes its own programming language. It has mechanisms which are vaguely-familiar-but-different from all the other programs. The mechanisms are 80% of a complete solution, but a different 80% each time, depending on the needs of the program.
    - TheOtherHobbes 10y ago
      Anyone can write js. Some humans can write Lisp. But Lisp production code can only be maintained and updated by AIs who are more intelligent than we are.
  - junke 10y ago
    > whether we like it or not, each project effectively creates its own dialect of the language (http://ithare.com/cpp-guidelines-made-to-measure-s-one-size-fits-all/ http://ithare.com/cpp-guidelines-made-to-measure-s-one-size-...) Each project has its own coding guide and idiosyncrasies. That is not restricted to Lisp. Macros allow you to express some rules in a domain-specific language, not in a separate document or tacit knowledge. This is more manageable than ad-hoc approaches. Abusing macros is definitely bad and can lead to ghetto-languages. Lisp is interactive, call "describe" on whatever you don't understand. Under Emacs, if you encounter a form you don't understand, point to it, "C-c C-d d" and you get the documentation; "M-." and you go to the definition; "C-c M-m" and you call macroexpand.
  - lisivka 10y ago
    Metaprogramming scales very well. Every high-level program + compiler is metaprogram for assembler code.
    - TheCoelacanth 10y ago
      That has a much higher barrier of entry, though. If I work on a project written in Blub, I won't be able to do any metaprogramming unless I can get everyone else to adopt my Blub++ compiler. If the software is written in Lisp, all I have to do is get it through a code review. In effect, it's not really scaling; it's being limited to the small portion of developers who work on compilers.
  - kjs3 10y ago
    Um...MacLisp (which begat, amonst other notable things Macsyma and Scheme...no connection to Apple) started on the PDP-6/10.
- wtbob 10y ago
  I love Lisp, and I love s-expressions, and I honestly can't viscerally understand why others don't. From listening to my teammates' comments, I think that it has something to do with how they register visual patterns in code. Lisp really does seem to be lots of irritating silly parentheses to them: where I just see sculpted code-shapes, they see a mess of undifferentiated parens and symbols. I wonder if there really are mental types well-suited to Lisp and types ill-suited to it.
  - agumonkey 10y ago
    It also comes from which system they used. Writing lisp outside of supporting editors is indeed a nice pain. People prefer to think in terms of blocks of lines rather than (nested (groups)). Culture shock.
- talideon 10y ago
  Here's your answer: https://xkcd.com/224/ https://xkcd.com/224/
patrickmay 10y ago
The engineering management that prevented Scheme in the browser should never be forgiven: https://brendaneich.com/2008/04/popularity/ https://brendaneich.com/2008/04/popularity/
- PeCaN 10y ago
  In some alternate universe the management didn't stop Eich: Scheme became the lingua franca of the web. Smug Array Weenies criticize Scheme for being “insufficiently APL-like”, while pure functional programmers criticize APL for being “insufficiently Haskell-like”. Legions of Scheme programmers write mutually unintelligible code, though still manage to criticize Haskell for being “insufficiently Lisp-like”. Prolog fails to catch on. Brenden Eich announces that continuations are considered harmful. C programmers maintain that continuations are the most reasonable way to handle errors in C. This happens in spite of C not having continuations. Douglas Crockford invents s-expressions as a data interchange format. Douglas Crockford writes “Scheme: The Good Parts”. Guy L. Steele sues Douglas Crockford for copying the Scheme standard. Hipsters begin using Node.Scheme to write their backends and are criticized for a nonsensical package management system and “using a web language on the server”. This happens in spite of Scheme having been a server language before it was used on the web. Microsoft invents a compiler with type inference and optional type annotations for Scheme. Facebook invents a compiler with type inference and optional type annotations for Scheme. GNU Guix is promptly ignored for “using a web scripting language for package management”. Facebook invents React, which uses an extensive set of macros to write HTML components in Scheme. This is criticized in spite of having been done a few hundred times before. Guy L. Steele angrily removes string-pad-left from the Scheme standard. This breaks many packages. Non-Scheme programmers laugh and wonder if Scheme programmers have forgotten how to program, suggesting that “proper design minimizes dependencies on the language standard”. In all seriousness, Scheme would make a really good lingua franca.
  - kowdermeister 10y ago
    Wonderful write-up, you deserve a HN Gold. Umm, sorry wrong site, but still, I rarely stumble upon such a witty comment in my space.
  - 10y ago
peatmoss 10y ago
Can we have a do-over on the web? I've seen (and even nominally participated) in something of a resurgence of Gopher as something of a shadow web for nostalgia-addled geeks. Gopher isn't an awesome protocol, but I love anything that recaptures the spirit and decentralized nature of the old web. At my curmudgeon-iest I like to imagine we carve off our own web where S-expressions reign, there is no Google, and a million timecubes bloom.
- gagege 10y ago
  Really, all you need to do is make your own browser and then popularize it.
  - Kinnard 10y ago
    1 step ahead of you . . . but this staircase seems really long . . .
- pcwalton 10y ago
  And such a web would be far slower. Restyling is usually the slowest part of the rendering pipeline in an optimized implementation. Throwing arbitrary tree transformations made with a Scheme interpreter into the mix would be totally irresponsible without looking at what the consequences would be for performance.
  - jguegant 10y ago
    Isn't it the way Qt + QML works? Last time I checked, this stack wasn't particularly slow. I would also express the same style in much less lines of code than HTML + CSS.
- TheOtherHobbes 10y ago
  That may yet happen. Although CSS sucks more than a very sucky thing, and the text+markup idea barely makes sense in 2016, I can see how we got here - and how CSS needed to hit the classic "worse is better" sweet spot that allowed designers to play, and not just people who code. But that was then. If someone invents a meta-protocol now and implements a meta-browser/meta-server for it, I'd expect cult/niche status at least.
_vya7 10y ago
Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.
- smitherfield 10y ago
  Well, slower and then faster. Virtual selectors mean that CSS is now also Turing-complete (in a horrible, horrible way). And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.
  - sdegutis 10y ago
    > And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript. I severely doubt that. JavaScript can inspect attributes of anything on the entire page, run remote HTTP queries and inspect their attributes, and make styling decisions based on those, on the fly, and in response to user GUI events. Granted, I'd probably be really okay with these features no longer existing. Just saying, I don't think any DSSSL could have taken them on.
    - smitherfield 10y ago
      I should've been more clear — DSSSL might've been able, possibly in conjunction with later extensions (just as XJAX was not originally part of Javascript), to provide a similar end-user experience in many cases as CSS+Javascript currently does, albeit with very different semantics for the developer. Not sure it would be better (it probably erred on the side of too much mixing of program logic and styling rather than too little), but it would certainly be different.
  - pcwalton 10y ago
    CSS is only Turing-complete in pathological cases. Pathological cases do not make a good basis for policy decisions. In reality, the loss in performance from losing the style sharing cache alone would probably swamp any gains you'd get from DSSSL.
pwenzel 10y ago
Looking at the structure, the DSSSL language looks reminiscent of modern-day Sass.
ldng 10y ago
A DSSSL implementation on desktop still exists : openjade [1]. Could probably be ported successfully to JS today. Heck, someone could try to compile it with Emscripten. [1] http://openjade.sourceforge.net/ http://openjade.sourceforge.net/
SteveLAnderson 10y ago
DSSSL was amazing. Mr. Clark did some truly outstand work, and I benefited from using it with SGML and FrameMaker back in the day. It was hard to learn, though, and the documentation wasn't good.

DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.

by Grue3 10y ago

DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.

When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.

marcosdumay 10y ago
My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.
- agumonkey 10y ago
  Possible that most people really like to have distinct level encoded as syntax.
- mordocai 10y ago
  Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming. For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish. I don't think the problem was metaprogramming.
  - agumonkey 10y ago
    Not the same level of metaprogramming. Ruby Python try but it's less idiomatic or batshit crazy. C macros are glorified sed scripts, you're at the byte buffer level; it's cute but not good either. To me lisps sit at a nice middle ground where metalevels are as close as possible while still being usable. That's my take based on what people said in the 60s, after all sexps weren't supposed to be used.
  - marcosdumay 10y ago
    When I see people talking about Closure, I don't see them talking about the power they get from metaprogramming. It's almost the opposite, people talk about the safety of FP, and power from Category Theory. For C++ templates, you get that impression and multiply by a few googols. Now, Ruby and Python communities do claim to gain power from metaprogramming. I can say that Python metaprogramming is something completely different from Lisp's one, but Ruby's is more similar. Yet, both communities put a hard limit on the amount of "magic" you should use on your programs (where Ruby's limit is way higher than Python's), so it can not become the panacea that it is in Lisp. Metaprogramming is one of the main selling points of Lisp, the only other being how easy it is to implement. Other languages have other features to show.
    - kenko 10y ago
      What people talk about category theory w/r/t Clojure? Since it has almost no type system to speak of, I'd be very curious to know what in the world they're on about. Macros and the repl were, to me, the best part of clojure.
      - marcosdumay 10y ago
        I see people talking about monads and applicatives all the time. I don't know Clojure, but I got the impression it has a powerful implicit type system.
- jdmichal 10y ago
  This is pretty much exactly the argument made by The Lisp Curse: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html That basically every program written in a Lisp becomes its own programming language. It has mechanisms which are vaguely-familiar-but-different from all the other programs. The mechanisms are 80% of a complete solution, but a different 80% each time, depending on the needs of the program.
  - TheOtherHobbes 10y ago
    Anyone can write js. Some humans can write Lisp. But Lisp production code can only be maintained and updated by AIs who are more intelligent than we are.
- junke 10y ago
  > whether we like it or not, each project effectively creates its own dialect of the language (http://ithare.com/cpp-guidelines-made-to-measure-s-one-size-fits-all/ http://ithare.com/cpp-guidelines-made-to-measure-s-one-size-...) Each project has its own coding guide and idiosyncrasies. That is not restricted to Lisp. Macros allow you to express some rules in a domain-specific language, not in a separate document or tacit knowledge. This is more manageable than ad-hoc approaches. Abusing macros is definitely bad and can lead to ghetto-languages. Lisp is interactive, call "describe" on whatever you don't understand. Under Emacs, if you encounter a form you don't understand, point to it, "C-c C-d d" and you get the documentation; "M-." and you go to the definition; "C-c M-m" and you call macroexpand.
- lisivka 10y ago
  Metaprogramming scales very well. Every high-level program + compiler is metaprogram for assembler code.
  - TheCoelacanth 10y ago
    That has a much higher barrier of entry, though. If I work on a project written in Blub, I won't be able to do any metaprogramming unless I can get everyone else to adopt my Blub++ compiler. If the software is written in Lisp, all I have to do is get it through a code review. In effect, it's not really scaling; it's being limited to the small portion of developers who work on compilers.
- kjs3 10y ago
  Um...MacLisp (which begat, amonst other notable things Macsyma and Scheme...no connection to Apple) started on the PDP-6/10.
wtbob 10y ago
I love Lisp, and I love s-expressions, and I honestly can't viscerally understand why others don't. From listening to my teammates' comments, I think that it has something to do with how they register visual patterns in code. Lisp really does seem to be lots of irritating silly parentheses to them: where I just see sculpted code-shapes, they see a mess of undifferentiated parens and symbols. I wonder if there really are mental types well-suited to Lisp and types ill-suited to it.
- agumonkey 10y ago
  It also comes from which system they used. Writing lisp outside of supporting editors is indeed a nice pain. People prefer to think in terms of blocks of lines rather than (nested (groups)). Culture shock.
talideon 10y ago
Here's your answer: https://xkcd.com/224/ https://xkcd.com/224/

patrickmay 10y ago

The engineering management that prevented Scheme in the browser should never be forgiven: https://brendaneich.com/2008/04/popularity/ https://brendaneich.com/2008/04/popularity/

PeCaN 10y ago
In some alternate universe the management didn't stop Eich: Scheme became the lingua franca of the web. Smug Array Weenies criticize Scheme for being “insufficiently APL-like”, while pure functional programmers criticize APL for being “insufficiently Haskell-like”. Legions of Scheme programmers write mutually unintelligible code, though still manage to criticize Haskell for being “insufficiently Lisp-like”. Prolog fails to catch on. Brenden Eich announces that continuations are considered harmful. C programmers maintain that continuations are the most reasonable way to handle errors in C. This happens in spite of C not having continuations. Douglas Crockford invents s-expressions as a data interchange format. Douglas Crockford writes “Scheme: The Good Parts”. Guy L. Steele sues Douglas Crockford for copying the Scheme standard. Hipsters begin using Node.Scheme to write their backends and are criticized for a nonsensical package management system and “using a web language on the server”. This happens in spite of Scheme having been a server language before it was used on the web. Microsoft invents a compiler with type inference and optional type annotations for Scheme. Facebook invents a compiler with type inference and optional type annotations for Scheme. GNU Guix is promptly ignored for “using a web scripting language for package management”. Facebook invents React, which uses an extensive set of macros to write HTML components in Scheme. This is criticized in spite of having been done a few hundred times before. Guy L. Steele angrily removes string-pad-left from the Scheme standard. This breaks many packages. Non-Scheme programmers laugh and wonder if Scheme programmers have forgotten how to program, suggesting that “proper design minimizes dependencies on the language standard”. In all seriousness, Scheme would make a really good lingua franca.
- kowdermeister 10y ago
  Wonderful write-up, you deserve a HN Gold. Umm, sorry wrong site, but still, I rarely stumble upon such a witty comment in my space.
- 10y ago

peatmoss 10y ago

Can we have a do-over on the web? I've seen (and even nominally participated) in something of a resurgence of Gopher as something of a shadow web for nostalgia-addled geeks. Gopher isn't an awesome protocol, but I love anything that recaptures the spirit and decentralized nature of the old web. At my curmudgeon-iest I like to imagine we carve off our own web where S-expressions reign, there is no Google, and a million timecubes bloom.

gagege 10y ago
Really, all you need to do is make your own browser and then popularize it.
- Kinnard 10y ago
  1 step ahead of you . . . but this staircase seems really long . . .
pcwalton 10y ago
And such a web would be far slower. Restyling is usually the slowest part of the rendering pipeline in an optimized implementation. Throwing arbitrary tree transformations made with a Scheme interpreter into the mix would be totally irresponsible without looking at what the consequences would be for performance.
- jguegant 10y ago
  Isn't it the way Qt + QML works? Last time I checked, this stack wasn't particularly slow. I would also express the same style in much less lines of code than HTML + CSS.
TheOtherHobbes 10y ago
That may yet happen. Although CSS sucks more than a very sucky thing, and the text+markup idea barely makes sense in 2016, I can see how we got here - and how CSS needed to hit the classic "worse is better" sweet spot that allowed designers to play, and not just people who code. But that was then. If someone invents a meta-protocol now and implements a meta-browser/meta-server for it, I'd expect cult/niche status at least.

_vya7 10y ago

Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.

smitherfield 10y ago
Well, slower and then faster. Virtual selectors mean that CSS is now also Turing-complete (in a horrible, horrible way). And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.
- sdegutis 10y ago
  > And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript. I severely doubt that. JavaScript can inspect attributes of anything on the entire page, run remote HTTP queries and inspect their attributes, and make styling decisions based on those, on the fly, and in response to user GUI events. Granted, I'd probably be really okay with these features no longer existing. Just saying, I don't think any DSSSL could have taken them on.
  - smitherfield 10y ago
    I should've been more clear — DSSSL might've been able, possibly in conjunction with later extensions (just as XJAX was not originally part of Javascript), to provide a similar end-user experience in many cases as CSS+Javascript currently does, albeit with very different semantics for the developer. Not sure it would be better (it probably erred on the side of too much mixing of program logic and styling rather than too little), but it would certainly be different.
- pcwalton 10y ago
  CSS is only Turing-complete in pathological cases. Pathological cases do not make a good basis for policy decisions. In reality, the loss in performance from losing the style sharing cache alone would probably swamp any gains you'd get from DSSSL.

pwenzel 10y ago

Looking at the structure, the DSSSL language looks reminiscent of modern-day Sass.

ldng 10y ago

A DSSSL implementation on desktop still exists : openjade [1]. Could probably be ported successfully to JS today. Heck, someone could try to compile it with Emscripten. [1] http://openjade.sourceforge.net/ http://openjade.sourceforge.net/

SteveLAnderson 10y ago

DSSSL was amazing. Mr. Clark did some truly outstand work, and I benefited from using it with SGML and FrameMaker back in the day. It was hard to learn, though, and the documentation wasn't good.