Shitty,slow and bug-prone string functions. NULL termination and strlen are shining examples of defective design.
No memory management, plenty of things going down the drain if
you don't watch them all. Malloc and free are slow and inefficient, and they ruin performance if used in fast loops.
Variadic functions: all C has is shitty macro which doesn't implement anything useful. C cannot determine types of such variadiac arguments at runtime. Everything is static.
Typeof(non-standard)/sizeof/pointer casts in many programs show how defective the implementation of only object C manages(the pointer) natively. Pointers(and arrays which are also pointers) are the glue of C, yet they lack anything useful(like size or datatype,sizeof alternatives like _msize/malloc_usable_size and typeof are ugly non-standard hacks) and people use void pointers for felxibility.
Python and Perl are far, far too slow. Lisp and the other functional languages are even slower, and have no library
support; they are essentially toy languages.
Lisp, slow? A lot of implementations are natively compiled and are damn fast if you do your own benchmarks. If your specific app is too slow, just profile your code and add some type declarations or rewrite your code in a more efficient manner. You get the choice how fast your code will run. You don't get the choice to write your programs in a clean manner in C, you have to write all that management code first.
No library support? Last I checked, there's plenty of good libraries, and even if they're not that many, you have excellent FFI support, so you can just reuse libraries written in other languages if you need to.
Toy languages? It's used in the industry for some demanding applications, but they are by no means popular languages. I think a language's popularity is irrelevant, just use what solves your problem best. If you turn to some framework for a few ready-made solutions, you're just limiting yourself to whatever they offer.
>>17-chan has never tried to access MySQL from a Clisp image, or grok UTF-8 text in a Scheme fibs, or coax Hugs into actually reading an entire file from disk instead of just the first line.
>>20 SBCL, CMUCL or CCL
Have you ever tried to compile these monsters? When they added CMUCL to Gentoo, it took ten people working a month and a half just to research the dependency graphs. There's no possible way you could use that shit for actual desktop binary deployment short of selling your soul to the ACLU.
>>19
Oh, don't get me started on Haskell. I followed the benchmarks for a while, thinking it showed some promise. It turned out the authors of the compiler were special-casing the benchmark algorithms and substituting actual C and assembler. Every time someone tried to ask about this on the mailing list or IRC, that dons guy would pop up with the same answer to everything. "Did you use the latest version? We just issued a patch for that within ten seconds of you asking your question!" Most unprofessional and insulting crowd I've ever seen.
>>22 Have you ever tried to compile these monsters?
I've tried to compile SBCL on Windows, and it worked on the first try. Worked fine in Emacs and SLIME as well.
SBCL and CMUCL are public domain, so you can use it for deployment without any worries. I don't think it would be harder to compile on *nix, as I used Cygwin(MinGW would likely work as well) to compile ( only needed for the loader ). I can't speak for CMUCL, but SBCL was derived from CMUCL with the goal of making it compilable in any ANSI CL implementation. It seems they have mostly succeeded.
There's no possible way you could use that shit for actual desktop binary deployment short of selling your soul to the ACLU.
I've even made some standalone executables for testing purposes. The executables turned somewhat big (about 20MB), but if I really need to deploy my code in some space constrained environment, It wouldn't be very hard to modify the loader/"runtime" to just compress the core image (I actually looked into the code that does the loading of the core into memory, and it looked fairly trivial to change to support compression). There's also a tree shaker for SBCL, but it's experimental.
I've also done some benchmarks and examined the disassembly of code produced by SBCL, and I must say I'm mostly impressed by the results.
In the event that SBCL really doesn't suit your needs, you can always use ECL to compile to C, which should cut down on FFI costs (as all calls are native to C, no copying of parameters or locking objects into memory needed).
OP, C isn't perfect. Other languages aren't too:
Anything higher-level then C tends to lose to C in performance,usability or flexibility.
1.C strings are slow. Its been that way, due O(n) search time for NULL.
You can either:1. Use your own string struct,C++ std::string, or save the length in companion variables(str_len) and reuse that. Designing your own string functions is possible, but useless unless you optimize that piece of code. Output and one-use functions in a program need zero optimizations.
2.Memory management is always risky. That why people use malloc mostly at start of program and manage the memory from there
as they wish. Garbage collectors are worse than manual allocation: it either results in wasted memory or slower programs.
You never use malloc in loops or inside small functions. Functions can have variable length arrays allocated on the stack.
3. If absolutely need these variadic functions(and garbage collection) use D. Also,you can use this construct:
void**args as pointer to array of your arguments `void *args[x]`, first pointer is `int size` second is argument 1,third is argument 2,etc(i'll post that on my blog in extended form) to simulate variadic(cast from void though) arguments in most cases.
4. If you use typeof/sizeof or _msize/malloc_usable_size extensively it a sign your code needs to be refactored.
Consider adding companion variables or structs which describe the datatype/size(I've used _msize/malloc_usable_size before and this can be easily abstracted out if you save data of size you allocated.)
Pointers are useful because they are fast, and they store little useful info(that why structs and objects are for).
null termination is delicious, it's probably my favourite thing about C.
fuck you, OP
Name:
Anonymous2009-08-21 10:24
Software development is a fucking ghetto. I fucking hate you guys and hate myself. All these endless discussions that lead to nowhere, no one agrees on anything, I can't take this shit. I hope you all die. Sofware development is not even close to reaching a stable or professional level, and it will keep on sucking until then, creating and dragging a bunch of psychological crutches along the way, such as OO bullshit, fucknut design methodologies, hell, all software engineering. Stop masturbating over stupid details and stab yourselves in the fucking eye already, you useless shit cunts.
>>29
The right answer is that there are different tools for different situations. People don't know which tools to use for the right situation. I personally like Haskell, Java and Piet.
Name:
Anonymous2009-08-21 23:20
>>30
I prefer Scheme, Spanish, and long-handled spoons.
I use C and JavaScript. Other languages are rarely needed if at all.
I like to see Haskell,D and OCaml to be useful in coding/hacking but they all have drawbacks compared to plain C.
_______________________________________ http://bayimg.com/image/aadbjaace.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
My Blog: http://frozenvoid.blogspot.com/
«We hold life to be sacred, but we also know the foundation of life consists in a stream of codes not so different from the successive frames of a watchvid. Why then cannot we cut one code short here, and start another there? Is life so fragile that it can withstand no tampering? Does the sacred brook no improvement?»
Name:
Anonymous2009-08-22 9:15
Shitty,slow and bug-prone string functions.
What do you mean with 'shitty'? How did you find out that they're slow? Why are they bug-prone?
NULL termination ...
You can't possibly terminate a string with the null pointer constant.
... and strlen are shining examples of defective design.
They are shining examples of primitive design, not defective. Don't forget where C is supposed to run. There's much better string libraries available too.
No memory management,
How would you implement MM in C without breaking anything?
Malloc and free are slow and inefficient
How did you find out?
As for your last point about pointers, you can implement those features in a standard-conforming manner yourself, and guess what, they're already implemented by someone else.
I don't think C is a nice language. I just think you don't have shit to say about it.
Name:
Anonymous2009-08-22 9:26
Hey, you're complaining about C's libs, but you should take a look at the Prelude. Most functions there are defined in a slow, non-tail-optimised, O(n2) way.
I don't think C gets enough credit. Sure, C doesn't love you. C isn't about love--C is about thrills. C hangs around in the bad part of town. C knows all the gang signs. C has a motorcycle, and wears the leathers everywhere, and never wears a helmet, because that would mess up C's punked-out hair. C likes to give cops the finger and grin and speed away. Mention that you'd like something, and C will pretend to ignore you; the next day, C will bring you one, no questions asked, and toss it to you with a you-know-you-want-me smirk that makes your heart race. Where did C get it? "It fell off a truck," C says, putting away the boltcutters. You start to feel like C doesn't know the meaning of "private" or "protected": what C wants, C takes. This excites you. C knows how to get you anything but safety. C will give you anything but commitment
In the end, you'll leave C, not because you want something better, but because you can't handle the intensity. C says "I'm gonna live fast, die young, and leave a good-looking corpse," but you know that C can never die, not so long as C is still the fastest thing on the road.
Name:
Anonymous2009-08-22 16:10
>>43
This is utterly superb pasta material that deserves a bump.
>>43
Naw, C isn't like that at all. It's backwards and primitive. It may seem to ignore the rules, but that's only because it hasn't managed to grasp their purpose. C likes to drive fast, but doesn't know why it should wear a seatbelt or slow down when it's raining. C will always be around — someone has to take care of the basics — but it will never be good for anything but delivering pizzas and selling its body. And it will never be able to satisfy your needs beyond those most carnal.
Name:
Anonymous2009-08-22 17:24
>>46 And it will never be able to satisfy your needs beyond those most carnal.
>>46
Mmmmm... C satisfying my most carnal desires. Why program in Haskell if it isn't going to fuck me in the ass with a strap-on while wearing a Richard Nixon mask?
Name:
Anonymous2009-08-22 20:30
>>49
That's mental. You'll need another language for that. Haskell would probably do it. C won't.
Name:
Anonymous2009-08-22 20:33
>>49
C is capable of satisfying carnal desires. You need a higher class language for higher class interactions.
Name:
Anonymous2009-08-22 22:30
>>49
You seem to be thinking that “carnal” means “sexual”. Typical of a Ctard.
Name:
Anonymous2009-08-22 22:45
>>52
That's right, it means "full of meat." Har har that's what she said
Name:
Anonymous2009-08-23 12:16
And then there's Haskell...
Haskell is like "that girl." You know the one...
You never really went steady, but you'd run into her from time to
time while knocking around in disreputable joints, usually late at
night, every several months or so. She looked so hot, so sleek, so
sexy, so expressive, so exotic. You'd end up back at her place and
the night would just... take off. A complete blur of hot, sweaty,
feverish, delirious, fumbling passion. You'd do things to each
other... you'd do things to her, she'd do things to you... things
that you're not even sure have names, that you're pretty sure are
illegal almost anywhere. Even her kinks have kinks --- and after one
of these nights, you'd realize that you yourself had a lot more kinks
than you. And it wasn't just physical, it was --- cerebral.
Ethereal. Transcendent. But it would all whiz by in a blur, and by
morning you'd find yourself lightheaded, a bit confused, and
stumbling homeward to your regular gal.
Over the next few days and weeks you'd find yourself occasionally
drifting away, thinking about her. Haskell. You'd be there, banging
away at your regular girl, and find yourself thinking "you know, if I
was with Haskell, I'd be doing this completely differently." You'd
think "I could be doing so much bigger and better stuff with
Haskell." Now, your regular girl, she's not as exotic as Haskell.
Pretty, maybe, if you're lucky. (Perhaps your regular girlfriend's
name is Python. ;-) But not nearly as --- weird. Wild. Cool.
Exciting. Don't get me wrong --- your girl, she's wonderful. You've
got a wonderful relationship. She's --- comfortable. You can bang
away at her all day and night. She's accommodating. Easy going.
You work well together. But --- confidentially --- she's, well,
maybe just a little bit boring. You'd catch yourself thinking these
things, and the guilty pangs would get to you... You'd quash the
thoughts, buckle down, and get back to banging away. Comfortable...
there's a lot to be said for that, ya know? Comfortable... just
keep telling yourself that.
Months would go by. Late some night you'd find yourself out,
disreputable places again. Maybe that hacker bar, LtU. Somebody'd
slip you an URL for some renegade paper, you know, one of *those*
papers. You'd run into Haskell again. And the whole thing starts over.
Eventually, you're going to get the ultimatum. Haskell's ultimately
just like any other girl on some level; she needs commitment.
Eventually, after one night of wild, feverish, kinky, abstract
passion, she's going to say to you: "All these times, and you don't
understand me at all! You know, you're going to have to get serious,
mister! I've got needs, too. You're going to have to get serious
about my monads, or that's the last time you're going to play with
them! Got it?"
...and then, you've got to make The Choice.
Chances are, you're going to go back to your regular gal. Haskell's
just too much for any one man, probably. She leaves a trail of
broken, brainy, embittered PhDs and former programmers behind her.
She ruins you for the RealWorld. You can ride a while, but you
probably can't go the distance with her. Go back to your regular gal
and try not to think too much about what you've seen. Done. Felt.
Thought.
Maybe you can salvage a little happiness; but it'll be hard. After
all... you've tasted Haskell.
>>57
Actually, they aren't. The sphinctres' natural state is loose, it's just out nervous system that keep them tight. Without it, they are as loose as a Mexican whore.
Name:
Anonymous2009-08-24 15:40
>>58
I think >>57 was making a rigor mortis ``joke''.
>>65
Fucking meiru field. Case sensitivity is a relic of the past. If I can type my password in upper or lower case, I should be able to type my sage that way as well.