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

Write code. Not too much. Mostly functions.

brandons.me

Post reply on HN
Print view View original

331–340 of 362 posts

Re: Write code. Not too much. Mostly functions.

#331

Post by throwaway34241 »

edumucelli wrote: post #270
serial_dev wrote: post #17

I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…

Golang and simplicity in the same sentence does not quite reflects my daily experience. Want a Set? Golang does not have one, create a map[type]boolean instead. Want an Enum? Golang does not have one, create a bunch of constants yourself that are not tied together by a type, or create your own type that won't quite make what an Enum is. If simplicity means feeling like you are programming in the 80's, that is what Go…

FWIW the set equivalent in Go would be map[Thing]struct{}, you don’t need a bool map value.

That being said I’m looking forward to more collection types now that they have a plan for generics.

Re: Write code. Not too much. Mostly functions.

#332

Post by Geminidog »

shakow wrote: post #327
Geminidog wrote: post #316

Earlier quoted context omitted.

It exists with dummy variables. Ive seen it with C++ bind and many fp libraries in JavaScript as well.

But then it's not pointfree, it's just anaonymous variables instead of named.

Yeah technically it's not point free. But technically nothing can truly be point free just like nothing can ever be truly purely functional.

In purely functional programming your IO and state has to live somewhere just like how your points in point free programming still have to exist on the function call.

A function that takes multiple arguments introduces extra points to your program similar to introducing extra IO calls to your purely functional program. These points are inevitable additions to your program. The philosophy remains point free however.

Another way to think about it is that every parameter in a point free program is tied to a point somewhere up the pipeline. If you introduce a function with multiple arguments, that extra argument will still need to be tied to a point either right now or up some other pipeline.

So either you curry in a point into that extra parameter or you curry in the result of another pipeline.

A good way to think of the point free style is a series of pipes flowing in one direction, from left to right. All pipes segments must be eventually connected to a source and eventually flow to an output.

A function with 2 parameters is a T junction within this system with 2 inflows and one outflow. No matter how you configure your network of pipes; points need to live to the at the source and output of this network either as IO or actual state. There is no "point" in creating a network of pipes that isn't connected to a source and an output.

When you introduce a new T junction into this network of pipes, you will inevitably need to connect these inflows to points at the source of the pipe network. There's no way around it.

Re: Write code. Not too much. Mostly functions.

#333

Post by nickbauman »

serial_dev wrote: post #17

I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…

This can be summarized as

"It's better to repeat yourself than use the wrong abstraction."

It happens often in the attempt to be DRY we add a parameter or some condition to handle a new variation to what seems like a universal logical construct in the code. Do this enough times and the code is no longer comprehensible to any of the people who wrote each variation, let alone a newcommer. We mistake some commonalities with a universality. We become zealots.

Re: Write code. Not too much. Mostly functions.

#334

Post by kortex »

lookdangerous wrote: post #100
kortex wrote: post #58

Earlier quoted context omitted.

I don't think GOPATH is poorly thought out at all. Dependency-environment-locating is a PITA. Off the top of my head, I can't think of a single package management system that doesn't use universal installs, FOO_PATH or "giant local dump per project". Universal: - apt, yum, brew Team PATH: - GOPATH - CMAKE_PREFIX_PATH - PYTHONPATH (which Conda, virtualenv, etc modify) - CARGO_HOME Team redundant local blob: - Node - p…

Is your home dir chock full of namespace folders?

Nope, just two or three. Most lives in ~/ao (easy to type on dvorak), some is in ~/rd (random), some is in ~/tmp. I don't really work on enough variety of projects to deal with collisions.

Re: Write code. Not too much. Mostly functions.

#335

Post by kortex »

fiddlerwoaroof wrote: post #148
kortex wrote: post #58

Earlier quoted context omitted.

I don't think GOPATH is poorly thought out at all. Dependency-environment-locating is a PITA. Off the top of my head, I can't think of a single package management system that doesn't use universal installs, FOO_PATH or "giant local dump per project". Universal: - apt, yum, brew Team PATH: - GOPATH - CMAKE_PREFIX_PATH - PYTHONPATH (which Conda, virtualenv, etc modify) - CARGO_HOME Team redundant local blob: - Node - p…

Nix isn’t any of these? It installs each replicable version of a package once, but it’s not visible outside of the project that uses it.

Never worked with Nix, though it looks interesting.

Re: Write code. Not too much. Mostly functions.

#336

Post by AnimalMuppet »

Geminidog wrote: post #330
AnimalMuppet wrote: post #324

Earlier quoted context omitted.

BTW, the term "organizational" usually refers to how you organize your people . Even under your definition, though, point-free only helps with a limited definition of "how you organize your logic". How do you organize it into layers? How do you organize it into files? How do you organize it into processes? How do you organize it across machines? You can get real "organizational technical debt" on all of those.

> BTW, the term "organizational" usually refers to how you organize your people. Then what, in your opinion, is a better adjective for "technical debt" that best conveys my point? >How do you organize it into layers? How do you organize it into files? Namespacing, files, and "layers" are aesthetic forms of organization that do not produce actual barriers in organization. They are for people to read and do not produce…

> > BTW, the term "organizational" usually refers to how you organize your people.

> Then what, in your opinion, is a better adjective for "technical debt" that best conveys my point?

"Structural", maybe? (Just off the top of my head; that word choice may also have flaws...)

Re: Write code. Not too much. Mostly functions.

#337

Post by eyelidlessness »

bcrosby95 wrote: post #235
plasticchris wrote: post #129

Earlier quoted context omitted.

Abstraction here likely means more than a function - maybe something like an interface base class?

Probably. When talking about object oriented programs, "abstraction" is oftentimes used as a placeholder for "abstract class" as opposed to a "concrete class". You can see this at play when talking about the SOLID principles and when you get to the "D" part people want to turn every class into an interface because it says you must "depend upon abstractions, not concretions".

I think this is where I’ve been most at odds with common OOP approaches (apart from the common practice of widespread mutability). An interface should be an abstraction defining what a given operation (function, module) needs from input to operate on it and produce output, and nothing more. Mirroring concrete types with an interface isn’t abstraction, it’s just putting an IPrefix on concrete types to check a design pattern box.

Re: Write code. Not too much. Mostly functions.

#338

Post by fiddlerwoaroof »

kortex wrote: post #335
fiddlerwoaroof wrote: post #148

Earlier quoted context omitted.

Nix isn’t any of these? It installs each replicable version of a package once, but it’s not visible outside of the project that uses it.

Never worked with Nix, though it looks interesting.

It has rough edges, but I find it one of the better developer experiences.

Re: Write code. Not too much. Mostly functions.

#339

Post by steveklabnik »

brundolf wrote: post #322
ritchiea wrote: post #273

What's the difference between writing OO code that depends on internal state and writing a pure function that expects an argument that is a data structure of a specific type (and thus has internal data that could be different)? Is the pure function no longer pure if the argument is a data structure thats complex and the values within the data structure dictate the outcome of the the function? Or is it a pure function…

Purity is a question of mutability, nothing more. If the function mutates its arguments (or its closure, or its global environment), it is impure. Any useful program will of course need to do these things at some point, but there's a lot of logic that just goes from A -> B (or A, B, C -> D, or whatever), that doesn't need to concern itself with these things, and should be insulated from them. There's nothing inherent…

Interior mutability allows you to mutate behind &self.

Re: Write code. Not too much. Mostly functions.

#340

Post by brundolf »

steveklabnik wrote: post #339
brundolf wrote: post #322

Earlier quoted context omitted.

Purity is a question of mutability, nothing more. If the function mutates its arguments (or its closure, or its global environment), it is impure. Any useful program will of course need to do these things at some point, but there's a lot of logic that just goes from A -> B (or A, B, C -> D, or whatever), that doesn't need to concern itself with these things, and should be insulated from them. There's nothing inherent…

Interior mutability allows you to mutate behind &self.

Yeah true, though I think of that as a bit of a trap-door along the lines of unsafe { }. There's still a reasonable guarantee under "normal" circumstances.
Post reply on HN