Link tags: language

“Let us Calculate!”: Leibniz, Llull, and the Computational Imagination – The Public Domain Review

The characteristica universalis and the calculus racionator of Leibniz.

Standards for Writing Accessibly – A List Apart

• Write Chronologically, Not Spatially
• Write Left to Right, Top to Bottom
• Don’t Use Colors and Icons Alone
• Describe the Action, Not the Behavior

The Web is Industrialized and I helped industrialize it - daverupert.com

We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.

Dave follows on from my post about design systems and automation.

At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.

Open UI

An interesting project that will research and document the language used across different design systems to name similar components.

Mornington Crescent - Esolang

A (possibly) Turing complete language:

As the validity and the semantics of a program depend on the structure of the London underground system, which is administered by London Underground Ltd, a subsidiary of Transport for London, who are likely unaware of the existence of this programming language, its future compatibility is uncertain. Programs may become invalid or subtly wrong as the transport company expands or retires some of the network, reroutes lines or renames stations. Features may be removed with no prior consultation with the programming community. For all we know, Mornington Crescent itself may at some point be closed, at which point this programming language will cease to exist.

Language and the Invention of Writing | Talking Points Memo

Language is not an invention. As best we can tell it is an evolved feature of the human brain. There have been almost countless languages humans have spoken. But they all follow certain rules that grow out of the wiring of the human brain and human cognition. Critically, it is something that is hardwired into us. Writing is an altogether different and artificial thing.

Building on Vimeo

Here’s the video of the opening talk I gave at New Adventures earlier this year. I think it’s pretty darn good!

Humanizing Your Documentation - Full Talk - Speaker Deck

The slides from Carolyn’s talk at Beyond Tellerrand. The presentation is ostensibly about writing documentation, but I think it’s packed with good advice for writing in general.

Yet Another JavaScript Framework | CSS-Tricks

This is such a well-written piece! Jay Hoffman—author of the excellent History Of The Web newsletter—talks us through the JavaScript library battles of the late 2000’s …and the consequences that arose just last year.

The closing line is perfect.

Getting help from your worst enemy

Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.

Words become walls.

I love this post from Ben on the value of plain language!

We’re not dumbing things down by using simple terms. We’re being smarter.

Read on for the story of the one exception that Ben makes—it’s a good one.

The CSS mental model - QuirksBlog

PPK looks at the different mental models behind CSS and JavaScript. One is declarative and one is imperative.

There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.

I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a :hover style—feels like an exception rather than a typical example of CSS.

Programming as translation – Increment: Internationalization

Programming lessons from Umberto Eco and Emily Wilson.

Converting the analog into the digital requires discretization, leaving things out. What we filter out—or what we focus on—depends on our biases. How do conventional translators handle issues of bias? What can programmers learn from them?

“It turns out” « the jsomers.net blog

It turns out that “it turns out” is a handy linguistic shortcut for making an unsubstaniated assertion.

Readable Code without Prescription Glasses | Ocasta

I saw Daniel give a talk at Async where he compared linguistic rules with code style:

We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.

Thus began some thorough research into trying to uncover a universal grammar for readable code:

I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.

I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).

I’m a Web Designer - Andy Bell

Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.

I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.

The Great Divide | CSS-Tricks

An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?

The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

Use the :lang pseudo-class over the lang attribute selector for language-specific styles

This is a great explanation of the difference between the [lang] and :lang CSS selectors. I wouldn’t even have thought’ve the differences so this is really valuable to me.

HTML+ Discussion Document: Images

Back in 1993, David Raggett wrote up all the proposed extensions to HTML that were being discussed on the www-talk mailing list. It was called HTML+, which would’ve been a great way of describing HTML5.

Twenty five years later, I wish that the proposed IMAGE element had come to pass. Unlike the IMG element, it would’ve had a closing tag, allowing for fallback content between the tags:

The IMAGE element behaves in the same way as IMG but allows you to include descriptive text, which can be shown on text-only displays.

Yeah, I know we have the alt attribute, but that’s always felt like an inelegant bolt-on to me.

The 100 Year Web (In Praise of XML)

I don’t agree with Steven Pemberton on a lot of things—I’m not a fan of many of the Semantic Web technologies he likes, and I think that the Robustness Principle is well-suited to the web—but I always pay attention to what he has to say. I certainly share his concern that migrating everything to JavaScript is not good for interoperability:

This is why there are so few new elements in HTML5: they haven’t done any design, and instead said “if you need anything, you can always do it in Javascript”.

And they all have.

And they are all different.

Read this talk transcript, and even if you don’t agree with everything in it today, you may end up coming back to it in the future. He’s playing the long game:

The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.

Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.

Stop Learning Frameworks – Lifehacks for Developers by Eduards Sizovs

It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:

• Programming languages are different, but design smells are alike.
• Frameworks are different, but the same design patterns shine through.
• Developers are different, but rules of dealing with people are uniform.