HN user

10x-dev

631 karma
Posts0
Comments121
View on HN
No posts found.

Crafting Interpreters by Nystrom.

It's great because of how accessible it makes compilers to average programmers, and, as a bonus, it also throws shade at the overly dense compiler textbooks:

"Classic compiler books read like fawning hagiographies of these heroes and their tools. The cover of Compilers: Principles, Techniques, and Tools literally has a dragon labeled “complexity of compiler design” being slain by a knight bearing a sword and shield branded “LALR parser generator” and “syntax directed translation”. They laid it on thick." (chapter 6)

Having read Compilers for a compilers course in college, Crafting Interpreters was a fun read on many levels.

I work at Meta and I use tools written in bash, C, Java, Go, TypeScript, Kotlin and Dart daily. I've definitely noticed that some C++ tools are moving to Rust. I would have preferred to see D in its place, but it is what it is.

Personally I'm not a fan of Rust, but it is interesting to see how the language is growing as it hits mainstream. Lots of similarities with Go back when it was cool and hip.

I loved 50% of my Master's degree program. Those were the best CS courses I ever took (writing assemblers, compilers, CPUs in FPGA, OS kernels from scratch). I could have presumably avoided the degree and done it all by myself, without the knowledge of a professor, without the support of the TA and without feedback from others, but it would have taken at least twice as long and I am not entirely sure I would have been able to get to the finish line.

This is my biggest issue with working at FAANG (been at 2). Lots of people just don't give a shit. To paraphrase the Silicon Valley show: "you got your RSUs now fuck off for 4 years". I can't fault people for making the best financial decision for them, but for crying out loud, give a shit about the code. Write the unit test. Write the docs to explain the architecture. Refactor the code while you're editing that file. Think about class and method names. Give a shit.

My 'favorite' silly thing PMs do is UX research studies (typically on 5-10 people) and essentially ask completely untrained people if we should go with X/Y or Z. It's a super-effective way of avoiding responsibility for product decisions ("the data suggest we should go with Y"). If only building good products were as easy as asking what customers think they want.

I bought one of these laptops. It came with Windows 11. I followed the steps on Ubuntu website to flash a USB drive and the laptop didn't boot from it, despite selecting to boot from USB. After disabling Secure Boot from BIOS, I was able to install Ubuntu. Windows continued to work just fine.

iirc whatever cert grub was using has been blacklisted by Lenovo because of some recent security issue in grub (I can't find the details right now).

Whatever your stance on Secure Boot, this increases friction and raises the tech bar for people to install other OSes. I imagine that even a "power" user wanting to try Linux would be very confused and would probably give up after not being able to boot from USB.

It is objectively not ludicrous. It might go against the commonly taught idea that businesses should focus solely on generating profits, but it is not unreasonable to create a system where businesses have to keep the common good in mind.

There is a difference between 'how things are now' and 'how things could be'. Imagining and wanting a different status quo is not by itself ludicrous (especially since we all stand to benefit from such businesses), it's a first step towards change.

Absolutely! Speaking of operators, out of curiosity, what's the reason for using '!' with templates?

Naively, I would think that making template instantiation look the same as a function call would be a desirable feature, with ambiguous calls needing to be resolved by the user.

Thanks Walter, that's a great example and I like that, because parens are optional, it could also be written as

    e.d.c(3).b.a
which is even cleaner.

For those who are thinking UFCS is a trivial detail, consider that the shell and some other languages have pipe operators (|>) to make the code flow intuitively the same way as the data.

In my opinion, in a C-like language, managing to squeeze so much functionality out of the '.' operator without any downsides is the mark of a well thought out, elegant language.

Thank you for creating D.

D is by far my favorite language. I put in a lot of effort to learn the language and thoroughly enjoyed discovering D's elegance. It has super clean solutions to all sorts of language issues (e.g. obj.foo() is just syntactic sugar for foo(obj), which gets you both type extensions and OO-looking methods on structs, which I miss in C).

That said I really tried to use D for my projects, but I had to give up for a rather surprising reason: the C interop is so good, that 1) most libraries provide a 1-1 translation of their C APIs, which ends up being ugly, non-idiomatic D that forces me to think in both C and D when coding; and 2) debuggers are not aware of D types and idioms, so when debugging, I have to again think in both C and D. Both of those add up to about 90% of the coding time, which is to say that, 90% of the time, when using D, I felt I had to code in 2 languages at the same time.

I'll skip some of the other issues I ran into, because I think a lot of the problems with D would go away if it had a large active community that would put the work in to maintain the D ecosystem, but that's a bit of a chicken and egg problem.

In the end, I decided that for me the reduced language overhead, solid ecosystem and modern conveniences of gnu17 C were more valuable in practice than the sweet features that D had to offer, and that made me a little sad, but I'm hopeful that one day D will make a strong comeback.

I know Walter gets notifications when D is mentioned on HN, and I imagine that if he read through this he'd shake his fist at me for saying interop-so-good-its-bad, but, if I could make a parallel with Java, I'd say that in code that uses many 3rd party libraries, D feels a bit like coding with JNI all the time (sorry). Ironically, in my opinion, D would benefit from having a community that rewrote popular libraries, instead of primarily relying on C interop.

In terms of developing software without distractions, I like to recreate airplane conditions.

I load devdocs.io in a persistent tab, get all the software I think I'd need for the day/weekend and turn on airplane mode. I don't need to Google everything - between devdocs, man pages and just figuring stuff out by myself, it can be very fun to code disconnected.

Anecdata: when I was intermittently fasting, I found that exercising at lunch curbed my appetite and I could easily last till dinner with no food or with a small yogurt snack (<50cal). On days when I didn't exercise, I felt hungrier and had to engage my will power much more during the day.