Earlier quoted context omitted.
IntelliJ Idea for Java?
Yes. There are lots of refactorings that cannot be done by simple search and replace, even for C, because they require semantic knowledge of the language.
The Unreasonable Effectiveness of C
331–340 of 394 posts
Re: The Unreasonable Effectiveness of C
#332C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level progr…
> C is the language that doesn't force any preconceived notions about how the world should work onto you Some preconceived notions forced upon you by C, off the top of my head: - problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming) - a variable can have different values at different times in the execution of a program (in contrast to standard mathematical co…
Linear sequences of steps processing data arrayed in some linear fashion or others is what computers do. It is certainly what a single core does.
So you would rather have someone else write a C program for you that abstracts it away and calls it a new way to program? That's k, just know that you'll still have those pesky linear steps under the hood. You know, at some point the neat source you write actually has to get converted into stuff CPU can make the slightest bit of sense out of.
Of course it's nice to try to "get the computer think like the programmer instead of the other way around" (kind of the motivation for the inventor of the compiler IIRC, in times when people really had to "speak binary" to the computer), but it also kinda sucks when people completely loose track of the machine they're programming, and think their abstraction layers du jour grow on trees or something.
a variable can have different values at different times in the execution of a program (in contrast to standard mathematical conventions)
Your problem is nomenclature? Why not simply declare constant variables where you need them and move on? And are you really trying to twist C giving you the choice into "forcing preconceived notions" on programmers? That is hilarious, I will give you that much.
a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term)
"Function" can also mean a lot of people coming together for a wedding or something. I think that's why you would call them "C function" if you wanted to be precise.
there is random access storage of information (with constant time access and update)
Again, that's just how "the world" works. But C hardly came up with that, which is why all languages have it.. yes, all of them. Some abstract it away from you, sure, but they still have it. So you pay overhead and control "tax" in return for convenience and and expressiveness; that's not a bad thing per se, often it's the sane and productive choice, but to me dissing C is just shitting where you eat. The only reasons I can imagine for it are jealousy or ignorance.
Re: The Unreasonable Effectiveness of C
#333Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…
the idea that specific requirements of c had started driving architecture development blew my mind the first time i came across it. it is still a point that does not get discussed nearly enough at a popular level.
Re: The Unreasonable Effectiveness of C
#334Earlier quoted context omitted.
So what you're saying is that C lets you write it on your own. In fact, and this might sound crazy, but you can do that exact same thing in C++, it's just that people don't because the C++ standard library provides plenty of performant and featureful data structures for you. Besides, anything the C++ standard template library map does when implementing a red-black tree is exactly what you would need to do if you wrot…
I'm confused. C has libraries too. I personally like the headers used by openbsd: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/tree.h?rev...
I've written C for most of my life, you can do great things with it. I also have a love/hate relationship with C++ and Python. There is no perfect language, they all have to make tradeoffs.
Re: The Unreasonable Effectiveness of C
#335Re: The Unreasonable Effectiveness of C
#336Earlier quoted context omitted.
> Because Lisp Machines didn't win. And if Lisp Machines had won, do you really think they'd run JavaScript, Erlang, C, and Haskell (as a rough sample) as fast as our Von Neumann machines do today?
C is built to run on a MASOS (multiple address space operating system) like UNIX so it wouldn't run as fast on a system like the Lisp machines that uses a single address space. Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence. Running C on a Lisp machine will be possible but at a performance cost. JavaScr…
What? You can run C on machines without a MMU, without an OS, or even to implement an OS.
> Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence.
What if people want a filesystem? They can't have one because the machine designer liked "single address space orthogonal persistence" better?
> JavaScript would run faster then it does on Von Nuemman machines because it would use the hardware support for dynamic languages > Haskell, in so far as its purely functional, would probably run the same as it does now.
I highly doubt these claims. Just because a language is "dynamic" doesn't mean it can take advantage of generic "hardware support for dynamic languages" to be as fast as highly sophisticated and language-specific VMs like V8 or IonMonkey. Just because a language is "functional" doesn't mean you can implement a thin translation layer that maps one onto the other with minimal overhead. This is fuzzy thinking that ignores the true complexities of high-performance language implementations.
Re: The Unreasonable Effectiveness of C
#337Earlier quoted context omitted.
The Burroughs was a stack machine, but that's only the beginning. Look at how it handled addressing hunks of memory. Bounds checked memory block references were a hardware type, and they were the only way to get a reference to a block of memory. So basically, null pointers didn't exist at the hardware level, nor out of bounds writes to arrays or strings. Similarly, code and data were distinguished in memory (by high…
I'll have to read more about the memory references to get a feel for that. However it speaks of a compiler for ALGOL... it was compiled down to machine instructions. Assembly is just a representation of machine instructions, so I don't see how it can be said to not have an assembly language. Maybe nobody ever bothered to write an assembler, but that doesn't mean that it somehow directly executes ALGOL. Thanks for you…
In this sense, you're completely right. But I think that people who grok the system mean something a bit different when they say it doesn't have an assembly language. (Disclaimer: I have no firsthand experience with Burroughs mainframes.)
The Burroughs system didn't execute Algol directly, true. But, the machine representation that your compiled down to was essentially a high-level proto-Algol. It wasn't a disticnt, "first-class citizen". It was, if you like, Algol "virtual machine bytecode" for a virtual machine that wasn't virtual.
If you're writing in C, or some other higher-level programming languages, there are times when you want more fine-grained control over the hardware than the more plush languages provide. That's the time to drop down to assembly code, to talk to the computer "in its own language".
The Burroughs mainframes had nothing analogous to that. The system was designed to map as directly to Algol as they could. It's machine language wasn't distinct from the higher-level language that you were supposed to use. To talk to a Burroughs system "in its own language" would be to write a rather more verbose expression of the Algol code you'd have had to write anyway, but not particularly different in principle.
So, I guess the answer to whether or not the Burroughs systems did or did not have an assembly language is a philosophical one. :P
Re: The Unreasonable Effectiveness of C
#338Earlier quoted context omitted.
None of what you said supports your initial claim that the author is ignorant. In fact, even if we pretend that everything you said is true, none of it contradicts the article, or the authors conclusions. Yes, C has lots of areas where other languages are better. And yet, it is still the most practical language to use because of the combination of things that it does well.
"it is still the most practical language" Only in extremely limited contexts: low-level code for operating systems that happened to have been written in C. Otherwise, there is a better language for pretty much every use-case of C.
You say that like it is an accident that just about every major OS today is written in C or C/C++
Re: The Unreasonable Effectiveness of C
#339Earlier quoted context omitted.
The author doesn't claim it's perfect or that there's no way to improve on it, but I think he has a very salient point, which is that most of the OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows. Basically, the author loves C because it is simple, straightforward, and restrictive -- it forces you to write [relatively] simple…
> OO buzzwords and programming fads that come and go in "higher-level languages" simply end up making a bigger mess of things as a project grows No, it's not the language features which make a mess. It's people lacking judgement and common sense. (Like, trying to apply patterns everywhere. Been domain-specific [crypto] consultant on such a project and watched it smash the schedule by more than 2x. It wasn't the langu…
Re: The Unreasonable Effectiveness of C
#340Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…
However, it is here to stay, just like Inch, Foot, and Fahrenheit. Not that the alternatives are worst, just the cost of switching over and training a whole lot of people is back-breaking.
Note that most unfortunately, it is being taken over by javascript (false == '0'), which is a far worse language in many aspects.