Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

How to tell if a language is shit

Name: Anonymous 2012-07-29 17:48

The best way to determine how much a language sucks is by counting how many ``harmful'' parts of the language there are. These are the warts and duplicate features that programmers tell others to avoid. They're usually there for backwards compatibility or to attract programmers from another language. For example, C++ programmers want you to use new, std::vector and functors instead of malloc, arrays and function pointers from C. Why do you need three (malloc/free, new/delete, new[]/delete[]) incompatible allocators and deallocators? Why do you need at least five (C local/static array, malloc, new[], std::vector, std::array) different ways to make contiguous arrays? Why do you need two incompatible ways to pass functions as arguments? Why do C++11 lambdas have unique types? A good language has only one way to make an array, maybe two for expandable and fixed size or heap and stack. A good language has only one way to allocate heap storage for each type of heap (manual/region/GC heap are good distinctions, C heap/C++ heap is not). A good language treats all functions with the same return type and parameter types the same. C++ is shit.

Name: Anonymous 2012-07-29 17:56

Python is shit because one word the forced indentation of the code THREAD OVER

Name: Anonymous 2012-07-29 18:09

Good luck finding such stuff in Go.

Name: Anonymous 2012-07-29 18:37

this is why javascript is poised to become the ultimate lingua franca of computing

Name: Anonymous 2012-07-29 18:52

>>4
Except it's utter shit.

Name: Anonymous 2012-07-29 19:03

>>4
javascript is the x86 of programming languages

Name: Anonymous 2012-07-29 19:09

>>1
Actually, you count the hacked-together parts (start with 1) and multiply it by the number of unorthogonal features.

Name: Anonymous 2012-07-29 19:48

A good language has only one way to allocate heap storage for each type of heap
Please, you're embarrassing yourself. `operator new[]`, `malloc()` and `operator new` are defined in the implementation libraries. They can easily be replaced with your own custom allocators for better performance, and it is common practice to do so in high performance code. `new` is not just `malloc()` in disguise. It is type safe and overloadable, among other things.

C++ is not for weak programmers who need their hand held. The programmers has to know what he's doing. It is not right to expect the language spec to avoid "harmful" features because the programmer is too incompetent to use them properly.

The same can be said for C arrays (there are many distinctions between C++ and C arrays, but since you obviously don't know C++, we'll not consider this) vs. STL vectors or Boost arrays. Although they are all contiguous, there are a lot of differences in their structure, which make them appropriate under particular circumstances, that would be obvious if you did two minutes of research.

Name: Anonymous 2012-07-29 21:18

(define (how_to_tell_if_a_language_is_shit x) (! (= x LISP)))

Name: Anonymous 2012-07-29 22:13

>>9
(define (how_to_tell_if_a_language_is_shit x) ( (= x LISP)))

Name: Anonymous 2012-07-29 22:29

For example, C++ programmers want you to use new, std::vector and functors instead of malloc, arrays and function pointers from C.
Except for the extremists, this is not true.

Why do you need three (malloc/free, new/delete, new[]/delete[]) incompatible allocators and deallocators?
malloc/free allocates and frees a plain block of memory, nothing more.
new/delete does what malloc/free does (look in the library implementation and you're likely to see it call them), plus call the appropriate constructor/destructor on the block of memory. It can also throw an exception instead of return a null pointer if the memory can't be allocated.
new[]/delete[] is similar to the latter except it allocates/deallocates memory for one or more objects, keeping track of the count, and calls the constructor/destructor the number of times requested.

Name: Anonymous 2012-07-29 23:00

>>1
>>2
>>9

get your asses back to /g/

Name: Anonymous 2012-07-29 23:21

>>12
get your ass back to /g/, sepples ``programmer''

Name: Anonymous 2012-07-29 23:32

>>13
Lisp is shit

Name: Anonymous 2012-07-30 0:53

>>11
Exceptions thrown in destructors?  Yeah, right.

Even Python ignores exceptions thrown during __del__.  This is one of the reasons why 99% of C++ programs are complete and utter shit (and so are 99% of C++ programmers who are really just fecal diggers).

The reason you gave for the existence of new[] and delete[] is laughable, considering the frequency of errors even experienced C++ programmers dealing with them.  People avoid them like plague.

Name: Anonymous 2012-07-30 4:10

>>12
I don't go to /g/, you buttangry ``faggot"!

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-07-30 5:22

>>15
operator delete shouldn't throw an exception. The standard says throwing an exception in a destructor is also undefined.

considering the frequency of errors even experienced C++ programmers
I wouldn't call those programmers "experienced" if they can't understand something simple like that. At least, I don't consider myself particularly expert with C++, but I can already write what the standard new/delete operators do, from memory. Really basic stuff.

Name: Anonymous 2012-07-30 5:27

>>9-10
Ridiculously unidiomatic Lisp. That's probably not even a real implemented language.

Name: Anonymous 2012-07-30 12:36

>>17
Then you are really inexperienced because it's easy to miss a [] after delete and then wonder about mysterious memory leaks or parasitic autoptrs.

Name: Anonymous 2012-07-30 14:32

>>19
shared_ptr/unique_ptr?

Don't change these.
Name: Email:
Entire Thread Thread List