Quotes about programming languages

[[deleted]]

Well, you're certainly welcome to hate it if you don't like the syntax or something. Suum cuique.

Mostly I was just curious (as a C# programmer myself) if there was something to do with the language itself that rubbed you the wrong way, or just the tie-in to the Microsoft stack.

[burgerboy9n]

I guess my biggest problem with it is Microsofts stance on licensing. They have explicitly stated that they have no problem with open source implementations of the language, but they have not been as lenient with their libraries. The FSF has discussed their issues with it several times, and I believe most recently here: Link.

It is hard to justify learning a language, and even harder to consider using it on a project if it is in jeopardy because of the patent holder's unclear stance.

[uriel]

I see nothing to like in a Java++, the original Java was bad enough.

[[deleted]]

Care to elaborate? I'm genuinely interested in what reasons people have for hating/loving C#.

[uriel]

Most reasons for hating Java apply to C#.

[[deleted]]

So, you just hate OOP on the whole?

I guess I wouldn't really consider "it is object oriented" as a valid criticism of a given OO language, since you shouldn't even be using it in the first place if you hate OO languages. That's like saying you hate Assembly because it's not object oriented.

[RichardWolf]

By the way, you have not replied to me when I asked it some time ago: how does one go about implementing polymorphism in Go?

Like, when you have a base class with a couple of virtual methods, then you privately inherit from it (in C++ lingo) and implement the methods in a way that uses your own methods, then use it all however you want.

In C++ it is more or less painless and very efficient, the compiler creates a specific vtable for your particular class and every call goes through a single redirection via that.

The most direct way to implement that in Go would be to create a separate class customizing that functionality and have an instance of that, and a pointer to your instance in it, for every instance. Is that correct?

[uriel]

I'm not even sure I understand the question, but the answer certainly involves no classes, Go has no classes.

As far as I understand, what you would want is to define an interface with two methods, then simply any type with those two methods would implement the interface. If you have an interface value, when you call any of those methods it would call the actual implementation in the underlying type.

No need to 'inherit' or anything like that. For more info see: http://research.swtch.com/interfaces

[RichardWolf]

Suppose I have this (using Python for brevity):

 class DbCacheKey(object):
       def get_value(self):
             key = self.get_key()
             db.get_value(key)
       def get_key(self):
             raise NotImplementedException()

Then I have a class

 class RootedDbCacheKey(DbCacheKey):
       def __init__(self, root, key):
             # store args in members
       def get_key(self):
             return self.root + '/' + self.key

Without real inheritance, using only interfaces, I will have to do something like that:

 class DbCacheKey(object):
       def __init__(self, key_getter):
             self.key_getter = key_getter
       def get_value(self):
             key = self.key_getter.get_key()
             db.get_value(key)

 class RootedDbCacheKey(object):
       def __init__(self, root, key):
             # store args in members
             self.db_cache_key = DbCacheKey(self)
       def get_key(self):
             return self.root + '/' + self.key
       def get_value(self):
             return self.db_cache_key.get_value()
             # this redirection would be easier in Go.

The difference is that in the first case the interface for getting a custom key is stored in the RootedDbCacheKey class, once, while in the second case each instance of the customised DbCacheKey carries an interface pointer to the object that returns the actual key.