gnus_migrate

It was my mistake, I said that we definitely know they don't vs. there is no evidence showing that there is. There aren't much studies to back this up. The whole point of the talk is that software engineering as a discipline is really poorly studied and we tend to make assertions like this without actually validating them.

If I was betting money on this(I.e. deciding where to focus my investment), the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC'd language because the kinds of bugs that you face in Web apps aren't really the kinds of issues that a borrow checker will help you with. The whole point of Rust being difficult is that it saves you time down the line, if it's difficult and it doesn't then that tradeoff doesn't make sense.

Hilel teaches formal verification for a living, he very much sees the value of automatically proving properties about your program, as do I, but the reality is that the typesystem doesn't necessarily help as much as we think it does.

There's a difference between tests and assertions. Students do test their code, however they don't write assertions, as I said because you want the cognitive load to be as low as possible so that they can master the basics. I'm fine with tests being provided to them, however they should be focusing on learning the constructs at the start.

In any field, the real life practice of a profession is something you learn working for an actual company, whether it's through an internship or an entry level job. Ideally there should be unions or syndicates setting these standards so that they're consistent across the field, just like with other knowledge based professions.

Universities are not corporate training programs, and they aren't supposed to be.

By the way, what you claimed “research shows” is so ridiculous that it’s hilarious that you wrote it while being serious.

There is still no research that definitively shows that static types reduce defects more than dynamic types, this is a fact. Turns out we are incredibly bad at studying this, so I don't know how you can say definitively that it is the case when even the people who study this for a living are not able to make that case.

The thing is the way they motivate new students to learn programming is by having them write programs that do something. Making a test green isn't as motivating as visually seeing the output of your work, and test fixtures can be complex to set up depending on the language. I mean students don't learn how to factor their code into methods until later into such a course, they're learning if statements and for loops and basic programming constructs. Don't you think having to explain setting up test fixtures and dependency inversion is a bit too much for people at that level?

https://youtu.be/WELBnE33dpY

It's not that there is evidence that it doesn't matter, but there is no evidence showing that it does.

A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters.

Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn't better or worse than other languages. If those problems are prominent in your domain(such as you have to write a ton of concurrent code), Rust makes sense. Otherwise being well rested will have a bigger impact on the quality of your code than the best type system in the world.

In terms of dev practices, the only practice demonstrated to have a consistent positive impact on code quality is code reviews. Testing as well, but whether it's TDD or other kinds of testing doesn't really matter.

If you wanted to introduce every industry best practice in an intro course you'd never get to the actual programming.

It would be good to have a 1 credit course(one hour a week) where you learn industry best practices like version control, testing and stuff like that. But it definitely shouldn't be at the start.

Its not docker's fault, its the fault of the stack of crap that is needed to run it(WSL and co). My point is that it isn't worth the trouble. I could figure it out myself, but dev containers don't bring enough value to my team to justify the investment, and I really dont want to spend a bunch of time troubleshooting issues related to it not just for myself, but for everyone on my team. I played that role before, and it is exhausting to have to do that on top of the other things I need to do.

Docker is really great for CI, for deployments, etc. I really like it, and i have spent a significant chunk of my career developing expertise in it. Its not something I would recommend locally unless you have no other choice, or you're running Linux and are able to use it natively.

I write Java mainly, not python, but I understand why python specifically might be easier with docker even though virtual env exists and works fine on Windows. To be clear, docker is a fantastic tool, and it has its use cases, but a local dev environment outside of Linux is a recipe for pain.

Every time I try to install it, I have to spend a bunch of time figuring out how to make it work, not to mention VPNs breaking it, and the tooling to run it changing every six months. The VM that it runs in on Docker desktop is largely undocumented, so you dont know how you can even log into it and troubleshoot, much less fix the issues that arise. This isn't a robust tool, this is a hodgepodge of technologies that are duct taped together into something that can work, but is extremely difficult to fix if it breaks.

I don't know why your experience is different, but don't assume that people don't know what they're doing when they say stuff like this. Just because it works on your machine doesn't mean it works on others. You can find lots of developers with similar experiences, it's not just me.

If you don't want to insult me, then believe what I'm saying rather than speculating about my abilities.

That matches my experience as well. Nothing kills a developers motivation like spending time dealing with and debugging weird failures on their dev environments as opposed to actually working on the things they care about.

The fact that you have to operate a VM on your machine in order to use it is a no go for me. Either use Linux as your OS in that case, or spend the time to make a dev environment that actually works. Even just mounting a directory is a painful exercise, and something that comes with performance limitations. I've had to deal with networking problems, drive problems, all sorts of issues that you really don't want to waste your time fixing when you have a deadline coming up.

Multiple levels of virtualization, meaning you have the containerization part which is virtualizing the userspace of the VM, and the virtualization of the VM itself. Your development environment consists of multiple layers of complex, not to mention fragile technologies which is an incredibly bad idea for something you rely on heavily for your day to day work.

The people I know who have to use it run a fully fledged Linux VM and do all their work on that. That is how bad the developer experience is on Windows.

Also I'm a bit insulted that you immediately assumed that I'm speaking from a lack of experience, as opposed to years of experience supporting docker dev environments on windows and failing to find a solution that doesn't come with severe drawbacks.

This works great, assuming you're using Linux. On Windows this kind of a setup is a nightmare to maintain, since if something goes wrong you have to troubleshoot through several layers of virtualization and weird OS integrations to understand what's happening. Venv is a much better solution for that.