Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 01:01:26 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)What's your favorite programming language?
Pages: 1 2 3 [4] 5 6 ... 12
Print
Author Topic: What's your favorite programming language?  (Read 21146 times)
Boreal
Level 6
*


Reinventing the wheel


View Profile
« 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

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
Ky.
Level 0
***


Programmer & Web Slinger


View Profile WWW
« 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


View Profile
« 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

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« 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. Smiley
Logged

RandyGaul
Level 1
*

~~~


View Profile WWW
« 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
Level 10
*****



View Profile
« 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


View Profile
« 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

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
Slader16
Level 8
***



View Profile
« Reply #67 on: July 21, 2014, 12:30:51 PM »

I mostly use Unity, so I'm partial to C#.
Logged

Tuba
Level 10
*****



View Profile WWW
« 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
Level 10
*****


It's been eons


View Profile WWW
« Reply #69 on: July 22, 2014, 07:52:08 AM »

so-<

(Python)
Logged

DoProgramming
Level 0
*


View Profile
« 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
Level 0
**



View Profile WWW
« 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  Sad
Logged

Sleeping at Evelend
SolarLune
Level 10
*****


It's been eons


View Profile WWW
« 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
Level 10
*****



View Profile WWW
« Reply #73 on: July 22, 2014, 04:16:16 PM »

Try writing a particle or collision engine in python and compare scalability vs C++ Smiley 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
Level 10
*****


It's been eons


View Profile WWW
« 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
Level 10
*****



View Profile WWW
« Reply #75 on: July 22, 2014, 05:43:22 PM »

Just as an illustration:
Code:
#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
Code:
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
Level 10
*****


It's been eons


View Profile WWW
« 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
Level 8
***


Open to collabs


View Profile
« Reply #77 on: July 22, 2014, 08:33:30 PM »

Try writing a particle or collision engine in python and compare scalability vs C++ Smiley 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
Level 0
***

"It is not enough for it to just work"


View Profile WWW
« 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 Smiley
« Last Edit: July 23, 2014, 08:02:59 AM by MorleyDev » Logged

nikki
Level 10
*****


View Profile
« Reply #79 on: July 23, 2014, 07:31:23 AM »

Just as an illustration:
Code:
#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
Code:
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:
Code:
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
Pages: 1 2 3 [4] 5 6 ... 12
Print
Jump to:  

Theme orange-lt created by panic