General > General Technical Chat

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

<< < (46/99) > >>

bd139:
Compiler and flags please?

Edit: irrelevant. Actually I just grepped about 3 megs of C code and can't find a single assignment to _Bool like that. I'm nto sure why you'd do it. Also works in python:

a = True
a = "hahahaa fuck the rules"

 :-//

Play stupid games, win stupid prizes. No one is stupid enough to play that game in our code. Just yours.

Siwastaja:
Yes, I don't disagree with the fact that your if("string") example is valid C (equivalent code is valid in many other languages, as well; and equally not making any sense), as is your modified code in post #204, which nobody has commented about, I was just looking for the point you are trying to make with your messages, but now that you have admitted you have none, and didn't even intend to, it explains many things, and it is unnecessary to discuss any further.

I would recommend you think before posting, so that you have actually something to say (not just some true/false/true/false claims without any point or reason behind them), in the future, to avoid driving threads into this kind of bullshit argumentation, for the argumentation's sake. This is because while you may be OK by just  :blah: ing for no reason, it's only natural that others expect there to be a reason, even a point, and are trying to find it, and fail. In other words, we are all trying to give you a chance, but you fail to deliver - assuming the deliverable of an internet forum is an "interesting discussion" or "increasing one's understanding"; not just fighting about whether claim X is true or false. What a waste of time, especially when coupled with classical goal shifting and outright lying.

So please just stop doing this, and start being honest with us. Thanks for your consideration.

This was inevitable, though. These kind of threads attract trolls. It stayed civil surprisingly long.

Nominal Animal:
What's in a tool?

I've written a raytracer – or, to be precise, a mixed method raycaster – for rendering ball and ball-and-stick atomic models containing anything from just a few atoms, to hundreds of millions of atoms, for producing quality animation for events in simulated molecular systems.  You know, the kind of size and complexity that gets your Nvidia card apoplexy.  Because of the algorithmic complexity, I had to go back to the underlying math, ten years ago, to get things to work reliably.  As I was using an old desktop machine with just a couple of gigs of RAM at the time, I even had to use memory-mapped files for accessing the data (if you know what MAP_NORESERVE does, you'll probably understand how).  (That entire tale, from combining different rasterization methods to reduce the number of objects tested for each ray, to consideration of information density in visualization and weirdnesses in human perception and exploiting them for conveying information, and to producing publication-quality graphics via low-resolution pixel images underneath raycast-solved vector outlines, is a funky tale in an of itself: I learned a lot there.  Then again, I actually worked it all out, instead of using existing toolkits and padding myself on the back for how good a "programmer" I am.  I didn't do it because I knew how to do it, I did it to learn how to do it.)

I do that kind of low-level code-mongery all the time, and for that, C seems most suitable.  Raytracing has long since passed from the pure mathematics of descriptive geometry to emphasizing the features of human perception (and exploiting its limitations), so reproducing early simple examples by applying extremely powerful existing libraries is a good exercise, but nothing impressive.

Back to topic at hand.  Why C?

The reason you do not want to use C++ for low-level cross-language libraries, is the risk of incompatible dependencies between different versions of the C++ runtime.  In theory, the dynamic linkers should handle it without issies, but reality is imperfect.  The nasty situation occurs when application A written in some other language than C++ needs libraries B and C, both of which depend on C++, but are compiled against different versions of the C++ runtime.

A lot of microcontroller development now uses some subset of C++ (or even G++, the GNU C++ variant provided by GCC).  While standard C has explicitly defined the freestanding environment (used in kernels and microcontrollers, when the standard C library and associated services are not available), the subset of C++ used varies, and is rarely if ever documented explicitly.  They usually do not support exceptions, but other verboten C++ features vary a lot.

Is it still C++ if one is supposed to keep to a strictly undocumented subset of its features?  Not just avoiding the standard library, but core features of the language like exceptions?  At least for C it (the freestanding environment) is well documented; for C++, almost all of it is implementation defined, and varies from implementation to implementation.  Can you still call it C++, if you need to test for support of each feature separately at build time?

To me, it only matters when this kind of discussion raises its head.  Whenever you see someone ridiculing others for using a tool they themselves cannot wield efficiently, there is stupidity afoot.

Consider this:

You are on a walk along a rocky river during one summer, when you come across a guy, obviously not an outdoorsman, with pasty skin not seen enough sunlight, now slightly burning, banging flint with a rock, obviously trying to recreate the way stone-age humans made their flint axes thousands if not tens of thousands of years ago.
You smirk to yourself, and walk past without saying a word.

What you do not know, is that that guy is a double PHD, expert in atomic force microscopy and nanorheometry, and is spending their summer day in getting some real-world practice in knapping flint.  Working at the scale of individual atoms, those materials science devices need sharp-tipped probes, preferably single atoms wide at their tip, that can withstand the vibration and movement close to the materials being investigated; and even today, knapping flint -- robotically, of course, nowadays -- is the best, most repeatable way we have of producing such minuscule tips.

What to you was an idiot banging rocks together, was actually somebody who understands reality fundamentally better than you.

Why didn't you know this?  Because Dunning-Kruger; and because tools are tools, and there are some that bridge a stone age human and a leading materials scientist of 2020s.


While C really isn't that good of a language, we don't have anything better in its niche – low-level libraries with bindings to multiple languages, and so on.  Anything that has a significant runtime or significant standard library won't cut it.  It's just a tool most suitable for its particular kinds of nails.

So, the simple answer is "because there are still problems for which C is the best tool".

For right now, I like doing math crunchy stuff in C (i.e., low-level code), and the user interface in Python.  I like the idea of end-users being able to modify the user interface if needed.

I don't touch Perl due to old battle scars.  Not really Perl's fault, I just had to work with a code base that was full of copy-paste-modify-slightly almost duplicates, critical to my users... You know the type: instead of fixing existing bugs, the functions are copied, the copy fixed, and only (some) future users using the fixed version, some the older version.  (This was two decades ago now, and Perl has evolved a lot since then, so I really should take a look again.  It's just that those scars itch easily.)

For quite a few years, I wrote lots and lots of PHP code.  Usually, the most critical part was to ensure none of the admins with access to the servers enabled "magic quotes" or other PHP misfeatures that gave it its reputation..  You can write quite secure code even in PHP.

Fortran is still common in HPC, especially physics and chemistry simulations.  While newer tools tend to be written in C or C++, if you want to duplicate old published results, you need to use that same code, too.  Sometimes that is very important, if you want to know exactly why your results differ from previously published similar-but-not-exactly-the-same results: you add your new model details to old code, and use the old code to compare the results for both cases.

The thing that annoys me most about some programmers, is that so many of them write code in the first language they learned, in every language they purport to know.
This is nothing new.  There was a saying already decades ago, "one can write FORTRAN code in any programming language", that describes this well.

In my opinion, that's not "knowing" anything, it is just mechanical translation.  It is like claiming you understand something, because you can recite a mathematical formula that in some situations describes its behaviour.

You could even say that some of the above examples of C code fall into this category, because they show code that would cause anybody who is familiar with existing C codebases to raise their eyebrows.  It is like saying that English is a horribly bad language, because in it "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." is a well-formed valid sentence.

Every programming language has some core beauty, some idea, some paradigm, that makes it efficient and useful (according to some metric -- it is easier to just call it beauty) for some tasks.  It is not important or useful to be able to mechanically translate code from one language to others; the important and useful part is understanding that beauty, and integrating it into your toolkit.  And then, being able to choose the appropriate tool from your toolkit to whatever problem you have at hand.

jfiresto:

--- Quote from: Siwastaja on May 10, 2020, 07:17:23 am ---...
Python's typing is handy, just type some letters from the keyboard without thinking, and it guesses the intent, and does fairly good job on it: when you test the code, it likely does what you wanted....

--- End quote ---

I have noticed many keep associating C with strong typing. They keep using those last two words, but I am not sure they mean what they think they mean. Python, especially Python 3 which dropped some risky implicit conversions, is much more strongly typed then C. If Python code tries to call a non-executable object, it will fail with an exception


--- Code: --->>> func_addr = 0x0
>>> func_addr()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

--- End code ---

whereas the C equivalent will happily call the null pointer. The above object has no __call__ method and if you try to call it, Python will let you know that. If you do not handle the TypeError, it will let you know it good and hard.

I think the distinction, if I correctly understand the criticism, is that C and Python are statically and dynamically typed, respectively. With C, you discover the type issues that the language and compiler care about, very early in the product's life cycle – at compile time; with Python, you discover type issues later to possibly quite later – when you or the customer actually run the code.

EDIT: changed second use of "the issues" to "type issues", since Python's issues do not match C's.

nctnico:

--- Quote from: IDEngineer on May 10, 2020, 12:28:39 am ---As noted herein by others, this is another example of "The right tool for the job". To which I would add, "...while also considering the person DOING the job". C is an excellent choice when the author is competent. The less competent the user, the more hand-holding and safety nets and babysitting they need.

--- End quote ---
That is true up to some point. Even the most skilled masters make mistakes. I like to avoid using C if I can. At least C++ allows to circumvent the use of pointers and freeing of dynamically allocated memory can be concentrated in the destructor of a class. But languages like Lua and Python are much more solving-the-problem-at-hand centric and don't suffer from overflows leading to an oil-stain which can't be traced back to the source. In C / C++ I add range checking to each layer of the software. That is just tedious stuff which doesn't add anything to the function of the program.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod