A notation for a sketch-based programming language

This is my design for a language called "SketchCode". The language tries to enable sketch-based programming, both on a traditional paper pad or on a tablet-like device, and strives to maintain simplicity and clarity of the sketches by reusing whatever notations people already use when sketching and by introducing as few new notations as possible.

Instead of making the code itself graphical, the system keeps the code mostly text based while using graphical notation for data structures. Blocks of simple shapes indicate objects, arrows indicate object references, tables indicate records or arrays.

As you see, this simple scheme already allows us to represent many kinds of data. In SketchCode our program should be mostly graphs, state machines, ...etc, I like the idea that a program's data stands out more than its code.  As Fred Brooks said: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious

The graphical nature of the data allows us to program by pattern matching as seen in a lot of functional languages. An important set of new notations would be the language of pattern matching: how to indicate matching a variable? How to match a part of an array or structure?

The first example shows how to calculate the sum the elements in a (sketched) linked list, the second shows how to extract data from a record, and the third shows the notation for 'if' statements.

Tentatively, I chose to underline an identifier in a pattern to indicate being a variable, and the "piece of a table" to indicate partial record matching. It would be interesting to see how to indicate other notations like a part of a graph or a slice of an array.

I have also borrowed some notations from math, and an implemented system could add traditional notations for things like roots, fractions, summation,...etc

A lot can be done with just those basic components: we could have unit tests with sketches of test input, or a "console" where we sketch function application to evaluate it, and more. From there, there is so much that could be added.

Of course, such a system needs to be implemented in order to find out whether this design is really sufficient to express interesting programs, and whether such expressions are actually natural to draw/understand, and how to e.g naturally modify an existing program.

Where is the casual programming?

I did not learn to program to have a software development job. True story.

I learned it for two reasons: (1) To have an aid for thinking and expressing ideas. What Steve Jobs called "A bicycle for the mind". (2) To automate repetitive tasks. Unfortunately, I don't seem to be doing much of either.

Perhaps some people are doing more than me. The Unix/Linux fans - some of them - write adhoc shell scripts or one-liners to solve casual problems. Perl and Python were created for such tasks. I suppose I could be complaining of a non-problem, except it is a problem. Programming is not casual enough.

The first barrier to casual programming is that you've got to learn too much stuff (too much to call it casual). This is the first and only shell script I wrote:

#!/bin/bash
cp -R Program ProgramCopy
cd ProgramCopy
find . -name bin -exec rm -rf '{}' \;
find . -name obj -exec rm -rf '{}' \;
zip -r ../Program`date +%d%B%y`.zip * -x \*~
cd ..
rm -rf ProgramCopy

It takes a program directory, removes temporary compiler generated files, and puts the code in a zip file with today's date. I made it with by trial, error, and Googling. It made me not want to write shell scripts again; feels too much like piecing together jigsaw puzzles where you first have to know which pieces actually exist.

Would I read a book about shell scripting? Nope. It's too much of a hassle for solving only one bit of the casual programming problem. Wouldn't help me much with writing a quick GUI or Web app to solve the problem, or to pull some data from Excel and write them into a .pdf

So how about Python? It has lots of libraries to do all of that and more. The problem is twofold:
1- The user needs to find the required libraries.
2- The user needs to read the documentation of those libraries.
3- The user usually does this with little less than an editor and an open browser tab.

That's the real problem with dynamic typing: With Java, C# and C++ I learn APIs on the go. I use autocomplete and when in doubt I point to the function invocation and press F1 to read the manual entry about this function. If I feel I need more background information, I follow the links higher in the doc hierarchy and begin learning about the big picture the exact moment I realize I need to learn this stuff.

I always wonder how Lisp and Python fans go along. They actually remember the difference between mapcar, mapcan, mapc...maybe I'm stupid or something.

But with the big three static languages, I have another problem: The IDEs take toooo long to load. If I need to write a utility to rename files in a certain way; I don't think "sure, I'll fire Eclipse, create a new Java project in the workspace, create a new run entry, & write and test the code".

Visual Studio? Qt Creator? the same.

What else? I wish everything had an easy to access API. If I can do it as a user, I want my code to do it. You know those cool hacks where people program small robot cars to bring them coffee? They should be trivial to write. I want to write a utility to, say, extract my old blog posts and find all posts written in Arabic, and tag them with "arabic-posts", and I want it running in a time comparable to what it took to describe it.

func isArabic(str)
...
end
blogger.blog("iamsamy", pw="*****").posts.contents.filter(isArabic).tag("arabic-posts")

You know what? Maybe there's a library that actually does this; but I need to find a "gem" or "egg" or "crate" or whatever to do it. And I need to read the docs. And the library may be out of date. And I'd be writing this in a command line window or an editor without autocomplete. And when I have a different casual, trivial, task, I'll need to do so all again.

Oh man. And I'm a professional and experienced programmer. How about the grocer or pharmacist or school student? We need things to be better!

Ok, we can start with a decent language with excellent library support (or we can develop a new one if we feel we have too much time on our hands). Maybe Rebol or Python or Ruby; they seem to be created by people who like to write code for solving casual problems.

If the language is dynamically typed, we could use some sort of technique to enable auto complete, like type inference or such. Otherwise use a fun but statically typed language, maybe C#.

Now we need an IDE that

• Loads fast
• Has very tight integration with a library repository, with a catalog of only the best libraries, easily searchable. I should type "blogger", find at most one or two working options, and press "add". I should be able to see the documentation before pressing add.
• The documentation should have working examples for the top 10 casual tasks usually done with this library. If I'm lucky I'd press "copy this example", "run", and be done.
• The IDE should have little cues in the code, like allowing me to select a directory from a dialog then use it as a file name in the File object's constructor, or choose a URL from my current browser tabs...etc
• There should also be some form of API discoverability. I should search for "convert jpg" and find a class to do the task, even if the name doesn't neccessarily include "convert" or "jpg".
• There should be a trivial to use GUI kit - like say Shoes - and a similar web kit.

I could go on and on....

تجربة: لغة برمجة غير مألوفة سهلة التعلم

كان احد اهدافي من لغة كلمات ان تكون اسهل ما يمكن في التعلم للاطفال لكن في نفس الوقت تشبه اللغات الاخرى الشهيرة، لكي يستطيع الاطفال ان يقفزوا منها إلى عالم البرمجة الاحترافية، ولكي لا يسخر منها احد ويقول انها لعبة (لا يحب الطفل الاكل بالملعقة الصغيرة لو فهمت قصدي).

لكن ماذا لو لم يهمني ذلك؟ لو اردت عمل لغة جديدة للاطفال، بالعربية، ويمكنني ان اضحي بمشابهة اللغات الاخرى مقابل سهولة الاستخدام؟

حسناً..اولا سيكون امر التخصيص في صورة ->، بدلا من علامة =، لتحديد اتجاه ذهاب البيانات. أيضاً سيتم تبديل الاتجاهات

س -> ص معناها "ضع س في ص".

ايضاً لن يكون هناك امر اقرأ ولا اطبع، لكن سيكون هناك كائنات Objects تعبر عن الشاشة، لوحة المفاتيح،...الخ

"مرحبا" -> الشاشة
المفاتيح -> س
الماوس ->(س1، ص1)
الماوس ->(س2، ص2)
ارسم.خط (س1،ص1)-(س2،ص2)

هل لاحظت (س1،ص1)؟ هذا لأن اللغة ستدعم تجميعات من القيم tuples. بالمناسبة هكذا تكون عملية التبديل مثلاً سهلة جداً:
(أ، ب) -> (ب، أ)

"خلي أ تبقى ب، وب تبقى أ"

لو أردت ان تكون اللغة object oriented جداً فيمكنني اصلا ان ارسل قيماً كما اريد للشاشة وما شابه..

خ = خط(100، 100، 200، 200)
د = دائرة(100، 100، 75)
خ -> الشاشة
د -> الشاشة

هذه الطريقة تجعل امور معينة سهلة جداً..ماذا لو اردت برنامج يرسم خطوطا باستمرار؟

كرر:
خط(الماوس، الماوس) -> الشاشة
تابع

حسناً....كفانا لعباً بالمعامل ->، ماذا نفعل أيضا؟؟

تعال نصنع طريقة بسيطة لعمل الدوال:

مجموع(أ، ب) = أ + ب.

وطريقة لتعريف الاجراءات:

حرك(أ، بداية، نهاية) =
ارسم(أ، بداية)
انتظر(30)
ارسم(أ، نهاية).

تبدو اللغة نوعاً ما مثل لغة prolog..أليس كذلك؟

مادمنا قد بدأنا في هذا المشوار، تعال نكمل بأن نضيف طريقة مبسطة لتعريف البيانات.

نوع شخص(اسم، سن، عنوان).

شخص(اسم: "حمدي"، سن: 12، عنوان: "الجيزة") -> ح
اسم ح -> الشاشة

ماذا عن الOOP؟ سوف نعرف كل الmethods كأنها رسائل للانواع المختلفة بكلمة في اللغة اسمها معنى

معنى شخص(أ، ب، ج) -> الشاشة =
("هذا شخص اسمه "، أ، "وسنه "، ب) -> الشاشة.

هذه هي الطريقة التي مكنتني من تعريف كيف ارسم خطاً بأن ارسله للشاشة مثلاً في الامثلة السابقة. لاحظ انني عرفت method بين نوع كامل من البيانات (شخص) وبين كائن object واحد هو الشاشة...يمكن في اللغة المزج بحرية بين classes وobjects..مثلما يمكنني في الحياة الطبيعية ان اقول هذا الكلب يجري حين يرى القطط، فأكون عرفت تصرف كائن معين بفصيلة من الكائنات.

هل هذه اللغة ابسط فعلاً أم هي فقط ازالت بعض الصعوبات ووضعت مكانها صعوبات جديدة؟ ماذا عن سطر مثل خط(الماوس، الماوس) -> الشاشة هل هة مفهوم؟ وهل هذه طريقة جيدة للبرمجة اصلاً؟

يحتاج الامر لتجربة. ما رأيك أن تنفذ انت هذه اللغة وتجرب على اطفال؟

نسيت شيئاً...ماذا اسميها؟ من الصعب عليّ أن أفكر في مشروع بدون اسم جيد له..ماذا عن "سهم"؟ بديهي اكثر مما ينبغي؟ سأبقيها هكذا حتى العثور على اسم افضل. أو سمّه انت لو ستنفذه :)

Concept: The Whisper programming language

I'm thinking up of a new programming language, heavily derived from Smalltalk and called 'Whisper'. This is an outline of my current thoughts -- I don't know when or if I'd actually implement the language.

Syntax

Like Smalltalk, almost everything is a message send. There are two kinds of message send in Whisper: binary operators and keyword messages. Binary operators follow the usual Smalltalk tradition:

12 + 8 * 2 -- returns 40

Keyword messages follow syntax like this:

myWindow : drawCircleAt(100, 100) withRadius(50)

Some notes:

• A colon after the object indicates the start of a message send
• A keyword can have zero, one or more values acting as positional arguments
• Normal C-like positional arguments are a special case of this syntax
• The syntax is heavily inspired by the Grace educational programming language, itself inspired - again- by Smalltalk

We have the traditional ST blocks:

myFunc = { x, y | x + y }

When sending a keyword message, and a block is the only argument between parenthesis, the parens can be omitted like so

(x > 5) ifTrue { out : print("yes") } else { out : print("no") }

IDE & Image

As an experiment, the main IDE for Whisper would be completely browser-based with IDE logic running from a web server. Local applications can be written that access local files...etc but the application's UI would still be browser based.

Another, for me much harder experiment is to make everything persistent all the time on an Sqlite database: All program state changes would be by writing to slots in objects, even function activation records or global variables (an idea taken from Self and others), and all slot writes would be trapped and written in the DB.

This would have a very high performance cost, so a lot of design thought should be put into this; by thinking about how to use memory for cache, possibly marking special object as transient, or some other clever method. I'm sure the Lispers, Smalltalkers, Selfers...etc have probably already "killed this problem from research", as the Arabic saying goes, and that I could find an ideal solution in some paper published in 1989..we'll see!

Gradual typing

Fields, method arguments and return values can have optional type declarations, this would allow the JIT compiler to better optimize things and (more importantly for me) allow autocomplete to work. It would also make refactoring safer, for example renaming a method would change the identifiers in all known calls to that method.

This should not change the dynamic nature of the language: The IDE and program are still 'live' and programs are still assembled piecemeal without an edit/compile cycle. There will be situations when calling a method with wrong argument types throws a runtime exception instead of a compiler error, and that's fine for me.

Other goodies

Since I'm now in the dreaming phase and not serious work phase, let's steal some ideas from Lisp, while we're at it:

The first is multiple dispatch. I think this will be useful in certain types of applications like compilers, allow us to think about libraries in new ways (I can imagine a GUI library inspired by the 'lenses' concept from MIT's Haystack project) and allows niceties like the return of traditional syntax:

if(x > 5) do { out: print("yes") } else { out: print("no") }

We can almost fool users into thinking it's Java or C#!

Also, since the syntax is nicely minimal, we could think about adding some metaprogramming...

Since Smalltalk tries to make as much of the program be represented as objects, we can do the same with the program syntax tree itself; and have the AST of each method be a public property of that method.

This would allow us to write code in our own DSL inside a method, code which looks like gibberish to the interpreter but useful for us, since we can write procedures to read the tree from the method and process it in whatever way we like. Possibly layer Common Lisp-style macros on top of this feature.

---

Looks like a nice language, right? I wish it were already available so that I didn't have to develop it :(

We can do Web applications

Watching a new homegrown language grow up and generate its first dynamic Web page. Seeing the result of months of work. It feels good, الحمد لله.

If you know Lisp, you probably can understand how the code works in the (simplistic) example below. Click on the picture for better viewing.

I hope I'll be able, soon إن شاء الله, to announce more details about the language and a bit about its history.
To the team members who contributed valuable code to this project*, if you're reading this, thank you :)

[*] Haytham Alaa, Mosapha Ateya Sakr, Mostapha M. El-Maasarawy, Mohamed M. Moussa, Mohamed Abdul-Aziz El-Morsy & Kamal El-Din Mohammed.