Why Go for decision trees? (2013) | Hacker News Reader

Why Go for decision trees? (2013)

datascience.systemsbiology.net

36 pointsrgbrgb34 comments

Hah, I wrote this article ages ago when we were experimenting with a data science blog. Surprised to see it pop up here.

I think most of it still holds true but we did do some benchmarks on public data and the implementation is competitive with or faster then other implementations including scikit-learn's cython implementation which wins a lot of benchmarks.

Code and some benchmark results in the README are here: https://github.com/ryanbressler/CloudForest

I submitted it because I'm playing with CloudForest right now. I really appreciate your work, it's fun to use.

I'm co-founder of a digital real estate brokerage[1] and as a weekend hack, I'm using CloudForest to predict sale prices for residential real estate using data from the MLS.

A lot of the predictions are really good with a few that are terrible (like double the list price, which is a feature). Any way to get a certainty value for each prediction? Perhaps I could look at the variance of values from each tree? I'm kind of a noob with decision trees so I'm probably totally off base but maybe that question makes sense. :)

[1]: https://www.openlistings.co/ (YC W15)

Yes, you should be able to estimate a confidence interval by looking at the distribution of votes from each tree.

[1] http://arxiv.org/pdf/1311.4555.pdf

It sometimes raises eyebrows, but this sort of post is why I classify Go as a modern take on a scripting language. With GC and interfaces standing in for duck typing, it's got a lot of the good characteristics of the scripting languages, but it's also got just enough low-level performance stuff going on (real structs, real arrays, the slices the blog post mentions) that rather than taking the 50-100x hit you can easily take with Python you can take merely a 2-3x hit over C, and you'll write the code significantly more quickly than C or Rust too. The result is that where you might not need something that allows you, and correspondingly, requires you to deal with all the issues of memory management or ownership that C, C++, or something like Rust may, but you might not be able to afford Python's performance issues or the general difficulty the scripting languages have with true concurrency and multicore, you have a viable choice in Go.

Go's not alone... it seems to me there's many languages taking a swing at this niche now. All the best to all of them... I love me the flexibility of Python or Ruby sometimes and may not need total system-level control but I can't always afford the resource gluttony of the older-school scripting languages.

This development/trend seems to show that the value of the "dynamicity" of scripting languages have perhaps been overrated. There seems to be a set of abstractions with reasonably/very good mechanical sympathy that are both easy to understand and use, and that doesn't constrain you that much with regards to factorability and coding iteration.

For me it seems to be hitting that niche of "one off" programs that have a nack for sticking around forever. Once I figure out something needs to become software and not be truly one off, then I find myself reaching for Go.

If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated.

Another kind of typing system is a mixture of dynamic and static typing named: gradual typing (PHP/Hack, JS, ActionScript, etc.) http://en.wikipedia.org/wiki/Gradual_typing

There is also the difference between strong and weak typing: http://en.wikipedia.org/wiki/Strong_and_weak_typing

It's certainly possible that there was a time when virtual machine based language implementations where overrated.

I didn't really mean dynamic typing (that's why I wrote "dynamicity" with question mark).

To be clearer: the ability for things to change at runtime, i.e. for the programmer to do things like monkey patching. I guess dynamic typing is related to this, at least in the sense that you'll have to give up on some static typing in order to get more flexible dynamic behaviour.

And yeah, I realize that Python et. al. is used for real apps, and certainly not just for scripting tasks.

"If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated."

I think that's actually a very important aspect of understanding where dynamic typing as a hugely popular thing came from. Today, I favor static typing. However, given a choice of Python or 1990s-C++, I'll take Python. It could be argued that the static typing world needed to be dethroned and be forced to improve itself in the face of the dynamic competition to become what it is today.

On the other hand, pretending that "static typing" is the same today as it was 20 years ago is merely the complementary failure that people too bedazzled by static typing 20 years ago and dismissed the oncoming dynamic typing wave made.

The real value of dynamic languages can only be realized in dynamic, image-based, live programming environments like the kind you have with Lisp and Smalltalk.

Whether "scripting" languages, as in languages used to write small, one-off programs, or programs to automate systems administration tasks or to glue other programs together, benefit from that type of power is debatable, but Ruby, Python, and Perl have never been particularly good representatives of the dynamic language paradigm as a whole, either conceptually or implementation-wise.

> like the kind you have with Lisp and Smalltalk

...and PHP and JavaScript

There's a reason that I wrote 'scripting languages' instead of dynamic languages. Python, Ruby etc. seem to be more regarded as scripting languages than Lisp and Smalltalk.

For a scripting language, Go is very strict with compile-time errors that could just as well be warnings. Unused variables, unused imports, dead code, etc. Other than that, I could see Go as a pretty useful scripting and systems language.

In case anyone else is wondering why doesn't the Go compiler have error ignore flags for scripting/prototyping purposes:

http://weekly.golang.org/doc/faq#unused_variables_and_import...

This middle ground is also why I think Go would be/is a great learning language at colleges or in general.

You've got something which has a lot in similar with dynamic languages, doesn't require much to learn Hello World (in comparison to Java), but has higher-level features like GC, first-class functions, etc. You also learn something C-ish in pointers which you might be aware of but not truly know in dynamic langs. Concurrency is only a benefit.

It is a really simple language that anyone can learn quickly and then take that knowledge higher level with a Python or even Clojure or Haskell or lower level with a C.

Is anyone aware of Go being used as a teaching tool in an academic environment?

Another view is that things like GC sacrifice low-level performance stuff (you reference not having total system-level control) while the similarity to languages like C sacrifices some of the good characteristics of scripting languages.

All of what you said about performance could just as easily be said for modern implementations of Common Lisps. SBCL, for example, fairs quite well against Go despite being much more dynamic than either Python or Ruby: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Not as well when we use more than one core:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

I wonder if that would still be the case against commercial Lisp compilers like Allegro Common Lisp.

Using the term "scripting language" for either Go or Python is a complete misnomer.

Back in the day, languages called as such where so slow, that there was a feeling that they were used "in lieu" of "real" programming languages. They were there to extend "real" software.

Today? Much the opposite. Computing power is almost always cheaper than brain power, and we use C to extend Python rather than the other way around.

For that matter, I think Go is great for networked infrastructure, but bad for interfacing with other languages and still significantly harder to learn than Python, Julia and R.

That is why I caution on the use of Go in projects which have "scientific" bent to them...

Go is way easier to learn than Python for real applications. Python might be easier for your first few times playing with a programming language, but the complexity ramps up fast. There are a lot of features in python - classes, decorators, all the __foo__ stuff... I think it's a lot easier to understand all of Go than all of Python.

I can't comment on R or Julia, since I haven't used them, but I would doubt they're simpler than Go.

I understand pushing back against the idea that Go is a scripting language.

Arguing that Python isn't a "scripting language" is a complete waste of time. That ship sailed at least 5 years ago, if not 15.

And Python is still very, very slow, and very difficult to make multicore (if you disagree, compare with Go), and there are plenty of domains where it should not be chosen as a result. Yes, I know about PyPy, but that project's performance characteristics are very strange and certainly isn't "it just speeds up Python code by 10x, all the time"... sometimes it does that, sometimes (rarely) it slows it down, mostly it does something in the middle that certainly doesn't bring Python anywhere near C.

For me, a scripting language is used to extend a larger more inflexible software project. Like scripting in Office Suites, Blender or similar.

Python is growing in popularity, and in the majority of cases it is used as the "primary" language now. That's why "scripting" is a misnomer, even if technically CPython is not compiled to machine language.

We need generics!

Don't know if the link was at a different place earlier, but it's now at: http://datascience.systemsbiology.net/data-notebook/

Thanks, we've updated the URL to that.

why go?

why is go being so heavily featured on HN lately? reminds me of that effort to ask a ton of R questions on stackoverflow.

We should have more stories about languages people actually get paid to use, like java!

jk (kind of)

Unlike some other languages I won't name this isn't astroturf, a fair number of people are using Go as an alternative to C++ or Java or Node.

i'm paid to write go :)

I wonder how many here are in your boat

If you are lurking on hacker news to improve your productivity, I think you're in the wrong place ;-)

If you think so, submit interesting posts about those ;)

New and shiny always has an edge in getting interest

I've been paid to write go for the last two years :). From the articles I've read, a lot of companies are starting to use go for part of their systems.

Reply on news.ycombinator.com