4 ms·

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize t

by zerr 2mo ago

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

thebytefairy 2mo ago
People should stop using these simplified high level programming languages with low cognitive weight, like Go. I only write assembly. ;)
red_admiral 2mo ago
Just because we can, doesn't mean we have to. I'd prefer to have some more brain-cache free to concentrate on the problem I'm trying to debug rather than doing type resolution in my head.
- yladiz 2mo ago
  Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.
  - kfuse 2mo ago
    No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like: interface Box<T> { value: T } function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> { return { value: func(input.value) } }
4ndrewl 2mo ago
(b Box[T]) Map[U any](f func(T) U) Box[U] _is_ for the Arts and Humanities. Unless you're writing assembler in vim you're not STEM.
fragmede 2mo ago
Why should I, as fallible human of limited short and long term memory, bear that cognitive weight when I have a perfectly good compiler on a computer to offload that particular cognitive weight to?
wannabe44 2mo ago
In terms of tooling, Go is one of the few languages which remembers that we are in STEM.
- SubjectToChange 2mo ago
  I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason. Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even if GoLand is closing the gap on the IDE front (idk, I haven’t tried it), golang simply doesn’t offer the features found in OpenJDK or Dotnet (GC parameters/implementations, profiling/introspection data, interoperability/ffi, etc.). It just feels like golang’s tooling looks good when it’s competing against python, ruby, or JS/TS.
  - wannabe44 2mo ago
    Native compilation which is fast enough, green threads, AST and analysis framework, in-built testing and profiling, call graphs, rewrite tooling (go fix), go.work and modules which are far better than maven / gradle mess. There's a good amount of rigour applied to Go tooling that it "just works", even as horrendous the language is. I agree java is good too, except spring boot manages to undo all the engineering that has gone to Java.
snsjjsjjs 2mo ago
I wish it was arts & humanities.. those are some actually clever folks.
sirsinsalot 2mo ago
Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity. Your comment boils down to "I'm smart", which in the end, isn't terribly smart. Having simplicity and expressiveness as a goal, and a general direction of achieving things through lazy means is at the heart of mathematics and engineering. Celebrate laziness and a want for simplicity. True simplicity is hard, but worth going after even where it threatens the notion that you're the smartest person in the room.
- SubjectToChange 2mo ago
  >Your comment boils down to "I'm smart", which in the end, isn't terribly smart. They are saying that a programmer should be able to cope with the cognitive dissonance of not immediately understanding something. >Celebrate laziness and a want for simplicity. Concepts like generics might be intellectually more challenging, but they are clearly the “lazy” approach for actually writing code. Writing and maintaining multiple versions of the same function, or using code generation, is intellectual lazy but manually intensive.
peterashford 2mo ago
I don't think that comment was necessary. What do you gain by denigrating the Arts?

by zerr 2mo ago

thebytefairy 2mo ago

People should stop using these simplified high level programming languages with low cognitive weight, like Go. I only write assembly. ;)

red_admiral 2mo ago

Just because we can, doesn't mean we have to. I'd prefer to have some more brain-cache free to concentrate on the problem I'm trying to debug rather than doing type resolution in my head.

yladiz 2mo ago
Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.
- kfuse 2mo ago
  No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like: interface Box<T> { value: T } function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> { return { value: func(input.value) } }

4ndrewl 2mo ago

(b Box[T]) Map[U any](f func(T) U) Box[U] _is_ for the Arts and Humanities. Unless you're writing assembler in vim you're not STEM.

fragmede 2mo ago

Why should I, as fallible human of limited short and long term memory, bear that cognitive weight when I have a perfectly good compiler on a computer to offload that particular cognitive weight to?

wannabe44 2mo ago

In terms of tooling, Go is one of the few languages which remembers that we are in STEM.

SubjectToChange 2mo ago
I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason. Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even if GoLand is closing the gap on the IDE front (idk, I haven’t tried it), golang simply doesn’t offer the features found in OpenJDK or Dotnet (GC parameters/implementations, profiling/introspection data, interoperability/ffi, etc.). It just feels like golang’s tooling looks good when it’s competing against python, ruby, or JS/TS.
- wannabe44 2mo ago
  Native compilation which is fast enough, green threads, AST and analysis framework, in-built testing and profiling, call graphs, rewrite tooling (go fix), go.work and modules which are far better than maven / gradle mess. There's a good amount of rigour applied to Go tooling that it "just works", even as horrendous the language is. I agree java is good too, except spring boot manages to undo all the engineering that has gone to Java.

snsjjsjjs 2mo ago

I wish it was arts & humanities.. those are some actually clever folks.

sirsinsalot 2mo ago

Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity. Your comment boils down to "I'm smart", which in the end, isn't terribly smart. Having simplicity and expressiveness as a goal, and a general direction of achieving things through lazy means is at the heart of mathematics and engineering. Celebrate laziness and a want for simplicity. True simplicity is hard, but worth going after even where it threatens the notion that you're the smartest person in the room.

SubjectToChange 2mo ago
>Your comment boils down to "I'm smart", which in the end, isn't terribly smart. They are saying that a programmer should be able to cope with the cognitive dissonance of not immediately understanding something. >Celebrate laziness and a want for simplicity. Concepts like generics might be intellectually more challenging, but they are clearly the “lazy” approach for actually writing code. Writing and maintaining multiple versions of the same function, or using code generation, is intellectual lazy but manually intensive.

peterashford 2mo ago

I don't think that comment was necessary. What do you gain by denigrating the Arts?