Slashdot Mirror
Ioke Tries To Combine the Best of Lisp and Ruby
synodinos writes "Ola Bini, a core JRuby developer and author of the book Practical JRuby on Rails Projects, has been developing a new language for the JVM called Ioke. This strongly typed, extremely dynamic, prototype-based, object-oriented language aims to give developers the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax."
http://www.iolanguage.com/
Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects, all messages are dynamic), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).
How we know is more important than what we know.
(There's (a best) (part (of LISP)))?!?
Paleotechnologist and connoisseur of pretty shiny things.
Ola Bini has no beard. The only proof you need that this language will fail?
I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones. The problem is that parents of types must be *instances* of their parent types, and there isn't always a suitable kind of instance to use as a prototype. Either you end up coding around the prototype system and emulating conventional constructors, or you end up specifying special uninitialized states for base classes.
Prototype languages make it easy to use the GoF prototype design pattern, true, but I find myself thinking "hrm, I need a new type" far more often than "Hrm, I need a prototype system for object initialization."
Also, Python and CLOS style metaclasses give you all the flexibility of a prototype system.
I'm all ears for any advantages the latter might have.
People think that s-expressions are a poor syntax. These people are wrong.
Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful. Representing your code as a data structure is what makes lisp lisp. Take that away, and you might as well just use ML.
Another pocket language with idiosyncratic design choices that seem just right to the understimulated nerd looking for fame.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
*sigh*
It would help if you actually read the rest of the article:
If you're looking for a modernized lisp on the JVM, check out Clojure: http://clojure.org/
All the goodies of lisp, the JVM, and functional programming without all the bad outdated stuff. It's a very cool language.
Oh great, you combine the white-space-tab problem with the Lost in a Sea of Parentheses problem to get lost in a sea of white space ;-P
Table-ized A.I.
Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.
the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax
So, it's Lisp then?
Seriously... in terms of small regular syntaxes you don't get smaller and more regular than Lisp:
(source).
Next smallest and most regular syntax for a useful language is probably smalltalk, but that's too long to post here. It's worth noting that smalltalk (particularly its first-class statement blocks) was a heavy influence on ruby. Smalltalk also gets close to hitting the 'nice' requirement, which IMO Lisp is a long way from.
My eye sight must be getting bad... I misread this as:
Joke Tries to Combine the Best of Lisp and Ruby
You mean, "Right, it's a joke." In some browsers, the bottom of the j is cut off. I invented a new language too, named asdlkj. It is whitespace combined with brainf*ck that sits atop the microsoft JVM that compiles down to executable php.
Here is some sample code (tabs in [tab]):
+ + + + +[tab]<[. -]-.[tab] [tab]>-- [tab]<.+.
I'm still trying to understand what it's supposed to do.
I sometimes look at programming as a form of Compression. In this case it's decision/rule/logic compression.
:).
:).
:). We'd rather do stuff like:
...
You can express any program with an infinite list of "IF THEN"s, but that's not very useful (and way too much typing).
So that's where programming languages come in. Not all compression algorithms are great for all sorts of data and situations, similarly not all programming languages are good at all things. Of course there are some compression algorithms which are just plain crap
A language that's powerful for a certain field will have good defaults so that a programmer does not have to do as much work to compress the rules. Typical faxes will compress very well using the standard fax compression method.
While a lot of CS academics like languages that are powerful for the code you have to write (which is a good reason), do not be surprised when programmers in the real world pick languages that are powerful for the code they don't have to write (aka modules/libraries).
You can have a newfangled language which has better compression that other programming languages so that you only need 1000 lines to do X, but it still is not that attractive if you still have to write all 1000 lines yourself, in contrast to using a language which requires 2000 lines to do X, but you only have to write 500 of those lines yourself. Others have already written the other 1500 lines AND best of all have documented and are maintaining them
Marketing and positioning can be quite important in order to somehow convince enough people who like writing those 1500 lines to take up your new language.
You can't expect lazy crap programmers like me to write all that code
use LWP;
Or:
import pyrad.packet
from pyrad.client import Client
Another problem with some languages favoured by CS academicians is they require very very smart people, and there are far fewer very very smart people than smart people (and far fewer smart people than stupid people).
At a certain point conciseness (compression level) isn't as significant compared to the other overheads.
So the ultrageniuses might not be much faster than the "merely smart" in writing the modules that the stupid people are likely to want to use, even if they use your superconcise language.
And if there are 10x more "merely smart" than ultrageniuses, no wonder the stupid people pick the less powerful language - there might be 3-5x more libraries that they'd want to use.
The ultrageniuses would be doing ultragenius stuff, so the modules they write might not be so useful for stupid people like me.
And that's why some crappy languages are so popular (but I could be wrong since I'm stupid).
Yes, people often don't see the point of things they've never tried, or of features that are missing from their current favourite language.
That's because C deals with how computers actually think. All this new stuff with languages is wonderful, and often has some uses in various cases, however none of it relates to how a computer actually works. C is a good "mid level" language. By that I mean it does a good job of structuring programs in terms of how they actually work on a processor, while still being fairly easy for a human to work with.
A lot of people get caught up in their "flavour of the month" language and forget that none of this relates to how computers actually work. For example yes, pointers are confusing and you can get in to trouble with them. However, that is actually how a processor handles things. It has registers that are pointers to memory locations of things it needs (like a pointer to the instruction to execute). So while more restrictive, managed references might be nice, they've nothing at all to do with how the processor works. That means you have to implement additional code overhead to deal with that sort of thing, and that you are losing the ability to optimise in certain ways.
Basically C is likely to remain strong until we just have more CPU power and memory than we know what to do with on all platforms (embedded included). Until then there is the need to generate optimised programs. To do that, you need to be able to write a program based on how the computer thinks, not on how you do.
There's more out there in high-level land than the current crop of scripting languages.
It's funny you mention that Python isn't QUITE fast enough to write an operating system in. I'd say it's dead-slow to write an operating in. Some guys at OLPC thought it was a good idea to write a window-manager in Python. And that is already dead-slow. Python as of now is still an interpreted scripting language. And I wouldn't exactly set the bar as low as to take PHP as a classic example of a fast, well designed language. I'm sure even the most rabid PHP fanboi (if they even exist), will agree with me.
There are a good number of high-level languages which are a good bit more flexible at a much higher performance rate than Python. Take some of the functional languages like Haskell or ML, Lisps like CL or Scheme, or Forth or Smalltalk. Not that shootouts say everything, but just compare a few benchmarks at http://shootout.alioth.debian.org/
And why are they faster? Because they can be (byte-)compiled quite efficiently. Python however was never designed with compiling in mind. And as such, there still isn't a worthy full-fledged Python compiler for real-live use. And as I understand it, Python is very dynamic in a way that's gonna be quite hard to compile.
Now Python is an elegant scripting language that is easy to pick up, has a nice and big standard library and has it's niche, but people that dare to write ' is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction', either blatantly choose to ignore decennia of computer science, or still have a lot of cool stuff to learn.
We already have a programming language with a simple syntax and the strengths of Lisp and Ruby. It's called Lisp.
Badass Resumes
That's the whole base code of Windows 7
Comment removed based on user account deletion