Hacker News Reader

Comment by dimgl | Hacker News Reader

I like Go, but I'm finding array operations leave a lot to be desired. It feels weird to use global functions (like append) to perform operations on array, and I miss having easy map, reduce and filter functions that are accessible from within the array itself. I guess things are getting better, but idk.

View on HN

Agreed. Doing Advent of Code in Go and it is so verbose to do simple things like filtering. I agree that for loops can be easier to read, but when it takes 4 LOC to express what a 1 LOC filter function can do and you have 3+ maps or filters you need to do it seems far less readable because it is so noisy. Sure you can understand it, but it is a mess and takes too long to parse for the importance it actually has.

This shortcoming of golang really shows when writing non trivial programs.

This is really annoying, every time i code in go i miss python's list.append method

That is weird because append is one of the five associated helper functions on slices that's actually in the Go specification.

https://go.dev/ref/spec#Appending_and_copying_slices

Yes, it's a helper function, not a list method like it is in python. The result is the same, its just weird

Oh, I understand what you mean now. I thought you meant the functionality, not the idiom of calling it as a method. I dare say that it didn't occur to me that this difference would be great enough for someone to complain about it on the internet. :P

Python also puts what should be methods as global functions, e.g. len, filter, reduce.

I miss having easy map, reduce and filter functions that are accessible from within the array itself

Those are be the sort of things that generics will enable.

Whenever I read "modern" javascript code, I'm irritated by the prolifiration of map/filter/reduce.

It makes code harder to read and modify.

A straight for loop is infinitely better in every way.

This debate is basically just "I learned C first" vs "I learned a higher level language first."

Disagree. I used Python heavily before Go, and Go is much, much easier to read. I've never seen Go code in any codebase I couldn't immediately follow. I can't say the same about Python, and that's supposedly an easier HLL.

Then again, I learned BASIC first technically, so my brain probably isn't quite right :).

Neither Go nor Python are languages that encourage composing functionality out of higher order functions, so I think the point stands.

C is high level, many just think it isn't.

DDJ had quite a few articles on how to do Lisp-in-C kind of thing.

You’re a bit quick to comment there because the GP said “highER”. ie another language that is a highER level than C.

So technically their post is correct

C provides the tooling to implement many of the necessary abstractions as libraries, hence why I pointed to the DDJ articles.

You can even plug a conservative GC for the full Lisp like experience.

Are you actually reading peoples comments before replying? You’re posting these completely irrelevant tangents as if it’s a contradiction to earlier posts (it isn’t) and in a tone that suggests you’re the only person who knows C (you’re not).

Whatever.

My learning path was Logo->Basic->Pascal\Delphi->PHP->Python->Ruby and then Go. With some of js here and there.

I don't really think it has much to do with you language path but rather with the field you are working most of the time.

People who are building Rails startups for sale will have opinion different from people who build some sort of integration systems.

I learned C first but then I rode the functional bandwagon (and dynamic languages) and spent many many years in Python and Javascript. I thought map/filter was much better than imperative for a long time.

I rediscovered imperative programming later and found it to be such a breath of fresh air.

It's a bit messy in JS.

In Ruby the map/filter/reduce handling is very smooth, readable and useful!

> It's a bit messy in JS.

Mainly, IME, because of the combination of JS map, etc., passing extra, infrequently used parameters, and functions you might want to use often accepting optional less-frequently-used parameters, which can end up interacting horribly wrong when you do:

  arr.map(func)

instead of:

  arr.map(v => func(v))

when you want a “simple” map application.

I find map/filter/reduce much easier to read if it is being used for a functional map, filter, or reduce operation or something not too distant from it.

> A straight for loop is infinitely better in every way.

A straight for, for-of, or for-in loop, as appropriate, is finitely better for imperative operations that don't naturally fit map/filter/reduce but need to be performed over some set of values.

This. Saw a reduce once which contained a lambda one screen long. It gets worse, it contained another reduce...

Ah, and a map that performed side effects.

A one line map or filter is ok.

Other than that it's unreadable.

I think its important to understand that big parts of the software community over-rely on this type of programming. In my opinion, over use of higher order functions is a cancer on programming languages, and should be used at the absolute minimum, or even omitted from a language entirely.

https://github.com/golang/go/issues/45955#issuecomment-83235...

Reply on news.ycombinator.com