First let's define the two.
Procedural programming in this
discussion refers to when you mainly use procedures and functions to get the job done. They can be classes too, such as "myobject.dostuff". With an object, you are still using procedures and functions to complete the task at hand.
Syntax programming on the other hand, is when a programmer heavily relies on the syntax of a language in order to complete his task at hand. With Syntax Programming, there still may be procedures and functions that help you get the job done, but the majority of the work you do will rely on syntax more than choosing procedures and functions.
What is an example of Syntax programming? Perl. In many cases, Perl programmers come on to the internet searching and looking for ways to get their syntax "right" to do what they need to do. They don't heavily think about what procedures they need to use, but rather what syntax they can use to trick the interpreter into doing what they need to do.
What is the problem with relying heavily on the syntax of your language to get your job done? The problem is that you spend time learning and relearning syntax. Syntax is not something that is easy to pronounce or easy to remember.
When you spent that time trying to trick the interpreter with some sort of syntax that hashes your data in a compact manner, are you going to be able to remember this trick in 2 months when you need it again? The whole premise of the Perl language, for example, is to figure out what syntax does the job you need to do. And is the syntax consistent? No, all sorts of syntax does different things. There are no standard and consistent methods that you choose to do your job - and you have to relearn the syntax each time you reread a script. Inconsistent syntax is not something you remember consistently.
This is the problem with syntax based coding, or "Syntax Programming". This is the problem with spending the majority of your time focusing on what syntax will get the job done right.
Example:
The perl programmer
spends a few minutes/hours figuring out what syntax in the perl language will parse his data into some string which he can then parse with another syntax trick. Once he has done this, he now has his data available to him and he can now sort his data with another perl syntax trick.
The syntax tricks he used to get his work done, ring a bell in his head. He remembers some of the syntax he used to get the job done.. but since the syntax is slightly different each time for different work, and since the syntax is very complicated, he only remembers exactly what syntax does what for a short period of time.
He cannot so easily remember each and every syntax trick that gets a job done, because each syntax trick does not have a unique name he can remember - like a word in the dictionary. The syntax tricks he used could be named using words and phrases, but usually the programmer is too lazy to name every syntax trick he used and call it something unique.
What are the problems with above?
The syntax programmer gets away sometimes with a faster prototype with dirty syntax,
but does not spend the extra time naming and describing his work within the code - unless he uses source code comments, which ultimately obfuscate the code since he must describe every little trick he is pulling off. There is no organized way to name and describe certain syntax tricks he pulled off on Tuesday.
Syntax tricks are not easy to pronounce like ThatFunction or this_function. Syntax tricks are not something you could write down on paper with a pencil consistently for 2 years, if someone asked you on the fly. There is so much variation, that each time someone asked you for an explanation of how to do some job, a different version of your syntax might be used each time.
If someone asked you in conversation how to approach your problem, you couldn't easily tell them "well underscore paranthesis parses the data and ambersand moves the data over left, and if you use the Parse script I made you'll see that the percent symbol and the dollar sign along with the bracket are what helped me complete this script.". The only thing you have to remember is the unique name of the script: parse, or parse.pl, or myscript.pl. But realistically, no one could or would want to talk about content in the script, or what was used in the script to get the job done. It's impossible to pronounce what you did, and impossible to keep consistent the methods which solved your problems.
Humans are communicative beings. And since communication involves remembering things and discussing things, do you see a problem?
Programmers must discuss the code they use. You cannot just tell your friend to "look at my script and see what I did". In the real world, a programmer must be able to discuss his problem with another human being even on the telephone or by email. If he has to resort to copy and pasting a script snippet for other people to see what he his trying to do each and every time, he gets frustrated. Why can't you just tell people you are using the DoStuff routine? Can you easily describe what you are doing, or does it rely heavily on the syntax and symbols in your script?
Discussing your problem on the telephone or in email with a heavily syntax based language often means you must copy and paste entire code snippets of your syntax, and people will have to spend extra amounts of time deciphering your code. Rather than just telling others that you are looking for a procedure that does the job, you must always paste your syntax into the conversation, because it might wreck everything up if one symbol is wrong.
A heavily syntax based language does not allow you to communicate as well with other programmers in conversation. And people discuss code in conversation every day - on email lists, on websites, and in person. A programmer must not deny that discussing code is important, and that a language which is easy to discuss is important.
|
