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

21–30 of 55 posts

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

#21

Post by derriz »

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 of a value corresponding to a key in a map (is it really exceptional for this to happen?) is a textbook example of exception-abuse where the code is obfuscated by the non-locality of the control flow.

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

#22

Post by enitihas »

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…

Well, for good or for bad, python does the same.

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

#23

Post by jitl »

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,…

Take a look at kscript, which is a single-file wrapper around Kotlin that includes dependency specification in the script file: https://github.com/holgerbrandl/kscript

Example:

    #!/usr/bin/env kscript
    // Declare dependencies
    @file:DependsOn(“com.offbytwo:docopt:0.6.0.20150202“)
    import org.docopt.Docopt
    val usage = “...”
    val doArgs = Docopt(usage).parse(args.toList())

    println("Hello from Kotlin!")
    println("Parsed script arguments are: \n" + doArgs)

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

#24

Post by lmm »

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,…

> I took a look at Scala but instead of virtualenv style dependency management it's more like maven projects.

You could do virtualenv style by setting the CLASSPATH environment variable if you really want. The ecosystem tends to prefer using explicit dependencies though.

> It has Ammonite where you can declare dependencies at the top of files but that seems kind of hacky.

Sort of, but I don't think you'll do better anywhere else. Lots of other replies are suggesting various languages that do essentially the same thing - a magic comment at the top of the file that declares your dependencies.

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

#25

Post by anon2657300168 »

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,…

I'm currently learning shelly haskell library. I tried to write a function in a haskell-emacs module and calling it as a elisp function in a eshell buffer and it worked flawlessly first try.

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

#26

Post by bpicolo »

enitihas wrote: post #22
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…

Well, for good or for bad, python does the same.

To be fair, there's utility to avoid it: check first or do a .get(). That helps you be expressive about what you think should/should not exist

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

#27

Post by cpeterso »

enitihas wrote: post #22
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…

Well, for good or for bad, python does the same.

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.

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

#28

Post by totalperspectiv »

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,…

If you're writing a lot of command line scripts and want some of the safety offered by types, but still want the flexibilty of python (+ more flexibility), you should check out perl6.

Gradual typing: https://perl6.party/post/Perl-6-Types--Made-for-Humans Command line arguments: https://perl6advent.wordpress.com/2010/12/02/day-2-interacti...

And at the end of the day it's perl, so it's the king of command line scripts.

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

#29

Post by wool_gather »

cpeterso wrote: post #27
enitihas wrote: post #22

Earlier quoted context omitted.

Well, for good or for bad, python does the same.

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)

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

#30

Post by [deleted] »

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…

[deleted]
Post reply on HN