next »

[ஒழுக்கின்மை (Paul Eres)]

I think it may have to do with personality: if a program presents me with too many options, I feel that's taking control away from me, not giving me more, because of all the confusion all those options entail. If you teach a child 20 different ways to tie their shoes, that doesn't give them more control than if you just taught them one way, it gives them less.

And why I think so is that I often come upon errors just due to how I named variables (such as naming something two identical variable names, or misspelling a variable name) and those errors wouldn't exist if we didn't use variable names at all. It'd make dealing with variables a lot harder, but you wouldn't have those errors.

[BorisTheBrave]

What are you talking about rinkuhero? You'd have exactly the same problem if you used fixed memory locations, only you'd confuse them even more as they aren't sensibly named.

Mebbe you'd like a concatenative language like Factor, it has no variables at all, just a stack.

[ஒழுக்கின்மை (Paul Eres)]

And I didn't mean that writing assembly language has *fewer* errors overall, just that it has fewer errors of the type mentioned (errors having to do with mixing up data types). I don't think the goal of a language should be to reduce the number of errors the programmer makes in it. The goal of a language should be to be able to ignore those errors and still work. Much like how you can understand a sentence in English even when there are grammatical and spelling errors.

[ஒழுக்கின்மை (Paul Eres)]

I don't think there'd be as many misspelling errors because variable names would be just random strings, which you'd copy and paste, so you wouldn't remember them as words, and there'd be fewer misspelled variable names.

And I wasn't arguing that it'd be a good thing to do that, just that it'd reduce errors (of a certain type) but be harder to use and cause other problems. Same with my assembly analogy.

[increpare]

Using types to represent dimensions is a neat trick, but one I don't miss massively. On the other hand, dynamic types open up all sorts of other neat tricks that are incredibly useful, like duck typing, or monkey patching.

I have to say that I'm not too familiar with these techniques (the main dynamically-typed language I use is PHP, and I don't use it in a very high-powered way at all).  I guess I should look 'em up   [edit: I don't think monkey-patching strictly requires dynamic typing, does it? it seems like it could work with any interpreted language  (duck typing though seems like it would)]

And I wasn't arguing that it'd be a good thing to do that, just that it'd reduce errors (of a certain type) but be harder to use and cause other problems.

Yes, introducing static typing means that people are going to have to type in the type names.  But would I rather have my compiler halt on typo-related errors or to miss type-related errors?  I'd go for the latter, all things being equal.  (the changes in readability are a different issue, for me, but one I'd be happy to discuss).

I don't think the goal of a language should be to reduce the number of errors the programmer makes in it. The goal of a language should be to be able to ignore those errors and still work.

I find this interesting.  One main example would be HTML I guess.

I have trouble imagining a more complicated language working too well that way: the semantics of most programming languages are waay too complicated for error correction to do anything other than confuse things.  I think there's a definite possibility that such languages might take a lot more effort to understand than not.  Natural language can get by because it's pretty ambiguous to begin with, but when one is trying to code in an exact algorithm, the philosophies seems to grate off one-another.  Though maybe that's the clue: a fuzzy programming language would work well if one was looking to write a fuzzy program?

For me, syntactic rigour isn't a problem when it comes to programming.  That said, I don't know if I've tried anything fuzzier?

to requote:

The goal of a language should be to be able to ignore those errors and still work.

What about environments that prevent you from making a lot of errors in the first place (like those with visual interfaces; mmf2, or the gamemaker visual one)?  Stuff this might get around some of the typo-related concerns you had (say having an IDE that would automatically fix spelling mistakes as you went along).

[nihilocrat]

It would be more fair to compare Java or AS3 to Python or GML.

Yeah, honestly a lot of my reasoning is just issues I have with C/C++ (but moreso with C++). I do hate the OO model of both C++ and Java, though. It all boils down to putting in more work in order to accomplish less. I see lots of advantages to static typing, but most of them are performance-oriented. The compile-time safety net, when removed, just forces you to be more disciplined about your code and not let variables get passed around too much without their 'duck type' getting effectively checked when that variable actually needs to be used for something.

I tried using D once for a game, but had some issues with getting somesuch thing to work and left it alone without giving it a real try.

What about environments that prevent you from making a lot of errors in the first place (like those with visual interfaces; mmf2, or the gamemaker visual one)?  Stuff this might get around some of the typo-related concerns you had (say having an IDE that would automatically fix spelling mistakes as you went along).

The importance of a good IDE and good set of generic programming tools (plus good game-specific tools) is vastly understated. A good IDE keeps you from making countless typos or spending tons of time looking up API docs, which are non-trivial activities. Remember that there are people in the gaming industry whose sole job is to write tools for games and game engines.

I think, because it's an abstract art, people fail to see how a nailgun will do the job better than a hammer, because the hammer is still going to let you put a nail through some wood without having to mess around with pressurized air or electricity.

[ஒழுக்கின்மை (Paul Eres)]

It's not just that they have to type in the type names, it's also that they have to learn and keep in mind all those various data types when it's unnecessary for most programming tasks to do that. For instance, GML only has two types: double/float and string. Everything is either one or the other, there are no integers, chars, etc., and that works fine. It just adds unneeded complexity to the programmer's mind to have to deal with all the other types, with little advantage. In most situations better if the compiler handles it, just as it's better when the compiler handles memory addressing for variables.

Again, I think this comes down to a personality difference, some people want all the options laid out for them and want full control, others are more comfortable when it just works. I don't think it's a matter of being fuzzy, any more than sketching a drawing rather than defining the location of every line is fuzzy; higher levels of abstraction aren't fuzzy, they're just higher levels of abstraction.

[ஒழுக்கின்மை (Paul Eres)]

As for visual environments, I think they're good in theory but in practice they're slower than just typing stuff out. For instance, let's say I wanted to define the behavior of an enemy. Doing that in Game Maker's drag and drop system that'd involve way more work than typing it out in GML code, even though you can do it in both. So I'm all for visual environments provided they actually are faster and easier than scripting, but in the examples of it I've tried scripting is faster and easier.

[increpare]

Yeah, honestly a lot of my reasoning is just issues I have with C/C++ (but moreso with C++). I do hate the OO model of both C++ and Java, though.

What languages would have OO models you have more sympathies with?

For instance, GML only has two types: double/float and string. Everything is either one or the other, there are no integers, chars, etc., and that works fine. It just adds unneeded complexity to the programmer's mind to have to deal with all the other types, with little advantage. In most situations better if the compiler handles it, just as it's better when the compiler handles memory addressing for variables.

Ah!  But it's possible to program in C/C++ using just double/floats and strings as well.  I can understand, from this perspective, why you'd want to minimize the number of types in a language.  However, this is, to be sure, a different issue from that of static/dynamic typing.

I don't think it's a matter of being fuzzy. [...]

Maybe I was using a very idiosyncratic usage of the word; in any event, I don't disagree with what you say from this sentence on in this paragraph, so maybe best to forget I used it at all...

[ஒழுக்கின்மை (Paul Eres)]

I don't think I'd have a problem with asking the user to name whether a variable is a float or a string, that's not a huge issue. I don't think it matters one way or the other anyway. The only time it's really a problem is when you try to use a string as a float or vice versa.

There have been a few times when using a variable as both, in different points in the program, has been useful: there's even an is_string() function to tell the difference. For instance, in Fedora Spade, I default a variable that I intend to use for strings to 0 and then use is_string() to determine whether or not there's a string assigned to it. I could just do (variable == "") too, but I find is_string() more convenient, especially because sometimes I *want* it to have an empty string, and I want to be able to tell the difference between empty strings and no string assigned.

[increpare]

I don't think I'd have a problem with asking the user to name whether a variable is a float or a string, that's not a huge issue.

So that means that you're (at least not very much not) okay with static typing I guess? ;P

There have been a few times when using a variable as both, in different points in the program, has been useful: there's even an is_string() function to tell the difference. For instance, in Fedora Spade, I default a variable that I intend to use for strings to 0 and then use is_string() to determine whether or not there's a string assigned to it. I could just do (variable == "") too, but I find is_string() more convenient, especially because sometimes I *want* it to have an empty string, and I want to be able to tell the difference between empty strings and no string assigned.

By ways of comparison (for the sake of comparison, rather than to prove any particular point).  If one was to tackle this in C, one might model this having a NULL pointer play the role of 0. 

bool is_string(char* c)
{
    return (c!=NULL)
}

In haskell, one could use the Maybe monad

isString :: Maybe String -> Bool
isString Nothing = False
isString Just _ = True

[ஒழுக்கின்மை (Paul Eres)]

I'm okay with static typing provided there are only two (or a few) types. What I don't like about static typing is that in languages that use it there are usually dozens of types to keep straight. I don't think all those types are useful: if a float can do everything an integer can do, and usually just as fast on modern computers, why even support integers at all, or bother to teach them to programmers?

[mirosurabu]

There is almost no difference in using variant classes in C++ and dynamic typing as in PHP and GML, right?

[increpare]

I'm okay with static typing provided there are only two (or a few) types. What I don't like about static typing is that in languages that use it there are usually dozens of types to keep straight. I don't think all those types are useful: if a float can do everything an integer can do, and usually just as fast on modern computers, why even support integers at all, or bother to teach them to programmers?

floats are nice, but have problems when it comes to approximation.  For instance 1/3 doesn't have an exact floating-point representation, and one in general has no guarantee that statements like 1/3+1/3+1/3=1 will hold for floats, and one wouldn't expect it to.  For tasks like these, other number formats are nice.  Some languages have 'fractional' data types, where you can specify a fraction as a pair of integers.  These can be nice as well for a lot of things, and avoid the trouble with equality (though of course they're useless when it comes to trigonometry and the like).  

I personally learned how to deal with integers before I came to terms with floats*.  For games programming, when one is working on a 2d grid that one accesses via integers (provided one isn't doing too much rotating), they make more sense.  Integer division takes a small bit of getting used to, but once you get it, there are really no more surprises.  From this perspective, your emphasis on floating-point data-types is sort of funny .

But, I agree that it's possible to write very versatile programs using only a small set of fundamental types (I'm allowing for people to build compound classes from these basic types, but I guess that's not really necessary either).

(*indeed, because I was learning pascal first, I used its 'Real' datatype in preference to floating-point ones for some time)

[nihilocrat]

What languages would have OO models you have more sympathies with?

Well, Python, of course , but also Javascript, which isn't technically OO but 'prototype-oriented' or whatever the correct term is. Steve Yegge has a pretty good description of it here.

A quote comes to mind:

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

Basically, the model is really simple and stays abstractly clean by having everything as an object. It eschews some of the things that were drilled into me as a student (encapsulation via public/private) and instead asks for a bit of discipline on the programmer's part to use convention (_foo() methods are understood as private, but not enforced) without actually having the model itself enforce these things. The duck-typing system means that you don't have to create virtual methods/members in anticipation of creating a subclass that fulfills them; at runtime, the method/member is either there or it isn't, and your subclass can freely implement them or override old definitions without any extra hoops to jump through.

The 'Pythonic' way of accessing members would be considered naiive by even a beginner in C++; you just directly access foo.member and do whatever you want with it, so there's no real encapsulation. If you want to write special-purpose getters and setters, you can write __getattr__ and __setattr__ (google "python special names") for your classes to handle that, but by default you are saving yourself from writing a bunch of meaningless getters and setters.

It's much closer to pure OO than C++ or Java are. There are a whole lot of OO design patterns out there which are married to C++ or Java style OO, and are either completely unnecessary or much more straightforward to implement in Python.

I'm okay with static typing provided there are only two (or a few) types. What I don't like about static typing is that in languages that use it there are usually dozens of types to keep straight. I don't think all those types are useful: if a float can do everything an integer can do, and usually just as fast on modern computers, why even support integers at all, or bother to teach them to programmers?

I don't really mind tons of types, it's always going to be simpler than the data types you run into with a database. Usually they are pretty logically named (const unsigned long int : a double-size integer that cannot be negative and cannot be reassigned).

An int calculation is going to be faster than a float, especially where multiplication or division is involved. For operations that are going to be occurring thousands or millions of times a second, this can add up to a non-trivial amount of time. There are a bunch of other reasons why, and they basically add up to CPU or memory optimizations. You are correct, however, that these optimizations are becoming less and less important versus program design or non-technical optimizations.

[increpare]

There is almost no difference in using variant classes in C++ and dynamic typing as in PHP and GML, right?

I haven't looked at boost::variant yet, but it seems so

It's much closer to pure OO than C++ or Java are.

Careful there!

(I'll check out the article that you linked to now...)

[nihilocrat]

Careful there!

Are you pointing out that it classifies Python as an impure OO language? I checked the history, and it seems no one has updated that since Python 2.3 or 4ish, where the base types truly became fully fledged objects.

The biggest impurity that I can see, based on that article, is no explicit encapsulation.

More importantly, even suggesting that Python's object model is similar to Java or C++ is bogus, I think the article is speaking accurately of older versions of python, but suggesting the wrong idea. The lack of encapsulation is something people notice immediately.

Oh, in case you don't want to read the whole article, this is the one paragraph that explains the crux of the property / prototype pattern:

But here's the rub: even though [L.T.]'s a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player.

It's pretty simple to implement in Python, thanks to the __dict__ member that exists in all objects:

Code:

class Prototype(object):
    """
    Prototype base class
    """
    def __init__(self, template=None):
	if template:
            self.copy(template)
        
    def copy(self, template):
	try:
	    # check to see if we are getting passed an object or a dict
	    template = template.__dict__
	except AttributeError:
            pass
        self.__dict__.update(template)

    def has(self, keyname):
        return self.__dict__.has_key(keyname)

I added the ability to pass Python dicts, because instead of using XML or INIs or some simple text file to store data, I just store it in .py files that contain Python dicts. I can then create objects in game by just passing one of the entries in this dictionary, which is itself a dictionary, to the Prototype's constructor. I do some magic with Python's import system so that I can import these files, as text, at runtime. This means that I can edit/reload them while the program is running if I wish, or I can load them as seperate user-editable text files if I've packed up the rest of my code with py2exe.

Actually, I suggest everyone to read the Steve Yegge article I posted above, because he talks about the game scripting interface he has for his MUDish MMO Wyvern.

[BorisTheBrave]

I'm okay with static typing provided there are only two (or a few) types. What I don't like about static typing is that in languages that use it there are usually dozens of types to keep straight. I don't think all those types are useful: if a float can do everything an integer can do, and usually just as fast on modern computers, why even support integers at all, or bother to teach them to programmers?

Man, there are some days when I just wonder whether rinkuhero spends his time trolling the technical boards. But then I realize the corrupting influence of Game Maker.

Already spelt out are good reasons you'd want an int type. I recall yourself lamenting earlier that saving a score in game maker can sometimes give 7.99999 and that sort of thing. And there are tons of other types you are using, but don't appreciate. Arrays for example, or sprites.
And in OO languages, you can define your own classes. Each class is a type as well, as if I have a Circle, it is not the same as a Square, just the same way a string is not a float. Types really become important when you start dealing with this sort of thing, as an instance of Square and an instance of Circle share something in common, they are both instances of Shape (inheritance), so I can sometimes treat them similarly. So it's guaranteed that there are many types the programmer needs to keep straight, and static typing helps with that immensely.

[brog]

So like, if ints can do anything floats can do - add, divide, multiply - as well as some other useful stuff like representing values precisely, modulo operator, not having gaps when you get to large numbers.. why do we even need floats at all?  They're a bit slower even on modern computers and they're clearly not as good.  I only ever use floats in graphics code, everything else is done precisely to make it easier to keep networked players in sync.

[BorisTheBrave]

No one said ints can divide. Clearly, they cannot: 5/2 = 2.5. They also don't represent as large a range of values as floats, or as small.
ints and floats are both completely necessary, brog. Believe it or not, language designers have put a bit of thought into this.