Kid’s Programming Language(KPL)

KPL is a programming language designed for kids aged 10-14. In brief,

In this paper, we introduce Kid’s Programming Language, or KPL. KPL is an integrated development environment (IDE) and programming language which are similar to but greatly simplified from current mainstream IDEs and languages. KPL is educational  freeware. KPL was initially targeted at the 10-14 age group, but has proven to be engaging and interesting to beginning programmers and hobbyists of all ages. KPL offers a highly leveraged object model which emphasizes graphics programming, including 2D and 3D graphics. KPL intends to address the problem of declining computer science interest and enrollment by 1) making it easy for beginners to get started with computer programming, 2) capturing and holding beginners’ interest by emphasizing graphics and games programming and 3) enabling a smooth “graduation” from KPL into mainstream languages and IDEs.

Simply put, it’s a statically typed OO programming language with some utility functions for 2D /3D graphics, sound and a scaled down version of visual studio/eclipse like IDE. In my opinion, it’s all snake oil. None of the claims in the paper are substantiated with evidence.

Firstly, the motivation to teach programming at schools is not to make them industry grade programmers, but to teach them the concepts of the world around us in a scientific (and mathematical) way. Computer programming and programming languages are a direct application of many mathematics concepts taught in school.

Secondly, KPL has none of the characteristics of a beginner’s language. Let’s compare it with python (I know there are better alternatives, but Python is a close contender)

1) Static typing is bad. I think the only reason they(KPL) needs it in the language is to support auto-completion in the IDE. While type safety is important it confuses newbies hell of a lot. I still wonder why the author added static typing to the language if he was impressed by BASIC.
2) The syntax is too verbose. Python’s syntax is much more concise.
3) Python IDE’s code completion capabilities are as good as Java IDE’s atleast for small programs.
4) Objects are best done using Prototypes or in a sense of objects as python.
5) Structures are more complex as they involve additional type system overhead. Dictionaries are more intuitive.
6) Does KPL give friendlier errors than other languages? Does the error explain the semantics of the language?
7) Aren’t closures more natural to be included in a beginer’s language?
8 ) KPL makes it easy to write 3D space fighting games. I don’t think implementing a 3D game gives more learning than a simple 2D board game? If writing 2D board game is equally enriching, then we can use a ton of other languages. Why KPL?

Thirdly, Squeak has set the bar high enough for any new major innovation in the field. Anything that makes learning programming simple is (majority of the times) selling snake oil.

While the author’s intentions seem noble, this language is an example of how a lousy product gets marketed under a  veil of noble intentions. I wonder how they selected such a lousy paper at the conference like SIGGRAPH.

Is this another MS trick to make users stick to their platform?

Software Visualisation – The next big leap?

Seeing what a program is doing (aka “Software Visualisation” or whatever you name it) may be the next big leap in software development.

This follows logically from the 4 stages of  evolution of programs and programming languages namely – Assembly programming, Sequential programming, Functional Programming and present day OOP. At each stage, we tried to manage the lower level complexity by abstracting away using more intuitive models. But if you look back, the life of a software developer hasn’t changed much since the last 40 years.

The situation hasn’t improved much because abstraction was only a band-aid, it never solved the complexity problem. OTOH, Visualisation is  a permanent cure, because it aims to show what the program is doing at various levels in various (intuitive)views and hence allows us to come out of the black box mode of development we do today.

Now that we have figured out the solution, the challenge now is to do it right.

powered by performancing firefox

Software Visualisation: The other side of the coin

I think software visualisation is the other direction for future research. It is atleast as important as other directions of research because the present day software systems are so huge that no single person can ever understand the whole system.

The pace at which human cognitive skills evolve is neglible compared to the speed with which we build new software systems. Given the lack of high-level paradigms that might make programming more easier, the time is ripe for researching mechanisms that will extend and aid human-cognition to understand the a software system. These mechanisms should do to human-cognition what telescope did to the human-vision.

Given that we are building systems almost the same way for the past 50 years, it would be a deliberate mistake and hurting in the long run to ignore this direction of research.

Note: The post is deliberately authoritarian (which i aspire to be ). I am trying to see if i can write that way.

Frameworks for Data Visualisation

These are the frameworks for data visualisation.

• Prefuse
• Some work on visualising huge data sets.

Frameworks for manipulating visual environments.

• Processing

A few more similar links:

• Information Visualisation tools

Plate

Plate is an interesting project.

Some excerpts from the website:

Plate integrates all the common programming interfaces into a unified visual space. This projects begins with the assumption that a text-based language is an appropriate and powerful method of representing a program.

Unlike a traditional text-editor, in which any series of letters may be generated, Plate breaks up the programming language elements (which are generally few in number) into immutable plate objects. When rearranging these plate objects into meaningful structures, the user is constrained so that only syntactically correct statements may be composed. This effectively eliminates the plentiful syntax errors which are such a bane to both novice and experienced programmers.

In short, each plate is an expression and each immutable plate maps to a statement. Though Unified interfaces and text-based programming are good insights, the claim that syntax errors are a bane does not hold ground given the kind of IDE's and languages we have today. This approach to building programs may not scale when the language is dynamic.

But the best thing i like about this project is the interface which is quite good and the best i have seen to visualise the execution of a text. Unfortunately, this interface doesn't work well when there are lots of variables in scope because the UI assumes that value of variables will be in the viewers head during the evaluation of the expression. The below image is a cheesy gimp work, that will fix this problem by showing the values of variables on top while evaluating the expression.

Sadly, the author did not publish any papers and hence the implementation details remain unknown. Also, the website does not mention if the environment re-executes the procedure everytime a value is changed, I think it does.

I plan to build a similar UI for NPL, when the user wants to see the execution of a single function.

NPL : Some Assumptions

These are some assumptions while designing the NPL language:

• Creating a Connect is cheap.
• Sending a Signal is cheap,quick and is reliable.
• The garbage collection algorithm is effective and efficient.
• An individual connect spends negligible amount of time per input signal compared to the total execution time of the program.
• Performance hit within tolerable limits is acceptable.

Some assumptions regarding NPL UI:

• Everything you know about your program is inside the source code in some form or will manifest itself at runtime.
• The NPL UI has read access to the internals of signals and connects inside the interpreter.
• The user can inspect and modify the signals and connects inside the interpreter via the NPL UI.

Assumption common to all:

• The NPL Language, NPL Interpreter and the NPL UI all will be modified in a coherent manner.
• NPL Language, NPL Interpreter and the UI will be based on COP.

Traits of a Framework for Software Visualisation

Here are the few traits that a framework used by a good visualisation environment would need:

• It should have good support for primitive graphics, 3D models and images.
• It should also have good support for primitive 2D shapes and 2D GUI widgets.
• It should be scriptable.
• Good support for displaying and handling text.
• Primitive shapes (2D and 3D) should be easy to create.
• Ability for Zoom in and Zoom out.
• Basic support for sound.
• Basic networking support.
• Ability to talk to an external environment.
• Should be lightweight.

Probable Candidates:

• A custom visualisation framework built on OpenGL. (A a futile excercise IMO).
• A framework built on Java Swing or something similar.. (This is also a futile exercise and may not be very flexible ).
• A 3D editing program like Blender. (Not sufficient)
• Any self-respecting game engine provides most of these facilities. They usually have bad support for 2D and primitive objects. (Not sufficient)
• An environment like blender with support for text(inside the scene) and 2D widgets.
• A Game engine modified for inbuilt 2D capabilities and text handling with some shortcuts for primitives thrown in to the mix.

“Pay as you Go” model for Visualisation

One of the complaints we hear about visualisation systems is that they are unintuitive. Most of them are unintuitive because, they are built for specialised applications. There are no general purpose visualisation systems.

NPL is also haunted by these concerns. Many do not like the NPL UI(at the moment) because it produces canned visualisations which are not always suitable to the way a person thinks. Hence, people need to have control over the visualisation. But the mechansim provided to customise the visualisation will ultimately decide the fate of a visualisation system. Here I introduce the "pay as you go" model for building visualisations which suits well with the way we develop software.

"Pay as you go" Model:

Instead of spending huge resources(or taking huge losses) upfront for a visualisation system, in this model the resources spent will be directly proportional to the intuitiveness of the visualisation. In this model, the basic features of the visualisation system will be free, where as the higher level views can be customised by a little effort from the user.

The effort can be minimised and returns maximised when

• The lower bound is free and acceptable for day to day chores.
• The resources needed to get better visualisations are little.
• The upper bound is(seems) achievable by(to) a average joe.

This model has the potential to make visualisation mainstream.

The Plan:

Though this model looks simple and straight forward, achieving them is no easy task. Here are some techniques i think will make this model work.

• The lower bound can be achieved by the following tasks:
  • Designing the language to suit visualisation.
  • Using designs which are easy to visualise.
  • Good basic visualisation.
  • Modifying Visualisation based on static and runtime anyalsis of programs.
  • Custom look and feel for standard libraries.
• The incremental changes to visualisation can be provided by:
  • A meta language which is turing complete and is similar to/same as the language we are coding in.
  • Providing default visalisations which the users can use.
  • Providing inspection of language structures in the meta-language.
  • A declarative language, for making chores easy and quick. (Can this be same as the meta language?)
• The upper bound should not be too high, so that it is daunting for a programmer to even attempt for a perfect visualisation. The upper bound can be kept under check by:
  • Providing mechnisms for customising visualisations rather than policies. This aids in keeping the number of visualisation primitives low.
  • Providing tools.

Order of evaluation of expressions effects Visualisation

Initially, i did not see much difference between any other language and a language designed for visualisation (NPL). Almost all of it is the same until i saw an example.

First lets understand how a function call works in NPL.

• Whenever a signal with the name of the function and its arguments is raised, it creates a GenericConnect.
• This GenericConnect looks at the symbol table for the function definition. If it is present, it proceeds furthur, else it gives an error.
• Next, it evaluates the expressions passed as arguments to the function to get the value of their arguments.
• Once the arguments are evaluated, it creates a BlockConnect which represents the function definition and sends in these arguments which are local values in that scope.
• Once the BlockConnect starts execution, it stores these values in the local symbol table and goes on to execute the function.
• Once the execution of the function is complete, it returns the return value to the GenericConnect.

This is the typical implementation of a function call mechanism in NPL. This model of execution is good as long as the function call does not have nested arguments and the function is recursive in nature. So, a (fact 5) seems to provide the right data for visualisation.

But when the function call has arguments which are themselves function calls, the visualisation is unintuitive when it is based on the exact execution shown above. For example, consider the expression, a function call

(func1 (func2 2) (func3 3))

Intuitively, we would think about this as func1 being called with the values of func2 and func3. We assme, that func2 and func3 are evaluated by func1(or after calling func1 but before executing func1 ). When the interpreter evaluates this expression, func2 and func3 are evaluated before the func1 is called. The visualisation also shows the evaluation in the same order. This kills the intuitiveness of the visualisation compared to the textual form. Though this difference seems trivial it makes big impact on the quality of visualisation since i was completely clueless of what was happening when i saw the visualisation of the above expression for the first time.

Solutions:

So there are 2 solutions to the above problem.

1. Make modifictions to the visualisation system such that we show that the evaluation of func1 starts the evaluation of func2 and func3. This is plausible for small changes, but is difficult when the functions are deeply nested. It is also computationally intensive as it involves lot of tree rewriting in the UI.
2. Change the function call mechanism in the interpreter such that the evaluation of the arguments of the function takes place after function is called, but before the function starts execution. This seems easier to implement, but is slightly complex because, the arguments now need to be passed as closures.

I prefer solution 2 because it is more elegant and passing arguments is less computationally intensive. This is the reason, why i feel we need a seperate language designed for visualisation. Another example is the implementation of GenericConnect which is the topic for another day.

Actor Model: Getting Started

Here are a few links on Actor Model. I am very much interested in Actor Model because COP is very much similar to the actor model.

Here are a few links to get you started:

• Actor Model
• Actor Model Implementation
• History of languages using the Actor Model
• Nice Collection of Papers on Actor Model
• A Critique of the Actor Model

I havent seen any papers or links which describe the implementation details. If you know any please post them in the comments.