101–110 of 246 posts
Earlier quoted context omitted.
I hate unnecessary functions with a passion and it's refreshing to hear his opinion. Sometimes a big, fat block of code is just easier to understand.
> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...
Earlier quoted context omitted.
I think that fn x() { doStuff(); moreStuff(); forgotSomething(); } is pretty bad code, but that's probably because I consider procedures with no arguments and no return value a sign that something is poorly factored. However, fn x(y) { foo = doStuff(y); bar = moreStuff(foo); if (isSomething(bar)) { return theRest(bar) } else { return theBest(bar); } } can be a good way to separate the why from the how and clearly com…
The former example was much easier for me to understand than the latter, even if it wasn't factored well. But I'm assuming that the functions aren't mucking about with global state or something equally distasteful.
It seems fairly obvious to me that either the former example is waaaay simpler or it is doing something really distasteful.
I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…
Whats important is to not have leaky abstractions though. The moment you need to start reading into those functions is the moment you realize you would have been better off leaving the code as is.
Its very hard (at least for me) to come up with those layers and requires a ton of iteration. Thats why I also prefer the top example - you need to work with the lower level code first, and go through enough of it before you can start spotting patterns and creating layers, otherwise you’re bound to mess things quite a bit.
I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…
Tradtional mulit-tier the UI depends on Business Logic, Buinsess Logic depends on persistence etc
The idea is protect the core, and persistence or UI concerns adapt to how the core wants to interact with the world.
Earlier quoted context omitted.
I hate unnecessary functions with a passion and it's refreshing to hear his opinion. Sometimes a big, fat block of code is just easier to understand.
> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...
As a functional programming enthusiast, I agree with this.
Recently I worked on rewriting a relatively large backbone web application in React/Redux (For those that don't know, Redux is a framework for writing JS in a more functional style).
While moving all app logic to functional style makes it safer and easily testable, it is definitely not friendly to most programmers that maintain it. We've had lots of bugs caused by new people coming in, not understanding the functional style and making bad changes such:
- Doing side effects from functions that are assumed to be pure.
- Writing a lot of logic into functions that are directly doing side effects, instead of refactoring the decision making into reducers.
While I still love mostly pure functional code, I would only recommend it for smaller projects, where one or few developers with strong grasp of the style would strictly review every new PR to ensure new people don't mess up.
Earlier quoted context omitted.
I hate unnecessary functions with a passion and it's refreshing to hear his opinion. Sometimes a big, fat block of code is just easier to understand.
> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...
Earlier quoted context omitted.
I think that fn x() { doStuff(); moreStuff(); forgotSomething(); } is pretty bad code, but that's probably because I consider procedures with no arguments and no return value a sign that something is poorly factored. However, fn x(y) { foo = doStuff(y); bar = moreStuff(foo); if (isSomething(bar)) { return theRest(bar) } else { return theBest(bar); } } can be a good way to separate the why from the how and clearly com…
Haven't you just described functional vs procedural programming?
It's independent of OOP vs. functional, through it's easier to have implicit arguments and mutation in OOP so you see it more often there, especially if people somehow ended up believing that programming OOP means you need to create a class for everything and make all states a object member instead of e.g. a variable in the stack.
Earlier quoted context omitted.
I think the idea described by the op is how you're supposed to organize code when programming in Haskell. Having most of your application logic in pure functions makes it easy to test and reason about. While this is possible to do, it is easier said than done. Organizing the code this way requires a lot of time dedicated to thinking/rewriting, which is often not available in the usual corporate environment with stric…
I think it only requires a change of mindset for a developer. Learning TDD truly will usually lead to functional code, even if you do not write your tests first. Eg. I can't imagine what would be hard for a MS Paint clone to achieve using this approach. There are always things with side-effects (IO, namely), agreed, but in this CRUD example, the integration bits are coupled in a way where you need a single trivial in…
I'd say that you can apply it mostly everywhere, however it is not friendly to most people that will maintain the code, and that is a problem since most software will have many maintainers over its lifetime.
This reply to another comment I made on this thread should elaborate a bit more: https://news.ycombinator.com/item?id=24917764
Earlier quoted context omitted.
I think that fn x() { doStuff(); moreStuff(); forgotSomething(); } is pretty bad code, but that's probably because I consider procedures with no arguments and no return value a sign that something is poorly factored. However, fn x(y) { foo = doStuff(y); bar = moreStuff(foo); if (isSomething(bar)) { return theRest(bar) } else { return theBest(bar); } } can be a good way to separate the why from the how and clearly com…
The former example was much easier for me to understand than the latter, even if it wasn't factored well. But I'm assuming that the functions aren't mucking about with global state or something equally distasteful.
There's not much else for them to do, since they don't take arguments, but to muck about with global state and/or have side effects.
Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…
Another pet peeve of mine is variable names suffixed with "Data" and "Info".