aji

My team recently started boxing both integer and string IDs in a service of ours and, though the transition was a little painful, it has paid off immensely in both readability and safety. These kinds of tips aren't just pedantic programming language theory, they're improvements that will actually make your code nicer!

Decent article but it's missing a lot of the things I expected to see, given the introduction. This seems really focused on the things I'd consider most analogous to "physiological" and "safety" needs. Writing code is a very basic part of software development, like chopping vegetables is a basic part of cooking.

To me, Maslow's hierarchy of needs is interesting because it tops out at "self-actualization". Maslow is effectively saying that the most important need a human can fulfill in their own life is the need to have a purpose and to live out that purpose.

The top of the analogous hierarchy of software development needs in this post, on the other hands, fizzles out at "patterns". What about understanding how different patterns are used to make a working piece of software? What about fitting separate software systems together to make a functioning product? What about shaping a product to fill some kind of need in the world?

My hierarchy would look something like this (with less bad ASCII art):

           /-----------\
          / Meeting requirements
         /---------------\
        / Designing software architectures
       /-------------------\
      / Manipulating software systems (e.g. implementing an HTTP service, setting up a database, etc.)
     /-----------------------\
    / Writing code (e.g. accessing APIs, implementing a function, etc.)
   /---------------------------\

with "meeting requirements" at the top since that is the most important thing to be done as a software developer, and it can't be done without addressing the needs below it. It's not as lofty of a name as "self-actualization", though.

Exactly. Arizona State University recently covered a bunch of walkways and parking lots with solar panels to both shade the lots while soaking up that delicious Arizona sun, which seems both effective and obvious. Putting it on the ground is not the best idea, and not even the most obvious idea. It's just mind-boggling.

I do something similar, but instead of 8 groups of 2 I have 4 groups of 4: 00xx 01xx 10xx and 11xx.

I also have some freebie groups that I just know, like 0001 0011 0111 1111, the powers of two, 5 and 6 from working with chmod, etc.

A B D E still give me trouble, but that's what a tool like this hex quiz is good for!

'dup' is a bad example from C, in my opinion. ('dup' and 'dupe' are both short forms of 'duplicate' anyway.)

What about 'strncpy' versus 'strlcpy'? Or 'vsnprintf'? 'fcntl.h'? 'execlp'? 'EBADF'? 'SIGSEGV'? 'lstat'?

The NES EverDrive is probably a good bet: http://shop.krikzz.com/EverDrive-N8-NES-EDN8NES.htm

The key distinction to note is the one between specifications and implementations.

As a small example, consider Brainfuck. The Brainfuck specification (if such a thing exists) has no upper bound on the number of memory cells, but practical implementations generally do have a limit that "useful" Brainfuck programs will rarely hit. The specification describes a TC language, while the implementation does not.

Therefore, if a language is TC according to its specification, but has an implementation in a language that is shown to not be TC, then it follows that the implementation must be of a non-TC subset of the language. This is, of course, assuming both that the specification has been proven TC, and that the implementing language has been proven non-TC.

I believe the point being made in the paper is that the C specification itself is restrictive enough that it describes a non-TC language. In other words, any implementation of C that is truly Turing complete would be violating the specification in some way. In that case, it follows that a C implementation of a TC language (such as the bignum language) must only be an implementation of a non-TC subset of the language.

(As an aside, consider that nothing running on an isolated machine will ever be truly TC, since an isolated machine has a finite amount of memory and so can't be TC. It's not that much of an inferential jump to see that this kind of TC-breaking limitation could end up in the specification of C, a language quite close to the metal.)

I'd say the interpreter is interpreting a non-Turing complete subset of the bignum language. That said, what is and isn't "Turing complete" is hardly relevant for practical purposes. C has obviously been very useful as a language, despite whatever theoretical statements can be proven about it.

Absolutely breathtaking. It's like standing on an enormous mountain.

In that same vein, what's the point of the term "interpreter"? Isn't an interpreter just compiling source code into an in-memory representation, and then executing that?

I'd argue that terms like "interpreter", "compiler", "decompiler", "transpiler", etc. are helpful for establishing a general taxonomy of program transformation tools, even if the boundaries aren't so clear.

Judging posts based on titling patterns considered harmful

The hack is cool, but the post's title could use a lot of work. The article doesn't really talk about how git push over SSH works, and strace isn't even mentioned outside of the first paragraph.

This is really dang cool. I started a similar project[0] but have tabled it for now, since I'm not sold on the usefulness of making C easier to use this way.

The way I see it, there are two ways to use a library like this that are worth considering: adapting existing projects, and starting new ones. In my opinion, the gains to be had from rearchitecting an existing project to use such a library are minimal, and for the vast majority new projects, C is not the best choice these days. If you want the performance of C with the programming style of Go, you can probably get away with just using Go!

That said, it's nice to see a polished, working implementation of this idea. Definitely something worth being aware of.

[0] https://github.com/aji/libco

This article is so charming! I get the same feeling reading this as I do watching a puppy waddle around.

I like this! "If you're the best jazz player in the band, find a new band"

I'll admit that there's a lot of gaps in my knowledge of how RobustIRC works, I tried to make that clear in the post. I was just enumerating the obvious problems with using strong consistency with IRC, RobustIRC being the most prominent implementation, and explaining how working around those problems ultimately leads to something only marginally better than what IRC currently is. (I apologize for the admittedly sensationalist title.)

>This design will also scale to running across multiple servers, and in general to any kind of computer, business or industry problem.

If I understand what you're getting at, you're saying that locking is the solution to all concurrency problems? This section is the most interesting to me, as I've been researching concurrency at a high level lately. I'm a little confused by your conclusion. It seems naïve to claim that multiple hosts can agree on what action to take "just" by using locks. What if a peer is holding a lock and becomes unreachable? What if the peer isn't dead and thinks it still has the lock? What if the core that is issuing the locks becomes unreachable?

That's a pretty funny parody of BBC Test Card F: https://en.wikipedia.org/wiki/Test_Card_F

To be fair, `ag shotgun` would take less than a minute to run and skim the output of. If nothing obvious turns up, you try other things.

Is this about the IA-32 debugger? There's a Phrack article that describes something similar: http://phrack.org/issues/65/8.html

While IRC is certainly in use at companies and by the public, it's in a pretty steep decline, especially in the last decade and a half. The only people who avidly use it in their free time anymore tend to be tinkerers and tech types. (As a side effect of this, the only large network that hasn't been shrinking significantly is Freenode.) From the public point of view, IRC is something for CSI-type movies to name drop when they want to evoke hacker culture, which is not by itself a bad thing, but it's a strong indicator of a perception problem.

As someone who has spent a non-trivial amount of time in IRC development and as an operator on small and medium sized networks, I've noticed that IRC (especially when services are involved) is pretty counter-intuitive for many users, even otherwise brilliant ones. Modes are obtuse and vary wildly from server to server, the idea of a separate nickname and channel registrations seems unnecessarily complex, channels just disappear when everybody leaves them, and so on. On top of this, the IRC architecture is needlessly limited for the most common IRC network use cases these days. In the past where networks were a federation of autonomous servers, it made sense, but these days a network's servers are partly or entirely controlled by a single entity, and things like netsplits are an unnecessary interruption in user service.

There is a working group to define the next generation of the IRC standard, but the additions tend to be patches for small nigglings in the protocol (such as needing to consistently poll for user away statuses and account names) than aggressive overhauls to the whole architecture, which is okay; there's only so much you can do with an effort like that while still seeing progress, and these are things IRC has needed for a long time anyway.

In my opinion what is needed if IRC is to regain its popularity is an innovative new server implementation that challenges the very workings of IRC from the ground up, maintaining only enough of the protocol to interact with existing clients. If users are to feel comfortable with IRC, they need a server software suite that conforms to their expectations of how a chat service should behave, and no solution currently provides that. The problem is, there is an enormous engineering cost associated with this, and the IRC development community is having a hard enough time as it is finding people who are willing to do more than just basic maintenance tasks.

I've only been on IRC for 4 years and I can't imagine life without it. For me, it's become one of those constants I can rely on that's just always there wherever I go.