Yearly Archives: 2014

Every once in a while, I go back and reread the Reddit thread where they were first talking about Smile. Each time I read it, it’s a reminder of what I’m up against. There are a lot of interesting notions about what’s good in a programming language; everybody has their own pet feature: It has to be as fast as C! It has to allow infinite threads! It has to be 100% type-safe! It has to be type-inferring! It has to be designed for building web services! Did you see how X implemented generics!? And you’d better not leave out Intellisense!!!

It reminds me of back in the ’90s when I worked with this lady who was convinced that client-server would take over the world — by which she meant custom apps running on PCs talking to mainframes. Our worldviews and past experiences skew our expectations toward what we want, and the future often doesn’t play out the way we hope or expect.

(This is gonna be a long post, and I’m going to talk a lot about Smile, including some philosophy and history, a deep-dive into the core syntax, and a bunch of additional examples at the end. I feel like writing a bit on one of my favorite topics. Don’t feel obligated to read the whole thing.)

Continue reading →

I’m quite overdue for a status update, so here we go.

I spent most of July with a busted ankle. Crutches are fun, I tells ya. That helps sum up the whole lotta nothin’ I did this month. It’s a really bad sprain I got late June, and it took many weeks and many doctors, and it’s still not fully healed yet, but at least I’m not on the crutches anymore.

Oh, you want to know more about Smile, right. Y’all come here to find out what I’ve been coding, not for personal stuff. So let’s talk about Smile.

The language grammar is now fully implemented in the interpreter, and a number of bugs in the methods on the core objects have been fixed. It has a REPL now, which makes experimenting and testing much easier.

Continue reading →

I really want to get the Unicode support in Smile right. I really do.

The unfortunate thing is that it seems there’s no consensus on what “right” looks like. Some people argue that UTF-8 is the right answer, some argue that UTF-16 is the right answer, some argue that UCS-4 is the right answer, and if you ask a hundred people, you get a hundred different answers as to what’s right.

Y’all are complicatin’ my life ‘cuz ya can’t agree on nothin’, I tells ya what.

Continue reading →

So a few weeks ago, I was reading this essay by Ramsey Nasser. I’ve debated back and forth several times as to whether Smile should keep its strings and identifiers as 8-bit characters, or whether they should be upgraded to full Unicode. It’s a tough question.

On the one hand, I’m trying to build a language that will be able to grow well with the needs of the future, and the future argues for Unicode. There are a lot of people out there, and not all of them speak English. Or read or write English. As Nasser notes, Arabic is poorly supported by, well, everything, and there’s only a few bajillion people out there speaking Arabic. (It so happens that Arabic is possibly a pathologically-bad worst case for programming language support, too, since it’s a proportional cursive writing system and not fixed-with, with concepts like initial, medial, and final forms, instead of a single letterform per phoneme, and for the icing on the cake, it writes in the dead opposite direction of most other languages on planet Earth.) And beyond Arabic there’s Chinese and Russian and Devanagari and Japanese and a thousand others, and a really good future-proof programming language ought to be able to support all that in a very natural, native kind of way.

Continue reading →

There are a few posts on Reddit about this that I just had to give direct replies to.

I always thought lisp was a platonic form

Lisp is not really a “platonic form,” although really what should be argued is the number of operators required for Turing-completeness. Lambda calculus could make a better claim to something like that, although it’s a Turing tarpit. Lisp had a certain degree of elegance by being able to describe its own evaluation using seven fundamental operators (or five, or six, or eight, or whatever, depending on who you talk to). But you can define a Turing-complete language using a single operator. Even the simplest Lisp is a lot bigger. Smile has about a dozen fundamental operators (and its unique parsing/translation layer): That core is not as small as McCarthy’s Lisp, but it’s not exactly a gallumphing dirigible either. That said, of that, only six or seven of those operators are truly necessary; you can write a simple but working eval function for Smile in Smile with just that much, and one of the sample programs I’ll include is exactly that.

I suggest Sean release the language specification and let alternative implementations begin.

Doesn’t there have to be a first implementation before there can be alternative ones? I’d like to get the formal language specification nailed to the floor and etched in stone — and build good conformance tests — before really thinking about alternative implementations. When I’m done squishing bugs in the interpreter, and I have enough documentation that people can learn Smile and become comfortable coding in it, that’s when it’s time to start talking about alternative (faster) implementations. Right now is just too early.

That said, the current interpreter has the Apache open-source license stamped all over its source code. You will be able to get your hands on it from stem to stern, optimize it, clone it, and rebuild it to your heart’s content — when it’s ready for the general public, which it definitely isn’t yet.

> Actually Smile code is very similar to Rebol however it’s exponentially more powerful

> what does that mean?

I don’t know either.

I’ve been pondering this question all day: What the heck do I do next?

The intarnetz has discovered Smile, which is kinda cool, in a terrifying sort of way.

But the language is still barely in its infancy. I have a semi-working interpreter (release package 0.3!), but there are lots of bugs and some stuff is far from built. The language grammar is pretty well nailed-down at this point. But the libraries are severely lacking, even for really common operations, and even a few of the standard data types don’t exist. I have some documentation, but it’s far from complete.

Yet people want to know more. They got a taste of something interesting, and for a fleeting moment, it’s become news, after a fashion. I don’t want to starve and disappoint potentially-interested folks, but I don’t want to give out junk and crush what could be something pretty neat.

So tomorrow, I’m going to talk with some folks at work who’ve been following Smile through its development, and we’ll see if our brain trust can figure out what a good next step is. I’m a coder: I develop algorithms, not marketing plans, and I’d rather stick to what I know.

For tonight, I got the current Smile interpreter running under Mono on Linux, so w00t on that.

Anyway, uh, stay tuned, I guess.