Do your worst
Is this a two-level language?
A Venn diagram describing the overlapping populations of Monty Python admirers and software developers would probably show a very large intersection between the two groups. But that's not the only reason software development and motor boat enthusiast Göran Krampe has announced a new programming language called “Ni”. The …
Is this a two-level language? ... Big John
Methinks the opportunity is that such a language is both executive top tier and pornographic bottom drawer, Big John. Although it is most probably only best used by a select and/or well chosen few.
Ni, or a certain root and overarching branch of it, would appear to be well suited and booted to further proactions and spooky reaction in Quantum Communications Control Systems where Creative Cyberspace Command and Control of Computers and Communications is AI@ITsWork and where nothing is as it initially seems, and something completely different, again and again, from what may be subsequently imagined, and therefore revealed and regarded as a being quite alien in nature within traditional established hierarchical circles/SCADA Command Bases and ControlLed Structures.
How very encouraging.
And there I went and shaved my neck today. I need to see more of Ni.* Very much reminds me of things I was "toying with" in the mid-eighties. Heady days. Hawaii, Maui wowee, Amiga, ....
* I need to take my spellchecker and put a stake through its black heart. Kept transposing Ni to Nintendo!
This post has been deleted by its author
Splendid. Took me a minute to figure out what was going on there as dynamically generated / self modifying code algorithms are never particularly easy to read. This is particularly true when you're used to procedural code and know the pain of working professionally with dynamically generated code (e.g. often found in JavaScript) all too well.
On an aside, why do so many new language designers manage to make their syntax only barely more legible than INTERCAL? (and never as polite)
I found it quite readable, actually. Mileage will, of course, vary. It's not how I'd design a language myself - I prefer more-verbose languages, because with expressive languages and fast interactive development systems the economics favor reading comprehension over saving characters when writing - but it's not terrible, in my opinion.
I do wish Krampe would learn how apostrophes are conventionally used in English, though, or quit using contractions. Reading his blog is a bit annoying.
The syntax of Ni is actually very free form and basically copied from Rebol and then I added some Smalltalk style - so for a Smalltalker its very legible. Also, the syntax goes hand in hand with homoiconicity - so its bound to be different from "conventional" languages.
Göran Krampe
That's either wrong or vapid - take your pick.
Wrong because Ni, like its predecessors (Rebol, etc) has syntactic sugar for things LISP doesn't accommodate directly. Common LISP doesn't have syntactic support for infix expressions, for example. The S-expression representation used by LISP doesn't have Ni's flexibility in selecting items from the (conceptual) stack. Ni blocks, like Rebol blocks, have an internal cursor; S-expressions don't. And so on.
Vapid because all Turing-complete programming languages are equivalent, in the sense of being able to express the same set of computable functions. And as Kolmogorov demonstrated, they're not only equivalent, but equivalent in program size except for a constant that is small relative to the average size of a non-trivial program.
"My old language is better than your new language" is a favorite curmudgeonly refrain (particularly among LISP enthusiasts), and as a curmudgeon myself I have some sympathy for it. But all too often it's an excuse for an anti-intellectual refusal to understand what actually is happening in programming-language design.
Thanks Michael, that was ... very insightful and well put. I am an old Smalltaker and love Smalltalk - but I am also old enough to know that, hey, stuff can always be improved. And Alan Kay was frustrated that Smalltalk stopped evolving. This is at least an attempt to try breaking new ground.
At the risk of sounding cynical, the "advantage" that it has is that it isn't Smalltalk - it's a new language. There seems to be a bit of an obsession these days with creating new languages, frameworks, etc. and declaring their awesomeness, rather than just concentrating on doing awesome things with the amazingly powerful languages and frameworks already in existence.
I don't mind evolution and invention, but these days I get the feeling that more effort goes into building the tools than goes into using them.
(and yes, I am a grumpy, jaded old man)
Sounding like you couldn't be bothered to look at the language ...
I generally like your rants, Michael, but seriously, what's with the ad hominem? The OP is clearly making a general point about new languages (not this one) and makes no bones about the fact that he's possibly being cynical and a curmudgeon (something you yourself mentioned in your OP).
So have an upvote for your original post, and a thumbs down for that one :(
I generally like your rants, Michael, but seriously, what's with the ad hominem?
I have to disagree - it's not an ad hominem, because I didn't impugn my interlocutor's character, much less base any argument on it.
I meant exactly what I said: if your argument sounds like you haven't bothered to look at the thing you're critiquing, then that makes your argument weak. And "a general point about new languages" is precisely the sort of gloss that - by making no association specific to the object at hand - sounds that way.
If I were to write "every post to the Reg forums is terrible, so this one probably is too", I'd be committing the same error.
The underlying problem is that a post of the form "new instances of X are usually crap" doesn't tell us anything useful about the specific nature of this particular Xi. And unless it's supported by something more substantial (say, a reference to a methodologically-sound study showing that a large fraction of new X, historically, have been crap), it doesn't tell us anything useful.
And it's not like I told the OP to jump off a bridge or anything. But, hey, it's not a big deal in any case.
I am doing awesome things with stuff already in existence. :) We work with Smalltalk and our product is a virtual world system for business use. However we also now use Nim, a very powerful new-ish language.
Ni started as a private itch. Now it has reached a point like "Oh, hey, this actually... is kinda neat". Will it ever reach the next level? Dunno. But its fun!
And oh, you did start out quite well there - one advantage is indeed that its a new and fresh start. There have been numerous Smalltalks over the years, but they almost always end up as 95% clones of Smalltalk-80. I want to try to make it different. Advantages over Smalltalk is also very hard to describe unless you refer to a specific implementation of Smalltalk.
But generally Ni is homoiconic and is able to do meta programming on the AST level. Smalltalk can also do such things, but not as natural. Smalltalk is also class based and quite a beast of a language. Ni is very small by design. And then yeah, Ni is meant to work with Nim.
Krampe mentions some in his blog post:
- Improved syntax for ordered collections and dictionaries, which Krampe claims make up the vast majority of collections in Smalltalk programs.
- Function parameters are not declared; they're pulled from a conceptual stack by an operation. That means a function's arity is determined only at runtime (all functions are variadic).
- Via Nim, it integrates easily with C, which means it integrates easily with a lot of legacy code.
- It has built-in support for native threads and parallel code.
I'm certainly not a Smalltalk expert, or a Ni expert for that matter, but those are some of the things Krampe is claiming.
Yes, I read the blog post. I'm certainly not a Smalltalk expert either (I was, once upon a time); my view is that:
As for improved syntax, I'm sorry but I don't see persuasive examples here. Smalltalk doesn't have any syntax apart from three reserved words, some delimiters and a particular form of message passing. There is certainly no syntax for handling dictionaries or other collections, you just send them messages. If you don't like the standard messages, you can use different ones. Is it that you don't like the way messages are passed?
I'm not sure what the advantage with not declaring a functions parameters is. If you want a function with variable arity, aren't you just passing it a collection of parameters? (Or, even better, invoking a function implemented by a particular class of collection?)
Every variety of Smalltalk I have used integrates easily with C.
Smalltalk supports parallel code but support for native threads is interesting - however, the lack of this in most Smalltalks is an issue of the Virtual Machine, rather than the language.
I'm not dismissing potential improvements here - I'm extremely interested. In particular I may have misunderstood the issue concerning functions. I would concur that many Smalltalks have ended up 95% like ST-80 but I think there is a good reason for that; it is, in my opinion, nearly perfect. I also think though, that in agreeing that all Smalltalks are very nearly ST-80, you have somewhat undermined your argument that it is difficult to compare its advantages to Smalltalk in general, rather than a specific implementation. If that is true, it suggests to me that your real advances are primarily in the interpretation of bytecodes (i.e. VM work) rather than in language design.
First of all, note that the article doesn't show all of Ni - nor is Ni in any way near a reasonable version. I did raise it to version 0.1 yesterday though. Secondly, I *am* a Smalltalk expert and love Smalltalk. :)
Smalltalk does have syntax, yes, its a minimalistic language - but it does have more syntax than Ni has. And yes 5 reserved words of which all are pseudo variables, but you also have cascades, statement separators, assignments and more. But the passage about syntax is about literal syntax for OrderedCollections and Dictionaries primarily. Smalltalk has literal syntax for arrays, no literal syntax for Dictionaries. Squeak added an extra literal syntax for arrays that can take expressions, but that is not standard Smalltalk-80. Either way, no, Smalltalk is quite weak when it comes to *literal* syntax.
I love keyword messaging syntax, that is why I deviated a bit from Rebol in order to be able to fit it into Ni. The part on not declaring function parameters, that is more of an experiment in Ni - it makes blocks even shorter, and it also enables blocks to dynamically decide how many arguments to pull in, and in which order. Note also that funcs in Ni can act as "infix operators" without being attached to a receiver as a behavior. In that way funcs are functions, not methods. But we will see how it plays out. The two major reasons for argwords is a) I didn't like Rebols way of declaring args and b) I want Ni to be homoiconic and that gets messy with a declaration section first inside a block.
Note that Ni has some things that enables it to do things Smalltalk can not easily do. The trivial first example with modifying a block and then run it - is actaully not something Smalltalk can do at all. Ni also supports "quoting" so that functions can operate on the AST nodes of the arguments, instead of the evaluated result of the arguments. This is something I have yet not explored, but its in there and that is actually how assignment is implemented! Assignment is just a function call in Ni. In Smalltalk its built into the language grammar.
Regarding integration with C - no, most Smalltalks are pretty weak on that. Sure, they can call dlls etc via FFI, but its not the same as being good at it, far from it. And C++ is basically a complete NO GO. Smalltalk/X is probably the strongest in this area.
Yes, almost all Smalltalks use green threads, and yes, its of course an implementation issue. But that doesn't make it less of a problem.
Regarding Smalltalk being perfect. No it isn't. Its VERY good, but its not perfect. Its my language of choice since 1994, but no, its not perfect. As I said, Alan Kay himself was quite annoyed with the Smalltalk community from not moving forward. He was also not happy with the meta class model, and personally I think Self has a much more interesting model. Lately we got Traits, and now Pharo is adding some new language level things, but it has stood basically still for a long time.
Finally, no, the Ni interpreter itself is a toy compared to a high end JIT VM like Cog by Eliot Miranda. That's not what Ni is about, I want to keep it very simple. No, Ni is about exploring new ideas in the realm of a Smalltalk-like language. Ni code can be made to be very similar to Smalltalk (if libraries are designed in that direction) and the feeling of development can be similar, and hopefully even more live and fluid.
Also, finally, note that this is an experimental language which evolves in an explorative fashion. I have no idea if its going to become great, medium or plainly suck. But its fun and its interesting! :)
Thanks for your feedback, I am normally on IRC if you want to discuss more.
regards, Göran
And here's an example of it:
> code = [3 + 1]
> code[-1] = 4
> print eval code
FAIL: you can't do that
> _
It has objects. All inherit from the superclass, fail:
> class Example -> fail [ ctor = [ print 'success!' ]]
> new Example
FAIL: success does not come your way today
> _
I intend to rewrite Windows in FAIL. It will be called FAILdows and I think it'll be a great success. Or failure.
I fear the loop command could be a tad long-winded...
Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out.
Eh, what? You are... completely missing ... like all points with Ni. Its not a dumbed down language. Its a seed for a Rebol-ish Smalltalk-like language. Its main goal is 100% live coding, which is very important in some domains like say... 3D interactive live worlds - which we happen to work with. Well, I can go on and on - but the short answer is: You are dead wrong.