I have written programs with thousands of lines that do nothing with strings at all, as have a great many other people. Parsing is simply not the universal requirement you claim it to be, and declaring that only real programmers can do it just makes you look arrogant and ignorant.
Did your programs take input? If you had studied parsing theory, you would know that "strings" do not mean ASCII/Unicode text strings, they mean sequences of symbols from a set. All communication protocols, any kind of input, can be described in terms of grammars, and that is important:
I have a computer science degree, and have studied parsing, compilers, etc. I have written many parsers for text and binary formats. I know exactly what I'm saying.
Not all programs need to take external input to be useful, and many or most of those that do can just use an existing library to read it, with no need to write a new parser. Writing parsers is simply not the universal programming requirement you people are trying to claim it to be.
You still don't understand what "input" means. Do your programs literally have all the data that they need to produce their output hard-coded into the source code? If not, they are taking input from somewhere.
I understand exactly what "input" means. Please stop assuming that I'm an idiot and that you're infallible.
Yes, all "data" is right there in the source code for the programs I'm talking about. (I do also write a lot of code that deals with external data, for which I write parsers or use existing ones.)
For example, I did some consulting for a company where I made a mathematical model of their physical product and simulated the static and dynamic behaviour of it in various situations. The model and situations are completely defined by a few parameters in the source code. There's no need for external input and definitely no need for any kind of parsing. Thousands of lines of code.
As a simpler example, the other day I helped a high school student write a program to do basic numerical integration. No external input needed.
I have university students who do an entire course on numerical methods without external input (partly because we're stuck in Matlab where IO and string processing are horrible). The few times they need to process a small amount of data it's just pasted into the code.
For part of my PhD I wrote programs over a thousand lines long to derive mathematical functions. No external input, and nothing that can even be called data.
Generative programs in general, for art, sound, video, etc. often have no external input. I have written many of these.
For another part of my PhD I wrote thousands of lines of code to reconstruct surfaces from point clouds. For real purposes it uses external data, but for testing and development it can simulate its own (so that the true answer is known).
Those are excellent examples. I was debating putting in a disclaimer about hard-coded numerical programs in Fortran or similar, but decided not to go into the detail I will write below, nor give you the benefit of the doubt.
Compound data types, and procedure argument lists, describe the grammar of the data that your programs operate on. That this data is in the source code and the parsing from text to intermediate representation is done by the compiler only offloads the first steps of the parsing. Obviously if you deal with simple data types like vectors and matrices there will not be a lot of grammar there. If you think about typing your program and more intricately structured data into a REPL, this becomes apparent (just because your compiler accepts something as valid input, may not give many guarantees about how your program will behave - this is the crux of type theory).
I am not sure how you can claim generative programming as a counter-example to needing to learn parsing theory. The entire field started out from formal language theory.
Perhaps "generative" was the wrong word. I just mean programs that generate things. For example, I make programs that generate illustrations and animations for teaching maths, programs that generate exam questions that have suitable properties (appropriate difficulty, answers that come out nicely, etc.), and so on (pretty pictures, music, fold patterns...), and few of them need any input data beyond the code itself.
I agree that the programs are doing work to assign meaning to the numbers and data structures etc. in the code and put them to use in context, though I wouldn't have called that part of the parsing myself. I think the grammar of my "input" data structures is usually pretty simple, as you suggest, and that more complicated source structures are likely to be kind of self-organised, e.g. involving dictionaries with meaningful keys or calls to class constructors. Complex data structures can then be built from the simpler source ones if needed.
>As a simpler example, the other day I helped a high school student write a program to do basic numerical integration. No external input needed.
So how are the functions fed into the integrator? The second you want your program to integrate more than the one function you hard coded it with you need a parser to understand what the function is and then translate it into the internal language representation. Something that is very far from trivial.
Sure, but for most purposes, that kind of generality is just not needed. I have hundreds of useful small to large programs that don't need any external input - it's all in the source code.
Besides, even if you want to take in a general function in this case, there's almost certainly no need to write a bespoke parser by hand. In fact, this student was able to handle that requirement just fine (he had this in there first, and we made the program more useful by taking it out):
It's hilarious when people are so wrong they don't even realize they are wrong. We have a whole generation of people who work as coders but don't understand the first thing about computers. And there are so many of them that they even manage to convince themselves they are right.
I have written programs with thousands of lines that do nothing with strings at all, as have a great many other people. Parsing is simply not the universal requirement you claim it to be, and declaring that only real programmers can do it just makes you look arrogant and ignorant.