Gothic notes

  • 145 views
Uploaded on

Rough transcript and notes, as delivered at Balisage 2013, August 6, 2013. Paper at http://balisage.net/Proceedings/vol10/html/StLaurent01/BalisageVol10-StLaurent01.html

Rough transcript and notes, as delivered at Balisage 2013, August 6, 2013. Paper at http://balisage.net/Proceedings/vol10/html/StLaurent01/BalisageVol10-StLaurent01.html

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
145
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Allure of#Gothic Markup Simon St.Laurent DISCLAIMER [READ DISCLAIMER in auctioneer voice] O Reilly doesn t just allow these kinds of wanderings, but encourages them. If you don t have an employer that lets you talk, especially if you have one that won t let you talk about what you do, look for better employers. We can improve the world this way. Ten Years Ago Ten years ago I stood here, and I opened with 2001: A Space Odyssey and the invention of markup. But quickly, matters devolved. This is XML Schema parts I and II. The hazmat crew is out removing the black sludge it has left on our beautiful markup. At the time I was reasonably sure I had outline the problems with schema but I didn t really have a compelling solution. I suggested that we take a break, and focus on markup syntax, thinking about how people actually interact with markup as markup. It was fun; it gave me something to do for a while. But it didn t really catch on. It turns out the power of markup is not so much the syntax. So what is the power of markup? Montreal We re also in Montreal. In addition to multiple pronunciations of my name, we have this classic form of architecture stuck next to insane office building. Architectural geologists theorize that tectonic disturbances hurled parts of Quebec City and Toronto into Montreal. Somehow in the resulting collision much of the stock market moved to Toronto. As you walk around, it s hard not to be struck by contrasts. Montreal is just contrast after contrast   part of why it s an exciting place. St. Leonard Cohen de Montreal Montreal also gave us Leonard Cohen. Cohen gives us the equivalent of what Tommie [Usdin] said NOT to say:  This is the dumbest thing I ve ever heard.  This is what I expect the response will be to a lot of this talk. I am calling for repentance. Even my own biography was repenting some of my books. The usual response when you issue a call for repentance is for people to say  I don t think that applies to me. I m a good person. I have corners of my life that aren t afflicted by what you re describing.  I would encourage you to track down The Future and check out the rest of Cohen s message, though I will warn you that it needs one of those little parental advisory stickers, and was the theme song for Natural Born Killers as well. We Are Fallen Creatures This is the inside of that beautiful Minster I showed you. As you tour buildings, you get a sense of your place in them, and your place outside of
  • 2. them. It s hard to describe the effect this building has without actually going there, but you can see this tracery on the top. It invites us to become involved with it, to become involved with the building in a way that is about more than  this is the structure of the building, and it s all about form!   Don t: Politics and Morality of Tech One of the worst things you can do at a technical conference   there are the usual rules about not talking about politics, religion, and morality. We like this it s because there are diverse opinions and everyone thinks they have better opinions. There can be strange surprises, as people s views don t match what you d expected. But there s a deeper reason that we don t talk, especially about the politics and morality of technology. [Daunting scale Distribution Concurrency] The Problems Lie Deep The problems are deep   there is an entire mountain of technology that we take for granted that rests on top of our most fundamental mistakes. We Are Complicit   I Am Complicit We are complicit in these mistakes. By writing books on XML, by writing books on programming, I have encouraged them. To take a more surface example, I recently became the chair of O Reilly s open source conference. I m pretty certain that the NSA is smart enough not to use any of the open source code that I ve actually published. I don t feel that by posting libraries that kinda sorta fix Erlang string handling I ve done much to support their activities. As the chair of the Open Source Conference, I know they re attending, I know they re talking with people, and using open source as a key component of their development process. So what is my level of being attached to this? Again, while we think we are all good people, we are doing good work, there are corners that are very hard to talk about. What has Gothic to do with markup? Morality. Markup? What am I talking about with Gothic? Gothic has about 100,000 meanings. If you want to talk about a word that has been semantically obliterated, Gothic is a good choice. There is an excellent The Gothic: A Very Short Introduction (http://ukcatalogue.oup.com/product/9780199586790.do). It s about 120 pages saying  it changes . By Gothic I mean basically what comes out of John Ruskin and William Morris looking back on Gothic architecture. I m not wearing all black, and I m not talking about Gothic as currently used in typefaces. Ruskin & The Nature of Gothic So John Ruskin, who defines himself in the same book as both  a violent Tory of the old school  and  the reddest of the red , sort of meaning both, was
  • 3. someone who began in art and architectures. Modern Painters is a classic of Victorian prose. I ll let you decide if it s beautiful or overwrought yourself. In the Stones of Venice, he described the progression of buildings and architectural styles. He realized that the buildings that were frequently dismissed   after the Renaissance   were by far the most compelling. He s looking at the transition from Byzantine to Gothic, and it turns into something more than a discussion of stone and archways. Savageness Ruskin finds values in the Gothic. I left this out of the original paper but was told by Mark Bernstein that it absolutely positively had to be there, and he was right. Ruskin starts with savageness. We think of the Goths, and we think of barbarians. When you look at Gothic architecture, you see gargoyles, devils, strange ideas that someone inscribed on the side of a building. It s easy for people who think the world should be organized in classic orders to dismiss them as accidents of a deranged mind. However, they are compelling in and of their own. They reflect an individuality of the craftsmen, they bring us much closer to the people who created the buildings than abstract form can. [From Ruskin: ...go forth again to gaze upon the old cathedral front, where you have smiled so often at the fantastic ignorance of the old sculptors: examine once more those ugly goblins, and formless monsters, and stern statues, anatomiless and rigid; but do not mock at them, for they are signs of the life and liberty of every workman who struck the stone; a freedom of thought, and rank in scale of being, such as no laws, no charters, no charities can secure; but which it must be the first aim of all Europe at this day to regain for her children. Let me not be thought to speak wildly or extravagantly. It is verily this degradation of the operative into a machine, which, more than any other evil of the times, is leading the mass of the nations everywhere into vain, incoherent, destructive struggling for a freedom of which they cannot explain the nature to themselves....] Changefulness Changefulness is where I started. I actually have a friend who named his company Changeful   a brilliant re-appropriation of Ruskin. This is not the best illustration, but you ll notice that there s variation. Even when there is a clearly-defined form, even when the form is reused, there is change from item to item. If you have the time to go explore a cathedral and examine the many variations inside, things that looked the same from a distance, you will marvel. It s not just about time. Some of these things were done at the same time. Builders allowed variation, expecting things to move. You don t come up with a plan for a cathedral and say  this is the way it s going to be  and expect it to magically appear over the next hundred years of stone carving. [From Ruskin: We have now to consider what reward we obtain for the performance of this duty, namely, the perpetual variety of every feature of the building. Wherever the workman is utterly enslaved, the parts of the building must of course be absolutely like each other; for the perfection of his execution can only be reached by exercising him in doing one thing, and giving him nothing else to do. The degree in which the workman is degraded may be thus known at a glance, by observing whether the several parts of the building are similar or not; and if, as in Greek work, all the capitals are alike, and all the mouldings unvaried, then the degradation is complete; if, as in Egyptian or Ninevite work, though the manner of executing certain figures is always the same, the order of
  • 4. design is perpetually varied, the degradation less total; if, as in Gothic work, there is perpetual change both in design and execution, the workman must have been altogether set free....] William Morris William Morris takes the intricacy a little bit further. Morris was writing in the late Victorian period. You can read Charles Dickens for the social effects of the Victorian age, but Morris remained optimistic. He made it clear that it was possible for us to rejoice in our work. There had been times when we did do that, instead of taking the joy out of work by mechanizing everything in sight without regard to the worker. I like his last bit:  all but the worthless must toil in pain.  The people who were gaining the enjoyment were not people he was very fond of. Christopher Alexander During an XML show in Philadelphia, I was very excited to find the American Institute of Architects  bookstore nearby. I ran over there and I splurged on Christopher Alexander s A Pattern Language and The Timeless Way of Building and they had several of them. I brought them over to the cash register and she said  You must be be a programmer!   What gave me away? I m not wearing a badge, I m not…   Only programmers buy that. Architects don t do this stuff. That s just for programmers.  A lot of programmers know Alexander through Design Patterns, the  Gang of Four  book. If you know Alexander through that book, start again. I cite in my paper a talk he gave to the IEEE that clarifies some of it. To say that they got it backwards would be an understatement. A Pattern Language is this amazing book where you can go through and see different parts of architecture and how they work at all kinds of scales. The Timeless Way of Building explains how they figured out these things, how they got to  these are the right patterns.  More recently, he s been writing a little more polemically, because as he took his theory to the real world, he found himself battling against not just bad architecture   that happens   but against the very system by which architects operate. These two books [are actually in the social room downstairs - if you have a chance take a look.] in addition to being beautiful, they have a lot to tell us. System-A and System-B After 40 years of fighting, Alexander creates this distinction. I know a lot of people hate dichotomies, but this one in actually pretty telling. System A is what Alexander wants to do, while System B is what we actually do. System-A is iterative, with drawings coming after facts on the ground. There is a tight communications loop between client and builder   the client is always in it. The plan is in continuous development. You build the large features and only then decide on the details of the small features. This allows that strange serendipity thing to work in your builds. You drop features, if you need to, to do cost control at the end. I think everyone realizes that when you build something there are usually overruns. You control your costs by customizing your buildings to fit their situation tightly. This is not the way that  normal  architects work. Drawings come before, there s a separate designer and contractor, everything possible is done to keep the customer off the site, you draw as much as you can at the beginning. Costs are controlled as much as possible by standardization. There s a wonderful passage in Alexander where he talks about the damage that standard
  • 5. size electrical boxes have done to our buildings, because we plan around them. This has made for layer after layer of standardization replicating itself. Depth, Not Quantity Alexander proposes changing the model of work. Instead of an architect who can design a hundred buildings in a year (or a contractor who can build thousands based on a small set of plans) they become an architect-building, who works on say 20. There is a much tighter focus on the details of the work, and much less interest in scale. Scaling up is part of the problem, which is something that s really hard to tell technologists. But what has this to do with markup? Markup, houses, what? [Even Christopher Alexander s website shows little evidence of interest in markup detail!] Markup as Architecture Markup is our architecture. We live in markup. The people in this room probably excessively live in markup and we should go take a walk outside. That is why this conference is in Montreal in August. Markup creates spaces, structures, it gives us places to have fun, and perhaps most important we assemble these structures into larger groups. It s not quite the William Gibson vision of cyberspace, with its geometric columns for databases and such, but there could be an amazing visualization of the XML work done to date if we wanted to view it as a city. XML as Industrialized Data There s a problem, though. We ve build all of this on the industrial model. XML has become something that is about automation, about touching the information as little as possible. Predictable results are central. We did not invent that, I grant   predictable results have other sources. When we want to do versioning, we have all these arguments. Should we change the namespace? How do we re-label these things? We ve created brittleness that s a lot like an auto factory where they used to shut down for months at a town to shift out old model tooling for new model tooling. Markup, despite being a unique intersection of human and computer, a place where millions and millions of people actually sully their hands with the characters, is something generally considered to be avoided. There is anarchy in XML, which is good for many of this in this room, but we treat it as an exception. It is something grudingly given, or given for  this will be filled in at a later date.  Validation Validation. For my first few years of XML, I thought it was amazing. You could have this validation step that would tell us whether we should bother to work with a document, and then I could just go on happily. As I got deeper and deeper into projects, I realized that validation wasn t just about making the consumers of the data happy. It was about setting up barriers, and setting up lines of blame in systems. Beyond markup, there s
  • 6. now a tool called  git-blame  that lets you look up who changed that line of code that irks you. The happy story is probably actually less than half the story. We Fear That Work Is This We are afraid of chaos. People do very different jobs, with onlookers passing through. We know that there are all of these things happening at the same time   this terrifies us about computers and most of us strive to be the onlookers. Asynchronicity Works This Way The reality is that these complicated situations can work, and this is just normal. If you think back, away from the computer to just human experience… Here, Christ somehow got a nail In his hand, and you can guess the symbolism. His mother is asking him to give her a kiss rather than the other way around, but John the Baptist is bringing water to the room, and Joseph is looking at his hand. They re working on a door. They are shavings on the ground, lumber in the background, which in Victorian times created a huge scandal.  How dare you show the Son of God with wood shavings?  It is messy, it is complicated. But that works. This is a very human way of dealing with the world. Data Transformation Flows As we step back to markup, looking at transformations. Changefulness to me reads as transformation. We shift state. XSLT is frequently how we do this. I only figured out XSLT about five years ago. This is the most important device in the world for XML people. It s a Pachinko machine. You send the balls up, and they come down through the slots in different configurations. If you spend time working in XSLT or in functional languages you quickly find your brain becomes one of those. The other thing I wanted to mention here was internal and external structures. Transformations let you say they don t have to be the same. Sometimes this is obvious. Sometimes it s not. Douglas Crockford: JSON and Functional Programming No one shouted  Satan! . This is good. Doug extracted JSON from JavaScript   that s part of why the syntax for JSON is a little odd. He didn t invent anything. The bigger thing that he did was re-orient JavaScript developers toward this Pachinko mindset. Everything will be functions and data flowing through. He avoids schemas. The JavaScript folks in practice, without necessarily realizing it, tend to focus on transformation just as a fact of life, whether it s a simple transformation or a massive one. [I ll explain the  don t be evil  license over beer. (But no one asked.)] Human Transformers We are transformation devices, for better or worse. Even reading is a transformation, when you start looking at how you consume content. Document creation is an insanely flexible transformation. One things I suggest is that we need some transformation tools that are more than the decoration that CSS
  • 7. offers us but less even than XSLT 1.0. Something that people can just walk up to and just take as normal. A few recent finds A few things have come up since I put in the paper in July. I m actually much more optimistic in this talk than I had planned to be because of things that I keep finding that suggest that people, whether inside or outside of the markup world, are heading in this direction. John von Neumann It turns out that some people were doing this earlier   much earlier. We think of computers as they very neat on-off switches multiplied by millions of times. For the early pioneers of computing, this was not reality. They had to spend a lot of time determining whether something was wrong in their code, or whether something wacky was happening to a vacuum tube. As a result, they spent a lot of time contemplating unreliable systems, systems whose reliability was actually worse than humans. This is a very old problem. Roger Costello: Fine-Grained Validation Roger Costello, who s sitting over there, posted something to xml-dev a few weeks ago that made me feel much better about schemas. That s an achievement in itself. Instead of the  whole doucment  view that we traditionally do   and again, there have been ways to get to what failed but it wasn t fun   Roger is proposing that we do the validation piece by piece, which effectively turns the validation step into a transformation with usable results without the barrier being set, without the same kind of scapegoating. You might have many little scapegoats in your system, but you wouldn t have one giant fail. Waterfall, Agile, Lean On the business side   I m always cautious about business models and their relationship to tech. I found a wonderful description of the change I ve seen in tech in the last 20 years, from Alistair Croll. I think it applies to markup. In the waterfall system, you knew you had a problem, you figured out a solution, and you implemented it. This is the classic  Architect looks at problem, figures out solution, we build it.  Agile   which we ve all been talking about for the last ten years until we ve forgotten what it really means   is where you know you have a problem, but you iterate over solutions. You don t have one design and one build process. These days, we have people, not all of them in Silicon Valley, talking about lean models, where you don t even know what the problem is. You come up with possible problems, you test various solutions, you develop a minimum viable project, and go from there. One of the things that I love about these, is that as they ve been implementing and testing these, they ve been more willing to include people, not just customers, in these. You pass data to a person who then makes a phone call and fixes something. It turns out to be a lot cheaper to hire a person to make a phone call than to architect an entire system and distribute it on the cloud. At least up to a certain scaling point, which you may never reach. The Importance of Wheedling
  • 8. When I was coming into Canada, filling out the forms, I noticed that they have these nice little lines to keep your letters separate, and I just didn t fit. I was wondering if I was going to get flak when I got here. Of course I didn t - the customs officer looked at it, read it like a human would, and went  wham! . That was a good  wham! , not a bad  wham!  You just can t wheedle a machine. They re designed not to do that. Some fool thought that was a virtue. So… Emphasize Markup We have a unique opportunity   not entirely unique but a very strong opportunity with markup in that it has this direct connection between people and information. Programmers marvel that one of the goals of XML was that humans could approach it. It doesn t seem right from a programmer perspective. You create the data through the code, and you interact with it through the code, and the code is central, and the data is this thing that you wrap in methods. I keep   this is just as true of web stuff as it is of XML stuff   you can shift the programming to be secondary rather than primary. Transformation can be critical but the programming part of it isn t as central. You can do transformations different ways. We can do things that are as simple as just declaring that  this X is a Y thing  and it has tremendous power. Any of you who are looking at the web right now   this [in CSS] is doing huge amounts of work for you and huge amounts of work for the people building those sites. The Promised Land [That came out terrible on the projector! I m sorry! The promised land is supposed to be bright and sunny, not foggy and dismal.] I put this up because it is very deliberately bucolic. It s not downtown Montreal, it s absolutely not downtown Toronto or New York. There are people who want to live there. There are people who want to live in factories. I don t understand everyone. [Original notes: Clean Code Flexible Code Scalable Code Superpowers Concurrency Integration Provability] The Journey: Setting Out We re setting out on a strange journey. These things that I speak of, of different interactions between humans and computers, this model of transformations   I ve been told that I was looking for the Holy Grail. Welcoming: Entry Points
  • 9. We need to change the way that we approach this conversation. Even XML was daunting to a lot of people. I think part of the reason that it wound up a programmer-centric community for a while was just that even as it attempted to be accessible to humans, the conversation frequently wasn t. There s one big problem with Balisage and with the markup community in general, and with James Clark especially: and that s that we re too damn smart. We need to work on these entry points. [Ease the gap between  programmers  and  end users .] Welcoming, Not Overwhelming And be welcoming, not completely  welcome to our world, you will be one of us now. You will learn out machines and our ways.  Teaching: Get Them First! Get to people early. This is my 3-year-old with a rasp. This may be a little too early   I m not sure   but thing that I wanted to emphasize is this direct tactile contact of rasp and basswood. He s transforming that. He s doing a transformation. Now I know that isn t connected directly to a computer itself, except through a camera, but that model of creation is something we have to integrate back into our technical world or we will just be lost. Designing for Approachability We build these wonderful things, frequently   well, I d like to say that people who build editors are different, but frequently they re not different enough. People build these things expecting familiarity with computers, tech, and especially programming. It s time to get past that. I marvel that the web tools in particular are still as crappy as they are because they reach millions of people who complain about them daily. We still somehow haven t moved beyond that. Experts have a hard time conceiving of the needs and interests of non-experts, much less valuing them. Maximum Welcome We need to achieve maximum welcome. We need to say  you are savage. Life changes. We accept that into our system. We recognize the value of what humans create and not just this neat array of bits that we ve been talking about for the last sixty years. Thank you. 
  • 10. We need to change the way that we approach this conversation. Even XML was daunting to a lot of people. I think part of the reason that it wound up a programmer-centric community for a while was just that even as it attempted to be accessible to humans, the conversation frequently wasn t. There s one big problem with Balisage and with the markup community in general, and with James Clark especially: and that s that we re too damn smart. We need to work on these entry points. [Ease the gap between  programmers  and  end users .] Welcoming, Not Overwhelming And be welcoming, not completely  welcome to our world, you will be one of us now. You will learn out machines and our ways.  Teaching: Get Them First! Get to people early. This is my 3-year-old with a rasp. This may be a little too early   I m not sure   but thing that I wanted to emphasize is this direct tactile contact of rasp and basswood. He s transforming that. He s doing a transformation. Now I know that isn t connected directly to a computer itself, except through a camera, but that model of creation is something we have to integrate back into our technical world or we will just be lost. Designing for Approachability We build these wonderful things, frequently   well, I d like to say that people who build editors are different, but frequently they re not different enough. People build these things expecting familiarity with computers, tech, and especially programming. It s time to get past that. I marvel that the web tools in particular are still as crappy as they are because they reach millions of people who complain about them daily. We still somehow haven t moved beyond that. Experts have a hard time conceiving of the needs and interests of non-experts, much less valuing them. Maximum Welcome We need to achieve maximum welcome. We need to say  you are savage. Life changes. We accept that into our system. We recognize the value of what humans create and not just this neat array of bits that we ve been talking about for the last sixty years. Thank you.