Live data from Hacker News

Languages Which Almost Became CSS

eager.io

51–60 of 136 posts

Re: Languages Which Almost Became CSS

#51

Earlier quoted context omitted.

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.

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.

This is pretty much exactly the argument made by The Lisp Curse:

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.

Re: Languages Which Almost Became CSS

#52
post #45

Earlier quoted context omitted.

Is the original source code that Tim Berners-Lee wrote available anywhere? I would think it would be an interesting read.

Yep! http://browsers.evolt.org/browsers/archive/worldwideweb/NeXT... Interestingly, some of the code "still resides on Tim Berners-Lee's NeXT Computer in the CERN museum and has not been recovered due to the computer's status as a historical artifact."

Also check out https://www.w3.org/History/1991-WWW-NeXT/Implementation/

Re: Languages Which Almost Became CSS

#53
post #27

Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate. To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must…

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would be better if both were available, but such is life.

http://floriankugler.com/2013/04/22/auto-layout-performance-...

Re: Languages Which Almost Became CSS

#54
> It is pretty clear how this proposal was made in the era of document-based HTML pages, as there is no way compromise-based design would work in our app-oriented world. Nevertheless, it did include the fundamental idea that stylesheets should cascade. In other words, it should be possible for multiple stylesheets to be applied to the same page.

> It its original formulation, this idea was generally considered important because it gave the end user control over what they saw.

Content (i.e. ad) blockers are a logical extension of this.

Re: Languages Which Almost Became CSS

#55

Earlier quoted context omitted.

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.

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.

> 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-...)

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.

Re: Languages Which Almost Became CSS

#56
post #11

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

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 millio…

Really, all you need to do is make your own browser and then popularize it.

Re: Languages Which Almost Became CSS

#57
post #31

Earlier quoted context omitted.

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

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 fa…

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.

Re: Languages Which Almost Became CSS

#58
post #11

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

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.

Re: Languages Which Almost Became CSS

#59
post #25
post #11

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

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.

Stylesheets would be smaller, and only execute slightly slower on the client due to the expansions needed. Trading rendering speed for network speed is a good choice.

Re: Languages Which Almost Became CSS

#60
To me, PSL looks the most promising, at least the conditionals would have come handy. CSS only 'recently' got features like the CALC() function which is a blessing.

However I have to agree with the decision to put it aside, because remember how implementing something seemingly simple as CSS went in the days if IE5,6. It was a disaster and something more complex like PSL would have been even worse.

Post reply on HN