Carbon Chemist

Tag: machine readable

  • Attention, Spoiled Software Engineers: Take a Lesson from Google’s Programming Language

    Attention, Spoiled Software Engineers: Take a Lesson from Google’s Programming Language

    [ad_1]

    Many of today’s programmers—excuse me, software engineers—consider themselves “creatives.” Artists of a sort. They are given to ostentatious personal websites with cleverly hidden Easter eggs and parallax scrolling; they confer upon themselves multihyphenate job titles (“ex-Amazon-engineer-investor-author”) and crowd their laptops with identity-signaling vinyl stickers. Some regard themselves as literary sophisticates. Consider the references smashed into certain product names: Apache Kafka, ScyllaDB, Claude 3.5 Sonnet.

    Much of that, I admit, applies to me. The difference is I’m a tad short on talents to hyphenate, and my toy projects—with names like “Nabokov” (I know, I know)—are better off staying on my laptop. I entered this world pretty much the moment software engineering overtook banking as the most reviled profession. There’s a lot of hatred, and self-hatred, to contend with.

    Perhaps this is why I see the ethos behind the programming language Go as both a rebuke and a potential corrective to my generation of strivers. Its creators hail from an era when programmers had smaller egos and fewer commercial ambitions, and it is, for my money, the premier general-purpose language of the new millennium—not the best at any one thing, but nearly the best at nearly everything. A model for our flashy times.

    If I were to categorize programming languages like art movements, there would be mid-century utilitarianism (Fortran, COBOL), high-theory formalism (Haskell, Agda), Americorporate pragmatism (C#, Java), grassroots communitarianism (Python, Ruby), and esoteric hedonism (Befunge, Brainfuck). And I’d say Go, often described as “C for the 21st century,” represents neoclassicism: not so much a revolution as a throwback.

    Back in 2007, three programmers at Google came together around the shared sense that standard languages like C++ and Java had become hard to use and poorly adapted to the current, more cloud-oriented computing environment. One was Ken Thompson, formerly of Bell Labs and a recipient of the Turing Award for his work on Unix, the mitochondrial Eve of operating systems. (These days, OS people don’t mess with programming languages—doing both is akin to an Olympic high jumper also qualifying for the marathon.) Joining him was Rob Pike, another Bell Labs alum who, along with Thompson, created the Unicode encoding standard UTF-8. You can thank them for your emoji.

    Watching these doyens of programming create Go was like seeing Scorsese, De Niro, and Pesci reunite for The Irishman. Even its flippantly SEO-unfriendly name could be forgiven. I mean, the sheer chutzpah of it. A move only the reigning search engine king would dare.

    The language quickly gained traction. The prestige of Google must’ve helped, but I assume there was an unmet hunger for novelty. By 2009, the year of Go’s debut, the youngest of mainstream languages were mostly still from 1995—a true annus mirabilis, when Ruby, PHP, Java, and JavaScript all came out.

    It wasn’t that advancements in programming language design had stalled. Language designers are a magnificently brainy bunch, many with a reformist zeal for dislodging the status quo. But what they end up building can sometimes resemble a starchitect’s high-design marvel that turns out to have drainage problems. Most new languages never overcome basic performance issues.

    But from the get-go, Go was (sorry) ready to go. I once wrote a small search engine in Python for sifting through my notes and documents, but it was unusably sluggish. Rewritten in Go, my pitiful serpent grew wings and took off, running 30 times faster. As some astute readers might have guessed, this program was my “Nabokov.”

    [ad_2]

    Source link

  • The Eternal Truth of Markdown

    The Eternal Truth of Markdown

    [ad_1]

    Markdown became a core part of how I wrote. The simplicity and flexibility meant I would live the dream of write once, run anywhere. It did lead to some ambiguity, though. Gruber would probably say this is by design. His emphasis throughout the Markdown documentation is on the syntax of Markdown, not—say—the resulting HTML. His Perl script does not support HTML class names or IDs, for example, so you can’t add those to the generated HTML. By the logic of the original Markdown script, if you want complete control over the HTML output, then you’d need to write in HTML.

    This situation is great for Markdown users: that is, writers. It’s less great for programmers. In fact, it drives them crazy. Programmers do not like ambiguity. It goes against so much of what programming is about. As a writer using Markdown, I love that I can pick whichever particular version is best suited to my needs. As a programmer, I hate that when I build something I have to make this same decision, which then affects all the people who use my finished product. Maybe I didn’t support some specific extension they were expecting because they’ve always used the same Markdown parser and assume that feature is available.

    If this weren’t bad enough, there are also some ambiguities in the syntax. For example, asterisks are used for italics when singular (*like this*) and bold when doubled (**like this**). So far so good. But what should happen if you write **like* this**? Should that be rendered like* this? Or maybe like this*? There’s no way to know; whoever is writing the parser has to make that decision.

    What’s more, unlike most extremely successful pieces of code, Markdown is not publicly hosted on the code-sharing site du jour. It doesn’t have hundreds of people contributing to it, and the last time the original Perl script was updated was 2004. This too rubs programmers the wrong way. We’re a cliquish bunch; things outside the clique are viewed with suspicion.

    About a decade ago, there was an effort to eliminate the ambiguities in Markdown and bring it into line with coding dogma. Some programmers got together and created CommonMark, which makes the choices the original Markdown script doesn’t and came up with what its creators think is the One Right Way to Do It.

    CommonMark offered comfort. It’s on Github. It has a discussion forum. It seems to be an active project. I have never personally incorporated CommonMark into a project, but its parsers are what convert your Markdown to HTML on such popular sites as Stack Overflow, Github, and Reddit. (To eliminate the asterisk ambiguity, for example, it proposed underscore for italics, asterisk for bold.) Presumably the developers behind CommonMark consider it a success.

    But it’s not Markdown. Not in name, and I would argue not in spirit.

    Around the time the CommonMark effort was happening, the software developer Dave Winer told me something I still think about: Markdown belongs to everyone who uses it. This is literally true because of the license. But it also reminded me of the real point of free software. We all have a say in it: by using it, by adapting it, even by forking it.

    Whether Gruber intended it this way or not, Markdown does belong to everyone, and there is no standard. I use a very old version of Markdown for Python. Gruber presumably still uses his Perl script. Other people use other versions. It’s messy. It’s ambiguous. It’s human.

    And this, in the end, is the Way.

    [ad_2]

    Source link

  • Inside the Cult of the Haskell Programmer

    Inside the Cult of the Haskell Programmer

    [ad_1]

    At the same time, I understood almost immediately why Haskell was—and still is—considered a language more admired than used. Even one of its most basic concepts, that of the “monad,” has spawned a cottage industry of explainers, analogies, and videos. A notoriously unhelpful explanation, famous enough to be autocompleted by Google, goes: “A monad is just a monoid in the category of endofunctors.”

    The language is also more despised than explored. Steve Yegge, a popular curmudgeon blogger of yesteryear, once wrote a satirical post about how, at long last, the Haskell community had managed to find the one “industry programmer who gives a shit about Haskell.” For programmers like Yegge, Haskell is a byword for a kind of overintellectualized, impractical language with little industry applicability.

    What Yegge didn’t understand, however, is that using Haskell is rarely a pragmatic decision. It is an intellectual, even aesthetic, one. In its essence, Haskell has more in common with the films of Charlie Kaufman than other programming languages: highly cerebral, charmingly offbeat, and oddly tasteful; appreciated by those in the know and judged by outsiders as pretentious. Haskell is, one might say, a cult classic.

    That Haskell never gained widespread adoption exemplifies a paradoxical truth in software engineering: Great programming languages aren’t always great for programming.

    Haskell is not inherently more difficult to learn than something like C, but the two languages pose different challenges. Writing in C is akin to precision engineering, requiring the kind of attention demanded of a skilled horologist. But Haskell code is, really, code-shaped mathematical expressions. C is a quintessential engineer’s language. Haskell is a pure mathematician’s.

    A good engineer’s and a good mathematician’s aptitudes don’t always overlap. The industry’s not-so-well-kept secret is that most programmers aren’t as good at math or logic as you might think. This is mostly fine. After all, many doctors would make poor molecular biologists, few lawyers are legal philosophers, and the great majority of MBAs know zilch about econometrics. But this means few programmers can really master Haskell. This includes me, of course, whose legs weaken at the sight of such expressions as “F-coalgebra” and “typeclass metaprogramming.”

    Still, when I think about Haskell, a line about Martin Amis’ prose comes to mind: “the primacy he gives to style over matter.” Haskell programmers are style supremacists, and it’s nothing to apologize for. In an industry often fixated on utility and expediency, the Haskell community should not feel obligated to summon evidence of its usefulness. Instead, it should simply retort: What’s the problem with useless intellectual exercises?

    Because the thing about useless exercises is they don’t stay useless for long. Even when “industry programmers” shunned Haskell, language designers took note. In recent years, a Haskell-style paradigm has come into vogue because of the treasury of benefits it offers: rendering certain categories of bugs impossible by design, making a program’s correctness more provable, and enabling easy parallel computation. Some of the most anticipated updates featured in new versions of imperative languages are those inspired by functional programming. In the end, Backus’ anti–von Neumann plea was heard. Programming has been liberated.

    [ad_2]

    Source link

  • How I Became a Python Programmer—and Fell Out of Love With the Machine

    How I Became a Python Programmer—and Fell Out of Love With the Machine

    [ad_1]

    The difficulty with any new programming language is the sharp learning curve, all that drudgery and bashing your forehead into the keyboard. There was no Codecademy or Stack Overflow in those days. We bought books from the likes of O’Reilly and No Starch Press. I bought Learning Python and skimmed the first few chapters, but I had no project to motivate me. Without something that obsesses you, you’ll never learn to program.

    I also didn’t have much time. Running a restaurant kitchen is an all-consuming, life-sucking thing to do. After another year I burned out. I scraped together what money I had, bought a plane ticket, and headed off to lose myself in Asia. Hey, it worked for the Beatles. Sort of.

    One day, I decided I needed some more music by the great jazz guitarist Django Reinhardt. I went down to the internet café below my guest house in Bangkok to search for it. The problem was that the keyboard, naturally enough, was Thai. I could change the layout in Windows settings, but the symbols on the keys were still Thai. I figured “Django” was a distinctive enough name that that was all I needed. (This was before the Tarantino movie existed.) I typed it in and, sure enough, Reinhardt was right there in the first couple of results.

    But what caught my eye was a website for something called Django, “the web framework for perfectionists with deadlines.” I didn’t have any deadlines, but perfectionist? I can’t tell you how many times I messed with tabs and spaces to make sure my handwritten HTML was properly indented when you viewed the source. Was there, possibly, a web framework for people like me? Tell me more.

    Django, it turned out, was a Python framework. If this were a movie, there would have been a badly animated sequence here where Aaron’s face cut through a cloud of Southeast Asian traveler haze, saying, Learn Python. Learn Python. Six months later, back in Los Angeles, a friend asked me to build a website for a bike charity, Wheels4Life. I agreed to do it, on the condition that I use Django. I had a project.

    That website turned out well. It led to another. And another. Eventually I had a small business building Django-based websites. It took a couple of years, but I wrapped my head around Python and got to the point where, given a problem, I could work out a way to solve it.

    But here’s what surprised me: I never went any deeper. Never wanted to. Python falls about midway down the stack, but it’s unique in its ability to move in either direction. You can work at the highest levels of abstraction and spit out HTML websites (Django’s specialty), but you can also get closer to the machine through an API that lets you import C modules. Working in Python, I could build anything I ever wanted to build. At a certain point, I realized I wasn’t even thinking about the stack anymore. I was just thinking about the possibilities.

    I went to the first Django conference, ostensibly covering it for WIRED, but I was also there to meet the founders and learn from the community. What I found was a welcoming group of fellow nerds and programmers all working together to solve problems and build cool stuff. It was all very concrete. Tangible. Even as it arose from abstractions.

    To say that we live in an age of abstraction can be pejorative. The word implies an excessive distance from the bedrock truth of things, and we tend to view that—often rightly—with suspicion. But it seems to me, now, that the quest to de-abstract everything, to get to the bottom of the stack, is an urge born of bygone times. The bare metal can be wherever you find yourself, your language of choice, your community. That’s where you build your world.

    [ad_2]

    Source link

  • JavaScript Runs the World—Maybe Even Literally

    JavaScript Runs the World—Maybe Even Literally

    [ad_1]

    Lex Fridman has done many long interviews on his popular podcast. Even so, the episode with the legendary programmer John Carmack has an unhinged director’s-cut feel to it. Over five hours, Carmack dishes on everything from vector operations to Doom. But it’s something Fridman says, offhand, that really justifies the extended run time: “I think that if we’re living in a simulation, it’s written in JavaScript.”

    To review: JavaScript is what makes static web pages “dynamic.” Without it, the internet would resemble nothing so much as an after-hours arcade, lifeless and dark. These days, the language is used in both front- and backend development for a whole host of mobile platforms and apps, including Slack and Discord. And the main thing to understand about it, in the context of Fridman’s nerdy koan, is this: For any self-respecting programmer, admitting to actually liking JavaScript is something of a faux pas—much like an art-house filmmaker confessing to Marvel fandom.

    I suppose this has something to do with the fact that JavaScript was created in less time than it takes to home-brew a jar of kombucha: 10 days. In 1995, Netscape hired a programmer named Brendan Eich to create a language to embed in its browser, Netscape Navigator. Originally called LiveScript, the language was renamed JavaScript to piggyback on the hype around an unrelated language called Java, which had been introduced earlier that year. (Asked the difference between Java and JavaScript, a programmer is likely to joke: “Java is to JavaScript what car is to carpet.”) To this day, few people consider JavaScript a particularly well-designed language, least of all Eich. “I perpetrated JavaScript in 1995,” he once said, “and I’ve been making up for it ever since.”

    What was his crime, exactly? You can easily find scads of blog posts, memes, and Reddit threads sandbagging JavaScript, but my favorite is a four-minute talk by software engineer Gary Bernhardt titled “Wat.” Imagine, for starters, showing a group of non-English speakers the present and past forms of verbs like boil (boil/boiled) and chew (chew/chewed). Then, when you ask them for the conjugation of eat, who could blame them for answering eat/eated? Similarly, the “Wat” talk is a blooper reel of JavaScript’s quirks and unpredictable behaviors. Let’s say you want to sort a list of numbers: [50, 100, 1, 10, 9, 5]. Calling the built-in sort function in any sane language returns the list in numerically ascending order: [1, 5, 9, 10, 50, 100]. Doing so in JavaScript returns [1, 10, 100, 5, 50, 9], where 10 and 100 are considered larger than 5. Why? Because JavaScript interprets each number as a string type and does lexical sorting, not numerical sorting. Total insanity.

    When Fridman says JavaScript runs the world, in other words, what he means is that our world is, like the underlying source code, massively screwed up and incomprehensible. It’s the equivalent of pronouncing, with a sigh, that considering the sorry state of the planet, the Universal Declaration of Human Rights must have been written in Comic Sans.

    At this point, I should confess that while JavaScript is not my favorite language, I like it. Adore it, in fact. So I can’t help but feel a flare of disapproval whenever a certain fraternity of programmers polemicizes against it. Often they focus on flaws that were dealt with years ago. To dwell on JavaScript’s original shortcomings is to overlook the fact that any piece of software—and every programming language is, in essence, a suite of software—is amenable to revision and improvement.

    [ad_2]

    Source link