Why the hell would anyone use Python or Ruby over C. The software should be nice to use. It's not nice when the program is slow as fuck.
Their dynamic nature makes debugging software increasingly hard. Basically developing with these higher level languages takes more time than with C.
Every program should be written in C. In most cases, it would be good to also optimize tight loops with Assembly. This way programs would be fast and fun to use.
Languages such as C# and Java have no point at all. They are essentially crippled versions of C. Limited pointers and limited memory management. The virtual machine takes forever to JIT-optimize the code, thus harming the user experience. Not to mention GC, which slows everything down, providing nothing useful in return. GC is shit.
Then there are these C++-retards. Sure, you can in theory make as fast C++-code as C-code, but is it really worth it? Every C++ program in practice is slower, harder to debug, and harder to develop.
Functional languages, such as Haskell are no answer to problem. They abstract the hardware to hell and are very slow in practice.
So tell me: Why is C and Assembly not used for every program today?
Scheme and common lisp are the only high level languages you should use.
Name:
Anonymous2013-09-10 5:11
because youre moms a fagot
Name:
Anonymous2013-09-10 7:17
C is a high level language.
Name:
Anonymous2013-09-10 7:46
>>1 Because your assertion that C is faster to develop in is not borne out by evidence, and because it is not always necesary for a program to be fast. C# also runs as fast as an equivalent C program in many cases (try it), so you're now relying on optimization tricks to get any performance improvement at all.
Name:
Anonymous2013-09-10 8:03
I wish someone would come up with a language like C, but that has barebones OO functionality. Not the retarded clusterfuck that is C++, though. I just want something like this:
obj struct { int x; int y; } Point;
Point a = {5, 7};
a.scale(5) // would feed structure ``a'' to function ``scale'' as an implicit automatic variable (like ``this'')
That's all, really. I don't see the need for all the other OOP shit.
>>6 You can do that using structs and function pointers. OOP is not that.
Name:
Anonymous2013-09-10 11:40
>>6 Google (I think) came up with a language called rust, which is basically what you are asking for. It looked like a real piece of shit to me because of some minor but hugely bug-inducing syntax decisions, but you might come to a different conclusion.
>>15 Right, Mozilla. One of them, ya know. I got very excited on reading the overview, and then nearly puked reading the tutorial. Just weird shit all over.
>>17 Rust is the only one of the modern ``We're too cool for C'' languages that has a chance at not being utter shit, honestly. Optional GC means it might actually be usable for systems programming, and sure, the syntax is shit, but that never stopped your favorite. What it will need is a good compiler, a good library strategy (as in, I can deploy libs written in rust, plug in executables written in rust, and not even think about installing a rust runtime/compiler/dancing cursor set on the target machine).
They'll also need a good spec so that a competing implementation can spring up. But hell, all you need for that is a bunch of drooling retards and a ping-pong table. It worked for Ruby, after all.
>>18 Why are you forgetting Go? Does it not have a chance at being a ``better'' C?
Name:
Anonymous2013-09-10 17:46
>>19 But it will keep having GC, no matter how well it performs. It will never be able to give you actual guarantees of performance that way. It may be useful, but it's just not in the same category as Rust, C, C++ or Ada because of that.
holy fucking shit the perofrmance fetish is pissing me off. for most of the programs people write, a high level programming language is the easier way, usually leads to more secure programs (not always because people can fuck everything up) and the performance difference is not noticeable outside of benchmarks. for everyday programming, Python is convenient as hell. for math shit, functional languages are elegant and intuitive. C is good when performance is critical: when you have to manage huge amounts of data or when you write drivers, OS components and shit that holds everything together. oh, and for AAA vidya but if you make a ASCII roguelike then you won't notice the performance difference.
now, the problem of slow software despite fast computers remains. but the reason is not that we're not using an old systems programming language that was cobbled together from many inconsistently named extensions to make up for its glaringly obvious flaws. the reason is that most of our programs are FUCKING BLOATED. desktop software suffers from feature creep and the desire to be the flashiest and most visually appealing to people who get hard while seeing an iPhone instead of doing what it is supposed to be done (preferably with a choice of a simple GUI for n00bs and a good old CLI). REAL ENTERPRISE LEVEL software is worse as it's a labirynthine mess of redundant, barely connected systems that are supposed to make things easier but end up making thigs worse.
basically, the problem is that most of software suffers from bloat and feature creep. it would suffer from the same things if it was made in C and the reduced overhead from not being made in Ruby or Python wouldn't help it because its design (or lack of thereof) has a much bigger impact on the end result. like orders of magnitude greater. classic Unix software might have been faster because of being made in C in 1970s, now it's faster because of Unix philosophy of not adding pointless shit everywhere (something that most of Linux distros forget).
now, some platforms are bloat incarnate and can't be made good - Java-based shit, mobile shit, browser-based shit. and C++ is a mess but again, with most software you won't notice performance difference. you'll just notice that the code looks stupid.
Name:
Cudder !cXCudderUE2016-05-15 14:37
usually leads to more secure programs
That could actually be a bad thing. Unrootable/unjailbreakable devices with DRM, only the corporate brainwashed drones would love that shit.
it would suffer from the same things if it was made in C
because its design (or lack of thereof) has a much bigger impact on the end result. like orders of magnitude greater.
That's the point. C makes it a lot harder to add bloat. You can write one line in an HLL that'll take a few thousand to implement in a lower level language. That tends to make you reconsider whether you should do anything and cause you to come up with a simpler solution. It's possible to write bloated code in C or even Asm, but you have to try really, really hard to.
Name:
Anonymous2016-05-15 15:32
ease of use and implementation don't have to write thousands of lines to implement basics or sort through snippets if you aren't a fucking idiot you will still be able to write a program without exponential growth. more time to work on other programs
It's simple cost-benefit analysis. Honestly I think the best thing would just be a smart interpreter.
That could actually be a bad thing. Unrootable/unjailbreakable devices with DRM, only the corporate brainwashed drones would love that shit.
you're answering the wrong question. if you need to look for exploits and hack a device you already own to have full access to it, the problem is with the device itself. the answer is to use devices that are open by design and avoid closed systems as much as possible
That's the point. C makes it a lot harder to add bloat. You can write one line in an HLL that'll take a few thousand to implement in a lower level language. That tends to make you reconsider whether you should do anything and cause you to come up with a simpler solution. It's possible to write bloated code in C or even Asm, but you have to try really, really hard to.
from the perspective of an individual programmer - yes. from the perspective of a corporation - no. if higher ups decide that adding a fuckton of bloat will guarantee more sales, the bloat will be added even if you have to change opcodes with hex editor.
meanwhile, an intelligent individual programmer can write a reasonably efficient and non-bloated tool in a HLL without having to worry which of the similarly named functions (strcpy, strncpy, strncpy_s, strncpy_c, memcpy or whatever else) to use so that the string is still treated like string and does not cause buffer overflows.
BTW the whole string copying bullshit is the prime example of problems in C: it uses the fucktarded zero-terminated strings (instead of Pascal-style length-prefixed strings) because the difference in two or three bytes in memory was a big fucking deal back when the language was created in the fucking stone age. it then adds a safer version of an old function so your computer doesn't explode and when that function still makes your computer explode, they add another one. meanwhile, I still see programmers in a major multinational corporation use fucking gets().
everyday programming in C is like driving screws with a hammer
meanwhile, an intelligent individual programmer can write a reasonably efficient and non-bloated tool in a HLL without having to worry which of the similarly named functions (strcpy, strncpy, strncpy_s, strncpy_c, memcpy or whatever else) to use so that the string is still treated like string and does not cause buffer overflows.
First of all, the functions ending in _s are a scam by Microsoft. And secondly, Java, a prominent and popular 'HLL', has like 7 (wild guess, but it has things like string builders and buffers and immutable strings and what not) or so different string types. Admittedly, most HLLs probably fare better than this, but most of them still worse than C. Even C++ will always be more complex than C in this regard (not to mention C++ streams).
Name:
Anonymous2016-05-16 3:32
>>6 You're not going to want to hear this, but the language you're looking for is Go.
type Point struct { x, y int }
func (p *Point) moveLeft(amt int) *Point { p = p.x - amt }
That's the point. C makes it a lot harder to add bloat
Wrong. Very, very, very wrong. C doesn't do jack shit for you, so what you end up with is a bunch of terrible NIH cobbled together fuckpiles of unstable garbage to make up for the lack of features easily provided by other languages.
How many C or C++ programs out there use refcounting because the language doesn't help at all with memory management? Tons, and that shit is slower and less reliable than GC. How many C programs have to include shitty little brittle faggot-spec interpreters for configuration data and scripting? Tons, because you can't evaluate or compile the language at runtime.
Because C doesn't do anything, that forces the programmers to go all NIH, and you end up with a bunch of Cudders that shit up everything and send us back decades. You need to be shot, for the greater good.
Name:
Anonymous2016-05-16 4:11
If you want features in your code, and C makes you second guess your feature, your project has failed. And it has failed because of C.
Requirements first, and the computer should serve your project. You are first making your requests at the altar of C. C then brings out the whip and punishes you for wanting something that isn't asm-level bit fiddling. You say "Yes, master, I will keep my computing requests in the 1960s" and lick C's shoes.
Fuck that. The computer does my bidding. If I need a feature then that damned feature is going to be in there, because I need the computer to use that feature to serve me.
You have been pussy-whipped by your own computer. How sad and emasculated you are. Stop trying to promote that anything of your submission to computing is useful. It is backwards and it is cancer.