Going against the grain here, but personally as I've gotten more experience and worked in larger code bases I've completely reversed my habit of breaking functions up into smaller functions to supposedly make them easier to understand.
I think this is a great point that most people forget. If you build something specifically for editing code you can do something cooler than vim/emacs and I've been working on that specific idea: https://youtu.be/owuuFxDBQh4?si=tqYi-RqvFQa6kI8h
A vscode extension that aims to be "vim for code' meaning that it has first class motions for programming concepts like functions, arguments, etc. quick demo:
In theory it should work for many languages with minimal support. In practice I've done some testing with typescript, Rust and Go and it largely works.
I'm working on something similar (not as far along), a vscode extension that has ideas like functions, parameters, etc as first class ideas (so press f to select a function) and also does things like adding a newline and a space where appropriate during insert actions.
The only argument I can think of against this would be that it would maybe slightly discourage adding the verbose details and would generally decrease the quality of error messages slightly. That said, even so it's probably worth the trade.
Errors are composable so this isn't such a problem in practice. Most of the prod code I wrote would do something like this
use thiserror::Error;
#[derive(Error, Debug)]
enum Error {
#[error("Could not open given decomp file: {0}")]
FileOpen(#[from] std:io::Error),
#[error("Compressed read error: {0}")]
CompressedRead(#[from] gz::Error)
}
fn decomp(filename: &Path) -> Result<Vec<u8>, Error> {
let fd = File::open(filename)?; // File is automatically closed by its destructor.
let zd = GzDecoder::new(fd); // flate2::read::GzDecoder::new does not return an error.
let mut data = Vec::new(); // Rust makes the caller allocate the buffer for reads.
zd.read_to_end(&mut data)?;
Ok(data)
}
Huh, can you explain that a bit more for a rust noob like myself?
1. How does it know how to create your Error enum? I guess it's from the #[from]?
2. What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
3. How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
> How does it know how to create your Error enum? I guess it's from the #[from]? 2.
#[from] is just a convenience library feature, in reality it’s because of the From conversion trait which ? invokes on the way out. Essentially it calls ReturnType::from(ValueType) to bridge the two.
> What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
If there is no available conversion to the return error type, compilation fails.
> How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
That is an option, although the slightly sad truth is libraries usually have a single big error type and every function returns that.
Convenient fine grained errors in rust remains unsolved, as far as I know. You can do it but it’s a lot of manual work.
It's worth considering that in the networking example given you discover the skills you need via a project and then argue that the skills could be learned more effectively through deliberate practice.
I think this post largely argues against a strawman (which I'm sure some people actually believe).
Seems fairly clear to me that you should (1) do projects that resemble the work you're trying to improve to:
a. Build up the basics across all the skills you need
b. Uncover gaps
And (2) then practice the skills you actually care to improve outside of the project.
If you really want to try-hard you can spend time actively thinking about how to improve what you're doing and observe other people to learn from them.
People who advocate project-based learning have generally experienced spending a ton of time learning things in theory and then being unprepared for actual work. Maybe address that concern instead of bypassing it with "I don’t want to debate the current way universities do things." To have a nuanced take you have to understand the arguments in favor and against the main options, no?
I don't think people who advocate for project-based learning are advocating for exclusively project-based learning (mostly).
It's definitely a mix. I have clear memories of some of my project-based courses/labs from school and would have had a poorer education for them not being part of the curriculum. But I also think it wouldn't be a very good curriculum (and presumably not an accredited one) if I mostly didn't do much beyond hacking around in machine shops and labs.
We're building Dash Enterprise, a web app that lets data scientists quickly and easily spin up and scale data science and ML apps. We do this using Kubernetes. Cool, right?
Reasons to join:
* Cool technologies like Kafka, Kubernetes, NestJS, and CockroachDB.
* Good pay (well above market).
* You'll spend 60-90% of your day programming.
* You won't work overtime.
* Plotly is a major supporter of open source (plotly.js and dash).
* Customers like Tesla, Shell, Cisco, and Nvidia.
* All the cool parts of working at a startup. Autonomy, impact, moving quickly.
* Dedicated time to learn every day (part of your 8 hours).
* New codebase!
What we're looking for:
Experience: 5+ years developing software. Strong with Node.js. Ideally familiar with NestJS, GraphQL, Kafka, Kubernetes, and/or event-driven architecture.
Table stakes: Familiar with git, pull requests, SQL, API design, automated testing, and writing clean/maintainable code.
Personality: You should be self-directed, comfortable diving into something you don't fully understand, friendly, and deeply care about doing a good job.
