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

[Picuino]

I have little tolerance for the command line as well as other user-unfriendly stuff

That's funny, the vast majority of the one-off tools I write are command line based because I'm simply trying to get some task done, and don't want to waste time on a "pretty" GUI. In my humble experience, creation (and the seemingly endless fine-tuning) of a fancy front end takes far more time than writing the code that actually does the work in question. If it's not a commercially shipping product, I don't care what it looks like... I care that it gets the job done, and the faster the better.

This is not meant as an insult to those with different priorities, just another data point to consider.

I can say the same of the tools that I program for few uses.
When I want to complicate things a bit more and add options, I usually add them in a separate file called options.ini with a list of options that are self-explaining or with comments. That is easier to use than the command line when there are many options and it is still easy to implement in languages ​​like Python.

[engrguy42]

Silicon Wizard,
Really, you don't like my humor? 

If you have an unbiased reading of what I actually post (not what you want to read in between the lines) I've been merely mentioning an option to C (the original topic) that nobody else has mentioned, in order to provide reasons WHY C might not be the language of choice for everyone. But over and over I have been the one saying that whatever tool fits the job is fine. How is that bad?

I've actually (as I usually do) been giving examples to show WHY C might not be the go-to language for some in the engineering world. Real world examples. From an engineer. Others rely on vague generalizations and dismissals, and unsupported opinion on stuff I'm increasingly starting to believe they just have no experience with.

As I've said, I don't care about software. I don't "like" one tool or the other. I'm not a fanboy. I don't take this stuff personally. Unlike others who make personal attacks against those who disagree.

Some languages are more frustrating than others, but that doesn't mean I don't use them. Or at least try them. And I try not to dismiss stuff without trying it. And I try not to make blanket, unsupported dismissals, which seem to be common here. As do claims of "you derailed this thread" by those who couldn't actually care less about whether anyone stays on topic, they just need some mud to throw.

[Picuino]

Unfortunately, this thread now is IMHO growing a significant probability of ending up locked due to it completely derailing. Nice job.

To focus the topic, the problem is not how good are other languages ​​to make GUIs or other similar things.
The initial question is how many people still use C and why.

I no longer use C on the PC. I did it before, but now there are better languages ​​for that environment.
But many programmers still make C programs for the PC (operating systems, office automation, programming languages, ...)

In the world of microcontrollers C it is still one of the best tools, not yet surpassed. Although there are those who program in C++, its advantages are not so many as to displace C.

[Karel]

That said, PyQt5 documentation is annoyingly hard to locate;

https://doc.qt.io/qtforpython/

https://doc.qt.io/qtforpython/api.html

https://doc.qt.io/qtforpython/modules.html

[Nominal Animal]

That said, PyQt5 documentation is annoyingly hard to locate;

https://doc.qt.io/qtforpython/
https://doc.qt.io/qtforpython/api.html
https://doc.qt.io/qtforpython/modules.html

Those are for PySide2, not PyQt5, though.  The Debian (and thus Ubuntu, Mint etc.) python3-pyqt5 still use the RiverbankComputing GPL (non-LGPL) Python bindings, not the official ones.  The official ones are relatively recent; I believe the PySide2 packages were added to Debian in July 2018.

(For a long time, there were no "official" Qt bindings for Python at all.  Debian and Debian-derived Linux distros used PyQt4 and PyQt5 bindings maintained by RiverbankComputing, under the GPL license.  PySide2 is the relatively new, official set of Qt5 bindings for Python.)

There is a python3-qtpy compatibility module that automatically switches between PyQt4, PyQt5, and PySide using the PyQt5 "style".

Are the two bindings identical, or close enough?  I do not know.  But I didn't want to assume the two are identical, and get bit at some point.

[Karel]

That said, PyQt5 documentation is annoyingly hard to locate;

https://doc.qt.io/qtforpython/
https://doc.qt.io/qtforpython/api.html
https://doc.qt.io/qtforpython/modules.html

Those are for PySide2, not PyQt5, though.

You are right, my mistake.

[Nominal Animal]

No worries, Karel!

I took a look at the glue interface in the python3-qtpy package (that provides a PyQt5 interface on top of PyQt5, PyQt4, or PySide), and here are the differences it smoothes over between PyQt5 and PySide2 currently:

• In PySide2, using Python objects as userData in QtWidgets.QComboBox can cause Segmentation Faults.  Should get fixed upstream, is also easily worked around in Python code.
• QtCore has four differences between PyQt5 and PySide2: pyqtSignal, pyqtSlot, pyqtProperty, and QT_VERSION_STR in PyQt5.QtCore are Signal, Slot, Property, and __version__ in PySide2.QtCore
• PySide2 doesn't have QtMultimedia
• .ui file loader in PyQt5 is uic.loadUi(), but PySide2 provides a QtUiTools.QUiLoader class instead, with completely different use patterns.  (python-qtpy implements a loadUi() based on the QUiLoader class on PySide2.)

So, nothing alarming.  This means that a Python3 Qt5 application can use either set of bindings, with just a couple of differences that are easy to fix either at application level or library level, and with the exception of uic and QtUiTools, one should be able to use either set of documentation.  It is not difficult to write an application that uses whichever is available at runtime.

[olkipukki]

A week or so ago I tried to get back in to Python (a short journey which I outlined previously in this thread), and decided the benefit wasn't worth the cost.

You cannot get back to Python, you either "with us or not" 

I would say same to C++ than need preaching and worship on daily basis, otherwise a few years gap or decade will leave it as just a line in a person list of known languages.

On another side, C punched in a brain gonna stay there forever. 

[Sal Ammoniac]

I still got ... several weighty tomes from O'Reilly.

Me too.

[nctnico]

I've actually (as I usually do) been giving examples to show WHY C might not be the go-to language for some in the engineering world. Real world examples. From an engineer. Others rely on vague generalizations and dismissals, and unsupported opinion on stuff I'm increasingly starting to believe they just have no experience with.

That is one of the hard parts of getting older. I know nothing of Python so when a younger engineer I work with regulary suggested to write an application in Python I had to take a bit of time in order not to Pavlov into 'I don't know it so it must suck. Use C++'.  But I did tell him to investigate whether an application in Python is easy to deploy for customers (create and installer and so on) first.

[Wolfgang]

Well done. I'm almost sixty, and this year I had to learn Python, too, and I must say for instrument automation,
engineering and scientific tasks its better than C/C++. Being dumb is no problem - not learning something new is.

[Karel]

[jfiresto]

Well done. I'm almost sixty, and this year I had to learn Python, too, and I must say for instrument automation,
engineering and scientific tasks its better than C/C++. Being dumb is no problem - not learning something new is.

A fun and rewarding aspect of Python is unlearning old habits from using C/C++. A couple decades of the latter (seasoned by a few years of TECO  ) took about seven years to unlearn.

[SimonR]

Well done. I'm almost sixty, and this year I had to learn Python, too, and I must say for instrument automation,
engineering and scientific tasks its better than C/C++. Being dumb is no problem - not learning something new is.

A fun and rewarding aspect of Python is unlearning old habits from using C/C++. A couple decades of the latter (seasoned by a few years of TECO  ) took about seven years to unlearn.

Interesting. I have to learn some python in the near future, What habits did you unlearn, what were they replaced with. In other words what traps are there for the unwary C programmer?

[bd139]

One simple thing. Don't try and write C in python.  Good book ... just speed read it though and do the setup and some of the exercises https://files.meetup.com/18552511/Learn%20Python%20The%20Hard%20Way%203rd%20Edition%20V413HAV.pdf

[olkipukki]

Good book ... just speed read it though and do the setup and some of the exercises https://files.meetup.com/18552511/Learn%20Python%20The%20Hard%20Way%203rd%20Edition%20V413HAV.pdf

Python 2?! 

They will read it and after year or two need unlearn print " vs print( 

[bd139]

Fail on my part  . I thought I linked to the python 3 version. But I just linked to the 3rd edition of python 2 ffs.

There is one! I'm not googling it on my phone though 

[paulca]

Monoglots.  Of course their language is the best language there is.... for everything.

[Karel]

[nfmax]

Fail on my part  . I thought I linked to the python 3 version. But I just linked to the 3rd edition of python 2 ffs.

There is one! I'm not googling it on my phone though 

The worst thing about Python is the 2/3 split. When they decided to launch Python 3 they should have named it Beansprout or something else. I've just been investigating how to install Python 3 'properly' on Mac OS. Seemingly I should install some weird version of gcc (or maybe Xcode at a pinch) then install Homebrew to install some package which will allow me to install and compile some utility that lets me dynamically switch between the antique system Python (so old it no longer gets security updates) which will cause all hell to break loose if it isn't there, and the one I should be using.

A good language, but life's too short!

[bd139]

Oh it's a piece of piss to install python 3 on MacOS. Take the mac and chuck it out the window or install windows on it. Seriously. I was a mac user from ~2001 -> 2019 and now I spend the entire day watching our contractors fixing shit on it to do basic stuff that actually just works on windows. It's both hilarious and surprising because back in 2008 it was the other way round. Python packaging on linux is crap too. I spent at least 5 days this year unfucking centos python packages where someone has installed something with pip on the target node.

So windows 10 + python/go + VScode + minikube for me now.

Also surprisingly perhaps MS's cloud offering is the least shit as well (I'm not going to say the best because that doesn't exist)

Edit: proof I'm a turncoat. Python on OSX ...



Actually that machine gave me a nasty arm rash constantly.

[olkipukki]

... I should install some weird version of gcc (or maybe Xcode at a pinch) .... will allow me to install and compile some utility that lets me dynamically switch between the antique system Python (so old it no longer gets security updates)

That's remind me how it done on Windows  to install either specific version of MS C++ tools and Mingw & Co 

[olkipukki]

For somebody who still in love with C, but tempted by Python, there is something for you too - called Cpython 

https://en.wikipedia.org/wiki/Cython

[bd139]

Yuck 

On windows you install Chocolatey and then run "choco install python"

[chriva]

... I should install some weird version of gcc (or maybe Xcode at a pinch) .... will allow me to install and compile some utility that lets me dynamically switch between the antique system Python (so old it no longer gets security updates)

That's remind me how it done on Windows  to install either specific version of MS C++ tools and Mingw & Co 

I really don't get the mingw stuff. It's just another layer of headache. Is it my stuff, is it the wrapper, is it a windows bug?