Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ioke Tries To Combine the Best of Lisp and Ruby

timothy posted more than 5 years ago | from the like-a-sibilant-jewel dept.

Programming 255

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."

Sorry! There are no comments related to the filter you selected.

Try harder on the naming front... (0)

Anonymous Coward | more than 5 years ago | (#25700633)

ioke? Loke? I couldn't tell from just looking at the article, I had to check the (thankfully lowercase) link.

Not that it's all that melodious either way...

Re:Try harder on the naming front... (1, Troll)

Praedon (707326) | more than 5 years ago | (#25700671)

Right, it's ioke. And unfortunately for me, at 1:30am in the morning eastern time, the link is very much slashdotted, but would love to see the info on it... yay for checking slashdot in the morning when I wake up!

Re:Try harder on the naming front... (3, Funny)

fractalVisionz (989785) | more than 5 years ago | (#25701309)

Right, it's ioke.

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 [wikipedia.org] combined with brainf*ck [wikipedia.org] 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.

Re:Try harder on the naming front... (1, Flamebait)

stjobe (78285) | more than 5 years ago | (#25701269)

I think it should be pronounced "joke", which seems to fit...

What, joke? (0)

Anonymous Coward | more than 5 years ago | (#25700635)

Mmmm, egg ioke!

Re:What, joke? (0, Flamebait)

RuBLed (995686) | more than 5 years ago | (#25701111)

Hey guys, I know that using close to unknown languages would help in times of war, like the use of Navajo.
But come'on, hawaiian? Can we just get along.. otoh, it would be cool to start all my programs with the word "aloha"

Re:What, joke? (0)

Anonymous Coward | more than 5 years ago | (#25701377)

Yeah, who would ever use a technology with a Hawaiian name? It's no wonder the wiki never caught on. And now that the people of America have overwhelmingly voted in a Hawaiian president, the popularity of the language is only going to decrease.

Try Io (4, Informative)

QuantumG (50515) | more than 5 years ago | (#25700645)

http://www.iolanguage.com/ [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).

Re:Try Io (1)

fucket (1256188) | more than 5 years ago | (#25700675)

Ten?

Re:Try Io (4, Funny)

Kingrames (858416) | more than 5 years ago | (#25700875)

Two. hand in your geek badge.

Re:Try Io (4, Insightful)

Smauler (915644) | more than 5 years ago | (#25700743)

New languages are announced every week or so in different places... it doesn't change the fact that the language that most big projects rely on now is one of the old guard. C [wikipedia.org] is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

Re:Try Io (5, Insightful)

MrNaz (730548) | more than 5 years ago | (#25700949)

The idea of these new languages (Python, Java, Ruby, and presumably ioke) is to abstract very common functions to increase the speed of development.

Every layer of abstraction increases the "power" of the language from a development point of view, allowing developers to do far more than they could with a single line of code, trading off flexibility, and performance.

The idea of a new language is to deliver as much "quick access" functionality as possible (saving the developer having to implement their own low level functionality such as string classes, array handling and perhaps memory management) while compromising as little as possible on flexibility and performance.

If ioke delivers a best-yet mix of these trade offs, then it stands a chance to become the Next Big Thing. Personally, I think that Python is the state of the art when it comes to highly functional development languages that still deliver good performance and flexibility. It's not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off), however it is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction such as PHP.

Re:Try Io (4, Insightful)

julesh (229690) | more than 5 years ago | (#25701357)

[Python]'s not quite fast enough to write an operating system in (although there was an effort called Unununium which tried but never took off)

Unununium's kernel was, I believe, written in C. The user interface, userspace applications and drivers would have all been written in Python.

Unununium didn't take off because its developers had no clue about OS design. They apparently spent most of their time boasting about how their operating system didn't have a kernel (it did; its kernel was a slightly modified Python interpreter[1]) and how it was such an innovative design (when all it did was replicate some of the achievements of traditional language-based systems that were popular in the academic research community in the 70s and early 80s, cf. Smalltalk-80, which although now generally considered just as a language was originally considered by its developers and users as an operating system, or the earlier CMU Hydra system which was built around similar principles), and not enough time actually writing the damned thing.

[1]: The issue seems to be one of understanding what a kernel is. The unununium developers seemed to believe the defining factor of a kernel is that it provides inter-process protection by allocating different memory spaces to the different processes. Under this view, many modern OSs don't have kernels, including Singularity and JX. Also, some older ones, including 16-bit Windows and Amiga.

Logic compression (2, Interesting)

TheLink (130905) | more than 5 years ago | (#25701365)

I sometimes look at programming as a form of Compression. In this case it's decision/rule/logic compression.

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 :). We'd rather do stuff like:

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).

Re:Logic compression (0)

Anonymous Coward | more than 5 years ago | (#25701533)

after reading your post , i too have become stupid

thank you

Re:Try Io (1)

digitig (1056110) | more than 5 years ago | (#25701441)

If ioke delivers a best-yet mix of these trade offs, then it stands a chance to become the Next Big Thing.

I'm glad you said a best mix, not the best mix, because the best trade offs depends on what you're actually doing, which is why the good programmer will have at least a couple of languages under their belt.

(eq high-level-language scripting language)=false (2, Interesting)

teazen (876487) | more than 5 years ago | (#25701773)

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/ [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.

Re:Try Io (1)

Tumbleweed (3706) | more than 5 years ago | (#25701015)

it doesn't change the fact that the language that most big projects rely on now is one of the old guard. C is, despite it's incarnations (or deformations, depending on who you believe) still king, and it was designed in 1972.

That's why I like D. It's basically C with modern concepts built (elegantly) into the core language. No need to get all crazy with things like Ruby, etc. Plus it's compiled. :)

Re:Try Io (0)

Anonymous Coward | more than 5 years ago | (#25701233)

Every time I have an open mind about looking into a new language I end up walking away bitter with "same old tired crap" echoing in my head.

Some academic type or person with nothing better to do gets a wild hair and a 'brilliant' new language is born that will change the world or so they say... If your willing to get past barbaric syntax, no IDE, debugger, supporting libraries or lack of staff who know how to use it. The unforgivable part is the language turns out to be "great" only for a small problem domain and quickly digresses from there.

Fancy language constructs are a trap. If you find them useful it is only because they (temporarily) hide your own bad design decisions.

Re:Try Io (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25702223)

Fancy language constructs are a trap. If you find them useful it is only because they (temporarily) hide your own bad design decisions.

Is that another way of saying real programmers code assembly? Because taken out of context and to its logical conclusion, your argument would seem to imply that.

Language constructs can be good, and can be bad; if your language is too full of them, it becomes write-only, but if it's too lacking, you end up with Java and you need to use design patterns to do everything (people using more functional languages laugh at the pattern hype in OO world, because most design patterns are really just ways of working around the limitations of Java and still getting your work done).

Re:Try Io (1)

BountyX (1227176) | more than 5 years ago | (#25701245)

That's because processor instruction set is essentially the same. Use a processor that takes BYTE code as its instruction set and you end up with a java platform. In the real world, most people have intel based instruction sets.

Re:Try Io (2, Informative)

Anonymous Coward | more than 5 years ago | (#25701399)

Good lord, you haven't done a damn thing at the low level, have you? First, the instruction set argument is complete nonsense -- there's no such thing as a "BYTE code" instruction set, it's a format for compiled code, and the code becomes x86 before it runs on your CPU.
Second, what you're running on should never relate to language choices unless you're running on an embedded platform. Java code is compiled to the CPU just like everything else, it's just done at runtime.
You miss the point: people use C because it's a battle-hardened language, not because of some machine restriction you seem to think exists.

Re:Try Io (-1, Flamebait)

BountyX (1227176) | more than 5 years ago | (#25701539)

You must be a delusional bastard. I can tell because youâ(TM)re using the word "lord" in a manner that suggests you believe in it. Bytecode is the instruction set used for Java's virtual machine, jackass. No, bytecode is not used for compiled code. Wrong again. When java is run on a machine it gets translated into bytecode by the jvm then the jvm executes that instruction set. In fact, the JVM is considered a "processor architecture" on which Java bytecode (a compiled Java program) is executed. Your point is well taken and in the end is one correct factor of the overall equation; my point was that people continue to use C/C++ for ultimate power and flexibility. Such power and flexibility cannot be leveraged with limitations imposed by the JVM and furthermore, javaâ(TM)s bytecode (such as advanced memory managment). Why the hell do you think Sun sells Java based processors? Also, language choice does make a big difference for preformance critical applications on non-embedded devices. Go look at PHP vs Python benchmarks for hashing and then tell me it dosn't matter when you need a server side script to hash 3k video files.

Re:Try Io (0)

Anonymous Coward | more than 5 years ago | (#25702077)

What you say does not make any sense. The java compiler translates java to the byte code. The JVM then takes the bytecode and translates it to the instructions for the given processor. You mix and mash and twist both like they were the same.

And given that, I still don't get why you tell us that. Your previous post begins with "That's because", but I don't see how what follows that has any relation to C being popular.

Third, he said the platform should not dictate the language. He did not say that you should never consider any reasons for a language, and choose them randomly. You should choose C because it is the right tool for the task, not because you are running on x86 Linux. You should choose Python because it meets all requirements and the development time is less than with plain C. You should never choose a language that does not meet the requirements. And he never suggested to.

No surprise (4, Informative)

Sycraft-fu (314770) | more than 5 years ago | (#25701541)

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.

"Best"? (2, Funny)

FlyByPC (841016) | more than 5 years ago | (#25700653)

(There's (a best) (part (of LISP)))?!?

Re:"Best"? (2, Funny)

mechsoph (716782) | more than 5 years ago | (#25700749)

Make that: (? (is there (part a best (of lisp))))

Re:"Best"? (2, Funny)

Haeleth (414428) | more than 5 years ago | (#25701383)

Oh, please. There's a macro for this:

(best-part-exists? 'lisp)
==> t

Re:"Best"? (1)

digitig (1056110) | more than 5 years ago | (#25701463)

Oh, please. There's a macro for this:

(best-part-exists? 'lisp)
==> t

Surely
(p_best_part_exists 'lisp)

Re:"Best"? (4, Interesting)

QuoteMstr (55051) | more than 5 years ago | (#25700759)

The parentheses just disappear after you've coded Lisp for a while. Also, try paredit.el [mumble.net] for Emacs. With that turned on, you don't edit text, but sexps. It's wonderful, once you get used to it.

As for Lisp itself, well, 20 years ago did for the first time many of the things that mainstream languages today are just beginning to obtain, like closures, arbitrary lexical scoping, highly dynamic data structures, and (in Scheme's case) call/cc. One thing gcc just implemented is per-function compiler optimization settings. Common Lisp has had a facility for that since the beginning of time.

One thing that still isn't matched by other languages, however, is Lisp's macro system. It's far more powerful than C macros. You can define new control structures, implement sub-languages, and construct any higher-language construct you want. And these features you build all look just like native language constructs.

And don't even get me started o CLOS, which is one of the very few object-oriented systems to provide a clean multimethod [wikipedia.org] dispatch solution.

Re:"Best"? (2)

cheater512 (783349) | more than 5 years ago | (#25700805)

Have you had your eyes checked recently?
If you cannot see *that* many brackets then something is horribly wrong. ;)

Re:"Best"? (3, Interesting)

hachete (473378) | more than 5 years ago | (#25701007)

Dylan had a very powerful macro system.

http://www.opendylan.org/ [opendylan.org]

with all the advantages of a late-bound language.

Re:"Best"? (2, Funny)

ukbazza (1232802) | more than 5 years ago | (#25701623)

Was that before he went electric ?

Per-function optimization (1)

ion.simon.c (1183967) | more than 5 years ago | (#25701183)

It seems to me that per-function optimization settings would be useful in very few real-world cases.

Re:Per-function optimization (4, Insightful)

Haeleth (414428) | more than 5 years ago | (#25701393)

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.

Re:"Best"? (1)

shutdown -p now (807394) | more than 5 years ago | (#25701203)

CL is great, and CLOS is wonderful (clean multiple inheritance, multimethods, etc - it really is the pinnacle of OO). But the real problem with Lisp today is the lack of static typing, even opt-in (there are type-hints, yes, but they are really more of an optimization hints - they may be ignored by the compiler at will, and type mismatches are essentially U.B., no checking required).

Re:"Best"? (0)

Antique Geekmeister (740220) | more than 5 years ago | (#25701341)

If Lisp were that good, it would have done better in the marketplace. The 'layers of abstraction' of Lisp, and its programmers focus on ignoring what is going on at lower levels, waving a lot of parentheses shaped magic wands and saying 'and then a miracle occurs', and worse yet using recursion to call the same miracle again, and again, and again without paying attention to what that miracle costs, led to terrible programming practices. And the garbage collecion problem keeps turning up, and at my last investigation has no solution. If you've abstracted away all the knowledge of lower level processes, you've surrendered your available tools to mitigate the issues.

Yes, I've worked with Lisp and some of its variants. Unless it's advanced a lot and lost its fascination with recursion for its own sake, it's never going to scale well and will always underperform.

Re:"Best"? (1)

tyler.willard (944724) | more than 5 years ago | (#25701515)

If Lisp were that good, it would have done better in the marketplace.

Please.

Market performance has fuck all to do with the success of superior technology. Case in point: the Amiga.

Re:"Best"? (1)

Antique Geekmeister (740220) | more than 5 years ago | (#25701609)

Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?

Let's look at it again: if Lisp were that superior in solving big problems, it would have solved some of them. As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems. If combining it with Ruby helps address those, great. But I'll believe it when I see it performing well. Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.

Yes, I've had to program in Lisp, and it's wonderful for writing an exciting few lines of demoware. But I've also cleaned up after people taught awful, awful habits of ignoring the interface between those 'layers of abstraction' and leaving the problem of formatting data or I/O to someone else entirely.

Re:"Best"? (1)

tyler.willard (944724) | more than 5 years ago | (#25701803)

Then, if market performance and superior technology have nothing to do with each other, why should anyone invest their money in research? Or are you saying that all technology is performance art, and we may as well paint our bodies paisley and recite poetry from lightposts, because it's just as useful?

This is pure sophistry.

So you don't dig Lisp: fine. However, trying to defend the idea that economic success implies technological superiority is wholely without merit.

Re:"Best"? (1)

dkf (304284) | more than 5 years ago | (#25701925)

However, trying to defend the idea that economic success implies technological superiority is wholely without merit.

Because that would imply that your favourite language is a failure, and you find that conclusion unacceptable?

Lisp is a power tool for a Very Smart Person. Like all such tools, they're difficult to master. The truly successful stuff tends to be usable in an effective manner by people who aren't VSPs. (For example, making it easier to see where the costs of resource management are biting makes it easier for programmers to get good performance. Well, for a large enough fraction of programmers for most SW companies to have at least one on staff...)

Re:"Best"? (0)

Anonymous Coward | more than 5 years ago | (#25701865)

Why should anyone invest in research? Why, to develop marketable technology! That's how it works: all technology research funded by business is primarily market-oriented, and what remains of basic research is funded by government grants. It's not like people choose what they use by technological superiority rather than convenience or price.

Re:"Best"? (1)

K. S. Kyosuke (729550) | more than 5 years ago | (#25701885)

if Lisp were that superior in solving big problems, it would have solved some of them

I think it actually did. :-)

As it is, Lisp faces real problems in garbage collection and system resource management, or at least it has traditionally faced such problems.

When? Where? Any Lisp app I have ever seen has performed much more system-resource-friendly than, e.g., Java apps. And Java is considered a "real" and "businesslike" programming language these days, whatever it means.

Even theoretically addressable problems like the traveling salesman problem, or chess playing, break down badly in Lisp until you ignore its 'layers of abstraction' approach and pay attention to the lower levels of the problem.

Hear, hear! Code written by a lousy programmer performs poorly - what a news...

Re:"Best"? (0)

Anonymous Coward | more than 5 years ago | (#25700765)

Seriously, lisp code doesn't have all that many parens. C code is mostly library functions (c itself being tiny, almost all useful stuff is done with library calls), lisp is mostly library functions. C function calls look like "this(a, b, c);" Lisp function calls just look like "(this a b c)". Equivalent C and lisp code wind up with almost the same number of parens, lisp just has less other punctuation fluff.

While lisp lacks quite as much "line noise" as C, it still has more than people who don't know lisp realise either. e.g. Your example didn't look much like working lisp code: "'" is a very important character that quotes the following expression - 'something is exactly equivalent to (quote something)

So "(There's ..." is thus pretty much incorrect. While in a lisp that separates the 's from the previous token even without intervening whitespace it would certainly be allowed and parseable, and would mean "(there (quote s) ...", it would still be considered incredibly peculiar to write it that way. If OTOH one intended "There's" to be one symbol, well one would have to write "|There's|" - incidentally introducing more of the secondary "line-noise" used in lisp.

Re:"Best"? (1)

QuoteMstr (55051) | more than 5 years ago | (#25700773)

Also, it's
(best-part-p 'lisp)
you insensitive clod. :-)

Re:"Best"? (1)

Simon Brooke (45012) | more than 5 years ago | (#25701547)

(There's (a best) (part (of LISP)))?!?

There is, and you just quoted it. The best part of LISP is that there's no bloody syntax; everything is clean, regular and simple. Of course this isn't true of Common LISP, but Common LISP isn't really LISP at all.

I have to admit I took a look at Io [iolanguage.com] this morning, and thought, 'oh, no, not another language with bloody stupid syntax.'

Re:"Best"? (1)

TheRaven64 (641858) | more than 5 years ago | (#25702321)

The main good part about lisp is that data and code are represented in the same way. Any transform you can do on data, you can do on code. This makes metaprogramming incredibly easy - something like 90% of the GoF patterns can be implemented as Lisp macros, for example.

Io has some syntax, but not much more than Smalltalk, which has assignment, message passing, and literals. After using Objective-C and Smalltalk for a while, I'd hate to switch back to a language which doesn't have infix parameter names (Io doesn't, Lisp optionally can). The thing that makes me hate Io is that, no matter how much I like the language idea and underlying semantics, the scoping rules are completely insane. They are full of weird corner cases that make understanding even short bits of code a real problem.

Your Father's Parantheses (1)

iangoldby (552781) | more than 5 years ago | (#25702307)

Lisp Cycles [xkcd.com]

Still one of my all-time favourites.

Outlook negative (5, Insightful)

incripshin (580256) | more than 5 years ago | (#25700667)

Ola Bini has no beard. The only proof you need that this language will fail?

Re:Outlook negative (0)

Anonymous Coward | more than 5 years ago | (#25700745)

He looks weird enough and has the unusual name that most language devs have, which is all that is needed to write a language, as for it being a good/useful/productive language thats a different matter altogether - odds are its just a bunch of buzz-words by someone trying to gather support for their latest "i-can-do-it-better" project.

Re:Outlook negative (1)

clarkkent09 (1104833) | more than 5 years ago | (#25701333)

He seems to have the required determination though. His name can be rearranged to "No Alibi" and also "I No Bail"

Hmm, so he's got the weird looks, unusual name and anagrams working for him, but the lack of beard is a serious handicap for a language developer. I guess the future of this language is still up in the air

Re:Outlook negative (1)

ignavus (213578) | more than 5 years ago | (#25701281)

However, he wears a hat AND has an "unhealthy" interest in programming languages. So maybe it will succeed after all.

Re:Outlook negative (0)

Anonymous Coward | more than 5 years ago | (#25701297)

Why is a superstition rated insightful?

Re:Outlook negative (4, Funny)

Haeleth (414428) | more than 5 years ago | (#25701413)

No, no, you've got it backwards. Designing a successful language gives you a beard.

Poor Grace Hopper...

Yet another wannabe Lisp minus macros (1, Insightful)

ari_j (90255) | more than 5 years ago | (#25700669)

the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax

In other words, this is just a reinvented Ruby targeted to the JVM. Without macros, what's the point? Why not just stick with Common Lisp and get all the power of Lisp, not just some of it, and still have a "small, regular syntax"? You can even use ABCL [common-lisp.net] if you want to target the JVM.

Re:Yet another wannabe Lisp minus macros (2, Informative)

Maian (887886) | more than 5 years ago | (#25700821)

*sigh*

It would help if you actually read the rest of the article:

Just like Lisp, Ioke provides syntactic abstractions. They take two forms, the first one is macros, which is basically like method calls with lazy arguments that can be evaluated in special ways. The other form is syntax, which works a lot like Common Lisp defmacro. These together provide the possibility of creating new control structures and define new abstractions. The language is powerful enough to allow you to create your own method types, for example. If you don't like keyword arguments, you can define a new method type that doesn't have them. The DefaultMethod currently in Ioke could be implemented purely in Ioke, using macros.

Re:Yet another wannabe Lisp minus macros (1)

BotnetZombie (1174935) | more than 5 years ago | (#25702031)

You can also use Clojure [clojure.org] , for a Lisp-like jvm language with macros.

Prototype-based? I'll pass. (2, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#25700713)

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.

Re:Prototype-based? I'll pass. (1)

Maian (887886) | more than 5 years ago | (#25700813)

The problem with JavaScript is that it doesn't have any mechanism to create new syntax simulating classes that desugars down to prototypes. Instead, you have all these ugly hacks.

So really, prototypes aren't bad. It's just that having only prototypes can feel clunky at times.

Re:Prototype-based? I'll pass. (4, Interesting)

Animats (122034) | more than 5 years ago | (#25700937)

I haven't used Self, but going by my experience with Javascript, prototype-based languages suck compared to conventional class/metaclass based ones.

Generally true. Javascript was never intended for writing large programs. The object system is basically a hack on top of dictionaries. That's easy to implement, but doesn't scale well.

This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully. Some other classic boners are leaving out a "bool" type (C and Python), not providing generics in a statically typed object-oriented language (C++ and Java), and not designing in separate compilation (ISO Pascal).

Ioke is cute, but there's just no really good reason for such a strange syntax, and it's going to turn too many people off. Using whitespace as an operator (really!) is probably a bad idea. The ability to change the operator precedence dynamically may be "fun", but does not lead to readable or maintainable code. Experience with "read macros" in LISP indicates that rewriting code during input isn't good for readability either. On top of all this, Ioke allows regular expressions in code, like Perl. (It's not clear from the description if you can use regular expressions in the read macros to rewrite the regular expressions in the code. I think you can.) So Ioke brings together the least readable features from four different languages.

People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.

Re:Prototype-based? I'll pass. (1)

Artraze (600366) | more than 5 years ago | (#25701301)

> Some other classic boners are leaving out a "bool" type (C and Python)...

I've never understood why this bothers people.
For the two languages you give:

C: In C, everything is a number. This is because everything is a number at the level of the processor, and C is all 'low-level' like that. If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero? There is some confusion by people who don't understand this who will type (x==TRUE), but that's why TRUE is defined as !FALSE (not 1) by clever people, and simply not defined most of the time.

Python: FWIW, Python does have a bool type, it's just that it doesn't really matter (as with a typedef in C). The thing is that without strong types, and the auto-bound, semi-singleton True and False, people never bother typing 'bool' unless they want the true value of an object (i.e. 'bool(obj)').

I think that the Python bit underscores my point: boolean types just don't matter. Python's got it, and you don't even know! Computers only test if something is zero. If it is, it's false, and if it's not, it's true. C exposes this behavior explicitly, while Python sort-of does it in it's rather complex OO way.

Re:Prototype-based? I'll pass. (1)

Antique Geekmeister (740220) | more than 5 years ago | (#25701349)

Everything is a number in C, but binary choices are very common in logic. It's at the core of every 'if' statement: having to re-invent booleans in so many different forms for different uses is just painful.

Re:Prototype-based? I'll pass. (1)

omuls are tasty (1321759) | more than 5 years ago | (#25701873)

You should've read his comment more thoroughly before replying:

This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully.

Booleans were only introduced in Python 2.3, and yes, I would call that a "boner" for such a high-level language.

And as a matter of fact, a similar response applies to the other poster for C++ (and Java) and generics. Actually, I think the GP directed the "painfully" part of his post to these two.

Re:Prototype-based? I'll pass. (1)

grumbel (592662) | more than 5 years ago | (#25702183)

If the processor is only going to check whether something is zero or not, why enforce that a given number is _precisely_ one or zero?

Because it expresses much more precisely what you intend to do. Having a "bool is_visible()" in a GUI toolkit makes sense, having a "int is_visible()" not so much, which is why everybody ends up doing macro hacks of BOOL, gboolean and whatever. Lack of basic features in a language just leads to lots of hacking around to get those features into the language down the line, its simply annoying.

Re:Prototype-based? I'll pass. (1)

Haeleth (414428) | more than 5 years ago | (#25701443)

On top of all this, Ioke allows regular expressions in code, like Perl.

This is a good idea; it makes the regular expressions themselves much easier to read, with less escaping than is required in languages that insist on putting them in strings. Regular expressions are already complicated enough without requiring you to write crazy stuff like "\\\\\\*" just to match a backslash followed by an asterisk.

It also makes it feasible for syntax-highlighting editors to treat all regular expressions specially, which means that things end up being more readable, not less, because you can see exactly which characters are literals and which are metacharacters at a glance.

Re:Prototype-based? I'll pass. (1)

johannesg (664142) | more than 5 years ago | (#25701733)

This is one of the classic things one can do wrong in language design, and which tend to have to be fixed in later versions, painfully. Some other classic boners are leaving out a "bool" type (C and Python), not providing generics in a statically typed object-oriented language (C++ and Java), and not designing in separate compilation (ISO Pascal).

C++ most definitely has generics (templates!). Feel free to hate the syntax, but they are there.

As for the other poster who #defines TRUE as !FALSE, that of course does not work - or at least, not as he seems to intend it:

const int a = 3;

if (a == TRUE) ...

This will still fail, because it expands to

if (a == !FALSE) ...

which itself expands to

if (a == 1) ...

which gives a result that I would rate as incorrect. And if by some miracle the author did intend for this to be correct, he is really overdue for a good beating...

People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.

So true...

Re:Prototype-based? I'll pass. (1)

LarsWestergren (9033) | more than 5 years ago | (#25701927)

Ioke is cute, but there's just no really good reason for such a strange syntax

I'm not sure Ioke is the language for me, but I think it is interesting that he is experimenting with syntax and trying out new things. He has blogged [olabini.com] about his reasons for using space as the method operator, and the consequences.

People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.

I've worked with Ola. Trust me, he's done plenty of maintenance programming over the years. :)

Lisp Syntax (4, Insightful)

mechsoph (716782) | more than 5 years ago | (#25700733)

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.

We don't think with 1 datastructure (0)

Anonymous Coward | more than 5 years ago | (#25701347)

My problem with expressing everything as a list structure is that it's A data structure, and that it seems my brain doesn't think like that.

Why not instead of lists, use maps + lists ? You can of course express a map with lists but maps/"names" are so natural to think with that I think it would be easier to express ideas with it. "Naming" is very natural, and I don't think names as lists of lists.

Having a unified data structure to handle code and data is nice for me, but the expressiveness of one data structure is too limited for me. I don't speak lists, I speak lists+namespaces.

Re:Lisp Syntax (4, Insightful)

grumbel (592662) | more than 5 years ago | (#25702235)

Seriously, if you give yourself the change to wrap your head around it, s-expressions are both elegant and powerful.

Elegant and powerful? Sure. But Readable? No way.

I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, even after some years toying around with Scheme, I still find "a = 5 + b" a hell of a lot more readable then "(set! a (+ 5 b))". The first paints a visual picture with clear symbols, the other is just token soup, it might be easy to parse for a computer, but very definitvly not for a human. Array access and a lot of other basic stuff is just a total mess in s-expressions.

Duhh (0)

Anonymous Coward | more than 5 years ago | (#25700737)

Scripting in the JVM, I remember when they called that Coldfusion.

Oh boy! (4, Insightful)

jjohnson (62583) | more than 5 years ago | (#25700753)

Another pocket language with idiosyncratic design choices that seem just right to the understimulated nerd looking for fame.

Re:Oh boy! (4, Insightful)

Maian (887886) | more than 5 years ago | (#25700827)

He's announcing it way too early. He has practically nothing to show. There's only one tiny code example that I can see to gauge its merits.

Re:Oh boy! (1)

LarsWestergren (9033) | more than 5 years ago | (#25701993)

He's announcing it way too early. He has practically nothing to show. There's only one tiny code example that I can see to gauge its merits.

When he announced it on his blog a couple of months ago it he said it was in progress. He is still experimenting with the syntax and semantics of the language, so I think it is currently mostly interesting for those who want to discuss ideas and experiment themselves.

Clojure (4, Informative)

slasho81 (455509) | more than 5 years ago | (#25700871)

If you're looking for a modernized lisp on the JVM, check out Clojure: http://clojure.org/ [clojure.org]
All the goodies of lisp, the JVM, and functional programming without all the bad outdated stuff. It's a very cool language.

Re:Clojure (2, Insightful)

shutdown -p now (807394) | more than 5 years ago | (#25701219)

In my opinion, those are the three projects that one has to look into for cool (if you're a PL geek) stuff that is nonetheless bordering on mainstream: Clojure, Scala, and F#. Last two in particular, as Scala seems to be the "future of Java" to many advanced Java programmers who got tired of language limitations, and F# is being made a first-class supported language for the next .NET and Visual Studio release.

Meanwhile, yet another my-own-programming-language-of-the-day is getting old. There are announcements of those pretty much every week on LtU. It may be interesting if it really explores some new dark corner in language design (particularly experiments with more powerful typing systems). But "combining the best of X is Y" is not it, sorry.

Re:Clojure (3, Interesting)

slasho81 (455509) | more than 5 years ago | (#25701319)

There is a lot of buzz around Scala and F#, and considering the limitations they lift from the more conventional mainstream languages it's understandable. But I think Clojure transcends both these languages and many other new on-top-of-another-platform languages because it doesn't just take the latest trendy language features and mix them with new syntactic sugar. It has a very well thought design that feels very right, elegant, and powerful.

I can't recommend enough the screencasts by Rich Hickey [clojure.blip.tv] , the language designer and main implementer.

The 5th screencast, Clojure Concurrency [blip.tv] , is most recommended by me for programming language aficionados. It's a long overview of the language and its philosophy regarding concurrency programming. After I saw that one, I was very excited about Clojure in a way that none of the latest languages made me feel.

Re:Clojure (2, Informative)

slasho81 (455509) | more than 5 years ago | (#25701329)

Slides [googlegroups.com] and code [googlegroups.com] for the 5th screencast about Clojure linked in the parent message.

Re:Clojure (1)

shutdown -p now (807394) | more than 5 years ago | (#25702371)

There is a lot of buzz around Scala and F#, and considering the limitations they lift from the more conventional mainstream languages it's understandable.

I think the buzz is not so much about lifting limitations as it is about those two moving into mainstream application development alongside the likes of Java and C#. It is that upcoming ability to use those nice language features in large real-world production projects that's so exciting (for me at least). Playing with Haskell is one thing, but this is quite different.

The 5th screencast, Clojure Concurrency [blip.tv], is most recommended by me for programming language aficionados. It's a long overview of the language and its philosophy regarding concurrency programming. After I saw that one, I was very excited about Clojure in a way that none of the latest languages made me feel.

STM is seriously cool, but present-day implementations are still too slow (even though the scalability is theoretically much better... but hey, we've got to run it on today's hardware). The rest of the bunch don't seem to be unique on the first glance - at least I don't think there's anything there that F# + PLINQ don't cover (and possibly something else - it just so happens that I'm mostly a C++ and .NET guy, so that's what I'm most familiar with).

Thanks (1)

pjt33 (739471) | more than 5 years ago | (#25701663)

Looks interesting. I've been wanting a functional language with a read-execute loop which I can put on my PocketPC for a while, but not finding anything. I'll have to play around and see what I can do with Clojure.

Lost in a sea of (3, Funny)

Tablizer (95088) | more than 5 years ago | (#25701059)

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

Yep, combining Lisp and Scheme does it for me ... (1)

wombat21 (1378555) | more than 5 years ago | (#25701095)

Is there a (popular) dynamic language that --hasn't-- combined facets of both Lisp and Scheme in its design ? And (inevitably) gotten it 'wrong' according to the Lisp/Scheme diehards on /. ? We want it all - purity, simplicity, power and blinding speed - but every 'new' language/platform will be held up to the light of these two standards. For mine, the language is only part of the equation - its the libraries that the community contributes which make it practical to use language X over language Y. I'll stick with Perl, Python and Java for now. YMMV, and probably will.

Re:Yep, combining Lisp and Scheme does it for me . (1)

inalienable (670771) | more than 5 years ago | (#25701199)

Um, Scheme is a Lisp.

Awesome another langauge (0, Redundant)

BitZtream (692029) | more than 5 years ago | (#25701205)

for shitty developers to produce crappy software with. Seriously STOP WITH THE 'LETS INVENT OUR OWN LANGUAGE' crap. REALLY. You're not going to help anyone. The good programmers already have PLENTY of GOOD languages to choose from, and your new language isnt' going to do anything for the crappy programmers because THEY AREN'T ANY GOOD AT PROGRAMMING, the language isnt' the problem.

We don't need a new compiled language.

We don't need a new vm.

We need to figure out what the hell we're doing with what we got and learn how to develop software that doesn't suck for users. The language isn't the problem there, we are, the developers who are spending our time trying to solve the problem by programing things for ourselves rather than listening to what the users want and need and STANDARDIZING on things.

You want to make computing better? Lets come up with some standardized way of doing things and improve on those together.

How many sources of electrical power can you get in your home right this moment where you live? 1? MAYBE 2? And no your own personal wind generators or solar cells don't count because you are missing the point. The end user just gets power, they know what they can use it for, anything that plugs in to a power socket.

How many sources of water can you get in your home? 2, maybe 3 if you count trucking it in.

How many different ways are there to start a common car? 1? 2 if you count keyless/remote ignitition.

The point to this is that all of those things people can and do use without needing to think about it. Not because someone invented a new way to start a car, but because everyone makes it so starting a car is the same for everyone instead of some whacky new 'look how pretty my new GUI is compared to the one that worked perfectly fine yesterday, forget the fact that we have our own names for everything thats probably not like anyone elses, and our own file system layout'.

Adding another useless option isn't going to help anyway, its just going to waste time. Yes, research is important, but this crap isn't research, its just another developer wanting to do his own thing because he's somehow 'better' than everyone else. Your new language isn't going to help bad programmers suck any less and its not going to really make a big difference to any good programmers as language doesn't matter to them for the most part anyway, except for some tiny little niche you might fill. MIGHT. Its likely in this cause being that its built on the JVM, that people should probably just use java anyway.

The last thing we need on slashdot to go with the daily slashvertisment and 'ask slashdot because I'm clueless' articles is another language thrown into the above to articles when clueless developer asks slashdot which language he should use for his new project. 2 hints on this matter: If your asking, you shouldn't be doing the project. Second, slashdot isn't going to help, its just going to confuse you with the opinions of several hundred other assholes just like me who think we all know everything perfectly. /RANT

Re:Awesome another langauge (4, Insightful)

ABasketOfPups (1004562) | more than 5 years ago | (#25701237)

Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.

Re:Awesome another langauge (1)

johannesg (664142) | more than 5 years ago | (#25701745)

Not one single soul in the world who was ever going to make a language, is now not going to, because of that rant.

I don't know. I was going to invent a language this morning, but after reading this I'm having second thoughts.

What should I do?

Re:Awesome another langauge (1)

Waccoon (1186667) | more than 5 years ago | (#25701277)

I say we stop all development entirely!

Its likely in this cause being that its built on the JVM, that people should probably just use java anyway.

I'm not a Java expert, but... Java does everything that Ruby and LISP does without having to jump through hoops?

Re:Awesome another langauge (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25701837)

In the old days some people had a terribly complicated device called a "stove" which they used to prepare all kinds of different food. There was no standardization at all. Everybody used different ingredients and different ways to prepare the food. It was horrible. But then came the golden age of standardization. MacDonalds and Starbucks rule!

Re:Awesome another langauge (1)

Jesus_666 (702802) | more than 5 years ago | (#25702251)

How many sources of electrical power can you get in your home right this moment where you live?

Let's see... I'm hooked up to the electrical grid and I have some chemical batteries lying around. That makes two. I also have a USB charging cable for my NDS, which is different from directly plugging the DS into the wall. So I have three different kinds of power source I can readily remember, the self-sustaining solar calculator not counting. And no, I wouldn't want to standardize on any one of them as they all have applications for which they are not good for.

We can't standardize on one single language because no single language is suitable for all tasks. I wouldn't want to do embedded programming in C# and I wouldn't want to write a large application or a shell "script" in C.

A replace-them-all language would have to fulfill all of the following requirements:
- be object oriented
- not be object oriented
- be functional
- be imperative
- be declarative
- be low-level and close to the metal
- be high-level and completely abstracted
- have a large class library
- have a tiny runtime
- have a garbage collector
- not have a garbage collector
...and so on.

So many languages but so little worth saying (0)

Anonymous Coward | more than 5 years ago | (#25701283)

There, I've said it.

So... (4, Insightful)

julesh (229690) | more than 5 years ago | (#25701291)

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:

s_expression = atomic_symbol \
                            / "(" s_expression "."s_expression ")" \
                            / list

list = "(" s_expression ")"

atomic_symbol = letter atom_part

atom_part = empty / letter atom_part / number atom_part

letter = "a" / "b" / " ..." / "z"

number = "1" / "2" / " ..." / "9"

empty = " "

(source [unige.ch] ).

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.

Re:So... (3, Insightful)

Haeleth (414428) | more than 5 years ago | (#25701459)

Unfortunately that nice small regular syntax is only for the Lisp core. The actual language that you need to program in has all kinds of other syntactic features, starting with 'symbols and `(macro ,@quoting) and going rapidly downhill from there.

Joke? (5, Funny)

shoban (190941) | more than 5 years ago | (#25701303)

My eye sight must be getting bad... I misread this as:

Joke Tries to Combine the Best of Lisp and Ruby

Re:Joke? (1)

machine321 (458769) | more than 5 years ago | (#25702011)

They should have called it Luby. I can see the want-ads now, "Experienced Luby programmer wanted for large adult web site."

you fail M1t (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25701513)

it A break, 1f [goat.cx]

The best of LISP? (0, Flamebait)

Bootarn (970788) | more than 5 years ago | (#25701563)

((((((((((((((((Really?))))))))))))))))

Pictures! (0)

Anonymous Coward | more than 5 years ago | (#25701587)

Pictures or it didn't happen ;)

From the RA: (1)

digitig (1056110) | more than 5 years ago | (#25701753)

"Since it's quite terse and provide powerful features for succinctness, it should be very maintainable."
Yeah, sure. We all know how maintainable APL and Forth are. Wikipedia identifies as a feature of write-only code "syntax which permits (or encourages) the writing of very dense code." I can't help thinking that "Those who do not learn from history are doomed to repeat it".

Why is ruby everyone's boyfriend (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25701835)

Seriously, why is everything in/about/emulating Ruby right now? From what I understand, this implementation isn't necessarily that much like Ruby, but given the summary it seems people would like to think/hope so.

Don't get me wrong, I like Ruby but I would never seek to emulate it. The language libraries are inconsistent and poor in many cases and there are other serious design issues. It's a cute little language great for shell scripting and quick one-offs, but I still cannot take it seriously after trying to prototype out various projects in it and seeing many weaknesses.

If you're not using some existing implementation/framework in Ruby such as Rails, why use it at all? Smalltalk and Lisp have done the same things are more much better since the beginning of time. Both languages are far cleaner, with Smalltalk having the better syntax IMO and Lisp having the advantage in power. If you could combine Smalltalk's dev environment and VM with Lisp's power, then we would have something worthy of actually looking at.

I Dub Thee... (0)

Anonymous Coward | more than 5 years ago | (#25702197)

Wewby!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?