6 ms·

> The idea with Bear is to refine the existing features to the point of perfection, instead of building new features or pushing monetisation. I love this. I wi

> The idea with Bear is to refine the existing features to the point of perfection, instead of building new features or pushing monetisation. I love this. I wish more software was built with limited scope. Not every application needs to grow larger and change forever.

urthor 4y ago
Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were. To get adopted, your "total experience" must be better the status quo. So, authors of software need "de facto" integrations with other products. To handle features their product doesn't. Unix utilities do "limited scope" brilliantly. In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope. Every year the "status quo" in software rises that much higher. Providing a better experience increasingly requires ever more resources to push a project to adoption.
- valenterry 4y ago
  > In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope. As in Scala the programming language? I find it is exactly the opposite. Scala is complicated and hard to learn, but if it can do anything well then it is allowing tools/libraries to be well-scoped and composed by the user. To give an example: In Scala there are 3 libraries: - One for http requests - One for async calls - One for json (de)serialization Those libraries don't know anything of each other and don't use the same interfaces/types, so by default you have to do some plumbing to make them work together. But there are 2 more libraries: - One that provides integration of http and json - One the provides integration of http and async As an end user that wants to build an async web app that uses json, you just have to add those 5 libraries and 5 imports and then everything just magically works out of the box. And it compile-time safe. No reflection or magic things happening. If anything doesn't work out, for example due to version differences, then it just doesn't compile and you adjust the plumbing yourself or update the libraries. I seriously don't know any even half popular language that supports that. Take Rust for example. Rust has traits and allows you to make whatever types you have become compatible. But you can't write libraries on top of existing ones to do the plumbing for the user who then just picks the plumbing they like.
  - anonymoushn 4y ago
    Which of these libraries does I/O, and why is it any of them? In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work.
    - valenterry 4y ago
      Depends on what you mean by IO. The http library can be used without IO (i.e. you give it a request and it gives you the response and potentially does some effect (but that's e.g. done through the async library). But it also includes functionality to bind to a port and listen to requests there in the way the async library (or maybe a streaming library) controls etc. > In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work. Of course. Now imagine you need backpressure (reactive streaming) and writer/reader interfaces don't support that. Can someone provide you a library that you import and then automatically the types of the TLS library change and it works with the new interfaces that it doesn't even know exist? Because that's what I'm talking about.
      - anonymoushn 4y ago
        I/O usually means syscalls, I guess. If I install a library to encode and decode a protocol and it has no mode of operation that performs 0 syscalls, it is defective. I'm not sure how "write does not even return until the writing is done" can avoid handling backpressure. Unfortunately, I have had to add calls to flush() to the TLS library because it was not made with buffered writers in mind. I guess instead of writing flush() a couple of times I could have written a library that wraps a pair of buffered writer and reader in a new reader which flushes the writer if necessary when you read it and wraps the TLS library so that the passed-in reader and writer are automatically wrapped by that new reader. This sounds like a bit much though, since the whole task was to call flush a couple times only during TLS handshakes only if flush was defined.
- JamesianP 4y ago
  > Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were. Ok but now everyone who doesn't need that new better experience doesn't get their code broken anymore right? So it isn't a wash, we've gained a benefit.
9dev 4y ago
This feels pointless. The world is in constant flux. There is nothing that’s ever perfect, or lasting, because the red queen keeps on running. Software should change to adapt, or it will become useless.
- phil-martin 4y ago
  It feels like the idea of refining something to the goal perfection is not mutually exclusive to the idea of being adaptable. To me it implies that since the definition of perfection is always changing, you are continually altering course to get closer to where you want to be.
- bottled_poe 4y ago
  Maybe at a certain point it just makes more sense to build something new instead of endless iterations.
- adrianN 4y ago
  Lots of tools haven't changed much in centuries.
  - johnfn 4y ago
    It's hard to think of any single tool which hasn't been superseded along some axis. People still use pens, for example. But if they want to write 100 copies of the same page, they'd much rather use a printer. People use hammers, but if they want to hammer in ten thousand nails, they might start thinking about automatic tools.
    - HermanMartinus 4y ago
      That's completely true. In this analogy Bear is intended to be the pen. Yes, printers are great, but pens are by no means obsolete.
      - dagw 4y ago
        But the pen you use today is quite different from a pen you would have used 100 years ago. Most people would not want to use 100 year old pen design as their 'daily driver'
drpixie 4y ago
I'm with CleverLikeAnOx on this. I known it goes against the prevailing HN ethos, but more-features-more-monetisation does not necessarily produce the best product. (In fact, I don't think it will ever produce the best product.) Think of those tools that you've really enjoyed using - perhaps the mid-range HP calculators, or a great fountain pen or knife, or even a spanner that just fits perfectly. These are all tools that have been designed with a clear idea of their purpose, and their design has focused on that purpose. A great chef's knife doesn't incorporate a bottle-opener - that could be added but it would be a less usable knife. Memorable products have long life-spans. Users treasure their fountain pen, often for life. I'm still disappointed at the loss of my HP11C. But who is going to mourn a programming language or front-end that drops out of favour because it's grown unusably big and cumbersome as the designers increase scope. When it comes to their next project, users will consider something cleaner, something that does all but only what they need.
- trenchgun 4y ago
  > I known it goes against the prevailing HN ethos, but more-features-more-monetisation does not necessarily produce the best product. What? Minimalism is very much favoured in HN. Unix-philosophy: do one thing well
dusted 4y ago
Reminds me of a previous job where IT wouldn't let me install netcat, because "it hadn't been updated since like forever", my response: "because it's fucking done", I was eventually permitted to install it..
- amtamt 4y ago
  Was it because it hadn't been updated or was considered a "hacking tool"?
  - Cthulhu_ 4y ago
    I mean "outdated software is unsafe" is a frequently mentioned adage; it's a good catch-all if you can't look into individual software.
  - dusted 4y ago
    Dunno, I had ethereal and tcpdump installed at the moment so I don't think so
    - lll-o-lll 4y ago
      How many hundreds of years ago was this? Ethereal has been Wireshark since 2006.
      - dusted 4y ago
        so obviously not that long ? might have been called wireshark at the time tbh :)
- rommel917 4y ago
  I had something similar when we had rewriten old application, and biggest change was move from WebSphere to Tomacat. First question we got was "What is missing in WebSpere?". Nothing is missing it had to much bloat we don't use.
ChrisMarshallNY 4y ago
I agree. I was going to say something similar, and wanted to highlight that exact sentence. I’ve written software that has lasted over 25 years. That’s not forever, but it’s nothing to sneeze at. I’ve found the secret to long-lasting software, is to use boring tech. Put away the Buzzword Bingo cards.
- Cthulhu_ 4y ago
  https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology I've given a talk at work about this one (but it ended up being more about people and kneejerk decision making processes where something cool is picked instead of something reliable), it resonated with a lot of people. I'm still hoping to get to work with Go again sometimes, I think it embodies the adage pretty well in that it's resistant to change; I'm confident code written today in Go is still going to be the same and working in ten years' time, unlike any other programming language I've worked in.
  - hamdouni 4y ago
    Hey, I have an web app written in Go in 2015 still running for one of my clients ! Pretty close to 10 years ;-)
hrbf 4y ago
I cannot stress enough how much I love this as well. This is what we need, all of us, all the time. It’s more common in traditional handcrafting and should be a guiding light for the future of tech. Less is more. Less but better (to invoke Dieter Rams here). The goal should be a slow, incremental improvement over time, towards perfection.

urthor 4y ago

Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were. To get adopted, your "total experience" must be better the status quo. So, authors of software need "de facto" integrations with other products. To handle features their product doesn't. Unix utilities do "limited scope" brilliantly. In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope. Every year the "status quo" in software rises that much higher. Providing a better experience increasingly requires ever more resources to push a project to adoption.

valenterry 4y ago
> In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope. As in Scala the programming language? I find it is exactly the opposite. Scala is complicated and hard to learn, but if it can do anything well then it is allowing tools/libraries to be well-scoped and composed by the user. To give an example: In Scala there are 3 libraries: - One for http requests - One for async calls - One for json (de)serialization Those libraries don't know anything of each other and don't use the same interfaces/types, so by default you have to do some plumbing to make them work together. But there are 2 more libraries: - One that provides integration of http and json - One the provides integration of http and async As an end user that wants to build an async web app that uses json, you just have to add those 5 libraries and 5 imports and then everything just magically works out of the box. And it compile-time safe. No reflection or magic things happening. If anything doesn't work out, for example due to version differences, then it just doesn't compile and you adjust the plumbing yourself or update the libraries. I seriously don't know any even half popular language that supports that. Take Rust for example. Rust has traits and allows you to make whatever types you have become compatible. But you can't write libraries on top of existing ones to do the plumbing for the user who then just picks the plumbing they like.
- anonymoushn 4y ago
  Which of these libraries does I/O, and why is it any of them? In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work.
  - valenterry 4y ago
    Depends on what you mean by IO. The http library can be used without IO (i.e. you give it a request and it gives you the response and potentially does some effect (but that's e.g. done through the async library). But it also includes functionality to bind to a port and listen to requests there in the way the async library (or maybe a streaming library) controls etc. > In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work. Of course. Now imagine you need backpressure (reactive streaming) and writer/reader interfaces don't support that. Can someone provide you a library that you import and then automatically the types of the TLS library change and it works with the new interfaces that it doesn't even know exist? Because that's what I'm talking about.
    - anonymoushn 4y ago
      I/O usually means syscalls, I guess. If I install a library to encode and decode a protocol and it has no mode of operation that performs 0 syscalls, it is defective. I'm not sure how "write does not even return until the writing is done" can avoid handling backpressure. Unfortunately, I have had to add calls to flush() to the TLS library because it was not made with buffered writers in mind. I guess instead of writing flush() a couple of times I could have written a library that wraps a pair of buffered writer and reader in a new reader which flushes the writer if necessary when you read it and wraps the TLS library so that the passed-in reader and writer are automatically wrapped by that new reader. This sounds like a bit much though, since the whole task was to call flush a couple times only during TLS handshakes only if flush was defined.
JamesianP 4y ago
> Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were. Ok but now everyone who doesn't need that new better experience doesn't get their code broken anymore right? So it isn't a wash, we've gained a benefit.

9dev 4y ago

This feels pointless. The world is in constant flux. There is nothing that’s ever perfect, or lasting, because the red queen keeps on running. Software should change to adapt, or it will become useless.

phil-martin 4y ago
It feels like the idea of refining something to the goal perfection is not mutually exclusive to the idea of being adaptable. To me it implies that since the definition of perfection is always changing, you are continually altering course to get closer to where you want to be.
bottled_poe 4y ago
Maybe at a certain point it just makes more sense to build something new instead of endless iterations.
adrianN 4y ago
Lots of tools haven't changed much in centuries.
- johnfn 4y ago
  It's hard to think of any single tool which hasn't been superseded along some axis. People still use pens, for example. But if they want to write 100 copies of the same page, they'd much rather use a printer. People use hammers, but if they want to hammer in ten thousand nails, they might start thinking about automatic tools.
  - HermanMartinus 4y ago
    That's completely true. In this analogy Bear is intended to be the pen. Yes, printers are great, but pens are by no means obsolete.
    - dagw 4y ago
      But the pen you use today is quite different from a pen you would have used 100 years ago. Most people would not want to use 100 year old pen design as their 'daily driver'

drpixie 4y ago

I'm with CleverLikeAnOx on this. I known it goes against the prevailing HN ethos, but more-features-more-monetisation does not necessarily produce the best product. (In fact, I don't think it will ever produce the best product.) Think of those tools that you've really enjoyed using - perhaps the mid-range HP calculators, or a great fountain pen or knife, or even a spanner that just fits perfectly. These are all tools that have been designed with a clear idea of their purpose, and their design has focused on that purpose. A great chef's knife doesn't incorporate a bottle-opener - that could be added but it would be a less usable knife. Memorable products have long life-spans. Users treasure their fountain pen, often for life. I'm still disappointed at the loss of my HP11C. But who is going to mourn a programming language or front-end that drops out of favour because it's grown unusably big and cumbersome as the designers increase scope. When it comes to their next project, users will consider something cleaner, something that does all but only what they need.

trenchgun 4y ago
> I known it goes against the prevailing HN ethos, but more-features-more-monetisation does not necessarily produce the best product. What? Minimalism is very much favoured in HN. Unix-philosophy: do one thing well

dusted 4y ago

Reminds me of a previous job where IT wouldn't let me install netcat, because "it hadn't been updated since like forever", my response: "because it's fucking done", I was eventually permitted to install it..

amtamt 4y ago
Was it because it hadn't been updated or was considered a "hacking tool"?
- Cthulhu_ 4y ago
  I mean "outdated software is unsafe" is a frequently mentioned adage; it's a good catch-all if you can't look into individual software.
- dusted 4y ago
  Dunno, I had ethereal and tcpdump installed at the moment so I don't think so
  - lll-o-lll 4y ago
    How many hundreds of years ago was this? Ethereal has been Wireshark since 2006.
    - dusted 4y ago
      so obviously not that long ? might have been called wireshark at the time tbh :)
rommel917 4y ago
I had something similar when we had rewriten old application, and biggest change was move from WebSphere to Tomacat. First question we got was "What is missing in WebSpere?". Nothing is missing it had to much bloat we don't use.

ChrisMarshallNY 4y ago

I agree. I was going to say something similar, and wanted to highlight that exact sentence. I’ve written software that has lasted over 25 years. That’s not forever, but it’s nothing to sneeze at. I’ve found the secret to long-lasting software, is to use boring tech. Put away the Buzzword Bingo cards.

Cthulhu_ 4y ago
https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology I've given a talk at work about this one (but it ended up being more about people and kneejerk decision making processes where something cool is picked instead of something reliable), it resonated with a lot of people. I'm still hoping to get to work with Go again sometimes, I think it embodies the adage pretty well in that it's resistant to change; I'm confident code written today in Go is still going to be the same and working in ten years' time, unlike any other programming language I've worked in.
- hamdouni 4y ago
  Hey, I have an web app written in Go in 2015 still running for one of my clients ! Pretty close to 10 years ;-)

hrbf 4y ago

I cannot stress enough how much I love this as well. This is what we need, all of us, all the time. It’s more common in traditional handcrafting and should be a guiding light for the future of tech. Less is more. Less but better (to invoke Dieter Rams here). The goal should be a slow, incremental improvement over time, towards perfection.