The Zimbu programming language
zimbu.org
zimbu.org
* It has to be as fast as possible, so interpreted languages are out.
* You don't want to micro manage memory, so C is out.
* You don't want to require programmers to have a degree, so C++ is out.
* You want fast startup and not depend on a big runtime, so Java is out.
* It has to run on most systems, anything with a C compiler, so D is out.
* You want to have fun making something new.
No existing language really meets these demands, so let's create a new one that does.
Actually, Lua meets every point except the last one...it's byte-compiled, garbage collected, refreshingly free of exceptions-to-exceptions-to-rules you have to memorize, it starts and compiles faster than many other major contenders start, it runs on literally anything with an ANSI C compiler, and it's been in production use for over 15 years.I use Emacs, but a Lua-extended vi could be very nice.
I think writing a new general-purpose language is something every programmer should try at least once, but don't fool yourself; there's probably an existing language that does what you want.
Now, back to work on that language idea I can't get out of my head involving pervasive generic functions....
(I say, as I work on getting compute-effective-method working in Guile...)
He is not making an interpreted language. It compiles down to machine code that runs directly; not vm bytecode.
Then again, with 2k loc, it shouldn't be that hard to break out the GTK...
UI model nonwithstanding, that's exactly the sort of project that Lua is designed for.
http://www.vim.org/scripts/script.php?script_id=1234 is handy.. You can also script vim with ruby and more..
Anything in all-caps had better be pretty damn important for the programmer to read. And while keywords are vital to the compiler's understanding of the program, they are arguably among the least important text for the programmer to read, as they can generally be inferred from visual length, placement, and formatting.
I think making the keywords all DASH caps is a mistake PERIOD Capital letters draw the eye EMDASH all DASH caps doubly so COMMA and at the expense of readability PERIOD
Given the syntax choices, the main advantage I see in Zimbu is that creating a new language is more fun than porting an existing one.
It allows for less syntax, which is a win for readability and also less boilerplate tokens, but still gives you a little freedom to mess with your indentation, unlike python. It means that (true) lambdas wouldn't be a syntactical enigma like they would be in python.
I don't think that you would need to use "}" to end a block though, since it looks like its missing the opening bracket, but maybe double semicolons would work, since they apparently aren't used elsewhere:
MAIN()
IO.write("Hello, World!\n")
;;
To be honest, the syntax that I have found to be nicest on the eyes so far has been Io: whois := method(host,
socket := Socket clone setHostName("rs.internic.net") setPort(43)
socket connect streamWrite(host, "\n")
while(socket streamReadNextChunk, nil)
return socket readBuffer
)
taken from http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h...What do you mean?
def acc(x):
foo = x
def closures_are_broken():
foo += 1
return foo
return closures_are_broken
def acc2(x):
foo = [x]
def closure_with_workaround():
foo[0] += 1
return foo[0]
return closure_with_workaround
The former is an error ("UnboundLocalError: local variable 'foo' referenced before assignment"), the latter is a workaround by manually boxing the variable in a list. I'm not sure why that works, but it's rather ugly.The same, in Lua:
function acc(x)
local foo = x
return function()
foo = foo + 1
return foo
end
endPython's syntax forces the language to guess whether you want to make a new variable or use the variable of the same name from the outer scope. The heuristic they have, says that if you assign something to the variable, you get a new one by default. You can declare
global x
before to assign to the variable in the outerscope.I like both approaches. it's better then having useless {. In some cases improve readability over python lack of marks. and risking mod down by the audience we have here, it's (much (better then (the gratuitous use of (parenthesis in lisp)))))
how (
is {
this();
}
any();
better(
than[$parenthesis]
);
);
? how (
is {
this();
}
any();
better(
than[$parenthesis]
);
);If you remove his last requirement I think lof of languages still qualify. Effeil for instance, and maybe OCaml.
If I end up having one tenth of the positive influence on the world as this fellow has already done, I'll count my life successful.
vimim
Avoid:
* expression by itself is return value, causes mistakes.Then I open up the GUI builder for almost any language, throw a pre-built text box in place, and press compile. Next?
Not arguing against the language itself. It's just that using "text editor" as a use case is about as descriptive as starting with "Suppose you want to write 'Hello World.'" It doesn't tell you anything about what the actual requirements are. Compiled isn't necessary to build a text editor. Java isn't excluded. Etc.
A text box is not a text editor. After all, take a look at Vim or Emacs. They have their own languages, syntax highlighters, language analysis tools, GUI and ncurses tools, etc... A goodtext editor is a huge piece of software - millions of lines of code (I think), perhaps, in the case of Emacs.
Although I do agree with you - good examples are important.