 |
for Manifesto read
A now typical software creation environment is hundreds of megabytes large and handle files and ressources that tends not to be human manageable anymore. These modern software creation tools have made increasingly easier to build large scale applications, but in the same time, by enforcing what is percieved as "good coding practices" has made experimentation increasingly difficult to do. Lew, by contrast, is an experimentation language. It goes in the opposite direction than the actual trend by keeping things simple, small and easy. It allows you to test an idea in little time, then to test another and yet another... Lew is targetted mainly to graphical creation and interractivity, a domain also covered by projects suchs as NodeBox and Processing. Still, compared to NodeBox, Lew is easily transferable to various operating systems, and compared to Both NodeBox and Processing is an extremely light software environment: less than 500k large and not requiring any software creation environement. Lew, beeing a single executable file, doesn't requires any installation and can be used in restrictive environments (machines were you don't have administrative privileges, for instance), which is a feature that again encourage experimentations of all kind. Genesis... Lew take its roots into Lua (a portable efficient scripting language becoming a de-facto standard in gaming industry), in Emmmp (a personal project of bitmap manipulation and creation routines) and add some Windowing. Hence the name: Lua-Emmmp-Window, L-E-W, Lew. This makes Lew an excessively compact language yet powerfull enough to include modern comodities (alpha transparency layer, object orientation, pattern matching, associative arrays,... and hopefully in a near future Z-buffering, pixel tagging and network support). The two major components of Lew, Lua and Emmmp are written in pure ANSI C and are highly portable code. The Windowing component is, of course, system dependant, but reduced to a minimal (and hopefully easily rewritable) core. Lew can as well be compiled without its windowing component, being then an absolutely portable bitmap manipulation language, of course lacking the interactivity features. The paradox... The professionalization of software elaboration produced a paradox: some coding that was considered easy (and even fun) to do in the '80s has now become increasingly difficult and cumbersome to create. As an example, a task that would need some graphical output and some interactivity (such as following the mouse position or controling the keyboard) has grown more and more difficult to write over the years. In the recent time, I worked on artificial vision routines in C, trying to elaborate a new algorythm in that field. I realised that it proved very difficult to cary this task because I had no easy way to view what the algorythm did in an interractive manner. It again proves the need of an experimentation tool such as Lew. Simplicity... The idea behind Lew is simple: instead of drawing in a window, you allways draw into a bitmap, and that bitmap is in turn displayed in a window if you decide to. Does it sound primitive and ineficient ? Well... it is, but it proves to be an extraordinarily powerfull and expressive model. To display a bitmap file would requires only the following instructions:
Bmp=LoadBitmap("foo.bmp");
Wnd=OpenWindow(BmpWidth(Bmp),BmpHeight(Bmp),"Title");
DisplayBitmap(Bmp,Wnd);
A minimalist paint program would be:
Just compare these two programs with the ones your environment would need to perform the same task. Once upon a time... The following program, in the 80's, would probably have displayed a circle on the screen: 10 CLS 20 R=50:X=50:Y=50 30 FOR I=0 TO 360 STEP 0.1 40 POINT X+R*SIN(I),Y+R*COS(I) 50 NEXT To draw the same circle one decade later, you would have needed this program:
#include <windows.h>
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM);
char circle_AppName[]="Newarc";
HINSTANCE circle_hInstance;
int circle_iCmdShow;
void circle_CreateNewWindow(int Width,int Height,
char *Title,HINSTANCE hInstance,int iCmdShow)
{
HWND hwnd;
hwnd = CreateWindow (circle_AppName,Title,
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,CW_USEDEFAULT,
CW_USEDEFAULT,CW_USEDEFAULT,
NULL,NULL,hInstance,NULL);
ShowWindow(hwnd,iCmdShow);
UpdateWindow(hwnd);
}
void DrawCircle(HDC hdc)
{
Ellipse(hdc,0,0,100,100);
}
LRESULT CALLBACK WndProc(HWND hwnd,UINT iMsg,
WPARAM wParam,LPARAM lParam)
{
static POINT apt[4];
HDC hdc;
PAINTSTRUCT ps;
switch (iMsg)
{
case WM_PAINT:
InvalidateRect(hwnd,NULL,TRUE);
hdc=BeginPaint(hwnd,&ps);
DrawCircle(hdc);
EndPaint(hwnd,&ps);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
}
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,PSTR szCmdLine,int iCmdShow)
{
MSG msg;
WNDCLASSEX wndclass;
circle_hInstance=hInstance;
circle_iCmdShow=iCmdShow;
wndclass.cbSize =sizeof(wndclass);
wndclass.style =CS_HREDRAW|CS_VREDRAW;
wndclass.lpfnWndProc =WndProc;
wndclass.cbClsExtra =0;
wndclass.cbWndExtra =0;
wndclass.hInstance =hInstance;
wndclass.hIcon =LoadIcon(NULL,IDI_APPLICATION);
wndclass.hCursor =LoadCursor(NULL,IDC_ARROW);
wndclass.hbrBackground=(HBRUSH) GetStockObject(WHITE_BRUSH);
wndclass.lpszMenuName =NULL ;
wndclass.lpszClassName=circle_AppName;
wndclass.hIconSm =LoadIcon(NULL,IDI_APPLICATION);
RegisterClassEx(&wndclass);
circle_CreateNewWindow(640,480,"Circle Demo",hInstance,iCmdShow);
while (GetMessage(&msg,NULL,0,0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
That program would have needed an environment of about 10.000.000 bytes to run, and either the creation of a project through a specialised tool or a lengthy cabalistic command line to run. Ten years later, a typical program to perform such a task would look like this one:
import java.awt.*;
import java.awt.geom.*;
import javax.swing.*;
public class SimpleShapeRx extends JPanel
{
SimpleShapeRx()
{
setBackground(Color.black);
}
protected void paintComponent(Graphics g)
{
super.paintComponent(g);
Graphics2D g2=(Graphics2D)g;
g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
int cx=getWidth()/2;
int cy=getHeight()/2;
int dia=40;
g2.setPaint(Color.red);
g2.fillOval(cx-dia/2,cy-dia/2,dia,dia);
}
public static void main(String[] args)
{
JFrame f=new JFrame("Prototype Visualisation");
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.getContentPane().add(new SimpleShapeRx());
f.setSize(500,500);
f.setLocation(300,300);
f.setVisible(true);
}
}
Which is shorter, but involves much more complexity concealed behind object oriented libraries. Such a program would require an environment of about 500.000.000 bytes and would require a set of tools to be created. What can be seen is a progress in term of functionality: where in 1980 you needed to draw all the points of the circle individually, you're now provided with an Ellipse() directive that perform this task or an Oval() one that does the same with some further refinement. This progress enabled us to replace 4 lines (including a complicated one) by a single simple line. In the same time, the personal computing paradigm matured. The original rogue program that assumed a total control over what was perceived as a hobbyist toy have now to behave nicely. It has to comply with access rights, to accept and process requests from the graphical environment, to follow a rigorous syntactic and conceptual model and so on. This maturation required us to replace a single (optional) line by 40 to 80 lines and caused an explosion of the complexity of the tools needed to create the program. Is this an advocacy to return to BASIC ? No: the old BASIC is clearly too primitive to handle problems we're now used to deal with, and new BASIC implementations have just grow in complexity the same way other languages did. The conclusion is a need to an equivalent of what BASIC was in old personal computer industry: a simple, exploratory language. Worth reading Lua beeing the core scripting language in Lew, it is of course worth visiting the Lua website. This article describes the genesis of Lua: The evolution of Lua. It is interesting to see that what would be now perceived as a negative protectionist law had such wonderfull consequences as Lua... In our world turned toward standardisation, maybe there is a lesson somewhere to get out of this :-)
|
