Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn C

medium.com

Post reply on HN
Print view View original

41–50 of 182 posts

Re: Learn C

#41

Post by betterunix »

kmm wrote: post #21
betterunix wrote: post #9

We need less code written in C, not more. We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code that is hard to escape; writing more software in C makes that problem worse. Most software is written to solve high-level problems. Using a high-level language is sensible, time-saving, budget-saving, improves portability, and saves on headaches later. The same rule that applies to COBOL…

Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++. The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software. In fact, give me a single big desktop…

"I know for a fact practically every piece software I use is programmed in either C or C++."

How confident are you that that software will work as expected? How much are you willing to bet?

The fact that a language is popular does not prove that the language is good, nor that it should be used, nor that it is not causing us problems. Just the other day on HN, there was an article about a massive number of vulnerabilities in X11 applications -- all resulting from problems that you have in C and C++ but not in higher-level languages. Entire classes of bugs that are common problems in C are just not an issue in other languages.

Sure, it is possible to write unreliable code in high-level languages. It is just a lot easier to write unreliable C code, and C programmers are much more likely to do so (even those with years of experience).

Re: Learn C

#42

Post by cthackers »

doktrin wrote: post #39
cthackers wrote: post #29

Earlier quoted context omitted.

There is a difference. The difference between someone who works as a programmer, who takes it just as a job but of course can be extremely good at it - just like anything else you practice a lot; and someone who is a programmer. They are lexically the same but they mean different things. The last one, beside working (or not) as a programmer, does it for the art of it. Who not necessarily learns or does something (shi…

That's hazy territory. While I understand what you're trying to get across, there's really no point adding layers of hidden meaning and subjectivity to the term "programmer". (non-software) engineers, lawyers, graphic designers, accountants, chemists, doctors define themselves by occupation and not some subjective non-metric of passion. Why exactly should programming be different? I'm not arguing that programmers sho…

Because we're talking about programming here. If we were talking about music for example, the same will apply. There are singers and there are artists and there is a clear difference in a song well made and a commercial song. Even if the last one makes you more money. But for programmers there's just that one term to use. So the need to point the hidden meanings.

Re: Learn C

#43

Post by asveikau »

> You’ll realize that Object Orientation is not the only way to architect software.

Actually, pretty much all the "good" C code I've seen is using some form of object orientation, for example using structs with function pointers, or information hiding through incomplete types and void pointers. I think the better observation is that you don't need much language support to do mostly-OOP.

That and a lot of people in those "other" languages are using language support for OOP as a bit of a mental crutch. (For example, many people working in Java or C# especially tend to write lots of indecipherable OO spaghetti.)

Re: Learn C

#44

Post by irahul »

habitue wrote: post #30
danso wrote: post #23

For anyone who hasn't browsed through Peter Seibel's "Coders at Work," one of his subjects is Fran Allen...it's kind of funny because I do agree that learning C has been valuable to the high-level programming I do today (but only because I was forced to learn it in school). But there's always another level below you that can be valuable...Allen says C killed her interest in programming...not because it was hard, but…

I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization, and JIT VMs pushing forward in other directions. It's actually an exciting time for "smart compilers".

> I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization

C compilers were optimizing long before Haskell. From her interview, I don't understand why she couldn't work on optimizers even if someone else advocated optimization being programmer's repsonsibility?

Re: Learn C

#45

Post by doktrin »

kmm wrote: post #21
betterunix wrote: post #9

We need less code written in C, not more. We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code that is hard to escape; writing more software in C makes that problem worse. Most software is written to solve high-level problems. Using a high-level language is sensible, time-saving, budget-saving, improves portability, and saves on headaches later. The same rule that applies to COBOL…

Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++. The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software. In fact, give me a single big desktop…

> And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound)

I was under the impression portage was "slow" (relative to other package management tools) due to the fact that it built everything from source (for which it uses make). Where is the Python bottleneck?

> In fact, give me a single big desktop software project made with a language that is not C or C++.

What constitutes "big"? There are a few large desktop projects that run on the JVM, for instance.

Re: Learn C

#46

Post by irahul »

mbel wrote: post #11
andrewvc wrote: post #4

This is a fair point, but it brings to mind another point I didn't really understand till the last couple of years. Learning about how compilers work is just as important. Building a small lisp compiler was a life-changing experience for me in terms of going one level deeper, as much as understanding C was. For those who've never written lisp before, the reason I recommend a lisp compiler is that lisp compilers are t…

I totally agree; actually a small, incomplete Scheme interpreter (which may be used to develop a lisp compiler later on) can be easily created in few hours (depending on used language) [0], without any prior experience. It's surely not as deep learning experience as building a compiler, but I think it's still worthwhile. [0] http://norvig.com/lispy.html

A more complete interpreter:

http://norvig.com/lispy2.html

Re: Learn C

#47

Post by pjmlp »

betterunix wrote: post #9

We need less code written in C, not more. We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code that is hard to escape; writing more software in C makes that problem worse. Most software is written to solve high-level problems. Using a high-level language is sensible, time-saving, budget-saving, improves portability, and saves on headaches later. The same rule that applies to COBOL…

As a Turbo Pascal refugee, I agree 100%

Re: Learn C

#48

Post by Jabbles »

betterunix wrote: post #41
kmm wrote: post #21

Earlier quoted context omitted.

Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++. The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software. In fact, give me a single big desktop…

"I know for a fact practically every piece software I use is programmed in either C or C++." How confident are you that that software will work as expected? How much are you willing to bet? The fact that a language is popular does not prove that the language is good, nor that it should be used, nor that it is not causing us problems. Just the other day on HN, there was an article about a massive number of vulnerabili…

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

Bjarne Stroustrup

http://www.stroustrup.com/bs_faq.html#really-say-that

Of course, that just dismisses the criticism of the language. But to say that it "should [not] be used" ignores the current landscape of engineers, employers and problems.

Re: Learn C

#49

Post by doktrin »

cthackers wrote: post #42
doktrin wrote: post #39

Earlier quoted context omitted.

That's hazy territory. While I understand what you're trying to get across, there's really no point adding layers of hidden meaning and subjectivity to the term "programmer". (non-software) engineers, lawyers, graphic designers, accountants, chemists, doctors define themselves by occupation and not some subjective non-metric of passion. Why exactly should programming be different? I'm not arguing that programmers sho…

Because we're talking about programming here. If we were talking about music for example, the same will apply. There are singers and there are artists and there is a clear difference in a song well made and a commercial song. Even if the last one makes you more money. But for programmers there's just that one term to use. So the need to point the hidden meanings.

There are no "hidden meanings". You're making them up.

edit :

Words, like functions, work best when their meaning is simple and clear. Like functions, there's nothing wrong with combining them (e.g. "good programmer", "passionate programmer", "programming craftsman", "software composer"), but shoehorning multiple definitions into a single word will just inevitably lead to confusion.

Re: Learn C

#50

Post by pjmlp »

Please don't.

Learn Delphi, Free Pascal, Modula-2, Ada, Oberon(-2),... and see how it is possible to have down to the metal strong typed languages with native compilers.

Then understand that C and C++ ubiquity is an historical accident due to the way UNIX spread across the industry.

Post reply on HN