What don't you like about your programming language?

In C#...

I wish there was a (better) way to create local references. The problem is that when I'm working with arrays of structs, I have to type the entire expression for every statement which yields a lot of duplication.

myArray[indexLookup[i] - 1].SomeStructField.SomeMember = someValue;
myArray[indexLookup[i] - 1].SomeStructField.SomeOtherMember = false;
// ...

Here I wish I had been able to make a local reference to that element and/or that SomeStructField. At the moment you have to wrap it with something like

WorkWith(ref myArray[indexLookup[i] - 1].SomeStructField, 
a => {
  a.SomeMember = someValue; 
  a.SomeOtherMember=false;
});

Edit:
Oh, and some form of specialized "generics". I miss the ability to create a generic that is only valid for a specific set of classes/structs, such as int, long and double.

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.

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.

++

That's a hard question. Every language I've worked with has things it could do better. Sometimes I wish a language would handle a construct better, but other times I select a language precisely because it has that construct.

As one example, some languages let you play fast and loose with data, it can be a string here, values there, and an array somewhere else. When I need to play fast and loose, such as writing scripts to run programs in a tool chain, these can be very nice. Other languages they are careful and meticulous about data types. When I need precision these rules can be very nice.

Occasionally when working in one language I'll wish I had something from another language. Usually it is just a mild desire, but if it bothers me too much I'll just write the code in the other language, find a compiler for the language, and add it in.

That's a hard question. Every language I've worked with has things it could do better. Sometimes I wish a language would handle a construct better, but other times I select a language precisely because it has that construct.
As one example, some languages let you play fast and loose with data, it can be a string here, values there, and an array somewhere else. When I need to play fast and loose, such as writing scripts to run programs in a tool chain, these can be very nice. Other languages they are careful and meticulous about data types. When I need precision these rules can be very nice.
Occasionally when working in one language I'll wish I had something from another language. Usually it is just a mild desire, but if it bothers me too much I'll just write the code in the other language, find a compiler for the language, and add it in.

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.

Just the opposite to my previous thread. What are the things you wish they would remove or should be better implemented? What features do you wish they should add that will make it easier to use?

The declaration syntax in C++ could learn a thing or two from Go's. In particular, function pointer declarations in C++ are really ugly.

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.

Did you read the book I recommended to you in the other thread? Did you work through all the exercises?

Read, study and gain experience. You WON'T become proficient in C++ in just a few days or weeks or months. Some features will probaly only dawn on you YEARS after you first read about them, yet there are probably many use cases for each of them.

C99 is almost perfect as an old-school procedural language, but it would be so much better if it also had function overloading. Yes, I understand the potential difficulties this would cause, so it's firmly in the realm of wishful thinking, and yes, I also understand the "so why don't you just use C++ instead?" argument. Can I just say that I'd love C99 so much more if it had function overloading?

In C, I hate signal handling... gosh, couldn't we just have a non global way to send info to the signal handler? u.u

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.

YES YES AND YES!

I hate that keyword, especially in JavaScript (and how it requires it!). I'm glad I'm not the only one!

I wish classes were easier to make in Objective-C. Right now, this is what it looks like...

You have to create a header file(which includes the names of any instance methods you need to use), and then a source file (the thing that actually makes the instance methods work!), like this:

Header:

@interface MyClass: NSObject
-(void) myMethod;
@end

Source:

@implementation MyClass
-(void) myMethod
{
    NSLog(@"Bit of a roundabout way to do this, eh?");
}
@end

Then you call it like this in your main source file, in the main function...

MyClass *newClass = [[MyClass alloc] init];
[newClass myMethod];

Why couldn't the engineers of Objective-C done it like regular programming languages? :P

I'm used to it now, but it did take me a little bit to get used to it...

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.

I wish classes were easier to make in Objective-C.

I wish JS had standardized classes. One of biggest issues with the language is having like two ways do things. Two ways to do getters/setters and many ways to do inheritance with mixins and other tricks. ECMAscript 6/7 is taking a while to be finalized. (Should add operator overloading, SIMD, and tons of value types). One of the biggest issues still is the lack of optional strong typing. The language has been slowly incorporating systems for working with binary data and the typed array spec is verbose.

My gripe in C# is not being able to use lambda expressions in attributes.

[Converter((x) => x * x)]
public Foo { get; set; }

There's a submitted suggestion for it, but it's so low priority it'll never get added.

In C++ the compilation system needs to be redesigned. The source/header system just doesn't work well. Having a multipass compiler that doesn't require forward declarations would greatly simplify the language making it modern. That and having an optional reflection system would be useful.

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%.

Nothing really stops a language from implementing every feature. One just hasn't been implemented. One of the big issues is a lot of features need to be optionally defined as they have performance implications. Reflection for instance is nice, but would need to be optional in C++ for performance. Basically the compiler needs to be able to optimize freely to produce the output required without restrictions. Having things be optional throughout the language greatly complicates the language. C# I believe is really close, but even that is missing SIMD support taking itself out of some specialized applications.

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.

C# has both static and dynamic typing via the dynamic keyword. Interpreted vs compiled has kind of been superceded by JIT kind of. You can use say C# as a scripting language within itself for instance. Regarding garbage collection and explicit memory management there's nothing that stops a language from offering both. Modern C++ with smart pointers for instance is reference counting garbage collection. It's a core part of the standard library and used heavily by C++ programmers. It's not exactly a global mark and sweep algorithm, but it can show how a language can have both features at the same time.

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.

Nah, they're just designed for different things.

Say you are writing a build script utility. There are good reasons to chose between Python, Perl, C#, and C++. Depending on the needs I might pick any one of the languages.

Just because C++ isn't a perfect fit for simple string processing as seen in a build script, that doesn't mean I dislike how C++ handles strings. I'm not going to blame Java for not being able to pull items from collections as easily as I can join tables in SQL. I don't care that C is not the best match if I'm building a web page, nor will I complain that I cannot directly embed Pascal into HTML scripts. If I'm doing extensive regex processing I don't care that hand-coded assembly is a less than ideal fit, or conversely complain about how Perl is less than ideal when I'm trying to count individual CPU instructions. None of those are flaws in the languages.

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.

Perl and PHP: The damned dollar sign! I get why its there, and I've written parsers that depend on it being there. But I've also fingured out how to deal with it not being there in my own parsers, and it wasn't that hard. And I'm talking about a recursive-descent parser with a simple hashmap for a symbol table, not a bison, yacc, or other animal-generated automata.

C: An operation I do sometimes, is given a pointer, take the address of a member. So if I want a pointer to foo's X member, its to_x = &(foo->x). If you expand out the arrow shorthand, its really saying to_x = &( (*foo) . x ) ; It's dereference, and then take a pointer to a member. We all know what its really doing. It will compile to just an ADD instruction adding some constant offset to my foo pointer. It seems like something that should be able to be expressed a little easier. My proposal would be to expand the use of 'dot'. We all know that if bar is a struct, then bar.x returns the value of x. If foo is a pointer, foo.x should return the pointer to x. At least I think it would be cleaner.

BASIC: Yes, this, I mention it because this is where I learned programming. 'DIM' needs to die. DIM x as integer. x as integer is sufficient. pascal-style x: integer. integer x. Anything is better than DIM. Some variants (like basic stamp or PIC micro basic, use a var syntax. Like var int x. That's not too bad.)

C and C++: I hate the preprocessor and compilation model. I hate ABI incompatibilities.

Most dynamically typed languages: I hate not being able to quickly and consistently discover what types are involved when looking at other people's code.

BASIC: Yes, this, I mention it because this is where I learned programming. 'DIM' needs to die. DIM x as integer. x as integer is sufficient. pascal-style x: integer. integer x. Anything is better than DIM. Some variants (like basic stamp or PIC micro basic, use a var syntax. Like var int x. That's not too bad.)

I prefer to avoid Basic and it's variants where possible, but when I do have to use it (normally some VBScript) I find that not being able to initialize a variable on declaration is a far greater evil. Not being able to say "dim x as integer = 47" just seems insane, one of those "WTF were they thinking?" moments. As annoying as the Dim syntax is, it's not as annoying as this. It may be fixed in more modern versions, of course.

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.

I hated it at first. Now I'm pretty much replacing everything with it, especially where I previously had to write the type twice (Dictionary myDictionary = new Dictionary()).

Perl and PHP: The damned dollar sign! . . .
. . . 'DIM' needs to die. DIM x as integer. x as integer is sufficient. pascal-style x: integer. integer x. Anything is better than DIM. Some variants (like basic stamp or PIC micro basic, use a var syntax. Like var int x. That's not too bad.)

i seriously hate dim and that dollar sign. Dim made me leave vb. As for the dollar sign, though i've not seen it in c++, it has no place in a programming language's keyword.
Another i don't like is var. I don't like seeing it in code examples.

Java

Type erasure: It gets in the way sometimes. Specially if you have to deal with primitives or generic array creation. Also in overloading, you can't overload a method that has a generic like List with another method that receives List because type erasure makes the two Lists equal, so no way to know which method you meant to call.

No array slicing: You can't slice a regular array, you have to use Buffer objects for that. And its annoying.

K&R for Java Class Library: I'd prefer allman.

Java 8 specific: No @FunctionalInterface for abstract classes with a single abstract method (it must be an 'interface' always).

JavaFX specific: Looks like there is no way to hook up your own drawing loop. So if you want to render the widgets yourself, you have to hijack them, draw them to a BufferedImage (and I hear even that one is difficult), then upload it to OpenGL separatedly. If this process was less retarded, it would make a sweet game UI lib with a few OpenGL hooks.

Java users and library developers: Java 5 came 10 years ago, drop it already!

In general, I really don't like the text file style of editing things, where functions have some sort of ordering relative to each other. I sort of understand the utility of having a text file as an intermediate form to simplify compiler authorship, sort of, but the idea that I would need to scroll through 500 lines of stuff to find a specific function just seems obstructive. Not quite sure why we're still stick with that in most languages, when there are so many more intuitive ways of navigating through information.

My biggest wish-list item for C# would be extension interfaces or implicit interfaces. This would make working with primitive types inside custom data structures a lot more simple. For example, if I wanted to represent a vector of type T, I should be able to specify T as satisfying certain constraints, so I could implement "Add" and "Multiply" on T. I would then be able to apply a new interface to integers and doubles, and get my vector code able to work over those types.

Biggest wish-list item for C++ would be the existence of some sort of auxiliary standard that would fill in all the "undefined behavior", with something that is diagnostically useful. Perhaps "Release" mode compilers would not adhere to this added standard, but "Debug" mode would, or some such. Just something that a compiler author can claim compliance to, so as to eliminate a lot of the guess-work associated with debugging complex code.

Java could totally use operator overloading.