I have to totally agree with this. I have almost completed Learn Python The Hard Way and it has been very good to me. I have been programming in many different languages while in school (I just graduated this May, lucky me...). I must say that this might be the most complete way that I have seen to learn a new language. I am definitely doing Learn C The Hard Way and I am definitely going to donate/pay for these materials. They are extremely beneficial to any programmer even if you know all of the information.
Learn C
91–100 of 182 posts
Re: Learn C
#92Earlier quoted context omitted.
We are talking about interpreters here, not compilers. Binary Lambda Calculus has both Forth and Brainfuck beat, with a BLC interpreter in BLC of only 206 bits (under 26 bytes).
Are you sure? From where I stand, it looks as though andrewvc and betterunix were both talking about compilers rather than interpreters, while dysoco didn't specify either, so I inferred that the compiler topic still stood.
I thought dysoco hinted at the brainfuck self-interpreter,
as linked to by peterwaller. There acutally is a brainfuck
compiler called awib (http://code.google.com/p/awib/), but
it's not that small (very artistic though). So I assumed
the discussion had drifted into interpreter territory...
Re: Learn C
#93Earlier 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.
I'm not siding with or against you here, but each of your examples is of something originally being in a language other than C.
Your position isn't strengthened if you can only name systems that were written in something else before someone converted them to C. In fact, by design, that's kind of benefitting the opposing side. I'm just saying.
Re: Learn C
#94Earlier quoted context omitted.
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 bu…
I think you misinterpreted my comment, but that's OK. My comment was that OOP in C can be seen kind of like a question of API or ABI (a bit like COM in the Windows world). If you need to do what some would consider hacky things with macros, or stuff that is "not very OO", you still want to keep boundaries between compilation units and libraries clean, and OO-style constructs is a good way to get that done. The fact that you used a macro is an implementation detail that disappears once your code is compiled.
However to your (to my eyes entirely tangential) comment about subrountines.. No, you can't do everything macros do in a subroutine. For instance you can't take the parameters and stringify them with #, you can't concatenate tokens with ##, you can't do funny things with braces or have a macro declare a bunch of static variables or code for you. You can't do the co-routine hack that btilly's link references (although it is very "out there"). This means you can do lots of interesting things with macros that you cannot with a function. These things can be abused but they can also make your code a lot simpler, shorter, easier to understand - and with the uglier parts constrained to a small amount of code. I don't see it as in conflict with OOP because it doesn't have to leak outside a single compilation unit or library.
Re: Learn C
#95Earlier quoted context omitted.
Well, I actually see that as an advantage vs. placing trust in an abstraction you have no control over that can provide security problems for you. So I guess we'll agree to disagree on this one. Curious though, in what would you implement the examples I gave?
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.
They took the code from the Ariane 4 and stuck it on the Ariane 5 assuming all would go fine.
While a famous incident attributed to Ada, I can safely say that C and other popular languages have done far more damage. Even if not in terms of exploding rockets (I don't know), but time lost debugging, fiddling with checks that would be handled in other languages and so forth.
I like to tell people with Ada I can spend my time adding value rather than fighting against the language because of it's minimalism and the bugs that come with that.
Re: Learn C
#96Earlier quoted context omitted.
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.
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.
Re: Learn C
#97Earlier 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, 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?
> 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 optimizing idioms etc, rather than optimizing actual constructs of the language.
How does a compiler optimize a single "goto"? There isn't much it can do unless, for instance, it notices that the goto is found in an idiomatic pattern that results in a loop. Then it can make a decision whether to unroll the loop or not. If the language gives you the loop construct, it can skip the "recognize the idiom" step (and the associated risk of guessing wrong), and go right to optimizing loops. Similarly, in higher level languages than C, the programmer can express their intent more directly, and therefore the compiler can take less risks when guessing "Ah, I see what you're trying to do, here's the fastest assembly that accomplishes that"
Re: Learn C
#98Earlier quoted context omitted.
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…
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 languages other than C. Eclipse in Java, Dropbox in Python to name two. But my point still stands. I looked at all the desktop applications I have installed and they're without fault C or C++.
Re: Learn C
#99Earlier 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…
I'm not betting anything. I'm just saying that it seems to me the advantages of higher level languages do not outweigh the disadvantages. Most of the software I use was written relatively recently, which means other program languages were available, yet C was chosen over them.
Re: Learn C
#100We 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…
> 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…
Several of your examples are hard real-time systems. Garbage collectors, schedulers, etc. are a no-go in such environments, so you won't see much Python or JavaScript there, but that doesn't discount the value of those languages. Note that Ada, a high level language, is used in similar systems, and that Lisp has been used in NASA satellites. High-level languages like Erlang are used in telecom systems and other critical network applications.
The fact is, languages created in the early history of computer programming have had the opportunity to be used in high profile projects like the ones you brought up. In time, you will undoubtedly see Python and others used in such contexts.