1. 1

    The “Operating Systems” list should just be called “Unix”. Death to this monoculture, I say!

    1. 2

      The listed books (those I’ve read, anyway; 3 out of 5) are well-written and some count as classics. Most of the underlying concepts aren’t UNIX-specific anyway. Do you have alternatives which are a) non-UNIX, b) well-written and c) practical?

      1. 4

        For what they’re like, I have a list of key, non-UNIX OS’s for people to check out with comments on them. The book on capability systems also describes some with interesting architectures.

        Being a Chicken developer, you might have liked Genera and the Lisp machines. Mezzano is a recent OS I remember. Idk if it has anything like Genera’s capabilities. lispm on Hacker News had this page where the company described its advantages at the time. Some still stand.

        1. 2

          I was specifically referring to book recommendations, but thanks for the list!

        2. 2

          No I don’t, that’s what I mean about Monoculture. But I would say yes, most of those idea are very UNIX-specific, we’re all just the fish that somebody asks “how’s the water?”

          1. 1

            Certainly true, and it would be nice if there were more (books about) alternative OSes. However, most of the UNIX books go into depth about file system architecture, process scheduling, networking and so on, which any serious OS needs to implement anyway.

        3. 1

          Well, so it happened that I only read books about Unix. Still, it seems to me that the core principles are more or less the same across different OSes.

        1. 1

          They included The Passionate Programmer but NOT The Pragmatic Programmer

          raised eyebrow.

          1. 1

            At the time of my talk “The Pragmatic Programmer” wasn’t as relevant as before, as many of the key insights there had become common practices today. Still, there’s no argument that it’s a very important book in the history of programming. Haven’t seen the updated edition, though.

            1. 2

              That’s a perfectly reasonable take.

              However I like to say that common practice isn’t always as common as you’d think :)

              It’s very easy for people to do Just Enough to fly under the radar when in fact their actual day to day craft embodies practices that would make most Crustaceans cringe.

              I speak from experience on this matter, since I resembled that remark for many years, and still do in some areas :)

              1. 3

                I speak from experience on this matter, since I resembled that remark for many years, and still do in some areas :)

                I appreciate the self deprecation.

                More seriously, it’s hard to do everything right and sometimes on teams it’s hard to even do the things you like doing.

                1. 2

                  More seriously, it’s hard to do everything right and sometimes on teams it’s hard to even do the things you like doing.

                  Totally. The trick is figuring out which things are “more right” in a way that represents actual functional difficulties as opposed to just somebody’s version of what’s elegant or idiomatic.

                  For instance, I’d argue that using some form of version control isn’t just best practice, it’s a strong way to keep you from shooting yourself in the foot :)

              2. 2

                “The Pragmatic Programmer” was updated in January 2020. I haven’t read the 20th anniversary edition yet though.

            1. 3

              RuboCop started out being a pretty fair representation of a “style guide” for Ruby, and I can’t thank you enough for your work. It’s saved me a lot of time and trouble, and helped newer developers get started writing great looking Ruby! But over the years I feel like a lot of superfluous rules began getting added to this supposed community style guide that I don’t remember anyone really having a discussion over. It seems like for any syntactical decision that can be made, there’s a RuboCop rule telling you which choice to make, even though it doesn’t have any context over why you made that choice.

              Here’s a great example. I don’t think and / or continuance should be used in this context:

              if something? and something_else?
                # do stuff
              end
              

              But I use it all the time in this one:

              redirect_to some_path and return if something?
              

              But RuboCop will make me rewrite that latter one into:

              if something?
                redirect_to some_path
                return nil
              end
              

              IMO this looks a lot worse.

              It’s stuff like that…RuboCop IMO needs a huge cleanout, most of the cops need to be disabled by default, with the ability to add ones in places that you feel are appropriate. Additionally, I think RuboCop’s existing cops should be modified to understand the context in which they are running, and possibly have that context altered by RuboCop plugins (for example, rubocop-rails might be able to tell RuboCop that you’re running in a Rails app, so some of the cops make sense in some places)

              1. 3

                Aesthetically, I agree, but fwiw I think the RC recommendation here is absolutely superior for a codebase being worked in any kind of team setting.

                The problem with the first is that it forces the reader to understand the fine points around the difference between and and && – and the writer to get those correct. Safer to avoid it entirely. I see it as a case of safety and simplicity trumping aesthetics.

                1. 3

                  I feel like the standardrb gem is a response to this. Have you tried it instead? I use it for the sidekiq codebase.

                  https://github.com/testdouble/standard

                  1. 2

                    For a long time I had it on my todo to check what exactly is changed in the default configuration there. I appreciate the goal of the project, but experience has thought me that finding complete consensus on style in our community is never going to happen. Or at least quite unlikely to ever happen. :-)

                    1. 1

                      Well, standard is there for people who do want to use an opinionated tool. Rails vs Sinatra, right?

                      1. 2

                        Fair point, although I guess you can say RuboCop is opinionated as well - it has some defaults for everything. :-)

                    2.  

                      I haven’t, but I’ve heard good things. Will check it out.

                    3. 2

                      Funny enough the example you gave was recently fixed (see https://github.com/rubocop-hq/rubocop/issues/7795). :-)

                      But I understand your point. Perhaps we went overboard here and there and RuboCop became too heavy-handed in certain cases. When those things happen gradually over the course of many years from time to time it’s hard to notice them. Doing sweeping changes is always alluring, but for everyone who wants those there’s also someone objecting, so we have to approach changes carefully. Hopefully at some point we’ll get to implementing some context-specific functionality.

                    1. 5

                      These retrospectives on evolving and ageing languages make good case studies. My personal takeaway: if you could write a piece of syntax as easily as any other library, all of these syntax tweaks and additions would become complete non-issues. It would eliminate reams and reams of bikeshedding in the issue tracker if you could just do import syntax/flipflop.

                      1. 3

                        Every Ruby project potentially having slightly different syntax sounds like a nightmare to me.

                        1. 4

                          Not trying to be glib, but… DSLs?

                          1. 2

                            DSL’s built on Ruby all follow the same syntax though.

                            I suppose there might be a few out there where Ruby is outright parsing some other text, but those are mercifully rare.

                            1. 2

                              But a DSL has a different syntax to vanilla Ruby, because otherwise it would be a regular library, not a DSL.

                              Is syntax sugar like a new sigil or infix operator (which is what most of these are) really that different to a DSL? Fundamentally, I mean, not just in that one of them uses tokens and the other uses characters. You have to learn something new the first time you encounter a new DSL exactly the same as you would for a new character syntax. Having been knee-deep in this kind of stuff for a few months now, I’m seeing less and less of a distinction.

                              1. 6

                                There aren’t any real Ruby DSLs. Ruby programmers just oddly refer to class methods called at the top level without parentheses as “DSLs” (or, more rarely, instance methods called without parentheses in what other languages would call a “builder pattern”).

                                Ruby doesn’t support macros or other syntax-level features that would enable an actual DSL.

                                1. 2

                                  I know, they’re technically only eDSLs, but my point remains. All syntax changes are the same. They could have added real DSLs (edit: you know, “just add this massive feature” :) and never had to decide between @1 and _1.

                                  1. 1

                                    They’re DSLs in the sense that any library API is a DSL, and in this respect I think Ruby does DSLs a lot better than other languages with “real” DSLs. APIs can be (almost) as expressive as real DSLs and they’re still using normal language syntax and semantics. Lisp is definitely more expressive and it’s still technically using the same syntax, but the semantics can vary wildly.

                            2. 2

                              Until you realise that less powerful languages have the same problem - except their abstractions aren’t expressed in a clear DSL courtesy Ruby or Lisp metaprogramming, they’re splattered throughout the application in AbstractFactoryFactories and FooUtility classes.

                            3. 2

                              In Lisp we trust! ;-)

                            1. 10

                              He adds a feature to master, gets feedback on it and reverts as necessary. I can see advantages to this approach: everyone focuses on the specific implementation and its trade offs, as opposed to an RFC with no code behind it.

                              1. 3

                                My main concern is the lack of vision, not the exact development approach. As Matz admitted himself - some things were added with no real consideration how they fit into the broader picture, and that worries me the most.

                              1. 22

                                There’s some irony here in this complaint coming from bbatsov, the author of Rubocop, where the constant, never-ending creep of additional on-by-default cops enforcing ever-more-specific and squirely tastes has forced basically every project I know of to throw up their hands and just refuse to upgrade the damned thing at a certain point out of frustration with Every. Single. Upgrade. introducing some new ever-more-rigid requirements on everyone that you then have to go and add to the endlessly growing blacklist of cops.

                                And this happens, of course, because there’s no definition of “Done” and the broader community is made up of many people with many tastes and use cases proposing many changes, which through some alchemical combination of consensus and maintainers’ tastes, make it into the project. It’s really the exact same phenomenon.

                                There’s no silver bullet, I guess, but this is all a bit “physician, heal thyself”

                                1. 12

                                  I’m also confused by this. Additionally, Bozhidar should know that the “three people complaining” are not three random people, but for example Eric Wong (author of Unicorn) and nobu, who is part of the MRI team after all.

                                  So, what does this post sum up to? 4 things that didn’t happen and a feature he doesn’t like and the personal request for Matz to chill out.

                                  1. 8

                                    Trying to satisfy Rubocop is the ultimate in automated code golf. The default ABC and method line count metrics was absolutely insane last time I used it.

                                    1. 4

                                      FYI - https://github.com/rubocop-hq/rubocop/pull/7184 :-)

                                      I’m well aware of the issue you mention (and it will be resolved before 1.0 is released), but you’re really comparing apples to oranges here.

                                    1. 1

                                      FFS, this is what drives me nuts about Rubocop. None of those options looks wrong or hard to understand to me. Python’s directive that there should be one and only one way of doing things should not be applied to Ruby. This sucks the joy out of the language for me.

                                      “Well you never have to decide or think about it, isn’t that better?” no? It’s not standing in the way of writing code or understanding. I have never once given code review feedback “Hey, use fdiv” or “Hey, call to_f on both sides” - I really think that there are so many rules in Rubocop now that they’re grasping for “well what else could we lock down”. Benefits be damned. And the end result? You’re writing in a different language than Ruby: Rubocop Ruby.

                                      Linting is good. Code formatting is good. Draconian arbitrary rules are not, and that’s where Rubocop lives in my experience.

                                      1. 3

                                        Fair point. There’s obviously the option of not enabling this by default at all. :-)

                                        Some people are trying to standardize on everything and I understand them as well. That’s why I want us to hear everyone’s perspective, but generally most people ignore the upstream development until something gets released.

                                        Draconian arbitrary rules are not, and that’s where Rubocop lives in my experience.

                                        I disagree with that assessment, though. If we wanted to be draconian we wouldn’t have spend so much time on making everything configurable. We give people the option to do/check something, what they end up doing is up to them. There’s even a config option to just suppress all the defaults, disable everything and just turn on whatever you like selectively.

                                        1. 1

                                          My expectation from past experience is that any new cop comes enabled by default. I -am- glad its configurable, but it’s not something I want to keep up with. I do appreciate your work on rubocop btw - I look forward to having something standard like this for Ruby (Ruby prettier, standardrb, rufo, something!), but I have felt rubocop is a bit too philosophically aggressive about stuff. You’re moving the needle, though, and that I do appreciate.

                                        2. 1

                                          I agree with you, some flexibility is good but not too much. I was offput at first by Go style requirements with braces. Even now, it’s not quite my style. But it is nice not having to worry about that, the style has been decided for me. Maybe Go has a compiler option to increase the flexibility, I don’t know.

                                          But I do know that its one less thing that I have to decide and maintain. If I do it wrong, it’s a compiler error so I know right away.

                                        1. 2

                                          This is really not that weird. Ruby is duck typed and object oriented. What is weirder is that there are methods that return true or false at all, since that should almost never be used.

                                          1. 1

                                            I think you missed my point - an API that should have been symmetric isn’t. Simple as that. While I disagree that it’s a good idea to return anything but true and false from a predicate method (regardless of duck typing), I didn’t really touch on this in that particular post.

                                          1. 4

                                            While it’s great to highlight people, I’d also like to note that the Ruby Heroes awards are not unequivocally liked. I’m highly critical of them.

                                            This sentence gives it away:

                                            I’m reasonably certain they need no introduction

                                            Usually, such awards are a popularity contest. In some instances even, people get a hero award by mainly implementing the same thing as someone else, but with more marketing force. This is fair and everyone has the right to do so, but Awards must make an effort to try look past that a little. That often doesn’t work out.

                                            Often, awards are also heavily biased to the locale that they are created in and leave a lot of people unknown that do remarkable local work, but just somewhere else.

                                            1. 1

                                              I completely agree. Generally good marketing skills trump good quality. A sad fact of life…

                                            1. 4

                                              The syntax looks like it’s inherited from Perl’s POD format.

                                              1. 6

                                                Sort of. They call it RD aka Ruby Document, and the syntax is inspired by but not a superset or subset of POD. It’s been out of fashion (in favor of RDoc) since the early 2000s.

                                                1. 1

                                                  Good to know! Seems I’ve completely missed the RD era. :-) I’ve updated the article to mention it.

                                              1. 1

                                                The new site looks good. But when I try https://www.cider.mx, I get a certificate warning.

                                                1. 1

                                                  Thanks for spotting this. Seems it’s related to how GitHub deals with certificates - https://github.community/t5/GitHub-Pages/Does-GitHub-Pages-Support-HTTPS-for-www-and-subdomains/td-p/7116 I’ll see what I can do about it, but from what I read the only real solution would be to host the landing page somewhere else. If someone has any tips I’d appreciated those!

                                                1. 1

                                                  Would one recommend using Antora with a single repo AsciiDoc documentation? Are there any live servers for AsciiDoc, so authors can quickly see results of their work locally?

                                                  1. 1

                                                    Yeah, Antora is great for single repo AsciiDoc documentation. You don’t really need any live servers as it generates a static website that you can easily preview locally.

                                                  1. 2

                                                    You might want to consider replacing the chum bucket ads with something actually interesting to your userbase. Promo-coded vultr links or something.

                                                    1. 1

                                                      I’m not even sure where those ads are coming from. I assume it’s something from disqus. I certainly didn’t intend to have any ads on my blog.

                                                    1. 4

                                                      Just want to take the opportunity to say how much value I’ve gotten out of Rubocop over the years. Especially in a team setting it simplifies so many discussions and gets a project to a baseline of reasonable formatting and practices. I usually even leave some rules that I don’t like unchanged just to avoid bikeshedding. I always set Metrics/LineLength to 100 though :)

                                                      And I will always cherish reject, collect and inject as reminders of Ruby’s colorful pre-history. If you do Ruby and wonder where they come from and have five minutes to kill, read all about it here: https://nofluffjuststuff.com/blog/rick__denatale/2011/01/how_arlo_got_injected_into_ruby

                                                      1. 1

                                                        Thanks for the kind words!

                                                      1. 7

                                                        Neat, but is it really worth the trouble of being a Surprising Syntax Detail instead of just a method?

                                                        1. 1

                                                          It’s hard to draw a clear line. :-)

                                                        1. 7

                                                          The real issue here is that github’s issue tracker is really primitive. On a more sophisticated tracker (I prefer redmine but there are dozens of decent ones) sorting, filtering, categorising and generally ‘tracking’ of issues is much more fine grained and controllable. It is still a good idea to close unhelpful issues, but it is no longer overwhelming when there are thousands of them.

                                                          A bug tracker should be designed to handle volume. The github tracker is an afterthought on a source repository hosting site. My advice for major projects would be to host a dedicated public bug tracker. Have a bot that takes all github issues, reposts them to the actual tracker, adds a link in the original, and then closes them straight away.

                                                          1. 1

                                                            No argument from me. GitHub Issues definitely doesn’t make managing projects fun. :-)

                                                          1. 8

                                                            I am not a fan of auto closing tickets. A bug is still a bug even when it is not getting fixed for a while.

                                                            If one responds just to avoid autoclosing it this does cause noise and thereby takes time from people actively working on fixing it.

                                                            Usually bug reports are a way to start contributing to a project. Closing bug reports just cause time passes seems like a waste of contributions.

                                                            Isn’t it just reducing a number when in reality you want a “sort by last activity” or something like that? Having actually resolved issues mixed with things that for whatever reason had no visible activity for a while seems like making things worse rather than better on the organizational side.

                                                            1. 3

                                                              If one responds just to avoid autoclosing it this does cause noise and thereby takes time from people actively working on fixing it.

                                                              My experience shows that minor bugs generally stay open forever, as no one is really interested in tackling those. Yeah, there are exceptions from time to time, but the overall picture is more or less the same. Btw, those tickets get auto-closed ultimately because no one expressed interest in fixing them. If there was any activity associated with them they’d forever stay open, even if you’re using some bot.

                                                              Isn’t it just reducing a number when in reality you want a “sort by last activity” or something like that? Having actually resolved issues mixed with things that for whatever reason had no visible activity for a while seems like making things worse rather than better on the organizational side.

                                                              Well, everyone has their own perspective here. I’ve tried keep issues open forever for 10 years and now it’s time to try something new. Frankly, I’ve seen very little activity on older tickets across all of my projects, that’s why I’m not really expecting something would change in a material way. I usually sort things by activity, when it comes to answering questions and reviewing PRs, but this doesn’t help when I have to pick tasks for myself (and I guess other core contributors experience this as well).

                                                            1. 29

                                                              Alternative perspective: https://www.jwz.org/doc/cadt.html

                                                              Not all issues are equal:

                                                              1. Support: “how do I use feature X?”
                                                              2. Bugs: “it should do X, but it does Y”
                                                              3. Feature requests: “it would be nice if it could do X”

                                                              It’s not always obvious what an issue is from the outset. Especially between support and bugs there is quite some overlap.

                                                              In my experience many issue that are left lingering are unclear, non-issues, confusions, etc.

                                                              Here’s what I did at my last job where the support staff had a tendency to just ramble 3 paragraphs of “description” in the issue title (who needs body text right?) often without a clear example of what went wrong. It worked well enough and made everyone happier; me because I didn’t have to decipher vague issues, support staff because they got better answers faster.

                                                              I haven’t tried it at an open source project yet, but I expect it will work well there too.

                                                              • Try to triage quickly to determine what kind of issue it is.

                                                              • No feedback and unclear? Just close after a few days. It can always be reopened later (but say so in a message! Otherwise people might think closing the issue means “go away”).

                                                              • Support request without easy answer? Direct to more appropriate channel. But please, don’t do it like the maintainers of a certain project which just closes issues with an abrasive “this is not a support forum”. Use a canned message to tell people why this is not an appropriate place to get help and where they actually can get help.

                                                              • Support request with easy answer? Answer concisely, tell people where to get more help if they need it, and close.

                                                              • Add a “confirmed” label to confirmed bugs that really are bugs. IMHO those should remain open until it’s actually fixed. If you’ve got a massive backlog of bugs then chances are that something, somewhere, has gone wrong. Consider it similar to the BUGS section in Unix manpages:

                                                                Our habit of trying to document bugs and limitations visibly was enormously useful to the system. As we put out each edition, the presence of these sections shamed us into fixing innumerable things rather than exhibiting them in public. I remember clearly adding or editing many of these sections, then saying to myself “I can’t write this,” and fixing the code instead.

                                                              • Feature requests: ~10% are either addressing some fundamental shortcoming or well thought out and are useful. The remaining ~90% are trivial and can be closed with “sounds great, I look forward to a PR!” There are always these people with “ideas” but no actual contributions that post these things.

                                                              • Issues without the “confirmed” label can be vacuumed (auto closed) after a few weeks. It’s often not a bug, or if it is, it’s not yet clear. If it’s really important the author can reply and it can be re-opened (say so in the vacuum cleaner message).

                                                              • Closing issues is never fun; we all want to help people, right? But it’s required and canned messages are great because it saves you the effort and time of explaining why you’re closing an issue.

                                                              1. 2

                                                                This seems like a sensible approach, if you can spare the time/energy/whatever to do the work. I believe one of the main issues the article is trying to address is when you don’t have the capacity to do project management work, and it’s more of an emergency measure to deal with a lack of project management resources.

                                                                I’ve experienced this myself, where even just doing the work to review and merge a well-put-together pull request feels a lot more like “I should get paid for this”-work than doing what I feel like on my own time.

                                                                1. 2

                                                                  I don’t think it’s that much effort. Essentially, my previous post was just a really verbose way of saying “keep confirmed bugs open, (auto)close most other other things”.

                                                                  This should get rid of the issue tracker noise while preventing the closure of real issues that should be fixed.

                                                                  1. 1

                                                                    I mostly agree with your perspective, but bugs come in different shapes and sizes, and treating them equally is rarely possible (mostly due to resource constraints). I think that major bugs should not be auto-closed, but minor bugs are fair game.