Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nadaka]

Python isnt as slow as you think, if you take care to not do a lot of super intensive stuff constantly or nesting tons of loops inside a main loop. Obviously you cant write an engine like CryEngine in Python,  but you can do some pretty nice stuff in Python.

Ok, I see what you mean. Python is fast enough if you don't do anything where you actually care about speed because of computational complexity. Basically you are confirming that python is slow.

You could additionally write your own pyd's in a lower level language like I do. With swig and some .bat files its actually quite a painless process once you get everything working. Just write anything that is going to be slow, or you need to be really fast (like physics calculations) in something like c/c++ and you have the speed of a lower level language, while still using Python.

except that now, instead of learning 1 language, you are talking about at least learning 3.

The point is, Python is extremely flexible and, at the very least, it can get you a prototype of your game, or help you find out if certain features are going to work/are interesting, with very little headache, and a LOT faster than if you are working only with a low level language.

Every language is extremely flexible once you know how to use it. Python provide far, far to much abstraction for a beginner who actually does need to learn a few things about programming.

Edit:
Plus the extremely dynamic nature of Python makes it rock. Not having to declare what type a variable is, and being able to change it on the fly rocks. Dynamic arrays (lists) are also convenient.

No. Actually all of these things are either flaws in python (undeclared data types, changing data types) or features that exist in every language in some way (Dynamic arrays, AKA lists).

[Virex]

There are some thing you can do with dynamically typed variables that don't work nicely with statically typed variables though. For example, a statically typed languages needs to know the expected type of a variable at compile time. While this often makes sense, things get muddy when you work with inheritance.

For example, if you've got a class Rectangle and a class Triangle that inherit from Shape, then there may be cases when you don't know and don't really care if something is a Triangle or a Rectangle at compile time. A statically typed language however forces you to give the variable the Shape type in that case. But then the object will be treated as a Shape, unless you explicitly cast it to a Rectangle or Triangle, so even though both types have a draw function, you can't call the draw function and get the desired result without an explicit cast, because you'll get the Draw function of the Shape class instead. In a dynamically typed language the behavior of Draw will be exactly what you expect it to be.

Note that ML dialects solve this problem by inferring the type of a variable from it's first assignment. This prevents all kinds of errors from (un)intentional misuse of dynamic typing, but it also forbids legitimate use, like, in the previous example, swapping a Rectangle for a Triangle.


Also, on the topic of Python, it's nice that they provide Lists as a core feature of the language, but why did they have to omit arrays/vectors? Access into an array or a vector is O(1) when you know where you have to be, while it's O(n) for a list...

[Xgamer4]

For example, if you've got a class Rectangle and a class Triangle that inherit from Shape, then there may be cases when you don't know and don't really care if something is a Triangle or a Rectangle at compile time. A statically typed language however forces you to give the variable the Shape type in that case. But then the object will be treated as a Shape, unless you explicitly cast it to a Rectangle or Triangle, so even though both types have a draw function, you can't call the draw function and get the desired result without an explicit cast, because you'll get the Draw function of the Shape class instead. In a dynamically typed language the behavior of Draw will be exactly what you expect it to be.

...This is a problem that was solved ages ago. Virtual functions?
http://en.wikipedia.org/wiki/Virtual_function

[Virex]

True, but that still requires you to know what functions should be virtual from the start
(note, I'm not saying that dynamic typing is better per definition. As always, extra freedom and ease of use comes at a price, which in this case is the possibility of elusive bugs and a general performance hit)

[Xgamer4]

...I'd argue that you have bigger problems if you have no idea what functions should be virtual or not when you start actually programming, but fair enough.

But yeah, I agree completely with dynamic vs static as far as an overarching choice. It's just a set of trade-offs. I think the usual listed tradeoffs are power and performance against speed of development and ease of use.

[Nadaka]

Virex:
In the example you provide, shape may be better served as an interface that triangle and square both implement. C++ that allows multiple inheritance uses abstract classes to provide interface support, and java/C# provide an implementation separate from traditional super-class inheritance.

[Virex]

That still doesn't fix all problems related to having to know the type at compile time, it just shifts the place where you define things around (it does solve the example given, but then again, you're just using a roundabout way to implement virtualisation) To actually circumvent these kinds of problems in a statically typed language you need to make creative use of visualization or have some way to cast your object to a type determined at run-time.

It's not that you can't get around the problems, it's just easier in the case of dynamic typing.

...I'd argue that you have bigger problems if you have no idea what functions should be virtual or not when you start actually programming, but fair enough.

That's a valid concern if you're writing the classes at the same time as the function, but if you implement the function after the classes you've got to change the classes as well, making it harder to extend your program or to write generic utilities. You're basically forcing one piece of the code to make assumptions about the other part of the code, meaning the programmer has to make sure each part lives up to these expectations. Dynamic typing lessens these expectations, making your life easier (at the expense of making life harder for the program itself)

[Nadaka]

I will also point out that in java, thanks to class serialization, you DO NOT need to know the class of an object at compile time if you know the class implements a known interface. You can create an instance of the class using a custom class loader, cast it to the interface and call any method (from the interface) that you want on it.

There is another option in C#/java as well, Reflection. But it is almost always the wrong solution.

Dynamic typing only seems to make the programmers life easier, until you have to track down a problem because your code is using the wrong class.

[Virex]

Agreed, Dynamic typing is a package deal and it depends on your development method and the code you're writing how much the trade-off between early error checking and being able to write code that just won't work under static typing actually is. This does make me wonder why no mainstream language has picked up the idea of having static typing with extra dynamic features (such as a dynamic "var" type that could be treated as a true dynamic variable or cast to a static type at run time as needed). Common Lisp does something like that, but has it the other way around, it's normally dynamically typed, but you can invoke type declarations that compilers will use for optimization.

[Nadaka]

c# added a variant type in version??? 3? 3.5? I forget.