
Projects: Back to C - mpweiher
http://thoughts.owensd.io/2018/08/17/projects-back-to.html
======
simias
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.

~~~
blattimwind
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.

~~~
samlewis
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.

~~~
some_account
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](https://www.qt.io/qt-for-python)

------
FrozenVoid
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.

~~~
blattimwind
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).

~~~
burfog
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".

~~~
blattimwind
I.e. somewhat portable code that might (and sometimes does) break randomly,
because it isn't actually portable, standard C.

~~~
burfog
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.

------
rapsey
> 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.

~~~
burntsushi
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.

------
wrong_variable
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.

~~~
deorder
Do you mean a separate project called "Lua Stack" or just the Lua stack?

------
azcore
Have you considered Nim? ([https://nim-lang.org/](https://nim-lang.org/))

------
FraKtus
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](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.

------
Kipters
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

------
noelwelsh
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.

------
kensai
C + Lua = Welcome to C Programming in the 21st Century

------
fit2rule
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.

~~~
oweiler
How do you run Lua on iOS?

~~~
mpweiher
Include the Lua interpreter in your executable and the Lua code in your
resource bundle?

~~~
fit2rule
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 ..

------
kuu
Why not Java?

