C is an amazingly designed language. It's beautiful, simple, elegant and fast.
Everything a well designed programming language should be.
C++ then came along and shit all over Dennis Ritchie's masterpiece. Bjarne took a beautiful, simple, elegant and fast language. And kept shitting on it until all that was left was 'fast'. Dennis should of beat the shit out of him for turning his work of art into an abomination.
Then Gosling came along, surveyed the turd that Bjarne had dropped, and attempted to clean it up. He redesigned C++ to remove the crap and attain the elegance that C had. Unfortunately, in his cleaning frenzy, he over-simplified the language and sacrificed speed. In the name of simplicity he removed pointers, manual memory management, generics, operator overloading and native code compilation. A noble effort, but ultimately just as much of a failure as C++.
Name:
Anonymous2012-07-19 21:03
C++ is a different language, it was never intended to be a C clone.
Name:
Anonymous2012-07-19 21:10
should of
I hate you.
Name:
Anonymous2012-07-19 21:22
At least C++ provides alternatives to C's shitty constructs. Enjoy being stuck on a single programming paradigm. The fact that C++ has a shitload of features is not a bad thing. Most C++ programmers subset it. A lot of companies have internal C++ style guides stating what features cannot be used (like inheritance, exceptions, RTTI, etc.). We don't need a new language **looking at you, D** in lieu of a piece of paper that says NO STL.
I seriously fucking LOVE C. If I ever unfortunately have to touch sepples, I really only use simple templates, and classes to a minimal degree.
And I overload the comma operator ಠ◡ಠ
Name:
cancer.exe2012-07-19 21:40
Objective C is pretty cool.
Name:
Anonymous2012-07-19 21:43
>>4 We don't need a new language **looking at you, D** in lieu of a piece of paper that says NO STL.
huh? no STL? thats your recipe for making C++ is not using the STL? then you might as well go back to using C because the STL is the only thing holding together the shitpile of memory managing things like inheritance and containers.
Seriously, people at some point I going to look at all the generics boilerplate to make OO work in C++ and ask themselves why, why are we polishing a turd. You can get all the speed of C++ in a safe garbage collected language like D. Stop using Java/C# as an example of why gc doesnt work because they are glorified scripting languages.
C is an amazingly designed language. It's beautiful, simple, elegant and fast.
Everything a well designed programming language should be.
That's so wrong it's not even funny. Maybe (maybe) compared to C++ it is not much poorly designed. Maybe.
>>13
Yes, not the best, but at least it was simple enough to visualize the actual instructions from the source code. Back then when your typical CPU had a fraction of a recent $2 microcontroller computing power.
C'mon. It looks like you're trying to maintain C/C++¹ active by yelling about their long gone superiority. Most programmers don't need or don't care about raw speed at the cost of weird grammar issues or unsafe features, so let them for the ones who can handle them.
>>20 weird grammar issues
C does not have these, that is why I like it. It is straightforward and clear. It will punish you for being stupid though, that is true.
I'm not saying use C for everything, god no. That would be stupid. I am saying that I thoroughly enjoy programming in it, and projects that can be done in C, I do in C. Lots of text manipulation? Then not C. Etc.
___________________________ 1 Nope.
Name:
Anonymous2012-07-20 0:20
C++ is a different language, it was never intended to be a C clone.
It was intended to be Simula-67 with C syntax and no GC. Its direct predecessor was known as ``C with classes''
>>8
It was just an example. The STL is widely avoided though. Even naive algorithms you write yourself can be faster because you don't really need to cover every single "edge case." Also executable bloat.
Name:
Anonymous2012-07-20 1:27
>>14
Objective-C is a piece of shit. SEPPLES is better. No templates--you lose a Touring complete meta-language. The only reason it is used is to make shitty iPhone nonsense. Thank Jewish Jesus that Windows 8 is going to dominate that shit--kick Objective-C back to the ash heap of history in which it belongs.
If you understand the principles behind the design of C++ then you will see that it is simply an embodiment of the same concepts that have been done in C, only with more convenience. Almost all the new features in C++ map directly to C equivalents. You are not obligated to use every single feature, but should only use the ones that make sense in the current situation. While it is true that many overuse these features and create "executable bloat" as a result, that is not the fault of the language but the user.
"There are only two kinds of programming languages: those people always bitch about and those nobody uses." - Bjarne Stroupstrup
>>29
``There are only two kinds of programming languages: Lisp and crap'' - my anus.
Name:
Anonymous2012-07-20 8:58
"There are only two kinds of programming languages: those people always bitch about and those nobody uses." - Bjarne Stroupstrup
It's funny how deluded Bjarne, he actually thinks C++ is good and the only reason C is still more popular than C++ is because of "political reasons". In reality C++ has quite a few useful features, but the language additions are so badly designed that most people would rather make do with C or write slow bloated Java programs than deal with C++.
C++ is so bad that the only people that use it are pretty much forced too because C is too low level, and everything else has shit performance. If Dennis Ritchie had designed C++ everyone would still be using it for pretty much everything. Java would be used like a slightly beefier scripting language, not for serious programming.
>>29 "There are only two kinds of programming languages: those people always bitch about and those nobody uses." - Bjarne Stroupstrup
this is wrong on so many levels. first of all the only languages in current use are C/C++ and a host of VM languages, there are Java/C# and then a bunch of scripting languages. (lets not bring up functional languages, no one actually uses those in production code).
and then there is the fact that C is just an overused systems language. the idea that you needed C to avoid bloat is a myth, even Delphi was able to produce code that was as fast and efficient as C. the fact that CS was dominated by CE was the main reason that C was used so much in the past when a lot of systems level programming had to be done directly to hardware on 80s vintage personal computers. There is no longer any reason to use C for normal applications that run on a modern OS
Name:
Anonymous2012-07-20 14:06
>>27
I wasn't even talking about the OS. Windows 8 will support writing apps in a variety of languages since it's based on COM. So you're not stuck with shitty Objective-C as with Apple.
>>31
I don't get why people think C is well designed, or Dennis Ritchie was a good language designer. C lacks design. A C compiler, especially back then, was basically a macro preprocessor for assembly. It's like what Coffeescript is to Javascript. Now look at Haskell, Smalltalk, or Go; that's what a well designed language looks like.
>>36
C is still the perfect systems and embedded programming language. Electrical Engineers still pretty much only use C. There is no other language that gives such static control of data on memeory, the typing system is very controllable. It still cant be beat.
>>39
there are basically only 4 embedded programming languages used, C, C++, Ada and a very small percentage of Java. you can find that information anywhere on the net that lists use of embedded programming languages by popularity
>>36
Go is not well designed, ignoring 40 years worth of advances in PLT is not good design.
>>38
C's type system and control on the actual representation of the data is laughably bad and you should feel bad. Ada might be a verbose piece of shit, but it's still years ahead of C.
Name:
Anonymous2012-07-20 18:02
C, C++, Ada, Java [citation needed]
Fine:
C
Java: Though completely inexistent outside Android, shitphones and some hobbyist stamps.
Sorta:
C++: U MENA Embedded C++ (scoffed by Bjarne), and repackaged g++ (depending on the target), complete C++ compilers for embedded are probably rare.
Contested:
Ada: Inexistent outside defense and aerospace, exactly one compiler (GNAT) for exactly one kind of 8-bit microcontroller (AVR) that I'm aware of. Green Hills' Ada compiler doesn't target ARM and some other target architectures you'd like to have these days.
Missing:
Forth: a rather large amount of compilers (always the case with Forth) for every chip target imaginable. Some chips currently ship with Forth such as the 144 core GA144.
BASIC: Microchip (4th largest in revenue share from microcontrollers in 2011) lists 3 premier third party compilers on their site: 2 are C and C/C++ and the other is PICBASIC PRO, that should say something.
Wiring: Processing derivative, used on Arduinos, confused with C++ sometimes.
Pascal: STMicroelectronics (9th largest in revenue share 2011) lists MikroPascal on their third party tools page. JAL for the Microchip PIC devices is similar to Pascal.
Interesting:
Lisp: Lisp was used on some NASA projects. Deep Space 1's Remote Agent was written in Common Lisp, was subsequently named "NASA Software of the Year". Butthurt SEPPLES coders tried to rewrite the planner to C++ but failed after a year. Whenever Lisp show up in embedded at all, its usually some type of robotics. Kinda inappropriate for cheap micros.
Python/Lua/Scheme subsets: Exists micro-interpreters for all of these to fit in small micros.
LOGO: Robot turtles, a lot of them.
Name:
Anonymous2012-07-20 18:30
>>19 simple enough to visualize the actual instructions from the source code.
Only if you're using a non-optimizing compiler that doesn't make good use of your CPU. >>31 C is too low level
Not true. C is not low level enough for low level usage and not high level enough for high level usage. BLISS and PL/M are low level, in the sense of controlling CPU instructions and registers and being able to do whatever your CPU can do. They have the full power of the assembly language. You can write a boot-loader or kernel in those languages without any inline assembly. C has far fewer capabilities than any hardware architecture. Even MIPS I, which is practically a "C machine," has overflow checking. Good C compilers can turn loops into single instructions even on RISCs. It's better if the programmer is able to say what they mean instead of writing a loop and having the compiler guess. >>38 no other language that gives such static control of data on memeory
Compared to many languages (such as PL/I or COBOL), C has terrible control of data in memory. You can't do anything about integer overflow. Dividing by zero is undefined behavior (not a signal, that's POSIX). You can't even tell C how you want structures to be aligned to simplify I/O (even if it causes a huge performance penalty).
>>46
What has been ignored in Go's design in your opinion? Every time I've heard this the person apparently expected another Haskell or C++. From the perspective of expecting C with some extra things, I find Go not bad.
>>49
I don't see anything ``C apologist''ic there. ``Jew'' quote the wrong post?
Name:
Anonymous2012-07-20 19:05
C#
Name:
Anonymous2012-07-20 19:27
>>47
you offer a very interesting counter evidence for embedded languages, I'll give you partial credit for contradicting me. Its worth commenting on why its only partially corrrect:
C++- its not used as much as C, but it is the second most used. I recommend you listen to this podcast of Bruce Powell Douglas who uses runable UML to design Real Time systems (like flight controls that have a severe time limit in reacting to input) http://www.se-radio.net/2007/10/episode-73-real-time-systems-with-bruce-powel-douglass/
this guy is a strong proponent of using OO in embedded systems
Forth- Yes that is true that forth is by for the most popular language for testing embedded electronics. But I would counter that it is only used as a testing language and rarely used for production code except on systems where code has to be changeable on live running systems like satellites. I dont have proof to back this statement up though so I will give you credit.
BASIC- Im aware there are some BASIC compilers for microcontrollers like PIC, but I think it is only used because its an easy language to teach. The common standard of BASIC would not work as it had a very primitive type system that would not be suitable for electronics. So partial credit.
Wiring- that is just Java/Processing. Most guys I know who are serious about programming microcontrollers dont consider Arduino to be a serious learning tool and just something to help hobbyists avoid hard issues in embedded programming. no credit
Pascal- the fact that the original Pascal standard was never good enough to make production code has to do with it being designed as a teaching language and not a production language. This is where C got its reputation for being a serious programming language by beating out Pascal for professional use. The fact is that Pascal produces that is as fast and efficient as C but is much safer. So Pascal/Delphi died an undeserved death against C. I'll give you full credit for disproving me although I dont know of anyone who uses it for embedded programming.
Lisp- Im aware it has been used for the same purpose as Forth, it is not as efficient as Forth requiring garbage collection and a large runtime
Python/Lua/Scheme- there have been rare occasions that a scripting langauge has been used in writing drivers, but these are very inefficient for this role. partial credit
Logo- this is not embedded electronics, its a program that runs on an OS. no credit
>>50
Lack of parametric polymorphism and polymorphic containers (except when they decide to not) and using tuples instead of a tagged union for errors are the real deal breakers.
The latter is just plain retarded.
The former is just as retarded, but it's even worse because you have to choose between useless code repetition, or (typesafe) void* casts.
Also, the asinine 32-bit GC implementation, but that's not part of the language itself.
Name:
Anonymous2012-07-20 19:46
>>54
polymorphism is really a non-issue for Go, Go does not try to do OO, polymorphism only works for identifying sub-types and inheritance some would argue is the worst part of OO, the kind of thing that Torvalds would argue you cant back out of once its set without redesigning the entire code. And polymorphism is really the worst part of inheritance as you are basically doing pointer arithmetic on objects, something the designers of Go want to avoid
>>55
What you're describing is subtype polymorphism. Actually, one particular implementation of a particularly bad formulation of it. But that was not my point.
I was talking about parametric polymorphism.
swap[T](T* x, T* y) T {
T tmp = *y;
*y = *x;
*x = tmp;
}
int a, b;
float c, d;
...
swap(a,b) // typechecks and works.
swap(c,d) // typechecks and works.
swap(a,c) // compile-time type error: `a' and `c' are different types.
>>56
>But that was not my point. I was talking about parametric polymorphism.
why dont you just say function overloading instead of using fancy terminology?
and youre using typeless pointers in this example, the kind of thing Go wants to avoid. The nice thing about C is that it avoids name mangling that is involved in making overloaded functions work in C++
>>58 why dont you just say function overloading instead of using fancy terminology?
Because it's not.
Goddamnit, I hate Gotards pretending to know it all.
THE FUCK ARE YOU DOING ARE YOU THE GRAND ARBITER OF KNOWLEDGE OR THESE ARE JUST OPINIONS ARE YOU GRADING BASED UPON CONSISTENCY WITH YOUR LIMITED KNOWLEDGE AND JUDGMENTS OF THE STATE OF THE WORLD AND PROGRAMMING LANGUAGES ONLY IMPLEM EXISTS NOW NO FUTURE NO PATH WHAT IS FIXED APPLICATION CODE APPLICABLE QUERIES SOLVENT VAPOR FIXED RESULTS UNDECIDABLE?
>>62
I remember reading that for the first time and being amazed that they didn't even pass the assembly through a basic optimizing assembler, it could get rid of what is practically dead code easily and rapidly.
there are a few things that you can do at that level. But assembly is difficult to work with. The program has much more structure in the earlier stages of compilation.
>>72-73
Optimization done at assembly level != an optimizing assembler, you idiots. The assembler's job is to just assemble the assembly, not to scramble the assembly I crafted with love.
>>72
Thanks for reminding me how shitty Wikipedia is
Name:
Anonymous2012-07-21 1:02
>>70
It could still eliminate "dead code", and then realign things later on with NOPs itself.
I don't understand why it would use instructions that are potentially way more expensive than a NOP just to align data so I think it's just shitty codegen but there you go.
>>71
Yes it does exist, and you're fucking retarded if it says that it "defeats the purpose". The purpose of an assembler is to assemble assembly code into opcodes, how it does it is just an implementation detail.
>>76 The purpose of an assembler is to assemble assembly code into opcodes, how it does it is just an implementation detail.
Not to be confused with assembling code into unexpected opcodes and patterns thereof for the sake of "optimization." Show me an assembler that does this.
>>80
So your code coincided with the optimized code in this case, maybe nasm thought your 7 instructions weren't worth optimizing since it would take longer to do that than it would for you to run it a billion times, maybe it recognized your program as rubbish, so what is your point exactly?
Try doing this with a large code base, I'm sure the flag is there for a reason, and not to mention that there are several other optimizing assemblers out there. You should try searching for "optimizing assembler" with Google, I'm certain that despite your apparent disabilities you will still be able to operate a simple search engine like Google.
And to expand on that, the -Ox flag in nasm picks smaller encondings.
Example:
Instead of assembling add ebx, 3 as add r32, i32 it assembles as add r32, i8.
Proof: _start: add ebx, 3
No optimization: 00000000 6681C303000000 add ebx,0x3
Optimization: 00000000 6683C303 add ebx,byte +0x3
>>81
It didn't because it's not nasm's work. -Ox only does >>82, and it's even written in the fucking documentation.
The burden of proof is on you, you are the one claiming there exists such an assembler.
>>83
I'm not really interested in convincing you that optimizing assemblers exist, the proof is even in this thread, >>72 provides you with a handy link and >>82 shows that nasm does produce "optimized" output so it is an optimizing assembler, and as I said it's fairly easy to operate Google and I'm sure even you can figure out how to do it.
If you still don't want to admit that optimizing assemblers exist I don't care, I generally don't bother dealing with retards like yourself.
Name:
Anonymous2012-07-21 2:04
>>83
if it doesn't exist, you could always make one. I don't get what you all are so worked up about.
Name:
Anonymous2012-07-21 2:07
>>84,85
Listen you stupid faggots assemblers should only translate the assembly into the exact equivalent opcodes. ALso still you have to come up with any proof that such optimizing assemblers exists.
>>85
Because it's not useful and the assembler cannot infer the intent of an apparently useless instruction and might ``optimize'' away something important.
Assembly is not C, where the compiler holds your hand making you think ``omg im writing low level coeds i can totally see wat teh machine is doing!!! :D'' while it reduces your whole loop to three SSE instructions and makes your undefined behavior ridden code go fast.
When I write assembly code, I expect my opcodes mnemonics to be assembled to said opcodes.
Name:
Anonymous2012-07-21 2:13
>>87 When I write assembly code, I expect my opcodes mnemonics to be assembled to said opcodes.
Then you shouldn't use an optimizing assembler. It's that's simple, just relax.
The reason why an "optimising assembler" in the same sense of optimisation as a compiler does not exist is that at the Asm level it is impossible to determine in general whether or not an instruction is needed. The extra instructions could be deliberately inserted for timing purposes, testing, etc. (This is a similar situation to how compilers may remove delay loops completely as they do not compute anything, and thus should not be used for the benchmarking of hardware.) On the other hand a compiler for e.g. C can eliminate code it deems unnecessary as the programs' outward behaviour with respect to the machine model defined in the language's standard remains unchanged.
Taking advantage of shorter encodings for instructions (like >>82 and the well-known short/medium/long jumps) is a default for many assemblers and it has been this way since the 8086 was introduced. That type of "optimisation" does not change the behaviour of the program at the machine level, but only its size. Going beyond that requires deeper analysis that no publicly available assembler I am aware of can do.
(Before some of you attempt to refute with this point: I am aware that some advanced techniques like SMC will be affected by this type of optimisation. However all assemblers I have used allow explicit specification of the form of instruction you want, or failing that, directly specifying the bytes that constitute it.)
>>63
Just don't use the features that are too bloaty.
>>67
They need to improve their code generator. As-is, it's probably the extremely simple single-pass type, with very few rules. The patterns are obvious: It almost always uses eax and edx for transfers, and ebx for the first pointer dereference. Occasionally it will use esi and edi for loop counters. Besides the loop counter exception, it does not seem able to keep track of register values beyond more than 3-4 instructions at most (likely expression boundaries).
>>20
We've almost reached the physical limits of hardware. That's why you see systems getting wider. But not everything can be parallelised. I've recently worked with some cloud/distributed systems stuff written in Java, and despite what they say, the efficiency is horrible. A C/C++ rewrite could easily cut memory usage and execution times to 1/10th what they are.
Another example: look at boot times of various operating systems over the year when run on their recommended hardware configuration. If there has been improvement, it is nothing near the order-of-magnitude growth in speed that processors have had for the past 2 decades. Faster hardware enables us to do more; but at the same time, also entices us to waste it. In other words there has been growth at the "top edge" of productivity, but the "bottom line" has remained essentially unchanged. MS has been aggressive in marketing the boot speed of Windows 7 and Windows 8, but to get those "improvements" they had to remove a lot of the existing functionality in previous versions. Does that fit with the notion of hardware being faster? "Do less with more" is where things seem to be going with software these days, and it is only to create the illusion that things are improving. As Apple's success shows, with the right marketing you can turn anti-features into features perceived by the masses of mindless consumer drones.
This level of waste is not sustainable --- look back to the 1970s energy crisis (were you even alive back then?) --- "let's waste resources because they seem infinite for the time being" was the attitude people had before then, and it didn't result in anything good.
>>91 Why are you using 16-bit mode with 32-bit instructions?
Nasm for DOS. No. You forgot about the stack.
Oh, right, there's an extra push in there. mov eax, [ebx]
push eax
, then.
>>1
Java is actually one of the fastest languages out there and it also has a very clear syntax. Using a fucklot of resources doesn't mean something is slow, but yes, it's a very bad thing. And objects are not even forced on you, only retarded code monkeys ``abstract" everything.
Java is slightly better than C++ for making small projects, as long as you don't fuck with the standard library.
So please stop pulling shit out of your anus, Java is not a complete failure.