Improving Procedural Languages

Tips and suggestions that improve the usability of procedural languages:

     var foo[];
     foo.bar = 'blah';
     foo.bar.snig = 7;
     foo['bar']['snig'] = 7; // equiv to prior, allows punctuation in "keys"
     print(foo.bar);  // result: blah
     print(foo.bar.snig); // result: 7  (some langs don't allow this)
.
    (ret, errCode) = myFunct(blah);


This list is turning into a general language feature wish-list. It was originally intended to make it easier for procedural to compete with the likes of OOP and FunctionalProgramming without becoming them.

[So... You'd also like to turn a bicycle into a car without an engine or four wheels?]

RE: "This list is turning into a general language feature wish-list. blah blah blah" -- Nested functions, multi-line text quoting, multiple returns, named parameters, and flexible data structures - i.e. everything you listed - are also general language feature wishes, buddy, so halt that whining. And all of the features named above certainly would help any procedural language compete with or surpass an OOP/FunctionalProgramming language that lacks them, and none of the features named above make the language 'become' functional or object oriented.

I'm not sure I entirely agree. OOP could use attributes instead of named parameters, for example. One could argue named parameters are not orthogonal enough with an OOP attributes. (Then again, one could also use associative arrays instead of named parameters, but there is also overlap between objects and associative arrays, especially in dynamic languages. The boundary between paradigms is fuzzy. But that's life.) -t

If you really want to get away from object orientation, dump the idea of structures (classes without methods). Stop the TightCoupling? of the members of structures by no longer using structures. Remove structures (and classes) from your language. Find a way of relating the members of structures in some more fluid way than having them part of the same structure. Associative arrays come to mind as in Perl. Ontologies come to mind as in OWL.

-- JonGrover

Functions and pattern matching come to mind, as in HaskellLanguage.

Or step beyond even that, and embrace PrologLanguage.

{Sounds more like MergingMapsAndObjects to me. Anyhow, the goal is not to get away from OOP, but rather leverage procedural more. The need for OOP may drop with access to more powerful procedural features, but there are probably times and places where OOP is still the best tool for the job. Some kind of ControlTable-enabling features may also help so that complex criteria can be used to dispatch functions/events/methods. To borrow from SQL-isms, it could allow something like "RUN functionX(foo.x, bar.y) FROM foo, bar WHERE foo.id=bar.ref AND foo.z < 7 ORDER BY bar.fiz". It approaches the ability of PrologLanguage without the hard-to-predict info-chomping paths, and something relatively similar to common and well-known tools. }

{Yes, I would like to order a fizzy at the bar....*hic* :-}


See also: ItsTimeToDumpCeeSyntax
CategoryProgrammingLanguage, CategorySyntax
AugustZeroEight

EditText of this page (last edited December 9, 2014) or FindPage with title or text search