5 ms·
The difference between parsing and everything else there is that every single program longer than 200 lines will need to take a string from somewhere and change
by zeth___ 8y ago
The difference between parsing and everything else there is that every single program longer than 200 lines will need to take a string from somewhere and change it somehow. If you don't know how to parse a context free language you will write a a thing that accepts a recursively enumerable one and someone will make full use of every corner case you can't even imagine.
It's pretty funny that next to no one here will even understand what I'm saying.
- dang 8y agoWould you please stop doing this sort of flamewar on HN? It's off topic and tedious.
- mkl 8y agoProbably because what you're saying isn't true. 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.
- sedachv 8y agoDid 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: https://www.youtube.com/watch?v=3kEfedtQVOY https://www.youtube.com/watch?v=3kEfedtQVOY
- zeth___ 8y agoIt'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.
- mkl 8y agoI 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.
- sedachv 8y agoYou 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.
- mkl 8y agoI 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). You are simply incorrect.