This holy war has been splitted from NES PRG/CHR ROM separater... to spare innocent men from certain death.
Unless you're programming with Flex and Bison.
I was talking pure C, not C-with-fat-ass-compiler-compiler-preparserrerrerrers.
You misspelled Python.
Python, of course, is the language I would recommend for a beginner to learn - it has a vast library of libraries for nearly every imaginable task. Playing god and parsing horrible HTML has never been easier!
Of course, me being the hideous Norwegian folklore monster that I become whence the dark hours of the night fall upon us, I must defend Perl's honor!
This topic has seen many fierce debates, so to keep it interesting and more relevant to the interests of this forum, let us speak of these programming languages from the point of a hobbyist NES programmer, instead of the more common "sandal-wearing hippie writing a script for checking the state of a coffee pot"-perspective.
Let's cough up some real-life programming challenges that a NESdever might face: (regarding NES development, ofc)
Also, let us assume that using C is out of the options for reasons unbeknowst to us (saving development time, coder being too drunk/messed up to deal with pointers and memory allocation...) since tepples'll eventually suggest the combination of it and Allegro. (btw, I prefer SDL over Allegro in every single case)
So, for all of the above scenarios, Perl wins. Why? Development time. No coder should use his time polishing one-off-tools that are merely an aid in creating something bigger. Even more importantly, a programmer should not waste his time in making the code for these tools readable. Python, with it's forced whitespace and other human-friendly advantages, is painfully slow to write compared to Perl. With the Bare Onion you'll be able to write at blinding speeds!
For all of the aforementioned cases, it is most likely that instead of wanting to import the chained ball of Python, a NESdever on the go wants to quickly create his one-off solution for the specific compression scheme he/she is using...or whatever. A new assembler with support for illegal opcodes, cycle-filling and automatic banking? Why not.
Oh well, I guess I shouldn't throw Perls to pigs.
Perlblem tepples?
tepples wrote:
InvalidComponent wrote:
String manipulation with pure C is not the way to go.
Unless you're programming with Flex and Bison.
I was talking pure C, not C-with-fat-ass-compiler-compiler-preparserrerrerrers.
Quote:
Quote:
...and Perl.
You misspelled Python.
Python, of course, is the language I would recommend for a beginner to learn - it has a vast library of libraries for nearly every imaginable task. Playing god and parsing horrible HTML has never been easier!
Of course, me being the hideous Norwegian folklore monster that I become whence the dark hours of the night fall upon us, I must defend Perl's honor!
This topic has seen many fierce debates, so to keep it interesting and more relevant to the interests of this forum, let us speak of these programming languages from the point of a hobbyist NES programmer, instead of the more common "sandal-wearing hippie writing a script for checking the state of a coffee pot"-perspective.
Let's cough up some real-life programming challenges that a NESdever might face: (regarding NES development, ofc)
- an assembler
a linker
a disassembler
an interactive disassembler
a script converter (ex. RPG dialog, special tags -> interpreter opcodes and ASCII -> custom charset offsets)
a graphics converter
a graphics editor
a compressor
a map editor
a map converter
Also, let us assume that using C is out of the options for reasons unbeknowst to us (saving development time, coder being too drunk/messed up to deal with pointers and memory allocation...) since tepples'll eventually suggest the combination of it and Allegro. (btw, I prefer SDL over Allegro in every single case)
So, for all of the above scenarios, Perl wins. Why? Development time. No coder should use his time polishing one-off-tools that are merely an aid in creating something bigger. Even more importantly, a programmer should not waste his time in making the code for these tools readable. Python, with it's forced whitespace and other human-friendly advantages, is painfully slow to write compared to Perl. With the Bare Onion you'll be able to write at blinding speeds!
For all of the aforementioned cases, it is most likely that instead of wanting to import the chained ball of Python, a NESdever on the go wants to quickly create his one-off solution for the specific compression scheme he/she is using...or whatever. A new assembler with support for illegal opcodes, cycle-filling and automatic banking? Why not.
Oh well, I guess I shouldn't throw Perls to pigs.
Perlblem tepples?