News for hackers. Stuff that matters.
Re:Lily: An interpreted language with a focus on expressiven... by koube on Thursday July 19, 2018 @01:17PM (#17568456)
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, or some kind of prechecking so I don't lose hours of processing to a print(str+int).

I took a look at Scala but instead of virtualenv style dependency management it's more like maven projects. It has Ammonite where you can declare dependencies at the top of files but that seems kind of hacky.

The other option is Python compile time checks using type hints and mypy, which I think I should eventually learn but haven't gotten around to.

The Lily language looks like the closest thing to "functional type checked python" that I've seen and that's cool.

Re:Lily: An interpreted language with a focus on expressiven... by the_duke on Thursday July 19, 2018 @01:37PM (#17568645)
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 run-cargo-script
    //! This is a regular crate doc comment, but it also contains a partial
    //! Cargo manifest.  Note the use of a *fenced* code block, and the
    //! `cargo` "language".
    //!
    //! ```cargo
    //! [dependencies]
    //! time = "0.1.25"
    //! ```
    extern crate time;
    fn main() {
        println!("{}", time::now().rfc822z());
    }
Then you can just execute it with ./my-script, which will download dependencies, compile and execute.
Re:Lily: An interpreted language with a focus on expressiven... by dmux on Thursday July 19, 2018 @03:41PM (#17569611)
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"
Re:Lily: An interpreted language with a focus on expressiven... by blattimwind on Friday July 20, 2018 @05:34AM (#17573621)
Re:Lily: An interpreted language with a focus on expressiven... by arcticbull on Thursday July 19, 2018 @09:42PM (#17571830)
Thanks for sharing that, I had no idea. You just improved my day.
Re:Lily: An interpreted language with a focus on expressiven... by joshbaptiste on Thursday July 19, 2018 @01:26PM (#17568553)
Have a look at https://nim-lang.org .. you might like it
Re:Lily: An interpreted language with a focus on expressiven... by FascinatedBox on Thursday July 19, 2018 @07:19PM (#17571204)
Author here. That's roughly what I was shooting for. Python was a big inspiration early on in the design, and later on some functional concepts were put into the mix. I found them and liked them too much to pass up on.

One advantage of Lily not mentioned (with regard to typing), is that the type-checking is very fast. One of the reasons I made Lily interpreted and homebrewed all the parts was because as much as I like static typing, it's often slow. Slow static typing, I think, diminishes some of the value of it since you're still waiting but in a different way.

Re:Lily: An interpreted language with a focus on expressiven... by weberc2 on Thursday July 19, 2018 @01:34PM (#17568623)
Linters should catch most typos; failing that, Python's type hints are a pain to use, but you can address a lot of low-hanging fruit for free.

I think for your use case though, Go would be perfect. Everything is statically compiled, so you don't need to mess with virtualenvs, and everything is statically typed ahead of time. I'm a professional Python developer, but I often do my prototyping in Go because the type system is more ergonomic than Python/mypy.

Re:Lily: An interpreted language with a focus on expressiven... by totalperspectiv on Thursday July 19, 2018 @04:54PM (#17570173)
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 expressiven... by jitl on Thursday July 19, 2018 @04:16PM (#17569856)
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 expressiven... by lmm on Thursday July 19, 2018 @04:17PM (#17569863)
> 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 expressiven... by mratzloff on Thursday July 19, 2018 @09:13PM (#17571735)
HN reads as: "Hey everyone, get in here and post your favorite language!"
Re:Lily: An interpreted language with a focus on expressiven... by rishav_sharan on Thursday July 19, 2018 @02:03PM (#17568858)
Nim lang. Nothing would beat it if you like python
Re:Lily: An interpreted language with a focus on expressiven... by anon2657300168 on Thursday July 19, 2018 @04:18PM (#17569868)
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 expressiven... by EwanToo on Thursday July 19, 2018 @01:30PM (#17568594)
Depending what you want, using

go run source.go

gives you the compile time checks, while still giving you the source code visibility and simplicity of scripts

Re:Lily: An interpreted language with a focus on expressiven... by koube on Thursday July 19, 2018 @01:44PM (#17568713)
I took a look at Go but it seems to be more of a systems language than a scripting language and I assume that means it's less amendable to "This guy across the country needs this information in 2 hours max".
Re:Lily: An interpreted language with a focus on expressiven... by zaphirplane on Friday July 20, 2018 @07:47AM (#17574197)
People say that about Go while I don’t have an opinion. I don’t understand what you mean by your example
Re:Lily: An interpreted language with a focus on expressiven... by koube on Monday July 23, 2018 @02:55AM (#17590988)
The point of my example is that my main priority is coding speed, and other things are an issue only if processing takes a long time. A systems language typically has a much slower coding speed than say, python, which is what I mainly use now.
Re:Lily: An interpreted language with a focus on expressiven... by falcor84 on Thursday July 19, 2018 @02:04PM (#17568866)
I suppose that print statement was just a silly example, but just in case this may be of use to anyone, note that you can pass multiple arguments to print and they will be printed space-separated, each converted to a str, so you will (practically) never run into type errors.

print(str, int)

Re:Lily: An interpreted language with a focus on expressiven... by koube on Thursday July 19, 2018 @02:36PM (#17569140)
True, that's a problem I don't have anymore but it's a quick and understandable example of a mistake that I think lots of people had made before.

Instead of a comma I would actually recommend f-strings, which are python's string interpolation. The only downside is that the code within the f-strings I think have even less prechecking.

https://www.python.org/dev/peps/pep-0498/

Example: print(f"There are {len(lights)} lights!")

Re:Lily: An interpreted language with a focus on expressiven... by falcor84 on Monday July 23, 2018 @05:19AM (#17591522)
I absolutely agree that f-strings are excellent for formatting, but I don't quite understand why you would use formatting in a regular print statement, when you could just stick to the commas and let the concatenation happen naturally in the output buffer?

print("There are", len(lights), "lights!")

Re:Lily: An interpreted language with a focus on expressiven... by bvrmn on Friday July 20, 2018 @01:08AM (#17572634)
You can look at https://nim-lang.org/