I don't understand, are you saying that writing a language parser is a litmus test that that only real programmers can pass?
What makes it so special compared to other tasks of similar difficulty?
What makes it so special compared to other tasks of similar difficulty?
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.
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.