1. 1

    I use autojump for this. It works out of the box on both Bash and Zsh without any changes to your shell configuration!

    1. 7

      I like this, it’s a really nice way to express this concept. I love the illustrations on this too — they’re even SVG :) What did you use to draw them with?

      1. 4

        thanks! The person is from Pablo Stanley’s Humaaans and I drew the telescope in Figma

      1. 2

        I use these to disable large swaths of code while I’m refactoring them. As weird as it is, it’s a pretty helpful feature IMO. And your editor will probably automatically align =begin and =end to the beginning of the line when you type it.

        1. 13

          This is great! I really like this style of explaining how the pieces fit together from the ground up. Every time I’ve tried to start a project in Phoenix (or Rails, or Django, …) in the past, I’ve been pretty overwhelmed by the sheer number of different moving parts that are simply scaffolded in.

          1. 6

            Agreed, this was super well written and easy to follow. I love the idea that each section links to a commit. I might steal that for my blog :)

            1. 11

              Thanks! I’ve got a whole pipeline that transforms a git log into an article formatted to work with my static site generator. I’m a big fan of the format!

              1. 6

                I’d be interested in hearing more about that!

                1. 2

                  I’d love to get an eyeball on that pipeline, seems really cool!

              2. 1

                As someone else who recently generated a new scaffolded project with Phoenix (just to have a play around, I don’t know much elixir) and felt overwhelmed by all the moving parts, I wanted to chime in too and say I found this post very handy. Thanks :)

              1. 8

                Hadn’t heard of this before. The blog post linked from the home page on Pijul’s merging algorithm is super fascinating: https://jneem.github.io/merging/

                1. 5

                  I found it to be the only convincing argument for the use of category theory in programming I’ve seen. I’m not sure one could arrive at or explain the design of their data structures and algorithms without explaining that they’re what make pushouts work. It really feels like a Grothendieck-style compass-bearing use of category theory to discover the structures one should be looking at.

                1. 4

                  I feel like these kinds of posts pop up every so often, and up to now my standard response is, “well, duh, everyone knows that clever code is bad.” But just what does “clever” mean?

                  Ultimately, I think readability is in the eye of the reader. Code that some people think is readable, other people may not think is readable. For instance, I personally think that the “ if ” idiom that is popular in Perl and Ruby makes possible is not as readable as “if ”; it doesn’t mesh with the mental model I have when I read code. But other people may think it’s perfectly fine.

                  “Clever” here seems to be used to indicate code that is inherently not readable. “Simple” isn’t the same as “readable”, but implies it; the thinking is that if something is simple, it is understandable, and therefore it is readable. Is “understandable” subjective too? I think so; again, some things that are understandable for some people aren’t for others.

                  With regard to the subject of this article — the {...something && { foo: "bar" }} expression — if I had not seen this before and someone said that this could either evaluate to {} or { foo: "bar" } depending on something, I would not be that surprised. I know what the spread operator does and I know what && means, so is it that much a stretch to understand that the result of this expression is either {} or { foo: "bar" }? I don’t think so. Not to say I wouldn’t like it — I would probably say that it’s weird, it doesn’t fit, there’s just something off about this. But that’s not the same thing as “unreadable”.

                  So if we can’t pin down “readable” or “understandable” or “clever”, then what are we talking about? Perhaps readability requires a consensus: if most people think something is readable, then it is. So when we talk about “readable” do we really mean “unconventional”? “non-idiomatic”?

                  1. 1

                    Exactly. When writing, you should know your audience – and when writing code, it helps to know your team to be on the same page with them.

                  1. 2

                    It’s moments like these that entice me to switch from Vim to Emacs. Maybe one day….

                    1. 1

                      You can do exactly the same in Vim with timer_start() and a callback to set colorscheme and/or background. Arguably, an autocmd is better though (see my other comment).

                    1. 2

                      Sounds like Apple should re-release the Mac Pro as the “iPC” ;)

                      1. 2

                        I really wish that JavaScript would just provide one way of doing this stuff. I can’t think of the last time I had to use an iterator, but if I do, I don’t feel like I should have to make a decision. What is the JavaScript community converging on as the true answer here?

                        1. 1

                          By using an iterator do you mean creating a custom one or simply using an iterator object from an existing lib?

                          I get your point about JS and the many ways to do one thing, but I actually find ECMAScript 2015 to have done something very powerful here with creating a standard and interoperable way to define synchronous iterable objects.

                        1. 3

                          Beside the caveat mentioned here, another thing to keep in mind is that Arel is a purposefully undocumented part of ActiveRecord. It’s there to make it easier for ActiveRecord to build queries; it’s not really intended for anyone else to use, and there is no guarantee that the API will remain the same in a future version of Rails. So if you don’t ever plan on upgrading your Rails app, then go for it, but otherwise — as lovely and expressive as it is — I would probably try to shy away from it as much as possible and just stick with ye olde find_by_sql (or select_values, or some variant). Sorry to ruin the fun. :/

                          1. 1

                            Go ahead and use Arel. It’s been very stable over the years, far more stable than ActiveRecord’s private APIs. I find the alternative of writing hard-coded SQL strings far more distasteful.

                          1. 6

                            I have mixed feelings about this article. On one hand, I agree with the philosophy that knowing your tools and understanding when to reach for certain ones is absolutely something that every developer should do. I also agree that making a web Thing involves a lot more code than it used to. The frontend/backend dichotomy didn’t really even exist until 10 years ago; modern JavaScript (i.e. “ES6”), Webpack, PostCSS, TypeScript/Flow, React, etc. definitely increase the learning curve and effort it takes to make a web Thing; and you could make the case that all of these new tools that we have don’t necessarily translate into faster development or better performance.

                            On the other hand, this post very much feels like “I like the old way of doing things and I do not care to learn the new ways”. C people didn’t like C++ because it introduced classes, Java people didn’t like PHP and Perl because it eschewed explicit types, and now we have people complaining that React and Sass and so forth are unnecessary when the way that they wrote web code 10 or 15 years ago works just fine. Fortunately, you don’t have to buy into all of it if you don’t want to:

                            • You don’t have to use ES6, but I would argue that TC39 has been doing some tremendous work in making JavaScript as a language better and more fun to work with. You don’t have to write 1000-line jQuery files, you can actually organize code into files :)
                            • You don’t have to funnel ES6 through Babel, as Chrome and Firefox have been really good about introducing new features in a timely manner, but then again, you will have to keep up with what browsers do and don’t support manually.
                            • You don’t have to use Webpack/Rollup/Parcel — if you want to funnel assets through some kind of processing step, you can write a Makefile if you so choose — but this seems like a lot of work.
                            • You don’t have to use npm to manage JavaScript dependencies, you can download them manually and stick them in your project if you really want to, but package management is a proper thing in JavaScript now and it seems a little stubborn to not take advantage of it.
                            • You don’t have to use Sass, Less, or PostCSS; there are some new things happening in CSS-land (like variables) that are supported in Chrome and Firefox, but there are also interesting things happening that the W3C has not introduced, like CSS Modules.
                            • You don’t have to use React, but I don’t think you should dismiss it completely, either. The idea that view code can be declarative and functional is pretty powerful. Of course it necessitates doing things differently, but so does everything else.
                            1. 1

                              Java people didn’t like PHP and Perl because it eschewed explicit types

                              This is a good example of a newer thing that’s not necessarily better. While dynamic typing certainly has productivity benefits in the short term, it also has more bugs. I’m not so sure if it’s an improvement when writing larger programs.


                              I agree that not all improvements are bad ones, but on the other hand you have “static site generators” such as Gatsby that use React to load your site. No JavaScript? No HTML for you! (also see my comment on reddit).

                              I’m not hating on React specifically here, but loading a basic HTML weblog post via an XHR request to a JSON document is just incredibly stupid. I have a lot of patience and understanding for viewpoints I don’t agree with, but I have no idea how anyone could possibly think this is even vaguely a good idea. I simply can’t.

                              I think that some of the pushback is against this sort of very silly stuff.

                            1. 2

                              I tend to think this is a bad thing overall, assuming they’re doing it. We’ll now have one less completely independent browser engine in the world. One step closer to being back in the bad old days where there’s one dominant browser engine, and whatever it decides to do is the de-facto standard.

                              If we do go that way, it’s also not a very good sign for any future diversity in browser engines if even a tech giant like Microsoft can’t justify the expense of building and maintaining an independent one.

                              1. 1

                                This was my immediate reaction, you hit it spot on. At least we still have Firefox.

                              1. 3

                                This is pretty insane. I’m surprised that no one is falling all over this. I loved his description of GANs. I had no clue these were a thing before this article, but the whole generator/critic model seems like it would be incredibly useful for MANY things involving artistic endeavors, not just restoring photos. For instance, I can imagine it being used as a vastly improved way to generate music. Part of the issue with algorithms that generate music is that they just don’t sound great, and I think it’s because art is very open-ended. However, there are rules and guidelines that musicians follow depending on the genre, and human players discover these rules by listening to existing music. Existing algorithms to generate music have, of course, relied on literal prior art, but the critic is usually the human. If the critic were the computer instead, then that could open a lot of doors.

                                1. 3

                                  Hello, creator here. Great minds think alike :) This thought about music has been on my mind too. I think it’ll be a much more ambitious leap from what’s been done currently but it seems like in principle it should work as you describe it more or less.

                                  If you’re interested in GAN art, there’s somebody I really like to follow on Twitter- Helena Sarin. https://twitter.com/glagolista

                                  And I’m posting my work likewise in a steady drip here: https://twitter.com/citnaj

                                  There’s not too many of us yet as far as I know but I do think it’s going to be a very interesting next decade in terms of doors opening wide open in the arts and creative space with this stuff!

                                  1. 1

                                    The WaveNet examples have some fascinating piano clips that were generated one sample at a time. Definitely worth a listen! For actually creating music I found the recent audio style transfer technique pretty impressive. At times it sounds just like a bad vocoder, but the results from a whistled Indiana Jones theme from 1:47 onwards is really fun.

                                  1. 4

                                    As will have been evident, a guiding design principle for Inform was to imitate the conventions of natural language.

                                    I think I would be a lot more sympathetic to this if “natural language” here didn’t in fact just mean “English”.

                                    Basing a programming language off a natural language that is logical and consistent might actually be a good idea, but I don’t know of any actual attempts to try it. Basing a programming language on English is a terrible idea, because English is so terribly inconsistent, and you’re left guessing as to how the implementation is going to interpret a phrase where a human mind would have no trouble cutting thru the ambiguity. (Granted some of the ambiguity is inherent in natural language, but a good chunk of it is just legacy nonsense from our defective orthography. Tackling just the inherent ambiguities is hard enough without being stuck attacking both at the same time.)

                                    The merits are: familiarity; […] conciseness, in that a lot of boring code becomes unnecessary; and perhaps a greater ease of expressiveness, because the lineaments of the language more closely follow our cognitive habits than would be true of, say, C++.

                                    Using C++ as your measure of a non-natural programming language is quite the straw man; neither of these concerns have anything to do with the natural vs non-natural divide, just with good programming languages and bad programming languages. This passage seems to imply an unfamiliarity with non-natural programming languages which allow concise and expressive code.

                                    Finally, it’s disappointing that this talk didn’t address the biggest problem in the Inform6->Inform7 shift: it changed from being free software to being another proprietary project.

                                    1. 5

                                      Basing a programming language on English is a terrible idea, because English is so terribly inconsistent, and you’re left guessing as to how the implementation is going to interpret a phrase where a human mind would have no trouble cutting thru the ambiguity.

                                      In my experience, the natural language design in Inform does pose problems, but not exactly for ambiguity in interpretation. It’s more that in English, there are multiple ways to say the same thing, even if they differ by a few words. Of course, in a programming language there may also be multiple ways to “say” the same thing, but there are far fewer possibilities. Inform pretends to be a natural language, but it’s really a programming language, and you still have to be very particular about how you say things. It does work most of the time, because Graham Nelson did a great job of phrasing things in a way that makes sense, but it’s very easy to write a sentence and then spend the next 30 minutes wondering why it fails to compile, only to realize that you left off one word. (Or, my favorite: if you want to tell Inform to do something each time the turn counter increments, you say it by writing “Every turn, do XYZ”. If you type “Each turn, …” instead, it won’t have any idea what you’re talking about.) While the same problems, of course, abound in traditional programming languages – syntax is always the first thing to trip up people brand new to a language – the Inform IDE doesn’t do a good enough job, in my opinion, of highlighting potential errors in real time. I’m a bit disappointed that Graham didn’t mention any of this.

                                      1. 4

                                        From the talk:

                                        One reason Inform hasn’t been open source in some years is that this infrastructure was such a mess. But not being open source is an existential threat right there.

                                      1. 2

                                        Very nice! I love the animations — they provide a smoothness without being too much. I have two nitpicks:

                                        1. When you’re selecting a time, it’s not immediately obvious which component of the time is active. Maybe reverse it so that instead of highlighting it in blue, it has a blue background with white text so it pops out a bit more?

                                        2. The “now” or “today” icon isn’t immediately obvious — I was initially confused but figured I’d try it out to see what it did. Perhaps in that case it might be better to use a word rather than an icon? Just a thought.

                                        1. 2

                                          Thanks for your time. I agree to everything you said. Consider it done in next release :D

                                        1. 1

                                          More inclusive and open

                                          Male and female emoji have been merged into gender-neutral emoji that are relevant to you

                                          I fail to see why this is “more inclusive” or “open”. I mean, I’m all for people who are gender-neutral, I have no problems with this, but considering that the vast majority of the population isn’t gender-neutral, it’s actually less inclusive, by definition. Either provide more possibilities or go ahead and just say that there are fewer options. But don’t bend over backward to appease a small amount of people by normalizing everyone. :(

                                          1. 6

                                            The way I see it is that Unicode emoji tried to be gender-inclusive by adding a “female” modifier (emoji + zero-width joiner + ♀️).

                                            This reinforces a false binary, and the way it’s implemented in mainstream emoji design reinforces gender stereotypes. Women have long hair, makeup, and pink clothes; men have short hair and blue clothes; that sort of thing.

                                            Gender isn’t something that can be seen, and so I don’t think adding more and more gender options makes sense. In my opinion, it would be much better to offer stylistic choice, such as “long hair” or “makeup”, as options unrelated to gender, since that’s what they are.

                                            I don’t agree that having fewer gender options makes it less inclusive. It isn’t saying that every emoji represents a non-binary or agender person or anything. It simply does not specify a gender, and so they aren’t excluding anyone on basis of gender.

                                            Edit: it’s like how the basic facial expression emoji were never gendered to begin with, and so there is no need to add more gender options to them.

                                            1. 0

                                              Gender isn’t something that can be seen

                                              Most of the time it can but not on something as tiny and reductive as an emoji without having to use things like clothes color.

                                              1. 0

                                                Sure, you can guess, and odds are you’d be right a lot of the time, but it still isn’t defined by any kind of outward appearance.

                                            2. 2

                                              Additionally, I find it odd that they’ve chosen to reduce the set of available choices when it comes to gender, but they’ve greatly expanded the choices when it comes to race. I think they should decide whether they want to provide options for things like race, gender, sexuality or not provide options.

                                              1. 1

                                                I poked around and found a relevant pair of questions in the FAQ on the race and gender questions. They don’t specifically compare the two decisions, but the rationale for each is there.

                                            1. 3

                                              A nice companion to this, which I just found recently, is Blue1Brown3’s explanation of Euler’s formula and what it means to take something to the power of i: https://www.youtube.com/watch?v=mvmuCPvRoWQ

                                              1. 3

                                                It’s amazing to see how much better he’s gotten at giving talks since then.

                                                1. 2

                                                  It sounds like a small audience, but even so I think he does a good job here: his pacing is good, and he mostly avoids the umm/err problem so many of us have when giving a presentation. I imagine this isn’t too long after he realised he had a talent for this :-)

                                                1. 1

                                                  Although I’m sure many people have had these same thoughts and have even gone down this route, I generally like this idea and would love to see it developed further for educational purposes. I’m a big fan of Inform and I think it’s pretty amazing what you can do with it given that 99% of the time you are writing in plain English (that actually makes sense to read). The flip side of this is that Inform can be just as frustrating to use as conventional programming languages, because at the end of the day, it’s still a language, and that language has certain rules you must follow and certain ways you have to say what you want to say to achieve some sort of result. With any system, it is natural to build a mental model of how that system works, and so when there is a dissonance between what you have in your head and what the language actually is, then there is opportunity for frustration. I am not sure if you can avoid this, because that is going to happen no matter how nice you make the language, but you can build tools around the language to help people as much as possible. Indeed, Inform does have very comprehensive documentation (complete with working examples!) and helpful, readable errors, but sometimes I do wish it were more forgiving in terms of the syntax, or at least better about offering suggestions for how I might should phrase something. On the whole, though, I think this is a pretty fascinating exercise at least.

                                                  1. 2

                                                    This is pretty neat. It goes to show that to make an effective AI, you don’t have to have it know everything or do everything; if you take a step back and narrow the focus and come up with some simple rules (in this case relying on the fact that medical experts can understand jargon) then you can still make something that’s quite powerful. Although not AI in the true sense of the word, the boids algorithm is another example of this. If you wanted to simulate a flock of birds as they move through the air, you could probably come up with a way to do it that takes into account speed, line of sight, how many others are in proximity, etc. And yet boids is only three rules and does a pretty damn good job.