How many people code in C these days, and if so, why?

[Kjelt]

Robert C Martin, Clean Architecture forword, comparing his begin days in the 60s to when he wrote the book in 2016:

"And there is one thing more about the software we have now, compared to the software back then: it's made of the same stuff.
It's made of if statements, assignment statements and while loops.

Oh, you might object and say that we've got much better languages and superior paradigms.
After all, we program in Java, or C#, or Ruby and we use object-oriented design.
True- and yet the code is still just an assemblage of sequence, selection, and iteration, just as it was back in the 60's and 50's.

When you really look closely at the practice of programming computers, you realize that very little has changed in 50 years."

[paulca]

If the file is 10GB in size and you have 1000 of them to parse trough on a daily basis then yeah you might want to go for C so that you don't sit around and wait for it each day.

For that there is PySpark.  Or Java Spark.

[cgroen]

Using C is like driving a car with manual gearbox. It's great fun and about as simple as it can get (only engine, clutch, gearbox, transmission and finally wheels). Sure, you need some practice, you need to think what you're doing but millions of people do it every day safely.

Interpreted languages like Python or LISP are similar to modern cars with automatic gearboxes. They are electronic, full of nice features, automation and safety devices but they are also sluggish (because emission regulations!) and lack any fun of driving. And when they break they cost thousands of zlotys for parts like some stupid sensor.     I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?

For daily driving I have a 1997 VW Passat B3 that I will use as long as it keeps running and passes yearly inspections. Spare parts are cheap too! I also own ex-military FSR Honker with Polish-made Andoria 4C90 engine that I fixed myself (some rust needed to be welded-over). Honker has zero electronics and is very reliable when you know what to check periodically. It's great car to go camping in remote areas because it will drive almost through everything (like old Land Rovers).

Once I had a chance to drive car with automatic gearbox and it was a horror. You have no control over vehicle whatsoever.

Hmm, so people that program in assembler drives a horse wagon ?
I program in C (and have been doing that for 35+ years) but drive a car with automatic transmission, so there goes the idiotic theory....
(and I think I would rather be in a car crash in my 3 year old Volvo XC70 than in your 23 year old Passat )

[chriva]

"Hmm, so people that program in assembler drives a horse wagon ?"

More like a spaceship with a million buttons. This is no limit to the insanity you can do

[Kjelt]

There are still some things you can do in assembly and not in C.

[paulca]

There are still some things you can do in assembly and not in C.

Exotic segmentation faults for instance.

[chriva]

There are still some things you can do in assembly and not in C.

Exotic segmentation faults for instance.

Well.. Is that the language's fault or your own stupidity not comprehending the complexity?

[Berni]

Yep assembler lets you shoot yourself in the foot with even more style than just plain C.

Tho programing entire projects in assembler these days...eeeh. You can do everything in C by plonking down some inline assembler sections or linking in a asembler source file. Sure technically its not pure "C" anymore but on the other hand pretty much all C compiles are designed to handle mixing in user supplied assembler code, heck its pretty common to see C startup scripts on MCUs written in assembler. Maybe such a thing makes sense for old stuff like a Commodore 64 where you might not have a C compiler that is advanced and stable enough for your liking.

[Elasia]

Yep assembler lets you shoot yourself in the foot with even more style than just plain C.

Tho programing entire projects in assembler these days...eeeh. You can do everything in C by plonking down some inline assembler sections or linking in a asembler source file. Sure technically its not pure "C" anymore but on the other hand pretty much all C compiles are designed to handle mixing in user supplied assembler code, heck its pretty common to see C startup scripts on MCUs written in assembler. Maybe such a thing makes sense for old stuff like a Commodore 64 where you might not have a C compiler that is advanced and stable enough for your liking.

In some pics asm calls are still specifically done for certain functions like unlocking program memory for flashing, gotos etc.. i might even do a super critical / super fast function in asm so its permanent vs any optimizer

Otherwise go go embedded C all the way.. i do very little else in my particular niche market

[Nominal Animal]

If you only need to run a few 1MB files trough it once, does it really matter if it takes 100ms longer and 2MB more RAM in exchange for the hours more work to program it?

Python's built-in CSV parser is particularly useful when interfacing to spreadsheet programs in a generic fashion; the DictReader and DictWriter in particular can make short work of many types of problems.

I do have roughly equivalent functionality with C code I've written myself (and that too handles the RFC 4180 oddish double quote rule: foo "bar" baz quoted is "foo ""bar"" baz"), but it takes a lot more code; plus, the Python code is simple enough to give to a new/non-programmer user, and they can do minor alterations to it themselves.  Not so with the C code.

Plus, you can add a PyQt5/PySide2 Qt GUI interface on top of it, and it'll work as-is on all major OSes, with just a couple of dozen lines of code; and code that is simple enough for nonprogrammers to understand.

That is a perfectly valid niche.  I claim so, because I've used it that way myself, successfully.

(A lot of web-based services nowadays can output (authorized) parts of their database in CSV format, by the way.  Using a CSV helper program – one that can be run as-is on different OSes – can munge those in a format that makes it vastly easier for not-very-technical users to do their work on it in a spreadsheet program.  And that is not just papering over "lack of knowledge", either; it can apply policy, like anonymize data, and even do it in a reversible way.  Such things are sometimes required by politics or internal guidelines – if by law, it must be included in the service itself – and being able to implement such quick tooling can make a big difference in practical operations office culture.  Just remember to add Branding, so your work isn't forgotten the moment it is no longer needed.)

Many classical (as in using potential models and not quantum mechanics) molecular dynamics simulations produce snapshots of the simulated system in a text-based format.  When simulating large systems, they can literally spew this data like from a firehose.  It turns out that with RAID storage systems, the bottleneck isn't I/O, but I/O parsing routines in the standard C library.  I've written parser routines for that case too, working thus far at full I/O rates.
Of course, the proper solution to that was to have the simulators output the data in more concise format, preferably using as little CPU time as possible.  One such I wrote for Fortran, that allowed storing the data in binary locally (and thus reducing network traffic, speeding up the simulation itself slightly), with Fortran and C tooling that allows slicing that data (across multiple files) in time and space.  No, I wasn't clever enough to name it Tardis. (Although "Istard" would've been even more my style.) The simulator was written in Fortran, and that particular simulation worked with almost 200 million atoms.  That's roughly 5 GiB of data per "frame" (snapshot of simulation at one moment).  I think the dataset, when compressed, did fit a 2 TiB drive.

Sometimes you get to choose the language you use, sometimes you don't because you are maintaining or developing a mature project.

The cost of time spent to develop a solution is often overlooked, but it really is important, and can go either way.  A funky addition of a couple of hundred lines of Fortran 95 code can make a project possible, or turn it from a month-long research project (per run) to a week-long one; but you might need a semi-crazy programmer to know whether it is even possible, and how.  Letting the programmer choose their favourite language instead of the most appropriate one may turn a one-day project into a multi-month one, because fun is fun, and sometimes the objective is forgotten when you're having too much fun.

[paulca]

The one thing that puzzled me with Python was that it lacks basic JSON support built in.  The is the "json" package and a few hacks you can do with the __dict__ member, but I honestly expected it to have amazing built in JSON marshalling support.

[bd139]

It does have basic JSON stuff built in. I use it all the time. Part of the core libraries: https://github.com/python/cpython/tree/3.8/Lib/json

[Berni]

The one thing that puzzled me with Python was that it lacks basic JSON support built in.  The is the "json" package and a few hacks you can do with the __dict__ member, but I honestly expected it to have amazing built in JSON marshalling support.

That's because Python is designed to keep actual features packaged in libraries while the core language just provides some basic core data types. Not everyone likes json, maybe they want xml instead, or maybe they like pythons own proprietary binary format. But it is part of the standard library so technically its included in the language. And if you need to do something not included in the standard library its typical practice so simply "pip install x" some X library that does that thing.

But yeah if i need performance on a PC i typically just resort to C# since it can run almost as fast as C in most cases but still provide all the handy libraries for easily getting things done, even if its just boring string manipulation. Yes i know oldschool C also provides string manipulation in its standard library, but its really lacking compared to modern languages (Really feels like a chore working with strings there)

[Nominal Animal]

The one thing that puzzled me with Python was that it lacks basic JSON support built in.  The is the "json" package and a few hacks you can do with the __dict__ member, but I honestly expected it to have amazing built in JSON marshalling support.

What do you mean?  The json module is built-in, a part of Python standard library.  (That is, I do not understand what the problem is – unless it is that Python does not use JSON as the native serialization format – and a quick glance at the python-list mailing list didn't immediately show any discussion related to this.  I'd like to know more.)

(Ninja'd by bd139 above!  )

Std 90, also known as RFC 8259, is only 2.5 years old at this point, and the native serialization support in Python uses the pickle module (the marshal module is used for compiled .pyc files).  The pickle format itself, as of this writing, is in its sixth variant already. 

In general, I've never trusted pickling, because I do not like to serialize code: it tweaks my paranoia way too much, being such a risky thing to do unless completely sandboxed.  Using the eval() function (with custom globals and locals, to evaluate user-specified expressions – especially math) is my limit.  In that sense, JSON serialization is better, because it does not support serializing Python code, unless you add such support yourself.

[paulca]

Have you tried to use the json package?  It's completely rubbish.  Generates pages of boiler plate code and is pretty much just a bare bones parsing thing where it's up to you to do the actual marshalling.  Often involving hacks with __dict__ and namedtuples.

Or maybe I used it wrong.  All I wanted was to say.  "Here is some JSON, please give me a Python object with that data populated."

In Java, while much heavier weight, things like JacksonBind or Sparks Encoders will serialise in and out of JSON with nothing but annotations on a value class.

Example of python:

Code: [Select]

        data_str=data.decode("utf-8")
        datums = Datum.jsonToDict(data_str)

Fine, but I have to implement jsonToDict() as:

Code: [Select]

    @staticmethod
    def jsonToDict(data):
        ts = json.loads(data, object_hook=Datum._json_object_hook)
        datums = {}
        for t in ts:
            if "timestamp" in t._fields:
                timestamp = t.timestamp
            else:
                timestamp = "0"

            datum = Datum(t.key, t.name, t.shortName, t.value, t.type, t.units, timestamp )
            datums[t.key] = datum

        return datums

I also have to implement the object_hook

Code: [Select]

   @staticmethod
    def _json_object_hook(d):
        return namedtuple('Dict', d.keys())(*d.values())

So only one line is actually helped by "json".

For an untyped language with dynamic member creation at run time it's a bit shit TBH.  Going a few more steps to ORM would have been nice.

[bd139]

Yeah aware of that. TBH you're probably expecting a bit much out of JSON there. It's pretty loosely typed and so is python so there is no serialization contract. Everything is runtime inferred. You get the same problem using python's pickle stuff as well.

This is one reason I use protobufs / gRPC for communication these days. Explicitly define the contract and generate the serializers etc. That gives strong contracts, strong type inference, portability of wire and disk formats and contract versioning.

tl;dr: JSON is fucking shit. Avoid it like the plague.

[paulca]

Yeah aware of that. TBH you're probably expecting a bit much out of JSON there. It's pretty loosely typed and so is python so there is no serialization contract. Everything is runtime inferred. You get the same problem using python's pickle stuff as well.

This is one reason I use protobufs / gRPC for communication these days. Explicitly define the contract and generate the serializers etc. That gives strong contracts, strong type inference, portability of wire and disk formats and contract versioning.

tl;dr: JSON is fucking shit. Avoid it like the plague.

Horses for courses, but JSON is both machine consumable and human consumable.  It's very loosely typed, or barely typed at all, but XML is far, far, heavier.

When a service goes tits up at 3am and it used JSON (say REST) you can poke it with a stick in a terminal without needing header files and a compiler or a suite of utility clients.  It's also, like XML standardised and fully standalone/introspectable.

I'm old enough to remember people starting to run scared from binary format and old enough to remember why.  So when I see proto-buf and RPC returning, get the popcorn and listen to Cherly bassy - history repeating.

[Nominal Animal]

Have you tried to use the json package?

Only to and from dicts, server-side talking to ajax.  And when I do that stuff, my mind is already bifurcated into two antagonists (one trying to implement the thing, another trying to misuse it), so I tend to not notice developer un/friendliness, unless the language/library actively fights me. 

It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se.
In fact, the two even have the same syntax in the two languages... which might explain why using JSON on Python objects is not comfortable/intuitive: the way those who use a lot of JSON in Python envisioned the json module to be used, would be mainly with dict/orderedDict objects.

This is exactly the paradigm difference I've mentioned in other posts, and others have called "writing X in Y" (with X and Y both programming languages).  It is not necessary for "object" to correspond to "object" in another programming language.  Here, it just happens that the general equivalent of JS objects is not a Python object, but a Python dict, behaviour-vise.

Note that this is a pitfall anyone with any amount of experience can fall into, because we humans are instinctive extrapolators, and are particularly susceptible of missing these unless we are aware of this pitfall.  Me myself, I've had to climb out of these often enough, and instead of asking "what in Y is like Z in X" (with Y a class or function name, and X and Y prohramming languages) I've had to learn to look at behaviour and features instead of assume analogous behaviour based on name or hierarchy!

In theory, that should be annoying (because it means the definition of "object" is now highly dependent on the context, and not like you were taught in school/course/book).  Me myself, I don't mind, because I am aware of my limitations, and finding those different approaches allow me to overcome and exceed my own built-in limitations; to grow.  You know, knowing how and why others see a different thing when looking at the same thing I am, tells me a lot about what my own limitations are, and how to overcome them.  I like that a lot.

[2N3055]

Yeah aware of that. TBH you're probably expecting a bit much out of JSON there. It's pretty loosely typed and so is python so there is no serialization contract. Everything is runtime inferred. You get the same problem using python's pickle stuff as well.

This is one reason I use protobufs / gRPC for communication these days. Explicitly define the contract and generate the serializers etc. That gives strong contracts, strong type inference, portability of wire and disk formats and contract versioning.

tl;dr: JSON is fucking shit. Avoid it like the plague.

proto3 I presume ??

[bd139]

Correct

[paulca]

It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se.

I realised that, at least to some extent and if memory serves me I only created the value objects (Datum in my example) because I googled how to use the json package and it started telling me I needed Encoders and JSON hooks.

My current protocol sends a dict of named dicts. eg. {"foo": {"...":"..."}, "bar": {"...":"..."}}

But when I went to the docs I ended up getting into what I have now.

Even reading this, it's horrible to be honest.  It looks like a hacky undergraduate project to parse JSON. 
https://docs.python.org/3/library/json.html

[Wojciech Krolopp]

Have you tried to use the json package?

Only to and from dicts, server-side talking to ajax.  And when I do that stuff, my mind is already bifurcated into two antagonists (one trying to implement the thing, another trying to misuse it), so I tend to not notice developer un/friendliness, unless the language/library actively fights me. 

It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se.
In fact, the two even have the same syntax in the two languages... which might explain why using JSON on Python objects is not comfortable/intuitive: the way those who use a lot of JSON in Python envisioned the json module to be used, would be mainly with dict/orderedDict objects.

This is exactly the paradigm difference I've mentioned in other posts, and others have called "writing X in Y" (with X and Y both programming languages).  It is not necessary for "object" to correspond to "object" in another programming language.  Here, it just happens that the general equivalent of JS objects is not a Python object, but a Python dict, behaviour-vise.

Note that this is a pitfall anyone with any amount of experience can fall into, because we humans are instinctive extrapolators, and are particularly susceptible of missing these unless we are aware of this pitfall.  Me myself, I've had to climb out of these often enough, and instead of asking "what in Y is like Z in X" (with Y a class or function name, and X and Y prohramming languages) I've had to learn to look at behaviour and features instead of assume analogous behaviour based on name or hierarchy!

In theory, that should be annoying (because it means the definition of "object" is now highly dependent on the context, and not like you were taught in school/course/book).  Me myself, I don't mind, because I am aware of my limitations, and finding those different approaches allow me to overcome and exceed my own built-in limitations; to grow.  You know, knowing how and why others see a different thing when looking at the same thing I am, tells me a lot about what my own limitations are, and how to overcome them.  I like that a lot.

The object oriented definitions are somewhat constrained, I mean we're not picking the same things.  For instance, there's the "inside of the egg" reference, which seems to refer to the whole egg.  However, it also happens to also say, "inside the sheet", which seems like an absolutely generic definition for the purpose of recognizing an object.  No, I am not going to be able to tell you why it's a challenge to watch your choices and interpret them without trying to come up with a rational explanation as to why you made the decision you did. Maybe some people need that.  But here's the thing:   we don't have to be everyone's victim.  It's really not that big of a deal to point out that the definition of "object" is silly and inconsistent. I think it's a good thing to consider, and that your own limitations are a very good thing to know about, especially in part with a deep understanding of the problem domain.

[paulca]

So I went back to look at the json module again.

It seems it works fine deserialising to a Dict.  So I can probably get rid of the hooks, drop my class type or create a class type which takes the dict as it's constructor arg, so it can handle default values for fields.

Code: [Select]

aDict = json.loads('{"garageTemp": {"key": "garageTemp", "name": "Garage Temp", "shortName": "GR", "value": "13.12", "type": "float", "units": "\'C"},"pressure": {"key": "pressure", "name": "Air Pressure", "shortName": "AP", "value": "1012.98", "type": "float", "units": "Hpa"},"humidity": {"key": "humidity", "name": "Humidity", "shortName": "HM", "value": "65.36", "type": "float", "units": ""}, "outdoor": {"key": "outdoorTemp", "name": "Outdoor Temp", "shortName": "OD", "value": "12.94", "type": "float", "units": "\'C"}}')

aDict['garageTemp']
{'key': 'garageTemp', 'name': 'Garage Temp', 'shortName': 'GR', 'value': '13.12', 'type': 'float', 'units': "'C"}


[emece67]

.

[westfw]

I feel like C++ has become

• Somewhat Arduino-like in that people don't write "C++ programs" - they go out and hunt down libraries and examples that are close to what they want, and work from there.  "Oh, you want Boost, and the Boost extension for lambda expressions, and the XYZZY ray-tracing library, and the ZZZ front end for importing data, and ..."
• The language itself is a sort of "Computer Science Language For Computer Scientists who write libraries", which SO much stuff added to it that seems so far off in the ether: "abstracted N-dimensional graphs using lambda expressions; and improvement of Boost" (yeah, I'm picking on lambda expressions...)
• There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code.  "That's not C++, that's Just C With Classes - you're not even using the STL!
• I keep seeing presentation "advantages of C++ in an embedded environment", where they keep listing features that have also been in almost all C compilers as well ("inline"?  TGtbKM!)
• C++ proponents tend to be blind to needs of embedded and speed freaks - "named address spaces" were apparently explicitly rejected, for example.  There's a lot of "C++ doesn't have to bad code for embedded; just avoid certain features", but not a lot of alternatives (STL almost immediately gets you dynamic allocation...)
  

I pretty much like the level of C++ used in Arduino and other "careful" embedded projects.   And I would certainly consider "real C++" for anything like implementing a GUI application on a desktop.  But not everything is an object, and I don't necessarily need all of the new ways to shoot myself in the foot (I have plenty!)