* Primitive type system
* No overloading
* Limited possibility of data abstraction, polymorphism, subtyping and code reuse
* No metaprogramming except preprocessor macros
* No exceptions
Why C++ sucks
* No garbage collection
* No reflection
* Type system excessively complicated
* No support for variadic functions and variadic templates
* Really hard to write efficient, object oriented mathematical code
* Not even compile time reflection (ie in a template you cannot inspect the parameter type)
Why C# sucks
* Way too prolix
* It has many special purpose constructs (such as yield/foreach)
* Not so powerful generic system
* No compile time metaprogramming facility
Why Java sucks
* No data pointers nor function pointers
* No templates (java 1.5 templates are a fake)
* No operator overloading
* No anonymous methods (C++ operator())
* Extremely verbose to write - and slow to run
Why Haskell sucks
* Indentation dependent syntax
* Types and values live in completely different worlds
* No metaprogramming (solved by Template Haskell)
* It is quite difficult to learn and to use for simple things, expecially if you come from an imperative/OO background. Sometimes, language features, extensions and design patterns are best documented by research articles, instead of tutorials written in an informal style.
Why Nemerle sucks
Some reasons as C#, except first and last.
Why Ocaml sucks
* Too many keywords
* Ugly syntax
* No templates and oveloading (unless you are using a still a bit limited and incompilete gcaml)
* Strange behavior of '_a and 'a types.
Why Ruby sucks
* Slow
* Complex
* Surprising
* Inconsistent
* Bad embedding
* No native threads
* No m17n
Name:
Anonymous2007-09-22 11:24 ID:qdW+dymY
Why Lisp sucks
* Incomplete implementations
* Scheme is a joke
* Common lisp is worse than scheme
* Has syntax covered, but sadly.. a language isn't made by
the syntax, but by the practical usability, speed, etc.
* Has more blind fanboys than perl, or python could ever hope
to have.
* Most importantly, claims have been made that many LISP
enthusiasts enjoy emacs, which would provide for epic
level failure.
Haskell's syntax isn't indentation dependent, you can use braces and semicolons instead. And I don't really get your complaint about types and values, care to elaborate?
If you find Haskell difficult to learn/use, then you're the one who sucks. Programming isn't for stupid people.
* "My other car is a cdr..."
* "How do you pronounce..."
* "Hi, I want to know how to hack myspace..."
* "How do you make [type of game]"
* /mu/ elitism
* /b/ faggotry and paedophilia
* /n/, /longue/ and /newpol/ racism and paranoia
* NO EXCEPTIONS
what doesn't suck then?
What makes you think there is such a thing?
Also, since when do you need garbage collection? Only retards and fags can't keep track of that.
Only retards and fags are willing to waste their time keeping track of their allocations.
It never ceases to amaze me how some people think they're perfect programmers, despite all evidence to the contrary. Manually managing memory is bug-prone busy-work that isn't needed.
Walter Bright said, and I think he was right: Garbage Collection allows you to write code that makes less allocations because you don't need to keep track on who is the responsability to free memory. Many people programming in C tend to prefer static memory management if they can.
Name:
Anonymous2007-09-22 20:26 ID:c085tPwf
bash is the language of the future
Name:
Anonymous2007-09-22 20:33 ID:TQ76e0Km
The ocaml thing is silly, you don't need templates and if you really want exactly templates you can use camlp4 which comes with ocaml.
Also ocaml has functors which are how templates are usually used.
If you want to pick on ocaml you mention:
* Poor functorization
* Boxing of floats
* No type-classes
Name:
Anonymous2007-09-22 20:34 ID:TQ76e0Km
The haskell thing totally misses the point that lazy evaluation is a fucking memory pig. See darcs.
Seriously. It kicks ass now and will continue kicking ass in the future. You have all the low level tools of C (pointers, references, etc.), decent OOP tools without the fucked up shitty syntax of C/C++, and strings/automatic memory management if you want to use them. Plus you can import C libraries (SDL, etc.) and use them directly, without a FUCKING PARSER BITCHING ABOUT SEMICOLONS AT THE END OF EACH LINE.
>>31
AND it still produces programmers that have no fucking idea how to interact with hardware, with getting the screen pointer as easy as saying
screen
you produce a breed of programmers that the rest of the programming world frown upon
Name:
Anonymous2007-09-23 0:34 ID:m/8kri+9
>>23
gc is just a way of saying, I'm not professional enough to manually manage memory, so I'll let a professional do it
as much as you want to believe the garbage collector is born of magic, it isn't, someone somewhere had to code it and since they are human, bugs in gc can go unnoticed
so if you don't believe you have the skill to manually manage memory, let someone else's code do it, whether that someone is another programmer or another programmer's code (the gc), these people shouldn't touch memory anyway
gc is just a way of saying, I'm not professional enough to manually manage memory, so I'll let a professional do it
You're an idiot. Let me put it to you this way:
a) Someone else writes the GC once, and hammers all the bugs out since everyone uses it. It's a small chunk of centralized code.
-or-
b) Everyone keeps reinventing the wheel, and making bugs. These bugs are distributed across your entire codebase. To add insult to injury, it takes longer to write these things in the first place.
You realize that time spent with b) could be better spent elsewhere? Like, you know, doing what you're paid to do, Mr. Professional? I hate to break the news to you, but businesses consider bugs a loss, it's functionality they're after.
I am 100% certain you have no real-world development experience. Go back to fapping over your idiotic 10-line toy programs and hanging out with people who think anything higher than assembly is eeeeevil because they dare to automatically create and pull down stack frames. You probably think lint and valgrind are evil too, because professional programmers don't use tools made by other professionals.
Fuck. GTFO/prog/, brat.
Name:
Anonymous2007-09-23 3:10 ID:gvUP5yCP
That is why there is Assembly you faggot,
Name:
Anonymous2007-09-23 3:58 ID:1PAati9x
>>1
You forgot to include a section on why you suck.
High-level languages offer built-in solutions to commonly encountered
problems. For example, it’s well known that the vast majority of program
errors have to do with memory mismanagement. Before you can use an
object, you have to allocate some space for it, initialize it properly, keep
track of it somehow, and dispose of it properly. Of course, each of these
tasks is extraordinarily tedious and error-prone, with disastrous consequences
for the slightest error. Detecting and correcting these mistakes are
notoriously difficult, because they are often sensitive to subtle differences
in configuration and usage patterns for different users.
Use a pointer to a structure (but forget to allocate memory for it), and your
program will crash. Use an improperly initialized structure, and it corrupts
your program, and it will crash, but perhaps not right away. Fail to keep
track of an object, and you might deallocate its space while it’s still in use.
Crash city. Better allocate some more structures to keep track of the structures
that you need to allocate space for. But if you’re conservative, and
never reclaim an object unless you’re absolutely sure it’s no longer in use,
watch out. Pretty soon you’ll fill up with unreclaimed objects, run out of
memory, and crash. This is the dreaded “memory leak.”
What happens when your memory space becomes fragmented? The remedy
would normally be to tidy things up by moving the objects around, but
you can’t in C++—if you forget to update every reference to every object
correctly, you corrupt your program and you crash.
Most real high-level languages give you a solution for this—it’s called a
garbage collector. It tracks all your objects for you, recycles them when
they’re done, and never makes a mistake. When you use a language with a
built-in garbage collector, several wonderful things happen:
• The vast majority of your bugs immediately disappear. Now, isn’t
that nice?
• Your code becomes much smaller and easier to write and understand,
because it isn’t cluttered with memory-management details.
• Your code is more likely to run at maximum efficiency on many different
platforms in many different configurations.
C++ users, alas, are forced to pick up their garbage manually. Many have
been brainwashed into thinking that somehow this is more efficient than
using something written by experts especially for the platform they use.
These same people probably prefer to create disk files by asking for platter,
track, and sector numbers instead of by name. It may be more efficient
once or twice on a given configuration, but you sure wouldn’t want to use a
word processor this way.
You don’t even have to take our word for it. Go read The Measured Cost of
Conservative Garbage Collection by B. Zorn (Technical Report CU-CS-
573-92, University of Colorado at Boulder) which describes the results of a
study comparing performance of programmer-optimized memory management
techniques in C versus using a standard garbage collector. C programmers
get significantly worse performance by rolling their own.
OK, suppose you’re one of those enlightened C++ programmers who wants
a garbage collector. You’re not alone, lots of people agree it’s a good idea,
and they try to build one. Oh my, guess what. It turns out that you can’t add
garbage collection to C++ and get anything nearly as good as a language
that comes with one built-in. For one thing, (surprise!) the objects in C++
are no longer objects when your code is compiled and running. They’re just
part of a continuous hexadecimal sludge. There’s no dynamic type information—
no way any garbage collector (or for that matter, a user with a
debugger) can point to any random memory location and tell for sure what
object is there, what its type is, and whether someone’s using it at the
moment.
The second thing is that even if you could write a garbage collector that
only detected objects some of the time, you’d still be screwed if you tried
to reuse code from anyone else who didn’t use your particular system. And
since there’s no standard garbage collector for C++, this will most assuredly
happen. Let’s say I write a database with my garbage collector, and
you write a window system with yours. When you close one of your windows
containing one of my database records, your window wouldn’t know
how to notify my record that it was no longer being referenced. These
objects would just hang around until all available space was filled up—a
memory leak, all over again.
>>39
No, you do it because you want to. You're too scared to admit to yourself, family and friends (do those in /prog/ actually have these?) that you are a faggot.
How do you justify saying that objects in C++ aren't objects when the code is running? Sure they're mostly structs with mangling and other magic, but.. what do you think most of these other languages are? Do you honestly think most of these languages at the lowest levels actually have objects? It's all "Hexadecimal sludge" behind the scenes, and really.. there are working C/C++ garbage collectors out there.. Eg. libgc. Many do not use this approach because speed matters above all else.
Name:
Anonymous2007-09-23 10:27 ID:fHhgNgiw
Many do not use this approach because speed matters above all else.
Except that it doesn't have much to do with speed anymore. If you use a language like C++, you're pretty much stuck with a conservative stop-the-world garbage collector. This is unfortunate, because it can cause delays.
Oh, wait, freeing something isn't deterministic either, unless you're doing custom memory management. But wait! You can do custom memory management with many GC'd languages too.
If you're writing for speed, you avoid allocating and deallocating to the heap. That applies whether or not you use a GC.
Now, add the wrinkle that modern GCs in higher-level languages can be incremental copying generational collectors. They give you O(1) allocation, and because they're incremental the delay is very low -- some are so fast their delay is on the order of that of a context switch.
EXPERT PROGRAMMERS call malloc one time during execution of their programs. Garbage collection languages are for people whose head is full of landfill.
Name:
Anonymous2007-09-23 14:37 ID:nLcgiJvV
>>45
You can't even say EXPERT PROGRAMMERS right. Why would I listen to you?