Like @Wintermute, I'm struggling to follow what you're trying to say. The "better tools" you're referring to are precisely package managers. And they're useful precisely because they don't automate the decision entirely (leaving humans disempowered) but because they "help with those decisions" as you put it. So it's unclear to me where we disagree. Let me try to knock off a few things I'm not saying, just in case they weren't clear before: a) I'm not saying we should be deploying software to production by wantonly installing whatever the latest version of our dependencies happen to be. Things like Gemfile.lock in the Ruby/Bundler world are a good idea, and my post isn't about them at all. b) I'm not saying we should be upgrading our dependencies en masse and immediately running `git commit` without testing that the upgrade actually worked. Upgrading dependencies will and should always be a manual process. I just want it to be less of a bottomless time-sink. The two links I mention at the start of OP set all this background up. Perhaps I should have explicitly said people need to read/watch them before reading me. They're actually better posts written by better writers and programmers, so they're almost certain to be a better use of your time than my miniscule contribution (that I wrote without understanding Cargo, and so may well already be hopelessly wrong).
Yes, I'm not familiar with Rust, and I've been meaning to learn more there. The best response to my post thus far started off with a description of how Rust has successfully policed SemVer, and the issues they ran into: https://news.ycombinator.com/item?id=15676691#15677343. I'd greatly appreciate further pointers to how that community does things. > Nothing interesting is trivial. That's almost tautological. Calling something out for being non-trivial is either meaningless.. I just provided a trivial alternative that I found interesting. So much for your "tautology". > ..or equivalent to calling it hard[er than it should be]. I do call it harder than it should be, by providing a simpler alternative. It doesn't look like you disagree that a tuple is easier for the package manager to unpack than a string. You seem to be only saying that the difference isn't much. I've already agreed with that. So what are we arguing about? --- I have a problem with the statement that "nothing interesting is trivial": it becomes license for hiding over-engineering. I'd rather say that "everything can be trivial". It's right about the same fraction of the time, and even when it's wrong it's an impetus to find better ways, rather than to be complacent. I spend some time teaching programming, and it's amazing to me how often finding the right approach to teach something renders it almost trivial. See also Alan Kay's statement about the right perspective being worth 80 IQ points. --- I have a problem with statements as general as "nothing interesting is trivial" (Or, indeed, "everything can be trivial".) They aren't concrete enough to actually support any serious amount of reasoning. You can end up anywhere you like depending on how you interpret them. This comment is about as much of such fluffy debate as I can handle without breaking out in hives. --- Seriously, stop nit-picking wording in one sentence I quickly moved past in OP. It's mystifying to me why that's a better use of your time, rather than to elaborate on the "practical reasons" you so quickly skip past. I'm going to stop engaging here unless it is to discuss more substantive criticisms.
I agree that the article needs to change something. I'm not a good writer yet, and I definitely failed to get my point across to many (most?) readers. But I don't think separating package managers from the discussion of versioning is a good idea. Versioning is a social convention (as evidenced by the quantity of criticism my attempt at changing convention has engendered), and the #1 place the convention is propagated is in the package manager. You can in principle implement every one of my recommendations (or any alternatives people proposed in comments) without changing the package manager. But of course nobody would expect that to take. The big insight that provoked my post was that the bad behaviors the creators of Clojure and Mercurial were complaining about stemmed from bad defaults in package managers. > "3.0.2" is hard to parse? Are you serious? If this was the only sentence-level criticism you could make I'm not doing so bad :) Notice that I said "non-trivial", not "hard". In a tool whose #1 reason for existence is to "get the latest version", it seems a bad idea to make the format of version strings unstructured in code (they're literally strings surrounded in quotes) or convention (people are encouraged to add arbitrary words to them). Why make comparison unnecessarily difficult? I'm talking about creating a package manager from scratch (I'm not proposing every package manager break their users in a post about not breaking your users) for some hypothetical next big language, and in that situation it seems worth fixing even if it's not that big a deal. > The software I write for my job has version numbers, even though it isn't distributed through any package manager. My recommendation may absolutely not apply then. If your software isn't ever being upgraded en masse I have no opinion on what versions it should have. I'm speaking in the context of eco-systems that want to be able to distribute security fixes (at the least) on an ongoing basis. That's what the two links I was putting together were talking about, and that usually involves a package manager to automate the upgrade process.
The convention programmers have long followed is now enshrined as something called Semantic Versioning (which comes with its own version, lol). Basically if a library makes an incompatible change it's supposed to increment the major version. So going from Rails 4.x to Rails 5.0 is a sign that you can't upgrade. Which is great in theory, except that the tools we programmers use to manage versions don't understand SemVer and just pick the latest version by default. Which causes programmers to explicitly ask for the version they want to avoid moving to the next. And all the 'pinning' in turn causes libraries to be less than disciplined about incrementing the major version number when they break something. So it's all a mess.
Sorry, yes you're absolutely right and I'm being unclear. I'm a reasonable programmer but not a good writer. When I say "rename" I don't mean going from "Snow Leopard" to "El Capitan". That's stupid, yes. (And it's also marketing, which I know even less about. So I have no comment on what an improvement would be.) My proposal is going from "Rails-4" to "Rails-5". Which would have the same benefits as 10.11 and 10.12. The comments I've gotten so far are making clear that I failed to set the stage for this post. The scenario I'm concerned about (as are the links I refer to) is this: you have an app you built, and it relies on some versions of other libraries. You'd like to periodically pick up bugfixes and security fixes for those libraries without it turning into a bottomless time-sink (because your libraries failed to adequately distinguish between compatible and incompatible changes). How do we do that? (It's not just about tool design, it's about eco-system design.)
Yes, if you can't relate with the problems mentioned in the talk and article I linked to, I guess you don't need the solution 🙂 Code shared between closely coupled teams tends to be the easier use case. Have you ever had issues upgrading your personal devices? I remember times when I couldn't get some Rails app running on my laptop after upgrading the OS. Anything like that ever happen to you?
I wrote an article about my first game a couple of years ago. Probably massively over-thinking it :) On a related note, I've been watching Survivor after looking down my nose at it for the last 15 years.
I read this passage this morning, and it reminded me of this old bicycle I used to have, that I didn't realize I loved until after it was stolen: -- Kim Stanley Robinson, "Aurora"Love is a kind of giving of attention. The one that is feeling the love has the universe organized for it as if by a kind of polarization. The giving is the getting. The feeling of attentiveness is its own reward. We had a labor of love. It absorbed our attention entirely. It gave a meaning to our existence. And this is a very great gift; this meaning is in the end what love gives. Because there is no obvious meaning to be found in the universe, as far as we can tell. But a consciousness that cannot discern a meaning in existence is in trouble, very deep trouble, for at that point there is no organizing principle, no end to the infinite search, no reason to live. No: meaning is the hard problem, and we solve it by giving and getting attention, and then it's all very interesting. It is a joy to serve.
Sorry I wasn't clear. I'm not saying anything permanent and immutable about either men/women or high/low level languages. Rather I'm thinking about the path by which people learn, and claiming that the way we teach has, by historical accident, favored a very narrow subset of personality types with specific initial cognitive strengths. The others might well have become just as good or better programmers in the end, but they drop out very close to step 1, because of a format ill-suited to them, before they have a chance to find out. When we say someone is a more visual or linguistic learner we aren't claiming they can't understand pictures or that their verbal GRE score is doomed to be low. We're just saying that they lean on one side/lobe of their brain more heavily than the others at the most initial stages of learning. I was speculating in similar vein.
Yeah, the 'motor control' section could be emulated by tmux+inotify. But you'd still have trouble writing tests that "the screen looks like this when you type this", and so on. It's also hard for learners to grok tests and code at the same time, so they currently learn testing later and not as well, or not at all.
I shared it recently, a logarithmic radial view of the known universe:
The mirror of her dreams by Stephen Donaldson. Bit of a slog (maybe I don't like fantasy as much as I used to?), but I just finished it.. and found it ends in a cliffhanger, and I'm supposed to read the second volume to see how it turns out. Not sure if I want to do that :/
Hmm, hadn't considered that. The OP never mentioned encryption. Immediate reaction: it would be hard to have privacy in a decentralized setup. You have to choose one or the other.
My reading was that it would be up to clients to decide whether to contribute to the hosting of it.
I think I lost the ability to ssh in to your server at some point when you switched servers. So I can probably commit if only I could get in to do so :) That reminds me: Are y'all maintaining an offsite backup of hubski data someplace? I used to have a script copy it everyday but I obviously haven't done so for a while.
Yeah, that seems to be a bug forwardslash, mk. Anchors work in regular links, just not in youtube embeds, perhaps.
(Search for 'digital blasphemy neuron'.)
I currently have two students (a 45 year old and his 10 year old son). They came expressly to learn Arc lisp. So far my approach with the younger one has been to give him a skeleton of a program to play tic-tac-toe, and then we're gradually filling it in. Right now we're three sub-problems deep learning about recursion, and tic tac toe probably seems much harder than when we started :) My general approach has been to give him a day or two to solve a problem before working with him on the solution. The idea being that he'll remember more once he's struggled with it by himself. But several times now I realized that the problem I gave him was too hard and spent the next session working on something simpler. So I'm learning a lot.
This is great! Is it a common approach to go over a non-trivial program like this? I've been ranting for months that we should do more of this. Less blank page, more tweaking programs that actually do something, getting feedback along the way. In case you haven't seen it, this is great as well.
Rather to my surprise, I wrote a hundred lines of code between getting up and going to work this morning. I'm building an environment to help teach my students programming, which consists of panels where you can define functions on the left, and a repl-like thingy on the right where you can call functions, see their results, click on the results to expand a trace of computations, zoom in and out of the trace. Eventually I hope to be able to make an edit to a function and automatically rerun all the commands in the 'session', flagging any changes or errors. Automatic unit tests for a fraction of the effort. As of this morning, the left side is done. Screenshot: I'm going to start wiring up the right side next. (The repl and trace browser are already done as standalone commands.)
I'm here! Thanks for tagging me on this thread, though. It's right up my alley. I've been teaching a couple of people programming using arc, and hacking on hopefully a better way to teach programming. Hope to have it working soon for everyone to check out!
Weird, that comment is from a different thread. I think it's the testing that mk mentioned elsewhere on this thread. But glad it led to some serendipitous conversation :) I still lurk from time to time, but I've just been a lot less active online for the past year as my project's cannibalized more and more of my attention. "Flow" says people should go through alternating phases of openness and closed "shut up and execute". The latter has been my story for quite a while now. http://www.amazon.com/Flow-Psychology-Experience-Perennial-Classics/dp/0061339202
I'm around! What made you think of me? (I've been working on http://github.com/akkartik/mu)
I was explicitly trying not to be ruled by our preconceived notions of what it means to own. Given that ownership of software isn't quite how we used to do it, are there benefits to changing the rules around a little bit elsewhere as well? Basically, our planet is getting crowded enough that giving people so many rights bundled up in 'ownership' is starting to crack at the seams. In my opinion :)
Yeah, exactly. Bottom-up allows humans to see what is possible. But bottom-up also allows some humans to be top-down towards others :) I'm not too concerned about the limited degrees of freedom. We're human and we have our limitations, no point worrying about that. In programming terms, I just want us to avoid regressions. It's wasteful of human lives to spend time changing states to one that we already knew long ago had problems. Avoiding repeating history and all that. Oh, I was totally serious. I wasn't sure how much to assume regarding familiarity with genetic algorithms and so on. At least the people I know at hubski wouldn't need too much belaboring of those properties. (BTW, do we have some way to do nested quotes? Has that come up?)As opposed to the morons who read Ribbon Farm? Kidding, obviously :)
Thanks insomniasexx. I had two different people tell me in drafts to drop that paragraph, but I just couldn't kill that particular darling :) There was also a version that put all of it in parentheses. Perhaps I should have stayed with that.. This is likely a more erudite audience than I was envisioning when I wrote it, and so the genetic algorithms stuff probably seemed overly belabored. What do you make of my attempt to apply its lessons to human groups, especially the "utopian participatory panopticon" thought experiment at the end?
Oh yes. A sentence that ended up on the editing floor:Change happens; avoiding it amounts to sticking one's head in the sand.
Yeah I agree with everything you said. Everything we do is imperfect, yes, but if we could write down our intentions then future generations could know where we were imperfect and biased, rather than guess and never be sure. That at least has a possibility of adding new biases that might destructively interfere with the old ones :) I think the analogy with unit testing is correct in a very deep way here. Even if after TDD you may have missed tons of tests you should have written, things that you unconsciously intended but forgot to be explicit about. But the presence of a growing set of tests still makes life easier for those who come after, and the accumulation of tests holds hope of one day being comprehensive.
Could you point me at where this is called biocentrism? I was confused because neither sense of the term at http://en.wikipedia.org/wiki/Biocentrism seems to require uniqueness.When I say "biocentrism" I'm specifically referring to the idea that of all the planets in the universe, abiogenesis only occurred on Earth.