Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Languages Which Almost Became CSS

eager.io

Post reply on HN
Print view View original

71–80 of 136 posts

Re: Languages Which Almost Became CSS

#71

Post by kjs3 »

marcosdumay wrote: post #19
agumonkey wrote: post #12

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.

Um...MacLisp (which begat, amonst other notable things Macsyma and Scheme...no connection to Apple) started on the PDP-6/10.

Re: Languages Which Almost Became CSS

#72

Post by marssaxman »

zackbloom wrote: post #10
schmudde wrote: post #9

"HTML is the kind of thing that can only be loved by a computer scientist. Yes, it expresses the underlying structure of a document, but documents are more than just structured text databases; they have visual impact. HTML totally eliminates any visual creativity that a document’s designer might have. — Roy Smith, 1993" Seems like an odd request in 1993. Sure, Prodigy had visual impact, but it was pretty hard to read…

You also have to think about who the audience was (Unix users) and what they were used to (Gopher, irc, plaintext email). With all of those technologies they were used to being in control of the styling of what they consumed. One person's styles for irc could be completely different than another's, and that was fine. The idea that things should be published with one rigid style which must be used to consume it was fo…

I suppose this explains why I've never really liked CSS or the design-heavy web: I was never willing to give up that control over my machine. I still resent the way modern "user-agents" aka browsers give every jackass designer out there more control over what my machine is doing than they retain for me.

Re: Languages Which Almost Became CSS

#73

Post by TheOtherHobbes »

peatmoss wrote: post #22
Grue3 wrote: 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…

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.

Re: Languages Which Almost Became CSS

#74

Post by talmand »

ergothus wrote: post #30

As a web developer, I see two main issues with web styling: First, the web was built around sharing technical papers. That means HTML structure focuses on those elements that are relevant to papers (outline layout via H* tags, tables of data, not much else), and not the sort of things that marketing and sales want to push. (ads, rails/gutters, etc). Those of use that suffered through the early "slice-and-dice" method…

How else would things go when people use a tool for which it was not designed to do? It's an evolutionary thing. A need is identified, a feature addressing the need is proposed. Then new needs are identified, new features are proposed.

The problem wasn't in the tool, the problem was the tragic slowness in the browser vendors implementing the features into the actual browsers. Don't forget that for many of those 20 years we had competing standards of different browsers doing their own thing. If the vendor didn't like a proposed feature of CSS, it didn't get implemented. I wouldn't blame CSS for that.

Every complaint that I see about lack of features of CSS or how long it took for the features we do have to get implemented I blame the browser vendors.

Re: Languages Which Almost Became CSS

#75

Post by TheOtherHobbes »

jdmichal wrote: post #51
marcosdumay wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: Languages Which Almost Became CSS

#76

Post by ryanbrunner »

Animats wrote: post #70
mahyarm wrote: post #53

Earlier quoted context omitted.

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

It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's also a subdomain that goes faster, and simple layouts should be in that subdomain. The idea is to get away from programmer-oriented layout input.

Right, but neither Lion or Grid Style Sheets were available in the early 90's. It may have been possible to implement, sure, but we're talking early enough in the web's history that the performance of the styling engine was a legitimate concern.

Re: Languages Which Almost Became CSS

#77

Post by martyalain »

Writing pages in a web site is a mess, polluted by different syntaxes, HTML, CSS, Javascript, jQuery things, MarkDown, ... It's a miracle that Wikipedia exists! Several works have been done to bring some unity, for instance Skribe, Scribble, LAML, SXML, but they generally lead to complex systems devoted to coders and forgetting web designers and, of course, beginners.

The {lambda way} project is built as a thin overlay on top of any modern web browser, and devoted to writing, composing and coding on the web, where the markup, styling and scripting are unified in a single language, {lambda talk}.

Commenting this work, somebody wrote this: « Reminds me of John McCarthy's lament at the W3C's choice of SGML as the basis for HTML: "An environment where the markup, styling and scripting is all s-expression based would be nice." »

The project can be seen here: http://epsilonwiki.free.fr/lambdaway/ or in https://github.com/amarty66.

Do you think that {lambda way} is on the good way?

Re: Languages Which Almost Became CSS

#78

Post by naasking »

pcwalton wrote: post #65
naasking wrote: post #59

Earlier quoted context omitted.

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.

Not only do I think the stylesheets would not end up appreciably smaller after gzip, I also disagree with that argument. Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Making the Web even slower at rich interactive apps is not doing the Web any favors.

> Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web.

Except this is an argument against JavaScript driven behaviour, not against a restricted styling language slightly more expressive than CSS. The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions.

Re: Languages Which Almost Became CSS

#79

Post by majewsky »

martyalain wrote: post #77

Writing pages in a web site is a mess, polluted by different syntaxes, HTML, CSS, Javascript, jQuery things, MarkDown, ... It's a miracle that Wikipedia exists! Several works have been done to bring some unity, for instance Skribe, Scribble, LAML, SXML, but they generally lead to complex systems devoted to coders and forgetting web designers and, of course, beginners. The {lambda way} project is built as a thin overl…

https://xkcd.com/927/

Re: Languages Which Almost Became CSS

#80

Post by junke »

mahyarm wrote: post #53
Animats wrote: 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-...

Some systems can be linear and solved in real-time.

https://constraints.cs.washington.edu/solvers/cassowary-toch...

Post reply on HN