8 ms·

This looks great, but my favourite thing might be the Principles section: > Hydra must be stable. It should never crash > Hydra must be lightweight... neve

This looks great, but my favourite thing might be the Principles section: > Hydra must be stable. It should never crash > Hydra must be lightweight... never use more than 10 MB of memory > API should be completely transparent > API must not be bloated I think these principles should be the standard to which we all hold our software. Looking forward to testing this out! Edit to say: it would be really great to see some more complete code samples but I'm sure that'll come in time.

sdegutis 12y ago
Can you give an example of the kinds of samples you would like to see, and where you would look for them? (I presume under the Examples section on the README page?) That will help me know what to put there.
- colinramsay 12y ago
  You have a link to your own config and some screenshots of it in action, maybe it would be good to pull out the relevant sections of your config so people can replicate what they see in the screenshots?
  - sdegutis 12y ago
    Not a bad idea, will do. Thanks.
cheepin 12y ago
Hail Hydra!
- Vanayad 12y ago
  Came here for this. Didn't leave disappointed.
chc 12y ago
I don't think "Must never use more than 10 MB of memory" is a reasonable standard to hold all software to.
- kennywinker 12y ago
  Nope, but I would venture to guess that most software would be improved by sticking to that.
  - chc 12y ago
    I don't even feel confident in that claim. If keeping memory usage under 10 MB requires a significant amount of developer effort, that is effort that isn't going into something else that I might value a lot more than, say, 20 MB of RAM.
    - georgemcbay 12y ago
      Not just developer effort, but also sometimes program runtime efficiency. RAM is cheap, RAM is pretty fast (compared to disk or network); cache shit there when it makes sense to do so for overall efficiency. 10MB is a fairly ridiculous modern standard to limit yourself to, IMO (and I started on the C64 and generally do dislike and try to avoid bloat).
- TD-Linux 12y ago
  To put this in perspective, a full screen application running on a Retina display needs at least 40MB total for its front and back buffers.
euank 12y ago
I do not like the "API should be completely transparent" and "API must not be bloated". I personally think APIs exist to hide complexity. They should make sense, they should be usable, but they need not be transparent. Let's have a rather contrived example. In SDL, you can call SDL_Init(). That does a lot of things, and what it does differs on windows, linux, and OSX. I absolutely don't want the more transparent API of SDL_Init_Windows_Video(), SDL_Init_Windows_Audio(), SDL_Init_Linux_Video() .... And so on. Realistically, for absolute transparency, you'd just do away with the API and write every line of code SDL currently hides (Reductio ad absurdum I know) The entire point of having that one SDL_Init() call that's identical on all platforms, even though it does many opaque things underneath (and different things per platforms) is that it's easier to understand and use. The goal of an API is to be usable and useful, nothing else. Transparency can often get in the way of usability. As for the "bloated" bit. Well, I'd rather be able to do too many things than too few. It's a great goal to have a purely orthogonal (no method may be accomplished with another combination of methods) API, but it should not be done at the expense of usability. > Nothing should be put into it except what's impossible or impractical to do in pure Lua, and what's extremely common and likely to be used in everyone's configs. The entire quote makes it seem even more damning to me. Why would you cater to what's "likely to be used in everyone's configs"? That's another way of saying "Let's support only the least common denominator" which to me seems like a bad philosophy. This philosophy would lead to twitter not having a friendship API because the only thing practically every api user does is login and (arguably) tweet, only a few deal with friendships or account settings. It would lead to linux not having a configuration option for running more than one physical CPU or hotswapping ram because the wide majority of people will never use these options. I'm happy that the author of this software decided to make it simple and it seems to be working here, but in the majority of cases of API design, I'd much rather the API be usable, not transparent, and large, not minimalistic. I'd rather be able to call a method that does some common activity for me which I could technically do myself in a 1000 lines of code than not have such a method because it's "bloat".
- geon 12y ago
  You can't really compare a platform speciffic "window manager" to a multiplatform 3D/2D rendering api.
prof_hobart 12y ago
I'm not sure I fully agree. For example > Hydra must be stable. It should never crash It's clearly better to have an app that never crashes than an equivalent one that crashes all the time. However, making sure that your app is 100% crash-free isn't a zero cost thing. It takes time and effort to (often, a lot of both) to get to a completely crash-free app, meaning that the app either costs more, takes longer, or has to compromise on features - or possibly all three. In some case, that trade off is clearly going to be worth it - I'd rather a self-driving car took 10 years longer to develop than have one that rebooted itself twice a day, but in others I'm fine living with the occasional crash if it means cheaper or more feature-rich applications.
- sitkack 12y ago
  For a window manager, crashing is kinda a pain depending how it restarts. Maybe another way to state the implicit goal would be > Hydra must gracefully and rapidly restart should it crash w/o losing any user data. And then maybe it could do this be serializing state into a sqlite or redis instance. We always to be careful of muddling the goal and the mechanism.
  - prof_hobart 12y ago
    I agree. Like I say, there are some instances where zero crashes is absolutely the right goal. It may not be absolutely mandatory for a window manager (in the way it would be for a self-driving car), but I can understand why someone would want this as a goal for this app. My point was more that I don't think it's a sensible standard for all software. I hear this kind of thing quite regularly, usually by non-technical managers, often in a way that seems to suggest they think bugs are either the result of pure sloppiness, incompetence or downright malice.
rossjudson 12y ago
"Bloat" is emotional, not factual. It's meaningless without well-justified examples and alternatives.

sdegutis 12y ago

Can you give an example of the kinds of samples you would like to see, and where you would look for them? (I presume under the Examples section on the README page?) That will help me know what to put there.

colinramsay 12y ago
You have a link to your own config and some screenshots of it in action, maybe it would be good to pull out the relevant sections of your config so people can replicate what they see in the screenshots?
- sdegutis 12y ago
  Not a bad idea, will do. Thanks.

cheepin 12y ago

Hail Hydra!

Vanayad 12y ago
Came here for this. Didn't leave disappointed.

chc 12y ago

I don't think "Must never use more than 10 MB of memory" is a reasonable standard to hold all software to.

kennywinker 12y ago
Nope, but I would venture to guess that most software would be improved by sticking to that.
- chc 12y ago
  I don't even feel confident in that claim. If keeping memory usage under 10 MB requires a significant amount of developer effort, that is effort that isn't going into something else that I might value a lot more than, say, 20 MB of RAM.
  - georgemcbay 12y ago
    Not just developer effort, but also sometimes program runtime efficiency. RAM is cheap, RAM is pretty fast (compared to disk or network); cache shit there when it makes sense to do so for overall efficiency. 10MB is a fairly ridiculous modern standard to limit yourself to, IMO (and I started on the C64 and generally do dislike and try to avoid bloat).
TD-Linux 12y ago
To put this in perspective, a full screen application running on a Retina display needs at least 40MB total for its front and back buffers.

euank 12y ago

I do not like the "API should be completely transparent" and "API must not be bloated". I personally think APIs exist to hide complexity. They should make sense, they should be usable, but they need not be transparent. Let's have a rather contrived example. In SDL, you can call SDL_Init(). That does a lot of things, and what it does differs on windows, linux, and OSX. I absolutely don't want the more transparent API of SDL_Init_Windows_Video(), SDL_Init_Windows_Audio(), SDL_Init_Linux_Video() .... And so on. Realistically, for absolute transparency, you'd just do away with the API and write every line of code SDL currently hides (Reductio ad absurdum I know) The entire point of having that one SDL_Init() call that's identical on all platforms, even though it does many opaque things underneath (and different things per platforms) is that it's easier to understand and use. The goal of an API is to be usable and useful, nothing else. Transparency can often get in the way of usability. As for the "bloated" bit. Well, I'd rather be able to do too many things than too few. It's a great goal to have a purely orthogonal (no method may be accomplished with another combination of methods) API, but it should not be done at the expense of usability. > Nothing should be put into it except what's impossible or impractical to do in pure Lua, and what's extremely common and likely to be used in everyone's configs. The entire quote makes it seem even more damning to me. Why would you cater to what's "likely to be used in everyone's configs"? That's another way of saying "Let's support only the least common denominator" which to me seems like a bad philosophy. This philosophy would lead to twitter not having a friendship API because the only thing practically every api user does is login and (arguably) tweet, only a few deal with friendships or account settings. It would lead to linux not having a configuration option for running more than one physical CPU or hotswapping ram because the wide majority of people will never use these options. I'm happy that the author of this software decided to make it simple and it seems to be working here, but in the majority of cases of API design, I'd much rather the API be usable, not transparent, and large, not minimalistic. I'd rather be able to call a method that does some common activity for me which I could technically do myself in a 1000 lines of code than not have such a method because it's "bloat".

geon 12y ago
You can't really compare a platform speciffic "window manager" to a multiplatform 3D/2D rendering api.

prof_hobart 12y ago

I'm not sure I fully agree. For example > Hydra must be stable. It should never crash It's clearly better to have an app that never crashes than an equivalent one that crashes all the time. However, making sure that your app is 100% crash-free isn't a zero cost thing. It takes time and effort to (often, a lot of both) to get to a completely crash-free app, meaning that the app either costs more, takes longer, or has to compromise on features - or possibly all three. In some case, that trade off is clearly going to be worth it - I'd rather a self-driving car took 10 years longer to develop than have one that rebooted itself twice a day, but in others I'm fine living with the occasional crash if it means cheaper or more feature-rich applications.

sitkack 12y ago
For a window manager, crashing is kinda a pain depending how it restarts. Maybe another way to state the implicit goal would be > Hydra must gracefully and rapidly restart should it crash w/o losing any user data. And then maybe it could do this be serializing state into a sqlite or redis instance. We always to be careful of muddling the goal and the mechanism.
- prof_hobart 12y ago
  I agree. Like I say, there are some instances where zero crashes is absolutely the right goal. It may not be absolutely mandatory for a window manager (in the way it would be for a self-driving car), but I can understand why someone would want this as a goal for this app. My point was more that I don't think it's a sensible standard for all software. I hear this kind of thing quite regularly, usually by non-technical managers, often in a way that seems to suggest they think bugs are either the result of pure sloppiness, incompetence or downright malice.

rossjudson 12y ago

"Bloat" is emotional, not factual. It's meaningless without well-justified examples and alternatives.