Boreal
Level 6
Reinventing the wheel
|
|
« Reply #60 on: July 18, 2014, 01:56:36 PM » |
|
My absolute favourite programming language (family) would be Scheme. I only wish it had more of Haskell's awesome features like monads and pattern matching. I'm planning to write a game-oriented Scheme interpreter so I can use it for all my projects as both a data definition and scripting language.
I use a subset of C++11 for everything native. I tend to avoid "runtime" components such as the STL containers and algorithms and instead use C++ for its templates, lambdas, and better typing, but program in a very C-inspired style (data-oriented).
|
|
« Last Edit: July 18, 2014, 02:26:13 PM by Boreal »
|
Logged
|
|
|
|
Ky.
|
|
« Reply #61 on: July 18, 2014, 02:09:29 PM » |
|
My absolute favourite programming language (family) would be Scheme.
I very much don't hear that very often..
|
|
|
Logged
|
|
|
|
Boreal
Level 6
Reinventing the wheel
|
|
« Reply #62 on: July 18, 2014, 02:27:14 PM » |
|
My absolute favourite programming language (family) would be Scheme.
I very much don't hear that very often.. Some call me crazy, yes. There's something about S-expressions that tickles me the right way.
|
|
|
Logged
|
|
|
|
eigenbom
|
|
« Reply #63 on: July 18, 2014, 05:24:08 PM » |
|
Boreal - I'm also very attracted to scheme, though I've never used it for anything. It seems so (theoretically) elegant.
|
|
|
Logged
|
|
|
|
RandyGaul
|
|
« Reply #64 on: July 18, 2014, 06:17:10 PM » |
|
I like Lua. It's so small, cohesive. It has it's own identity! C++ has too much useless cruft for me to like it. C just doesn't quite have enough tools... C++ templates are (rarely) very necessary.
Also JS seems pretty sweet lately. The ability to prototype stuff and post it to blogs with JS is just so cool.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #65 on: July 19, 2014, 12:26:24 PM » |
|
My absolute favourite programming language (family) would be Scheme. I only wish it had more of Haskell's awesome features like monads and pattern matching. I'm planning to write a game-oriented Scheme interpreter so I can use it for all my projects as both a data definition and scripting language.
I use a subset of C++11 for everything native. I tend to avoid "runtime" components such as the STL containers and algorithms and instead use C++ for its templates, lambdas, and better typing, but program in a very C-inspired style (data-oriented).
Is there some things about scheme that haskell doesn't have that keep you preferring scheme over haskell (I really dont know much about scheme, I was under the impression it was a functional language like haskell or f#)
|
|
|
Logged
|
|
|
|
Boreal
Level 6
Reinventing the wheel
|
|
« Reply #66 on: July 19, 2014, 12:54:44 PM » |
|
My absolute favourite programming language (family) would be Scheme. I only wish it had more of Haskell's awesome features like monads and pattern matching. I'm planning to write a game-oriented Scheme interpreter so I can use it for all my projects as both a data definition and scripting language.
I use a subset of C++11 for everything native. I tend to avoid "runtime" components such as the STL containers and algorithms and instead use C++ for its templates, lambdas, and better typing, but program in a very C-inspired style (data-oriented).
Is there some things about scheme that haskell doesn't have that keep you preferring scheme over haskell (I really dont know much about scheme, I was under the impression it was a functional language like haskell or f#) I'm not a big fan of Haskell's syntax; I find it's too ingrained in math and it uses a lot of symbols. Plus, Scheme is a lot easier to write an interpreter for and it maps more strongly to actual running code. I just wish it had better support for the features I mentioned.
|
|
|
Logged
|
|
|
|
Slader16
|
|
« Reply #67 on: July 21, 2014, 12:30:51 PM » |
|
I mostly use Unity, so I'm partial to C#.
|
|
|
Logged
|
|
|
|
Tuba
|
|
« Reply #68 on: July 21, 2014, 01:03:26 PM » |
|
I worked so much with ActionScript that's impossible to not like it... but I think my favorites are Javascript and C++. Though I admit that most of the time I use C++ just as C with classes.
|
|
|
Logged
|
|
|
|
SolarLune
|
|
« Reply #69 on: July 22, 2014, 07:52:08 AM » |
|
so-<
(Python)
|
|
|
Logged
|
|
|
|
DoProgramming
Level 0
|
|
« Reply #70 on: July 22, 2014, 11:50:14 AM » |
|
I'm going to have to say Objective-C. I've been coding in it for years now and I'm too comfortable with it.
|
|
|
Logged
|
|
|
|
coppolaemilio
|
|
« Reply #71 on: July 22, 2014, 11:55:26 AM » |
|
I think Python is my favorite. It feels so nice to code with, unfortunately, I was never able to do a proper game with it, since the performance sucks
|
|
|
Logged
|
Sleeping at Evelend
|
|
|
SolarLune
|
|
« Reply #72 on: July 22, 2014, 03:42:47 PM » |
|
Python's speed isn't that bad, I don't think. Anything in particular you found slow, or any particular engine you were using?
|
|
|
Logged
|
|
|
|
Geti
|
|
« Reply #73 on: July 22, 2014, 04:16:16 PM » |
|
Try writing a particle or collision engine in python and compare scalability vs C++ python is fine for scripting tasks and web programming, but not fast enough for writing game systems in. Game code via BGE is another matter, and seems to hold up reasonably well. What I've seen of pygame it seems to attempt to directly wrap a lot of its systems a little too closely, so you still waste a lot of your potential iterating collections in python. BGE gets around this by leaning more on callbacks and simple, separated scripts, with most of the performance critical stuff (particle systems, physics, render loop) done in C++/GLSL.
|
|
|
Logged
|
|
|
|
SolarLune
|
|
« Reply #74 on: July 22, 2014, 04:45:14 PM » |
|
^ Yeah, I have tried writing a particle engine in Python, and yeah, it's not nearly as fast as C++ would push it (I think). But then again, pygame, for example, is more low-level than the BGE, so I thought you could use some optimizations like PyPy or Cython or something like that.
Hum, you might be right about the BGE. The engine's in C++ and Python's just for scripting.
|
|
|
Logged
|
|
|
|
Geti
|
|
« Reply #75 on: July 22, 2014, 05:43:22 PM » |
|
Just as an illustration: #include <iostream>
int main(int argc, const char* argv[]) { int total = 0; for(int i = 0; i < 100000; i++) total += i; std::cout << total << std::endl; return 0; } vs total = 0; for i in range(100000): total += i; print('%d\n' % (total)); The C++ example runs (on average) 27ms wall clock time; python example runs 137ms wall clock time. Measured using powershell's Measure-Command since I'm under windows at the moment (example output for the final 2 runs http://grab.by/yOcO). That's a 5x slowdown on integer crunching with a very tight loop; python gets slower when accessing complex object fields due to duck typing with runtime lookups; C++ does member lookups using known memory offsets. For all the good things python has to offer, speed certainly isn't one of them (you can see more benchmarks here if you're interested). (standard benchmark validity/usefulness argument disclaimer here)
|
|
|
Logged
|
|
|
|
SolarLune
|
|
« Reply #76 on: July 22, 2014, 07:08:04 PM » |
|
^ Oh yeah, I'm aware Python's slower. I was thinking more along the lines of using optimizers and type defining for Python. And I'm pretty sure people have made entire games in Python before, but I'm unsure of if they faced these performance issues and sidestepped them somehow, or simply ignored them.
|
|
|
Logged
|
|
|
|
s_l_m
|
|
« Reply #77 on: July 22, 2014, 08:33:30 PM » |
|
Try writing a particle or collision engine in python and compare scalability vs C++ python is fine for scripting tasks and web programming, but not fast enough for writing game systems in. Game code via BGE is another matter, and seems to hold up reasonably well. What I've seen of pygame it seems to attempt to directly wrap a lot of its systems a little too closely, so you still waste a lot of your potential iterating collections in python. BGE gets around this by leaning more on callbacks and simple, separated scripts, with most of the performance critical stuff (particle systems, physics, render loop) done in C++/GLSL. Similar deal with Panda3d. It gets pretty good performance by being all in c++ with python only for scripting. That is really the type of use that python is made for.
|
|
|
Logged
|
Think happy thoughts.
|
|
|
MorleyDev
|
|
« Reply #78 on: July 23, 2014, 06:26:16 AM » |
|
Python makes for a good glue for scripting. I do remember reading how the company that runs the servers of Call of Duty use a mix of Erlang and Python (well and probably umpteen other things, but those 2 are the core), for example. Though I'd say it's main strength is in physics and mathematical simulations where performance isn't as important as accuracy and easy handling of large numbers. Since numbers don't overflow in Python, it's useful when you need to accurately work with huge numbers like 10**78, aka the approximate number of atoms in the universe. And for when the performance is good enough (and considering how far along moore's law we are, good enough has a pretty wide range). Also it's a decent scripting language for task automation. If you can't do what you want easily with shell scripts, it's a common approach for people to break out the Python. This is why my favourite programming language depends on what I'm doing. Different tools for different tasks
|
|
« Last Edit: July 23, 2014, 08:02:59 AM by MorleyDev »
|
Logged
|
|
|
|
nikki
|
|
« Reply #79 on: July 23, 2014, 07:31:23 AM » |
|
Just as an illustration: #include <iostream>
int main(int argc, const char* argv[]) { int total = 0; for(int i = 0; i < 100000; i++) total += i; std::cout << total << std::endl; return 0; } vs total = 0; for i in range(100000): total += i; print('%d\n' % (total)); The C++ example runs (on average) 27ms wall clock time; python example runs 137ms wall clock time. Measured using powershell's Measure-Command since I'm under windows at the moment (example output for the final 2 runs http://grab.by/yOcO). That's a 5x slowdown on integer crunching with a very tight loop; python gets slower when accessing complex object fields due to duck typing with runtime lookups; C++ does member lookups using known memory offsets. For all the good things python has to offer, speed certainly isn't one of them (you can see more benchmarks here if you're interested). (standard benchmark validity/usefulness argument disclaimer here) i've taken your python function and put some timing in there: import time
def testme(): start = time.time() total = 0; for i in range(100000): total += i; print('%d\n' % (total)); end = time.time() print end - start
when called as python it prints number like 0.00600004196167 when I compile it with cython it prints numbers like 0.00332999229431 so compiled is obviously faster, roughly 100% in this case. just saying compiled (python) code is probably always a factor faster then interpreted (python) code, but thats nothing new offcourse, ps and still (standard benchmark validity/usefulness argument disclaimer here)
|
|
|
Logged
|
|
|
|
|