Difference between revisions of "Talk:YourLanguageSucks"

From Theory.org Wiki
Jump to: navigation, search
(PHP: No integer division)
m (Added signature to the edit made by Squingynaut.)
Line 113: Line 113:
* '''there's no integer division, just floating point one, even if both operands are integers; you must truncate the result to have back an integer'''
* '''there's no integer division, just floating point one, even if both operands are integers; you must truncate the result to have back an integer'''
** Seems to work fine for me. In fact, the opposite appears to be true: <code>echo(gettype(5/1)); echo(gettype(5.0/1.0));</code> The first returns type integer, the second returns type double. If echoing the result of the calculation instead of the type, both simply return "5".
** Seems to work fine for me. In fact, the opposite appears to be true: <code>echo(gettype(5/1)); echo(gettype(5.0/1.0));</code> The first returns type integer, the second returns type double. If echoing the result of the calculation instead of the type, both simply return "5". -- [[User: Squingynaut|Squingynaut]]
== Object-oriented programming sucks? Perhaps not. ==
== Object-oriented programming sucks? Perhaps not. ==

Revision as of 14:45, 11 October 2013

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.
      • This is not a problem of CSS A71104
        • If a standard isn't widely supported, then it sucks regardless of whatever good intentions it may have had. The #1 problem web standards have is that browser makers don't give a shit and just do their own damn thing. There's stuff in CSS v1 that isn't handled right across browsers, I've run into it on several occasions (and it usually involves tables). -CppThis

Python sucks

  • "the syntax for conditional-as-expression is awkward in Python (x if cond else y). Compare to C-like languages: (cond ? x : y)" really? I don't see how the latter is clearer - quite the opposite. The python reads as you'd expect it to, and calls back to the normal if: ... else: ... syntax.
  • Removed 'inefficient JSON dumper: leaves spaces along with commas' - takes 'separators' - an argument that allows you to specify the more compact version if you want to make it completely unreadable.
  • 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.
    • It is not the existence of Unicode strings that is the problem. I would say the bigger problem is that the str strings are used for text at all! Fortunately this is fixed in python 3.0. The sad thing is bytestrings and Unicode strings are not interchangeable. There are very very subtle bugs also, that will kick you hard in the butt, for example b64encode WILL BARF if fed unicode strings AND the 63rd and 64th characters are specified. Just guess which one of these will throw a runtime error: base64.b64decode(u'YQ==', u'+/'), base64.b64decode(u'YQ==', '+/'), base64.b64decode('YQ==', '+/'), base64.b64decode(u'YQ==', u'+/'), base64.b64decode(u'YQ==', u'+/'), base64.b64decode(u'YQ=='), and base64.b64decode('YQ=='). They should all be equivalent, but the first two barf out. As base64 is embedded in text data, the objects might as well be unicode. --Ztane 14:15, 15 July 2011 (PDT)
  • 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,

--Cesare Di Mauro

  • Removed: -1 ** 2 is -1 ???. The unary - operator has lower precedence than **. So -1**2 actually means -(1**2). (-1)**2 is 1.
    • This had popped back on the page. Unary - has never had precedence over ^... not even in my highschool math classes...
  • Changed: Added a notice for != and <>
  • Removed: there's pow() and **
    • well, why did you? isn't that an idiotic duplication? A71104
  • Removed: you can do list[1] = x, but you can't do dict['abc'] = 123 (you have to use the unintuitive dict.update({'abc':123}) instead...)
>>> d= {}
>>> d["abc"] = 123
>>> d["abc"]

perfectly works

...Uh. Well, that's weird. Maybe it wasn't like that in an old version, because I'm sure that didn't work when I tried it ages ago, so I never bothered trying after. But if it worked from the start then I'm just confused. Keiji 09:01, 23 March 2011 (PDT)
  • Removed: "If variables would be need to be declared similar as in JavaScript you would not need this." In JavaScript, you can actually use a variable like:

for(i = 0; i < 10; i++){ and guess what? Now you have the variable i in your global namespace!

  • Removed: "as is typical of major revision updates, there are breaking changes between Python 2.x and 3.x"

There is nothing typical the transition from Python 2.x to 3.x. It was always intended to break backward compatibility when necessary to produce a better language. Therefore, it might be better to think of Python 3.x as a distinct language from 2.x. This is supported by the fact that 2.x has continued to be updated well after 3.x was released, gradually absorbing some features from 3.x in a backward-compatible way.

  • Removed: "what is a bigger indent: more than one white space or one tab? and why shouldn't a programmer be able to use { } to define any arbitrary block?"

This was badly worded at best. The choice to use white space to structure code explicitly was a conscious design decision which the lack of block begin and end characters is consistent with.

Python sucks, but some of these reasons suck worse

Since I am a python fanboy, I'll temporarily recuse myself from editing the python section, and instead make my comments here. I assume that language features that have a greater benefit than cost are not reasons for a language to suck.

  • What is bad about having pow() and **? The benefit is straightforward: Having an operator is nice sugar, and the non-operator version allows modular exponentiation (more efficiently than (x**y) % z). Of course it defaults to mod-infinity, which gives it the same semantics as ** in this degenerate case.
  • Why is it suckage that you have to implement __len__ to get len() to work? That's also how you get support for other operators and builtins, like __add__, __lt__, __getslice__, __contains__, __abs__, and so on. Whoever wrote this must hate operator overloading in general, which is fine, but the complaint should be changed to "single-dispatch operator overloading and builtin overloading is possible"; it would accurately paint what is going on. Or maybe you're actually sad that builtins are not all operators? Like maybe you'd like len() to be an operator, and then also abs(), and then also 'in'? This is just incoherent.
  • I think it's a bit unusual to complain that there are breaking changes from 2 to 3. Isn't that what a major version number change means? But then again, yeah, it sucks, even if it's how every language and every piece of software ought to work.
  • Whoever wrote "no tail recursion" doesn't deserve to complain about it, because the thing one might want is tail call _elimination_ (a.k.a. tail call optimization). Tail recursion, that is recursion via a tail call, is a property of functions as-they-are-written, not a property of languages.

--Jholman 23:41, 12 July 2011 (PDT)

I'll add something to this:

  • "no assignment in while condition": This is a good design decision. It is a very common bug to accidentally only type one = when you've meant to type ==. Convenience isn't always a good thing. (I too, was confused by this one. I've wished that it was legal syntax much less than I wished for a notification in C(whatever) User:waynew:waynew)
  • "No labeled break or continue": The consent is that such features tend to produce bad/complicated code much like goto does. And goto is listed as bad thing for other languages, so this is rather inconsistent.

--Panzi 16:50, 11 April 2012 (PDT)

I'm letting it stay though, because it also means you have to initialize variables before the loop, and it's one of the reasons for the annoying "while True:...if <condition>: break" pattern. --Regebro 05:14, 17 February 2013 (PST)
  • The complain about `(-1) ** (0.5)` giving an error instead of a complex number is ridiculous: when one performs arithmetic in the integer/real/complex realm, it expects to obtain results in the integer/real/complex realm as well. `4 / 3` gives `1`, but `4 / 3.0` gives `1.3333333`. That is, if you write `(-1+0j) ** (0.5)` you get the expected complex result. The same operation in the real realm is not valid, hence the resulting error.

--Jerome 11:44, 19 December 2012 (PDT)

  • "This means in order to change global variables or variables in the closure you need to declare those using global and nonlocal in the function in which you change them." - Uh, and since when is it a BAD thing that you have to explicitly declare that you want a variable to be global? --Regebro (talk) 00:47, 26 June 2013 (PDT)


If no-one is opposed (or I can get support for this idea) I would like to clean the list of reasons why PHP sucks up by putting things in logical sections rather than one muddled list. -- Potherca

  • code must be inserted between <?php and ?> tags
    • how can the interpreter know where the html starts and where the php starts without start and end tags? --Alias
    • It doesn't need the ?> if the entire file is PHP (in fact, this is preferable). Matt 15:54, 18 June 2009 (UTC)
  • there's one is_type for each type: is_int, is_float, is_string, etc. to check for a proper type
  • ++ and -- cannot be applied to booleans
    • why would you do that? --Alias
      • To change it to its opposite. $foo = false; $foo++; $foo #=> true Matt 15:47, 18 June 2009 (UTC)
        • There is a boolean unary NOT operator for that; nobody uses ++ and -- on booleans, moreover ++ would only work on false and -- would only work on true (right?). --A71104

  • Constants do not use $ prefix, like variables
    • I might be missing a point here, but why is this a bad thing? I always though having that distinction was helpful? -- Potherca
  • there are two ways to begin end-of-line comments: // and #
    • Why is this considered to be "sucky"? I though having more choice would make people happier... -- Potherca
  • (instances of) built-in classes can be compared, but not user-defined ones
    • This seems very much like a false claim to me... -- Potherca
  • there's no integer division, just floating point one, even if both operands are integers; you must truncate the result to have back an integer
    • Seems to work fine for me. In fact, the opposite appears to be true: echo(gettype(5/1)); echo(gettype(5.0/1.0)); The first returns type integer, the second returns type double. If echoing the result of the calculation instead of the type, both simply return "5". -- Squingynaut

Object-oriented programming sucks? Perhaps not.

  1. "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.
      • 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
        • Dijkstra was brilliant; he was also an asshole. What kind of person makes world-changing contributions to a field and then refuses to use what that field produces? Psychlohexane 08:01, 27 January 2012 (PST)
    • OOP doesn't suck, but a lot of OOP fanboys make it suck by expecting it to be a magical panacea to all problems everywhere. A well-architected procedural application scales just fine, and crappy OOP is impossible to leverage for anything beyond its intended purpose. My professional experience is due to the rise of ".NET communities" there is a lot more bad OOP (.NET) out there than bad procedural. -CppThis
  2. 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.

C Sucks

The objections to C appear to amount to "it's old" or "I don't know how to use it." There are maybe three objections in there that may have been written by people who have used C (terribly named functions, preprocessor sucks, switch fall-through). Why not add "you have to compile it" or "it doesn't massage my feet"? Mephistopheles 05:11, 20 April 2012 (PDT)

C's standard supports trigraphs and digraphs. Digraphs were added in C99. Seriously? We're really adding language features (which are more likely to CAUSE bugs than to solve problems) to pander to people who's keyboards don't have [ and ] keys? LadyCailin 13:13, 18 December 2012 (PST)

C++ sucks? Perhaps not.

Who ever wrote the C++ Part, has no clue about C++ and Compiler Languages! Did you ever imagine that excatly this complexity of C++ made the most language interpreters possible?Tbe 07:01, 16 April 2012 (PDT)

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.

  1. 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
          • There is no notion of class or static in procedual programming because they strictly belong to OO. Therefore, creating a whole Java programm within a static main method is absolutely OO (stupid, but OO). Going on the subjective side of things, I'd say that it is as easy to create horrible code in Java as in Fortran (and any other language, it simply takes an idiot). -- -- User:groovem
  2. 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
      • I'd even say the opposite is true: A lot of things one would expect of a standard library these days is not included (list/create/remove directories, unicode support, regular expressions, HTTP client, XML, JSON, ...). There are 3rd party open source libs for that, but I'd expect this to be in the runtime. --Panzi 17:03, 11 April 2012 (PDT)
  3. 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
        • Exactly: you're not supposed to use __asm/asm constructs that much, so the GNU syntax will not get in your way. About being practical or handy, it's mostly a matter of taste. -- jmc
    • 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
      • Multi-paradigm is possible in pretty much every other language too though, usually through overuse of the local equivalent of static classes/methods. The bigger issue for a large, robust C++ application with many developers is that no garbage collection plus fast-and-loose memory operations leads to things getting forgotten and bad assumptions about what that pointer actually points to, and thus ugly runtime bugs. This no-bullshit efficiency is arguably C++'s biggest selling point, and also its biggest weakness. -CppThis
  4. 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
  5. 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
  6. 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.
    • What are you calling "the C++ ABI"? The C++ standard doesn't define such a thing (at all). An ABI is generally characteristic of an operating system and CPU. If you define it in the language, you mandate separation from the OS/hardware, which simply isn't what C++ is intended for.
  7. An std::string::c_str() call is required to convert an std::string to a char*. From the most powerful language ever we would have all appreciated a goddamn overloaded operator const char* () const.
    • I think that this is on purpose. Add such an "operator const char*() const" and the compiler will become confused over the meaning of "str[x]". Is it "str.std::string::operator[](x)" or is it "str.std::string::operator const char*()[x]"? If you desperately need such a thing, just subclass std::string and implement your own operator... -- jmc
      • Keeping both operators would take stupidity to a new level; of course you don't need the [] operator any more when you got the const char* one! --A71104
      • Keeping both operators would mostly raise ambiguity to a new level -- any attempt at using [] would lead to ambiguity, so the code wouldn't compile. The real question here is: why do you want to convert a std::string to a char * in the first place? If you want to do so often enough to care, that's your real problem.Jerry Coffin
  8. There's a moment in every C++ programmer's life where he wonders why, why, switch case fall-through has been invented: it's completely useless, and if you forget a break you introduce a bug silently.
    • How is this exactly related to C++? It's a C idiosincrasy, obviously preserved for backwards compatibility with older C code. It's on purpose: if you don't like it, then head for some other language. -- jmc
      • You're right, I should correct and just write: "C++ is backward compatible with C." That's a huge sucks. :) --A71104
  9. Not to mention a classic: [...]
    Just the same as above, something that should be moved to the "C sucks" section... -- jmc
  10. There is try but no finally
    • Why is that even needed? C++ provides superior alternative, called RAII Idiom. Usage of this idiom results in better code, as it throws irrelevant code outside the function, and then the function can focus on only what it needs to do - the relevant thing. Think of `get` member function of a concurrent queue; using RAII object such as scoped_lock, you can throw lock-unlock responsibility outside the function, and the function can focus on only dealing with the relevant thing - `get` an element from the queue. Also, finally block in other languages result in code duplication which RAII easily avoids. -- Snawaz
      • To state it more succinctly: finally is simply a (mostly failed) attempt at compensating for the lack of deterministic destructors. Since C++ has deterministic destructors, it doesn't need a second-rate imitation.Jerry Coffin
  11. A number of the cited problems are now simply obsolete. C++11 added:
    • native threading support
    • memory model
    • Unicode support
    The first two points are now completely irrelevant. Unicode support could still be better. Jerry Coffin
  12. "Throw in function signatures is perfectly useless."
    In C++11, it's been removed entirely, in favor of the 'nothrow' keyword, which only enforces that the function does not throw. Charles B. (talk)
  13. "The standard committee is unable to establish a memory model and thus add multithreading support, lol."
    This statement is rendered obsolete by C++11. The standard now defines a memory model, and more clearly defines atomics, mutable, and const. Herb Sutter recently did a very good talk on the subject, called "Atomic<> Weapons". Charles B. (talk)
  14. "Lambdas have unique types that cannot be expressed and that makes them very hard to use. For example, standard functions cannot return lambdas."
    This is incorrect. The auto keyword can be used to declare a variable to hold a lambda, and lambdas can be implicitly stored in generic std::function<> objects. Charles B. (talk)
  15. "An std::string::c_str() call is required to convert an std::string to a char*."
    ... The alternative is an operator (const char*)() which gets implicitly called in a number of unexpected places, not all of them desirable. This is why the "Safe Bool Idiom" was invented and why C++11 now has explicit operators. Charles B. (talk)

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

  • Exceptions as part of the type system means you have to catch every imaginable exception that might be thrown.
You could just catch java.lang.Exception and let that same type system gobble up the differences. --G H
That's a foolhardy approach which will bite you in the ass eventually - Do you really want to be catching OOM, ThreadAborts, etc? Basic (talk) 10:06, 28 March 2013 (PDT)
  • Many standard classes do parameter checking and manually throw unchecked exceptions such as NullPointerException and IllegalArgumentException. No problem; but what are the assertions for, then?
Assertions are used to test whether assumptions you make about your own code or that of others hold true. This is different from the two mentioned exceptions in that those signal wrong use of code, not wrong code. For example:
  • You passed in null as a parameter to a method that clearly states in its documentation that this parameter should not be null. It throws an NPE to signal your wrong use.
  • You have an instance field in a class that is not final but should never be null (for example, it must have been set by a container by dependency injection). However, it is. Something isn't doing its work. You catch this abnormality via an assertion.
  • You passed in two differently sized arrays as arguments to a method that states the two arrays must be of the same length. It punishes you with an IllegalArgumentException.
  • You have a piece of code that uses two arrays which you've created at two different places but that should logically have the same length. You test this with an assert. If it fails, it's clear that your code is faulty or you've made a wrong assumption. --G H
It's also explained in the official guide: http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage
  • catch clauses can contain only one exception, causing a programmer to rewrite the same code N times if he wants to react the same way to N different exceptions.

This is not true as of Java 1.7: http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html I suggest removing this paragraph

  • The paragraphs:
  • Initialization blocks (both static and non-static) can't throw exceptions.
  • The return statement is not valid within initialization blocks.
  • Instance initialization blocks cannot throw checked exceptions, there must be a no-arg constructor throwing those exceptions in its signature.
That's not why initialization blocks were made. If you want a initialization block that behaves like a method or function, you should take a look at AOP paradigm. I suggest removing this paragraph. -- Rperez 09:17, 21 January 2013 (PST)
  • Arrays are objects but don't properly implement .toString() (if you try to print an array, it just prints hash code gibberish) or .equals() (arrays of the same contents don't compare equal, which causes a headache if you try to put arrays into collections)

I agree with .toString(), but I highly doubt that any programmer would expect(or desire) the equal() method to behave like that on arrays. Why would you want to do that? What would you do, when you already have the arrays in the set and then modify one of them? And what if you don't want one of them to disappear? What if those are vectors for the state machine? One of them disappears. Why? Please, remove the second part of the paragraph.

  • Enums in Java 1.5 are cool, but to use them you have to prefix the enum type, like MyEnum.SomeValue, because they exist in the enum class's namespace, so they are less convenient than just defining int constants

Then don't use them if you don't like them. Enums as a drawback of a Java? Seriously? Saying that enums are less convenient than integer constants is like saying that writing structured code is less convenient than having one method with thousands of code per program.

  • Initialization blocks (both static and non-static) can't throw exceptions

What would that accomplish? See http://stackoverflow.com/questions/2070293/exception-in-static-initialization-block for some explanations on why is that pointless

  • No automatic resource cleanup; instead we get have five lines of "allocate; try {...} finally { cleanup; }"

I may not seeing the point in this paragraph. What resources you mean? Orphaned objects? GC is for that. Closing a file? This is very unclear.

  • No string join function

It's in the apache commons or you can write those three lines of code yourself. Such trivialities only clutter this list. This should be removed.

  • Java has unused keywords, such as goto and const.

I don't see why does it matter. If it's really an issue for some people, then it should be on the bottom of the list.

  • There's int types and Integer objects, float types and Float objects. So you can have efficient data types, or object-oriented data types. Wouldn't it be better to make your object-oriented types efficient?

How exactly is Integer inefficient? Is there some language which handles the same "issue" better? If not, the paragraph should be removed.

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)

XSLT/XPath sucks?

  • There is no concept of types whatsoever. Everything is fundamentally a string. This means that even things that are intrinsically typed are treated as strings fundamentally. For example, sorting on the number of child nodes sorts by string order, not numeric order, even though counting is an intrinsically numeric operation.
<xsl:sort select="count(*)"/>
<!-- sorts like this: 10, 11, 1, 23, 20, 2, 37, 33, 31, 3, 4, 5, 6, 78, 7, 9 -->
  • <xsl:sort> tag has an optional data-type attribute. It's value could be "text" (this is default), "number" or "qname". So if you want to sort numbers you must set this attribute to "number". --Sandh 18:58, 19 June 2011 (PDT)

Python ** comment removed

For instance, in math -2^2 yields 4, while in Python -2**2 yields -4.

I don't know about you, but I've done Further Maths at A-level and Computer Science with Maths at university, and in absolutely every situation where an expression of the form -xy was involved, it means -(xy); parentheses are used explicitly where the (-x)y meaning is desired. Thus, I've removed this "reason" from the Python section. Keiji 09:18, 17 July 2011 (PDT)

As a fellow mathematics graduate, I concur. — Timwi (talk) 04:46, 9 August 2013 (PDT)

Supports 'goto'

Why would a language supporting a feature you don't have to use make it suck? If it was something like "goto is the only way to idiomatically do x", then fine, but the "goto" keyword simply being there? Mephistopheles 05:24, 20 April 2012 (PDT)

  • +1 -- User:groovem
  • Because you might write crappy code that uses goto, and then I have to maintain it. Granted, if you're just that bad of a programmer, you'll figure out how to write crappy code without gotos, but why would a good language provide a feature that is misused 99.9% of the time, and provides other perhaps slightly less eloquent (but still reasonable) ways of handling the other 0.1%? Besides that, things like goto are noob traps, they use it in a simple program, it works fine, so they assume it scales up to other, more complex situations too, which it won't. LadyCailin 10:24, 3 January 2013 (PST)
  • I think some distinction may be in order here. C and C++ have given “goto” a bad name by making it an incredibly sucky feature. You can use it in ways that will crash your program or make the code make no sense. C# has a “goto” that is completely safe. You cannot use “goto” to jump into a for loop, out of a finally clause, or any crazy shit like that. Such a safe goto is as useful and unsucky a feature as any well-respected standard language feature like while loops or method overloading. — Timwi (talk) 04:39, 9 August 2013 (PDT)

Can we add bash?

Bash is a gold mine of things that suck. That should be a section.

Perl 5 sucks because:

Sigil variance is hugely annoying

  Sigil variance is not annoying..  it is necessary and powerful.  
      my @a = ('a', 'b', 'c', 'd');
      my %h = (a => 1, b => 2, c => 3, d => 4);
      my $c = $a[2];         #  scalar; Third element of the array @a
      my @l = @a[1,3];       #  Array slice; @l contains ('b', 'd'); 
      my $a1 = $h{'a'};      #  scalar; the value of %h associated with the key 'a'
      my @v = @h{'b', 'd'};  # Hash slice; @v contains (2, 4)

hashes don't stay in order like they do in most other languages. This can (and, except for luck, does) mean that reading a JSON string into a data structure and then reencoding it without modifying it except to decode and encode will end up with a different JSON string (even without paying attention to anything that might otherwise muck it up like different character encoding schemes or differences in whitespace used by the encoder).

   That is intentional.  It is a security feature, not an accidental flaw to make someones life complicated.  [1]

just like Ruby it has redundant keyword "unless". You can do "if not" at least in three ways, which can lead to confusion and spoiling readability of code:

    If you don't like unless, don't use it.  Also, the two examples given with '!' and 'not' within an if statement are NOT equivalent.  In the example they
    would work in the same way..  but '!' and 'not' are not just synonyms, and there are subtle differences between the two, namely where the sit in order
    of precedence.

what's with all the $,@,%,& things in front of variables? It takes a lot of effort to type those redundancies every single time ... C and most others let you define a type just once, and then you can use it without reminding yourself what it is. In any case, that Perl lets you change the thing depending on what you want to do so it's even more stupid to use say @ and $ in front of the same var.

  Another complaint about sigils?  They are at the core of perl syntax..  if you don't like them, move on along.  As far as "Perl lets you change the thing depending on what you want to do" goes, I don't get it.  $a, @a, %a, &a..  all refer to the symbol 'a' in the symbol table, but are separate entities.  So, a change to @a has no effect upon the contents of %a, $a, etc.