Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lily: An interpreted language with a focus on expressiveness and type safety

lily-lang.org

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#41

Post by Quelklef »

wool_gather wrote: post #29
cpeterso wrote: post #27

Earlier quoted context omitted.

You can use dict's get() method to get back a None for missing keys instead of throwing a KeyError exception. That avoids the overhead of checking `if key in dict` or catching KeyError.

Another option, it's very easy to wrap a dict in a defaultdict: class optionaldict(defaultdict): """ A defaultdict that disregards KeyErrors and returns None for missing keys. """ def __init__(self, *original, **kwargs): super().__init__(lambda: None, *original, **kwargs)

This is almost always a bad idea, though; it doesn't distinguish between

    {k: None}[k]
and

    {}[k]

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#42

Post by bvrmn »

wool_gather wrote: post #29
cpeterso wrote: post #27

Earlier quoted context omitted.

You can use dict's get() method to get back a None for missing keys instead of throwing a KeyError exception. That avoids the overhead of checking `if key in dict` or catching KeyError.

Another option, it's very easy to wrap a dict in a defaultdict: class optionaldict(defaultdict): """ A defaultdict that disregards KeyErrors and returns None for missing keys. """ def __init__(self, *original, **kwargs): super().__init__(lambda: None, *original, **kwargs)

It's not a generic option, you are polluting memory with non-existing keys.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#43

Post by [deleted] »

the_duke wrote: post #7
koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

It was weird for me at first, but actually Rust provides a great solution here. With https://github.com/DanielKeep/cargo-script you can have single file Rust "scripts" with ecosystem dependencies. When executing the file (via the cargo-script wrapper), dependencies are fetched and a binary is compiled on demand (and cached for re-runs). It's pretty awesome for scripts where type safety is important. #!/usr/bin/env ru…

[deleted]

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#44

Post by bvrmn »

koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

You can look at https://nim-lang.org/

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#45

Post by wruza »

I wish we had humane keyboards with special symbolic row (or two), since this:

  ["+" => (|a: Integer
  split(" ").reject(|r|
  stack: List[Integer]
is a shift-hell challenge to type it. Most of my unproductivity goes from being tired of mistyping or too concentrated on precise shifting. Even $150 keyboards go with classic/tkl layout at most; no chance unless going handmade.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#46

Post by simen »

derriz wrote: post #21

I read the first example of Lily on the site. I found nothing offensive in the language at all - in fact there's a lot to like particularly the readability. Side rant. Unfortunate I can't get past the decision to use exception handling to deal with non-existing keys in map. I'm of the exception-disliking school which is thankfully growing but I guess not yet universal. For me using an exception to indicate the lack o…

> For me using an exception to indicate the lack of a value corresponding to a key in a map (is it really exceptional for this to happen?)

Sometimes it is, sometimes it isn't. Most languages allow you to choose whether you want a hash to throw a key error on non-existing keys or return a signal value. My favorite is the uber-flexible approach and nice syntax in Crystal:

  hash[foo] is sugar for hash.fetch(foo)

  hash[foo]? is sugar for hash.fetch(foo, nil)

  hash.fetch(foo) will return the default value of the hash table on nonexistent keys if one was assigned, otherwise raise keyerror

  hash.fetch(foo, nil) will return nil on nonexistent keys

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#47

Post by steveklabnik »

Ar-Curunir wrote: post #40
staticassertion wrote: post #36

Earlier quoted context omitted.

Rust makes a similar decision, despite having Option and Result. If you want the Option behavior, there's .get() Anyways, very cool looking language.

But from what I've seen, most idiomatic Rust code doesn't use the `map[key]` syntax, but instead uses `map.get(key)`.

We must look at very different code :)

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#48

Post by blattimwind »

dmux wrote: post #20
the_duke wrote: post #7

Earlier quoted context omitted.

It was weird for me at first, but actually Rust provides a great solution here. With https://github.com/DanielKeep/cargo-script you can have single file Rust "scripts" with ecosystem dependencies. When executing the file (via the cargo-script wrapper), dependencies are fetched and a binary is compiled on demand (and cached for re-runs). It's pretty awesome for scripts where type safety is important. #!/usr/bin/env ru…

Likewise with Apache Groovy, which has optional typing: #!/usr/bin/env groovy // @Grab annotation won't work in scripts import static groovy.grape.Grape.grab grab(group: 'org.apache.commons', module: 'commons-csv', version: '1.5') println "Starting to parse CSV"

Kotlin can do it, too: https://github.com/holgerbrandl/kscript

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#49

Post by Narishma »

blattimwind wrote: post #15
nickpsecurity wrote: post #11

Earlier quoted context omitted.

Oh yeah, my mistake. I should've said predictable, not efficient. I remember people liked it to avoid long pauses coming out of nowhere.

With (naive) ARC you can still get long pauses "seemingly out of nowhere", e.g. when a large object tree goes out of scope.

That's not out of nowhere, since you have exact control over when it goes out of scope.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#50

Post by Narishma »

weberc2 wrote: post #8
nickpsecurity wrote: post #2

Prior art like Wirth's or Modula-3 language added a minimal amount of features like exceptions or some OOP on top of simple, efficient, systems languages. Usually have a GC but many prefer ref counting for efficiency. This seems like that kind of thinking in an interpreted language. Just going by what's on the front page: didn't dig deep into it or anything. Interesting project.

Reference counting isn't more efficient than GC; usually the value of reference counting is that it's deterministic and you can bind finalizers to them (with traditional GC, finalizers run when GC runs which may not even happen). The canonical example is a file object that closes its operating system file when the object is no longer used; this is nice in theory, but as the Python folks found out, not a good substitu…

> Reference counting isn't more efficient than GC

Isn't it more efficient in terms of memory usage?

Post reply on HN