• 0 Posts
  • 47 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle

  • Datalog is sometimes used as an alternative to SQL. Prolog is used by researchers experimenting with rule systems (e.g. type systems, theorem provers, etc).

    Mercury has been used to write regular desktop software, with a couple of notable successes.

    One way to think about Mercury is that it’s like Haskell, except it’s so declarative that the functions can run backwards, generating arguments from return values! Obviously that comes with some pretty big caveats, but in many cases it works great and is extremely useful.







  • 5 years ago everything was moving to TypeScript. Now everything has moved. Developers are still catching up, but it will be one-way traffic from here.

    I’m guessing your manager thinks TypeScript is like CoffeeScript. It is not like CoffeeScript.

    Also, TypeScript is only the beginning. In the halls of the tech giants most devs view TypeScript as a sticking plaster until things can be moved to webassembly. It will be a long time until that makes any dent in JS, but it will also be one-way traffic when it does.


  • The specifics of C’s design could barely be less important. In the 70s it was one of countless ALGOL derivatives churned out on-demand to support R&D projects like Unix.

    Unix succeeded, but it could have been written in any of these languages. The C design process was governed by the difficulty of compiler implementation; everyone was copying ALGOL 68 but some of the features took too long to implement. If Dennis Ritchie had an extra free weekend in 1972, C might have a module system. But he didn’t, so it doesn’t.




  • Lol okay. Here are some concrete examples I don’t have:

    Templates as basic generics

    • Templates still show bizarre error messages far too deep into instantiation, despite at least three major features which provided opportunities to fix the problem (static_assert, type_traits, and then concepts)

    Templates for metaprogramming

    • 33 years after the introduction of templates, there are still many common cases in which the only good way to abstract a pattern is by using a macro, and many cases that neither macros or templates can solve
    • There is finally an accepted proposal to fix part of the problem, which will be introduced in C++26, and probably not usable in real code until 2030 at the earliest
    • In 2035, people will still be reluctantly using string macros and external code generation to solve basic problems in C++

    Safe union types

    • C++17, std::variant was introduced to provide a safe inline union type
    • The main API for accessing it is inexplicably slow, unlike in every competing language
    • The fast alternative is an eyesore that can’t integrate with switch statements except via weird, unmaintainable hacks
    • Everyone keeps using custom struct/union/enum combos instead
    • CVEs everywhere

    Error handling

    • C++ uses exceptions as the primary error handling mechanism
    • Exceptions are so slow and so riddled with problems that some companies ban them, and almost all consider them bad practice for representing common failure paths (e.g. failing to parse something)
    • std::expected eventually approved, similar to Rust’s Result type, but with no equivalent to the ‘?’ operator to make the code readable
    • Now there is a proposal to introduce “value type exceptions” instead, which is gathering momentum before std::expected has even stabilised, but will probably not be available for 10 years

    Subtype polymorphism deprecated

    • Now that virtual methods and inheritance are widely considered tools of last resort, they obstruct the introduction of better alternatives
    • Instead we have widespread use of specialised template structs and CRTP to replace instance inheritance with a kind of static inheritance designed for templates
    • It’s all a hack, and as a result it’s full of edge cases that don’t work very well, and poor tool support

    References

    • Good C++ programmers use references where possible, because pointers can be null
    • Good C++ programmers avoid unnecessary copies and allocations
    • Good C++ programmers avoid patterns that can permit unintended coercions with no error
    • Oh no, I accidentally assigned a reference to an auto variable in a template, and instead of giving a helpful type error it implicitly coerced a new copy of my vast memory buffer into existence
    • Okay fine I’ll pass pointers to avoid this, and just trust they won’t be null
    • Oh no, C++ has standardised the idea that raw pointers represent nullability even in all their newest standard library types (thanks again, std::variant)


  • I learned through three things:

    1. writing some basic functions in assembly code by hand for a course (not many)
    2. implementing a basic compiler back-end in llvm (any similar IR or assembly target would do)
    3. learning the principles other people were using to write fast code (in my case game engine developers)

    The first two things helped me understand how common code constructs are translated to assembly, so I can do a rough projection in my head when skimming a C function. Nowadays you can get quite far just by playing around on godbolt.

    The third thing helps surface the less visible aspects of CPUs. After learning how a few low-level optimisations work, all the principles and explanations start to repeat, and 90% of them apply to every modern architecture. You can set out with specific high-level questions, like:

    • why is iteration faster with an array than a linked list?
    • what does vectorisation mean?
    • what is a “struct of array” optimisation?
    • why does the ECS pattern make game engines fast?

    Very quickly you’ll find lots of insightful articles and comments explaining things like CPU caching, prefetching, branch prediction, pipelining, etc.

    I have no book recommendations for you. I’ve found all the best information is freely online in blogs and comment sections, and that the best way to direct my learning is to have a project (or get employed to do low-level stuff). Might be different for you though!





  • If you see a real chance of it shipping soon, that might be good experience. As I mentioned, a surprising number of grizzled senior devs have never actually shipped anything.

    But if you see better opportunities elsewhere then just go. Sad reality is that job hopping early is what gets most people a good salary. Very few companies give real raises. The only time you have bargaining power is when you haven’t joined yet or when you’ve already made plans to leave.


  • It’s very common. I’d bet most software projects still fail. I once met a guy who’d been a gamedev for over 10 years at some big companies, and every game he ever worked on got cancelled.

    Sometimes these long, poorly managed projects do succeed though. Usually because they launch a beta or get publicly scheduled for release, and the sudden reality check causes someone senior to trim the scope down dramatically.

    It might be worth sticking around if you think you’re learning things, but impose some personal limits. Don’t kill yourself trying to meet some idiot’s impossible schedule. Work your contracted hours and no more. Be blunt and unashamed about how long tasks really take. Share your concerns when the month’s schedule looks unrealistic, referring back to previous tasks that overran. This is how you learn to one day become a lead who doesn’t run shitty projects like the one you’re on.