Code Ina New Form Discussion

See, if code instead was "stored" as a data-structure/database instead of text, then the presentation could be switched to whatever style you wanted for you and only you. You code view could be managed by something similar to InstantLanguageForm, for example. Automated mass editing would also be simpler. Got Virtual Milk? --top

Presentation? You mean, like indent? And mass editing? You mean, like grep?

There's a difference between mass changing and view change. Actual mass changing may have unintended side-effects, for grep doesn't "understand" the language, only follows text rules blindly. If you crash a production system merely to "make the code prettier", your boss may hang you. For example, early in my HTML days, I would reformat HTML to make it easier to read. However, in some cases putting spaces between tags that didn't have spaces before can change the resulting page layout. (It was a poor decision to make HTML space-sensitive at tag borders in my opinion, but it is what it is.)

Yeah, anybody who's done serious HTML editing has run into that latter problem at some time or other. That is a problem of presentation being interwoven with structure. Straight-up SGML or XML won't have that problem because the presentation is set by a separate component.

But the issue of grep having unintended consequences needs to be addressed as a matter of full code understanding. Grep is just a dumb tool; like any dumb tool it needs to be used with the appropriate caution. A chain saw will make the same short work of your finger that it will of a tree branch.

My point was the difference in dealing with "code" as higher-level or abstract structures versus dealing with it as characters and text. For example, a variable named "if" may confuse grep, but an abstract view of code would not have that problem because an IF statement would be a "kind" of object or entity or classification, not "i" + "f" as characters. A variable named "if" would be a variable instance/entity/classification.

Okay, that would be similar to the Basic method of "tokenizing" the source as a set of keywords expressed as single characters. This is a still a matter of expression (from the HMI point of view), not one of representation. Human users need their source code expressed as readable symbology, not as strings of unrecognizable tokens. Just look at Perl or Lisp as examples of function over form, if you will.

It's very difficult to come up with a means by which the keywords of a programming language can be expressed without using commonplace words as representations of those keywords. Can you come up with something better that works in multiple media and doesn't require specialized conversion utilities to view?

That's not what I suggested. Code in an abstract form can be presented how one wants. That's the idea: separate meaning from presentation.

Hmm. Okay, but "code in an abstracted form" is not really useful to the programmer, is it? I mean, compiled code or bytecode or some intermediate thing like P-code or something is also an abstraction of the source, but is it useful?

Is there some useful way to represent the source code to the programmer other than as keywords in text? How would such a representation look? How could it be manipulated? What specialized tools would be needed to view or edit it?

How limited would such a representation's usefulness be if it required a specialized IDE or other environment in which to work? As it is, "normal" source code is viewable, printable, and storable in plain text, so that means anywhere. What kind of new environment would have to be created -- and accepted by enough users to make it viable -- to support some new kind of code representation?

Additionally, what would be the set of advantages? In order for the programming community to justify changing paradigm to a new form of code representation there would have to be some real advantage to using this newfangled "thing." What is it?

This is getting interesting...

AbstractSyntaxTree gives a general diagram-based example. RunTimeEngineSchema shows a relational example of something similar; however, that one is "lossy" from a code-reader's perspective in that "block" control structures are lost because blocks were not needed for the point being made, which was about types-versus-classes there. (Control-flow blocks were assumed translated into goto's). But that can be remedied with more tables. -t

One tricky part to consider is a syntax error. Textual code may not be able to be converted back into an abstract form if a parser cannot turn it into such.

Re: What specialized tools would be needed to view or edit it?

In terms of MaspBrainstorming, I've suggested that the initial choices are a roughly C-like syntax, XML, and a TableBrowser. However, since it's based on a simple data structure, hopefully it would encourage custom and specialized tools and/or viewers. The more complex the language structure, the harder it is to roll-your-own viewer/browser/editor. -t

CategoryCodingIssues