[HN Gopher] A 2024 plea for lean software
___________________________________________________________________
A 2024 plea for lean software
Author : pseudolus
Score : 139 points
Date : 2024-02-09 15:15 UTC (7 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| geodel wrote:
| Lately I have seen developers are nuking the bloat by converting
| existing applications to hundreds/thousands of ultra slim micro
| services. I applaud this approach of taking this issue head on at
| least in server side domains.
| namaria wrote:
| > hundreds/thousands of ultra slim micro services
|
| Sounds to me like trading one type of bloat for another.
| 7thaccount wrote:
| More macro level complexity for sure, but I guess you
| eliminate some issues from having all that as a monolith.
| namaria wrote:
| And create many others by having networking being now part
| of your architecture. Bloat is bloat, changing how it's
| distributed isn't getting at the problem.
| infogulch wrote:
| Yes this is a great move, turning code bloat problems into
| a distributed systems bloat problem is definitely an
| improvement.
| shrimp_emoji wrote:
| We'll break the elephant apart into a brainiphant, a
| heartiphant, a liveriphant, two lungiphants, and they'll
| all agree over a communication protocol with which to
| exchange matter and energy.
|
| It's more a way to enforce API boundaries than reducing
| complexity. I guess when you have some anxiety about your
| ability to do so otherwise.
| thfuran wrote:
| If the goal is just to have harder boundaries, it seems
| like entirely the wrong tool for the job and comes with a
| ton of unnecessary baggage. Something like java's module
| system seems like a much better way to try to enforce API
| boundaries. Of course, there are languages that lack an
| equivalent but which can be used to write microservices.
| troupe wrote:
| Agreed, and if security is an issue, creating network
| connections between every single piece of your
| application seems to exponentially increase the attack
| surface.
| meindnoch wrote:
| Can't tell if sarcastic or not.
| Sohcahtoa82 wrote:
| In a sane world, this would be satire, but I really can't tell
| these days.
|
| Have people taken "Function-as-a-Service" too literally and
| done the equivalent of moving "is_even" into an AWS Lambda? Or
| maybe have a dedicated "is_even" nano-service with its own
| Kubernetes cluster?
| geodel wrote:
| You are thinking in right direction. Ultra small but critical
| service like "is_even" and combining it with reliability of a
| kubernetes cluster, that is genius level stuff.
| mouse_ wrote:
| See OpenVPN (~70k lines of code) being replaced with WireGuard
| (~4k lines of code), resulting in far less vulnerabilities and
| performing far better on top of that.
| christophilus wrote:
| > We are likely looking at over 50 million active lines of code
| to open a garage door, running several operating-system images on
| multiple servers.
|
| It is kind of insane when you see it written out that way. It is
| staggering how much code I'm running right now on my machine as I
| type this-- code that I never reviewed and that very likely
| hasn't had much rigorous review at all. :/
|
| Well, back to installing npm dependencies.
| MrDresden wrote:
| 'Do less, but do better' is a mantra that could do with being
| applied more often.
| surfpel wrote:
| Dieter Rams mantra is "Less, but better"
|
| His 10 principles guide everything I create.
| lifeisstillgood wrote:
| >>> Software is now (rightfully) considered so dangerous that we
| tell everyone not to run it themselves. Instead, you are supposed
| to leave that to an "X as a service" provider, or perhaps just to
| "the cloud." Compare this to a hypothetical situation where cars
| are so likely to catch fire that the advice is not to drive a car
| yourself, but to leave that to professionals who are always
| accompanied by professional firefighters.
|
| I'm stealing that line :-)
| bryanlarsen wrote:
| If cars were invented in 2024, there's no way that the general
| public would be permitted to drive them. We freak out over new
| products that result in a few deaths, let alone 40,000 per
| year.
| samtho wrote:
| This is hard to say because an alternate universe where the
| car didn't exist would be quite different and may have not
| led to our contemporary understanding and management of risk
| in the first place.
| lcnPylGDnU4H9OF wrote:
| I'm not so convinced. People talk similarly about the issues
| that smart phones have caused with the rise of social media
| but only fringe political groups want their use restricted by
| law (with exceptions, such as while driving). I'd expect the
| most popular opinion to be that the convenience outweighs the
| cost.
|
| (Of course, as a sibling comment points out, it's impossible
| to really know.)
| supertrope wrote:
| Status quo bias is very strong. If you proposed accepting
| tens of thousands of fatalities per year, bulldozing entire
| city neighborhoods, kids not being able to cross the street
| safely, smog, and constant traffic noise people would be
| horrified. One common justification NIMBYs use is increased
| traffic aka the burden other drivers impose on a neighborhood
| by driving through. Ironically instead of identifying the
| root of the problem (too many cars and the subsidized
| infrastructure supporting them) they blame one of the
| solutions (more housing).
| Karellen wrote:
| > Software is now (rightfully) considered so dangerous that we
| tell everyone not to run it themselves. Instead, you are
| supposed to leave that to an "X as a service" provider, or
| perhaps just to "the cloud."
|
| Well, that's what cloud providers tell you. And their
| employees, whose salaries depend on them not understanding
| otherwise.
| mk89 wrote:
| In my experience, it's not that simple as you make it sound.
|
| In some cases, especially due to some compliance
| (ISO27001/SOC2-3, Fedramp, etc.) companies implement a proper
| management of CVEs. It has become a standard practice
| (typically, this is part of the Enterprise subscription of
| the SAAS/product of choice).
|
| Having a service/lib/whatever that uses a crappy lib that
| doesn't get a CVE fixed in a specific timeframe can lead you
| to miss the SLA you define with your customers (e.g., "we fix
| high risk CVEs in 90 days and critical in 30 days", that kind
| of stuff).
|
| For such companies having a service like that which is
| probably not even core business can become really a cost,
| especially because Enterprise companies will push very hard
| on you to make those CVEs fixed. I have seen colleagues
| working over weekends just to have 1 single CVE because of 1
| single company pushing us really hard to fix that stuff. It
| was a big contract, you don't want to lose it.
|
| So, yes: paying X$ to someone that promises you "we take care
| of CVEs", etc. can be a win. You're not just buying software:
| you are in a sense buying some accountability, although at
| the end of the day YOU are what the customer sees, not your
| SaaS behind the scenes.
| supertrope wrote:
| All so that these vendors can mis-configure a S3 bucket or
| use the password "solarwinds123."
| thimp wrote:
| Can I just point out that the vast majority of users I know are
| basically teetering on the edge of the cliff of losing
| everything they have ever done. I'm not suggesting that selling
| your soul to the SaaS vendors (disclaimer: I work for one) is
| the right solution. In fact some of them you're probably better
| setting fire to your data than trusting them (disclaimer: I
| work for one of those!).
|
| Example my now ex-girlfriend was distrusting of "the cloud",
| for rational reasons I will add thanks to a former Eastern Bloc
| childhood. However the alternative solution was hoping she
| wasn't going to lose the HP laptop she'd paid bottom dollar
| for. Some education later and she had peace of mind, at least
| on that front.
|
| What we have is a general lack of education and consideration
| of what the consequences of that lack of education are. The end
| game is that you either have to accept the risk, and I've seen
| many a tear there, educate yourself, and I've not seen much of
| that, or suck up to the SaaS and cloud vendors.
|
| It's a matter of personal responsibility and no one seems to
| have it so leaving that to the professionals (ha!) might be a
| less bad solution that trusting yourself.
|
| Education is the right answer though but hopeless. I'm not sure
| if my post has a conclusion but it sure depresses me re-reading
| it.
| nonrandomstring wrote:
| One more cheer for suckless [0] philosophy. Hoorah!
|
| [0 ]https://suckless.org/
| Mistletoe wrote:
| Is software bloated because that's the only way for everyone to
| justify promotions and salary increases? It's hard to get a
| promotion for slimming down your program to a tiny size and it
| still works perfectly and is exactly what the user wants/needs.
| But that is exactly how promotions and bonuses should work.
| namaria wrote:
| I think the huge influx of money into technology has been akin
| to pumping energy into a closed system. Entropy went through
| the roof.
| amelius wrote:
| Since Eternal September it hasn't been a closed system.
| namaria wrote:
| Closed systems can communicate with other systems/their
| environment. Closed doesn't mean sealed here, it means well
| defined boundaries.
|
| edit: ok so for thermodynamics analogy purposes, the
| statement 'closed system' means no matter flows but energy
| obviously yes... furthermore, 'the tech system' being made
| of isolated computers and specialized professionals, or
| networks of computers and specialized professionals is
| immaterial for the analogy... lots of energy flowing in, in
| the form of huge amounts of cash, created a lot of entropy,
| in the form of accidental complexity.
| chasd00 wrote:
| i know in the consulting world you always want to maximize the
| number of logos on any given architecture diagram.
| zem wrote:
| no, it's bloated because that's the path of least resistance.
| it's easier to write code that builds on frameworks which build
| on libraries which build on virtual machines etc, and that is
| arguably even a better use of the programmer's time than doing
| everything from scratch, but the tooling hasn't kept pace to
| let us produce a final artefact that strips out all the bloat
| and collapses the layers into a small binary. (this is
| theoretically possible with a "sufficiently smart compiler",
| tree shaking, and a host of related techniques, but is
| impossibly hard in practice, given the current state of the
| art)
| nox101 wrote:
| Bloat is most libraries on npm. The authors don't know good
| design and instead try to make every library do everything. Oh,
| my library converts strings from one encoding to another, I'll
| make it load files for you, save files for you, download them
| over the internet, and give you a command line tool, all in the
| same repo. The library should just do its one thing. The rest
| should be left to the user.
|
| I get the impression it's no better in rust land. Go try to edit
| the rust docs. Watch it install ~1000 crates.
|
| The issue is not the language, it's that anyone can post a
| library (not complaining) and anyone does. People who "just want
| to get stuff done" choose the library with the most features and
| then beg for even more since they can't be bothered to write the
| 3 lines of code it would have been to solve it outside the
| library. "Can you add render to pdf?"
|
| I don't know how to solve it. My one idea is to start an "Low
| Dependency" advocacy group with a badge or something and push to
| get people to want that badge on their libraries and for people
| to look for that badge on libraries they choose.
| amelius wrote:
| The "3 more lines" problem can be solved by LLMs.
| mewpmewp2 wrote:
| Yeah honestly one key thing of copilot has been that I can
| create a fn definition I need that is very common and it will
| do the boilerplate for me. It feels dirty not using a
| library, but in the end I save bytes and have clear control
| over the fn that otherwise is quite standard.
| nehal3m wrote:
| A black box that turns a few megawatts and 60TB of data into
| a model that can write three lines is antithetical to lean
| anything
| PH95VuimJjqBqy wrote:
| > People who "just want to get stuff done" choose the library
| with the most features and then beg for even more since they
| can't be bothered to write the 3 lines of code it would have
| been to solve it outside the library.
|
| I feel this so much.
|
| I once had a contract for ruby on rails work. They were
| experiencing severe performance issues, so bad that they were
| developing in release mode (server won't detect a file change
| and reload for you).
|
| One day I get tired of it and start digging into it. I don't
| remember how many gems they were pulling in but it was A LOT. I
| came across one particular gem which saved 3 lines of code.
| Seriously.
|
| I stayed away from the RoR community after that. I recently
| picked up a contract for more RoR work (after all these years,
| lol) and ... it's not nearly as bad but it's not good either.
|
| Some communities just do NOT respect the risk that dependencies
| bring.
| crooked-v wrote:
| On this note, I wish more npm library authors would emulate
| sindresorhus's approach of making small packages that each do
| very specific things in a predictable and well-documented
| manner.
| whstl wrote:
| Hell no. This person is probably the worst offender in terms
| of supply-chain problems and bloat in the NPM ecosystem.
|
| A terminal spinner with 15 dependencies (including
| transitive) is not an example of good design.
|
| Inflating the numbers of downloads in your own packages is
| doing no good to the world of software.
| sweeter wrote:
| This is why I like Go and the stdlib. Its very much "do it
| yourself" unless we are talking about monumental libraries for
| very specific applications. Outside of that if we are talking
| about simple libraries that do one simple thing, its better to
| just roll your own using the stdlib. Almost all of the building
| blocks are there.
|
| On the other hand its really nice that any git repo can host a
| Go lib and anyone can use it from that url
| MrDresden wrote:
| Never used Go, but I much more prefer a proper stdlib that
| covers most base cases so that there isn't a need for
| rolling-your-own each time, or worse using a badly
| made/maintained bloated third party lib.
|
| Examples of excellent stdlibs in my opinion would be for
| instance Kotlin and Python.
| worble wrote:
| >Oh, my library converts strings from one encoding to another,
| I'll make it load files for you, save files for you, download
| them over the internet, and give you a command line tool, all
| in the same repo. The library should just do its one thing. The
| rest should be left to the user.
|
| >I don't know how to solve it. My one idea is to start an "Low
| Dependency" advocacy group with a badge or something and push
| to get people to want that badge on their libraries and for
| people to look for that badge on libraries they choose.
|
| It sounds like you're conflating low bloat and low dependency,
| which is like trying to have your cake and eat it too. If you
| want low bloat libraries, then it's likely you're going to be
| pulling a lot in that don't independently do much. If you want
| low dependency libraries, then you'll be pulling in a few that
| do do a lot.
|
| From my perspective I'd rather have slightly fatter libraries
| if they're low dependency and by authors I trust. Lodash for
| instance, sure it's big but the es6 module version supports
| tree shaking and it's basically the standard library JS never
| had. Same for something like date-fns for Date. I pretty much
| pull these two in by default into any project to fill those
| holes in JS's core library.
| whstl wrote:
| The problem comes from two sides.
|
| First you have package makers that want to make this into a
| career, and the only way to generate buzz is by having
| thousands of them. So they focus on generating packages that
| depends on others created by them, and on trying to get their
| one or two useful packages into someone else's code.
|
| The second is people who believe that the only solution to
| problems involves including a new package, without caring about
| how many dependencies it has, or even if the actual problems is
| actually hard to solve. So instead of learning how to solve the
| problem, they must learn the API of some wrapper with 4 GitHub
| stars.
| hgs3 wrote:
| > A typical app today is built on Electron JS
|
| Not enough folks seem to realize but you can use each platforms
| native web control rather than bundling electron. If you do that
| your distributed app can be in the kilobytes. This approach also
| gives you the freedom to use whatever backend programming
| language / tech stack you want so long as it can communicate with
| the web view.
| moralestapia wrote:
| How?
| jsheard wrote:
| I think Tauri is the most established "like Electron but with
| the system webview" framework. It supports wiring up native
| Rust code behind the webview frontend.
|
| https://tauri.app
|
| The obvious downside compared to Electron, besides maturity,
| is you have to test the frontend on multiple browser engines
| rather than just bundling Chromium everywhere and calling it
| a day. It uses Microsofts flavor of Chromium on Windows,
| Apples flavor of WebKit on their platforms, and WebKitGTK on
| Linux.
| grujicd wrote:
| There's a small problem with Windows, there are no
| guarantees you'll have Chromium based Edge installed on a
| system. You'll have to download and install it if not
| present, and when I looked it was 100+MB. Sure, you don't
| have to include it in installer, but you have to account
| for that case.
| jsheard wrote:
| I haven't tried it but according to the docs their
| installer will automatically download Chromium Edge if
| it's not already installed, so the user doesn't have to
| deal with it, and Windows 11 has it out of the box so
| that case will only trigger on older versions.
| hgs3 wrote:
| You can create the web control using each platforms native
| GUI toolkit and setup JS communication yourself OR you can
| use a lightweight library that does it for you [1] (search
| this projects README for language "bindings").
|
| [1] https://github.com/webview/webview
| grujicd wrote:
| You still need access to native menus, clipboard, dialogs,
| drag&drop, etc. There are no light multiplatform libraries
| for that afaik. Either you'll use Electron, which is more
| or less these services + browser. Or you'll use some of
| full multiplatform GUIs, which all have their limitations
| and drawbacks. Potentially you can use hybrid - web control
| inside one of multiplatform GUIs (if web control is
| available at all), but you'll have to reimplement some IPC
| stuff for communicating with web part. That part already
| exists for Electron. And you'll still have to rely on this
| multiplatform GUI and deal with its issues. There's also a
| matter of trust, Electron if nothing else has VS Code, so
| we all know that production ready application is possible,
| even if it's not trivial. It's not that clear cut for
| Avalonia, MAUI, etc.
| edflsafoiewq wrote:
| "Lean software" doesn't just mean download size.
| hgs3 wrote:
| With the native web control approach you can write the bulk
| of your app in whatever efficient programming language / tech
| stack you want (Rust, C, C++, Go, whatever). The webview need
| only be for presentation - the 'V' in MVC. You aren't stuck
| with Node.js.
| petabyt wrote:
| And the app takes several seconds to start up, it's slow, and
| ends up using more RAM than electron because the user isn't
| using the native webview as their main browser.
| jurschreuder wrote:
| This is what I keep saying about Rust.
|
| Maybe you have 70% fewer vulnerabilities per line of code than
| C++ if really 70% of (old) C++ vulnerabilities are memory
| related.
|
| But if you then pull in hundreds of packages in Rust and have 10x
| as many lines of code...
|
| 30% of 100k lines is more in total than 100% of 10k lines of
| code.
| tcoff91 wrote:
| memory related vulnerabilities tend to be the worst kind
| though, like RCEs and stuff. Remote code execution is so much
| worse than many other types of vulnerabilities like DOS. How
| many RCEs have there been in rust programs compared with C++? I
| bet C++ has far more than 70% more RCE frequency than rust.
| bsdpufferfish wrote:
| Only for software directly connected to the internet. Unix
| process separation is a thing too.
| estebank wrote:
| Counting crates and comparing that with number of C++ libraries
| is making an obtological error. In Rust, a single team usually
| splits their project in multiple crates. Something like QT
| would be hundreds of crates on its own if it were written in
| Rust, but the amount of code and level of risk taken would be
| exactly the same.
| jsheard wrote:
| Plus many crates have zero unsafe code, so they're not much
| of a liability at least in terms of the common memory safety
| problems. The nice thing about unsafe code having to be
| declared is you can get an idea of a crates attack surface at
| a glance just by grepping for it - if only evaluating C/C++
| libraries were so easy.
| PhilipRoman wrote:
| >you can get an idea of a crates attack surface at a glance
| just by grepping for it
|
| please don't... I understand your point but there are
| hundreds of vulnerabilities introduced every day in memory-
| safe languages that have nothing to do with rust's concept
| of "unsafe".
| PH95VuimJjqBqy wrote:
| no, absolutely not, and I have no idea where this
| misapprehension came from.
|
| the root cause of a problem in unsafe could can absolutely
| be from safe code because the safe code can set state in a
| way that causes problems.
|
| One can easily see this if you consider safe code that sets
| an index and then calls into unsafe code but the index is
| out of range. The root cause is absolutely in the safe
| code.
| jsheard wrote:
| There has to _be_ unsafe code for that to happen though,
| if you consume a crate which doesn 't touch unsafe at all
| then it's only going to happen if _you_ write the sloppy
| unsafe code which makes assumptions that don 't actually
| hold. That's not a safety issue in the crate, it's a
| safety issue in your crate, it's on whoever writes the
| unsafe block to do their due diligence.
| steveklabnik wrote:
| https://wiki.alopex.li/LetsBeRealAboutDependencies is an
| interesting exploration of these dynamics.
| Ygg2 wrote:
| > But if you then pull in hundreds of packages in Rust and have
| 10x as many lines of code...
|
| No one is forcing you to use the libraries. Just write your own
| software stack yourself.
|
| But big problem is vulnerablilities. Is it better to fix
| hundred libs by fixing a bug in one shared lib or is it better
| to fix hundred libs one by one?
| sharas- wrote:
| "Writing has been called the process by which you find out you
| don't know what you are talking about.
|
| Actually doing stuff, meanwhile, is the process by which you find
| out you also did not know what you were writing about."
|
| Why architects code: https://bitslap.it/blog/posts/why-
| architects-code.html
| cptaj wrote:
| In Vernor Vinge's book A Deepness in the Sky, humanity is spread
| out around the stars with only subluminal technology.
| Interstellar ships are very old and mix many technologies from
| different systems and civilizations.
|
| They touch on the fact that computer systems have evolved for so
| long that nobody really knows most of the code anymore. They just
| use it and build on top of it.
|
| One particular character has been traveling and in stasis so long
| that he is probably one of the oldest humans alive. A systems
| engineer of old. It turns out to be a big advantage to know the
| workings and vulnerabilities of his time because he can use them
| in the future when everyone else is building many layers on top
| of that and have no way of knowing exactly what he's doing.
|
| Vernor had a point, I think.
| peter_l_downs wrote:
| Vinge definitely got it right. I love the title of "Programmer
| Archaeologist", it's an extremely good description of what we
| actually do every day.
|
| For more discussion, see http://lambda-the-
| ultimate.org/node/4424
| rvbissell wrote:
| Oh man, 3 more novels to read -- thanks!
| pavel_lishin wrote:
| For what it's worth, while the first two are set in the same
| universe, you can read them in either order. The third one is
| a definite sequel, and imo, the weakest of the three.
| AdamH12113 wrote:
| What amazes me is how many people (even here) will leap to their
| feet to defend an exponential increase in complexity to provide a
| minuscule improvement in convenience from putting their garage
| door/fridge/front door/etc. on the internet. I really hope the
| garage door opener bit is a joke (they come with radio remote
| controls!), but I have a bad feeling it's not.
|
| I can almost see how this sort of thing _could_ work -- a secure
| LAN for the house with appliance controls based on open protocols
| driven by a local server. Your phone would talk to the server via
| a LAN (in-house) or a VPN (remotely), decoupling the connectivity
| from the actual control. Heck, while we 're at it, drop IP from
| the appliances entirely and use some low-bandwidth power line
| communication system (X10?) -- no need for an OS at all.
|
| That would require a lot of industry coordination, though, and in
| an age of walled gardens and digital surveillance I don't see it
| happening anytime soon.
| Semaphor wrote:
| I don't really see those comments, everyone usually talks about
| how people are stupid for getting cloud devices instead of
| going local with something like home assistant
| AdamH12113 wrote:
| Home Assistant looks like at least 80% of what I was
| imagining. Glad to see that some serious work is going into
| this.
| ryandrake wrote:
| Also, a lot of software developers will defend the exponential
| increase in complexity by pointing to developer comfort and
| speed. Building on top of these 40 layers of abstraction is
| easier and faster for the developer, so therefore it's always
| worth it. Binary/download size, performance, security issues,
| user experience... so much can get sacrificed at the altar of
| developer convenience if we let it.
|
| It gets defended because "developers are expensive" but nobody
| thinks of all the person-hours of our users' time lost because
| they are waiting for the code to execute up and down that class
| hierarchy...
| givan wrote:
| My approach to avoid bloat with Vvveb CMS was to avoid general
| purpose frameworks and libraries that do 1 thing I want and 100
| more that I don't.
|
| Even if it's harder to get started in the end it's less time
| spent because you know the code better and the code is not
| adapted around the library and it can better follow the
| application design.
|
| This approach made everything lean and easy to develop and as a
| bonus everything is rocket fast.
| pcardoso wrote:
| Congrats, looks very good.
| givan wrote:
| Thank you.
| galleywest200 wrote:
| That Github they linked in the article with 1,600 (!!!)
| dependencies. Out of all of the programs ever written, this is
| certainly one of them. I am sorry to the programmer and this is
| not meant to be a slight on them, but holy moly.
|
| https://github.com/SashenJayathilaka/Photo-Sharing-Applicati...
| wahnfrieden wrote:
| That's not high
| crooked-v wrote:
| I think it's fair to note that a huge chunk of those come from
| react-scripts (and its own dependency Babel), though. I would
| bet that only a small fraction of all the depedencies are ever
| actually included in the output of the build.
| kps wrote:
| "Have you looked at a modern airplane? Have you followed from
| year to year the evolution of its lines? Have you ever thought,
| not only about the airplane but about whatever man builds, that
| all of man's industrial efforts, all his computations and
| calculations, all the nights spent over working draughts and
| blueprints, invariably culminate in the production of a thing
| whose sole and guiding principle is the ultimate principle of
| simplicity?
|
| "It is as if there were a natural law which ordained that to
| achieve this end, to refine the curve of a piece of furniture, or
| a ship's keel, or the fuselage of an airplane, until gradually it
| partakes of the elementary purity of the curve of a human breast
| or shoulder, there must be the experimentation of several
| generations of craftsmen. It seems that perfection is attained
| not when there is nothing more to add, but when there is nothing
| more to remove."
|
| -- Antoine de Saint Exupery, _Terre des Hommes_
| RomanHauksson wrote:
| I would have liked to see some statistics cited instead of
| anecdotes about individual security incidents. Is industry
| software really less secure than it used to be because of larger
| attack surfaces, proportional to the size of the software
| industry?
| barnabee wrote:
| Over time I'm coming to two conclusions:
|
| 1. Standard libraries are the new operating systems
|
| 2. The only way to design reasonable (lean, secure, responsive,
| interoperable, reliable, long lasting, etc.) software is for rich
| and carefully thought out abstractions to be incorporated into
| operating system and/or standard library APIs.
|
| We have to remove complexity by building better operating
| systems, programming language, and core standards/ abstractions.
| A great example is web components--they should have destroyed the
| case for React and its ilk, instead a completely wasted
| opportunity.
| Ancalagon wrote:
| Leave the bloat, that'll ensure employment for me forever.
| d-lisp wrote:
| A few years ago I thought "how smart I am" when I built a smart
| TV out of a dumb TV, old computer, small server and light apk on
| my phone to control the newly created dumb-smart-tv, but in fact
| even this toy project mediately depends on a the linux kernel,
| drivers, android and a lot of code I cannot even hope to have the
| possibility to read in my lifetime. The true smart solution would
| be to have some kind of system on chip that would send via hdmi
| the proper signal from a source fetched by a sort of _curl but
| with streaming_. But then I would expect the source itself to
| rely on lean software; something like netflix but instead of a
| web app you would just have some catalog (a printed one?) of the
| available routes or codes you can send (like a telephone number)
| to ask for the emission of bytes to your hardware. But then I
| would ditch software, you would just compose a number on an old
| analogue phone and plug the video cable in the enclosure to
| receive your movie, while listening to the audio via the phone
| speaker.
| akprasad wrote:
| I'm reminded of Maciej Ceglowski's "The Website Obesity Crisis"
| (2015):
|
| https://idlewords.com/talks/website_obesity.htm
| TheAceOfHearts wrote:
| Lean code doesn't get written because there's crazy time
| constraints and the market generally doesn't reward or care about
| code quality. Managers want things shipped last month and they
| want to keep churning new features without long-term planning.
|
| But even going beyond that, we're forced to keep building upon
| tons of old design decisions which don't always match modern
| software expectations. It doesn't help that modern operating
| systems have failed to evolve in order to provide a better
| ecosystem. And that's not even taking into consideration the
| barriers created by artificial platform segmentation enforced
| through copyright abuse. In general, platform owners are very
| resistant to working together.
|
| The biggest innovation in the OS space during the past decade
| which I'm aware of has been the proliferation of containers.
| We've given up on combating software complexity and decided that
| the best thing to do is throw everything into a giant opaque ball
| of software and ship that.
|
| Anyway, for all my ranting all this bloat has at least enabled a
| lot of people to ship code when they probably wouldn't have
| otherwise shipped anything at all. The choice is rarely between
| good code and bad code, it's often going to be between nothing
| and bad code. And a lot of this shitty horrible code is often
| solving real world problems, even if it's bloated.
___________________________________________________________________
(page generated 2024-02-09 23:00 UTC)