Learn C • Hacker News Board

Re: Learn C

#171

Post by pjscott » Mon, Jun 03, 2013, 9:56 PM UTC

Jabbles wrote: post #48

betterunix wrote: post #41

Earlier quoted context omitted.

"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.

That quote is always annoying, because it applies equally well to all criticisms of any programming language in active use, but not all criticisms are created equal. A useful heuristic would actually help distinguish between reasonable criticism and inevitable kvetching.

Re: Learn C

#172

Post by tracker1 » Mon, Jun 03, 2013, 10:08 PM UTC

sirclueless wrote: post #135

tracker1 wrote: post #104

Earlier quoted context omitted.

Using functional paradigm with immutable types does take care of a lot of the complexities of parallel computing... It allows you to make a lot of assumptions (from the underlying platform's perspective) and can break up work in very interesting ways, not just across cpu cores, but even in distributed computing environments. If you combine this with a scriptable language, you can even carry the workload with the code…

The kicker for me that makes me think that working too hard to make easily parallelizable constructs isn't worth it is that communication is expensive and single cores are actually pretty darn powerful on their own. The implication is that you don't want to be parallelizing at too low a level. You want to be doing it at a much higher level if you possibly can. If you have an 8-core machine and thirty independent task…

I think with the increasing availability of more, weaker CPUs with a decent thermal envelope, and efficient processors like ARM, then distributing work makes even more sense... in a SOA system, where a lot of processing may well be IO bound, why not break out the load even more... I think the future will be thousands of compute nodes/workers along with hundreds of service nodes handling millions of simultaneous requests.

Functional constructs make such scaling nearly effortless once the practical issues of breaking up work are handled. Yes, communications has a cost, but there are faster channels available than what are used... and distributing data persistence into redundant, sharded clusters can yield a lot of other benefits.

Given, most line of business applications are fine on current hardware... the problem is scaling to 10x or 100x the workload. You can do this by creating a system that can scale horizontally, or to be more performance oriented with current hardware. One solution gains you a single generation of increased output... another gets you N scale expansion.

I don't think it's just macro parallel tasks... but many-micro tasks that can work within such a system.

Re: Learn C

#173

Post by jasomill » Mon, Jun 03, 2013, 11:25 PM UTC

_pmf_ wrote: post #145

betterunix wrote: post #36

Earlier quoted context omitted.

"Reliability and security requirements are up to the developer to impose on any language" This is a common fallback in these discussions, but it is misguided. Yes, you have to work to make software secure in any language; no, this does not mean C is equivalent. In C, you still need to worry about high-level problems like SQL injection, while simultaneously having to worry about low-level problems like integer overflo…

> while simultaneously having to worry about low-level problems like integer overflows Integer overflows are exactly the same in Java and C# as they are in C.

No! Signed integer overflow in C/C++ is undefined. In other words, the language specifications permit implementations to do anything whatsoever[1]. This is emphatically not the case with either Java or C#. As an example, per the spec, with respect to C# integer multiplication,

In a checked context, if the product is outside the range of the result type, a System.OverflowException is thrown. In an unchecked context, overflows are not reported and any significant high-order bits outside the range of the result type are discarded.

In other words, while integer overflow isn't necessarily checked, unlike C/C++, C# isn't allowed to corrupt memory, violate runtime security guarantees, format your hard drive, threaten the President, or launch a video game[2] on integer overflow.

[1] http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

[2] http://feross.org/gcc-ownage/

Re: Learn C

#174

Post by peripetylabs » Tue, Jun 04, 2013, 1:42 AM UTC

There exist proof and verification tools for C, like ACSL and Frama-C, [1] or LCL and Splint. [2,3] Not to mention the myriad of static and dynamic analysis tools. You can prove that a piece of C code does or doesn't contain certain bugs -- this is not the case for higher-level languages (except perhaps Haskell and ML). That is why C is used for highly sensitive projects like avionics.

I would say: learn C and high-level languages.

[1] http://frama-c.com/acsl.html

[2] www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-74.pdf

[3] http://splint.org/

Re: Learn C

#175

Post by betterunix » Tue, Jun 04, 2013, 5:01 AM UTC

_pmf_ wrote: post #149

betterunix wrote: post #33

Earlier quoted context omitted.

I think the disagreement we have may stem from our notions of what constitutes "fundamental computing concepts." I rank the lambda calculus much higher than C or assembly language when it comes to that. I would say that knowing your data structures and how to analyze algorithms asymptotically is vastly more important than knowing how code is being executed at a low level. Even for the cases where low-level code must…

> I would say that knowing your data structures and how to analyze algorithms asymptotically is vastly more important than knowing how code is being executed at a low level. Except that most modern data structure research goes deep into cache awareness (i.e. structures that respect cache lines and algorithms that prevent cache misses and avoid pipeline stalling), which requires understanding of the hardware and the i…

Knowing your data structures does not mean being on the cutting edge of data structures research. It does mean knowing more than just vectors, lists, and hash tables. It means choosing the right data structures for your problem -- something that can have profound effects on performance, much more so than the cache.

Yes, people should know about the machine their code is running on, because when there are no asymptotic improvements to be made, constant factors start to matter. Right now, though, people tend to choose asymptotically suboptimal data structures and algorithms. Worrying about things like pipeline stalling when an algorithmic improvement is possible is basically the definition of premature optimization.

Re: Learn C

#176

Post by com2kid » Tue, Jun 04, 2013, 9:39 AM UTC

pjmlp wrote: post #138

com2kid wrote: post #54

Earlier quoted context omitted.

> There is no particularly good reason for C to be anywhere in the software stack; Really? Not anywhere? Who is handling your hardware interrupts? How is your keyboard and mouse input being handled? What about your video card drivers? Now I will grant that you can bootstrap an initial run time in assembly and place your favorite high level language4 on top of that, if you add extensions to your favorite language to b…

> LISP doesn't have built in support for doing a DMA copy from memory buffer to a USB port. Where in the ANSI/ISO C standard is this support described?

It doesn't (yet one example of why C isn't the best systems programming language), but the concepts of C (raw memory, pointers, flat buffers), map onto underlying concepts pretty clearly.

Now that said, a lot of other things (anything dealing with asynchronous programming) don't map onto C that well at all, and other languages do a much better job at solving some conceptual problems.

But that is why languages like LISP and Haskel are taught, so that even when one is stuck working in the C ghetto, higher level concepts and more abstract coding patterns can still be brought to bear to solve problems. :)

Re: Learn C

#177

Post by sigkill » Tue, Jun 04, 2013, 11:07 AM UTC

jmilkbal wrote: post #162

sigkill wrote: post #154

Earlier quoted context omitted.

Is Ada worth learning?

It's a very personal decision. :) You're not going to be popular on HN with a language like Ada. You're also probably not going to find a company looking for Ada developers, though I, myself, do Ada work for pay. The Ada way of doing things really is a whole other world with completely different goals in mind than what fanboys and fangirls (I'm using the term dismissively, but there are real problems with new languag…

Well, since I'm not an American nor living in the US, DoD jobs are out of the question.

Secondly, I am unable to grok functional programming, which is why I quit trying to learn Haskell. I tried, I really tried but there's no way I'm able to wrap my head around functional programming. In my mind, there's a long list with two digits in hex, that the computer iterates as fast as possible. So if Ada is a functional only language that puts the brakes right there. If no, I'd be more than happy to start learning.

Re: Learn C

#178

Post by aidenn0 » Tue, Jun 04, 2013, 3:52 PM UTC

kmm wrote: post #81

doktrin wrote: post #45

Earlier quoted context omitted.

> 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…

> 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? I was talking about the overhead of making the list of packages to update/install. Pretending to install a simple package takes 7 seconds. Pretending to update takes 13 seconds. That's a very long time, because I mig…

I'm pretty sure the 'emerge -pv' performance is IO bound and would not be significantly improved by writing it in C.

Re: Learn C

#179

Post by koffiezet » Tue, Jun 04, 2013, 4:48 PM UTC

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…

When I read "C code" in this thread - I assume people mean C and C++ together, since they're both capable of the same low-level stuff.

The thing is, the new compilers, static analysis, JIT'ing, ... available these days for C++ makes it the best time ever to write C++ in a reliable way, and being technology that is being used in the real world, this will only improve.

There's a reason the C++ language is undergoing a lot of changes nowadays, for the better. After years of no movement at all, C++11 finally arrived, supporting features improving general reliability and memory-management (single pointers, smart pointers, auto type, ...), and C++14 is on it's way. While old programs will still work, the core language evolves and so do the generally accepted standard/best practices, that when generally accepted provide very reliable code.

I work on quite a large C++ code-base, and both our test-team and static analysis tools rarely find "programming errors". Functional bugs - sure, you still have those like you have in any program, but real end-of-the-world memory corruptions or leaks are rare to completely absent. The only tricky part I guess is threading, although analysis tools have massively improved here - and this is an issue in pretty much every language that understands threads.

The nice thing about learning C is that you get to understand what exactly is happening, and while a functional language like Haskell is very cool and can in certain situations offer massive optimizations due to it's language and runtime design, it presents you with a non-existing world. C is an "easy" way to understand low-level for as far as it's useful. I fooled around with a lot of languages, including Haskell - and knowing C gives you a much better insight in what the runtime is actually doing, because you KNOW a CPU doesn't work like that, and you're able to quickly understand it's limitations and advantages.

Another way to understand what happens +- on CPU level is implementing a simple bytecode compiler and interpreter - in any language of your choosing, but for some reason, most "real world" interpreters are implemented in C/C++.

Re: Learn C

#180

Post by pjmlp » Tue, Jun 04, 2013, 5:07 PM UTC

com2kid wrote: post #176

pjmlp wrote: post #138

Earlier quoted context omitted.

> LISP doesn't have built in support for doing a DMA copy from memory buffer to a USB port. Where in the ANSI/ISO C standard is this support described?

It doesn't (yet one example of why C isn't the best systems programming language), but the concepts of C (raw memory, pointers, flat buffers), map onto underlying concepts pretty clearly. Now that said, a lot of other things (anything dealing with asynchronous programming) don't map onto C that well at all, and other languages do a much better job at solving some conceptual problems. But that is why languages like LI…

Raw memory, pointers, flat buffers exist in almost every systems program language, even strong typed ones.

My point was that what many developers think what are C features for systems programming, are in fact language extensions that most vendors happen to implement.

In this regard, the language is no better than any other that also requires extensions for the same purposes.