31–40 of 81 posts
As a web developer, who mostly spends time with Go and Python, is there any benefits of learning C?
-Embedded/cyber-physical systems software (firmware dev)
-Driver development (applies to Win/macOS/UNIX/iOS/Android)
-Contributing to the Linux kernel/OS dev in general
-Contributing to many large OSS projects (Apache, ffmpeg)
-Exploit/malware dev/reverse engineering
-Emulator development
you'd need to learn C.
As a web developer, who mostly spends time with Go and Python, is there any benefits of learning C?
These are things that are not directly useful, but help you have a better mental model of how your language of choice actually works.
Earlier quoted context omitted.
I wish we could talk about style in objective terms, not just opinion. Opinions are kinda stupid. Here's my opinion: https://news.ycombinator.com/item?id=26790701 (actually that's just a faux opinion to make a point, but you get the point) And if there are no objective facts, then maybe we could just stop calling other peoples' preferred style nasty and "bad habits" as if it were objective.
More difficult to read, more difficult to edit, but the worst thing is how difficult it makes diffing code. You should try using some kind of code versioning, git is a popular choice.
Subjective, and I do not find it more difficult to read. On the contrary, I often find shorter and denser expressions (especially around obligatory fluff that doesn't actually do much) to improve readability and make it easier to focus on the interesting part.
> more difficult to edit
Subjective, and I do not find it more difficult to edit.
In general, as long as you're not using a magnetized needle as your editor, creating new declarations or moving declarators around shouldn't be a challenge. It is trivial.
Nevertheless, if we want to consider the relative difficulty of various trivial edits, it can go both ways as far as multiple declarators per line are concerned. It can be easier to edit when you have a set of related variables and you need to change the type once. If you split them on a bunch of lines, you need to remember to change every line, which is more work and larger diffs. Oh the horror...
> but the worst thing is how difficult it makes diffing code.
I agree that it can make diffs a little harder to read but I have not found that to be a big issue in practice (having worked on both styles of code professionally and as a hobby for more than two decades).
If diffs were such a major concern, then we probably should adopt an assembly-style syntax with one instruction per line and no nested indentation. That would keep lines inherently short, so you don't have to locate and read the small change on a longer line. And you'd never have to pick small changes from a large hunk that is large mainly due to changed indentation. (At this point, I'd like to make a point about how splitting everything to more and more lines isn't always good for readability but I think I made that point already.)
By the way, you might wanna try out one of these modern diff tools that can hilight the actual change on a diff line.
> You should try using some kind of code versioning, git is a popular choice.
I can assure you that "multiple variables per declaration" have never been a problem for me with git. Coincidentally, the source code of git itself does have multiple declarations per line so looks like it wasn't a big problem for the authors of git either. (Obligatory example: https://github.com/git/git/blob/89b43f80a514aee58b662ad606e6...)
Oh man, multiple declaration on the single of code is nasty. Passing this kind of advice causes the beginners to develop bad habits. At least these are not uninitialised variables. // Shorthands for multiple declarations: int i1 = 1, i2 = 2; float f1 = 1.0, f2 = 2.0; int b, c; b = c = 0; Edited:.. After 1hr of posting my original comment, I noticed that there many opinions here. I should have added why I think this i…
C has been around long enough to develop multiple competing paradigms for how to format source code, each with copious existence proofs that "Good Code" can be written in them. Conform to what you're maintaining, don't start fights.
Earlier quoted context omitted.
More difficult to read, more difficult to edit, but the worst thing is how difficult it makes diffing code. You should try using some kind of code versioning, git is a popular choice.
> More difficult to read Subjective, and I do not find it more difficult to read. On the contrary, I often find shorter and denser expressions (especially around obligatory fluff that doesn't actually do much) to improve readability and make it easier to focus on the interesting part. > more difficult to edit Subjective, and I do not find it more difficult to edit. In general, as long as you're not using a magnetized…
I shouldn't be surprised, of course you're also the kind of person who writes terribly long lines of code. We have ultra-wide screens nowadays, better put them to good use.
Anyways, you might think you're making a point by repeating "it's all opinions", but that doesn't mean your single opinion is equal to everyone else. And on the subject of one vs multiple declarations, you're overwhelmingly in the minority.
Having self learned C devs do a big, complex program is an invitation for security vulnerabilities.
Most of the time people find themselves fighting against the language, and struggling to have the program simply not to crash.
If you see that, you start to think how much those guys would have time left to ensure anything like input sanitation, or code hardening in general.
C is easy to learn, but very hard to master. Having self learned C devs do a big, complex program is an invitation for security vulnerabilities. Most of the time people find themselves fighting against the language, and struggling to have the program simply not to crash. If you see that, you start to think how much those guys would have time left to ensure anything like input sanitation, or code hardening in general.
> Ah, C. Still the language of modern high-performance computing. Yet its major compilers are written in C++ nowadays, and C++ is the main language for GPGPU computing, including the memory model used by NVidia on their cards. I suggest some benchmarks updates to the author.
For practical purposes, it is C.