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

Underscore.go

tobyhede.github.io

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Underscore.go

#51

Post by pjmlp »

Daishiman wrote: post #43
shantanubala wrote: post #40

Earlier quoted context omitted.

It depends on the level of abstraction with which the language was designed. Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications. JavaScript was designed for the web to make authoring interactive pages easier. The web benefits as an ecosystem to have com…

A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system. Seriously; LuaJIT achieves greater performance and has more abstractions in place; Rust fills the niche of systems programming languages easily . I just fail to see th…

> A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system.

- Mesa/Cedar (Xerox PARC)

- Modula-3 (Compaq/Olivetti)

- Oberon/Active Oberon (Swiss Federal Institute of Technology)

- Sing# (Microsoft Research)

- D (Digital Mars)

Re: Underscore.go

#53

Post by Dewie »

shantanubala wrote: post #40
Daishiman wrote: post #28

Earlier quoted context omitted.

It seems that enough people are tired of such a verbose idiom in 2014 to merit a library like this. I really dislike being that guy, but there's no reason why a language, today, shouldn't implement a decent map shorthand construction. For loops and unnecessary visual burden for a large variety of tasks and give no hint to the semantics of the code within a loop (is my loop doing a map, a transform, a reduction?).

It depends on the level of abstraction with which the language was designed. Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications. JavaScript was designed for the web to make authoring interactive pages easier. The web benefits as an ecosystem to have com…

> It depends on the level of abstraction with which the language was designed.

> Go was designed for systems programming, and the code is intentionally verbose. A few extra characters, brackets, and syntactic constructs are a small price to pay for more control in performance-critical applications.

Rust offers more fine-grained control over memory, and things like map, filter etc. are more idiomatic than straight for-loops. They are implemented in a way that makes it a zero-cost abstraction compared to regular for-loops.

Generally I think Rust and Go gets compared too much, since they are very different languages both technically and philosophically. But the claim that things like map, filter etc. is unsuitable in a systems programming language (and Rust's definition of 'systems' has more stringent requirements than Go's definition of 'systems') is clearly false.

Re: Underscore.go

#54

Post by Dewie »

Daishiman wrote: post #28
tptacek wrote: post #19

Underscore is not a perfect fit for JS, but it's close enough; if you like coding in the style Underscore promotes, Underscore.js makes Javscript programming simpler. Underscore seems like it would not at all be a good fit for Golang. Golang really wants you to just use a for-loop.

It seems that enough people are tired of such a verbose idiom in 2014 to merit a library like this. I really dislike being that guy, but there's no reason why a language, today, shouldn't implement a decent map shorthand construction. For loops and unnecessary visual burden for a large variety of tasks and give no hint to the semantics of the code within a loop (is my loop doing a map, a transform, a reduction?).

But is there any reason to program in Go if you don't like idiomatic Go code (which seems to favour for-loops over higher-level abstractions)?

I can understand programmers wanting FP concepts and techniques in languages like C++; there is a lot of legacy C++ code, libraries and overall a large ecosystem. Some C++ programmers might either

1) have started programming in C++ many years ago (let's say 8+ years ago), and they might have thought that procedural and OO concepts where all that they wanted in C++. Now they might see some benefit in FP concepts, and want to see them used in C++, too. They don't want to switch languages because they already like C++ overall, and they have invested a lot of time into it.

2) They are "stuck" with C++ because of libraries, legacy code etc.

But the Go language is, what, 5 years old? It probably also has less legacy code, and I guess also relatively lacking ecosystem of libraries compared to other more established (or just older) languages. Why shoehorn FP concepts into Go instead of just moving on to a language where these concepts aren't seemingly going against the grain of the design of the language? Do most people really have a lot to lose from "ditching" Go?

Re: Underscore.go

#55

Post by Havvy »

dsymonds wrote: post #48
Daishiman wrote: post #28

Earlier quoted context omitted.

It seems that enough people are tired of such a verbose idiom in 2014 to merit a library like this. I really dislike being that guy, but there's no reason why a language, today, shouldn't implement a decent map shorthand construction. For loops and unnecessary visual burden for a large variety of tasks and give no hint to the semantics of the code within a loop (is my loop doing a map, a transform, a reduction?).

It really is a foreign world to me where a loop is considered a "verbose idiom".

It's less about verbosity and more about the lack of clarity. `for (i = 0; i < myContainer.length; i++) { ... }` vs. `myContainer.map( ... )` - which tells the reader more about what the code does? Which of these lets the writer focus more on domain logic?

Re: Underscore.go

#56

Post by tobyhede »

enneff wrote: post #47
tobyhede wrote: post #26

Oh hello. Library author here. Underscore.go is a mostly WIP that I hadn't intended to go live on HN :) The general feedback so far is __ is annoying, I thought it was cool and if people were annoyed they could fix it on import. But I might be quite wrong on this one. The directory layout is going to change and I am working on a branch at the moment that splits the whole thing into a file per algorithm, which makes t…

You should make the library installable with "go get" (yes, "__" is an ecosystem-hostile import path), and remove .go from the repository name.

Yep. Both points are top of the todo list.

Re: Underscore.go

#57

Post by omphalos »

Havvy wrote: post #55
dsymonds wrote: post #48

Earlier quoted context omitted.

It really is a foreign world to me where a loop is considered a "verbose idiom".

It's less about verbosity and more about the lack of clarity. `for (i = 0; i < myContainer.length; i++) { ... }` vs. `myContainer.map( ... )` - which tells the reader more about what the code does? Which of these lets the writer focus more on domain logic?

And something like groupBy is even worse.

Re: Underscore.go

#58

Post by dbaupp »

pjmlp wrote: post #51
Daishiman wrote: post #43

Earlier quoted context omitted.

A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system. Seriously; LuaJIT achieves greater performance and has more abstractions in place; Rust fills the niche of systems programming languages easily . I just fail to see th…

> A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system. - Mesa/Cedar (Xerox PARC) - Modula-3 (Compaq/Olivetti) - Oberon/Active Oberon (Swiss Federal Institute of Technology) - Sing# (Microsoft Research) - D (Digital Mars)

Presumably you're contesting the garbage collection point? However, the statement was a conjunction of that and:

- not such a constrained set of concurrency primitives

- such a basic type system.

I imagine those languages have a good type system and/or good concurrency primitives (i.e. possibly making up for their GC "penalty").

Re: Underscore.go

#59

Post by pjmlp »

dbaupp wrote: post #58
pjmlp wrote: post #51

Earlier quoted context omitted.

> A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system. - Mesa/Cedar (Xerox PARC) - Modula-3 (Compaq/Olivetti) - Oberon/Active Oberon (Swiss Federal Institute of Technology) - Sing# (Microsoft Research) - D (Digital Mars)

Presumably you're contesting the garbage collection point? However, the statement was a conjunction of that and: - not such a constrained set of concurrency primitives - such a basic type system. I imagine those languages have a good type system and/or good concurrency primitives (i.e. possibly making up for their GC "penalty").

My main point was GC, yes.

Actually the original Oberon type system is simpler than Go's. Its later revision Oberon-07 is even simpler.

All the other ones I mentioned, have better type systems than Go, even support for some form of generics.

Concurrency depends on the language, but you get a mix of threads, co-routines, tasks, active objects and processes, overall.

Re: Underscore.go

#60

Post by jerf »

tobyhede wrote: post #29
jerf wrote: post #2

Underscore was chosen in JS presumably because it is a valid variable name that isn't used for anything. Underscore in Go actually means something, which is why this is actually double -underscore, which makes it even visually more confusing. The approach is interesting, but I'd really rather see a better name.

Yeah, that's the general feedback I've had. Happy to take suggestions. "un" or "us" might be preferable?

Then my hat's off to you. So many times I've critiqued some awful names, just for the package author to dig in and stand on their "rights" or whatever. It will be to your benefit, I think.

My only suggestion would be a meta one, which is that I would suggest using a nice, full name and letting people shortcut it themselves. "un" is hard to search for.

Post reply on HN