What is so bad about virtual environments? I found them to be really nice and useful when I developed in Python over about 5-ish years. It was really nice being able to have separate clean environments for installing libraries and executing things.

Granted, I only used Python as a solo developer, so if there are shortcomings that emerge when working with other developers, then I would not be aware of them…

Edit: also, performance is a bit more of a subtle topic. For numerical logic, Python actually is (probably) much better than a lot of its competitors thanks to numpy and numexpr. For conditional logic, I would agree that it’s not the best, but when you consider developer velocity, it’s a clearly worthwhile tradeoff since frameworks like Django are so popular.

True, but if you’re looking at a Python library that doesn’t have type hints in 2024, then chances are that it’s not very good and/or not very well maintained.

Website redesigns. Just more whitespace all over the place, less information on the screen, and more trouble trying to get anything done.

Github is especially bad about this. I’m so tired of only being able to fit about 50 lines of code on the screen at a time, or issues with a similar lack of information density. I can understand this paradigm for websites that you only use once every year or so, but for something that most people use regularly every day, it’s such a backwards anti-productivity trend. I hate it… hope it dies someday.

Mozilla 2017: Competing with Chrome is hard. What if we break all existing extensions and never let people replace them all?

This is the one that broke my back. Understandable that XPCOM extensions had to go, but leaving nothing to replace them, and then going on to push their trash UI redesigns without giving us any recourse to change them back - that was just unforgivable.

Then again, that was still well before they started pushing spyware in their own browser, so in retrospect, those were very quaint times!

I haven’t done too much work with WASM myself, but when I did, the only languages I saw recommended were Rust, C++, or TinyGo. From what I’ve heard, Rust and C++ are smoother than TinyGo. Garbage collected languages usually aren’t great choices for compiling to wasm because wasm doesn’t have any native garbage collection support. That limits your selection down a lot.

But another option you may want to consider is Nim. As I understand, it compiles to C, so any C->Wasm compiler should theoretically work for you as well. I did a quick search and wasn’t able to find any great resources on how to do this, but you might get a bit more lucky. Good luck!

You’re probably right. I think COBOL development is one of the cases where the crazier stories are the ones that bubble to the top. The regular scene is probably more mundane.

I do think there are a few advantages to learning COBOL over C++. COBOL seems to be much stickier - companies that use it seem much more hesitant to replace it than a lot of the companies that use C++, and as a result, they will probably get more desperate. And while there’s definitely a lot more C++ out there than COBOL, I have to imagine that the number of people under 50 that use COBOL is probably tiny, while C++ still has a very large userbase. On the other hand, consulting depends a lot on your portfolio, references, and past accomplishments, and nobody’s going to pay 1k EUR/USD/etc. per hour (exaggerating, obviously) if you don’t have any credentials. It takes time to build that up.

Ultimately, I do think you’re pretty spot on, but we’ll have to see. This is more just a fantasy I tell myself to make it seem like retirement is closer than it probably is…

I fantasize about being one of those extremely well-paid Cobol consultants when I reach the later stages of my career. Hoping that I can earn a full year’s salary in 3-4 months and take the rest of the time off as a semi-retirement. It would be easier said than done, but it’s a dream that helps me get through the days when I get sick of the daily grind.

This is very interesting! Things like this make me wish programmers would give functional^W declarative programming more of a chance. I’ve long fantasized about being able to write programs as declarative code that the computer can optimize automatically without human intervention. When you implement your program in more restrictive (ie. stateless) paradigms, you can more easily reason about the code, and thereby make it easier to optimize or run in different environments.

SQL is a great example of this - when you look at some of the optimizations that servers like PostgreSQL can do under the hood, this is because the language inherently limits what you can do so the actual system executing your instructions can do different things with it for better performance and reliability. Things like this are what make query optimizers possible, and it’s really fascinating if you actually read carefully what query analyzers report (beyond just checking whether your indices are being used or not).

Beautiful chart. Thanks for sharing!

I would vote for docker as well. The last time I had to inherit a system that ran on virtual machines, it was quite a pain to figure out how the software was installed, what was where in the file system, and where all the configuration was coming from. Replicating that setup took months of preparation.

By contrast, with Docker, all your setup is documented. The commands that were used to install our software into the virtual machines and were long gone are present right there in the Docker file. And building the code? An even bigger win for Docker. In the VM project, the build environment for the C++ portion of our codebase was configured by about a dozen environment variables, none of which were documented. If it were built in Docker, all the necessary environment variables would have been right there in the build environment. Not to mention the build commands themselves would be there too, whereas with VMs, we would often have developers build locally and then copy it into the VM, which was terrible for reproducibility and onboarding new developers.

That said, this all comes down to execution - a well-managed VM system can easily be much better than a poorly managed Docker system. But in general, I feel that Docker tends to be easier to work with than a VM. While Docker is far from flawless, there are a lot more things that can make life harder with VMs, at least from my experience.

Just in case this comment didn’t make it explicitly clear, you can just invoke the python binary inside your venv directly and it will automatically locate all the libraries that are installed in your virtual environment.

To show how this works, you can look at the sys.path variable to see which paths python will search for modules when you run import statements. Try running python3 -c 'import sys; print(sys.path)' using your system python, and you will only see system python library paths. Then, try running it again after replacing python3 with the full path to the python3 binary in your venv, and you will see an additional entry in the output with the lib directory in your venv, which shows that python will also look there for modules when an import statement is executed.

Don’t worry everyone, I’m here to help:

Mail

Garbage

Outlook

Hot Garbage

Outlook (new)

Shit-tier garbage

Glad to be of service! Until next time…

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.

This is quite cool and a very interesting read. I’m not sure if it’s something I would want to use in a real project, because it looks like you’re basically inventing a new language within Python’s type system itself, which is a little weird. That said, I feel like I learned a lot from reading this, and it was a very interesting demonstration of what you can do with Python’s type-checking system.

There is no way to make a network request faster than a function call.

Apologies in advance if this it too pedantic, but this isn’t necessarily true. If you’re talking about an operation call that takes ~seconds to run, then the network overhead is negligible. And if you need specialized hardware for it, then it definitely could be delegate it out to a separate machine over the network. Examples could include requiring a GPU, more RAM, or even a faster CPU if your main application is running on more power-efficient CPUs.

I’m not saying that this is true in every case - they are definitely niche cases. But I definitely wouldn’t say that network requests are never faster than local function calls.

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!

Yeah, I knew someone was going to say that. Usually it’s more likely that Python is installed than jq - especially on servers. But yes, that would definitely work too.

I use json.tool a lot to format JSON directly in vim. Simply highlight the text you want to format and run :!python3 -m json.tool. There are probably plugins to do this too, but doing it this way is probably the simplest, unless vim has a built-in for it.