General > General Technical Chat
How many people code in C these days, and if so, why?
jfiresto:
Indeed, the four ideas mostly strike me as specific, implementation requirements to make certain, non-dynamic(?) languages object-oriented.
You could very well believe Python is object oriented after reading Alan Kay, who coined the term, or Brad Cox, who brought OO into the mainstream.
Nominal Animal:
One way to classify programming languages is by their abstractions (specifically, by the complexity of their abstractions, or how far those abstractions are from how the hardware works in reality). (I actually prefer to classify programming languages by their paradigm, but bear with me here.)
At the lowest level, you have assembly languages, which are just different symbolic representations of the underlying machine code, with trivial abstractions like labels instead of addresses.
(Anything above that level is up to discussion, however; depending on how you define the complexity of abstractions.)
At the next level, you have low-level programming languages. Nowadays (among actively-used programming languages), this includes C, Forth, and Fortran at least.
If we look at freestanding C, we find that it is an extremely simple and compact programming language, with its abstractions more like compatibility layer between different hardware architectures rather than abstractions that help human programmers. In comparison, Forth is more abstract, as it behaves like a stack-based abstract computer. And Fortran has all sorts of abstractions, including array slicing, that are not "natively" supported by hardware, whose intent is to make "programming" something humans can do without knowing how computers actually work.
In a very real way, freestanding C is the "simplest" portable programming language we have.
In that sense, it is obvious how and why C is still being used. It is nowhere near perfect, as its "abstractions" – more like hardware compatibility features, really – no longer match the hardware, the hardware having vastly progressed forward, but the low-level programming languages staying stagnant, or just adding to instead of refining their abstractions/compatibility layers... which should also explain the reason for my own rant at C standard development in this thread.
olkipukki:
--- Quote from: paulca on May 17, 2020, 12:18:29 pm ---Abstraction - Nope. No protection, no formal interface, no "Interface" concept.
Encapsulation - Nope. No protection, no internal/private/hidden members, everything is public.
Inheritance - Sort of, but without the above it's a bit weak and allows you to do really messed up stuff that you really shouldn't.
Polymorphism - Again, sort of, but not really.
--- End quote ---
Let's keep as is.
If someone wants all-in-inclusive package, there are Ada and Esperanto around >:D
Karel:
--- Quote from: Nominal Animal on May 17, 2020, 02:28:31 pm ---At the next level, you have low-level programming languages. Nowadays (among actively-used programming languages), this includes C, Forth, and Fortran at least.
--- End quote ---
When I did my C programming course, it was considered a high-level programming language... 8)
The terms high-level and low-level are inherently relative. Some decades ago, the C language, and similar languages, were most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level". Today, many programmers might refer to C as low-level, as it lacks a large runtime-system (no garbage collection, etc.), basically supports only scalar operations, and provides direct memory addressing. It, therefore, readily blends with assembly language and the machine level of CPUs and microcontrollers.
https://en.wikipedia.org/wiki/High-level_programming_language
paulca:
Wanted to point out, I like Python. I like C, I like C++. I sort of like Java. I like any language that lets me do a job with the least appropriate amount of effort.
Monoglots are frustrating. An example:
We had a REST API service for registering job batches on a cluster. When I was faced with this, in test, I used a single line of curl to push a new job or update an existing one. The previous monoglotic Java engineers wrote an entire enterprise Java client with really funky non-standard commandline arguments. Why? The curl command takes 30 seconds and can be put into an sh file for later. The java app took a week, runs in about 20 times the time, takes up 100Mb of RAM.
You "can" put a screw in with a hammer and you "can" put a nail in with a screwdriver, but doing so just makes you look unskilled.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version