| I stand by my statement! Compare the length of the C standard to JS / ECMAScript, or C++! :) Maaaaybe I'm hiding a tradeoff around complexity vs built-in features, but volunteers can work that out themselves later on. You honestly don't need much knowledge of C to get started in some areas. The ML GUI is easy to modify if you stay within the lines. Other areas, e.g., porting a complex feature to a new camera, are much harder. But that's the life of a reverse engineer. |
| Conversely, the terseness of the C standard also means there's many more footguns and undefined behaviors. There are many things C is, but being easy to pick up is not one of them. I loved C all the way up until I graduated uni, but it would be a very hard sell to get me to pick it for a project these days. To me, working with C is akin to working with assembly, you just feel that you're doing real programming, but realistically there's better options for most scenarios these days. |
| |
| ▲ | names_r_hard 6 days ago | parent | next [-] | | I agree with some of what you're saying; some of the well known risks of working in C are because it's a small standard. But much of the undefined behaviour was deliberately made that way to support the hardware of the time - it's hard to be cross-platform on different architectures as a low-level language. C genuinely is easy to pick up. It is harder to master. And you're right, for many domains, there are better options now, so it may not be worth while mastering it. Because it's an old language, what it lacks in built-in safety features, is provided by decades of very good surrounding tooling. You do of course need to learn that tooling, and choose to use it! In the context of Magic Lantern, C is the natural fit. We are working with very tight memory limitations, due to the OS. We support single core 200Mhz targets (ARMv5, no out-of-order or other fancy tricks). We don't include C stdlib, a small test binary can be < 1kB. Normal builds are around 400kB (this includes a full GUI, debug capabilities, all strings and assets, etc). Canon code is probably mostly C, some C++. We have to call their code directly (casting reverse engineered addresses to function pointers, basically). We don't know what safety guarantees their code makes, or what the API is. Most of our work is interacting with OS or hardware. So we wouldn't gain much by using a safe language for our half. | | |
| ▲ | chownie 6 days ago | parent [-] | | > C genuinely is easy to pick up. I feel like this is a bit of an https://xkcd.com/2501/ situation. C is considered easy to pick up for the average user posting HN comments because we have the benefit of years -- the average comp sci student, who has been exposed to Javascript and Python, who might not know what "pass by reference" even means... I'm not sure they're going to be considering C easy. | | |
| ▲ | names_r_hard 6 days ago | parent | next [-] | | I've taught several different languages to both 1st year uni students, and new joiners to a technical company, where they had no programming background. Honestly, C seems to be one of the easier languages to teach the basics of. It's certainly easier than Java or C++, which have many more concepts. C has some concepts that confuse the hell out of beginners, and it will let you shoot yourself in the foot very thoroughly with them (much more than say, Java). But you don't tend to encounter them till later on. I have never said getting good at C is easy. Just that it's easy to pick up. | | |
| ▲ | wkjagt 6 days ago | parent | next [-] | | C made a lot more sense to me after having done assembly (6502 in my case, but it probably doesn't matter). Things like passing a reference suddenly just made sense. | |
| ▲ | 6 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | F3nd0 6 days ago | parent | prev [-] | | I agree. For me as a beginner, C was relatively easy to learn the basics of. Sure, I never went on to get familiar with all the details and become proficient in it, but the basic concepts really aren’t that hard to understand. There’s just not too much you need to wrap your head around. |
| |
| ▲ | pixelmonkey 6 days ago | parent | prev | next [-] | | C is taught as the introduction to programming in CS50x, Harvard's wildly popular MOOC for teaching programming to first-year college students and lifelong learners via the internet. Using the clang toolchain gives you much better error messages than old versions of gcc used to give. And I bet AI/LLM/copilot tools are pretty good at C given how much F/OSS is written in C. Just to provide another data point here... that C is a little easier to pick up, today, than it was in the 1990s or 2000s, when all you had was the K&R C book and a Linux shell. I regularly recommend CS50x to newcomers to programming via a guide I wrote up as a GitHub gist. I took the CS50x course myself in 2020 (just to refresh my own memory of C after years of not using it that much), and it is very high quality. See this comment for more info: https://news.ycombinator.com/item?id=40690760 | |
| ▲ | jibal 6 days ago | parent | prev | next [-] | | Everything is passed by reference in Python. Everything is passed by value in C. | | | |
| ▲ | jcelerier 6 days ago | parent | prev [-] | | depends on which school you went? the one I've been to started with C and LISP in the 2010s and then moved on to C++ and java with some python |
|
| |
| ▲ | ptero 6 days ago | parent | prev [-] | | Undefined behaviors -- yes. But being able to trigger undefined behavior is not a huge foot gun by itself. Starting with good code examples means you are much less likely to trigger it. Having a good, logical description of supported features, with a warning that if you do unsupported stuff things may break, is much more important than trying to define every possible action in a predictable way. The latter approach often leads to explosion of spec volume and gives way more opportunities for writing bad code: predictable in execution, but instead with problems in design and logic which are harder to understand, maintain and fix. My 2c. |
|
