next »

[Sik]

Javascript is like C++, there are a lot of weird gotchas that aren't so obvious, but at least you can keep it under control if you actually care.

[Geti]

Implying you can't in C++ or what? I've seen far more clean C++ than clean JavaScript.

[Krux]

I really like C++, but I hate it's inheretid problmes like include or linking order matters and can cause bugs   Writing build and deployment scripts takes way too much time. And if you have accidently two classes with the same name that only collide at like time one of them is thrown away silently  . And then there is the compiler that likes to fight against you. But I like C++ templates RAII move semantics and memory layout control. It's not just everything a reference.

Then there is Go a very stupid and simple language that let's you manage the memory layout like C, but it is garbage collected and has some sort of static duck typing for polymorphism. But best part of all is its build system. You never have to write any build files or manage project files from ides. Just put your source in the right folder and it works. You can even simply import github/bitbucket projects and it works  

Third language Scala. Scala is just the best language on the JVM. Since it is a JVM language java knowledge is extremly helpful here, even if the syntax differs internally those languages are very close related. The big difference is in the verbosity. Just remove all verbosity of java, replace obscure and long patterns by better language constructs and improve the type system by a magnitude any you get Scala. The only problems left are longer build times and binary incompatibilities of different scala version, so you have to rebuild for every version of scala  .

[Geti]

Re: writing build scripts - use premake or similar, saves a lot of time in the long run and can essentially make it as simple as pointing it at a folder and defining main in there somewhere. Agree with the rest of it, though namespaces avoid link time name collisions 99% of the time (and coupled with a more procedural approach to programming can also help keep compile times low).

I want to like Go and I do like their "interface" system since it's better defined and thus harder to screw up than most duck typing systems I've seen, but I've found it kind of fiddly to use in practice; you end up taking a reasonably OO approach without the ability to do a lot of OO things, and you end up with a fractured, un-namespaced (-> hard to search) interface definition over time.

edit: we looked at Scala a while ago; I liked its design at the time but didn't get to do much programming in it, haven't looked at it much since. Binary compatibility breaking each version sounds like a pain.

[RecidivistSW]

Javascript and Objective C (which probably makes me a weirdo).

[nikki]

I fell in love with D recently

[Krux]

Re: writing build scripts - use premake or similar, saves a lot of time in the long run and can essentially make it as simple as pointing it at a folder and defining main in there somewhere. Agree with the rest of it, though namespaces avoid link time name collisions 99% of the time (and coupled with a more procedural approach to programming can also help keep compile times low).

wow thanks for the hint to premake. I really looks like the build system I am looking for. CMake is way too cryptic and strange for me. But somehow I want QTCreator projects. I am just used to that IDE now.

I want to like Go and I do like their "interface" system since it's better defined and thus harder to screw up than most duck typing systems I've seen, but I've found it kind of fiddly to use in practice; you end up taking a reasonably OO approach without the ability to do a lot of OO things, and you end up with a fractured, un-namespaced (-> hard to search) interface definition over time.

I can't really follow you here. I used scala for a game project and ended up using interfaces almost not at all. I separated my project in several sub packages. Here I found out that Go doesn't allow me to have curcular dependencies within packages. At first I thought it would be a disadvantage, but the requirement to make my modules without circular dependencies really improved the quality of the structure compared to the project I wrote earlier in scala. Also to mention, I liked having multiple return values, and I am missing that right now in C++. Scala has tuples whit should do the same, but knowing that on the jvm a heap object is being allocated for multiple return values makes it less usable in critical points of code and therefore less attractive in general.

edit: we looked at Scala a while ago; I liked its design at the time but didn't get to do much programming in it, haven't looked at it much since. Binary compatibility breaking each version sounds like a pain.

I can tell you the language is great designed, but sadly at least for me is the fact that it is a JVM language. Means slow startup, waste of memory, no arrays of structs (pod). I mean it's an advantage to be compatible with Java, but as a game developer you want to be compatible with C++ or at least C. I mean it is possible with JNI, but try to write that build file. Go is here way ahead. Go let's you include C header files or generate C headers for go functions. you will still write wrappers to the C functions, because you don't want to call naked C functions, but it really is easy to write. Just look at some example wrappers like this https://github.com/veandco/go-sdl2 and see how easy it is.

[Geti]

wow thanks for the hint to premake. I really looks like the build system I am looking for. CMake is way too cryptic and strange for me. But somehow I want QTCreator projects. I am just used to that IDE now.

http://qt-project.org/wiki/PremakeProjectManager might be of interest


Re: lack of circular dependencies - I actually like that approach for most things, circular dependencies tend to indicate too much encapsulation and generalisation to me; erasing them, as you say, tends to lead to better code and a saner overall structure. I find data orientation encourages this a lot of the time when applied in C/++.


Re: Interface fracturing - I found that some libraries I used split functions related to some data; this is fine in theory, but since they are "namespaced" by package it meant I spent a lot of time sifting through either source or documentation to find what I needed; this was facilitated by the ability to extend the interface of a type in an unrelated package, and made reading isolated source once I found the function tricky because it was constantly using other parts of that type's interface that it relied on, which was again defined elsewhere.

Don't get me wrong, that's great for adding functionality without breaking anything else or having to hack on the 1st party code directly, but I really wish there was a way to tie them together under a common, searchable name (searchable by ide ideally for some nice auto-complete prompt) without just cramming it all in one file, like there is with a namespace in C++. Let me know if there is something I'm missing here of course.


Re: Go->C
Yeah I've seen CGo and tinkered with go-sdl (afair sdl2 wasn't out at the time) but it feels like they really could have made it even more convenient; I don't care as much about safety guarantees as they seem to

[JigxorAndy]

I've been using C# a lot the past 6 months because of Unity and I really like it. I think it provides a good level of abstraction that I like to work out, without having to deal directly with memory management and not having to be completely explicit.

I hated Python when I first used it, but now I'd say it's one of my other favourite languages. The way that I can be so fluid with types and everything can be transformed into everything else makes doing data manipulation and parsing tasks very quick.

[ndke]

I recently discovered Dart, and I must say that I really like it!

[quisseh]

Generally speaking, my current love is C#. I was a Java purist until I got hired into the .NET development team at my current company. After writing C# 8 hours a day for over a year, it grows on you. Something like Stockholm syndrome. Now I get a high off stringing along lambda expressions.

For web development, I try to put as much logic on the client as I can (within reason). So in this case I would prefer JavaScript over C# or PHP (I do not like PHP). JavaScript is fun.

For games, I've only been using Python for whatever reason. I enjoy writing Python, but I'm tired of having to eek out every last bit of performance from my code. It just isn't very well suited for games. I plan to move to C# in the near future.

[Dacke]

Oh yeah that too, though I see that more as a library problem than a language problem (doesn't prevent me from being annoyed by them every time I need to use java though, haha). Particularly insidious are a lot of standard lib close() functions that potentially throw and as such require trys within finally blocks.

Dacke is a java fan iirc, haven't seen him around here so much recently though.

The issues with exceptions on close is actually fixed by Java 7's try-with-resource. It automatically closes the file for you when you exit the scope, ignoring the potential exception unless you explicitly catch it.
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Code:

    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }

I wouldn't call myself a Java fan, though. Oracle is horrible and both the language and the standard library have glaring flaws. The problem is that I haven't found anything better to use.

[Layl]

I've got a not-so-secret love for C++, but just generally end up using C# every time. There's just things all over that I'm so used to having in C#/.NET that I don't have in C++. Things like the "lock" and "async" keywords, the LINQ keywords and LINQ itself, the (mostly) painless dependencies and dynamic assembly loading (creating a plugin framework in .NET is amazingly simple). Also, some day I'll find a good use for the "yield" keyword. Some day...

[Photon]

Hmm... if you'd asked me sometime ago I would have said Python; its, as another poster put it, rather fluid to work with and is great for just laying out code and running with it. I made a couple things in Python with Pygame, but as I looked towards more ambitious projects the looming disaster of Python's performance problems became a strong concern. I looked at something called Kivy briefly but didn't take to its way of handling things very much.

Javascript looked appealing for a bit but I didn't like the absence of straightforward inheritance, even if it was only for simple base classes.

Recently the thing for me has been Haxe and OpenFL.

[Geti]

The issues with exceptions on close is actually fixed by Java 7's try-with-resource.

Oh, thank goodness. I still find the language too obnoxiously OO-worshipping for general use but for times when I'm forced to write it that'll at least save me a few lines

I wouldn't call myself a Java fan, though.

Fan was perhaps too strong a word, haha.

[Interface]

I'm pleasantly surprised how many people are saying C#. I like it as a language, a lot. I was shocked to see Unity using it, but I'll take it. I've been thinking about porting my old unfinished 3d engine from c++ to c#, but I dread the OpenGL wrappers I'll need to find. I know I tried once, didn't like any of them.

Has anyone ever tried .NET native? http://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

[InfiniteStateMachine]

I'm pleasantly surprised how many people are saying C#. I like it as a language, a lot. I was shocked to see Unity using it, but I'll take it. I've been thinking about porting my old unfinished 3d engine from c++ to c#, but I dread the OpenGL wrappers I'll need to find. I know I tried once, didn't like any of them.

Has anyone ever tried .NET native? http://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

I'm skeptical about the .netnative performance claims. It still uses a GC. Also my brief experience with NGEN had no noticable performance improvement.

As for your engine. Maybe just do a binding to your C++ code? I was really surprised how well binding works when you make a CLR enable dll.

[Interface]

I'm skeptical about the .netnative performance claims. It still uses a GC. Also my brief experience with NGEN had no noticable performance improvement.

As for your engine. Maybe just do a binding to your C++ code? I was really surprised how well binding works when you make a CLR enable dll.

I built the engine a long long time ago. And let's just say it could use a GC =)

[Interface]

Also, I exposed the engine to LUA for scripting. I was interested in trying out using PowerShell as a scripting language inside a C# based engine - I read some articles about that a while ago, seemed interesting (and more "natural"). And surely better than my manual classes-to-lua code I wrote from scratch.

[InfiniteStateMachine]

powershell huh? I REALLY need to learn that. Especially considering my line of work involves build management.  I guess I can see how that could work as a scripting language. It would certainly be more terse than C#.

A while back I remember someone posting about using C# as a scripting language for their C# engine. They just used the API compile stuff to rebuild the script layer while the game was running.