This is quite cool. I always find it interesting to see how optimization algorithms play games and to see how their habits can change how we would approach the game.

I notice that the AI does some unnatural moves. Humans would usually try to find the safest area on the screen and leave generous amounts of space in their dodges, whereas the AI here seems happy to make minimal motions and cut dodges as closely as possible.

I also wonder if the AI has any concept of time or ability to predict the future. If not, I imagine it could get cornered easily if it dodges into an area where all of its escape routes are about to get closed off.

Git’s internals are very easy to understand and once you know more about them, you’ll have a much better idea of how it works (especially when it comes to tags and branches). They’re so simple, you could even easily write your own scripts to parse git’s internal data directory if you wanted to.

I would highly recommend reading about them: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#

there has to have been a significant global productivity cost due to the lack of a better UI.

I’m not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.

Xournal - a great way to draw on pdfs

Agreed on all points. I think some of the issues that you’re facing are things that would be resolved if Ocaml were more popular. But some others would be harder to fix without making breaking changes to the language as I mentioned earlier. If I had to put it as succinctly as possible, I’d say that the language just needs a lot more polish which would probably happen if it were more mainstream. But not all languages have to be mainstream, and maybe Ocaml’s purpose in the world is, as you put it, to inspire other languages. It is definitely extremely good at that!

No one has said Ocaml yet, so I will. It’s not a perfect language, but it has a lot of cool ideas and concepts. It’s a functional language, but allows you to write imperative code when you want to. Algebraic data types and type matching are built natively into the language and work very nicely. It’s type inference capabilities are very powerful (though that can backfire at times), and the |> operator is really, really fun to use. It also has very powerful module/functor capabilities, though they go a bit over my head since I haven’t had a chance to play with them. Also, Opam is a very powerful package manager and it’s pretty easy to wrap/bind external libraries with it.

I’d love to see some improvements to the language - the syntax is a bit confusing and ugly at times (but this unfortunately can’t be fixed without breaking the language of course) - but overall I think I’d have a lot more fun programming in Ocaml than what I do in my day job.

I think most of the arguments here are kinda ridiculous and poorly thought out. A lot of them also sound pretty imaginary and made-up. For example:

To assert that frontend languages are not programming languages is to assert that what one is doing when writing them is not programming, but something else. Something different.

Something—perhaps not explicitly spoken, but undeniably implied—lesser.

Basically, he’s arguing that everyone who thinks HTML/CSS isn’t a programming language is wrong, and then the only reason they feel this way is because of a prejudice against front-end developers. I think this is really just a wild leap in logical reasoning, personally.

(No mention of Javascript/Typescript here by the way.)

If you wanted to find the dev specialization with the most people who aren’t cishet white males, you’d pick frontend.

Do we honestly believe the language around frontend is different purely by mere coincidence?

… yes? His argument that HTML/CSS should be considered programming languages is honestly quite weak. Couldn’t that be the reason instead?

Certain pursuits are validated with importance, dignity, and honor.

Doctors; lawyers; architects; CEOs; software engineers.

… we relegate others to the role of the sidekick - even though their labor is no less important, and they do at least as much to push the work toward success.

Nurses; paralegals; interior designers; executive assistants; frontend developers.

Who the hell is making these groupings?? Front-end developers compared to nurses? Software engineers to doctors? And software engineers being held in the same light as CEOs… wtf???

(Surely it’s a coincidence the first group tends to be more male than the second.)

Once again, he’s attributing his feelings with prejudice when really, I think his arguments are just very poorly thought out.

Other forms of development are generally considered serious work. They’re important. They’re real computer science. (Computer science itself being a higher level of things we’ve decided are real, serious, and important—maybe not quite as much as medicine or law, but then again, maybe so in some circles.)

Again, I don’t see anyone arguing or claiming this. I’m sure the author would argue that just because we don’t say it aloud, but it’s just implied, but I honestly just think no one says it because it’s just silly.

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

Though critical to the project, frontend work will quite often be disregarded by those who consider it beneath them (usually men, and usually only tacitly, never explicitly). It’s not serious enough; not important enough; not real enough. Too squishy. Like soft skills.

Once again, just unfounded accusations of bias. “You didn’t say it, but I’m telling you that you said it anyway.”

Their [software engineers’] output is easily measurable. A new API feature; a more efficient database; crises averted and crashes prevented. They go on charts and get presented to board members.

Board members couldn’t give less of a shit regarding what software engineers do. We’re considered a cost that they’d love to get rid of as much as any other position. Look at all the AI hysteria going on right now, like Nvidia’s CEO telling people not to go into software because it won’t exist anymore. Again, I have no clue where this guy is getting his ideas from.

If our job title does include the word “engineer,” it will almost certainly specify what we’re engineering. It’ll be UI engineer, or frontend engineer, or maybe the newer (and arguably more fitting) design engineer.

But it’s probably not “software developer” or “software engineer” without any other qualification. Because that, tacitly, is not what we do.

Completely disagree. Front-end development is a subset of software engineering. He even admits this as much:

Sure, this is nuance of language and these titles serve to disambiguate. I get that.

but then he goes on to dismiss that by saying “that’s not really it though, it’s really because we’re not considered real engineers”:

by definition, somehow what we do isn’t seen as software engineering. It’s different than that. It’s softer than that.

By what definition exactly? He just explained the reason for the difference in terms above, but then goes on to say that’s not really it - the real reason for everything bad is (what he perceives as) negative bias.

There’s a couple interesting ideas in here. He makes a good point that layoffs on the front-end are more likely to hit underrepresented classes, though there’s not much that can be done about that. Layoffs are happening everywhere, and DEI is probably not what’s on CEOs’ minds when they make those decisions. And sure, there are unrealistic expectations at times, but that happens everywhere, not just in the software industry, but in pretty much any labor scenario.

But overall, I think this guy has major issues with his self-perception. Pretty much all of his arguments are predicated on very poorly thought-out or straight up imaginary ideas. And blaming everything that’s wrong with his perception of front-end development on the white male hierarchy is just… I can barely even find words for it… nonplussing? I think he figured it out by the end of the article:

Maybe I’m feeling sorry for myself. Maybe I’m just a little depressed right now. Maybe I have an inferiority complex and I’m projecting it on everyone else.

I’m pretty sure it’s all of those.

I wish this guy the best. Shit is hard right now. But I’d be a fool to say that I agreed with more than 10% of what he’s trying to argue.

My advice would be to learn C first (or at least develop a good understanding of it). It’s extremely important to understand how memory works in C so that you can understand pointers in C++; and also important to understand how functions work so you can understand classes and methods in C++. I would go through The C Programming Language. It’s fairly concise and while you don’t have to go through it cover to cover, you should at least understand the chapters on structs, pointers and functions (up to chapter 6, I believe).

(Note that the wikipedia link that I posted above has a link to the full text of the book in pdf format.)

The reason why I think it’s important to understand C is because when you learn C++, then you’ll understand how the language abstracts over a lot of the lower-level functionality in C. new in C++ supplants malloc in C for example, and your understanding of functions in C will map to more complicated concepts like constructors, destructors, copies, methods, and operators in C++. At this point, I would probably start learning how classes in C++ work. They’re basically structs with private member variables and methods defined in the scope of the class. learncpp.com, is the best reference that I’m aware of (it’s very thorough, which makes for a pretty slow read, but you’ll understand it very well). I would probably start with chapter 14 (introduction to classes), and then go back to the earlier chapters to fill in the gaps, but this is more dependent on how you think you learn best.

Be aware though, that if you don’t have existing experience with OO development, then C++ is (in my opinion) not a great language to start learning it, because a lot of it is hacked on top of C and implemented in arcane ways in order to maintain compatibility with C. The first language I learned was Java, and it was really helpful to have that as a background for when I learned C/C++. I’m only familiar with Javascript on a procedural programming level, so I’m not aware of its OO functionality or how well that will translate to C++, but hopefully it works out.

Good luck!

Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that’s smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.

I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A “deep knowledge” of a language is not just about being faster and more productive; it’s also about not creating more issues than the ones your solving.

This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:

You don’t really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you’re going to spend more time learning about common libraries and how to manage dependencies. If you’re working with a language like C++ or Java, this could also include build systems and how to use them.

Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.

the only annoyances are that to use the slash you need to use shift

Oof, that sounds really annoying. I can’t possibly imagine how I would use the terminal that way

But Swiss, that’s the stuff of nightmares!

Ha, that sounds funny (in a morbid kind of way…). What’s so bad about it?

Off-topic, but I’m curious why you would put Nim in that list. While I absolutely love the language, I’ve never heard of anyone using it for anything serious, especially compared to Rust or even Zig. I’d even be surprised if it has more mindshare than D.

(An absolute shame by the way. Nim looks like an absolutely fantastic language.)

Guess we’ll just have to deprecate the entire Windows OS then…

I’d really like to do some personal projects, both to learn new stuff and scratch my digital itches.

Likewise. There are so many things I’d love to do. Hell, I’d even love to just practice and improve at things that I do in my day job. My current job requires golang and while I’m competent, I’m nowhere near the level of comfort that I want to be. And that’s just the language, there are other libraries, technologies, etc. where I’d like to improve too.

But unfortunately, I have to pace myself. And that basically means I can never do anything computer-related in my spare time. A part of me hopes that some day, I can reduce my hours, or just find a very chill job that still pays decently so I can do more important things in my spare time. But for now, this is the choice that I’ve made.

Personally, I’m just sick and tired of modern UI design. Bring back density, put more information on the screen, eliminate the whitespace, use simple (and native!) widgets, get rid of those fucking sticky headers, and so on.

In addition to all the software freedom stuff, and so on. Also, I wish GPL were more popular too.

The fact that debug cycles are fast. I started out working in nanotechnology, and spending 3-4 days of fabrication -> electron microscope -> optical verification was soul crushing cause 99.9% of the work never led to anything and you practically never knew why.

Software development is logical and predictable. It’s (relatively) easy to break a large task down into small ones, prove to yourself that they will work, and compose them together to complete a large project. Sure, things go wrong here and there, but for the most part, you can be confident that whatever you’re doing should work every step of the way… without having to worry that you committed some irrecoverable error at any step in the process.

This is still on my todo list, but getting rid of std::regex in my C++ code. It’s abhorrently slow.

OCaml is a really interesting language. Wish I had more opportunities to try it out…

Anyway, you might want to check out https://discuss.ocaml.org/. They are a pretty active OCaml community and are pretty helpful for beginners and learners.

Corporations are always happy to pander to morality when it’s to their benefit

Seriously. We have fossil fuel companies knowingly and willingly destroying the planet in the name of profits. Where's the outrage over that? Or is that moral and ethical?

But when we're talking about technologies that give power to the people to break from the shackles of the content cartels, then all of a sudden, out come the morality police!