General > General Technical Chat

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

<< < (88/99) > >>

JPortici:
C++ hands down

olkipukki:

--- Quote from: Wolfgang on May 17, 2020, 04:08:43 pm ---... just an academic question:

If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...

what language would *you* choose ?

--- End quote ---

English 

If you know so much, that's enough  :popcorn:

Nominal Animal:
If you want portability, use Python and Qt5.  Qt5 not only provides an uniform look across all operating systems (not exactly "native", but uniform), but also has uniform interfaces to things like network, and serial and usb ports.  A carefully written Python application can work as-is on most/all OSes.
Unfortunately, Python I/O is not very efficient.  If the application works on a lot of data, Python will be slow(er).  Also, you do not use Python if the source code is a trade secret.  You can license it however you wish, but the end users will be able to read the source code.
Finally, the current official Python interpreter, CPython, only runs Python code in one thread per process.  You can have multiple threads in the same process, and that is very useful for things like asynchronous I/O, but for heavy math, you need to use process parallelism to max out the performance.
 
If you need OS drivers, in Linux you do it in C.  (While technically it is nowadays possible to write an userspace "driver", those are fragile things that to an end user like me, are just turds.  I know many members here advocating doing that instead of trying to write a kernel driver, but in my experience, the userspace stuff just isn't worth the effort.  The only exception is "drivers" that use an userspace-exported bus, like USB, Ethernet, Infiniband, or similar.)

If you deal with lots of data, and want a graphical user interface, then your choices are basically C or C++.  There is only one pure C GUI toolkit, GTK+, that has been ported to all OSes, but it does not provide a "native" use ańd feel on Mac OS or Windows, and outside the POSIX/Unix/Linux world, GTK+ is not well known among programmers.  With C++, you have a lot more options available, including Qt; but also things like FLTK, that allows you to do portable GUIs that do look and feel native on different OSes.  Some OSes, like Windows, have much better C++ support for their OS and kernel-level interfaces.

If I was limited to a single programming language for whatever odd reasons, but still wanted to work on that project, the language I'd choose would depend on the particular requirements of said project, emphasizing the above points.

If I was to work on it alone, right now I'd probably go with C and GTK+, developing on Linux, just because in the last few years I've done a lot of POSIXyC, and not much C++, so it'd be less effort for myself personally.

If I was to work with other programmers, I think C++ (and Qt for the GUI) would be the best choice.

You see, even if limited to a single tool – and this really is similar to asking a builder which tool they would choose, if they had to build a house using just a single tool –, I would still pick the tool based on the problem at hand.

(For the house, it'd be a Finnish wood axe, because I could build (a horribly ugly, but livable) log cabin with that; for anything better, I'd need more tools.)

IDEngineer:

--- Quote from: Wolfgang on May 17, 2020, 04:08:43 pm ---If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform... what language would *you* choose ?
--- End quote ---
C with a small smattering of C++, because I suspect it would yield the largest Venn diagram intersection of: 1) being available on a large number of diverse platforms, 2) known/supportable by a large number of personnel, 3) close-to-the-metal control and performance when you want it, 4) likely to have the library you're looking for when you don't necessarily need control and performance, 5) probably easiest to interface to some other language if needed/wanted.... the list goes on.

This isn't a religious issue for me, I'm just interested in getting the job done with the least hassle. If I had to choose "just one language" that covered everything you said/implied, to me the choice is obvious. YMMV.

SiliconWizard:
Yes, more or less agree with the two above.

The "right tool for the job" is all nice, but if you are hypothetically restricted to only ONE language, while having to cover many different levels from low to high, one essential criterion, after making sure the language you choose *can* be used for all the tasks at hand, is that you have an excellent COMMAND of this language. You can't properly cover that many areas if you don't.

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