Your Language's Worst!

[ZekeDragon]

This is a language war, but a language war in a different manner. Instead of espousing the best parts of your chosen language(s), you're going to be talking about the worst! Give your chosen language(s) some valid criticism!

The rules are simple

1. You must come up with at least one and up to three valid criticisms of your chosen language(s).
2. Each valid criticism should be explicable in one paragraph and possibly a code sample.
3. Each criticism you make should be unique. If it's already been listed by someone else, choose something else!
4. The language(s) you choose to criticize should be ones you've actually programmed projects with. You have no reason to criticize a language you've never used.
5. Don't take other peoples criticisms of your favorite language so seriously!

Here's an example:

Java:

• Choosing to have BigInteger as an immutable type. It should be rather obvious that BigIntegers would be used with intense mathematical calculations, and forcing the user to create a new BigInteger object EACH time you perform a mathematical calculation with it is fantastically slow. Even if Java came with a MutableBigInteger type similar to how Strings have a StringBuilder this would work as well. The only way to do this is with your own MutableBigInteger class.
  

  public class Doubler {
      public static void main(String[] args) {
          BigInteger num = new BigInteger("1");
          BigInteger two = new BigInteger("2");
          for (int iii = 0; iii < 100; ++iii)
              // Each loop iteration generates a NEW BigInteger!
              num = num.multiply(two);
          System.out.println(num.toString());
      }
  }

• Ridiculously long lines of code. Because Java requires static methods to be resolved through their according objects, you end up with extremely long lines of code, which in the case of trying to live within the 80 character limit, is frustrating. Consider giving a "GroupBox" style border to a JPanel:
  

  import javax.swing.*;
  import java.awt.Color;
  import java.awt.Dimension;
  public class JGroupPanel extends JPanel {
      public JGroupPanel() {
          // Look at this friggin' line! O_O
          this.setBorder(BorderFactory.createCompoundBorder(BorderFactory.createTitledBorder(BorderFactory.createLineBorder(Color.BLACK), "Title"), BorderFactory.createEmptyBorder(5, 5, 5, 5)));
      }
      public static void main(String[] args) {
          JFrame frame = new JFrame();
          frame.setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.LINE_AXIS));
          frame.setMinimumSize(new Dimension(300, 300));
          frame.add(new JGroupPanel());
          frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          frame.setVisible(true);
      }
  }

Anyway yeah, that's the idea. I can't wait to see what you guys come up with!

[JCoder]

Scala:

1. For comprehensions can be much slower than while, if the content of the loop is fast:

for (i <- 1 to 1000000) doSomethingFastAndSimple

is much slower than:

var i = 0
while (i < 1000000) i++; doSomethingFastAndSimple

2. The distiction between a lambda expression taking n parameters and lambda taking one parameter of tuple type with n values is somewhat funny:

val hashMap = Map("abc" -> "def", "xyz" -> "lkj")
hashMap.foreach {case (key, value) => 
  println("Key is: " + key + " value is: " + value) }

val list = List(9,34,345,5,7,21,49)
list.sort((a, b) => a < b)

3. Implicit conversions can be tricky. But unfortunately no other language has anything as powerful as Scala's implicit conversions, so the complexity here is justified.

object SafeEquals {

  trait Related[T, U]
  implicit def related[T, U <: T]: Related[T, U] = null

  class Equals[A](o: A) {
    def ===[B](other: B)(implicit related: Related[A, B]) = o == other
    def !==[B](other: B)(implicit related: Related[A, B]) = o != other
  }

  implicit def anyToEquals[A](o: A) = new Equals[A](o)
}

BTW: The criticism of Java BigIntegers is not valid. Immutable objects are your friend. They are not necessarily slower than the mutable ones. You save only on making a copy of the object, wich is cheap compared to the actual calculation. The problem with BigIntegers is that the syntax sucks. Operator overloading as in Scala would be nice.

[MeTh0Dz]

3. Implicit conversions can be tricky. But unfortunately no other language has anything as powerful as Scala's implicit conversions, so the complexity here is justified.

Lol, that's a bit ridiculous.

[JCoder]

Yep. Scala has tricky implicit conversions. Contrary to C++ implicit conversions which are pure evil (and less powerful).

Ok, while we are at C++ - the C++'s worst of the worst:
Just to list three:

1. Header files: ancient compile/link model taken from 70's. Modularity based on text file inclusion.
2. Templates: slow compile times, code bloat, scarying error messages, covariance tricky to get right
3. Weak and overcomplicated type system that is pretending a strong one.

[MeTh0Dz]

I was loling because your statement was so ridiculously inaccurate and shortsighted.

[JCoder]

If so, can you give an example of language with more powerful implicits than Scala's? And with better power to evilness ratio? I know only of two other languages that support user defined implicits: C++ and C#. But both are extremely limited.

[MeTh0Dz]

If so, can you give an example of language with more powerful implicits than Scala's? And with better power to evilness ratio? I know only of two other languages that support user defined implicits: C++ and C#. But both are extremely limited.

Look at what you said.

... no other language has anything as powerful as Scala's implicit conversions ...

This implies that Scala's implicit conversions are the most powerful concept in any language, not that they are just the most powerful implicits.

It's important to convey your point properly.

[davidthefat]

Brain ****

-Its just absolutely worst thing to use to program anything. Its so messy that you can't make any practical applications with it. Just see the Hello World code and you will understand... It literally fucks with your brain

+++++ +++++             initialize counter (cell #0) to 10
[                       use loop to set the next four cells to 70/100/30/10
    > +++++ ++              add  7 to cell #1
    > +++++ +++++           add 10 to cell #2 
    > +++                   add  3 to cell #3
    > +                     add  1 to cell #4
    <<<< -                  decrement counter (cell #0)
]                   
> ++ .                  print 'H'
> + .                   print 'e'
+++++ ++ .              print 'l'
.                       print 'l'
+++ .                   print 'o'
>++ .                   print ' '
<< +++++ +++++ +++++ .  print 'W'
> .                     print 'o'
+++ .                   print 'r'
----- - .               print 'l'
----- --- .             print 'd'
> + .                   print '!'
> .                     print '\n'

[MeTh0Dz]

Brain ****

-Its just absolutely worst thing to use to program anything. Its so messy that you can't make any practical applications with it. Just see the Hello World code and you will understand... It literally fucks with your brain

+++++ +++++             initialize counter (cell #0) to 10
[                       use loop to set the next four cells to 70/100/30/10
    > +++++ ++              add  7 to cell #1
    > +++++ +++++           add 10 to cell #2 
    > +++                   add  3 to cell #3
    > +                     add  1 to cell #4
    <<<< -                  decrement counter (cell #0)
]                   
> ++ .                  print 'H'
> + .                   print 'e'
+++++ ++ .              print 'l'
.                       print 'l'
+++ .                   print 'o'
>++ .                   print ' '
<< +++++ +++++ +++++ .  print 'W'
> .                     print 'o'
+++ .                   print 'r'
----- - .               print 'l'
----- --- .             print 'd'
> + .                   print '!'
> .                     print '\n'

It's an esolang...

[davidthefat]

It's an esolang...

I am clearly aware of it