It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).
I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.
It may well be. Books have tons of useful expository material that you may not find in docs. A library has related books sitting in close proximity to one another. I don't know how many times I've gone to a library looking for one thing but ended up finding something much more interesting. Or to just go to the library with no end goal in mind...
Speaking as a junior, I’m happy to do this on my own (and do!).
Conversations like this are always well intentioned and friction truly is super useful to learning. But the ‘…’ in these conversations seems to always be implicating that we should inject friction.
There’s no need. I have peers who aren’t interested in learning at all. Adding friction to their process doesn’t force them to learn. Meanwhile adding friction to the process of my buddies who are avidly researching just sucks.
If your junior isn’t learning it likely has more to do with them just not being interested (which, hey, I get it) than some flaw in your process.
Start asking prospective hires what their favorite books are. It’s the easiest way to find folks who care.
I’ll also make the observation that the extra time spent is very valuable if your objective solely is learning, but often the Business™ needs require something working ASAP
It's not that friction is always good for learning either though. If you ever prepared course materials, you know that it's important to reduce friction in the irrelevant parts, so that students don't get distracted and demotivated and time and energy is spent on what they need to learn.
So in principle Gen AI could accelerate learning with deliberate use, but it's hard for the instructor to guide that, especially for less motivated students
I admire your attitude and the clarity of your thought.
It’s not as if today’s juniors won’t have their own hairy situations to struggle through, and I bet those struggles will be where they learn too. The problem space will present struggles enough: where’s the virtue in imposing them artificially?
Disagree, actually. Having spent a lot of time publishing papers in those very journals, I can tell you that just browsing a journal is much less conducive to discovering a new area to dive into than going to a library and reading a book. IME, books tend to synthesize and collect important results and present them in an understandable (pedagogical?!) way that most journals do not, especially considering that many papers (nowadays) are written primarily to build people's tenure packets and secure grant funding. Older papers aren't quite so bad this way (say, pre-2000).
I've done professional ghostreading for published nonfiction authors. Many such titles are literally a synthesis of x-number of published papers and books. It is all an industry of sorts.
> It may well be. Books have tons of useful expository material that you may not find in docs
Books often have the "scam trap" where highly-regarded/praised books are often only useful if you are already familiar with the topic.
For example: i fell for the scam of buying "Advanced Programming in the unix environment" and a lot of concept are only shown but not explained. Wasted money, really. It's one of those book i regret not pirating before buying, really.
At the end of the day, watching some youtube video and then referencing the OS-specific manpage is worth much more than reading that book.
I suspect the case to be the same for other "highly-praised" books as well.
I had a completely different response reading the sentence. I've been programming in C for 20+ years and am very familiar with exactly the problem the author is discussing. When they referred to a "static variable", I understood immediately that they meant a file static variable private to the translation unit. Didn't feel contrived or made up to me at all; just a reflection of the author's expertise. Precision of language.
I used to very down on C++ but have stopped caring quite so much... Just using C++ and restricting oneself to templates seems like a better bet than this. Or you could use D and have a language whose template experience is much better than C++'s...
Any language this is going to need debug info eventually. One could step through the generated C code, but this is much less pleasant than stepping through the original source.
For me, it was just to have some fun seeing whether you can get the convenience of generics in C without blowing up the size of a "minimal standards-compliant compiler." E.g., Chibicc[1] is only a few thousand lines of code; adding Gamma to that would not blow it up by much. There's something aesthetically pleasing about knowing I can read the whole thing in a few days. Nothing like that is possible for C++ (or D?) AFAIK.
But yes --- for a real project I would absolutely recommend someone use D over this !
Networking involves more than just letting people know you exist. I'd say that's borderline useless. Actually networking requires building real relationships with people. For me, that means continually meeting new people who do the same kind of thing that I do, having pleasant or exciting conversations with them, learning as much as I can about them (showing a real interest! asking serious questions! listening to their answers!), and demonstrating to them that I'm hungry and I want to do Big Things. It's hard to do this effectively. I'm sure it depends on your field and it certainly requires continual practice.
In general, going to a single networking event with the purpose of networking is kind of silly, but going to the same conference year after year to see the same people and have deep discussions opens a lot of doors. I imagine the point of "networking events" in general is to be a modern take on a country club: You go to see like-minded people who want to meet people like them, and you keep going over and over again to develop relationships.
> Actually networking requires building real relationships with people.
Yes! I'm sorry, I didn't mean to imply that letting folks know you exist was sufficient; it is only necessary.
I find a cheat code to building relationships with people is to give first. I love to ask "how can I help" when I meet someone at a conference or networking event. This does a few things:
* separates you from so many other people who go to these events looking to be transactional
* shows you can follow through (when you actually do help them) which, somewhat shockingly, distinguishes you from many other folks
* filters folks that might not be a fit for a deep relationship because you move in different worlds; if someone asks "well, I am looking for a major piece of real estate to buy", I as a software developer am unlikely to be able to help them
This book provides a high level overview of many methods without (on a quick skim) really hinting at the practical usage. Basically this reads as a encyclopedia to me, whereas Nocedal and Wright is more of an introductory graduate course going into significantly more detail on a smaller selection of algorithms (generally those that are more commonly used).
Picking on what I'd consider one of the major workhorse methods of continous constrained optimization, Interior Point Methods get a 2-3 page super high level summary in this book. Nocedal and Wright give an entire chapter on the topic (~25 pages) (which of course still is probably insufficient detail to implement anything like a competitive solver).
Alg4Opt covers more topics, providing the motivation behind the algorithm, sometimes a basic derivation, and a concrete implementation. It has citations in the margin for more info.
Nocedal and Wright will go more in-depth on derivation, proving theorems, etc. Implementations are pseudocode, and fewer topics are covered.
It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).
I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.
reply