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

GoPlus – The Go+ language for data science

github.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: GoPlus – The Go+ language for data science

#41

Post by stevekemp »

maddyboo wrote: post #17

I love the idea of main-less Go scripts for times where you just want to do something simple, fast. Neugram [1] aimed to make Go a better scripting tool, but unfortunately it seems the project is dead. Although Go+ says its focus is on data science, I think it could fill this niche too. By the way: does Go+ have shebang support? 1: https://github.com/neugram/ng

Go doesn't need to have shebang support, the kernel will provide that. But for the record it will work:

        frodo ~ $ cat t.go 
        //opt/go/bin/go run $0 $@ ; exit
        package main
        import( "fmt" )

        func main() {
           fmt.Printf("Hello, world\n" );
        }

        frodo ~ $ ./t.go
        Hello, world
Otherwise there are a bunch of go-interpreters out there, which can be used for adhoc scripting. I'm sure that in some circumstances they can be useful, but I've only used them for providing extensions / scripting to host-applications, rather than trying to use them interactively.

Re: GoPlus – The Go+ language for data science

#42

Post by uryga »

dgellow wrote: post #38
maddyboo wrote: post #17

I love the idea of main-less Go scripts for times where you just want to do something simple, fast. Neugram [1] aimed to make Go a better scripting tool, but unfortunately it seems the project is dead. Although Go+ says its focus is on data science, I think it could fill this niche too. By the way: does Go+ have shebang support? 1: https://github.com/neugram/ng

> I love the idea of main-less Go scripts for times where you just want to do something simple, fast. What do you mean by a main-less script? And what would be "simple and fast" about it? If I want to try out something fast, I just do everything in a main.go and run it with "go run main.go", and that works well as a scripting language.

> What do you mean by a main-less script?

probably something that's common in "scripting" languages, where you don't have to wrap your code in main(), it just executes from the top:

  myscript.py
  -----------
  print('hi')
vs

  myscript.go
  -----------
  func main() {
    fmt.PrintLn('hi')
  }

Re: GoPlus – The Go+ language for data science

#43

Post by mleonhard »

yahyaheee wrote: post #5

I feel where they are trying to go with this, I wrote https://github.com/aunum/gold in Go because of all the nice parts of Go. This solves some of the pain points but is still fatally flawed as any other Go ML tool in that it can’t accelerate due to the Go C FFI. Until that issue is resolved Go simply won’t be broadly accepted in data science.

Would you please explain?

Re: GoPlus – The Go+ language for data science

#44

Post by ascotan »

zmmmmm wrote: post #25
WoodenChair wrote: post #10

IMHO these conveniences should just be in the language. List comprehensions, dictionary comprehensions, and short-hand for literals are the kind of syntactic sugar that have almost no downsides, save you some RSI, and make code more readable. I'm surprised comprehensions in particular haven't spread to more modern languages.

> I'm surprised comprehensions in particular haven't spread to more modern languages. I've come to dislike list comprehensions. Simple ones are ok but they do not handle incremental complexity well. Invariably it means code slowly becomes really unreadable as time goes by because nobody wants to rewrite the list comprehension when one more little tweak stuffed in there will do the job. I much prefer object-functional…

They're great until you find something like this in code:

[x for y in z for x in zz if y in x]

Then you begin to wonder how great they really are.

Re: GoPlus – The Go+ language for data science

#45

Post by mlthoughts2018 »

zmmmmm wrote: post #25
WoodenChair wrote: post #10

IMHO these conveniences should just be in the language. List comprehensions, dictionary comprehensions, and short-hand for literals are the kind of syntactic sugar that have almost no downsides, save you some RSI, and make code more readable. I'm surprised comprehensions in particular haven't spread to more modern languages.

> I'm surprised comprehensions in particular haven't spread to more modern languages. I've come to dislike list comprehensions. Simple ones are ok but they do not handle incremental complexity well. Invariably it means code slowly becomes really unreadable as time goes by because nobody wants to rewrite the list comprehension when one more little tweak stuffed in there will do the job. I much prefer object-functional…

Functional chaining (aka “fluent interfaces”) is very bad for dependency injection / mocking.

In f(g(x)) you can directly access or patch f and g as top level names.

In x.g().f() you have to patch methods internal to other structures, and this can lead to problems if the patching should only happen in a certain local scope.

I encountered this recently with differences between pathlib.Path and os in Python.

Consider

    def my_mkdir(pathname):
        pathlib.Path(pathname).mkdir()
        # or
        os.mkdir(pathname)
From the pov of testing and decomposition, the second option is much nicer, because I can patch os.mkdir directly, and not patch pathlib.Path.mkdir (and also worry about controlling when instance creation happens to use the patch when I need it, but let other possible pathlib.Path objects my tests interacts with be constructed normally). mkdir is even a very simple example since pathlib.Path.mkdir is an instance method but only relies on the string data the instance has. Imagine how much harder if pathlib.Path.mkdir has complex interaction with the internal object structure or other instance methods.

Obviously you _can_ solve it either way, but the fluent interface does nothing except require more code.

On this balance I think list comprehensions (or just fmap, which is all comprehensions are) are much, much better than chaining.

Also if you want to operate on data structures just operate on them with module functions.

I think pandas really messes up on this.

    agg(groupby(df, cols), funcs)
is way better than

    df.groupby(cols).agg(funcs)

Re: GoPlus – The Go+ language for data science

#46

Post by mlthoughts2018 »

ascotan wrote: post #44
zmmmmm wrote: post #25

Earlier quoted context omitted.

> I'm surprised comprehensions in particular haven't spread to more modern languages. I've come to dislike list comprehensions. Simple ones are ok but they do not handle incremental complexity well. Invariably it means code slowly becomes really unreadable as time goes by because nobody wants to rewrite the list comprehension when one more little tweak stuffed in there will do the job. I much prefer object-functional…

They're great until you find something like this in code: [x for y in z for x in zz if y in x] Then you begin to wonder how great they really are.

To me that looks super easy to read. You just go left to right.

    for y in z:
        for x in zz:
            if y in x:
                yield x
It’s extremely easy to sight read. If the lines become long, just split them up and it’s even more obvious.

    [x
     for y in z
     for x in zz
     if y in x]
There’s nothing tricky about multiple loops and conditions in comprehensions in most languages that support them. Just go left to right and it mirrors outer to inner loops/conditionals.

Re: GoPlus – The Go+ language for data science

#49

Post by _3sno »

BiteCode_dev wrote: post #39
zmmmmm wrote: post #25

Earlier quoted context omitted.

> I'm surprised comprehensions in particular haven't spread to more modern languages. I've come to dislike list comprehensions. Simple ones are ok but they do not handle incremental complexity well. Invariably it means code slowly becomes really unreadable as time goes by because nobody wants to rewrite the list comprehension when one more little tweak stuffed in there will do the job. I much prefer object-functional…

This assumes some_giant_list is an object that has "findAll", that "findAll" returns and object that has "groupBy", which returns an object that has "countBy". Looking at that code, I don't even know what the intermediary objects are, but given the names of the operations, they can't be all flat lists. Besides, you may not put your list comprehension inline. It is often more readable to make it span on several lines,…

This is exact how I write mine, I find it much more readable personally.

The real challenge I've encountered is typically you can only use one expression. If I need to write a slightly more complex mapping I am forced to write a function, which I normally define just before the comprehension. Even though this works, it introduces boilerplate I'd rather not write.

I will admit this doesn't happen often, but it happens enough to bother me.

> This assumes some_giant_list is an object that has "findAll", that "findAll" returns and object that has "groupBy", which returns an object that has "countBy".

> Looking at that code, I don't even know what the intermediary objects are, but given the names of the operations, they can't be all flat lists.

In regards to this, I would say sure, but does that really matter. Most IDEs will give you enough inference to list the operations you can perform and the return types they give. If anything the "super collections" make a developers life far easier, I think Kotlin does a particularly good job of this with a vast set of extension functions. Have a scroll of this documentation https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti... mapIndexedNotNull is a great example

Post reply on HN