jesserayadkins2

My language (Lily) handles the problem by trying to avoid the gc where it can.

Lily is statically-typed, built-in classes can't be inherited from, and there's no C-like casting.

With those rules in mind, most objects can't become cyclical. It's impossible for a list of strings to loop back onto itself, for example. It helps that the value classes backing enums (like Option and Either) are immutable, which I so far suspect prevents a cycle.

That at least allows you to group classes into three groups:

These never cycle (Integer)

These may cycle (List)

These always cycle (Dynamic, linked lists?)

It has good intentions, but it might make someone ask themselves if the boss thinks that their use of colors needs to be changed. If it was a good choice, then why bring it up, they might ask themselves.

I have a github account established, and it has a couple of projects on it. One, a telnet client, is missing. I keep forgetting to add that in. I've been meaning to, once the language is more established, to spread the packages out into different repositories.

I know I should have more of a variety there, the trouble thus far has been the 'what'.

I was diagnosed with Aspergers early on in life. For a long time, I tried to ignore it. But there's parts that you can't. It's difficult to make friends when you can't read people's intentions or read between the lines. I don't have a great interest in hanging out with people because I often don't feel like I fit in.

In my teenage years, it meant that I was a loner who went home at the end of a school days, played games by myself, and that was it. In my adult years, it's been much more difficult.

My background is a complete mess. I got a degree in Computer Networking because programming wasn't available, and then later went on to work retail for several years. In the meantime, I kept working on programming projects.

On the programming side, I have a 5 year project where I built everything myself, and a handful of 1 year projects, most of which the source code has been lost for.

Trying to get jobs in the industry is a joke. Take a look at the above, and you'll see someone who isn't normal, isn't average. I send resumes off and I get "We don't think you'll be a good fit" or ignored. That right there is what hurts the most. I could accept getting interviews and failing them, but being outright rejected before being given a chance, that flat hurts.

I've got a lot of traits that come from Aspergers too. I don't have an interest in much besides computers, so I often spend entire days at home and coding or thinking about coding problems. Doesn't bother me to spend 12+ hours in a day just coding.

Horrible at eye contact, and don't know why. Monotone voice? Check. Sometimes I'll mean to say one word and say another without realizing it, or focus on someone's meaning in one part and miss the others. I don't have that rage though. Used to when I was younger. But the computer doesn't care if you get mad, and it's better to just let logic take over.

I've still got my fingers crossed that I'll find a place that will give me a chance. But if I can't find that, then I'll shrug my shoulders and go back to working retail.

Multiple return values I'm not very interested in. Lily has first-class tuples, and you can return a tuple which I might later add in desugaring for. But multiple return values themselves cause a lot of problems with the internals being pretty set on 0 or 1 return.

Macros are a hard no. DSLs, maybe. For the latter, I could see allowing a pluggable import handler through Lily's options. But I'm reluctant to commit to a yes or no on that at the moment, since I'd rather get over the hump of api not being fully fleshed out.

No, I'm just terrible at making up examples so cats! Cats everywhere!

I can't seem to find it. Am I missing something?

Thanks!

I started Lily to be an alternative to PHP. The first commit was adding templating support, and it was a while before the language could be standalone.

I had two requirements when creating and designing Lily:

One, that the language had to be interpreted. I didn't want to offer people an alternative to PHP but then tell them that they would need to repeatedly run compile passes over it. Facebook has HipHop, and it transforms PHP into C++. I wanted a language that could be used like PHP, but having a faster interpreter wasn't enough.

The other requirement was to have a statically-typed language. I believed that a statically-typed language would lend itself to better transformation into a lower-level language. In theory, an llvm frontend might also be writable that took Lily as input.

I wanted Lily to outperform PHP both when interpreted, and when compiled. Over time, the focus broadened once I realized Lily's low memory usage, and how fast the turnaround of the parser is.

I couldn't think of a good name. I had ideas of something like Meteor or Hurricane or Tornado. The first was taken, and I -very- quickly had second thoughts about the other two.

My mom, from time to time, mentioned that she really liked the name Lily. After giving it a lot of thought, I said, "You know, why not go with that?"

I've grown to like it.

This is a big problem in the language now. There's no solid apis for working with the frontend (invoking the parser and getting a result). The backend apis are acceptable, except that it's difficult to move values around.

I'm a couple of weeks away from the end of a three month release window, so I've (for the moment) given up on trying to finish the apis. But I'm not far from having them done. A month, maybe?

But after that, I'll write a guide on how to embed Lily, and how to extend it.

For the moment, your best bet if you're creating a standalone package like postgres is to refer to how postgres structures the dynaload table. If you're looking to embed the interpreter, it's awkward and hard.

Once this release cycle ends (July 10, Lily's true 5 year anniversary), it's the first thing on my list. I want to give people a solid api so that other people can start building stuff and not have to worry about me breaking it.

First the api, then the tooling, then documentation. You've got my word on that (and HN won't let me delete this, on top of that).

It's probably possible, especially with today's compilers being smarter about using those instructions. You're right, in that concat is currently only available through interpolation.

At the moment, I'm not interested in adding vectors or SIMD. It's something I might try further down the line, but not now.