Talk:YourLanguageSucks
From TheoryOrg
Contents |
CSS Sucks
- Contrary to your argument given for a lack of transparency, CSS actually does support transparency as of CSS3. This is implemented via the opacity attribute. --Crazy Pothead 23:58, 4 October 2007 (PDT)
- CSS 3 is not an official spec yet and is not supported by all browsers. --Matt Chisholm
- This is not a problem of CSS A71104
- CSS 3 is not an official spec yet and is not supported by all browsers. --Matt Chisholm
Python sucks
- Removed There are strings, and then there are Unicode strings. No justification was given. Python's Unicode strings allow for superior Unicode support than Ruby & PHP, and nothing in Python forces you to use Unicode strings -- you can write an entire application that uses only byte strings and do encoding support the Ruby/PHP way.
- Removed The syntax for singleton tuples,
(x,), is confusing, and different from the syntax for singleton lists. Python syntax for tuples uses commas; parenthesis are used to disambiguate when the context requires it (mostly on expressions). For example:
spam = 1, 2, 3 spam = 1, + 2, 3 # spam will be 1, 2, 3 first, second, third = 1, 2, 3 alone = 1,
- Removed:
-1 ** 2 is -1 ???. The unary-operator has lower precedence than**. So-1**2actually means-(1**2).(-1)**2is 1. - Changed: Added a notice for != and <>
- Removed: there's pow() and **
PHP
- code must be inserted between
<?phpand?>tags- how can the interpreter know where the html starts and where the php starts without start and end tags? --Alias
- from the caller context --Cesare Di Mauro
- It doesn't need the ?> if the entire file is PHP (in fact, this is preferable). Matt 15:54, 18 June 2009 (UTC)
- how can the interpreter know where the html starts and where the php starts without start and end tags? --Alias
- there's one
is_typefor eachtype:is_int,is_float,is_string, etc. to check for a proper type- so? --Alias
- a single function (or operator) for identity check will be a better solution --Cesare Di Mauro
- so? --Alias
-
++and--cannot be applied to booleans
Object-oriented programming sucks? Perhaps not.
- "Object-oriented programming is an exceptionally bad idea which could only have originated in California." --Edsger Dijkstra.
-
- Well he was dumb. OOP dramatically improves the scalability of programs. --Matt Chisholm
- I agree; remember the "arrogance in computer science is measured in nano-Dijkstra's" thing? A71104
- Suggesting that Dijkstra was dumb, is itself dumb. How many Turing awards have you won? Much of the scalability of OOP comes from adopting Dijkstra's principles of structured programming. Far too many OOP proponents don't seem to realize that many of their techniques come from structured programming. This seems to be because they learned OOP without previously knowing about structured programming, and so they incorrectly think that OOD is the origin of these techniques. Furthermore, Dijkstra's quotes usually need to be understood in the context of where and when they were said. I can't find a reference for where or when he said this. That statement could have easily been made in the early 1970's or even the 1960's. OOP has come a long way since then. One of his famous quotes about BASIC was made in 1975, and made a lot of sense then, but wouldn't be terribly fair in the context of Visual Basic of today. --Bill Davidson
- Well he was dumb. OOP dramatically improves the scalability of programs. --Matt Chisholm
-
- Object oriented programming has been shown to have no significant difference in productivity than standard procderal programming.
-
- That's actually just not true.
-
- If this "has been shown" then cite the source. --Matt Chisholm
- Done. A71104
- If this "has been shown" then cite the source. --Matt Chisholm
-
C++ sucks? Perhaps not.
The C++ section should be about five times longer than the PHP section. :-) Matt 15:56, 18 June 2009 (UTC)
I think the reasons for why C++ sucks are vague and in some cases debatable. I would like to see more concrete examples.
- C++ doesn't enforce a single paradigm. Neither procedural or object-oriented are enforced resulting in unnecessary complication.
-
- Isn't that a good thing?
-
- None of the languages on this page enforce a single paradigm. How is this problem specific to C++? --Matt Chisholm
- Not true: Java enforces object oriented programming (you can't do procedural programming in Java, there are no functions). A71104
- You absolutely can do procedural programming in Java. Just make all of your methods static. You can even write your entire program in one class. You can be as procedural as you want. Methods that have a return value are really just glorified functions, with the implication that they are attached to an object. However Java's static methods are only attached to a class, not a proper object. Java encourages OOD, but it doesn't really force it. You can write horrible code in Java as easily as with Fortran. -- Bill Davidson
- Not true: Java enforces object oriented programming (you can't do procedural programming in Java, there are no functions). A71104
- None of the languages on this page enforce a single paradigm. How is this problem specific to C++? --Matt Chisholm
-
- It requires a bulky runtime.
-
- That's not true. You don't have to use MFC, and you can program really small programs if you turn off function header generation at the linker.
-
- What does "bulky" mean? C++'s runtime is lightweight compared to every other language on this page. --Matt Chisholm
- You're right, I removed that point. --A71104
- What does "bulky" mean? C++'s runtime is lightweight compared to every other language on this page. --Matt Chisholm
-
- Not practical for low level system development and quickly becomes a mess for user level applications.
-
- That's actually not true. The __asm {} construct allows you to make fairly arbitrary code so long as you tell the compiler to ignore function headers.
- The GNU __asm {} construct is all but practical. Instead, asm blocks using Intel syntax (which can be found on Microsoft compilers) are much better, but if you are programming in C++ you are not supposed to use much assembly, otherwise you are programming in assembly. --A71104
- That's actually not true. The __asm {} construct allows you to make fairly arbitrary code so long as you tell the compiler to ignore function headers.
-
- Why is it not practical for low-level system development?
-
- Why does it quickly become a mess for user level applications? --Matt Chisholm
- Because it supports multiple programming paradigms, so a programmer could write object oriented parts and procedural parts, leading to a very heterogeneous and really ugly design, which complicates code maintenance. --A71104
- Why does it quickly become a mess for user level applications? --Matt Chisholm
-
- The standard has no implementation for exception handling and name mangling. This makes cross-compiler object code incompatible.
- Why does the lack of exception handling make cross-compiler object code incompatible? --Matt Chisholm
- Not the lack of exception handling, but the lack of any specification that forces an implementation of exception handling; we are talking about *binary* incompatibility. A71104
- Why does the lack of exception handling make cross-compiler object code incompatible? --Matt Chisholm
- C++ supports 'goto'.
-
- Are we complaining that C++ is too high level or too low level here? Even if it didn't, you could do
-
register int f = *location -
__asm_ volatile ("jmp eax", "a=", f)- Neither of them; we are complaining (as it's widely accepted) that the goto construct brings to really bad designs, and modern languages should just *not* offer such a deadly instrument. A71104
-
- No widely use OS supports the C++ ABI for syscalls.
-
- And why should they? The ABI necessitates an underlying operating system (vtables et. al don't appear by magic ya' know), and if C++ enforced them it would make C++ unable to do low level systems programming. Silly.
-
- I removed the dispute note: most of the discussion points have been answered. --A71104
Java sucks
- The assertion: Nearly everything is wrapped with objects and many things must be buffered, even those things that don't really need to be objects or be buffered
must be adequately explained with examples, because it doesn't make much sense: it is left to the programmer whether to buffer something or not. I think that it should be removed. --A71104
Ruby sucks
"No real support for arbitrary keyword arguments (key=value pairs in function definitions are positional arguments with default values)"
Not sure what this is supposed to mean. Hashes as the last parameter of a method require no braces:
def foo(options); end; foo(:foo => 'bar', :baz => 'quux')
This requires no order. In 1.9, this can become:
foo(:foo: 'bar', :baz: 'quux')
Matt 15:51, 18 June 2009 (UTC)

