1. 5
    • Finish Brave New World - it’s a lot shorter than I expected at ~220 pages. It’s also a lot worse than I expected, compared to 1984. I would say even that to compare them is a little…odd?
    • Continue my FASM experiments from last night - possible blog article to follow.
    • Didn’t get to the GC papers - get to them.
    • Start thinking about storing and decrypting secrets from the Somu (like pass, but on the device). Create some documentation on how to use Rust with it.
    1. 1

      Brave New World What’s odd about it? They both share the aspect of a dystopian system of societal control, they just vary in the method used. The world today shares traits with both views. I’d recommend reading Brave New World Revisited which is a series of essays by Huxley on key aspects of the book.

      1. 2

        It’s odd because Brave New World feels too stuck up on a particular aspect of its dystopian future, whereas 1984 the future is detailed, textured, and does not focus on one aspect of control. Also BNW is written in a way too non-linear manner, many times switching between 3 contexts 4-5 times on the same page. You know those times when you watch something and you see cut after cut after cut? That’s what BNW reads like, whereas 1984 is like one continuous shot.

        You’re right that they share that aspect, but 1984 just gives it so much more depth. BNW doesn’t have much meat to it at all I find. I feel I was sold BNW as being as in-depth as 1984 but no, that’s not the case. I would not recommend BNW to anyone, and would hope that someone would recommend to me something along the same theme, but written in a more structured, thought-out way.

        Anyway, my 2 cents. :)

        1. 3

          I thought BNW was interesting for proposing a world where most-everyone knew, on some level, that what they were being told was untrue - and they didn’t care. A proposal that seems less unlikely over time.

          I agree that the writing was much, much harder to follow than 1984, though - and that is a pity.

          1. 1

            Could your expectations have been set in ways that pre-disposed you to not find Brave New World as satisfying?

            I wholeheartedly agree that comparing them is a mistake. While they’re both descriptions of a dystopian future, 1984 draws its superb texture and depth from Orwell’s experiences in the British Imperial Police serving in Burma.

            Orwell also authored a decidedly non trivial amount of excellent writing on the politics of language.

            I think Brave New World’s scope is narrower by design. It poses (and answers!) the question: What if a drug could make people utterly happy and satisfied all the time?

            Just my $.02

            1. 2

              Just a nit-pick, I think Orwell also drew a lot of inspiration from his experiences in the Spanish Civil War, and from how Communists in Europe and elsewhere toed the party line prior to World War 2.

              The deprivations described in Nineteen Eighty-Four are supposed to have been inspired by Britain’s post-war rationing and austerity.

              1. 1

                Just a nit-pick, I think Orwell also drew a lot of inspiration from his experiences in the Spanish Civil War, and from how Communists in Europe and elsewhere toed the party line prior to World War 2.

                A fine point. I agree that I should have mentioned that. It’s important.

                The deprivations described in Nineteen Eighty-Four are supposed to have been inspired by Britain’s post-war rationing and austerity.

                No doubt that was an inspiration for him, but so was Burma. Take a look at this article

                I think the shortages and other privations were as much a point he was making about the injustice of the society he was depicting as they were rooted in any real event.

                1. 2

                  Thanks for the link. I need to read more Orwell.

                  1. 1

                    Sure! Other than 1984 and Animal Farm, I recommend his essay Politics and the English Language to everyone. It’s as applicable now as it was then, although I’m not nearly as afraid of socialism as he was :)

                    1. 2

                      I don’t think Orwell ever repudiated his socialism, his beef was rather with (Soviet) Communism.

      1. 3

        It’s unfortunate that our software does not facilitate this. Most software in common use actively undermines the entire purpose of the computer; web browsers are a particularly heinous example. Good on you for teaching these skills.

        1. 2

          As they say, “when all you have is a hammer, everything looks like a nail”. When you are choosing your tools you have to consider how “smart” they are: i.e. do you want to use a machine or do you want the machine to use you? You can write all of your code without the fancy IDE features (how many kernel devs use VIM?). Sticking to “dumb” tools gives you more freedom but it can also prove to be a limiting factor. There’s always a tradeoff.

          1. 4

            After watching an extremely skilled carpenter construct a beautiful shelf for a problem where a simple lashing would suffice, my colleagues and I coined the phrase “when you are a hammer, everything looks like a nail”. On a similar note, I recently saw this video from linux.conf.au about how expertise can constrain thinking: https://www.youtube.com/watch?v=Yv4tI6939q0

            It talks about the construction of the Harvard Convention Center, and how the builders raised problems that the architects ignored, because their fancy new computer said it would be fine. It also describes a gripping story of smokejumpers (parachuting firefighters) jumping into a situation that goes out-of-control and talks about who was trapped by their training, and who found creativity when that training failed.

          1. 23

            FTFY: “A plea to developers everywhere: Write Junior Code”

            Let’s get bogged down with how much simple code we write.

            God, I wish every developer would make an effort to write simple code.

            1. 7

              I don’t disagree with you at all, but Haskell does have a bit of a spiral problem with these sorts of things; often folks writing even simple Haskell programs end up using very exotic types that are abstruse to more junior devs (or even more senior devs who just haven’t looked at, say, lenses before). I have this tweet about a simple dialect of Haskell saved because I think about this often when interacting with Haskell code.

              1. 8

                Those exotic types describe complexity that is present in other languages as well. However, in other languages, you do not need the type checker’s permission to introduce complexity. Instead, you discover this complexity after the fact by debugging your program.

                It is questionable whether the Haskell approach is as wise as it is clever. At least to me, it does not seem very suitable for writing what the original post calls “junior code”. Consider some of Haskell’s main features:

                • Purity and precise types:

                  • Benefit: You can use equational reasoning to understand the complexity in your code.
                  • Drawback: You cannot ignore the complexity in your code, even when it does not matter to you.
                • Lazy evaluation:

                  • Benefit: It is easy to write programs that manipulate conceptually large data structures, but in the end only need to inspect a tiny part of them.
                  • Drawback: It is difficult to track the sequence of states resulting from running your program.
                • Higher-kinded types:

                  • Benefit: It possible to abstract not only over concrete types, such as Int or String, but also over “shapes of data types”, such as List or Tree (leaving the element type unspecified).
                  • Drawback: Oftentimes, type errors will be an unintelligible mess.

                It is ultimately a subjective matter whether these are good tradeoffs.

                1. 6

                  often folks writing even simple Haskell programs end up using very exotic types

                  … abstruse …

                  🤔

                2. 1

                  Isn’t a large aspect of Java and C# that they force you to write simple code? Then they get called “blub” languages or whatever. The reality is that you should write for whoever your audience is. Explaining everything such that a six-year old can understand it requires an inordinate amount of effort and without picking a target audience this is what your suggestion devolves into.

                  1. 7

                    Isn’t a large aspect of Java and C# that they force you to write simple code?

                    No. C# has had type inference, covariant and contravariant generics, opt-in dynamic typing as distinct from type inference, lambdas, value variables, reference variables, checked and unchecked arithmetic, and G–d knows what else I’m forgetting since at least the late 2000s. Java’s missing some of that (although less and less recently), but adds to it things like implicit runtime code generation, autoboxing, and a bunch of other stuff. Neither language is intrinsically simple.

                    But that said, I don’t honestly know that they’re honestly much more complicated than most languages, either. They’re more complicated than Go, maybe, but I don’t even know for sure if they’re more complicated than Python. The thing is that Java projects—at least, the “enterprise” ones for which the language has become famous—go crazy with complexity, despite—and often at odds with—the underlying language. There’s nothing preventing Python from doing absolutely crazy things, for example, and people who remember pre-1.0 versions of Django might recall when it used metaclasses and what would now be importlib to make one hell of a lot of magic happen in model classes. But the community rejects that approach. The Java community, on the other hand, is happy to go crazy with XML, factories, and custom class loaders to roam way into the Necronomicon of software development. I tend to regard this as the ecosystem, rather than the language, going to the extreme.

                    Haskell in practice, to me, feels like what C# or Java code taken to the extreme would look like. And there’s even indeed libraries like language-ext for C# or Arrow (which is for Kotlin, but same difference), which do go there, with (IMVHO) disastrous results. (Disclaimer: I work heavily on an Arrow-based code base and am productive in it, albeit in my opinion despite that comment.) This is also an ecosystem decision, and one that I think this article is rightfully and correctly railing against.

                    1. 5

                      There’s nothing preventing Python from doing absolutely crazy things, for example, and people who remember pre-1.0 versions of Django might recall when it used metaclasses and what would now be importlib to make one hell of a lot of magic happen in model classes. But the community rejects that approach.

                      I don’t think that’s true at all. The difference is that Python has good abstractions, so if you want to do something complex under the hood, you can still expose a simple interface. In fact, Python programmers would much rather use something with a simple interface and complex internals than the other way around. That’s why they’re using Python!

                      1. 4

                        I’m not sure we’re disagreeing, except for I think you’re implying that Java and C# lack an ability to expose something with complex internals and a simple interface. I’m logging off tech for the weekend, but Javalin is a great example of a Java framework that’s on par with Flask in terms of both simplicity and power, and done with 100% vanilla Java. It’s just not popular. And the reason I cited early versions of Django for Python is specifically because the community felt that that tradeoff of a simple interface for complex internals went too far. (If you have not used way-pre-1.0 versions of Django, it did Rails-style implicit imports and implicit metaclasses. We are not talking about current, or even 1.0, Django here.)

                        In other words, I think you’re making my point that this is about culture and ecosystem, not language in the abstract. Which is also why this article is making a plea about how to write Haskell, and not about abandoning Haskell for e.g. OCaml.

                        1. 4

                          Ah right yes I see about the Django thing. I was thinking about how it uses them now. I wasn’t aware it did import magic before, that definitely sounds a bit much!

                  2. 1

                    I used to use juxt and comp and partial quite a bit in my Clojure code, but these days I try to avoid them. They’re clever, they’re fun, they’re succinct… but they can also make it harder for the next person who comes along if they’re not already a Clojure hotshot.

                    1. 6

                      That’s setting a pretty low bar, isn’t it? Partially applying functions isn’t exactly whizz-bang fancy-pants programming in a Lisp.

                      1. 2

                        And yet, there’s usually another way to write it that’s more clear to someone not as familiar with Lisps.

                        (I’m not saying “never use these”. There are definitely times when it’s more awkward to use something else.)

                        1. 3

                          Function composition is the most fundamental functional programming concept as far as modularity is concerned, and partial application is not far behind. They are not specific to Lisps. juxt is slightly more “clever,” but nonetheless provides a ton of utility, is a part of the core library, and should not be shied away from. Talking about avoiding these functions without explicit examples or clear criteria is pointless.

                          Do you disapprove of any macro usage in your Clojure code? Are transducers out? What about core.async? I’ve seen more “clever” and confusing code written using those features than with any of the functions you’ve listed. For that matter, the worst (all?) Clojure codebases tend to be agglomerations of layer after layer of “simple” map-processing functions which are impossible to grasp in the aggregate and incredibly frustrating to debug. This is evidence of a general lack of coherent system-level thinking, versus any specific features in Clojure being responsible for complex, unmaintainable code.

                          The guidelines for writing clean, simple, maintainable code are never so straightforward such that they can be stated pithily, to the chagrin of Rich Hickey true-believers everywhere. It’s a combination of figuring out what works for a given team, adopting conventions and architecture well-suited to the domain, and choosing an environment and libraries to integrate with so that you introduce as little friction as possible (and probably more that I’m forgetting, unrelated to the choice of language). But picking and choosing arbitrary functions to eschew will not get you very close to the goal of writing simple code.

                          1. 2

                            I think you’re taking this a lot farther than what I actually said.

                            1. 2

                              I’m sorry, I was trying to respond systematically to a comment I disagreed with. If you wouldn’t mind: how exactly did I take it too far?

                              1. 1

                                Well, I didn’t say “don’t use these”, I said that I “try to avoid them”. I don’t always succeed in that, and I’m happy to use them where they make sense.

                                There’s a continuum between “can’t avoid it” and “totally gratuitous” and I try to push my personal cutoff towards the left, there. When it would make the code harder to read, I don’t avoid them!

                                1. 1

                                  Well, I didn’t say “don’t use these”, I said that I “try to avoid them”. I don’t always succeed in that, and I’m happy to use them where they make sense.

                                  Why do you try to avoid using them? When does it make sense to use them?

                  1. 12

                    Protobufs are an attempt at a solution for a problem that must be solved at a much lower level.

                    The goal that Protocol Buffers attempt to solve is, in essence, serialization for remote procedure calls. We have been exceedingly awful at actually solving this problem as a group, and we’ve almost every time solved it at the wrong layer; the few times we haven’t solved it at the wrong layer, we’ve done so in a manner that is not easily interoperable. The problem isn’t (only) serialization; the problem is the concept not being pervasive enough.

                    The absolute golden goal is having function calls that feel native. It should not matter where the function is actually implemented. And that’s a concept we need to fundamentally rethink all of our tooling for because it is useful in every context. You can have RPC in the form as IPC: Why bother serializing data manually if you can have a native-looking function call take care of all of it for you? That requires a reliable, sequential, datagram OS-level IPC primitive. But from there, you could technically scale this all the way up: Your OS already understands sockets and the network—there is no fundamental reason for it to be unable to understand function calls. Maybe you don’t want your kernel serialize data, but then you could’ve had usermode libraries help along with that.

                    This allows you to take a piece of code, isolate it in its own module as-is and call into it from a foreign process (possibly over the network) without any changes on the calling sites other than RPC initialization for the new service. As far as I know, this has rarely been done right, though Erlang/OTP comes to mind as a very positive example. That’s the right model, building everything around the notion of RPC as native function calls, but we failed to do so in UNIX back in the day, so there is no longer an opportunity to get it into almost every OS easily by virtue of being the first one in an influential line of operating systems. Once you solve this, the wire format is just an implementation detail: Whether you serialize as XML (SOAP, yaaay…), CBOR, JSON, protobufs, flatbufs, msgpack, some format wrapping ASN.1, whatever it is that D-Bus does, or some abomination involving punch cards should be largely irrelevant and transparent to you in the first place. And we’ve largely figured out the primitives we need for that: Lists, text strings, byte strings, integers, floats.

                    Trying to tack this kind of thing on after the fact will always be language-specific. We’ve missed our window of opportunity; I don’t think we’ll ever solve this problem in a satisfactory manner without a massive platform shift that occurs at the same time. Thanks for coming to my TED talk.

                    1. 5

                      You might want to look into QNX, an operating system written in the 80s.

                      1. 1

                        It should not matter where the function is actually implemented.

                        AHEM OSI MODEL ahem

                        /offgetlawn

                      2. 3

                        I’ve been thinking along the same lines. I’m not really familiar with Erlang/OTP but I’ve taken inspiration from Smalltalk which supposedly influenced Erlang. As you say it must be an aspect of the operating system and it will necessitate a paradigm shift in human-computer interaction. I’m looking forward to it.

                        1. 2

                          I’ve been finding myself thinking this way a lot recently, but I’ve also been considering a counterpoint: all software is fundamentally just moving data around and performing actions on it. Trying to abstract moving data and generalizing performing actions always just gets me back to “oops you’re designing a programming language again.”

                          Instead, I’ve started to try and view each piece of software that I use as a DSL for a specific kind of data movement and a specific kind of data manipulation. In some cases, this is really easy. For example, the jack audio framework is a message bus+library for realtime audio on linux, dbus does the message bus stuff for linux desktopy stuff, and my shell pipelines are a super crude data mover with fancy manipulation tools.

                          Rampant speculation: the lack of uniformity in IPC/RPC mechanisms boils down to engineering tradeoffs and failure modes. Jack can’t use the same mechanism that my shell does because jack is realtime. dbus shouldn’t use full-blown HTTP with SSL to send a 64 bit int to some other process. Failure modes are even more important, a local function call fails very differently from an RPC over a TCP socket fails very differently than an RPC over a UDP socket fails very differently than a multicast broadcast.

                          I feel like the abstractions and programming models we have/use leak those engineering tradeoffs into everything and everybody ends up rolling their own data movers and data manipulator DSLs. From my limited exposure, it seems like orgs that are used to solving certain kinds of problems end up building DSLs that meet their needs with the primitives that they want. You say those primitives are “lists, text strings, byte strings, integers, floats”, but I’d just call all of those (except maybe floats) “memory” which needs some interpretation layer/schema to make any sense of. Now we’re back into “oops I’m designing an object system” or “oops I’m coming up with rust traits again” because I’m trying to find a way to wrangle memory into some nice abstraction that is easily manipulable.

                          In conclusion I keep finding myself saying things very similar to what you’re written here, but when I’ve explored the idea I’ve always ended up reinventing all the tools we’ve already invented to solve the data movement + data manipulation problems that programs are meant to solve.

                          1. 2

                            cap’n proto offers serialisation and RPC in a way that looks fairly good to me. Even does capability-based security. What do you think is missing? https://capnproto.org/rpc.html

                            1. 2

                              Cap’n proto suffers from the same problem as Protobuffers in that it is not pervasive. As xorhash says, this mechanism must pervade the operating system and userspace such that there is no friction in utilizing it. I see it as similar to the way recent languages make it frictionless to utilize third-party libraries.

                            2. 2

                              well, the fundamental problem imho is pretending that remote and local invokations are identical. when things work you might get away with it, but mostly they dont. what quickly disabuses you of that notion is, that some remote function calls have orders of magnitude higher turnaround time than local ones.

                              what does work is asynchronous message passing with state-machines, where failure modes need to be carefully reasoned about. moreover it is possible to build a synchronous system on top of async building blocks, but not so the other way around…

                            1. 4

                              I agree with this in general, but I disagree with the specifics. There is no real difference between any of the operating systems mentioned except that on some of them applications don’t break with an OS update. More security is great, but it doesn’t really impact end users. Computers suck because they’ve been “televised”. In order to see real improvement, we need a greater focus on computation; that is, automation - the raison d’etre of computers.

                              1. 5
                                1. SICP - the classic
                                2. Mirror Worlds by David Gelernter (1991) - Describes what the Internet could have looked like if UserAgents actually helped users.
                                1. 6

                                  I found out this week that I was readmitted to university after 4 years, so I’ll be figuring everything out for that. 1 more month and I can say goodbye to working in a factory!

                                  I’ve also been doing Advent of Code so I’ll continue doing those. Have to do some Christmas shopping on Saturday as well.

                                  1. 2

                                    I have a desktop I built about 8 years ago. i5-2500k @ 4GHz, 24 GB RAM, NVidia 770, and about 16 TB of storage. Just runs Ubuntu 16.04 now since I don’t play games anymore. I’d like to upgrade but I don’t really need it so it’s hard to justify it.

                                    1. 0

                                      This is the first full weekend since Labor Day, so I’ll be relaxing. Planning on going to the local university library tomorrow and doing some shopping. I might fiddle around with my car too.

                                      1. 3

                                        Finishing Thucydides tomorrow. Don’t have work this Sunday so I’m planning to do some light programming on a program for managing my finances in Scheme.

                                        I’m considering buying TAPL as a practical introduction to type systems but it’s pretty expensive. Anyone here who’s read it and thinks it’s practical? I read half of PFPL but had difficulty applying it and I don’t want to waste money on another theory-heavy book.

                                        1. 2

                                          I recently finished Machiavelli’s Art of War. Some parts were pretty boring but overall it was interesting. The historical aspects about the Roman military were neat to read.

                                          Currently reading Thucydides. It’s been far more interesting than I expected, it reads like a novel.

                                          1. 29

                                            Unions would help remove this chicanery from the already-grossly-imbalanced empower/employee relationship.

                                            1. 9
                                              1. 8

                                                Probably, but unions aren’t a panacea. Unions can lead to some bad things too. From my experience I’m not sure which I prefer.

                                                1. 33

                                                  Unions are not a panacea, as in they don’t solve all problems and even come with some of their own, but they exist to deal with exactly this situation. This feels a little like discussing an article about nails and pointing out that hammers aren’t a panacea.

                                                  1. 10

                                                    “Unions” as a concept is mainly just “allowing workers to form a structure to gain negotiation power”. There’s thousands of implementations of that concept, which makes it hard to have a discussion about “unions” on that level as much as for “political parties” or “enterprises” globally.

                                                    Even as a business owner, I got a lot of support from my union, which makes me quite happy with my particular implementation, but I appreciate there’s tons of problems even in mine, specifically around my business.

                                                    1. 1

                                                      By that definition, you might consider callout-blog-posts like these as a form of union.

                                                      1. 6

                                                        Where’s the collaborating structure? This is an individuals post.

                                                        1. 1

                                                          collaborating

                                                          Message boards (such as this one) and social media, I suppose.

                                                          1. 1

                                                            That’s not collaboration. That’s marketing and communication.

                                                    2. 3

                                                      Wouldn’t the logical conclusion be to prefer power being more dispersed between employers/unions, rather than concentrated? We should fight concentration of power, as it is always weaponized against us.

                                                      The only argument I can think of is that the union can interfere at times when they aren’t strictly necessary.

                                                      1. 2

                                                        No, the logical conclusion is to prefer power being more dispersed between employers and employees. Unions are one way of achieving that, but they present their own problems which ought to be considered. Unions can pervert incentives. Where I work (UAW) there is no reason to work harder because you will never get ahead from it (unless you’re trying to be a supervisor, but there aren’t many of those). Sometimes people will work really slow to make sure they don’t do better than standard. Our supervisors won’t even tell us “good job today” unless it’s in private because they’re worried about the union. It’s also basically impossible to fire someone no matter how bad they are at their job. I’m not sure we make more money either, the last place I worked started a bit lower but increased the longer you worked there.

                                                        I pointed out that they aren’t a panacea because I get the impression that the people advocating for them in tech have no experience with them and aren’t fully considering the implications. But maybe UAW is the only one with these problems.

                                                        1. 4

                                                          Individual approaches can pervert incentives just as much. It does for example lead to situations where motivations are entirely self-driven. I’ve seen many projects put on hold because people personal goals for the next raise in the company didn’t align with the goals of their team. That included that their goal became meaningless over the year!

                                                          I’m not saying unionisation cannot lead to weird situations such as yours, but that also usually a sign of a business where this still go too well. For example, when talking to union people in the insurances sector in Germany, they are keenly aware that the whole sector is being automated, so for example some of their strategy is currently bargaining with the employers to migrate people to either other parts of the company or going half-time positions instead of straight-out being fired. Those are very knowledgeable people with high interest in finding a good solution for all sides.

                                                          I do agree with your reading of union advocacy in tech: most of the time, employees figure out they want to unionise when they already have an open conflict with their upper management. Even if they manage, they will be in a situation where management gives them not quarter (why should they, they didn’t before) and that will also lead to them never giving a win away anymore.

                                                        2. 1

                                                          bosses can interfere at times when they aren’t strictly necessary

                                                      2. 6

                                                        This threat, along with wage suppression and employee control in general, is why big tech is pushing for more H1Bs for India.

                                                      1. 7

                                                        I first heard about Hy for livecoding blender which I thought was pretty interesting.

                                                        1. 2

                                                          I found out today that I wasn’t readmitted to university because of a mistake I made on the application. I guess now I have to figure out what I’m going to do. For interesting things, I’ll work on my compiler a bit. I might take another crack at understanding dependent types.

                                                          1. 8

                                                            I got my assembler to the point where I could print “hello world”. It feels kind of cool making a program using your own code. I’m going to see if I can automate adding more instructions this weekend. This is for a compiler so I’m also starting to think about the IR and the language itself. I think I’d like to make a bare-metal language with dependent types, but I don’t think I’m smart enough for that. I’d like a type system that is at least as capable as Rust’s, but even that seems difficult.

                                                            1. 1

                                                              Which machine language are you targeting? x86-64?

                                                              1. 1

                                                                Yes I’m targeting AMD64. If this compiler takes off I’d like to target other architectures but I think that would be wasted effort until the compiler is self-hosting. It would be really nice to target something straightforward but AMD64 is what I use for development so anything else would just be annoying.

                                                                1. 1

                                                                  That’s ambitious! One of these days I should take a look at a few existing code generators for AMD64. Things like register allocation are still a mystery to me.

                                                              2. 1

                                                                but I don’t think I’m smart enough for that

                                                                Judging by what you’ve done so far, you definitely are smart enough to do that.

                                                                1. 3

                                                                  I appreciate it, but I don’t think writing an assembler takes a genius. It’s sort of hard to figure out all of the corner cases for instruction encoding but it just takes time. Meanwhile I’ve been trying to understand dependent types for 6 months now and I still don’t get it. I’ll try to experiment a bit again, maybe it’ll click.

                                                                  1. 2

                                                                    Yeah, sometimes understanding a concept really requires implementing it.

                                                                    1. 1

                                                                      When you figure out dependent types, please explain it, with a language other than Haskell :)…

                                                                      Sometimes I think terms like “Dependent Types” and “Monads” are just because Haskell folks refuse to admit that their ideas might be simple enough to explain with simple off the shelf words. :)

                                                                1. 4

                                                                  Homework and continuing work on my assembler. I’ll probably get some shooting practice in too, and if I have time I’m going to try making a pair of jeans.

                                                                  1. 3

                                                                    I’m taking classes this summer to try and go back to school, so I’ll be doing homework for those. I’ve been fiddling about with writing a compiler, so if I have time I’ll work on the assembly syntax for it (mostly for inline assembly). I’m planning to do an Sexpr based syntax which should be pretty simple. I was trying to output to ELF but I don’t have time to read the spec so I just output the machine code and I wrote a little loader to deal with that for now.

                                                                    1. 4

                                                                      For a more in-depth look at optimizing Brainfuck, see Eli’s articles which start with an interpreter and eventually move to a JIT and then to LLVM.