I really enjoy coding in C (it's probably the language I know the best) and I think C++ is an over-engineered and bloated language, however I'd still pick the latter for something like that. Or rather, like most devs, I'd pick a decently small subset of C++. The main reason for that is that in C if you need a data structure that's more involved that a simple contiguous array then you're on your own. A linked list is sort of not too bad to implement (the kernel's list.h is easy to use and reuse for instance) however as soon as you want things like hash tables, trees or anything that benefits from RAII IMO it becomes a pain to manage everything. It's perfectly possible to do all of that in C (or hell, in assembly if you want to) but in my experience it will take a lot of time to implement correctly (and since you don't have generics it's harder to have general purpose structures that you can reuse easily) and it'll have worse ergonomics because of a lack of destructors and other RAII patterns.
In my experience C is great for low level things (dealing with hardware, writing small low level services etc...). You don't have to deal with too many abstraction layers, memory management is generally straight forward (your average driver won't usually deal with anything more complex than a buffer queue or ring). For the type of application the author is talking about he'll probably have to deal with rather abstract data structure holding the state of the game, "a fluid flow of information coming into the app and going out of the app", concurrency issues etc...
Is it possible to do all that in C? Undoubtedly. If I was tasked to implement something like that would I choose C ? Hell now. I'd probably go with a subset of C++ like I mentioned before, Rust if the dependencies I needed were available (or I didn't mind coding them myself) or maybe even Python if I wanted to reduce development time as much as possible to get a PoC implementation live as fast as possible.
Here's a general purpose decision tree for deciding what to use for graphical applications.
mobile? -> Ask someone else, not me.
desktop?
portable?
yes: -> Qt
needs to be fast?
Lots of heavy lifting?
yes: -> Use "simple C++"
no: -> Use Python
no:
linux: -> unless specifically for gnome, Qt.
mac: -> Mac.
windows: -> C# and MS's flavour-of-the-day framework
If you really dislike C# for some reason, Qt.
none of the above: -> probably Qt
embedded? -> Qt.
What-part-of-Qt-to-use
A "productive" application, something people will work with
for lots of hours and just need to get stuff done.
-> probably Qt Widgets
A "special snowflake fancy" application that should look special
and very distinguished
-> probably Qt Quick. This is going to be more work, if
it's a "productive" application as well.
Embedded or quasi-mobile applications mostly used with a touchscreen
or other limited inputs
-> Qt Quick.
Asking out of mostly ignorance, but is Qt still relevant in 2018?
I've noticed that even for standalone graphical applications, it's becoming more and more common to use webapps - either served locally and accessed through a browser, or through something like electron.
If you're building commercial products, then "it'd be great if everything was free because that's more profit for me", but usually it doesn't work out that way. That being said, there is still a much cheaper commercial version of Qt for smaller businesses ("start-up license").
How about - our dirt cheap embedded product can not bear the cost of the (great BTW) QT library so we have to make do with something else, perhaps our own polished turd.
Or - we could easily afford it except that it's neigh impossible for us on the dev level to get an audience with the powers higher up in the company imbued with the ability to bless payments for software. AKA corporate spend. In times of budget freeze, even a request for such frivolous expenditure can usually not be done without the proper ritual sacrifice of someone in middle management. It's really hard to get volunteers.
Known workarounds are to start developing in QT (or whatever) and postpone the ritual sacrifice of middle management personell until the shit hits the fan AKA release date, or to just use something else. (It's possible a smashing success at release may make it easier to forgive and forget and not look too hard into which middle management drone should take the blame the licensing slip up.) Another workaround is to pretend that LGPL = MIT for all intents and purposes but that is frowned upon in certain corporations priding themselves with such things as ethics and licensing guidelines.
People often critique C without acknowledging the simplicity and versatility of C as a platform: C always comes ahead when you need to write portable, simple code without dependencies and without overhead(zero-cost abstractions).
Writing big monolithic projects in C is hard, but making dozens of components, libraries and utilities turns out much easier(Unix way) and they can be optimized/combined at every level as tools instead of monolithic parts of a projects, creating lots of code/program reuse scenarios.
C is also simple in terms of code generated, assembler doesn't expand to 1000 lines from 1 line of C. C keeps performance predictable and easy to reason to about.
Performance is basically never easy to reason about unless we're literally talking about 10 line long for loops. Then, maybe. But that's not a typical case for most applications.
Writing portable C is genuinely hard. I doubt many people can write significant quantities C89 code that actually does the same thing on GCC and MSVC out of the box (or on LE and BE, or on different pointer models, or on different architectures).
Big-endian is nearly dead, even in consumer network gear. POWER still survives in high-end network gear, and there are some big-business things (think COBOL) still in use. Most people really shouldn't care about big-endian.
Weird pointer models are dead. Even in the embedded world it has all gone byte-addressable, single-address-space, without hardware segments. The hardware does exist on x86, but modern systems effectively hide it. The pointer models are ILP32, LP64, and that abomination that Win64 uses.
Within reason, even bitfields are now portable. Both gcc and msvc will assign them starting from the LSB. You might need a pragma to pack the bits, but both compilers support that.
Speaking of that: lots of pragma is portable now! You can pack. You can do "once".
It is actually portable. It isn't 100% standard of course, and almost nothing is. Start with the fact that standard C is unable to have a GUI, unable to make a network connection, and unable to make a plain text editor that can respond immediately to any keystroke other than Enter.
You can't even implement the functions to provide those features. Any program using any of those features is fully undefined by the C standard. Any interesting program is thus undefined by standard C.
I was thinking the same thing. It wouldn't be trivial, but when compared to the work required to support the three major platforms with different UIs, the binding layers are probably a marginal additional cost.
Is the marketing department in Lua so bad that this person didn't even consider it ??
Lua's secret trick is that you are really not writing Lua but C - most of the time when I am writing Lua I am actually thinking in C.
C <> Lua interlop is probably the best designed API out there and other language designers can take some advice - it does't do traditional FFI but something even cooler using something called Lua Stack.
Lua is also tiny ! it can run on embedded devices like hearing aids.
And you also have LuaJIT - which is faster then V8 ! but is not as stable as vanilla Lua.
I write small cross-platform applications in plain C for the same reason the author gave.
I use Nuklear for the GUI; one nice thing is that it's header only, see https://github.com/vurtun/nuklear
With that, I can write small apps that run macOS, iOS, Windows and Android while sharing the same C code.
On macOS, iOS, and Android I use SFML to manage windows and events.
Works like a charm for me and I produce lightweight apps that are fast to deploy and have no dependencies. I compile the subset I need of SFML straight into my projects.
IMHO C# may be a good choice for this project: shared common code in a C# lib and WPF/UWP, Xamarin.iOS and Xamarin.Mac frontends using native UI frameworks and one language to rule them all
I've recently got back into RPGs with my kids. I used to play a lot, mostly WFRP and mostly with the same group. When I read this article it suggests a very different game to type I play, so I'm curious if other RPGers out there look at this and think "that would be really useful" or not. Do you derive enjoyment from crunching over mechanics? I've always been focused on the story, with dice a way to add an element of uncertainty and hence tension.
I do that for my own game engine. Wrote a very thin layer in C (C99 to be exact) that has all the low-level stuff, tight loops and things that require to be data-oriented. I do everything else on top in Lua. I use libclang to automatically create the Lua bindings from the C code using annotation attributes (X is just a macro around `__attribute__(())`), for example when using `X(ADD) xvector2_t xvector2_add(const xvector2_t a, const xvector2_t b)` it will make sure that this function is called when using the `+` symbol between 2d vectors in Lua. When needed (for performance) I can always move things from Lua to C.
Exactly. People seem to have this misunderstanding that you can't use Lua on iOS "because only approved languages make it into the App Store" - not true. I've shipped tons of Lua-based iOS apps ..
I really enjoy coding in C (it's probably the language I know the best) and I think C++ is an over-engineered and bloated language, however I'd still pick the latter for something like that. Or rather, like most devs, I'd pick a decently small subset of C++. The main reason for that is that in C if you need a data structure that's more involved that a simple contiguous array then you're on your own. A linked list is sort of not too bad to implement (the kernel's list.h is easy to use and reuse for instance) however as soon as you want things like hash tables, trees or anything that benefits from RAII IMO it becomes a pain to manage everything. It's perfectly possible to do all of that in C (or hell, in assembly if you want to) but in my experience it will take a lot of time to implement correctly (and since you don't have generics it's harder to have general purpose structures that you can reuse easily) and it'll have worse ergonomics because of a lack of destructors and other RAII patterns.
In my experience C is great for low level things (dealing with hardware, writing small low level services etc...). You don't have to deal with too many abstraction layers, memory management is generally straight forward (your average driver won't usually deal with anything more complex than a buffer queue or ring). For the type of application the author is talking about he'll probably have to deal with rather abstract data structure holding the state of the game, "a fluid flow of information coming into the app and going out of the app", concurrency issues etc...
Is it possible to do all that in C? Undoubtedly. If I was tasked to implement something like that would I choose C ? Hell now. I'd probably go with a subset of C++ like I mentioned before, Rust if the dependencies I needed were available (or I didn't mind coding them myself) or maybe even Python if I wanted to reduce development time as much as possible to get a PoC implementation live as fast as possible.
Here's a general purpose decision tree for deciding what to use for graphical applications.
What-part-of-Qt-to-useAsking out of mostly ignorance, but is Qt still relevant in 2018?
I've noticed that even for standalone graphical applications, it's becoming more and more common to use webapps - either served locally and accessed through a browser, or through something like electron.
Depends on the app. I run some things in the browser but if there is a native app for something, it's always more responsive and faster to use.
Qt is very fast and very cross platform and Qt 5 together with Python is coming in a new form:
https://www.qt.io/qt-for-python
Lots of people loathe this trend, so yes, I'd say, anything but web apps packaged as platform apps are relevant.
Embedded?
Can your end-user relink your app with their own version of QT? Yes - fine, use QT.
No? Is it OK to pay for the commercial version of QT? Yes - fine, use QT.
No - look elsewhere.
If you're building commercial products, then "it'd be great if everything was free because that's more profit for me", but usually it doesn't work out that way. That being said, there is still a much cheaper commercial version of Qt for smaller businesses ("start-up license").
Oh wow, way to over react.
How about - our dirt cheap embedded product can not bear the cost of the (great BTW) QT library so we have to make do with something else, perhaps our own polished turd.
Or - we could easily afford it except that it's neigh impossible for us on the dev level to get an audience with the powers higher up in the company imbued with the ability to bless payments for software. AKA corporate spend. In times of budget freeze, even a request for such frivolous expenditure can usually not be done without the proper ritual sacrifice of someone in middle management. It's really hard to get volunteers.
Known workarounds are to start developing in QT (or whatever) and postpone the ritual sacrifice of middle management personell until the shit hits the fan AKA release date, or to just use something else. (It's possible a smashing success at release may make it easier to forgive and forget and not look too hard into which middle management drone should take the blame the licensing slip up.) Another workaround is to pretend that LGPL = MIT for all intents and purposes but that is frowned upon in certain corporations priding themselves with such things as ethics and licensing guidelines.
People often critique C without acknowledging the simplicity and versatility of C as a platform: C always comes ahead when you need to write portable, simple code without dependencies and without overhead(zero-cost abstractions). Writing big monolithic projects in C is hard, but making dozens of components, libraries and utilities turns out much easier(Unix way) and they can be optimized/combined at every level as tools instead of monolithic parts of a projects, creating lots of code/program reuse scenarios. C is also simple in terms of code generated, assembler doesn't expand to 1000 lines from 1 line of C. C keeps performance predictable and easy to reason to about.
Performance is basically never easy to reason about unless we're literally talking about 10 line long for loops. Then, maybe. But that's not a typical case for most applications.
Writing portable C is genuinely hard. I doubt many people can write significant quantities C89 code that actually does the same thing on GCC and MSVC out of the box (or on LE and BE, or on different pointer models, or on different architectures).
Even MSVC will do C99 these days. C89 is dead.
Big-endian is nearly dead, even in consumer network gear. POWER still survives in high-end network gear, and there are some big-business things (think COBOL) still in use. Most people really shouldn't care about big-endian.
Weird pointer models are dead. Even in the embedded world it has all gone byte-addressable, single-address-space, without hardware segments. The hardware does exist on x86, but modern systems effectively hide it. The pointer models are ILP32, LP64, and that abomination that Win64 uses.
Within reason, even bitfields are now portable. Both gcc and msvc will assign them starting from the LSB. You might need a pragma to pack the bits, but both compilers support that.
Speaking of that: lots of pragma is portable now! You can pack. You can do "once".
I.e. somewhat portable code that might (and sometimes does) break randomly, because it isn't actually portable, standard C.
It is actually portable. It isn't 100% standard of course, and almost nothing is. Start with the fact that standard C is unable to have a GUI, unable to make a network connection, and unable to make a plain text editor that can respond immediately to any keystroke other than Enter.
You can't even implement the functions to provide those features. Any program using any of those features is fully undefined by the C standard. Any interesting program is thus undefined by standard C.
> Rust requires bindings and unsafe code; this ends up being a good amount of work to accomplish.
Not really all that much work. Combined with Rusts library ecosystem and other productivity improvements you very easily come out ahead.
I was thinking the same thing. It wouldn't be trivial, but when compared to the work required to support the three major platforms with different UIs, the binding layers are probably a marginal additional cost.
Why not Lua ??
Is the marketing department in Lua so bad that this person didn't even consider it ??
Lua's secret trick is that you are really not writing Lua but C - most of the time when I am writing Lua I am actually thinking in C.
C <> Lua interlop is probably the best designed API out there and other language designers can take some advice - it does't do traditional FFI but something even cooler using something called Lua Stack.
Lua is also tiny ! it can run on embedded devices like hearing aids.
And you also have LuaJIT - which is faster then V8 ! but is not as stable as vanilla Lua.
Do you mean a separate project called "Lua Stack" or just the Lua stack?
Have you considered Nim? (https://nim-lang.org/)
I write small cross-platform applications in plain C for the same reason the author gave. I use Nuklear for the GUI; one nice thing is that it's header only, see https://github.com/vurtun/nuklear With that, I can write small apps that run macOS, iOS, Windows and Android while sharing the same C code. On macOS, iOS, and Android I use SFML to manage windows and events. Works like a charm for me and I produce lightweight apps that are fast to deploy and have no dependencies. I compile the subset I need of SFML straight into my projects.
IMHO C# may be a good choice for this project: shared common code in a C# lib and WPF/UWP, Xamarin.iOS and Xamarin.Mac frontends using native UI frameworks and one language to rule them all
I've recently got back into RPGs with my kids. I used to play a lot, mostly WFRP and mostly with the same group. When I read this article it suggests a very different game to type I play, so I'm curious if other RPGers out there look at this and think "that would be really useful" or not. Do you derive enjoyment from crunching over mechanics? I've always been focused on the story, with dice a way to add an element of uncertainty and hence tension.
C + Lua = Welcome to C Programming in the 21st Century
Why not Lua? If you think you can do it in C, you can do it with Lua and end up with a system 10x better.
I do that for my own game engine. Wrote a very thin layer in C (C99 to be exact) that has all the low-level stuff, tight loops and things that require to be data-oriented. I do everything else on top in Lua. I use libclang to automatically create the Lua bindings from the C code using annotation attributes (X is just a macro around `__attribute__(())`), for example when using `X(ADD) xvector2_t xvector2_add(const xvector2_t a, const xvector2_t b)` it will make sure that this function is called when using the `+` symbol between 2d vectors in Lua. When needed (for performance) I can always move things from Lua to C.
How do you run Lua on iOS?
Include the Lua interpreter in your executable and the Lua code in your resource bundle?
Exactly. People seem to have this misunderstanding that you can't use Lua on iOS "because only approved languages make it into the App Store" - not true. I've shipped tons of Lua-based iOS apps ..
Even Apple uses Lua on IOS according to the following tweet: https://mobile.twitter.com/_inside/status/102617383252726579...
https://gist.github.com/lgastako/2243243
Why not Java?