MonthJuly 2010

Environmental Controls

Grant Skinner, the renowned ActionScript developer, has recently been playing with applications that span both desktop computers and Android based smart-phones. An idea struck me that this dual-platform would be perfect for a environmental controlling system. Imagine, having installed a simple Remote Control app onto your phone, every time you walk into a hotspot certain controls can be sent onto your handset to give you control over certain systems around you.

Continue reading

The Robot’s Creole

When I first began programming I was appalled at the simplistic nature of the tools being used to create software; and whilst there have been admiral efforts in the past to make programming a more intuitive affair (think node-based programming) very few of these tools have lived on.

In my opinion, this is symptomatic of a bigger problem in the way we build software; namely, the strong tethering between programming language, compiler & delivery platform.

Imagine a system where, when you typed (in your preferred language), and behind-the-scenes, your IDE was converting all of your code into an XML based representation of the language structures you are typing. These XML representations are what gets saved in your files, NOT your ‘human-readable’ programming language.

This effectively turns the code you view in your IDE into a ‘rendering’ of the core XML structures in the files.

Consider these benefits:

  • Formatting preferences (like the eternal cuddling brackets debate) would be stored in your IDE, allowing everyone to view the code however they want.
  • Programmers are not restricted to platforms or compilers. For example, anyone could happily write a Flash application in C#, because both languages would be saved into the same core XML structure.
  • Pre-compilers and IDE tools would be completely cross-language. Consider having refactoring tools that work across all languages, or code documentation tools that worked across all languages.
  • New ways of rendering code. Consider being able to have a Colour picker next to colour values, or a popout calendar next to date/time values.
  • Alternate views of code (e.g. Visual layouts for forms, Class diagrams of entire program, UML diagrams) would all become first class citizens and would be language agnostic.
  • Breaks down relationship between files and classes. You could have multiple packages/classes in one file, or alternatively you could split classes into multiple files (e.g. a function in each file). This would not change the way you edit the code within the IDE. This could make for easier file handling and version control.
  • Compilers and Pre-compilers would be faster in two ways; Firstly, they’d only have to parse XML instead of processor intensive human-readable languages; Secondly, this parsing need only happen once, then all compilers/pre-compilers could use the in memory standard data structures.

Arbitrary Formatting

When discussing this with people, I have found the biggest concern is to do with arbitrary formatting of code, i.e. occasionally it is beneficial to break ones preferred formatting rules to make code more readable. This could easily be solved by the IDE detecting whenever you’ve broken your own preferred formatting rules (as defined in the IDE preferences) and insert a ‘formatting’ tag into the XML structure, describing the custom formatting. Of course this formatting difference will only be applicable within certain languages, and so these ‘formatting’ tag would also be accompanied by information describing which language (or group of languages) the tag applies to. Alternatively this information could be stored in a separate file, keeping the code free of arbitrary data (and potentially making these formatting choices specific to the programmer who made them).

The Challenges

There are many challenges that such an idea faces, these are the initial ones that spring to mind.

Language Types & Paradigms

Which languages and structures should be able to be represented within this core XML language?

There are vast differences in the structures and paradigms of (for example) Functional Languages and OOP Languages, and much thought must be put into how similar these core items are. For example, the statelessness of Functional programming means that it may not contain non-local variables, this doesn’t mean that it is incompatible with this system, only that if you use local variables in your program you will not be able to use Functional Compilers.

Compiler restrictions on language features

How will your IDE know whether the language features used in your program are available to the compilers you wish to target?

Consider you are writing your application in C# but intend to compile to JavaScript, you use getters and setters in your code (which are not a native feature of JavaScript). There needs to be some way for your IDE to detect that you’re using invalid code for the JavaScript compiler.

One solution would be to create a standardised way for compilers to declare which language features they support. The programmer would target the intended compilers in the project settings, then the IDE could report on invalid uses.

Interaction between Strong and Loose typing

Writing code in a completely loosely typed language (like JavaScript) would not provide enough information for some strongly typed compilers; whilst it would be possible to use a solution like the compiler declaration mentioned above, I believe there is a better solution to this.

Currently, in most OOP languages (Java, C#, AS3, etc) coders use specifically formatted comments to represent information about certain classes/members, which is then used to generate documentation. I believe a similar system could be used to add/display type information in loosely typed languages where adding this information outside of comments would break the language spec. It would be the language parser’s job to analyse these comments and put them into the correct XML data structures (and likewise I believe documentation information should be stored in standard XML structures, not in arbitrary comments).

Using native APIs and existing compiled libraries

All programs use native APIs and existing compiled libraries, whether it’s simply for base mathematics or multi-dimensional matrix operations (think MATLAB). These APIs need to be referenced in a manner that doesn’t tie your code to a specific Compiler/Platform.

One solution could be to develop a set of standard API interfaces. Then existing APIs would be packaged up to contain which of the API interfaces it supports and how those APIs get mapped to the internal classes and members. This would allow native APIs and external libraries to be interchangable, and eventually compilers could easily support features that are native to other platforms without modifying the target platform.

© 2017 Thomas Byrne

Theme by Anders NorenUp ↑