

Reasons to hate any programming language - AmberShah
http://stackoverflow.com/questions/282329/what-are-five-things-you-hate-about-your-favorite-language/282436

======
baguasquirrel
It seems like the good ones about Clojure and Scala are buried beneath the
pile of whining about Java and Ruby.

Anyway, here's my 5 for Haskell.

1\. Sometimes the type system feels backwards. What if I don't want the
compiler to infer types for my variables? What if I want the opposite, where
it does constraint checking on said variables? For example, instead of
inferring the type of the elements of a list, it instead makes sure that they
all belong to a particular typeclass. This is a subtle but huge difference
that makes it difficult for me to program UIs. It can be done, but it seems to
take more effort than it does in some other languages.

2\. Allowing the construction of infinite values leads to some really
frustrating errors sometimes. Sometimes you make mistakes of the form "let x =
f x", which is valid in some situations and not others.

3\. Monad should imply Applicative should imply Functor.

4\. Bytestring handling bites you in the ass sometimes and you don't know it
until your program crashes because you mixed things up improperly. Something
is wrong here, when we are losing type information that should have prevented
this.

5\. Typeclasses should be automatically derived for trivial cases, like
witness types, but there's a strong potential for abuse there.

~~~
samstokes
Accidentally downvoted this while intending to upvote, and now I can't undo -
HN is not very mobile-friendly.

~~~
baguasquirrel
Yea that happens to me too. =/

------
RyanMcGreal
5 Reasons to hate any programming language:

1\. It doesn't _just know_ what I want it to do.

2\. It doesn't accept ambiguous syntax.

3\. I still have to type stuff, even if I use an IDE.

4\. It's not fast enough (for any value of "fast").

5\. It's either too verbose or else unintelligible.

~~~
viraptor
Re. 3: It seems you haven't worked with LabView. On the other hand -- you're
lucky, you haven't worked with LabView.

~~~
X-Istence
Labview, why did you have to remind me of that abomination? It is a real shame
that US FIRST (FIRST Robotics) has decided for the FRC division to use LabView
to have people program their cRio controllers to control their robots.

------
iskander
OCaml:

5) Polymorphic comparison is an ugly hack and land you in an infinite loop
when accidentally used on a circular imperative structure. Type classes
(specifically, an Ord type class) would fix this problem.

4) Arbitrary gaps and inconsistencies in the standard library. Extlib and
Batteries go a long way to fix this, but the language really just needs a
standard library overhaul.

3) Inefficient data representation and wonky hacks to optimize a few special
cases (e.g. 31/63 bit integers).

2) Absolutely terribly C interface which requires deep knowledge of the
runtime data layout.

1) Too many languages in one: OCaml is the awkward synthesis of an awesome
module system (functors, first class modules, etc...), a slightly confusing
but cool object system, the classic ML core, and some random fancy features
(such as polymorphic variants). The interaction of these parts ends up being
pretty confusing.

All that said, it's still my favourite language.

------
scott_s
This question made me realize I don't have a favorite programming language
anymore. I am most experienced in C++, but I've spent enough time with Python
and Haskell to know what I'm missing.

~~~
viraptor
I feel the same... but I have a clear area->language mapping now: networking -
erlang; random quick tools - bash/python; utilities which should work for a
longer time - haskell; anything with gui - c#; stuff that still doesn't quite
fit anywhere - c/python; own experiments - ooc.

However, I have clear "hated" languages: perl, ruby and java.

------
narag
These issues apply to my favorite language and also to the rest. Surely I'm
cheating, but I don't believe it's against the spirit of the question.

I hate the fact that we have to program using plain text. A program is not
really a sequential structure. I'm old, I do know the reasons that this
anachronism has perpetuated. It's been a pain in the ass to deal with
proprietary formats using not quite right tools. But in 2010? Seriously? How
hard is to define a simple format that can be understood by simple editors?

Just an example: comments need to fit the syntax. So there's a need to
delimite them, so some characters or characters combination are not allowed,
or you need to use escape sequences, alternating delimiters or something.
Think of code blocks that are commented out. I absolutely hate the time that I
need to spend "formating" comments. It'd be trivial to create an editor that
used certain special character (one that's < ASCII 32) to delimite comments,
so we would not have to deal with this.

In general, the editor should be syntax-aware, in a more thorough sense (the
editor would perform a first step of compilation), not in the patchy "syntax
highlighting" way in which a quick and dirty scan of text is used. That would
also speed compilation and "intellisense".

It would also eliminate syntax and the artificial differences among languages.
Instead of curly braces vs, indentation vs. begin-end pairs vs. whatever, the
program structure would be recognized by the editor and presented graphically.

The editor should only accept legal constructions (the rest would be
considered comments or incomplete senteces) instead of the distracting red
understrike of Eclipse.

In general, what I most hate is the fact that most languages use the very same
constructs, while still are written differently and you need to learn the
quirks of each of them. A while loop is the same in most languages. What's the
point of learning stupid syntax for a dozen languages. I feel I'm working for
the compiler. It should be the other way around.

I hate languages that do now allow me to do something, just because the
language "designer" decided so. I feel the languages should be construction
kits, not a set of rules to constrain what I can do with them. Why can't I
have garbage collections in some languages and at the same time I can't have
manual memory management in others? Why can't I have a language that accepts
new constructs like Lisp, but not having to be Lisp with all its constraints?

So to summarize, I hate syntax. I hate a = b vs. a := b vs. b -> a vs. let a =
b vs. ... Languages have become walled gardens, bigotry and us vs. them. Of
course some tasks _are_ different. But I think there's no real reason not to
have all the features in the same language and define "sections" of code that
use certains "modes", except the competition.

~~~
viraptor
I agree with many things... especially the editor complaint. I wanted to
create a syntax-aware editor one day and it's considerably harder than
creating a standard one. It's also almost useless in case of dynamic
languages, since you cannot verify that much at the editing stage. But this
seems just wrong:

> _I hate languages that do now allow me to do something, just because the
> language "designer" decided so._

In many cases it's not about "designer decided so", but rather about
tradeoffs. We cannot do X, because that would make Y considerably more
difficult / fragile / slower. It also helps create some coding standards and
common constructs. For example it's easier to read someone else's python code
where the syntax is pretty much minimal and uses the same concepts over and
over again (decorators are just functions in functions, decorators with
parameters just call another wrapping function to get the decorator, etc.),
rather than reading some haskell code, where someone decided to build own DSL
which implements everything. Limits can be good.

~~~
narag
But limits don't need to be in the language itself. It should be possible to
define subsets.

Maybe it seems the same thing to be limited by the language or by a
requirement imposed by the boss or the customer. But it's not quite the same.
I've worked for companies with very strict code conventions and revisions, and
I was happy with them.

It's not the individual freedom what I'm requesting. It's more like having the
possibilty of exceptionally resorting to powerful features when it's seen as
the best option with the consensus of the team.

IOW: the limits can be good, but I don't think a single person should decide
for all the users.

------
jluxenberg
Didn't see anyone mention this little gem about Ruby:

a = [1,2,3]

x = :foo

puts x

a = a.map do |x|

    
    
      x+1
    

end

See anything wrong here? (hint: what is the value of x?)

~~~
prog
Yes, thats surprising behavior. Fortunately its fixed in 1.9. :)

Spoiler alert:

.

.

.

1.8.x produces 3 while 1.9 produces :foo

~~~
lincolnq
Why was this broken in the first place? (What abomination of semantics would
cause this behaviour)?

~~~
gnaritas
Closure variables not having their own scope and shadowing method level vars.
They're simply implemented as method level vars, so not true closures.

~~~
lincolnq
I got that, but I don't understand why it should gain the value 3 before a
single execution of the loop.

~~~
mike
It's only at the end that the value of x is 3. The puts x immediately after x
= :foo does print :foo

------
henrikschroder
C#/.Net:

1) Collection classes.

2) Collection classes.

3) Collection classes.

4) Collection classes.

5) Collection classes.

~~~
RodgerTheGreat
I'm guessing I'm not the only one who wonders why all the Remove(index)
methods are void instead of returning the removed element.

------
limist
I'm just pleased to see that the complaints/rants against python are few, and
without much import (at least for me).

~~~
orangecat
One that I didn't see mentioned: why do I have to import a separate module and
call a weirdly named function to get a stack trace? Why isn't it just a method
on Exception? Not a major issue but it just feels wrong, along the same lines
as __init__ and "if __name__=='__main__'".

~~~
viraptor
At some level it makes sense probably... It's not a very common operation, so
don't load it unless needed. It looks like an arbitrary choice, rather than
good/bad design.

