Bad things about your favourite programming language

So, what's frustrating about your programming language of choice? Anything that could've been improved?

I could start up (LISP):
1) There's no "standard" common lisp implementation everyone uses. It is so simple to make a Common LISP-interpreter and compiler that there are thousands on the internet, where some have turned into "big" interpreters. Thus, many of these implementations have different ways of working. Which leads me to issue # 2:

2) The standard implementation is very vague. What should be supported and not be supported in a Common LISP implementation is mostly dependent of the programming team. Usually stuff is "implementation-dependent", which is messy.

3) There's no freaking libraries for anything. I had to make my own ZLIB-library ffs.

4) get-setf-method-multiple-value is something that bothers me. I usually make functions which return multiple values, and using that function makes me feel sad. I can just make a macro to shorten its name, but it's the principle. least-positive-normalized-double-float is also a long constant name, though I never use it, so it's okay.

Actually, that's about it. There's some issues with making a lisp-website and stuff (Arc works though), but looking at jsp makes me feel sorry for those who use it, so I'm probably fine for now.

Python:

Problems with dynamic languages in general:

In larger projects, you need to know the type of the variable you're using, especially if it's a method that depends on a certain object entering it. So the language being dynamic really doesn't give me any flexibility as reassigning types doesn't do any good within the scope of the method. So instead I have to name a variable in such a way that its association with an object or primitive is obvious. These days I tend to program Python like Java/C# due to this problem.

With python in general:

There is no multithreading possible due to a Global Interpreter Lock (GIL). All threads of a program are limited by the GIL in that it can only execute one bytecode at a time. Attempts have been made to make the GIL multithreaded, but the mass spawning of threads slowed down the already slow language by twofold. The only way to get a multithreaded application is to spawn multiple processes within python so that it operates on two sets of bytecodes - but then it can't share a global state between them. So if you're working with a large data set, you have to work with double the memory and each process cannot communicate with each other. Regular threading works well on I/O bound operations since they do not invoke GIL bytecode.

There are incompatibilities with Python 2.x and 3.x. Most static languages bend over backwards to ensure backward compatiblity, but not python. In Python 3.x, they include new types (byte, bytearray) and make UTF-8 the standard string type. This totally screws with reading binary files as you have to use bytes types instead of string types. The frustrating thing is that according to C, a string and an array are the SAME THING. So why can't it be the same in Python? Why can't I XOR a char in Python if I can XOR a char in C?

When working with integrated database classes (anydbm, bdbm), if the program crashes while you are working with a database then the database will be corrupted. You have to include try/catch blocks on everything to make sure the db is totally closed so that it isn't corrupted.

No JIT. If you want a JIT, you have to install psyco or Unladen Swallow.

Problems with C# (version 4) in general:

- Compiles to MSIL, no (feasible) way to compile to x86. You either use commercial products to compile everything your application depends on to x86, or you live with MSIL (and JIT). There is also AOT but that is merely for improving performance, not for running applications on platforms without .NET.
- .. nothing with the language ...

Problems with the .NET Framework in general:

- Cross-platform interoperability - it took Microsoft years to develop. Now the open source community has to match that, if they want it on linux and Mac. PITA, much?
- It is huge. But Vista/7 now come with .NET Framework 3.5 so that isn't much of a problem.
- Too easy to reverse engineer - suppose this is a problem with all intermediate languages

Other than that, I love C#.

C#

No C++-style const-correctness. Let's say I have a class that internally has some sort of container object and I would like clients of the class to have read-only access to that object. In C++, you could simply return a const object. In C#, your options are: 1) Return the object and document that the caller should not call any methods on the object that change it. 2) Make a (deep) copy of the object and return that. 3) Make a "ConstFoo" class that wraps a Foo and exposes only the "const" methods and properties of the Foo class.

None of those approaches are particularly satisfying.

No support for automatic release of resources other than the using statement. In C++, when an object goes out of scope, its destructor automatically runs and releases any resources the object may have held. For objects on the heap, you have things like shared_ptr that can reference-count the object and have the destructor run when there are no more references to it. In C#, you need to use() any local IDisposable objects and make a class IDisposable if it owns any IDisposable members (or if it *might* own any IDisposable members if it's an abstract class or interface).

.NET framework (or Mono) needs to be installed on user's machines.

@AngelSL: Mono is fairly mature. Any .NET 3.5 or lower program that doesn't use P/Invoke or Windows-specific libraries like WPF will run on Mono. However, I did run into some performance issues recently when developing a program on Windows that would be deployed on Linux with Mono. Mono's string.StartsWith() method is ridiculously slow, even when using StringComparison.Ordinal. I got a 25% speed increase of my entire program just by replacing all calls to string.StartsWith() with my own implementation. The program started out ~8 times slower on Mono than .NET and I was able to get that down to ~3 times slower with some optimization. The program is mostly string processing.

Seeing as everyone above me posted 2-4 paragraphs I'm feeling like this post is way too short, but my favorite language is C# (although I'm in the process of moving to C\C++) and the only problem I find with it is the fact that it is CLR based (which implies speed decrease, lack of cross-platformness, the need to have .NET installed on every computer and the lack of ability to control low-level memory).

Seems like all of our problems would be solved by moving to C++.

Seems like all of our problems would be solved by moving to C++.

But C++ has its own problems.

C#

No C++-style const-correctness. Let's say I have a class that internally has some sort of container object and I would like clients of the class to have read-only access to that object. In C++, you could simply return a const object. In C#, your options are: 1) Return the object and document that the caller should not call any methods on the object that change it. 2) Make a (deep) copy of the object and return that. 3) Make a "ConstFoo" class that wraps a Foo and exposes only the "const" methods and properties of the Foo class.

None of those approaches are particularly satisfying.

No support for automatic release of resources other than the using statement. In C++, when an object goes out of scope, its destructor automatically runs and releases any resources the object may have held. For objects on the heap, you have things like shared_ptr that can reference-count the object and have the destructor run when there are no more references to it. In C#, you need to use() any local IDisposable objects and make a class IDisposable if it owns any IDisposable members (or if it *might* own any IDisposable members if it's an abstract class or interface).

.NET framework (or Mono) needs to be installed on user's machines.

@AngelSL: Mono is fairly mature. Any .NET 3.5 or lower program that doesn't use P/Invoke or Windows-specific libraries like WPF will run on Mono. However, I did run into some performance issues recently when developing a program on Windows that would be deployed on Linux with Mono. Mono's string.StartsWith() method is ridiculously slow, even when using StringComparison.Ordinal. I got a 25% speed increase of my entire program just by replacing all calls to string.StartsWith() with my own implementation. The program started out ~8 times slower on Mono than .NET and I was able to get that down to ~3 times slower with some optimization. The program is mostly string processing.

Problem is, WPF is getting on - many applications are starting to switch over to WPF. It is now 4 years old, and Microsoft themselves have moved over: VS2010 is full WPF.

Also, the using statement does not release memory. The GC still needs to do it's job before the memory is actually released.

C++'s downfall would be memory management. You must manage memory yourself.

Not if you use smart pointers. Treat a pointer as an object. In its constructor allocate the memory and in the destructor deallocate the memory. Voila - no need for self-memory management. Smart pointers can also do bounds checking, array searching, etc. - anything a higher level language can do.

I have never had any problems with my programming language. It was quite BASIC

But no the only other language I worked with was Object Pascal and it forever traumatized me ._. Gives me flashbacks just thinking about it

Problem is, WPF is getting on - many applications are starting to switch over to WPF. It is now 4 years old, and Microsoft themselves have moved over: VS2010 is full WPF.

Also, the using statement does not release memory. The GC still needs to do it's job before the memory is actually released.

C++'s downfall would be memory management. You must manage memory yourself.

I said resources, not memory. To be more precise, I meant "resources that are not managed memory". Things like process handles, synchronization primitives, database connections, etc.Anything that needs to be released when you're done with it.

If you use Windows Forms or WPF, you're basically giving up on your program ever being cross-platform (at least without a significant amount of work), just like if you're using C++ and use MFC, ATL, DirectX, or COM and don't abstract it behind a cross-platform layer.

R - the big one for me is memory management. It's a fair pain in the ass to figure out what objects are using a lot of memory. If it hits the limit (1500M) it just gives an error when you try to assign new variables.

Looping through certain kinds of vectors could also use some work. It's the kind of thing that the language is meant to do easily through vector/matrix notation, but there are still a few edge cases where you need a for-loop.

Lua's not a programming language

I guess the main "issue" is that it's designed as an extension language so it's really not suitable for large standalone projects, for similar reasons Fiel mentioned about Python. Then again I don't do large standalone projects in the first place, or really anything used by other people, so it's all good for me.

Also it's very minimalistic in terms of syntactical constructs and standard libraries, so you don't have classes, bit ops, regex, etc and so for pretty much anything beyond basics (math, string, list, I/O, system) you need to find and install a third-party module, if one exists.

And due to string immortality there are stupid things it lets you do, like this

Code:

s = ''
for i = 1, 100000 do
    s = s .. 'a'      -- string concatenate
end

which takes 33 seconds to complete on my machine because it makes a copy of the string each iteration and collects garbage every few times.

Problems with dynamic languages in general:

In larger projects, you need to know the type of the variable you're using, especially if it's a method that depends on a certain object entering it. So the language being dynamic really doesn't give me any flexibility as reassigning types doesn't do any good within the scope of the method. So instead I have to name a variable in such a way that its association with an object or primitive is obvious. These days I tend to program Python like Java/C# due to this problem.

Well, that's not an issue with dynamic languages. That's an issue with typedeclaration. LISP and ActionScript are e.g. dynamic languages, and usually don't typedeclare variables. However, it is possible to do in order to optimize speed, or what you describe.

Lua's not a programming language

I guess the main "issue" is that it's designed as an extension language so it's really not suitable for large standalone projects, for similar reasons Fiel mentioned about Python. Then again I don't do large standalone projects in the first place, or really anything used by other people, so it's all good for me.

Also it's very minimalistic in terms of syntactical constructs and standard libraries, so you don't have classes, bit ops, regex, etc and so for pretty much anything beyond basics (math, string, list, I/O, system) you need to find and install a third-party module, if one exists.

And due to string immortality there are stupid things it lets you do, like this

Code:

s = ''
for i = 1, 100000 do
    s = s .. 'a'      -- string concatenate
end

which takes 33 seconds to complete on my machine because it makes a copy of the string each iteration and collects garbage every few times.

C# and Java have StringBuilder classes that allow you to build up a string like in that loop without incurring the cost of creating a new string object with each concatenation. Maybe Lua has something like that?

Last time I checked, Java knows not about unsigned primitives. It was a total shocker to everyone when I asked "how to unsign long?"

C# and Java have StringBuilder classes that allow you to build up a string like in that loop without incurring the cost of creating a new string object with each concatenation. Maybe Lua has something like that?

Well yeah the proper way to do it is insert all the little strings into a table and call concat() to collapse them all into one, like so:

Code:

t = {}
for i = 1, 100000 do
    table.insert(t, 'a')
end
s = table.concat(t)

which executes almost instantly.

It's just that the naive method has ridiculous costs, that's not to say there isn't a better method, and it isn't the most straightforward one.

Last time I checked, Java knows not about unsigned primitives. It was a total shocker to everyone when I asked "how to unsign long?"

BigInteger, a very slow implementation that handles any amount of huge digit

Code:

long val = 123456789;
BigInteger uLong = new BigInteger(String.valueOf(val & 0xfffffffffffffff));

Something that I'm very annoyed with when dealing with conversion of code between C/C++ to Java such as Nexon's Randomizer.

Problems with C# (version 4) in general:

- Compiles to MSIL, no (feasible) way to compile to x86. You either use commercial products to compile everything your application depends on to x86, or you live with MSIL (and JIT). There is also AOT but that is merely for improving performance, not for running applications on platforms without .NET.
- .. nothing with the language ...

Problems with the .NET Framework in general:

- Cross-platform interoperability - it took Microsoft years to develop. Now the open source community has to match that, if they want it on linux and Mac. PITA, much?
- It is huge. But Vista/7 now come with .NET Framework 3.5 so that isn't much of a problem.
- Too easy to reverse engineer - suppose this is a problem with all intermediate languages

Other than that, I love C#.

Not really, C# can be difficult to be reverse engineer with the correct tool.
Till now I've yet to see any good proxy API based obfuscation on Java and C#, which I've been working on it at around January 2010. With that, all the APIs from Sun/Microsoft can be obfuscated and renamed to our own custom one and compiled into the executable. That will create a whole chunk of garbage that cannot be understood by people.

I guess you've tried decompiling CSharp's client?

BigInteger, a very slow implementation that handles any amount of huge digit

Code:

long val = 123456789;
BigInteger uLong = new BigInteger(String.valueOf(val & 0xfffffffffffffff));

Something that I'm very annoyed with when dealing with conversion of code between C/C++ to Java such as Nexon's Randomizer.





Not really, C# can be difficult to be reverse engineer with the correct tool.
Till now I've yet to see any good proxy API based obfuscation on Java and C#, which I've been working on it at around January 2010. With that, all the APIs from Sun/Microsoft can be obfuscated and renamed to our own custom one and compiled into the executable. That will create a whole chunk of garbage that cannot be understood by people.

I guess you've tried decompiling CSharp's client?

You might have some clever tricks here and there but in the bottom line .NET is far easier to decompile than any native language.

BigInteger, a very slow implementation that handles any amount of huge digit

BigInteger, a very slow implementation

a very slow implementation

very slow

*facepalm* Unacceptable, just simply unacceptable.

And yes I know about it after doing the programming challenges from projecteuler.net :o Even though BigInteger works for their challenge, it is simply magnitudes slower for my purposes.