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

131–140 of 182 posts

Re: Learn C

#131

Post by simonster »

kmm wrote: post #121
Teckla wrote: post #115

Earlier quoted context omitted.

In fact, give me a single big desktop software project made with a language that is not C or C++. I find your requirements odd and vague (why big? why desktop?), but speaking just for myself: Eclipse, jEdit, CyberDuck -- all written in Java. I use plenty of applications written in C and C++ too, of course; but I think that's largely due to (1) inertia in the application development industry, and (2) it took a while f…

My parent's post said C was bad and software shouldn't be written in it. So I retort by talking about desktop software because this is an area where C and C++ rule supreme. I specified big because big software projects carry more merit. A calculator written in your favourite language might be pretty handy, but it doesn't show your language can be used for real software. I use some Python scripts, but I don't see it i…

Google Chrome is based on WebKit, which was based on KHTML, which has been around since 1998. Moreover, Chrome depends on system and external libraries that provide C/C++ headers. Any viable alternative would need to work with C/C++ headers without needing large amounts of glue code, which isn't necessarily easy.

People still use C not because all of their code is so performance-sensitive that they can't deal with the overhead of bounds checks and garbage collection, but because there still aren't reasonably high-performance alternatives can easily integrate with existing codebases. Go and Rust are two promising contenders in this regard, but the former has only recently achieved C-level performance, and the latter is still not ready for production use. With that said, Mozilla is writing a browser in Rust (Servo), which shows their aspirations.

Re: Learn C

#132

Post by simonster »

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…

A major part of Firefox (hundreds of KLOC) is written in JavaScript. While the layout and network code is all C++, most parts that aren't performance-critical and don't need to interact directly with the OS are JS. This includes all of the high-level UI code.

Re: Learn C

#133

Post by btilly »

asveikau wrote: post #77
btilly wrote: post #72

Earlier quoted context omitted.

In my experience, people who like to use the preprocessor come up with very non-OO abstractions. Similarly people who program heavily using templates in C++ tend not to use a lot of the OO features there either. I may be more aware of this than you because my design sensibilities by nature are not particularly OO. This is not to say that I can't produce and understand OO designs. I both can and do, particularly if I…

I guess I don't see a strong distinction (or see them on the same axis) because I like the preprocessor and use it when I feel it's useful, but I still write fairly OOP-like public interfaces to my code.

I guess I'm not sure what you mean by "fairly OOP-like public interfaces".

My strong suspicion is that you're referring to features that were standard in imperative programs prior to OOP becoming popular. For instance structs in C are functionally equivalent to records in Pascal which date back at least to ALGOL W in 1966. By contrast the earliest OO language is Simula 67 which came out a year later.

If so, then I disagree with you about what "OOP-like" means.

I first learned about the value of information hiding, etc, from Code Complete. The first edition of which was published before OO programming had become mainstream, and therefore says not a word about OO. That said, the ideas in that book translate well into an OO world. (And the second edition does talk about OO concepts.)

Re: Learn C

#134

Post by munin »

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…

writing optimizers in C is much harder than in Fortran because of reduced abstractions and reasoning about memory and pointers. in Fortran they were working on making automatic multi-threaded optimizations where you would write Fortran and it would auto-parallelize into multiple threads ... before C was invented.

C did kill a lot of work on making computers easier to program and safer. it was a devils bargain for speed and we paid for it with decades of crappy code with buffer overflows and shared state race conditions. it's tricky to know if it was worth it.

Re: Learn C

#135

Post by sirclueless »

tracker1 wrote: post #104
foobarbazqux wrote: post #86

Earlier quoted context omitted.

Actual song from PLDI'07 where she received the Turing Award, which we all sang to the tune of Take Me Out to the Ball Game: Let’s all sing to Fran Allen For the great things she’s done. PTRAN and Blue Gene and E C S Fran, we’ve gathered to toast your success. As we ponder all you’ve accomplished, Our colleague extraordinaire, Here’s to you, Fran Allen, you’re truly beyond compare Optimizing compilers Parallel transf…

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 tasks at the top-level, then all the functional programming research and parallel algorithm wizardry in the world isn't going to make you want to parallelize anything except the top-level tasks. So even if that's a verbose and error-prone task due to procedural programming constructs, at least you only need to do it once. Heck, in my own (admittedly limited) experience 90% of the hard work I have needed done has been handled by my OS's process scheduler and Redis.

The fact is that business applications, the web, and consumer software are all perfectly happy to accept the current limitations of hardware -- 12 processes running on 4 cores is efficient and easy, even with no parallelization at all below the OS process level (with the possible exception of GUI threads in desktop applications).

The only really interesting work happens in areas like HPC where you have 1 task and 900 cores and if you can't parallelize you are dead in the water, and latency-critical applications where the sacrifices made to run intra-task parallelization pay big dividends.

Re: Learn C

#136

Post by pjmlp »

sliverstorm wrote: post #124
pjmlp wrote: post #50

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.

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

Re: Learn C

#137

Post by pjmlp »

dylangs1030 wrote: post #96
pjmlp wrote: post #83

Earlier quoted context omitted.

Funny as someone that started coded back in the day Assembly was enterprise coding, my understanding of a high level language is a bit different than yours. You asked for desktop software without any mention of time.

The implication is that his test is a proof of C's merit. Merit is time-sensitive, in that if software is converted to another language, that language is more profitable/efficient for that software. Therefore, the implication is also that systems converted to C demonstrate C's merit, because it's been decades since they were actually in the language you speak of.

What can I say. I am older than C and remember the days when it was used only as the UNIX system's language.

UNIX's success made people want to port UNIX's tooling for their home computers, this lead to the spread of C implementations outside UNIX.

Had UNIX been written in language XYZ, the article would be called "Learn XYZ". Merit is relative.

Re: Learn C

#138

Post by pjmlp »

com2kid wrote: post #54
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…

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

Re: Learn C

#139

Post by shmerl »

Somehow I thought that C is usually in the curriculum of any CS oriented university / college program, so most have at at least rudimentary knowledge of C.

Re: Learn C

#140

Post by waps »

habitue wrote: post #97
irahul wrote: post #44

Earlier quoted context omitted.

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

> C compilers were optimizing long before Haskell Right, and they've come up with some excellent tricks too. But the reason she felt optimization wasn't going to progress as far is because C is a lower level language than some of the other languages out at the time, and there are necessarily less tricks you can do in a lower level language because you have to infer the intent of the programmer more, and rely on optim…

To convince C users why Haskell has the potential (but currently only potential) to optimize better, it is best to just point to one example that C can never hope to optimize : deforestation.

http://book.realworldhaskell.org/read/profiling-and-optimiza...

C will never be able to do that. Before optimization : the programmer requests a list to be created, fill it by calling functions and then passes the completed datastructure list (or tree) along to another function, which executes commands according to what the list contains.

After optimization there is no more list. Instead the function the list is passed to will call a generated function that generates exactly the needed elements of the tree just-in-time. Result: no list, no memory (aside from 1 element on the stack), no allocation, no clearing of memory afterwards.

Of course the downside is that it's very tempting (and encouraged) to write programs that don't contain these optimizations you'd have to do manually in C/Java/... and just have them run. What you'll miss as a Haskell programmer is that the program is effectively dependent on those optimizations for it's complexity (for example: optimized program is O(n), program as written is O(n^n). Then you insert what looks like a tiny change, say, sorting the list, which prevents optimization from happening and boom, your binary switches from O(n) to O(n^n). All tests will obviously pass, yet your boss is unlikely to be happy ... At this point it is extremely hard to figure out what just happened)

Post reply on HN