Meta Programming

From Sfvlug

SFVLUG Meta Programming Page

This is starting out as mostly an unorganized brain dump. It comes not only from my own knowledge but from the SFVLUG group mind. I've been meaning to organize and publish what has already been discussed. Unfortunately, much of the discussion was not recorded and notes are sparse. I'll clean this up more but for now I thought it better to post something, no matter how lacking, rather than leave it unpublished, so my apologies in advance.

Here are some of my notes, please feel free to edit and/or comment:

Meta Programming Notes

Thoughts on meta-markup of documents...

Have a unified editor that can deal with all sorts of documents with the ability to mark up those documents with comments, proposed revisions, and hypertext links that will link to and bring up any document. Should have capability to commit edits while retaining as complete a history as possible. Look into using svn or git for other than program source documents.

Thoughts on meta programming...

Perhaps a good intermediate step to a good meta programming language would be to better organize and classify existing code snippets to make them easier to locate. Sort of a library that cuts across different languages. The snippets could be in almost any language. They could actually be any blob of code in any language from the smallest fragments to application suites. The only way to accomplish this would be through open source. All blobs would need to either be FLOSS or a method of managing licenses would also be required. Basically all this amounts to is finding methods to speed up the problem solving process by making resources more readily available. It would require the group mind to solve since it would not be a financially profitable venture. However, there could be chunky bits of profitability within the larger FOSS blob.

More on programming, variable use...

I've been having difficulties using descriptive variable names, they just get too large and by size alone serve to obscure code readability thereby being counter productive and taking the edge off their strength.. Solution use descriptive variable abbreviations. Nothing new there, you can see it in a lot of code. But the problem is that all authors abbreviate differently. It works just fine for your own code as long as no one else needs to read it. So instead make standard abbreviations based on commonly used variables or by removing vowels. The standard abbreviations should be based on well known but unenforced naming schemes. Typing might also be included in a naming scheme but omitted if the variable is designed to be typed. In the spirit of explicit vs implicit any information about the nature of the variable would be of use, even if it designates itself as untyped. Another solution would be to write meta tags for all code which would help a programmer to understand someone else's code or remember your own long after you had even forgotten it was you that wrote it.

Editor...

Maybe a real cool editor could help fill the requirements of a meta language through code reuse. Common programming tasks could be accomplished by the language most suitable to a task. Getting to the issue of using the right tool for the right task. Much of that could be make transparent to a meta programmer. Go above the details to higher logical constructions. It shouldn't matter how it is done but what is done! Yes, for some tasks you may need to go down to the level of detail but many of the detail problems have already been solved.What are some of the editors that are likely candidates as meta programming editors? Which already exist that include highlighting, macros, etc.? Which would be good as light weight tools but can be user extensible through preferences and/or plugins? Eric? Kate? Komodo? ???

Custom Distro

Programming tools have become much less expensive and it seems that it could be quite possible to turn a distribution into a unified development platform based on meta programming by having many tools and/or scripting languages available at once. It could become transparent or not depending on the programmer's decisions. Most would remain transparent much of the time. Only when the desired results are not obtained will it be necessary to drill down to the detail level.

This is a living document, please help keep it alive by adding your own thoughts and comments!

--Miasma 03:13, 7 September 2008 (PDT)