6 ms·

He basically admits that several of the "improvements" boils down to ripping out patterns that decouple code instead of finding alternate solutions. They're kin

by geokon 10y ago

He basically admits that several of the "improvements" boils down to ripping out patterns that decouple code instead of finding alternate solutions. They're kinda quick and dirty, not agile, and could make refactoring a nightmare. I mean, he's not necessarily wrong, but hindsight is 20/20 and once you're done you can look back and cherry-pick and say "ahh, well obviously these things would always need to be coupled! I shouldn't have done the gymnastics to decouple them!" .. but that's a dangerous mindset to start solving the problem with. The whole topic of global state is very interesting and one I approach cautiously. I'd love to hear what more experienced programmers have to saw. When I go with global state I usually rely on someone else's judgement and use a framework. Like OpenGL and the graphics pipeline has global state.. and I'm okay with that. I use Cinder/Arduino, those things have some global states and for good reasons as well. But you really try your best to find a stateless solution - and here is feels like he isn't really trying

girvo 10y ago
> stateless Game development is kind of different, in that it's rendering the state of a simulation; so aiming for completely stateless solutions ends up making code quite convoluted -- you're hiding state rather than getting rid of it, in my experience. Now, stateless functions are still well worth it, at least up until it's time to get it optimised for performance ;) Game development is a fascinating world where a lot of the things I would normally reach for don't apply quite as well. It's quite likely you know all of this already, but I found learning this myself absolutely fascinating, and one of the reasons I still like to tinker with game development in my spare time :)
- TeMPOraL 10y ago
  Since a lot of my programming experience is writing hobby engines and games (and reading up a lot of engine code and gamedev resources), I sometimes wonder how negatively does this impact my regular career (previously web, now desktop applications). EDIT: to clarify, I mean the code I write, not my career prospects.
  - deleted 10y ago
    [deleted]
    - deleted 10y ago
      [deleted]
      - deleted 10y ago
        [deleted]
  - cableshaft 10y ago
    I know several people who used to work in the video game industry, and I used to as well (I still may get back into it eventually). It's much harder to convince interviewers that you can handle the work than it is for you to be able to do that work. Granted, there was a lot I've picked up over the past few years working for large corporations, but not all of it was good. And there's just as much awful code in business applications as there are in game applications, and it's even less fun to debug them.
  - errozero 10y ago
    Bit of a tangent but how was the switch from web to desktop apps?
    - TeMPOraL 10y ago
      Quite fine, actually. I like desktop apps better. Architectural patterns are pretty similar in both; the primary difference is that in a desktop app, you deal with single user and a lot of impersistent state.
      - errozero 10y ago
        I can imagine that would be a lot nicer, do you work for yourself? If not, how did you transition from a job in web dev to desktop?
        10y ago
- falsedan 10y ago
  > > stateless I think they're going for 'immutable' instead of stateless.
- taneq 10y ago
  Coming from a background mainly involving game development and control systems, this is one of the things that I find myself shaking my head at when reading HN. So many people here forget there's a software world outside web code, where memory and CPU time aren't effectively infinite, you're modeling processes and systems with continuously evolving state, and where trying to make everything immutable is just plain silly.
  - geokon 10y ago
    Well my last job was working on simulations and I've only worked on performance sensitive system.... Making everything immutable maybe is silly, but it's still a very good goal to have in mind. A continuously evolving system can be designed in an mostly immutable manner as well without sacrificing performance. In a big picture sense you are trying to have your system be a function of time. And while for efficiency you sometimes should preserve intermediate states, you can typically accomplish that with clever caching systems that are not exposed in the interface. So the design remains "immutable" in a sense
  - smaddox 10y ago
    It's certainly not realistic to make everything immutable, but it's still worthwhile to move global state into some monadic encapsulation to make your code more testable and composable. This might not be an option on embedded systems, though, or for certain specialized hardware, e.g. GPU's.
sillysaurus3 10y ago
The whole topic of global state is very interesting and one I approach cautiously. I'd love to hear what more experienced programmers have to saw. 1. Quake 3 relied heavily on global state. It was good design, and the engine produced billions in revenue. 2. Emacs relies heavily on global state. A global variable is a first-class citizen. When a package declares a global variable, it's a contract between the package author and the user that "You may configure the behavior of this package by binding this variable to a new value, then invoking one of my functions." Emacs lisp has language constructs which makes this easier: `(let* ((foo-state 42)) (foo-bar))` will update the global variable `foo-state` to 42, call the global function `foo-bar`, and ensures that `foo-state` is returned to its previous value even if an error occurs and an exception is propagated. In other words, global variables are the interface to a module, just like a module's functions, and global variables are almost never left in an unexpected or invalid state due to errors. This system works shockingly well in practice. Emacs is basically a gigantic state simulation, and it parallels a game engine quite strongly. The Emacs Lisp language itself is cumbersome, which has led many to dismiss it as ancient. The true power of emacs has little to do with lisp and almost everything to do with excellent design decisions. 3. The history of programming informs us that those who hold to dogma are quickly made obsolete. Every tool and pattern has its place. A technique that simplifies X in a certain domain will make X far more complicated in a different domain. Context matters.
- saurik 10y ago
  The Emacs property you are demonstrating with let is "dynamic scoping" and not "global variables" (which is leading to a weird and essentially incorrect description, even if it is difficult to notice a behavior difference between that mental model and what really happens).
  - sillysaurus3 10y ago
    A global variable is a variable with global scope, meaning that it is visible and accessible throughout the program, unless shadowed. Emacs added lexical scoping several years ago. When a global variable is declared in emacs using defvar, in addition to becoming globally accessible, the symbol is also flagged as special. This causes it to use dynamic binding whenever it is `let`-bound, even if lexical scoping is in effect. I pointed out dynamic binding in order to call attention to a technique that allows global variables to be composed into large-scale systems without being hindered by the problems traditionally associated with global state. But if you'd like more precision, feel free to ask.
buzzybee 10y ago
Decoupling isn't the same as statelessness. The state machine pattern used by OpenGL is a logical decoupling to the physical state of GPU hardware. State machines, buffers, protocols and the like - abstractions that we tend to think of as "low level" or "implementation detail" - are in fact the primary means of decoupling used when dealing with stateful systems. Computing hardware itself makes considerable use of these abstractions in providing modular interfaces. Stateless abstractions are great when you can provide them. But the stuff you're building on isn't itself built out of statelessness.
coldtea 10y ago
>I shouldn't have done the gymnastics to decouple them!" .. but that's a dangerous mindset to start solving the problem with. Is it, though? YAGNI comes to mind.
- TeMPOraL 10y ago
  My current rule of thumb is: if I know how to write it correctly, then I write it correctly. If I don't feel confident, I write the dumbest / most direct version that works to get the feel of the "lay of the land", and then refactor it later based on the new experience.
  - coldtea 10y ago
    I like this rule (don't remember who said it): "Write code that is easy to remove, not easy to extend".
grey-area 10y ago
but that's a dangerous mindset to start solving the problem with A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. Often you don't even know what the problem is. Far better to keep things coupled and simple till you know in retrospect that you need to split them out. Same goes for global state. This is a hard lesson to learn. Abstraction is seductive.
- icebraining 10y ago
  A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. This sounds off to me; if you assume you'll need to change the architecture later on, aren't you better off starting with a decoupled system that can more easily be changed? Or are you essentially arguing for YAGNI, in the sense that decoupling upfront is potentially useless?
  - grey-area 10y ago
    Yes, YANGNI. Not against all decoupling at all, but beginners tend to err on the side of too much structure.
  - wtetzner 10y ago
    > aren't you better off starting with a decoupled system that can more easily be changed? I think the problem is that you don't know where the boundaries of your abstractions should be until you have a better understand of what it takes to solve the problem.
- Nomentatus 10y ago
  I think about making an effort to loosely couple from the start as building in flexibility, which is useful precisely because "Often you don't even know what the problem is." Flexibility isn't a commitment to any particular abstraction of the solution, on the contrary it's the ability to dump any abstractions that you care to later on with less fuss. (Of course, you can still be unwise and decouple or create modules in ways that commit you to more than you realized.) We agree that placeholder code shouldn't commit you to too much, but there are patterns that help you with that. In the parent, the original decoupling turned out to be less performant (I take it) but wouldn't hinder completing the first draft or get in the way of a rewrite with closer coupling.

by geokon 10y ago

girvo 10y ago

> stateless Game development is kind of different, in that it's rendering the state of a simulation; so aiming for completely stateless solutions ends up making code quite convoluted -- you're hiding state rather than getting rid of it, in my experience. Now, stateless functions are still well worth it, at least up until it's time to get it optimised for performance ;) Game development is a fascinating world where a lot of the things I would normally reach for don't apply quite as well. It's quite likely you know all of this already, but I found learning this myself absolutely fascinating, and one of the reasons I still like to tinker with game development in my spare time :)

TeMPOraL 10y ago
Since a lot of my programming experience is writing hobby engines and games (and reading up a lot of engine code and gamedev resources), I sometimes wonder how negatively does this impact my regular career (previously web, now desktop applications). EDIT: to clarify, I mean the code I write, not my career prospects.
- deleted 10y ago
  [deleted]
  - deleted 10y ago
    [deleted]
    - deleted 10y ago
      [deleted]
- cableshaft 10y ago
  I know several people who used to work in the video game industry, and I used to as well (I still may get back into it eventually). It's much harder to convince interviewers that you can handle the work than it is for you to be able to do that work. Granted, there was a lot I've picked up over the past few years working for large corporations, but not all of it was good. And there's just as much awful code in business applications as there are in game applications, and it's even less fun to debug them.
- errozero 10y ago
  Bit of a tangent but how was the switch from web to desktop apps?
  - TeMPOraL 10y ago
    Quite fine, actually. I like desktop apps better. Architectural patterns are pretty similar in both; the primary difference is that in a desktop app, you deal with single user and a lot of impersistent state.
    - errozero 10y ago
      I can imagine that would be a lot nicer, do you work for yourself? If not, how did you transition from a job in web dev to desktop?
      - 10y ago
falsedan 10y ago
> > stateless I think they're going for 'immutable' instead of stateless.
taneq 10y ago
Coming from a background mainly involving game development and control systems, this is one of the things that I find myself shaking my head at when reading HN. So many people here forget there's a software world outside web code, where memory and CPU time aren't effectively infinite, you're modeling processes and systems with continuously evolving state, and where trying to make everything immutable is just plain silly.
- geokon 10y ago
  Well my last job was working on simulations and I've only worked on performance sensitive system.... Making everything immutable maybe is silly, but it's still a very good goal to have in mind. A continuously evolving system can be designed in an mostly immutable manner as well without sacrificing performance. In a big picture sense you are trying to have your system be a function of time. And while for efficiency you sometimes should preserve intermediate states, you can typically accomplish that with clever caching systems that are not exposed in the interface. So the design remains "immutable" in a sense
- smaddox 10y ago
  It's certainly not realistic to make everything immutable, but it's still worthwhile to move global state into some monadic encapsulation to make your code more testable and composable. This might not be an option on embedded systems, though, or for certain specialized hardware, e.g. GPU's.

sillysaurus3 10y ago

The whole topic of global state is very interesting and one I approach cautiously. I'd love to hear what more experienced programmers have to saw. 1. Quake 3 relied heavily on global state. It was good design, and the engine produced billions in revenue. 2. Emacs relies heavily on global state. A global variable is a first-class citizen. When a package declares a global variable, it's a contract between the package author and the user that "You may configure the behavior of this package by binding this variable to a new value, then invoking one of my functions." Emacs lisp has language constructs which makes this easier: `(let* ((foo-state 42)) (foo-bar))` will update the global variable `foo-state` to 42, call the global function `foo-bar`, and ensures that `foo-state` is returned to its previous value even if an error occurs and an exception is propagated. In other words, global variables are the interface to a module, just like a module's functions, and global variables are almost never left in an unexpected or invalid state due to errors. This system works shockingly well in practice. Emacs is basically a gigantic state simulation, and it parallels a game engine quite strongly. The Emacs Lisp language itself is cumbersome, which has led many to dismiss it as ancient. The true power of emacs has little to do with lisp and almost everything to do with excellent design decisions. 3. The history of programming informs us that those who hold to dogma are quickly made obsolete. Every tool and pattern has its place. A technique that simplifies X in a certain domain will make X far more complicated in a different domain. Context matters.

saurik 10y ago
The Emacs property you are demonstrating with let is "dynamic scoping" and not "global variables" (which is leading to a weird and essentially incorrect description, even if it is difficult to notice a behavior difference between that mental model and what really happens).
- sillysaurus3 10y ago
  A global variable is a variable with global scope, meaning that it is visible and accessible throughout the program, unless shadowed. Emacs added lexical scoping several years ago. When a global variable is declared in emacs using defvar, in addition to becoming globally accessible, the symbol is also flagged as special. This causes it to use dynamic binding whenever it is `let`-bound, even if lexical scoping is in effect. I pointed out dynamic binding in order to call attention to a technique that allows global variables to be composed into large-scale systems without being hindered by the problems traditionally associated with global state. But if you'd like more precision, feel free to ask.

buzzybee 10y ago

Decoupling isn't the same as statelessness. The state machine pattern used by OpenGL is a logical decoupling to the physical state of GPU hardware. State machines, buffers, protocols and the like - abstractions that we tend to think of as "low level" or "implementation detail" - are in fact the primary means of decoupling used when dealing with stateful systems. Computing hardware itself makes considerable use of these abstractions in providing modular interfaces. Stateless abstractions are great when you can provide them. But the stuff you're building on isn't itself built out of statelessness.

coldtea 10y ago

>I shouldn't have done the gymnastics to decouple them!" .. but that's a dangerous mindset to start solving the problem with. Is it, though? YAGNI comes to mind.

TeMPOraL 10y ago
My current rule of thumb is: if I know how to write it correctly, then I write it correctly. If I don't feel confident, I write the dumbest / most direct version that works to get the feel of the "lay of the land", and then refactor it later based on the new experience.
- coldtea 10y ago
  I like this rule (don't remember who said it): "Write code that is easy to remove, not easy to extend".

grey-area 10y ago

but that's a dangerous mindset to start solving the problem with A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. Often you don't even know what the problem is. Far better to keep things coupled and simple till you know in retrospect that you need to split them out. Same goes for global state. This is a hard lesson to learn. Abstraction is seductive.

icebraining 10y ago
A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. This sounds off to me; if you assume you'll need to change the architecture later on, aren't you better off starting with a decoupled system that can more easily be changed? Or are you essentially arguing for YAGNI, in the sense that decoupling upfront is potentially useless?
- grey-area 10y ago
  Yes, YANGNI. Not against all decoupling at all, but beginners tend to err on the side of too much structure.
- wtetzner 10y ago
  > aren't you better off starting with a decoupled system that can more easily be changed? I think the problem is that you don't know where the boundaries of your abstractions should be until you have a better understand of what it takes to solve the problem.
Nomentatus 10y ago
I think about making an effort to loosely couple from the start as building in flexibility, which is useful precisely because "Often you don't even know what the problem is." Flexibility isn't a commitment to any particular abstraction of the solution, on the contrary it's the ability to dump any abstractions that you care to later on with less fuss. (Of course, you can still be unwise and decouple or create modules in ways that commit you to more than you realized.) We agree that placeholder code shouldn't commit you to too much, but there are patterns that help you with that. In the parent, the original decoupling turned out to be less performant (I take it) but wouldn't hinder completing the first draft or get in the way of a rewrite with closer coupling.