Live data from Hacker News

Learn C

medium.com

141–150 of 182 posts

Re: Learn C

#141
post #98
post #84

Earlier quoted context omitted.

The parent poster asked for desktop software written in languages besides C or C++ without any reference of hybrid applications or timeframe when they were written. Since when desktop operating systems are not desktop applications? I can provide other examples, but most likely I will get extra requirements along the way, so why bother... After all, you can always use the argument that any application needs to call C…

What a victim complex. If someone is debating that we should stop using C, and I ask for software not written in C, it's obvious that I'm looking for contemporary software. And the reasoning that every software is "C" because it needs to do system/library calls would be ludicrous, and to provisionally accusing me of that is insulting. I've done some research myself, and there are some interesting and big projects in…

My impression is that desktop software is/was largely written in C/C++/C#/Objective C/Objective C++ because those are the languages to which the Operating Systems of today expose their APIs. For example Win32 = C/C++, Cocoa = Objective C, Metro = C# (or I guess anything compiled to the Common Intermediate Language (CIL)???).

Now that said, most languages provide a bridging layer that allows them to call out to those "native" APIs. These are used to enable API ?wrappers?, however due to these being provided by third parties (I believe) there has been a tendency to gravitate toward the "blessed" language of the OS vendor.

One of the big advantages of Java (to me at least) was that it provided a platform independent windowing capability inbuilt within the JDK that has been maintained by Sun/Oracle/(and Apple) as new operating system revisions were released.

Note, for example, that C/C++/Objective-C/Objective-C++ programs aren't/weren't allowed in the Mac App Store (I'm not sure if this is still the case...). (Personally I ported a Java App to Objective C++ due to this.)

But generally I agree with your point that this isn't the only reason why C was so pervasively used. However, you also need to consider that a large number of programming environments and tools were specifically developed to aid C/C++ programmers, e.g. Borland C++, Visual C++, Code Warrior, XCode. It's also worth remembering that the GNU C Compiler and Debugger were import contributions to free software back in the day.

But also consider distribution of compilers etc. I think it is pretty fair to say that a lot of programmers learnt to program using Borland Pascal/C++ because at that point the Internet was not as accessible as today and copies of these could be "obtained".

The advent of Internet has not only allowed the distribution of compilers and environments for other programming languages, it has also meant that the languages used for backend systems, i.e. web servers and web applications, is irrelevant to the user's web browser.

Anecdotally, for safety-critical system software an issue with some languages other than C is that they have not been suitable for real-time systems. I don't know much about this other than that exception handling and also garbage collection can cause issues due to their non-determinism.

I fear that you'll think that the above is a bit too much like saying "all software is 'C' because it needs to do system/library calls", however I think it's probably fairer to say "all software is 'C' because many people have really, really liked it" and "better the devil you know".

Re: Learn C

#142
post #136

Earlier quoted context omitted.

Accident? C did exactly what it was designed to do; allow UNIX to spread to other architectures.

Any high level language would do it in a time and age where most OS were still 100% coded in Assembly. Lets say UNIX used PL/I or Algol 68, the article would be called "Learn PL/I" or "Learn Algol 68".

I can't say you couldn't have written UNIX in Algol 68, but C was very specifically developed by K&R for building the underpinnings of UNIX. They didn't just "pick" C out of a pool of available languages- C was made for UNIX.

(This is probably a gross oversimplification- please don't hang me out to dry for it- but it summarizes my understanding of the origins of C)

Re: Learn C

#143
post #59
post #3

You'll learn to feel every line of code you write This is exactly how I felt when I started writing C. I started out with .NET and Java. Both had quite high abstraction levels, and not much deep integration with hardware. I took my control statements, conditionals, and high-level object-based programming for granted -- I never WANTED to learn C. I took one look at K&R and was turned off by the insane amount of low-le…

A small part of C was beaten into us for 2 years at the 11th and 12th grade. Today (I'm not a CS guy by the way), even when I write programs in python or any high level language I have this nagging feeling of 'loss of control' and that the code is not efficient enough. I know this is wrong but I can't help this feeling when now things are handed to you as compared to flipping every figurative bit in C.

It is right not wrong. Being decoupled from the machine by several layers of abstraction means you're just rearranging the furniture rather than whittling it out of wood.

I hate rearranging the furniture; it gives no satisfaction.

Satisfaction is a big part of quality in your life.

Re: Learn C

#144

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…

C is easy to get right. Its also easy to get wrong.

To be honest, most holes I've seen over the years are above the level of the language and are down to the implementation or design being flawed. For example SQL injection, silly business processes, elevation flaws, bad maths etc.

Re: Learn C

#145
post #34

Earlier quoted context omitted.

> We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code A ton of the world's software with the highest reliability requirements is written in C and C++. Nuclear power plants? Yes. [1] Joint Strike Fighter? Yes. [2] Mars rover? Yes. [3] Your Tesla? Yes [4] US telephone systems. Stock exchanges. Bloomberg. Your cell phone OS (incl. many years before smartphones). The list goes on and…

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

Re: Learn C

#146
post #136

Earlier quoted context omitted.

Any high level language would do it in a time and age where most OS were still 100% coded in Assembly. Lets say UNIX used PL/I or Algol 68, the article would be called "Learn PL/I" or "Learn Algol 68".

I can't say you couldn't have written UNIX in Algol 68, but C was very specifically developed by K&R for building the underpinnings of UNIX. They didn't just "pick" C out of a pool of available languages- C was made for UNIX. (This is probably a gross oversimplification- please don't hang me out to dry for it- but it summarizes my understanding of the origins of C)

C was made with UNIX, not for, mostly because the authors did not like to use other available languages.

There is hardly any feature in the language that makes it better than other higher level languages for systems programming.

Please note that I am older than C, for me higher level language is anything higher than Assembly.

Re: Learn C

#147
post #146

Earlier quoted context omitted.

I can't say you couldn't have written UNIX in Algol 68, but C was very specifically developed by K&R for building the underpinnings of UNIX. They didn't just "pick" C out of a pool of available languages- C was made for UNIX. (This is probably a gross oversimplification- please don't hang me out to dry for it- but it summarizes my understanding of the origins of C)

C was made with UNIX, not for, mostly because the authors did not like to use other available languages. There is hardly any feature in the language that makes it better than other higher level languages for systems programming. Please note that I am older than C, for me higher level language is anything higher than Assembly.

I suppose I'm descending to semantics and quibbling over meaningless details at this point, but I was just taking issue with the idea that C wound up in its current position on accident. It was not by chance that C makes up the underpinnings of UNIX, nor did (to my knowledge) the spread of UNIX have much to do with chance.

I don't mean to contend there are no other languages that could have been used.

Re: Learn C

#148
Very interesting thread. I moved to SV a year ago and my perspective on how modern programmers think has changed enormously.

As a background, I am a software engineer on route to being a cpu architect. My job is to understand how hardware works and what changes need to go into the instruction set to allow modern software work better. I have some thoughts to share.

I also think that a lot of folks in HN are true software engineers with little hardware background. So, most arguments simply gloss over why (or why not) use C.

Let us all be very clear. C is not a great language for app development. This comes from a person who has worked his entire life with C. I have no qualms in saying this.

C is primarily just an abstraction over assembly (not the same as machine). With this in mind, you can safely assume C to be a "stateful" language. By "stateful" I mean, each statement gets "executed" and the state of the CPU and memory changes. The fact that multiple assembly instructions can get produced per-line of C is what makes it better than lower languages.

That is all that is there in C. Everything else is an add-on. The standard library functions (strlen(), printf() etc.) are all essentially a few assembly instructions clubbed together.

Now, as it turns out, oop and other paradigms were created for the sole purpose of making it easy to program. In other words, we want to lower the barrier of entry into programming and have more programmers do things that they would normally never be able to do. We were ready to take a performance penalty with higher level languages so that more people can make useful stuff with a computer.

For example, oop was made to create the illusion that a program really is objects interacting with each other or functional execution. However, folks well versed with the computer know that oop is eventually executed sequentially.

The whole eco-system of web and app developers is able to thrive because they do not have to deal with 'nasty' (I personally find them amazing) issues of why things work the way they do. Let's just say that programming is becoming commoditized and the barrier to programming is made lower by them not having to deal with these issues. If we were still programming in C, most programmers would have dropped out of their CS classes when they were freshmen.

An analogy would be you don't need to understand the internals of a combustion engine to drive a car.

So, should everyone learn C? As someone who cares about expanding the powers of a computer, I do not think wasting resources on it is worthwhile. There are enough people maintaining C and using it for great purposes. Commodity programming (application level) should not involve C as far as possible. Cpus are fast enough to handle bloatware languages. I would personally prefer people thinking of newer languages/paradigms that would expand on what people can do with a computer.

As a programmer, you do not need to learn it. It is certainly helpful and I would definitely encourage folks to try to understand it, if you are curious. But no point wasting your time on it if all you are going to do is application level development.

Now, if you are working on something really deep and involved, the story changes completely. For example, folks working on router/switch programs, fast search engines, OS, devices, simulations (basically everything cool in my biased mind) need to understand it.

An analogy is that an you do not need to understand nitty-gritty details about engines unless you are building something in the range of a Ferrari.

Just my thoughts.

Re: Learn C

#149

Earlier quoted context omitted.

My point is there are fundamental computing concepts that you can pick up by learning C. In a world of high-level, low-LOC languages you can get by without learning those concepts, but it serves your and the ecosystem's best interest to learn them.

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 instruction set.

Knowing your Big-O-stuff is a prerequisite for modern algorithm design; it does not take you anywhere new, though.

Re: Learn C

#150
post #79

Earlier quoted context omitted.

Well probably... but no one said anything about bootstrapping being a requirement.

The LiSP book only describes self-hosting implementations while in Forth it's heresy to implement it in anything else than Forth or assembly. Well, perhaps Java implementations are excused for not being implemented in terms of themselves. :-)

It's been done: http://jikesrvm.org/

Historically, the performance was pretty decent. I don't know how it stacks up against Hotspot today, but I note it does still seem to be a live project after >10 years.

Post reply on HN