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.

Thank you!

As for me, I'm not so sure what to share. I'm not all that exciting. Most of the time I have I spend on Lily. Once in a while I take a break. But I don't get out that often. Lily's nice in that it's a place for me to do something and feel like I make a difference.

My day job? For most of the time that I worked on Lily, I was working part-time at [redacted] as a Maintenance Assistant. My favorite memory was talking shop with a guy there who had some computer knowledge. He asked what I had done and I told him that I had just written a garbage collector and that it was so awesome because it took just a week and it went well.

He answered me saying something to the effect of "Well of course you wrote a good garbage collector, you're Maintenance! That's what you do!" We both had a good laugh at it.

I've never had a job doing software development. I recently left [redacted] to pursue a job in software, but haven't had much luck with it. I'm still holding out hope though.

So, no, my job isn't programming related.

Resources? My strategy is that when I get up to something new, I do all of the research that I can both in the topic itself, as well as how other languages do it. One example would be Exceptions. I didn't know how to do that, so I started researching how Python did it, how Java did them, Ruby, etc. I started thinking of what I wanted, and also what the goal of having them in my language was. I also made sure to search through Haskell, Scala, Rust, and OCaml since they don't use exceptions as much. The point being that I wanted to know what languages do when they tend to not use exceptions.

Rather than starting off as "This is a good idea", I instead approach it as, "I think I would like X. How does that typically get done?"

For resources, the most helpful thing I've read has been ESR's guide on struct packing:

http://www.catb.org/esr/structure-packing/

I'm afraid not much else comes to mind though.

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.

That's a good question, and unfortunately one that I'm at a loss as to how to answer right now. I've been focused more on building it, and less on using it. However, I've been looking to change that lately now that the core is becoming more stable and usable.

I owe ESR a lot for writing about struct packing, because that's a large part of how Lily uses so little memory:

http://www.catb.org/esr/structure-packing/

Const is something that I'd like to think over before adding it. A question I have is what happens if a List is const, or should it just be that only primitives are const? I could see const values being optimized as just literals down under the hood, which would be nice for performance.

I'd have to have a long, long think before adding operator overloading. It's got uses for math, but thus far I've been reluctant to add features that can be abused or used improperly like native class dtors or finally.

First of all, thank you! As for what motivates me, it's a few different things:

* The challenge of it. Lily's one of the few things that I've done where I feel really challenged, and where I can actually make a true difference in it. It gives me something to do, something that I can always be refining and thinking about.

* I -strongly- believe there is a market for this. I want to see this used in game development, used in server development, and used standalone. It's really, really fast scripting language with static typing that brings a unique blend of features that allow for terse code. I want to eventually port this to Arduino, just to say that I did it (Lily boots in 6K with 64-bit pointers, so I think it's possible).

* It's something that I can put at the top of my resume.

* I balance what I do. You might see me spend a week doing plumbing work in lexer, and the next I jump around and patch different places in emitter. I try to not stick in any one area too long. If I do a feature that's difficult and takes a long time, I balance that out with what I term "candy". Candy, in this case, being something that's more immediately visible. I added the constructor shorthand syntax shortly after doing type erasure. Type erasure took a month, and I was a little burned after that. So I balanced it out with a feature that was easier, and had a more visible effect on the language.

* Once a week, I'll go over what I've done, and sort of pat myself on the back, and also think of "Alright, X is done..." and it always goes to "So what's next week?" There's never been a "I'm done". Honestly? The first two years were the hardest, because I didn't have a product that I cared much for. These last three have been easier, because I'm excited about what I'm doing, and there's a more broad spectrum of what I can do.

* You all. No, seriously, I'm finding myself more often talking to different communities about what I've done. I talked to 4chan's /g/ last night. Sometimes I talk to different boards on Reddit, sometimes I try to talk here. I tried Slashdot once, but they didn't bother to even approve the article. Some people give crummy comments, but seeing the new stars, seeing people say they're willing to try the language, that means a lot to me. I really enjoy engaging people when it's over text about what I've done, since I'm comfortable when talking over text and I don't get RL opportunities to talk about what I do hardly ever since I don't know anyone personally RL who does coding for a living, and I'm a pretty stay-to-myself person.

There's no operator overloading. I'm pretty reluctant to add it too, because I've seen it be abused far, far too many times. It has uses, yes, but I'm not very interested in it at the moment.

I won't say absolutely no to it, but if it were to be added, it wouldn't be right now. There's too much api that needs doing right now.

No traits yet. A few other things need to be done first. Generics need to be name-able, System F, and core api is a more pressing need right now.

My plan is to tackle traits in a few months, so long as everything goes well. But I want the above stuff done first, so that when I do traits I can start thinking about higher kinded types, trait inference, and the like.

To my understanding, Swift wasn't public for a long time. The idea behind requiring a special syntax for interpolation is that it's supposed to be more clear as to do you really want interpolation, or do you not actually want it. I'm :/ about the interpolation syntax right now. One thing I wanted to avoid is telling people "oh no your string never terminated."

You're right about reference counting being able to pause. But that's something you're more able to control. If you're doing game dev, you can say "I won't assign to references that might be big" during frame critical code.

With garbage collection, you're more or less "Run the gc before, hope it doesn't trigger during that critical spot." or the alternative of fiddling with the gc/manually firing it off so it doesn't stop your world when it's a bad time to stop the world.

No, there's only one constructor for any given class. The body of a class is the constructor of a class, and that constructor is made available through a method called .new. It's sort of like...Python, and imagining that you get __init__ created for you automatically. It's just two ways of doing the same inner call.

They're the same thing. The first (Cat(arg)) is the same thing as the second (Cat.new(arg)). The reason for the distinction is...umm...I'm still not sure if I want to eventually include classes as values the way that other things are values.

If you're grabbing the constructor as a function, for example, then it's a bit more sensible to use Cat instead of Cat.new. I don't know...it seemed at the time neat to allow a shorthand way of constructing something, but it's kinda wonky.

I've heard a few complaints about this now, so I'm thinking of changing it. I wanted to cram a lot into a small space, and it didn't do so well.

The piping is more an example of how piping works with everything and that, yes, the new method really really is a method instead of some magical keyword.

But I stand by piping: https://lorgonblog.wordpress.com/2008/03/30/pipelining-in-f/

Actually, no, I've never used C# except for a few minutes and only one time. I have more experience with the syntax of Scala and Rust. Between the two, I found Rust's more appealing. I like that enums serve a single purpose and can't be inherited.

Currently, the best you can get for iteration of Lists and Hashes is to do each-ing the way you'd go about it in Ruby, except that the language currently lacks iterators.

That's not to say I don't want iterators. But I've spent a huge amount of time of this release in making sure that all of the built-in classes get dynaloaded so that memory usage stays low. Now that everything's getting dynaloaded properly, I've less of a problem with doing iterators.

Thank you! I've spent a great deal of time on it. As for that module, I admit that it's pretty bare-bones (so is postgres). Both were made as a proof-of-concept, to be fleshed out at some later point in time.

Header support was, at the time, something I didn't know quite how I wanted done, and was thus left out. I will, at some future time, add in header support.

I would also like header support. Perhaps during the next release (which should start some time in July), I can get around to putting that in. One of my original goals was to get Lily usable on Apache, and I've gotten far distracted from that.

Neat tool, but the results are disappointing for me. :(

What's even worse is that it's not even a good Ruby like Crystal. It seems to be missing any sort of callable object (can't find any mention of a proc, a block, or a lambda in the website documentation). So consequently there's no select, reject, each, or really any sort of mapping in the standard library (unless it's buried or I missed it).

I'm biased in the matter, but I have to agree. There are a number of problems with it.

Arrays are covariant, and object is the base class of everything. I'm surprised that nobody's noticed that already (it's unsafe: arrays should instead be invariant).

It doesn't seem like there are any first class functions, and there's no tuple class either. I don't find any mention of mapping/selecting/reducing within standard collections.

For all (heh) the boasting about the type system, covariant arrays produce other problems too. If you have a function that takes an `Array[nullable Int]` and send it `Array[Int]`, the type system doesn't say anything about it. That means you could get into problems down the line. It's also possible to take a nullable Int and do `.as(Int)`

`var v = 1 / 0` causes FPE and core dump and dumps an ugly compiler stack trace.

The documentation about abort also mentions that there's no stack trace for it.

I don't think there are standalone functions with generic typing either, just classes with generic types. I suspect that their virtual types are probably unsound, but haven't tried working with them.