Disqus - Latest Comments for akkartik

Re: From "Habitability and Piecemeal Growth," by Richard Gabriel:

Kartik Agaram — Fri, 15 Feb 2019 17:33:21 -0000

"On the other hand, people need a chance to identify with the part of the environment in which they live and work; they want some sense of ownership, some sense of territory. The most vital question about the various places in any community is always this: Do the people who use them own them psychologically? Do they feel that they can do with them as they wish; do they feel that the place is theirs; are they free to make the place their own?" — Christopher Alexander

Re: Software archeology in a mature programming environment

Kartik Agaram — Wed, 02 May 2018 16:27:19 -0000

"All services are microservices if you ignore most of their features." -- https://xkcd.com/1988

Re: An experimental UI for teaching programming

Kartik Agaram — Fri, 20 Apr 2018 03:09:57 -0000

I think it should be fixed now. Do a `git pull` and tell me how things work.

Re: An experimental UI for teaching programming

Kartik Agaram — Fri, 20 Apr 2018 02:50:02 -0000

Oh that's really interesting! Looks like my choice of name `unused` for the macro is unfortunate. I'll fix it in a few minutes.

Re: An experimental UI for teaching programming

Kartik Agaram — Thu, 19 Apr 2018 10:32:14 -0000

Thanks! I'd love to see the error message anyway. Can you just paste it into a comment here?

Re: An experimental UI for teaching programming

Kartik Agaram — Thu, 19 Apr 2018 02:07:26 -0000

Hi Shakthi, the arc folder is the first prototype of Mu from back in 2014. I moved it into a subdirectory when I promoted the C version to the root directory: https://github.com/akkartik...

(Since it's a prototype it's definitely not compatible with the current version.)

Re: The cargo cult of versioning

Kartik Agaram — Mon, 12 Mar 2018 18:37:19 -0000

How Python parses version numbers (https://setuptools.readthed... ):

Setuptools can work well with most versioning schemes; there are, however, a few special things to watch out for..

A version consists of an alternating series of release numbers and pre-release or post-release tags. A release number is a series of digits punctuated by dots, such as 2.4 or 0.5. Each series of digits is treated numerically, so releases 2.1 and 2.1.0 are different ways to spell the same release number, denoting the first sub-release of release 2. But 2.10 is the tenth sub-release of release 2, and so is a different and newer release from 2.1 or 2.1.0. Leading zeros within a series of digits are also ignored, so 2.01 is the same as 2.1, and different from 2.0.1.

Following a release number, you can have either a pre-release or post-release tag. Pre-release tags make a version be considered older than the version they are appended to. So, revision 2.4 is newer than revision 2.4c1, which in turn is newer than 2.4b1 or 2.4a1. Post-release tags make a version be considered newer than the version they are appended to. So, revisions like 2.4-1 and 2.4pl3 are newer than 2.4, but are older than 2.4.1 (which has a higher release number).

A pre-release tag is a series of letters that are alphabetically before “final”. Some examples of pre-release tags would include alpha, beta, a, c, dev, and so on. You do not have to place a dot or dash before the pre-release tag if it’s immediately after a number, but it’s okay to do so if you prefer. Thus, 2.4c1 and 2.4.c1 and 2.4-c1 all represent release candidate 1 of version 2.4, and are treated as identical by setuptools.

In addition, there are three special pre-release tags that are treated as if they were the letter 'c': pre, preview, and rc. So, version 2.4rc1, 2.4pre1 and 2.4preview1 are all the exact same version as 2.4c1, and are treated as identical by setuptools.

A post-release tag is either a series of letters that are alphabetically greater than or equal to “final”, or a dash (-). Post-release tags are generally used to separate patch numbers, port numbers, build numbers, revision numbers, or date stamps from the release number. For example, the version 2.4-r1263 might denote Subversion revision 1263 of a post-release patch of version 2.4. Or you might use 2.4-20051127 to denote a date-stamped post-release.

After each pre or post-release tag, you are free to place another release number, followed again by more pre- or post-release tags. For example, 0.6a9.dev-r41475 could denote Subversion revision 41475 of the in-development version of the ninth alpha of release 0.6. Notice that dev is a pre-release tag, so this version is a lower version number than 0.6a9, which would be the actual ninth alpha of release 0.6. But the -r41475 is a post-release tag, so this version is newer than 0.6a9.dev.

For the most part, setuptools’ interpretation of version numbers is intuitive, but [one tip]: Don’t stick adjoining pre-release tags together without a dot or number between them. Version 1.9adev is the adev prerelease of 1.9, not a development pre-release of 1.9a. Use .dev instead, as in 1.9a.dev, or separate the pre-release tags with a number, as in 1.9a0dev. 1.9a.dev, 1.9a0dev, and even 1.9.a.dev are identical versions from setuptools’ point of view, so you can use whatever scheme you prefer.

Rotflmao.

Re: Nobody's just reading your code

Kartik Agaram — Tue, 27 Feb 2018 16:38:54 -0000

Yes, this has long been a priority for me. With Mu, for example, you get up and running in 3 commands:

git clone https://github.com/akkartik/mu
cd mu
./mu

That's it! A big reason for this is minimizing dependencies. Every library a tool needs, every compiler that it requires a specific version of, is a place where somebody will trip up and have a bad experience.

Re: Nobody's just reading your code

Kartik Agaram — Mon, 26 Feb 2018 21:48:57 -0000

This was a fun post to watch develop, not least because it proved such fertile ground for forming new associations in my thinking around the subjects of programming literacy and comprehending the global structure of codebases. For example:

a) Conventional approaches to making codebases readable are like still lifes or depictions of a single scene. But since codebases are non-linear, what they need is something more like a mural. Something that can be read in many different ways. Like a Thangka (https://en.wikipedia.org/wi... ), or a codex:

https://farm5.staticflickr....

(from http://publicdomainreview.o... ) Something with multiple "centers" of narrative, to use Dave West's terminology (http://akkartik.name/davewe... )

b) We typically focus on the ability to find the right information. Your post is pointing out that knowing what to ignore is under-emphasized, and the desire to modify provides a powerful "ignore this" heuristic.

c) There's the old story about how paving cowpaths is often a better way to decide where footpaths should go. (The best source I could find is the second occurrence of 'footpath' in http://tomslee.net/2008/03/... ) In these terms, perhaps we programmers are prematurely paving narratives in our codebase. In the terms of James C Scott (https://www.ribbonfarm.com/... ), programmers are being Authoritarian High Modernist, in assuming that they understand all the ways future readers may try to read their code. Some humility for the inherent illegibility of the activity of programming (particularly how other people read code) may be in order.

d) There's a body of work on how the human brain comprehends messes (https://www.ribbonfarm.com/... ). If you see your codebase as a mess, that results in some set of ideas for improvements. But the jungle metaphor results in a whole other set of ideas.

e) When we programmers read code, it is purposefully but non-linearly. Like Bruce Willis in "Die Hard" (http://www.bldgblog.com/201... ): barging through walls, moving through elevator shafts and air-conditioning ducts. However, when we write code, we assume an idealized reader who will read our creation aimlessly but in order, content to follow our lead in all regards. This is a pretty big disconnect in all our minds.

f) Often you have something useful to tell the reader, but no obvious place to put it that the reader is likely to see at the right time. Perhaps making code easier to explore is just a matter of creating Schelling points (https://en.wikipedia.org/wi... ).

Re: The cargo cult of versioning

Kartik Agaram — Wed, 15 Nov 2017 18:12:35 -0000

That's something that OP wasn't clear about, and that I've had to clarify several times to commenters: this post isn't about fixing versions of libraries in production. That is absolutely a good thing. It's about making it easy to periodically run things like `bundle update` or `npm update` in a dev box to get the latest security fixes and bugfixes. In Ruby parlance, versions in Gemfile.lock are absolutely fine, but versions in Gemfile are a smell. (Though there's no reason the version you fix at in Gemfile.lock can't be a commit hash. Nobody should be looking at it much.)

So I think I'm already at your compromise position, and I refuse to compromise further :D I absolutely agree that enforcing a better version format isn't a panacea. I'm thinking of it rather as a strong default that will hopefully guide more people to doing the right thing.

Re: The cargo cult of versioning

Kartik Agaram — Wed, 15 Nov 2017 17:14:18 -0000

If someone's not following norms it's worth considering if they're part of the community :) They have to participate, as you put it.

In any case, I'm not claiming the problem is entirely located in the version format or package manager. But now that I have a handle on that part it's worth eradicating it. That'll make the system less noisy and hopefully make it easier to 'listen for' the next problem.

Your suggestion is indeed interesting. See Khalid's comment on Elm elsewhere in this thread. I wonder if avoiding smarts would be a better experience here than getting to 99% accuracy. I still prefer to avoid voice menus and use the touch tone interface because I know it'll be perfectly reliable. But that said, I'd be rooting for anyone who were to explore this possibility.

Re: The cargo cult of versioning

Kartik Agaram — Wed, 15 Nov 2017 08:50:55 -0000

That does seem reasonable. Thanks, I was aware of Elm but hadn't considered it in this context.

Do you have any insight into the Haskell eco-system? Does Cabal respect SemVer?

Re: The cargo cult of versioning

Kartik Agaram — Mon, 13 Nov 2017 22:11:41 -0000

Programming languages in general are pretty good at compatibility guarantees. This whole discussion is more about the eco-system of libraries around them, and the customs engendered there. These customs are often manifested as defaults in the package manager, which is why my article focused on them.

Re: The cargo cult of versioning

Kartik Agaram — Sun, 12 Nov 2017 23:37:24 -0000

I'm not trying to make things perfect, just strictly better. Yes, every change can cause incompatibility in some situations, but it's sheer innumeracy to ignore the relative probabilities. It is far more likely that an intentional incompatibility will inconvenience users than an unintentional one. Libraries follow a power law when it comes to number of users, so for the vast majority of libraries the odds that you as a single user will run into an unintentional incompatibility are extremely small. And yet we're constantly running into issues when upgrading. The vast majority of these issues are intentional incompatibilities.

Re: The cargo cult of versioning

Kartik Agaram — Sun, 12 Nov 2017 15:32:51 -0000

I'm not following you yet. Is your argument for preserving minor vs patch levels, or a broader rebuttal? Under what circumstances does SemVer tell you when going backwards will work?

Perhaps I'm captured by my constraints, but it didn't at all occur to me that going backwards is something someone may want to do. I've always treated that as a deployment consideration rather than a pinning consideration. When upgrading I may spend a while trying to fix issues, but if it doesn't work I may just roll back to an older version without any of my changes. Should I be wanting more than this?

Re: The cargo cult of versioning

Kartik Agaram — Sun, 12 Nov 2017 14:07:35 -0000

Yes, there's no way around the fact that a community has to collectively agree that this is important enough to take on some short-term pains, and to hold each other to a higher standard. That not pinning versions preemptively takes on some risk but is worthwhile. That pinning versions when libraries misbehave rewards bad behavior. (Better to fork and manage it locally, so that the pain of doing that forces you to find a new supplier for this functionality.)

I spent the first half of my life in India, where people casually drive on the wrong side of the road. In the US, on the handful of times I saw someone accidentally go down the wrong way on a 1-way street, others immediately honk at them. Long before they're in any personal danger of collision. This is a hopeful sign to me, that it is possible to engineer customs that safeguard a commons even though each individual isn't immediately affected.

Hopefully the next language to go mainstream will create this awareness from the start. It doesn't have to be precisely the solution I outlined. Just so long as we think about what eco-system we want to have, and what policy will engender it. I'm just throwing another log into the fire, in hopes of turning the tide of awareness. Consider not letting people pin versions, because that easy fix is a source of technical debt for the community at large.

Re: The cargo cult of versioning

Kartik Agaram — Sat, 11 Nov 2017 22:39:24 -0000

Thanks for the pointer to `npm install --save`. I only dabble in Node.js, and I've been modifying my `package.json` files by hand. It must have come from starting out in Rails where we manage Gemfiles by hand. I was thinking about the "" version string, which is the same as "*".

Re: The cargo cult of versioning

Kartik Agaram — Sat, 11 Nov 2017 17:15:27 -0000

Totally agreed! There's two distinct issues here: fixing versions of dependencies for testing and deployment, and pinning versions during development. I'm only concerned with the latter in this post. If you're familiar with Ruby's Bundler, it's the difference between having version numbers in Gemfile.lock (good!) and Gemfile (smell!).

The question I'm trying to answer (following in the footsteps of Rich Hickey and Steve Losh) is: how can we make it easy for developers to upgrade their dependencies so that they pick up bugfixes and security fixes but not breaking changes?

Re: A new way to organize programs

Kartik Agaram — Thu, 28 Sep 2017 21:20:43 -0000

"It is usually possible to learn about the principles of a system by watching it under construction.. In my experience complex systems have been built with layered abstractions.. As a system boots, older services organize themselves before the newer ones." http://cap-lore.com/Softwar...

Re: A new way to organize programs

Kartik Agaram — Tue, 30 May 2017 09:34:06 -0000

Absolutely. I suspect that with hindsight the analogy between software and lego may be one of the most damaging ideas in our history, turning us from programmers to line managers at some factory. Modifying code is what we *do*, and we should embrace that. Things become stable when requirements converge, not when you put them behind a plate of glass to prevent yourself and others from touching them. Not allowing ourselves to change some (most) of a codebase just makes our problems much more harder, by forcing us to generalize simple solutions to anything that anybody anywhere may want to do. There's no way you'll end up at a standard connector. You end up with every possible hook, as you say.

Worth reading is [Martin Sústrik's essay on software as memes subject to natural selection](http://250bpm.com/blog:51).

Re: Teaching taste

Kartik Agaram — Mon, 23 Jan 2017 12:22:42 -0000

Thanks for a very interesting comment. It brought a couple of things to mind (in addition to bumping "Ecology of Mind" up my reading list):

1. My friend Mike Plotz has been writing a series on Bateson: http://hyponymo.us/2015/08/...

2. One of the best books I've read on learning is "The Symbolic Species" (http://www.goodreads.com/bo.... In particular it has a great description of an experiment in teaching chimpanzees symbolic manipulation (https://www.google.com/sear... ), showing that chimps can learn negative reasoning and so evolve symbols. You first spend weeks teaching them to connect up configurations with reward, then you abruptly stop rewarding them for it, and they gradually grok that the presence of the configuration is undesirable. Another great example it describes is a peace treaty ritual between pre-linguistic tribes: if each tribe can be mock charged repeatedly by the other without reacting, you get peace.

Re: The trouble with 'readability'

Kartik Agaram — Mon, 19 Sep 2016 19:06:46 -0000

Richard Gabriel puts it better than I ever could: http://akkartik.name/post/h...

Re: From "Habitability and Piecemeal Growth," by Richard Gabriel:

Kartik Agaram — Mon, 19 Sep 2016 18:40:33 -0000

Some anti-abstraction links to pile on to that tantalizing ending:

http://www.sandimetz.com/bl...

http://programmingisterribl...

http://bravenewgeek.com/abs...

http://akkartik.name/post/m...

http://dimitri-on-software-...

http://thereignn.ghost.io/o...

Re: Art and Philosophy in Programming

Kartik Agaram — Sat, 13 Aug 2016 21:58:01 -0000

"Projects like to hide these away as “internal implementation details.” This is out of good intention, but is wrong."

I said something similar the other day: http://i.imgur.com/oFZiH68.png

My side project lately has been an attempt to learn about the internal implementation details of my computer by trying to retrace the steps of Ritchie and Thompson in co-evolving C and Unix: https://github.com/akkartik/mu. I've also been teaching programming with it: http://akkartik.name/post/mu.

Re: A new way to organize programs

Kartik Agaram — Sat, 09 Jul 2016 11:55:03 -0000

I thought the others who mentioned AOP mostly did it as related work I should be aware of, but not to say it's similar enough to the point where AOP's drawbacks translate automatically. The big differences with AOP are that a) I can insert code anywhere I want, no need for specially blessed join points, and that b) AOP still continues to build just the final monolith, whereas I add constraints about what combinations of concerns are required to continue to work on an ongoing basis. I think these additions make this a completely different beast from AOP:

1) I don't require each layer to be understandable just by reading it in isolation. I'm constantly building my program just up to a certain layer and then reading the generated code, or stepping through it in a debugger. The goal is to support interactivity in the learning process, or active reading if you like.

2) Layers absolutely patch previous layers. That's where they get all their power from. I don't make the distinction between "base program" and "cross-cutting concern". If I did, everything but layer 1 would be cross-cutting concerns. That's near 100% of the program, since I've already shown my layer 1 above: it's an empty skeleton that does nothing.

Layers are more powerful than cross-cutting concerns. They're powerful enough that they become a completely first-class unit of organization. As Alan Kay put it, "take the hardest and most profound thing you need to do, make it great, and then build every easier thing out of it." (http://worrydream.com/Early...

3) Since I don't require a "good architecture" before adding a new layer, because my mechanism for inserting code is as just arbitrary patching, and since I constantly make sense of my program by looking at the "joined" version the compiler sees, development is absolutely not blocked on reorganizing.

This doesn't mean there are no drawbacks. I tried to enumerate them in this post, and I'll do a follow-up at some point about lessons learned. But I feel confident that I am making new mistakes and not just repeating AOP's missteps.