MadAubrey:
I did try assembler/machine code way back in the Sinclair / Commodore era - twice - the first time and the last time - they were both the same time!!! Not for me, my head is too flat!
I did not mean that you should write programs in assembler - merely that you gain an appreciation of how assembly code works.
...R
I am starting to realize that C does not have a multitude of "standard" functionality and that is probably why it is so powerful.
You can do just about anything if you build the function yourself because all the low level commands are exposed and not hidden away as in some other programming languages.
I'm not sure that this counts as "powerful." But yes, one of the things that will annoy C programmers in "modern" languages is the inability to get at the "bottom layers" in a way that permits them to optimize code for a particular situation.
People with a background in modern languages (PHP, Python, etc) tend to be shocked by the primitive nature of C: "but a dynamically sized array indexed by a string is SO EASY in my language. What do you mean that I have to write it myself?" Usually they overlook that their fancy array is still really COMPLICATED "underneath." C (and assembly language) programmers shudder every time a fancy (but inherently expensive) language feature is used to implement something trival:
# translate characters from strings to their actual numeric value
translateCharToValue = {"0":0, "1":1, "2":2 ... "9":9}
Here's an interesting write-up on how PHP arrays are actually implemented.
Understanding PHP's internal array implementation (PHP's Source Code for PHP Developers - Part 4) (tl:dr: hash tables!)
You can can see how this might be less-than-desirable on a chip with very limited memory resources (compared to the gigabytes you have on a typical desktop.)
In theory, C++ has a "Standard Template Library" that provides a lot of the advanced data structures and algorithms that you're probably used to, but most of them are aimed at desktops and are full of features that are not present, dangerous, or disliked on small systems (exception handling, dynamic allocation, extra memory overhead.)
std::vector is probably most similar to PHP arrays (but isn't necessarily the best choice for the usage you describe. A "nice" thing about the languages that implement a fancy data structure (like hash tables) for their basic features is that someone goes to a lot of effort to implement the fanciness in very efficient ways...)
westfw:
I'm not sure that this counts as "powerful." But yes, one of the things that will annoy C programmers in "modern" languages is the inability to get at the "bottom layers" in a way that permits them to optimize code for a particular situation.
The lower down the "generation level" a language is the more you can do with it and that makes it "powerful".
Yes, it may (will) take longer to code but that is the price you pay to get fast and efficient applications.
And that right there appeals to me!
In a 3rd or 4th level language you get an encapsulation of a whole bunch of lower level commands but it is normally a "best fit" or 80/20 type of situation.
Or an "all things to all men" type of scenario which is normally slow, resource hungry and a waste of memory.
Getting armpit deep into the thing and making it the best you can is mental fun of the first order.
And it will keep your brain agile which at my age is something that I need to do.
It would be very easy and a lot less effort to simply get into the "sit on the veranda and wait to die" frame of mind.
I think that most people are saying to themselves that my project is ridiculous!
A robot arm on a turntable with another turntable for the work piece, swinging a router around - 7 positional motors and all of it controlled by a small little Due being fed G-Code!
If it was not my own project I would think that it was ridiculous too and maybe it is - we will see.
But it is probably going to be a good thing that I am learning C because I doubt if there is a G-Code generator out there that can successfully generate the G-Code for the configuration of my machine so just maybe I'm going to have to write that myself as well.
Plus point is that I can optimize the G-Code output and tool paths generated to suit my machine profile.
Will it ever stop? Sure as heck hope not!!!
westfw:
Here's an interesting write-up on how PHP arrays are actually implemented.
Understanding PHP's internal array implementation (PHP's Source Code for PHP Developers - Part 4) (tl:dr: hash tables!)
You can can see how this might be less-than-desirable on a chip with very limited memory resources (compared to the gigabytes you have on a typical desktop.)
For when the structure is static / fully defined at compile time (and memory is constrained)...
https://www.google.com/search?q=minimal+perfect+hash
MadAubrey:
The lower down the "generation level" a language is the more you can do with it and that makes it "powerful".
Depends on what you mean by "powerful". You could make the opposite argument: scripty languages with their libraries, their lambas, their map-reduce stuff make it possible to code complex stuff with a few lines. I mean - consider SQL. Think about what a query with a couple of joins is actually doing. It would be days of tedium to code that up in C.
In this sense of the word, C is 'powerful' in that it is much easier than writing in assembler.
Since people have been saying "C is powerful" for donkeys, maybe we should compare C to the languages it was being compared against at the time, back in the day. This might give us a sense as to what's so powerful about C. Fortran has computing grunt. COBOL has data structures (oh my Lord, does COBOL have data structures!).
What C allows you to do is to code in a way that is congenial to the way processors do their work. Most particularly, the integration of array and pointer arithmetic. It makes it easier to write code that, when compiled, is smaller and faster than code written in comparable languages. It's that balance: almost as good as assembler for most jobs, but with the features of a block-structured language.
PaulMurrayCbr:
It would be days of tedium to code that up in C.
Nope...
https://www.google.com/search?q=embedded+sql+preprocessor
I think that is just tilting the plate so the gravy runs to one side.
How long would it take to write the preprocessor?
...R
Robin2:
How long would it take to write the preprocessor?
You don't. You use the one provided by the vendor. The Groton Database / Interbase / Firebird one works well and the Sybase / Microsoft SQL Server one used to work well (it has been more than a year since I used it). I know I have used one other (Oracle?) but I cannot remember which one.
Just like you don't typically write your own C++ compiler.
I know that.
But I don't reckon that is what @PaulMurrayCbr was referring to when he said "It would be days of tedium to code that up in C.". I believe he was referring to the business of writing the equivalent of SQL from scratch.
...R
Robin2:
I believe he was referring to the business of writing the equivalent of SQL from scratch.
He was. Which makes it a poor example given the existence of a tool that nicely automates such work.
But that does not negate the rest of his argument. And, had he included that tidbit, he may have strengthened his argument.
Robin2:
But I don't reckon that is what @PaulMurrayCbr was referring to when he said "It would be days of tedium to code that up in C.". I believe he was referring to the business of writing the equivalent of SQL from scratch.
I was thinking about what RDBMSs do at the "I have a tablespace in a UNIX file" level. Especially in the context of wanting to make it general enough to support more than one query, and to support the usual things - inserting rows deleting rows. If you have a couple of static files on disk holding a big array of fixed-size C structs, and files indexing the search fields and the join field … it'd still take a while. Especially thinking about the work that would be invloved in slapping those files into shape.
I suppose "tedious" is a bit subjective. Who knows - a coder might enjoy that sort of thing. But I'd be thinking "there's got to be an easier way to do this - has someone already written a library that does this stuff?"
But the question was: "is SQL more powerful than C"? If by more powerful we mean that it takes much less programming effort to write or modify a query, then yes. If we mean is it faster and more compact, then no.
So - as almost always - the answer is "it depends".