Worst language features, all languages?¿?

Hello all,

I've recently, for the past 3 months or so, been relearning JavaScript in order to build a game engine based on the new HTML5 canvas API.

I first learned it as a young teen, and at that time was oblivious to it's downsides. Now that I've delved deeper into the actual language (rather than just making pretty effects), the downsides stick out more blatantly.

For instance the same mechanism that makes closures possible (scope reference chain), also makes it possible to sneakily create global variables from undeclared ones.

Also being able to call methods from different objects with a similar interface allows polymorphism, but when the same functions are called without an object, the 'this' is bound to the global object (called "window" in browsers), unless you state that you want to use strict mode.

This isn't to bash any language, I just have a theory that bad features often come as a side effect of doing old things in new and interesting ways.

So basically, I'm wondering what are the worst language features of any language you know? Also, any reasoning for their inclusion in the language of reference is a plus!

:wink:

Quote:

---

Originally Posted by Alpo

So basically, I'm wondering what are the worst language features of any language you know? Also, any reasoning for their inclusion in the language of reference is a plus!

---

That which annoys me most is dynamically typed languages where anything and everything is a variable and anything is a property or method, or "undefined" if it doesn't exist. *cough* javascript *cough*
The reason is simple: so many bugs that are typically found at compile-time are now shifted to runtime instead.

"Register globals" in PHP. It has been removed now but damn did it cause a lot of security issues when it was still widely used.

Quote:

---

Originally Posted by Alpo

For instance the same mechanism that makes closures possible (scope reference chain), also makes it possible to sneakily create global variables from undeclared ones.

---

Only if you actively do it.

Quote:

---

Originally Posted by Alpo

Also being able to call methods from different objects with a similar interface allows polymorphism, but when the same functions are called without an object, the 'this' is bound to the global object (called "window" in browsers), unless you state that you want to use strict mode.

---

Only if you actively do it.

Quote:

---

Originally Posted by Alpo

This isn't to bash any language, I just have a theory that bad features often come as a side effect of doing old things in new and interesting ways.

---

I have a different outlook. Bad features are either:

• The absence of a feature. This is the cardinal of bad features. In a programming language, no feature means no dice. And not being able to do something with a computer language is pretty much the equivalent of limiting the English vocabulary to just the words we want. Which makes for a pretty lame conversation.
• A feature that doesn't work as documented. This of course includes bugs but NOT features that kill/crash the application or burn the computer if this is explicitly told in the documentation. Exceptions are good features, and overclockers rely on multitasking to burn their test processors.

As I tried to illustrate above in an answer to your worst features list, a feature with usage rules and documented patterns isn't a bad feature. It's a good feature and quite possibly even a great feature. It's your fault if you don't care enough about your programming language to learn its semantics and idioms.

It is in trying to protect the programmer against itself that we have been devising ever more weak programming languages. It is in looking at programmers as irresponsible children that need orientation, that we have been devising ever more limited programming languages. And as a byproduct of all that, we have been breeding ever more weak and limited programmers.

In fact one of the worst tragedies to ever happen to computer science was when the first person came up with the idea that programming languages should be created on top of Ideology.

But, won't help to cry of spilled milk. Just know that you should really quickly drop your idea that a bad feature is a feature that expects you to think before you use it. That is exactly what constitutes a great feature.

Just like with the example Elysia gave of a bad feature. (and that was unfortunately upvoted by a good deal of people).

Dynamic typing is not a bad feature. It is in fact a good feature. In fact a great feature to have in many (but not all) contexts! Just learn to use its decades-old and well-documented patterns and idioms. If you do that you will realize the whole runtime debugging scaremongering BS he speaks of is complete and utter nonsense. But if instead you choose to stay anal retentive to different programming paradigms than the only bad feature in here is You.

Bless the language that gives you the choice between dynamic and static typing, and, why not, between strong and weak typing.

And the only reason I'm making this post so long is because this is an issue dear to me. I want programming languages that offer me choice and aren't afraid of programmers. And I want back those geek and unkempt intellectual programmers, instead of the vanity types polishing their tin medals on top of justin bieber programming languages.

Now... to end this, two features I don't like about Python, the language I have been learning of late:

• No function overloading
• import this

Quote:

---

No function overloading

---

O_o

Quote:

---

No native function overloading

---

o_O

I fixed that for you.

Sure, the example is simple. You need to instill quite a lot more power to give enough juice to be really useful, but the example shows the beginning of a possible path, and I would imagine that anyone using a version with decorators would prefer the sugar.

Soma

Code:

---

class FunctionOverloadable(object):
    def __init__(self):
        self.mSignature = {}
    def __call__(self, *args):
        self.mSignature[tuple(c.__class__ for c in args)](*args)
    def overload(self, fSignature, fImplementation):
        self.mSignature[fSignature] = fImplementation

DoSomething = FunctionOverloadable()

def DoSomethingImplementation(f):
    print("int")

DoSomething.overload((int,), DoSomethingImplementation)

def DoSomethingImplementation(f):
    print("float")

DoSomething.overload((float,), DoSomethingImplementation)

DoSomething(1)

DoSomething(1.0)

---

Quote:

---

Originally Posted by Mario F.

Only if you actively do it.

---

I said, "makes it possible". The rules of the language make these things possible even when not actively doing it (else there would be no need to not do it).

I like dynamic typing, but I also agree that the analysis tools that I have aren't the most helpful. JsLint is probably the best, and most of it's analysis is "Look here, you're letting JavaScript use its own type coercion!", or "Put the use strict statement at the top of your functions!". However, it can't deal with things like circular type declarations (that is if class b uses class a, and vice versa, then it will say you are using a type before its been declared).

Quote:

---

Originally Posted by Mario F.

Just like with the example Elysia gave of a bad feature. (and that was unfortunately upvoted by a good deal of people).

---

I didn't say it was a bad feature (i.e. a poorly designed feature agreed as a whole by a community or experts). I said it annoyed me.
Dynamic typing can be both good and bad. Ups and downs. For me, the way javascript does it is a huge down for me. But that's me. For others, it may be a huge up.

Quote:

---

Originally Posted by Mario F.

Just learn to use its decades-old and well-documented patterns and idioms. If you do that you will realize the whole runtime debugging scaremongering BS he speaks of is complete and utter nonsense.

---

It's not.

Quote:

---

Originally Posted by Mario F.

Bless the language that gives you the choice between dynamic and static typing, and, why not, between strong and weak typing.

---

I'd like such a language.

In my opinion the worst language feature and most oft-abused goes to C#.

It is var. Its very name can spawn a debate in the friendliest of places. Likely even in this thread.

Spawn of the devil. Let's hide the actual type of the variable from the person who needs to see it most (the developer) while maintaining its type under the hood to ..um...save typing. Valid use case for LINQ expressions but unfortunately its use was not limited to LINQ by the compiler. Now it's just a mess and has spawned a million debates.

Worst offender and propagator of var nonsense: ReSharper.

That's interesting because I find features that deduce type to be the holy grail. They save on typing, and automatically match types so you can "forward" types in a local function without having to go back and change every type if you change one and they can make code less verbose by omitting the type. I'm sure there are all kinds of debates, but in my opinion, a good IDE should show you the type, or you can easily jump back to the definition. Visual Studio provides such features, making it easy to use these type deducing keywords.

I also don't really like dynamic typing. Maybe it's because I started with languages that were statically typed but I feel the same as Elysia about it. That being said, I'm amazed at the power of languages like JavaScript and PHP. What they allow you to actually do is astounding to me but that might just be because I'm late to the web development party.

Quote:

---

Originally Posted by VirtualAce

In my opinion the worst language feature and most oft-abused goes to C#.

It is var. Its very name can spawn a debate in the friendliest of places. Likely even in this thread.

---

I'm pretty sure JavaScript did it before C#. And probably other languages before that. I personally avoid using it in production code unless it's a LINQ result.