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

281–290 of 362 posts

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

#281

Post by noisy_boy »

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…

I recently had to write some Go code and coming from Java/Scala world, actually the "err != nil" thing didn't bother me as much as I thought it would. In fact I liked the explicitness of error handling. However, lack of enums really puzzled me; how is having to go through "iota" hoops simpler than "enum Name { ... choices ... }"? I did like the batteries included approach though - I could build the entire component purely using standard library - not having to deal with importing requests and creating virtualenv etc was refreshing.

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

#282

Post by yarg »

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…

It's the difference between c++ and c.

He's not suggesting pure functional programming - and beyond a certain point the simplicity associated with functional programming will be completely negated by the complexity of the arguments.

From my understanding of what he said, I doubt that he'd advocate for pure functional in circumstances of significant necessary complexity.

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

#283

Post by UK-Al05 »

agallant wrote: post #90
nx7487 wrote: post #50

Earlier quoted context omitted.

> In my experience, code with too many functions is more difficult to grok than spaghetti code. In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.

The best label I've heard for the excessive layers anti-pattern is "lasagna code."

Lasagna code isn't meant to be derogatory, just a description.

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

#284

Post by varjag »

KronisLV wrote: post #252
monocasa wrote: post #86

Earlier quoted context omitted.

Hard same. The best organizational level technique I've found so far is to add the rule of three to code review checklists. An abstraction requires at least three users. Not three callsites, but three distinct clients with different requirements of the abstraction. Obviously it's not a hard rule, and we allow someone to give a reason why they think that it's still a good idea, but forcing a conversation starting with…

I recently ran into the very same thing. Instead of creating a Spring service to call a repository for data retrieval, i instead called the repository directly, because there was just a single method that needed to be implemented for read-only access of some data. And yet, a colleague said that there should "always" be a service, for consistency with the existing codebase (~1.5M SLoC project). Seeing as the project i…

Hey, it wouldn't become a 1.5M sloc codebase if these rules weren't followed! ;)

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

#285

Post by ritter2a »

cjfd wrote: post #249

I agree with the sentiment that things should be made as simple as possible. The sine function really has no reason to be anything besides a function. I am not sure, though, that writing the simplest thing possible results in mostly pure functions. In my experience programming is mostly about managing a state. My programming jobs have generally been about tracking what the state of some other piece of hardware and/or…

I would claim that the benefits of 'mostly functions' strongly depend on the task at hand.

For the field of compilers, I can for example see value in making program analyses pure functions that just compute information about the program and separate them from the program transformations that use this information to (impurely) manipulate code. This makes the analyses more reusable and probably makes reasoning about correctness easier.

For other tasks in the compiler, pure functions can be a pain. My favorite anecdote for this is that of a group of students in a compiler's course who insisted on writing the project (a compiler for a subset of C) in Haskell and who, when discussing their implementation in the final code review, cited a recent paper [1] that describes how you can attach type information to an abstract syntax tree (which is an obvious no-brainer in the imperative world).

---

[1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_004...

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

#286

Post by laudable-logic »

hutzlibu wrote: post #262
laudable-logic wrote: post #146

Earlier quoted context omitted.

> wasted too much time thinking about the right approach in a neverending, neverprogressing loop to achieve perfection A CEO from my past often muttered that "perfect software comes at infinite cost". It's key, imo, to identify which components of what you are building _must_ be perfect. The rest can have warts.

"to identify which components of what you are building _must_ be perfect" Well, but by the words of your former CEO (and my opinion) those parts would then have infinite costs, too... if they really need to be perfect. I mean, it is awesome, when you do a big feature change and it all just runs smooth without problems, because your design was well thought out, but you cannot think of every future change to come - and…

> risk the flow of the whole project

Agreed. What I mean by "perfect" is: for a given part/component/decision/etc, take the time (an always-limited resource) to learn as much as possible and contemplate more than just the seemingly obvious path forward. Take security for example. I'd rather 'waste time' now making sure I'm covering any gaps in that realm before shipping.

OTOH maybe some jacked-up abstraction/incorrect tool choice/ugly-ui/etc is something that can wait a few sprints or longer. At least you can plan when to deal with these. Security breaches tend to plan your day for itself on your behalf. :)

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

#287

Post by ookdatnog »

ritter2a wrote: post #285
cjfd wrote: post #249

I agree with the sentiment that things should be made as simple as possible. The sine function really has no reason to be anything besides a function. I am not sure, though, that writing the simplest thing possible results in mostly pure functions. In my experience programming is mostly about managing a state. My programming jobs have generally been about tracking what the state of some other piece of hardware and/or…

I would claim that the benefits of 'mostly functions' strongly depend on the task at hand. For the field of compilers, I can for example see value in making program analyses pure functions that just compute information about the program and separate them from the program transformations that use this information to (impurely) manipulate code. This makes the analyses more reusable and probably makes reasoning about co…

An ad hoc solution is also a no-brainer in Haskell. They didn't need to read a paper to solve this issue, they did because they wanted the fanciest solution that is extensible in all dimensions.

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

#288

Post by atoav »

redisman wrote: post #241
atoav wrote: post #239

Earlier quoted context omitted.

I think a good programmer should have an "intuition" whether it is worth to build an abstraction for something or not. If in doubt don't do it. If in hindsight your intuition fooled you constantly, adjust it.

I agree but it's kind of too vague to have as a company/team-wide policy

Sure, but I wouldn't implement something like that as a policy, but as a guideline. So when someone really goes overboard into one or the other directionyou can point them to the guideline, but there is still some freedom in deciding on the spot.

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

#289

Post by wxd2351 »

bob1029 wrote: post #11

I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…

I definitely agree, I've realized that most programming languages store data in a hierarchy (structs within structs) which you then "query" in a very static way with the "." operator. Normalizing data and storing it relationally seems way more flexible for a lot of use cases which is why most databases are relational and not hierarchical.

However, I've tried to figure out how to actually store and query data relationally in a language like C++ and haven't been able to figure out a good way. I don't want to use SQLite because of performance, this needs to be close to real time (like a game or something similar). I just want a way to store data relationally in memory in C++. I'm still trying to figure out the right approach here. C++ is very static which makes it difficult. I've been able to figure it out in Javascript though.

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

#290

Post by m45t3r »

nightcracker wrote: post #244
m45t3r wrote: post #102

> By "functions" here I mean "pure functions". After programming for Clojure for quite a long time (~2 years), I fully share this sentiment. Using pure functions for business logic (and also using simple data structures instead of, say, classes and encapsulation) seems to generally makes the code more simple and maintainable in the long run. > Of course the qualifier is "mostly": this isn't a dogma. Writing a 100% fu…

For years now I've felt the same way about functional v.s. imperative programming, and where functional languages go 'wrong', and what they get right. There are exceptions of course, but I personally feel that there's three main 'kinds' of code: 1. functions that define some input/output relation 2. query methods on data structures 3. modification methods on data structures 4. the bodies of the above functions In a p…

> In a purely functional language all four are purely functional, but this is (IMO) needlessly restrictive.

I concur. My two favorite languages nowadays (Elixir and Clojure) are far from being purely functional. They are functional enough that mutating state is awkward, but if you do need it it is there.

I also think having immutable data structures by default is a saner choice IMO.

> It leads to recursion where iteration is more natural, awkward choices of data structures or even plain impossibility of certain algorithms/data structures

Anecdotal, but I rarely use recursion/for loops, opting for defining auxiliary functions that works in one element and using map/reduce instead. Really, I don't remember the last time I needed recursion to solve a problem (for example, I know recur exists in Clojure, but I never saw it in the code that I work everyday).

Post reply on HN