Java:

1: Simplify type casting

2: Simplify boolean

Python 2.x and 3.x :

1: The gods ####ed class declarations !

Ruby:

1. Mixin. Great concept, but overused a lot, causing spaghetti's code and violating common sense and everyone's private parts to the tenth degree.
2. Not really the language's fault, but the people who use it - they would use nouns for method names. This always bugs me. C/C++/Java, or pretty much everywhere else, method names have mostly been verbs. GetThis(), DoThat(), RetrieveXYZ(). Since Ruby does not require the parentheses () when calling a method, you can't tell the difference between a method and local variable.

Ruby's naming convention is snake_case, similar to C, and combined with Mixin, and method names that are nouns, you will be looking everywhere for your definition and have no clue whether it's invoking a method, a local variable, or an accessor, or perhaps something else.

This is very common:

def read
  # holy shit, where's this books variable defined?
  books.each do |book|
    book.read
  end
end

# somewhere else deep in the code, located in other file and class ...

def books
  # get all books
end

C#:

I have an irrational hatred of the "var" keyword. This is more of a style thing as it has its uses, but I've worked with people that use it everywhere.

++

it would be nice to have one language that has everything right. Ease of use, general purpose precision etc. But i'm guessing nothing can be 100%.
Some things in c++ make me wonder why i would want to use them or why they are there.

Not really possible to have one language that has everything. Some things are mutually exclusive (or, at least, impractical enough within a single language to effectively make them so). E.G. static typing versus dynamic typing. Garbage Collection vs. Explicit Memory Management. Interpreted vs Compiled. Depending on what I'm doing, I may prefer one environment over another. Different tools suited for different jobs. Just like Mechanics, Electricians, Plumbers, etc. all have a variety of tools in their toolboxes to accomplish a variety of tasks, Software Developers have a variety of tools in their toolboxes. The biggest difference being that it's much easier for a programmer to use the wrong tool (or perhaps just the less ideal tool) for the job than most other professions.

Incorrect on every count. C# has both static and dynamic typing, and while it's extremely uncommon, manual memory allocation is possible. C++ has both garbage collection and explicit memory management, and while I am not aware of one specifically, I would not be surprised if there were a dynamic type library somewhere. Racket has all three of your false dichotomies.

Systems programming languages are meant to be general purpose tools. Your analogies are meaningless.

To the rest of you, I love the var keyword in C#. I tend to do a lot with complex type hierarchies, generic types, reflection, and functional programming in C#, so var is extremely useful. Why should I have to repeat myself? It also makes changing types on things easier. It's half of all the good parts of dynamic typing without any of the bad parts.

I wish C# had algebraic types. F# has them, but they are only compile-time constructs and are not available during runtime for reflection. I want to be able to specify physical units for my values and have the type system prevent me from adding a kilogram to a meter (that's just one example, I'd have much more specific uses for it if I had it). But it doesn't. You can get halfway there with generic types and extension methods, but not far enough to bother.

Semi-related to algebraic types, I wish generic code written for numeric primitives could do arithmetic.

I also wish C# had hygienic, syntactic macros, ala Racket's syntax-rules. Or basically, I wish all the stuff that I do with reflection were pushed back to compile time and getting type-checked more explicitly.

Multiple inheritance. Mixins are a poor substitute. I don't care if you're not adult enough to do it right, I want it.

Or:

I wish Racket had a class definition syntax that had a little more opinion about how you should be writing classes. It's just a tad too generic and it makes the whole thing very verbose. It's also very difficult to write macros about classes.

It would be nice if Racket had a decent GUI editor. There is one, sort of, but it's extremely buggy. I'd rather learn Tcl/Tk than deal with Racket's GUI editor. Also, I wish the GUI controls used the native widgets. I'm sick of apps looking like Windows 2k.

I wish I could run Racket in Visual Studio.

I wish the libraries in Racket weren't a hodge-podge of user contributed packages, none of which match each other in style, quality, or completeness. For example, one of the more complete libraries is for connecting to databases, yet it has no syntax for calling stored procedures (or if it does, it's not documented anywhere and the author isn't replying to my second email). The mathematics library has a lot of great linear algebra code, but statistics is kind of lacking. Web dev is sometimes awesome (type-safe, compiled text templating!), sometimes a nightmare (continuations for handling POST requests). The algebraic type package makes no attempts to make the types actually look like physics equations.

And for good measure: I wish everything were using .NET-style namespaces instead of this garbage "require" pattern that makes you explicitly state what your module exports while also forcing your consuming modules to explicitly state what they are importing. If two classes are in the same namespace, I want them to be accessible to each other. I don't want to have to tell them to require each other. If I add a third class to the namespace, I don't want to have to go back to the other 2 and add more require statements. It's bullshit and it needs to stop.

I use C++ on a daily basis at work, and there's a lot of things I don't like about it:

- confusing syntax (templates, lambdas, iterators...)

- no proper implementation for delegates, no RTTI, no real interfaces (only abstract classes)

- the 'override' keyworkd is not required

- a lot of small WTF that kill you productivity. For example the boolean type is broken in C++, you can write something like that :

myBool = 3;
if (myBool == true)
{
    // do something
}
else if (myBool == false)
{
    // do something else
}
else
{
    // WTF ??
}

Another example is destructors that are not virtual by default. How many hours did I spent trying to solve a bug before realising that my desctuctor was not virtual?

In general, I think the C++ language is confusing and overly complicated. It's really easy to fall in a trap if you're a beginner or if don't know by heart every little implement details of the language.

I also use C#, and so far, I like almost everything about it :)

Well, despite all the small quirks the language has, my biggest beef against JavaScript is the lack of a (good) free editing tool. I've been jumping back and forth between Notepad++, Scripted and Brackets, but it amazes me to no end how no tool manages to implement a good code assist like WebStorm's.. But I currently can't afford it, so..

Well, despite all the small quirks the language has, my biggest beef against JavaScript is the lack of a (good) free editing tool. I've been jumping back and forth between Notepad++, Scripted and Brackets, but it amazes me to no end how no tool manages to implement a good code assist like WebStorm's.. But I currently can't afford it, so..

You might want to check out LightTable

To the rest of you, I love the var keyword in C#. I tend to do a lot with complex type hierarchies, generic types, reflection, and functional programming in C#, so var is extremely useful. Why should I have to repeat myself? It also makes changing types on things easier. It's half of all the good parts of dynamic typing without any of the bad parts.

At first I thought var was a bad idea, but now I use it EVERYWHERE. The compiler isn't doing something shitty like using a dynamic type for it like other languages with var do. It makes generics easier to write. It makes foreaching over strongly typed collections MUCH simpler to write. Refactoring is faster. The IDE shows you the type and will still find references properly (You ARE using an IDE, right? Who the hell would write C# without an IDE?).



I just remembered another language constraint I don't like:

F# - You have to declare something before it's used (i.e. "textually above it in the compile order"). C# spoiled the hell out of me since order of declarations only matters in function bodies and very few other cases. F# is like C or C++, except there AREN'T forward declarations (there are "and" declarations, but that sucks as well). You either have to explicitly sort your code yourself, or be disgusting and use "and" to tie everything together.

Basically I have a toolbox with hammers, screwdrivers, wrenches, drills, saws, sanders, and much more. I'm not going to say I dislike a screwdriver just because it doesn't cut wood very well.

I agree. You don't need a hammer with a machete attached to it if you can have a hammer and a machete separately.

I imagine having a language "that does everything" would just be cumbersome.

Basically I have a toolbox with hammers, screwdrivers, wrenches, drills, saws, sanders, and much more. I'm not going to say I dislike a screwdriver just because it doesn't cut wood very well.

I agree. You don't need a hammer with a machete attached to it if you can have a hammer and a machete separately.
I imagine having a language "that does everything" would just be cumbersome.

i've seen this somewhere. It was an arguement on a universal programming language that could be used for almost anything and they were using the tools to describe languages. This was until someone changed it. He/she said that a language isn't a tool but a toolbox with different tools in it.
Similar to a language with multiple features.
When you want to tighten to a screw, you go to your toolbox and remove your screwdriver, if it's a nail, you take the hammer etc. without any inconvenience. The bigger the toolbox, the more tools you can fit in it and less need to go to the market to buy the tool when you need some work done.
Wouldn't it be nice to have a language that had numerous features and capabilities (a big toolbox) and depending on your project, you use the features you need (the hammer, screwdriver etc.) and use it, and if the language didn't have that feature, you simply add it. Rather than having to learn a whole new language (going to buy in the market) to accomplish the same thing because your language doesn't support that tiny feature?