The difference between people who get regular languages, pretty much everyone who codes, and the people who get context free grammars is more than $100k a year.
Gatekeeping: when someone takes it upon themselves to decide who does or does not have access or rights to a community or identity.
What makes it so special compared to other tasks of similar difficulty?
If you can't do it you might use computers but you're not programming.
Tuning DE solvers might take as much skill, or more, than getting context free string parsed, but it's not a skill that is used outside of numerical computing. DBAs aren't called programmers for a reason, but they are no less valuable for it.
The same applies for every niche skill that takes years to develop.
so you just defeated your own argument, instead of hyper-focusing on writing parser why not just say "years of experience" if that is what really matters?
no wonder you got shit on.
Parsing, databases, concurrency, floating point numbers, optimization, common data structures, regular expressions, networking, operating systems, recursion, complexity theory, etc., are all things you should understand to be considered a competent programmer.
It's pretty funny that next to no one here will even understand what I'm saying.
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.
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.
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).
You are simply incorrect.
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.
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.
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.
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):
exec('f = lambda x: ' + input('Enter function: f(x) = '))
This will be my last reply in this thread.
Regular Expressions are used to solve problems, but almost no one makes a career of programs written exclusively in Regular Expressions.
If you can't parse reverse polish notation to infix notation you're going to be writing monstrosities like the mediawiki markup parser.
It doesn't help that 80%+ of developers these days are script kiddies.
Even if it comes a fad getting more people to learn something as basic as that would make the code I have to read so much better.
I didn't magically get a $100k raise after I wrote my first parser, either. Companies care about how you can make money for them, not that you aced "CS405: Compilers and Interpreters" in college. And that latter bit isn't at all correlated with the former... unless you're applying to work at a company that makes compilers.