Programming languages - the things that are wrong.
Author
I decided to start thread there for normal discussion about programming languages and what was done wrong.
Lets make the rules for this. Everyone points the down-sides of one of his *favorite* language(s).
I'll start with incomplete list of very common wrong things with procedural languages at the grammar level:
1: Grammars that require you to know meaning of symbols to parse expression using them. Very big deal for compiler writers, for tool developers (e.g. refactoring tools), and so on.
Example: (C-like languages, C++)
a*b; (can be either Type *Pointer; or operator*(a,b))
a b(c);
a < b > ( c )
and so on
Cause:
Clever token reuse tricks (reuse lessthan and greaterthan as braces), combined with backward compatibility or C-like syntax
2: Too many equivalent, obvious ways to do every thing.
Example: anything perl.
3: "Clever" grammar ideas in general, like abovementioned < >, and pointer and especially function pointer syntax in C (the idea is very 'clever': in statements, "*whatever" gives an object referenced by a pointer, in declarations, you declare "*whatever". Which quickly gets real bad for function pointers).
This list is by no means complete.
C++ suffers from pretty much every grammar problem ever possible. Nonetheless, I do a lot of programming in C++, and it is ok-ish language, crap grammar offset by library and api availability.
4: Too large % of typos becoming hard to track runtime errors.
Examples:
Lua (any code, any typo) , lot of other scripting languages. To lesser extent, python. Lua is beautiful little language, but it becomes severe problem when you make some complicated script for a game.
Possible remedy:
= for first assignment, := for consequent assignments (or vice versa), with := throws if lefthand side does not already exist. Would make typo bugs much less annoying.
Anyways, what do you think? What other grammar or language quirks annoy you in your favorite languages / languages that you use the most?
Lack of function closures (in just about any language that doesn't have them). Especially applies to Java, where I frequently construct anonymous nested classes. Though fortunately both NetBeans and Eclipse reduce the number of keypresses.
My problems with C/++:
1:
Fails. Apparently the upcoming C++0x addresses the issue, let's hope so. I'm less reliant on it since my introduction to STL, but the problem is still there.
2: Recursive dependencies. I'm currently tackling this issue as we speak - the QMake compiler doesn't like forward declaration, which is making Qt development a headache for me.
Finally, a nitpick with the programmers of any language - single character variable names. Absolute pain in the backside.
1:
int Array[GetSize()];Fails. Apparently the upcoming C++0x addresses the issue, let's hope so. I'm less reliant on it since my introduction to STL, but the problem is still there.
2: Recursive dependencies. I'm currently tackling this issue as we speak - the QMake compiler doesn't like forward declaration, which is making Qt development a headache for me.
Finally, a nitpick with the programmers of any language - single character variable names. Absolute pain in the backside.
Quote:Original post by deadstar
My problems with C/++:
1:int Array[GetSize()];
Fails. Apparently the upcoming C++0x addresses the issue
You missed the point. In C++0x static arrays still need their sizes specified at compile time. GetSize() must return a compile time constant, not one determined at runtime.
For example:
constexpr int GetFive() {return 5;} // constexpr is a new keyword int some_value[GetFive() + 5]; //create an array of 10 integers. legal C++0xI hardly even consider your point a problem in the first place.
For a pretty good list of what is actually wrong with C++ I refer you to this.
In C# :
IEnumerable, ICollection, IList, etc. : The fact that generics were only added in C#2.0 forces to implement both generic collection interfaces (IEnumerable<Foo>) and non-generic ones (IEnumerable).
The impossibility of adding in a derived class a setter to an abstract property defined in the base class.
The support for the lock keyword which, if I'm not mistaking, introduces an overhead of 4 bytes with each object created, even when the feature is used on an extremely small amount of them, and can be replaced with mutexes.
In .NET :
The incompatibility of unsigned types with the common language runtime.
I'm sure there are a few others but I can't get to remember them right now...
IEnumerable, ICollection, IList, etc. : The fact that generics were only added in C#2.0 forces to implement both generic collection interfaces (IEnumerable<Foo>) and non-generic ones (IEnumerable).
The impossibility of adding in a derived class a setter to an abstract property defined in the base class.
The support for the lock keyword which, if I'm not mistaking, introduces an overhead of 4 bytes with each object created, even when the feature is used on an extremely small amount of them, and can be replaced with mutexes.
In .NET :
The incompatibility of unsigned types with the common language runtime.
I'm sure there are a few others but I can't get to remember them right now...
Quote:Original post by fpsgamerQuote:Original post by deadstar
My problems with C/++:
1:int Array[GetSize()];
Fails. Apparently the upcoming C++0x addresses the issue
You missed the point. In C++0x static arrays still need their sizes specified at compile time. GetSize() must return a compile time constant, not one determined at runtime.
For example:constexpr int GetFive() {return 5;} // constexpr is a new keyword int some_value[GetFive() + 5]; //create an array of 10 integers. legal C++0x
I hardly even consider your point a problem in the first place.
For a pretty good list of what is actually wrong with C++ I refer you to this.
Maybe not problem, more set back. Seems pretty reasonable in my head to do: int Array[GetSomeValue()], so if it doesn't work it's a nitpick of mine.
I tolerated the separating class definitions from declaration in C++. I've never once figured out why the compiler can't do the same action. IDE's have evolved making looking at tons of code simple. I've heard the word translation unit, but it doesn't mean anything to me since I've never taken a compiler course at my university yet. C# seems to handle things just fine.
I'll get flamed to next year and already have for the next comment, but C# doesn't have Multiple Inheritance which I've legitimately needed. (CLR I get it, that's a fine reason not to have it; interfaces != MI). Not a fan of languages that restrict programmers or use backwards compatability, but C# has .NET and well yeah it's awesome. Also no default parameters in C# lead to code bloat, but I've never really cared too much. Just seems tedious sometimes. Oh yeah and no .NET MathF for floats. Always though working with only doubles was a bit odd.
Flash AS3 I use sometimes to help people and it has a complete lack of sane data types. (It has Number, int, uint, string). Flash 10 also added 2 generic classes but no way to actually make generics. (that I know of). The list goes on, but they are generally obvious.
I'll get flamed to next year and already have for the next comment, but C# doesn't have Multiple Inheritance which I've legitimately needed. (CLR I get it, that's a fine reason not to have it; interfaces != MI). Not a fan of languages that restrict programmers or use backwards compatability, but C# has .NET and well yeah it's awesome. Also no default parameters in C# lead to code bloat, but I've never really cared too much. Just seems tedious sometimes. Oh yeah and no .NET MathF for floats. Always though working with only doubles was a bit odd.
Flash AS3 I use sometimes to help people and it has a complete lack of sane data types. (It has Number, int, uint, string). Flash 10 also added 2 generic classes but no way to actually make generics. (that I know of). The list goes on, but they are generally obvious.
Some things in C#:
1) Lack of support for default arguments.
2) Having to specify visibility for each method/variable separately, instead of like in C++.
3) No support for deterministic destruction.
4) Generics not being weakly typed (I know this has some benefits, but it feels too restrictive at times).
There are probably good reasons for all these things, but they are still annoying.
1) Lack of support for default arguments.
2) Having to specify visibility for each method/variable separately, instead of like in C++.
3) No support for deterministic destruction.
4) Generics not being weakly typed (I know this has some benefits, but it feels too restrictive at times).
There are probably good reasons for all these things, but they are still annoying.
Oh so many to name...
I'll stick to the ones I can remember (since my current toy language project deals with them). All the gripes target C#.
1. Lack of decent support for methods as objects.
2. Lack of operation constraints on generics (require the supplied type supply T + T for example).
3. Requiring explicit inheritance of interfaces.
The language design itself is okay, though as has been mentioned the non-generic collection stuff is unfortunate; and having 2+ anonymous delegate syntaxes (types actually, since lambda stuff is only implicitly convertible to delegates) is similarly icky.
I'll stick to the ones I can remember (since my current toy language project deals with them). All the gripes target C#.
1. Lack of decent support for methods as objects.
2. Lack of operation constraints on generics (require the supplied type supply T + T for example).
3. Requiring explicit inheritance of interfaces.
The language design itself is okay, though as has been mentioned the non-generic collection stuff is unfortunate; and having 2+ anonymous delegate syntaxes (types actually, since lambda stuff is only implicitly convertible to delegates) is similarly icky.
Quote:Original post by deadstar
Maybe not problem, more set back. Seems pretty reasonable in my head to do: int Array[GetSomeValue()], so if it doesn't work it's a nitpick of mine.
It's only reasonable to expect that to work if you don't understand the difference of the stack vs the heap. To get the functionality you want, simply allocate on the heap instead of the stack:
int *Array = new int[GetValue()];delete[] int;If you can't stand the delete, use smart pointers.
Anyway, a problem with several functional languages: arrays are not a native type. Yes, yes, I understand that lists are much more appropriate in general in functional programming, but sometimes you simply need fast random access. Lists cannot provide that, and I don't want to see some weird #[#[a b] #[c]] syntax for something as basic as arrays.
I also hate it when languages force me to use a certain indentation strategy. This is mainly a problem for me when I use Haskell, because the Emacs Haskell mode is not smart enough to handle indentation properly. To get compilation errors only because a line is two spaces too far to the left is annoying and pointless.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
