next »

[Aaron P]

Ok, this may be a silly observation ( and abit obvious) but bear with me, I just started this programming stuff.

Ok, so I've been learning GML for the past couple of weeks, and today I was at the library and decided to pick up a Python/PyGame book, just because I had heard about how easy Python was to use.

So granted, I have only delved into the introductory chapter of the book, but as I read, I start to realize, this is feeling abit like GML.

Are pretty much all programming languages built on Strings,  lists, etc? Or is it just a similarity between the two? Once again, may be a stupid question...

[increpare]

Are pretty much all programming languages built on Strings,  lists, etc?

Most languages feature strings and lists (or things like them).  Whether on not one one makes a lot of use of them (or would want to make easy and frequent use of them) depends on the language.  Lisp, for instance, is entirely oriented about lists, whereas in C, for instance, lists are a bit awkward, with fixed-length arrays, or pointers to variable-length lists being more 'basic' than lists (qua linked lists).  But, it's true that most languages feature most datatypes.

[Core Xii]

Yep. This is why GML is great for learning general programming - It's easy to pick up other languages.

[BorisTheBrave]

It's really quite hard to describe what differences there are between languages. Most languages have basic features (such as strings and lists), but each usually introduces some new way of dealing with things, or extra types it can handle. And you can only really appreciate that new thing by attempting a language that uses it extensively. Of course, every language can do everything, if you write enough code, so there is some debate over exactly what features each language has. As increpare says, you wouldn't really recognize lists in C as the same as in GML, as they require more work, and work differently.

GML itself introduces a fairly standard set of concepts, which you will see in some form in virtually every other language. But that's not to say that all languages are "built on" them, as they rely on such basic concepts to varying extents.

Python is a good move for you, it will strike you as similar to GML, more than other languages, while still introducing new concepts and better habits you will be able to transfer to other languages.


Core Xii:
I'm not sure I agree. While GML is no where near as bad as VB for teaching people bad habits, it still has things which you will have to unlearn in order to move to other languages. E.g. freely converting from integers to sprites.
Learning most all languages makes it easy to pick up other similar languages, it's the first which is hard.

[increpare]

I'm not sure I agree. While GML is no where near as bad as VB for teaching people bad habits, it still has things which you will have to unlearn in order to move to other languages. E.g. freely converting from integers to sprites.
Learning most all languages makes it easy to pick up other similar languages, it's the first which is hard.

Seconded: static typing for the win ;P

[Core Xii]

While GML is no where near as bad as VB for teaching people bad habits, it still has things which you will have to unlearn in order to move to other languages. E.g. freely converting from integers to sprites.

...what? Integers to sprites? Maybe it's just been so long since I grew out of GM, but I have no idea what you're talking about.

[increpare]

...what? Integers to sprites? Maybe it's just been so long since I grew out of GM, but I have no idea what you're talking about.

I think he means that you can do things like

intNumber = 1;
intNumber = "This variable now contains a string";


(taken from the wiki)

[Core Xii]

It's just implicit type conversion. Many other languages have that as well. It's not a bad concept IMO, it simplifies the learning process.

[increpare]

It's just implicit type conversion.

No it's not. (unless it stores 1 as a string "1"?). Most languages have implicit typing, but not all (Haskell, for instance, doesn't).

The term you're looking for is dynamically typed.  Many languages have this (php and lisp, for two), but not the majority, I think.

There are advantages and disadvantages to all these various methods.  Static typing can be absolutely lovely in some situations, and dynamic typing can also be.  Implicit typing can also be pretty handy.  They all have their drawbacks as well, of course.

[BorisTheBrave]

No, I didn't mean dynamic typing. That's an awesome thing for a language to have, and probably the single biggest difficulty between learning "scripting" languages like GLM and learning hardcore languages like C++, which is statically typed. (Pointers being a close second, of course).

I'm not a GM user myself, but I thought if you used integers like objects, it automatically found the sprite with that id.
E.g. with(5) {...}  or (5).x
This is implicit type conversion, though I bet the GML reference never uses that term. But it is a completely inappropriate conversion, both in the circumstances you can use it, and converting from one thing to another that behave quite differently. Too much implicit conversion makes it very hard for the novice programmer to get a decent understanding of types, and then they are confused when a different language expects them to appreciate this.

[increpare]

No, I didn't mean dynamic typing. That's an awesome thing for a language to have, and probably the single biggest difficulty between learning "scripting" languages like GLM and learning hardcore languages like C++, which is statically typed. (Pointers being a close second, of course).

Wow.  I strongly disagree that dynamic typing is a better thing than static typing (I do think it has its good points, but that's it's not a matter of better/worse).   Using statically-typed languages that don't implicit type conversion has saved me a hellova lot of debugging time; the compiler can catch a whole swathe of programming erros at compile-time that it would miss in C/C++, say.  It also allows one to do things like implement systems of units (so that you don't add meters to seconds, for instance), without adding any run-time overhead. 

I mean to say, I have love for both static and dynamic typing.

[nihilocrat]

If you start coding in a dynamically-typed language with a large standard and non-standard library (Python) you will probably never look back at C/C++.

You will have to deal with two things:
* The only compile-time errors are syntax ones, so you will experience most of your errors at runtime. This is really really annoying for someone coming from C/C++ who is thankful that their types are checked. You eventually deal with it and find ways to make your code less likely to have obscure type-related errors, probably involving frequent use of try/except blocks.
* Compared to C/C++, it's slooooooow, so you will want to either use existing libraries coded in C/C++ or write your own libraries which you then use in Python via ctypes or SWIG or Py++ or whatever you want. You can also use Pyrex, which is a bit friendlier than trying to make a wrapper or use an FFI.

[increpare]

If you start coding in a dynamically-typed language with a large standard and non-standard library (Python) you will probably never look back at C/C++.

'probably never look back'?  I call BS.

[nihilocrat]

Okay, explain.

The only time I code in C/C++ is when I'm really really concerned about speed. I usually then wrap the code for use in Python. Generally I hate how I am usually writing tons of boilerplate code or trying and failing to link libraries when I want to use some existing library out there. You have to pray that they chose to use your compiler of choice to compile their libraires, or be forced to compile their lib yourself and more importantly compile all the myriad dependencies.

I like languages that let me concentrate more on the actual work at hand. I code in C/C++ only if I really have to, because except for the simplest tasks I'm used to having to deal with huge categories of new errors and annoyances. Thank god I at least know how to use STL; not having a string type, associative arrays, or variable-size lists built into the language is really painful.

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

Why would a programmer need a decent understanding of data types if they only use languages that don't use data types, though? Data types may one day be outdated, like "goto" in BASIC. What advantage is there to forcing the programmer to keep all their data types separate?

[increpare]

Why would a programmer need a decent understanding of data types if they only use languages that don't use data types, though?

All languages use data types, be it implicitly or explicitly.  I take it you mean static-typing.

The only time I code in C/C++ is when I'm really really concerned about speed.

I'm pretty much in the same camp.  However, when I'm not concerned about speed, I generally use Haskell, which has a much stricter typing system than C/C++ (no implicit type conversion).  And that's one of the things I like about it.

Data types may one day be outdated, like "goto" in BASIC.

Good old goto ... I actually have tossed in the odd naughty goto into my current project   

What advantage is there to forcing the programmer to keep all their data types separate?

Because it helps keep large-scale project organised.  They also allow the programmer to set up various formalizations (the example before about being able to differentiate between minutes and seconds), and to have the compiler be able to deal with them.  To this extent, static typing (esp. without implicit conversion) allows for me to express* certain things  that I couldn't with a dynamically-typed language. 

I don't think of static typing as being something of a restriction on the things a programmer can do, but it can just as much function in a constructive way.

Goto went down because it lead to a lot of errors.  Static-typing reduces the number of errors that make it past the compiler.


*in the nontechnical sense.

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

Sure, but writing in assembly would reduce the number of errors that get past the compiler too, wouldn't it? The more specific and detailed you force the programmer to be, the more control they have, but the harder it is to maintain that control. Replacing variable names with memory addresses would also reduce the number of errors. But I think the ease of use of variable names outweighs the benefit of fewer errors.

[Bad Sector]

If you start coding in a dynamically-typed language with a large standard and non-standard library (Python) you will probably never look back at C/C++.

'probably never look back'?  I call BS.

Indeed i have worked with both dynamically and statically typed languages and i even wrote both kinds of languages and yet i still prefer statically typed to dynamically typed. The only case where dynamically typed languages are good is for small/hacky scripts where you don't really care what it'll look or work after a while because for the short term its easier to work with them.

As about goto, i frequently use it for cleanup cases in C/C++ like:

Code:

void foo(void)
{
    void* ptr1 = malloc(...);
    void* ptr2 = NULL;
    obj_t* ptr3 = obj_create(...);
    char* str = NULL;

    if (stuff) {
        str = strdup(...);
        ...
    } else goto cleanup;

    if (more_stuff) {
        ptr2 = malloc(...);
        ...
    }

    if (something_failed) goto cleanup;

    ...

cleanup:
    if (str) free(str);
    if (ptr2) free(ptr2);
    free(ptr3);
    free(ptr1);
}

(note: in some cases i could use alloca instead of malloc, but this isn't the case always and alloca needs extra care for a crosscompiler/crossplatform setup)

[Bad Sector]

Sure, but writing in assembly would reduce the number of errors that get past the compiler too, wouldn't it?

No, actually it will increase it since the assembler has no semantic information. Data and code is the same for it.

The more specific and detailed you force the programmer to be, the more control they have, but the harder it is to maintain that control.

No actually its the opposite: the more detail you give over the program, the more control you have (and the less control the language/compiler has).

Replacing variable names with memory addresses would also reduce the number of errors.

No this is absolutely false. Why would you think so?

[BorisTheBrave]

I have "looked back" since learning some dynamic typed languages, but all the same, I don't like static types. Yes, it is faster, but it isn't significantly faster any more, a good JIT means that hot functions are essentially statically typed. Pyrex in particular compiles several versions of a function depending on the types passed to it. C++ is fast for other reasons, not just for static typing. It would be more fair to compare Java or AS3 to Python or GML.
And that's not going into arguments about how speed is less and less relevant for the majority of code you write.

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.

So the main value of static typing is an organizational one for large projects, as you can determine correctness of types at compile time. This is indisputable at least, you just have to decide how badly needed it is for a project, and how much other language considerations outweigh it.

Rinku: No, just no. Writing in assembler is very error prone.