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

81–90 of 182 posts

Re: Learn C

#81

Post by kmm »

doktrin wrote: post #45
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…

> 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 might want to review the list of packages and make some changes, and every time I have to wait 13 seconds.

The compiling part is true, but that is not supervised.

Re: Learn C

#82

Post by asynchronous13 »

pjmlp wrote: post #53
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…

Just three, ask for more if you wish: The original version of Skype was done in Delphi. The first versions of Mac OS were done in Apple Pascal. Photoshop was originally done in Apple Pascal.

1) the original UI for Skype was written in Delphi. The core functionality is, and has always been written in C/C++.

2) Mac OS is not a desktop application.

3) Adobe Photoshop is all C/C++ now. They converted it to C/C++ because they decided that was a better choice. Its tough to sell that as a case for a major desktop application not in c/c++.

Re: Learn C

#83

Post by pjmlp »

kmm wrote: post #80
pjmlp wrote: post #53

Earlier quoted context omitted.

Just three, ask for more if you wish: The original version of Skype was done in Delphi. The first versions of Mac OS were done in Apple Pascal. Photoshop was originally done in Apple Pascal.

To be honest, I was looking for some more recent software. Skype is 10 years old and both Mac OS and Photoshop are both decades old. And Pascal is not "better" than C, it is not a high level language.

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.

Re: Learn C

#84

Post by pjmlp »

asynchronous13 wrote: post #82
pjmlp wrote: post #53

Earlier quoted context omitted.

Just three, ask for more if you wish: The original version of Skype was done in Delphi. The first versions of Mac OS were done in Apple Pascal. Photoshop was originally done in Apple Pascal.

1) the original UI for Skype was written in Delphi. The core functionality is, and has always been written in C/C++. 2) Mac OS is not a desktop application. 3) Adobe Photoshop is all C/C++ now. They converted it to C/C++ because they decided that was a better choice. Its tough to sell that as a case for a major desktop application not in c/c++.

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 APIs when the OS is written in C, therefore all applications are written in C.

Re: Learn C

#85

Post by philwelch »

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…

Eclipse is made with Java.

Re: Learn C

#86

Post by foobarbazqux »

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…

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 transforms too
  Intervals, call graphs, and data flow
  Keep our programs from running too slow
  So we root, root, root for Fran Allen
  Her heart, and spirit, and voice
  For she’s won the Turing Award and we all rejoice!
She said that she believes functional languages and programs are key for scalable parallelism on massively multicore processors, because of the unavoidable performance problems associated with synchronization on shared data dependences in imperative languages.

The back story you quoted about C motivates her position a little, so thanks. It seemed like few of the hardcore compiler people that I spoke to at the conference seriously believed functional languages were going to be the future because of performance reasons, although personally it doesn't seem like an entirely unreasonable proposition.

Re: Learn C

#87

Post by m_mueller »

asveikau wrote: post #58
btilly wrote: post #51

Earlier quoted context omitted.

People who use the preprocessor heavily tend to use a fairly non-OO design. See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html for an interesting example of a design technique enabled by that. I also note that said technique is problematic in practice not because it isn't good - it is - but because it causes people to suffer a brain freeze.

I tend to see these as orthogonal. What does a macro do but generate more code? So shouldn't the use of macros be reducible to ordinary code? That, and you can still employ this stuff at the micro level and your chatter between compilation units or library boundaries can still be OO.

> So shouldn't the use of macros be reducible to ordinary code?

No, because it's a matter of performance. To avoid code duplication, without macros, you use routines. To get the same performance as with macros the compiler needs to inline them - which only works up to a certain point. If you can't compromise on performance (for example for HPC or low power purposes) you can't replace macros/templates with anything but copy pasting code.

Re: Learn C

#88

Post by gnuvince »

ColinWright wrote: post #69
claudius wrote: post #64

Earlier quoted context omitted.

The control software for the Ariane rockets is written in Ada, which is apparently meant to be especially ‘secure’/predictable. And promptly blew up the rocket.

As I understand it, this was in part specifically because they turned off the protection the language provided.

Exactly right.

Re: Learn C

#89

Post by webreac »

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 do not understand the hype around clojure. I think functional programming languages have mainly evolved to introduce stronger typing and to remove the parenthesis. I wish a great future to scala (and haskell). For me, clojure is outdated.

Re: Learn C

#90

Post by sramsay »

betterunix wrote: post #33
hbridges wrote: post #14

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…

Except that C is all over the stack that most people work in every day, and not just way down at the level of the OS.

It's astounding to me how many of the people talking about Python, Ruby, and PHP as moments of great liberation from C appear not to realize how many of the most useful libraries in these languages are really just gentle wrappers around C libraries.

Someone needs to write that not-particularly-low-level code, and someone needs to hook it up to these miraculous high-level languages. The people who do this have always been a quieter bunch than the Pythonistas, the Rubyists, the Node-nuts, and whoever else, but damn do they know what they're doing. And they certainly don't go around talking about how C is obsolete, only for device drivers, and has nothing to do with their "stack."

Post reply on HN