[HN Gopher] Malleable Systems: Software must be as easy to chang...
___________________________________________________________________
Malleable Systems: Software must be as easy to change as it is to
use it
Author : pcr910303
Score : 197 points
Date : 2020-04-13 16:58 UTC (6 hours ago)
(HTM) web link (malleable.systems)
(TXT) w3m dump (malleable.systems)
| mntmoss wrote:
| The question to reconcile in my mind: Malleable systems with
| reproducable builds.
|
| It's very easy to get your hands dirty with the bytes and add
| various assumptions and dependencies. Most "hack solutions" go in
| that direction. But reproducing the modification in some larger
| context changes the assumption: What if the dependency isn't
| there?
|
| What tends to make the system stable over the long term is the
| thematic assumptions: Certain broad goals that never shift, even
| as the specification does. I think that's the factor missing from
| having malleability itself as a goal. You already have it, that's
| software.
| renewiltord wrote:
| Web user agents do this the best. You can run code in the
| console, delete elements, make that persist with an extension.
| And there you see the best outcomes and the dangers ("This is a
| browser feature intended for developers. If someone told you to
| copy and paste something here to enable a Facebook feature or
| "hack" someone's account, it is a scam and will give them access
| to your Facebook account.").
| saagarjha wrote:
| I don't think this is a very popular opinion, but for those
| shipping software, consider having at least one programmatic way
| to "monkey patch" it. These are things like a plugin API,
| dynamically linking it, or using a language with an exposed
| runtime-things that allow programmatic injection of code, so that
| users who _really_ care about tweaking the tool can do so. It
| doesn 't even take much effort, either: my text editor has no
| plugin interface, but one of the reasons I stick with it is
| because I can hook its calls to libc to customize some of the
| things I don't like. My preferred mail client happens to lack a
| certain entitlement that most people don't even know about and
| that enables an entire cottage industry of software for it.
| Browsers let you specify some JavaScript to run on each page and
| suddenly the balance of power on the web tilts significantly
| towards the user. Even (or especially) if your tool is open
| source, consider supporting such an interface: it's much nicer to
| add on to piece of software than fork it.
| bcrosby95 wrote:
| The problem is support. Even if you put big caution tape around
| it, if you break it or change it in a way that isn't backwards
| compatible users will complain loudly about it. And if you have
| users paying lots of $$$ relying on it, it might force your
| hand.
|
| Building a plug-able system in a way that doesn't blow up in
| your face can be hard. Firefox got a lot of bad press for
| redesigning their plugin system.
| enos_feedler wrote:
| This is a great point and something to consider when
| designing runtime programmable tools. It should mean moving
| slow, cautious with minimal surface area and opinions about
| the future is probably a way to go. Having strong isolation
| is probably good too. This is something that made me uneasy
| about highly programmable/hackable platforms. I like when the
| core maintainers understand _how_ a system wants to be
| extended and shaped and provides precise hooks for doing so.
| funkymike wrote:
| It seems to me the key then would be to have that
| programmable interface be used to actually implement the
| features shipped as part of the project. It will be a lot
| easier to get the API right if the developers are using it
| themselves, plus that adds a lot more incentive to maintain
| backwards compatibility as well.
| jmercouris wrote:
| I agree :-)
|
| The user _should_ have the power. Also the interface should be
| as powerful as possible. One such browser that embraces this
| philosophy is Next https://github.com/atlas-engineer/next.
| Source: biased author
| denster wrote:
| Very cool! I'll show this to our team [1]; we have a few
| keyboard ninjas & I think they'll absolutely love it.
|
| --
|
| [1] team of https://mintdata.com, where we've been known to
| appreciate a fine keyboard shortcut or 12.
|
| [2] partly an inside joke to our team who reads HN, since we
| recently shipped keyboard shortcuts for our top menu (Google
| Sheets, we borrowed what we could to ease the pain :D )
| denster wrote:
| -\\_(tsu)_/-
|
| Card carrying member of the disagree-club here (malleable
| clan), but I think it's a tall order to ask users to write
| procedural code.
|
| Tools that are:
|
| (1) declarative by nature (HTML, DSLs)
|
| (2) based on direct manipulation (PSA: we're lucky to have Bret
| Viktor on this planet)
|
| is what will win out in my opinion.
|
| Or will we be writing procedural code 30, 50 years out? :)
|
| --
|
| [1] YMMV, founder of https://mintdata.com here, where we
| recently opened public access & are seeing the above come true.
| slifin wrote:
| Mintdata looks cool, what does the imperative layer that
| drives the declarative layer look like? It'd be nice if this
| was a platform where engineers could sell the imperative
| layers
| denster wrote:
| Thank you! Genuinely warms my heart to hear it :)
|
| We've been using our own "Visual SDK" to build large parts
| of MintData for the past few years.
|
| It's 100% written in TypeScript/React, using decorators
| (cough: annotations!) and allows us to:
|
| 1) add new spreadsheet functions in TypeScript
|
| 2) wrap any React component
|
| 3) we get the auto-magic property panel UI "for free" & it
| instantly talks to/from the spreadsheet
|
| For our cloud/backend imperative layer:
|
| 4) we use our own real-time stream processor (think: Apache
| Storm but minus the Clojure stacktraces)
|
| 5) the SDK lets us quickly write flow blocks in Java using
| annotations & connect to all sorts of enterprise-y systems
| (SQL/NoSQL stores, Queues, File Systems, etc)
|
| @slifin -- in terms of engineers writing & selling those
| layers, we're open to it -- ping me if you have ideas & we
| can give you access to the docs & SDK.
|
| --
|
| [1] I'd put a link here, but the flamethrowers have come
| out on this thread :)
| chrisweekly wrote:
| Looks pretty cool; IMHO it's a good idea. (I once
| participated as a consultant / dev on a project to
| convert a Byzantine set of Excel spreadsheets into a
| deployable application built on web technologies, and
| this might have been a saner approach.)
| bem94 wrote:
| I agree that people would and do find such interfaces very
| useful in many of their programs and tools.
|
| Those with nefarious purposes find them extremely useful too.
| It's a lot of work to secure those interfaces against abuse.
| conradev wrote:
| https://xkcd.com/2044/
| saagarjha wrote:
| This is why I believe it to be an "unpopular opinion" these
| days as most computing platforms move towards being more
| locked down and less extensible; for security or complexity
| reasons these kinds of things seem to get little love or are
| even axed completely. Usually, the hard part is not security
| per se, but identifying user intent. You want to come up with
| a process that ensures that the user who enables potentially
| dangerous interfaces knows what they are doing. Preventing
| the user from doing this entirely is an easy but fairly
| disappointing "solution" to this problem.
| bem94 wrote:
| > Preventing the user from doing this entirely is an easy
| but fairly disappointing "solution" to this problem.
|
| For sure. And if individuals are happy with trading some
| security for some functionality/flexibility in their
| software, I'll support their right to make that choice.
|
| It gets more complex when the people affected by that
| choice aren't the people making the choice. Which is more
| likely in the case of network programs.
|
| > Usually, the hard part is not security per se, but
| identifying user intent. You want to come up with a process
| that ensures that the user who enables potentially
| dangerous interfaces knows what they are doing.
|
| Indeed. I'd add identifying developer intent to that as
| well. What functionality am I trying to enable v.s. what
| else am I actually enabling? Coming up with that process is
| the herculean task there.
| CapriciousCptl wrote:
| I see this and then I think of all the success of strongly
| opinionated things like Rails. Having one way to do things forces
| you to focus on what's most important, make choices and get
| things done. It keeps you away from premature optimization and
| analysis paralysis. Yes, you could split things into 100
| different pure pluggable microservices but should that really be
| where you put your resources at the beginning? To me, engineering
| and for that matter everything you do isn't any doing things the
| perfect way-- it's about doing them the best way you can and
| moving on to the next problem.
|
| Some things work well together in a functional pipeline-- Linux
| commands that do one thing for instance. EMRs are famously
| malleable too, for better or worse.
|
| But could you imagine being IT managing 1000 PCs all with
| slightly different versions of word processors or something like
| that?
| denster wrote:
| Here's a counter argument:
|
| In college (17 years ago) a professor once told me that
| databases largely outlive the apps that use them.
|
| Imagine a world [1] where IT manages data centrally, but users
| are free to interact with it how they best see fit?
|
| Would this kind of a world be better?
|
| (provided of course you have the right permission model & audit
| trail for modification)
|
| --
|
| [1] Founder of https://mintdata.com, so I'm biased -- malleable
| systems are near and dear to our heart
|
| [2] Professor Franklin at UC Berkeley, if you're reading this,
| I am very sorry for not being the most attentive student :)
| acomjean wrote:
| That's kind of how we design my web applications.
|
| We store all the data in the database and the applications
| query the data/ process and return. We actually have multiple
| applications in various languages accessing the data (php,
| java, perl...).
|
| Its genetic data so a lot of tables are shared across our
| applications. Gene symbol lookup for example).
|
| When I started in this field I worked with Lotus Notes. Its
| actually a shared nosql database which users can create
| applications that query it as they see fit. I was clunky, but
| it could be effective in making custom team tools.
| philote wrote:
| In this sort of world, how do you prevent users from making
| bad queries and hogging all the database resources or even
| crashing the database? How do you prevent users from wiping
| out data? (I get that you could back it up and restore it,
| but depending on the company, this could cause serious
| downtime and loss of revenue).
| denster wrote:
| I think of this in two parts:
|
| 1) Computing is cheap, human time is not.
|
| 2) Competition in established industries is fierce
| (finance, real estate, education, construction, etc)
|
| -- To the extent possible, I'd:
|
| a) time out bad queries
|
| b) add more hardware where feasible
|
| -- For the "wiping out data" part, I think:
|
| 1) Mark things as "removed", delete when {GDPR,CCPA,etc}
| requires it
|
| 2) The UIs designed can/should have human processes in mind
| -- that is, things like multiple people involved (async) on
| what to do with a piece of data (flag it, mark it removed,
| send it for approval, etc) -- what a lot of companies are
| calling "workflows" and "workflow management platforms"
| these days.
|
| 3) Backup/restore should be used only as a last resort (DR
| and the like)
|
| 4) Versioning like Google Sheets of the UI is _paramount_
| and integration with CI /CD systems is crucial to having
| the cake (allowing people to create the tools they want)
| while also eating it too (making sure IT doesn't drive the
| above-mentioned dune buggy off a cliff in protest)
| mtraven wrote:
| Should include some mention of Richard Gabriel's "Habitability
| and Piecemeal Growth", a really good essay on this topic from
| almost 30 years ago...
| https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
| 0xDEEPFAC wrote:
| In my experience, this line of thinking tends to lead to
| inefficient and hard-to-manage large projects based on languages
| which are convenient on a small scale.
|
| _Cough_ Electron _Cough_ https://medium.com/commitlog/electron-
| is-cancer-b066108e6c32
|
| I mean, what percentage of users are adept enough to change a
| program they use and then what percentage of them would even
| _want_ to go through the trouble of doing it. Moreover, why
| should we go through all the hoops needed to encourage novice
| /non-programmers to modify things they don't _really_ understand
| anyway.
|
| This seems like a solution/problem in search of a problem.
| saagarjha wrote:
| Nobody said you need to bundle a Chromium engine to make a
| program extensible.
| danShumway wrote:
| If you want to talk about text editors in that post, Emacs is
| wildly, almost obscenely configurable (I'm currently using
| Emacs as my Linux WM[0]). Vim has its own scripting language
| that you can use to write custom bindings and configs, and they
| can get similarly complicated. Sublime has a pretty good Python
| API. Even Nano can have its syntax highlighting extended.
|
| The extensibility of those systems are why they've stuck
| around. The composability of Vim's keybindings are why people
| keep reimplementing Vim modes in different pieces of software.
|
| If you don't like Electron, fine, but what does that have to do
| with building malleable systems? Can you name me any popular
| native text editor that's used for serious work and that
| doesn't support plugins?
|
| > Moreover, why should we go through all the hoops needed to
| encourage novice/non-programmers to modify things they don't
| really understand anyway[?]
|
| This is like asking why a programming language should have
| power-user features in it. I mean, by that logic why would
| anyone add pointers to a language like C? Pointers are hard,
| and most programmers aren't very good with them. Why go through
| the hoops needed to encourage programmers to use a memory model
| that most novices don't understand very well?
|
| If you design a system or program only for beginners and no one
| else, then only beginners will use it. Once they've matured,
| they'll leave so that they can find something else that meets
| their evolving needs. Good software design considers the entire
| life-cycle of how a user will interact with a program as they
| develop and learn new features.
|
| Many users will never get to the point where they'll want to
| program extensions themselves, but even they will often benefit
| from having extensions written for them by the surrounding
| community.
|
| [0]: https://github.com/ch11ng/exwm
| twelvechairs wrote:
| I have thought about this for a long time. For me the meaningful
| change means it needs to work at the OS/GUI level.
|
| What people miss in this thread is there 2 kinds of complexity we
| deal with - one that is fundamentally understanding the field and
| a second that is understanding the complex tooling required to do
| things. The latter has been getting much more complex lately
| (frequently multiple programming languages and multiple software
| packages) and a good set of fundamental tools that can operate in
| a loose environment is absolutely a big thing to aspire to
| mrfusion wrote:
| I always liked the extension system in browsers.
| PaulDavisThe1st wrote:
| We had a moderately long thread on the question of scripting
| versus "change the code" over on the ardour.org forums, starting
| with a post from me ...
|
| https://discourse.ardour.org/t/is-open-source-a-diversion-fr...
|
| TLDR: i still don't know if most of our users would prefer a more
| scriptable application even if it was closed source.
| oliverx0 wrote:
| This is the vision that Seliom, the startup I am working on, has.
| We are still too early and don't have documentation to share, but
| the idea is to give business owners the power to easily change
| digitized processes in minutes.
| bri3d wrote:
| Wasn't this the idea of the 4GL and 5GL craze in the 1980s and
| 1990s?
| awinter-py wrote:
| > software must be as easy to modify as it is to use
|
| interesting metric, reallllllly bad target
| austincheney wrote:
| Does this article literally mean _easy_ as in hire somebody else
| to do it for you or does it mean _simple_ as a one step change?
| By no means is that clear from reading the post.
|
| This subject of easy versus simple is frustrating, angrily so.
|
| I frequently see people asking for things to make various
| software tasks more easy. When I see anybody ask for easier the
| only appropriate question is: _How easy does it need to be?_. The
| question isn 't rhetorical, because I doubt (from experience with
| this issue) that the person asking for easy has any idea about
| what the end state of what that easy should comprise.
|
| Here is a real life example:
|
| At work there is a software component that has jQuery 1.x
| embedded and this failed an internal security audit. To solve for
| the audit failure version 1 of jQuery must be removed from this
| application. My first thought is to simply remove jQuery all
| together. You don't need it, but jQuery is easy. I was denied
| from removing jQuery, so I have to upgrade it.
|
| I upgraded jQuery and it breaks the application. I tried 3
| different versions of jQuery Migrate and multiple versions of
| jQuery 2 and 3 and no luck. The application is broken.
|
| This quest for easy is wasting an absurd about amount of time, so
| far a week, and its still ongoing. Knowing this is absurd I took
| the initiative to simply remove jQuery. I removed the jQuery
| library (about 12000 lines of code uncompressed and about another
| 100 lines for AJAX prep in our application). I then added about
| 20 lines of code for standard XMLHttpRquest handling. The
| application works perfectly, but fails a code review. We must use
| jQuery.
|
| I tried to explain this to nondevelopers and couldn't do it in a
| way that empathizes with the need for easy, because at face value
| it seems irrationally absurd. No matter how I tried it always
| sounded stupid. So, instead I have learned to explain like
| driving a car.
|
| Imagine you are a professional driver. You have been driving
| professionally for 10 years and have quite the validated resume.
| You have experience driving sedans, limousines, trucks, and so
| forth. You can drive safe and fast. You come to the current
| client highly recommended. A transport service dropped off an
| extremely expensive super sports car at an import broker and you
| are required to drive it to the client.
|
| You hop into that driver's seat and are shocked to discover there
| is this weird stick thing in the middle console between the seats
| and 3 foot pedals. Remaining confident you put the keys into the
| ignition but the car doesn't start. You sit there for 10 minutes
| completely lost. You have never seen a car with 3 pedals or a
| weird stick between the driver and passenger seats. Clearly, the
| car must be broken. Never mind that somebody just pulled the car
| up to you and never mind that its a standard transmission, which
| is the default in most super sports cars.
|
| Obviously the car is broken. The best recommendation is to
| investigate the car for mechanical defects, swap out the manual
| transmission with an automatic and after $18000 and 3 weeks it
| will be ready to go. Easy, now any qualified driver can drive the
| car.
|
| Simple, conversely, is just putting your foot on the clutch while
| engaging the ignition. The car starts without delay and allows
| for greater speed and precision at no extra effort.
|
| As a web developer most of the software I encounter is easy and
| extremely fragile, but its certainly not simple. This is
| especially true when you out grow your giant framework.
| thesuperbigfrog wrote:
| The Malleable software principles seem to be more of a "No Code"
| / "Low Code" wish list with some similarities to the Four
| Freedoms of the Free Software Foundation.
|
| >> "Software must be as easy to change as it is to use it"
|
| Easy is relative. I find command-line interfaces remarkably clear
| and easy to work with, but others might not agree with my
| opinions or preferences. How easy is "easy"? How do you know if
| software is easy enough? How can we fundamentally simplify the
| essential complexities of software development so that it is
| approachable by "the man or woman on the street"? What incentives
| do we have to do so?
|
| >> "All layers, from the user interface through functionality to
| the data within, must support arbitrary recombination and reuse
| in new environments"
|
| >> "If I want to grab a UI control from one application, some
| processing logic from another, and run it all against a data
| source from somewhere else again, it should be possible to do
| so." source: https://malleable.systems/mission/#2-arbitrary-
| recombination...
|
| If you have the software source code then this might be
| technically possible, but licensing restrictions may come into
| play. Short of the source code, the "no code" / "low code"
| software development pipe dream needs to become a reality and
| then become standardized to allow for component interoperability.
| It might be possible, but the question of incentives comes up
| again. If I were a company selling a production-quality "no code"
| / "low code" system, why would I make it interoperable unless I
| was trying to undercut a competitor?
|
| Compare to the FSF Freedom 1: "The freedom to study how the
| program works, and change it so it does your computing as you
| wish (freedom 1). Access to the source code is a precondition for
| this."
|
| >> "Tools should strive to be easy to begin working with but
| still have lots of open-ended potential"
|
| How do you define or measure "open-ended potential" from the user
| standpoint?
|
| >> "People of all experience levels must be able to retain
| ownership and control"
|
| Does this imply some kind of built-in DRM or is it merely
| copyright and licensing? How would ownership and control be
| enforced?
|
| >> "Recombined workflows and experiences must be freely sharable
| with others"
|
| This nests pretty closely with the FSF Freedoms 2 and 3:
|
| "The freedom to redistribute copies so you can help others
| (freedom 2)."
|
| "The freedom to distribute copies of your modified versions to
| others (freedom 3). By doing this you can give the whole
| community a chance to benefit from your changes. Access to the
| source code is a precondition for this."
|
| How does this principle combine with the previous principle about
| retaining ownership and control? How is it different from
| copyright and licensing that is currently used?
|
| >> "Modifying a system should happen in the context of use,
| rather than through some separate development toolchain and skill
| set"
|
| Using software and building software are different activities
| that REQUIRE different knowledge and skill sets. This is roughly
| the equivalent of wanting to modify your car without
| understanding how the drive train or transmission work. If you do
| not understand the underlying natural laws that govern how
| something works then how can you expect to make changes that do
| what you want? Lack of understanding leads to cargo cult
| reasoning and magical thinking.
|
| >> "Computing should be a thoughtfully crafted, fun, and
| empowering experience"
|
| It depends on the person, but actually learning how computers
| work and how to program computers can be a fun and empowering
| experience.
| badsectoracula wrote:
| > Does this imply some kind of built-in DRM or is it merely
| copyright and licensing? How would ownership and control be
| enforced?
|
| I think this refers to the _user_ being in control (as opposed
| to the developer) and having ownership of their computing
| environment.
| thesuperbigfrog wrote:
| But in a Malleable System, the user becomes a developer or
| something closer to a developer.
|
| The links in the principles give more details:
| https://malleable.systems/mission/#4-retain-ownership-and-
| co...
|
| For this principle, it says:
|
| >> "A fundamental problem of today's software ecosystem is
| that we do not own or control the software that runs on our
| devices. In addition, much of the actual processing logic has
| been passed off to remote systems in the cloud, so only the
| inputs and outputs are observable."
|
| >> "We must ensure that malleable software approaches allow
| the customisations and personal workflows you create to be
| owned and used as you see fit. If an approach relies on some
| amount of remote functionality (perhaps to assist with
| pulling apart an application or service), we must ensure
| there's a clear path for anyone interested to keep those
| dependencies alive so that their workflows are not disturbed
| if the remote service were to shut down."
|
| >> "This has many parallels with the ongoing movement towards
| data ownership, which is gaining popular awareness. Although
| the data ownership movement typically focuses on identity and
| social data, the programs and customisations that authors
| create are personal creative expressions. Authors must retain
| ownership of their data, programs, and customisations just as
| anyone would expect to have control over a book they wrote or
| art they created."
|
| The first paragraph definitely matches up with your point
| that the user should be in control of their computing
| environment. However the third paragraph certainly seems like
| copyright and licensing are implied.
| chrischen wrote:
| Functional programming to the rescue!
| pjc50 wrote:
| Interesting to put this on the front page next to the "immutable
| infrastructure for mutable systems" one.
|
| The thing is, these drives pull in opposite directions. If it's
| easy to change it's easy to break, and changes drive entropically
| downwards as it's always easiest to make the quick and dirty
| change.
|
| Malleable systems are great for expert users, but can easily be
| turned into a ball of mud by a non-expert. Hence the popularity
| of Chromebooks.
|
| Security also enters into consideration. Anything that can be
| programmed can be attacked. Any program that reads external data
| is an attack surface.
|
| Look at the history of e.g. web browser extensions, and how they
| have become more and more locked down to prevent abuse by bad
| actors.
| teodorlu wrote:
| And in the intersection of mutability and immutability you have
| fantastic experiences like live editing and time travel.
| /Where/ the interface for mutability is located is essential.
| rektide wrote:
| I agree there's a tension.
|
| There are strong engineering impetuses for control, for
| provability, for ahead-of-time decisions, for immutability.
| Engineers get woken up when things go wrong, they get blamed
| when things go wrong, & they want, they have to deal with other
| engineers code doing bad things with their code, & the software
| world has a wide variety of strategies, tools, & outlooks that
| all try to build safety, certainty, that restrict & constrain
| systems, to keep anything unexpected from happening.
|
| I feel, though, that characterizing malleable systems as being
| for expert users alone is a great injury. At present this may
| match expectations, but I don't think it's fair to make an
| assessment of how or what computer-users want when, at the
| moment, they don't really have the options. There are too few
| malleable systems out there to judge. What general malleable
| systems we do have require advanced expertise to use-
| AppleScript, DCOP (Desktop COmmunication Protocol), DBus,
| WebExtensions all require at least some programming style
| skills to use. But I think this expertise is owing to a broad
| lack of investment in building malleable software. Most
| software strives to give the user a specified & specific
| experience, not be a malleable system folks can get the
| experience they want out of. I don't think we know how much
| latent pull users have, how strong the tension is to be
| released from engineer's certainty, because I don't think there
| are even many testbeds, much less a broader societal view of
| systems flexibility, systems adaptability, of softer software.
|
| To me, I just think it's clear that, whatever valid concerns we
| do have, whatever justification we have for building endless
| arrays of rigid systems, it seems like it's not worth it
| anymore. We keep making more and more software, the profusion
| of software applications is a torrent of similar-but-different
| applications, focusing on shuffling this or that kind of data
| specifically, yet the generality, the inter-connectedness of
| the pieces seems so weak, and it seems like we've shut users
| out from having any creative capabilities & control of their
| own.
|
| I think WebExtensions are a very interesting case. The killer
| aspect, to me, is that the extensions work invisibly. We can't
| rely on everyone becoming an expert extension operator, but I
| do think that some reporting mechanisms on what extensions do
| would radically reshape how the community review's & socialized
| the extensions they use. In many ways, it's that the extensions
| are a means of exercising the malleability of hypertext, but
| they themselves are rigid & unmalleable & opaque. A part of
| being malleable- a precondition- is making yourself visible,
| providing viewability into what is happening, such that folks
| can reshape & redefine & redirect those actions that you the
| software are enacting. So the circle needs to grow more, is
| what it seems to me- rather than lock down extensions, rather
| than rely on authoritarian centralized powers to moderate
| extensions, my plea would be to make extensions malleable too,
| to make their working visible too, and to try to let
| consciousness & human adaptability start to take hold in this
| realm.
|
| You're absolutely correct that there are good reasons why
| software is so rigid & inflexible & opaque. Security has been
| nightmarishly cumbersome to the whole industry for the last
| decade. And I think malleability does indeed open up a lot more
| surfaces, endlessly opens surfaces. But at some point, we have
| to develop systems that have a co-relation with their
| operators, that respect the operators, that let them see what
| is happening & let them work their own systems. Continuing to
| try to push computers forwards entirely on the assumption that
| the user is worthless, does not know anything, and can not
| understand what is happening has cornered us, has cut off the
| chance to try & explore other options.
| AnIdiotOnTheNet wrote:
| On the other hand, malleable systems are responsible for
| enormous increases in the productivity of computer users. We
| may all hate kludgy excel spreadhseets with a nightmare of
| tangled hacky VBA code, but you see that sort of thing in a lot
| of businesses' critical workflow because that kinda of
| malleability by "untrained" users was invaluable in the earlier
| life of the business.
| Jtsummers wrote:
| It's still invaluable in highly locked-down office
| environments. It lets users automate things that they
| wouldn't be allowed to automate otherwise (needing a full
| development environment or the ability to run arbitrary
| executables or access to Powershell).
| ereyes01 wrote:
| I can see immutable infrastructure and this concept working in
| a copy-on-write model. For instance, if a service is up and
| running, a modification can consist of duplicating the
| infrastructure so you have your own copy and then making the
| modifications. It localizes the change, and in theory keeps the
| original unmutated.
|
| I have no idea how this would work in practice. This manifesto
| seems to go against the grain in other ways, as I'm not sure
| how it can coexist the economic model of SaaS that has emerged.
| Also, as others have said, the security and UX implications are
| big concerns that threaten the feasibility of this idea.
| rwmj wrote:
| This is describing Smalltalk and Lisp Machines?
| jshap70 wrote:
| title makes it justifiable for systems to both be hard to modify
| and difficult to use
| dustingetz wrote:
| "Mission... reset the balance of power"
|
| Does any of the real economic activity want to reduce its power
| and influence? that's the opposite of a startup
| rektide wrote:
| My guess is there's a lot of companies that would do very very
| well, if we opened up software & made it flexible.
|
| The entire era we live in/just left, the PC era, happened
| because of Adversarial Interoperability. Massive economic
| activity was created because "real economic activity" had
| "reduce[d] its power and influence", as PC-compatible systems
| emerged & created a robust, fast growing, competitive market
| place.
|
| Did IBM want to? No. But enough legal space was still there to
| allow companies to create. While IBM could patent inventions,
| they could not own the idea of an addition ops code to add two
| numbers.
|
| I'd content that the lack of Adversarial Interoperability, this
| low standard we've sunk to in software world, is holding back
| vast seas of economic activity. We cannot effectively build new
| better more interesting, systems, when each piece of software
| is a closed, inflexible box. We've got to open up to
| possibility again, just as PC-Compatible opened the doors of
| possibility that brought Very Large Scale Integrated circuits &
| systems to us all.
|
| Support Adversarial Interoparability. Support Malleable
| Systems. Support an open future where people can have
| meaningful interactions with machines & build meaningfully
| better ones. https://www.eff.org/deeplinks/2019/10/adversarial-
| interopera...
| oblib wrote:
| Ok... I am a self taught "app maker". Not CS grad. Not a
| "software engineer".
|
| I use tools that other's here create to make apps. What they do
| is way over my pay grade but I can use well written and
| documented APIs, especially when some example code is supplied.
|
| I think I'm closer to the target this applies to. Compared to the
| folks who create something like jQuery or PouchDB.js, I'm a
| laborer working in the fields with the tools (APIs) they create
| and provide.
|
| What I do is more akin to a craftsmen than a "software engineer".
| I'm sure some of what I've made is pretty crappy from an
| engineering viewpoint. I struggle sometimes to get stuff to work.
| But I also make software that some people love using.
|
| It's a pretty low bar to learn how to use HTML, CSS, and even
| tools like jQuery, Bootstrap, and PouchDB.js. What you can make
| with them can be very useful, and very specific. And it can be
| fast and easy to make too.
|
| I guess what I'm trying to say is the bar is now low enough that
| we can start teaching others how to make apps as a trade skill.
| joe_the_user wrote:
| Well, I think this is one of the "gatchas" in an idea like
| this. The malleable system you're talking about is only "a bit
| malleable", you can take it's elements and add a bit more. This
| is something like a "producer-consumer" model. To build a small
| or a medium-sized system from such standard elements is now
| reasonably simple - the original component set seems malleable.
| But once you've built your medium-sized system, changing it
| actually becomes hard, the resulting product is no longer
| malleable.
| denster wrote:
| (!) This!
|
| First, big props for shipping stuff that people use.
|
| Second, I've [1] often compared 90% of what we do in software
| development to being highly trained baristas. Granted, this
| buys me little love from engineers & even less from Starbucks.
|
| To the point -- I think it's time we rise up & start to use
| more powerful tooling.
|
| Tooling that:
|
| 1) Lowers the barrier for who can author software (really, web-
| based interfaces that help us get stuff done, the way _we_ want
| to accomplish a task)
|
| 2) Doesn't introduce more chaos (disparate data spread across
| 10 SaaS products, death by 1,000 spreadsheets by email or in
| Google drive, no centralized/secure/managed storage, etc)
|
| 3) Emphasizes that a superb user experience is table stakes for
| such tooling.
|
| Thoughts?
|
| --
|
| [1] founder of https://mintdata.com here, so just a tad biased,
| take the above with a few pounds/kilograms of salt.
|
| [2] oblib -- DM me, we're happy to give you free access if
| you'd like -- the above wording just warms our collective
| hearts.
| taurath wrote:
| > highly trained baristas
|
| And its sort of an insult to training, since there is very
| little actual formal training. Over 95% of the processes I
| use in developing software and systems are ones I've learned
| on the job, not learned while learning to be on the job.
|
| An apprentice system would work extremely well with software
| development.
| denster wrote:
| 200% agreed.
|
| I learned to develop software [1] before the interwebs,
| where we would just kind-of hack things together in C/Unix.
| Manuals were our only (& best!) friend.
|
| I then went to uni for a CS degree, and they had a very
| "holy grail" attitude about the whole affair.
|
| I agree that:
|
| 1) an apprentice system would work better 2) we have _got_
| to get more powerful tooling out there, into people 's
| hands
|
| --
|
| [1] founder of https://mintdata.com here, which makes me
| biased on the above
|
| [2] I'm still reminded of a world where the bridge between
| creating & using software was much smaller (not to mention,
| user interfaces were much snappier!) Here's a virtual toast
| to hoping we can one day come back to that reality.
| throwaway_pdp09 wrote:
| I'm going to disagree here, though sort of understand what
| you and the original poster are saying.
|
| In short I've seen the mess that 'unsilled' people make using
| complex tools. Tools such as databases (my area) are
| presented as being easy to use by microsoft, who make a lot
| of effort to make it easy to use. Too easy. Not because I
| want to keep people out, far from it, but because if they
| don't know what they are doing they get only so far, then
| things go bad and they've no idea why. Drag/drop, point/click
| only goes so far.
|
| I guess no complex tool can be (or should be?) used with
| concomitant levels of training. It's not an argument for code
| gurus to make themselves a comfortable walled garden to
| preside over and keep others out, it's an argument that tools
| should come with training, always.
|
| The problem these days is the hirers just want everything
| (blah blah full stack blah) and don't understand the cost of
| getting it wrong because it works - up to a point. MSSQL,
| Spark, Kafka, down to failure to understand how CPUs work.
| They all get treated as black boxes, and that's fine up to a
| point. Then things break or don't scale. Out of my sphere I
| see so many websites that have no basic understanding of
| usability, or standards, or accessibility, security and by
| web devs that barely understand HTTP.
|
| If it's plain line of business, unimaginative gruntwork that
| keeps a business alive with spreadsheets etc, then that's
| what's needed and basic understanding is sufficient. I've
| done plenty of jobs like that, they keep the economy going,
| but if you want heftier dev work, I don't think that will
| suffice.
|
| I guess that makes me sound a snob. Not intended that way,
| just saying complex tools may not be usable to their full
| capacity without understanding them. I may be wrong too.
| gatvol wrote:
| The two aims of the argument are often at odds in my experience.
| You can generally have one or the other, seldom if ever both
| tmikaeld wrote:
| Eric Elliot would probably jump on this, considering his books
| and series https://medium.com/javascript-scene/composable-
| datatypes-wit...
| lerpapoo wrote:
| open ended thinking on a framework level is basically R&D, many
| companies don't have money for R&D, they just need something to
| sell and get paid so you can get your next paycheck, but u can
| try and find a sugar daddy or live off of foodstamps for a few
| years and really put some thought into it lol.
| AriaMinaei wrote:
| Alan Kay: It was kind of like what we have today, but better. It
| was a completely integrated system that was not made up of
| applications, but "objects'' that you could mix and match
| anywhere. You've got a work area and you can bring every object
| in the system and you just start: You've got every tool, you've
| got every object, and you can make new objects. It was
| programmable by end user, and it had the famous GUI.
|
| Larry Tesler: It was the first one that was graphically based-
| overlapped windows, a mouse, stuff like that.
|
| Adele Goldberg: It was very much a GUI demo.
|
| Dan Ingalls: I was scrolling up some text and Steve said, "I
| really like this display."
|
| Alan Kay: At that time, when text scrolled, it did so discreetly:
| So jump, jump, jump-like that.
|
| Dan Ingalls: And Jobs said, "Would it be possible to scroll that
| up smoothly?"
|
| Alan Kay: "Can you do it continuously?" Steve liked to pull
| people's chains.
|
| Dan Ingalls: Because it did look a little bit jerky, you know?
|
| Alan Kay: So Dan or maybe Larry just opened up a Smalltalk window
| and- Bruce Horn: -changed a few lines of code in Smalltalk, and
| in the blink of an eye it could do a smooth scroll.
|
| Alan Kay: And so it was like, "Bingo!" And so Steve was impressed
| but he didn't know enough to be _really_ impressed. The other
| Apple people just shit in their pants when they saw this. It was
| just the best, best thing I've seen.
|
| Dan Ingalls: I think that sort of blew Steve's mind. Certainly,
| just about anybody who worked on development systems responded
| really well to that particular demonstration. It really showed
| how the Smalltalk system could be changed on the fly and be
| extremely malleable in terms of stuff you could try out in the
| user interface.
|
| Alan Kay: On Smalltalk you could change any part of the system in
| a quarter of a second. These days it's called live coding, but
| most of the stuff today-and virtually everything back then-used
| compiled code, so your programming and editing and stuff like
| that was a completely separate thing. You had to stop the system
| and rebuild.
|
| Dan Ingalls: So you had a regular sort of programming environment
| sitting there in front of you with windows and menus and the
| ability to look at code and stuff. But the neat thing about it
| was that if you edited the code, it would actually change the
| code that you were running at that very moment. The object-
| oriented architecture made it really, really quick to make
| changes.
|
| Bruce Horn: Even today if you wanted to change something at the
| level of the operating system in MacOS or Windows, it's simply
| impossible unless they have decided to give you that option to
| smooth-scroll or not. It's simply impossible to get to the source
| code to do that unless you're an employee-and even then it would
| probably take six months to get that feature in. Whereas within
| Smalltalk, you pop up the menus, accept the change, and it's
| working right now. You can't even do that today.
|
| (from Valley of Genius: The Uncensored History of Silicon Valley)
| goatlover wrote:
| It's interesting how the ideas of the Smalltalk and Lisp
| systems of the 70s and 80s get reintroduced over time, but
| they're never fully embraced, even though some of their
| features make it into the mainstream. Emacs would be an
| exception. Makes you wonder where Smalltalk-inspired systems
| would be today if they had the kind of support popular
| languages have received. Imagine Smalltalk receiving the kind
| of attention Java, Python or Javascript have the past 20 years.
| ddevault wrote:
| This is something I like about Plan 9 (and I like basically
| everything about Plan 9). The entire OS's source code (the
| kernel, userspace, everything) is available at /usr/src and can
| be compiled and installed with these commands:
| cd / . /sys/lib/rootstub cd /sys/src mk
| install
|
| It takes about 5 minutes. Want to cross-compile for another
| architecture? cd / . /sys/lib/rootstub
| cd /sys/src objtype=arm64 mk install
|
| If you haven't tried Plan 9, you really ought to spend your next
| spare weekend messing around with 9front.
|
| http://9front.org/
|
| No other technology you could spend your weekend with will have a
| larger impact on your way of thinking about computers than Plan 9
| might.
| PaulDavisThe1st wrote:
| Plan 9 is lucky - by design it is self-contained and has no
| dependencies.
|
| One of the hardest parts about building many complex open
| source projects (particularly on Windows and macOS) is getting
| their dependency stacks in order.
| ddevault wrote:
| All projects would be well served by carefully keeping their
| dependency graph small and conservative.
| qqii wrote:
| Unfortunately I think plan9 only remains this way by keeping
| the people who use it small, being elitist and somewhat
| unwelcoming[0]. That's not to say I wouldn't also recommend
| spending a weekend messing around.
|
| I was recently having a conversation about the unix philosophy
| on reddit[1]. As _nix and software built for_ nix became more
| and more mainstream it becomes harder and harder to keep with
| the unix philosophy and the philosophy of this post.
|
| [0]: http://fqa.9front.org/ [1]: https://youtu.be/XvDZLjaCJuw
| ddevault wrote:
| The reading material is "unwelcoming" to discourage coming
| into it with any preconceptions. If you go into it trying to
| make it do $x, you'll have a bad time and send lots of
| annoying emails to the maintainers. If you come into it
| wanting to learn about it and derive an $x from your
| experience, you'll have a better time.
| gm wrote:
| I think it's a pipe dream. Non-experts making changes to a system
| an expert wrote will yield either: 1) very few little changes,
| such as changing the color of an item, etc. Or 2) disasters where
| it's better to throw away the changes and start over doing it
| "the right way".
|
| Just look at automobiles: They are malleable indeed. We've all
| probably seen pics of modifications of all types, from the
| hillbilly type VM bug/truck combination to the amazing Cobra
| replica that few can tell from the real thing. In all cases, the
| craftsmanship level (and budget) of the person doing the
| modification directly affects the quality of the result. And how
| many cars are there whose modifications simply failed and the car
| never hit the road again?
|
| The same in software. Give Annie in accounting the ability to
| modify the inventory system and you will have a disaster in your
| hands, especially if she does not know much about the
| architecture of the system and/or she's not a matter expert on
| inventory methods and procedures. In that case I'd much rather
| trust my company to a hard-to-change system than one where
| everyone can mess with and break it beyond repair.
|
| I think the false premise here is that non-experts can build on
| the work done by experts. And I'm talking about both experts in
| programming who built the system in the first place (ie, add
| shitty architecture on top of good architecture), and experts in
| the domain the system is solving. If you get a smart your
| developer who is a solid coder to make changes to the
| aforemetioned inventory system, he will probably break the system
| (at least in the edge cases), albeit with beautiful, readable
| code.
|
| I just don't see how it's possible unless the ability to expand
| the system is severely limited (ie, not a "malleable system").
| denster wrote:
| Whoa! What do you have against hillbillies? :)
|
| Jokes aside, imagine if Annie in accounting has the ability to
| define her own malleable tools, on top of a solid/robust system
| for centrally managing data? (version, backup, secure via IAM,
| etc)
|
| Or will we really be stuck writing procedural code for the next
| 20, 30, 50 years?
|
| --
|
| [1] Caveat: chief hillbilly of https://mintdata.com here, where
| we think you really can have your cake (create expressive
| tools) and eat it too (centrally control, manage, and version
| your data) .
| chrisco255 wrote:
| Hillbillies are some of the best mechanics.
| ghayes wrote:
| You've linked to your site on at least 4 comments in this
| thread, which is really taking away from the comment
| experience. I am glad you're enthusiastic, but make sure the
| disclaimers don't take away from your (otherwise great!)
| comments.
| denster wrote:
| Point taken :)
|
| Is it ok to shill Roosevelt?
|
| [1] https://youtu.be/Mm4epcGApnY?t=14
| derefr wrote:
| Sure, but that's not "modifying the original system" any
| more. That's taking the original system (original
| abstraction) as a fixed/static foundation, and then
| expressing things in terms of it.
|
| Which, I mean, if the tooling you've made is Turing-complete
| (Excel, Unix) then you can certainly say that the person
| working on top of your system is "programming"; but they're
| not programming _your system_. They 're not writing plugins
| that interface with it on the same terms that its components
| interface with one-another (as you would be if you e.g. wrote
| your own POSIX shell utilities in C); they're trapped "above"
| that abstraction, in a sandbox, one from which they can only
| access the narrow subset of the API surface that you
| explicitly chose to expose to them.
|
| Let me put it this way: you can get pretty far using e.g.
| Postgres as a custom data platform, by defining custom
| functions and types. But at some point, you'll need to write
| a Postgres extension. There's a big difference between a
| system that makes it easy for someone who's not a
| professional programmer to work on top of it (PG
| functions/types) and a system that makes it easy for someone
| who's not a professional programmer to _extend_ it (PG
| extensions.) I 've not yet seen a constructive proof that the
| latter is even possible.
| denster wrote:
| I'll give you an example that mid-way [1] disproves the
| above.
|
| Think of a typical "product tour" in a SaaS product. We're
| building the MintData product tour, in MintData itself. We
| then "publish" this "product tour application", and include
| it with the original blank design that a user gets when
| they first enter MintData.
|
| So, in a way, our MintData onboarding is built in/on
| MintData itself, a bit like how you can have a
| bootstrapping compiler (one that compiles itself).
|
| So, is the above us "modifying the original system"?
|
| I think to some extent yes, although we have special
| spreadsheet functions that help jump the gap between
| Onboarding Application and Blank User Design (akin to the
| Postgres extensions [2] above).
|
| So I think it _is_ possible to build a system that allows
| you to then customize the system 's own behavior (earlier
| versions of MintData could not build the onboarding
| experience, similarly to how the first compiler has to be
| built in a lower level language).
|
| Genuinely curious -- derefr, do you agree or disagree with
| the above?
|
| --
|
| [1] Chief abstraction wrangler at https://mintdata.com, so
| YMMV on the above.
|
| [2] As a person who was held at Grade-point and forced to
| write PostgreSQL C code to "modify the original [Postgres]
| system", I can only say it's an acquired taste :) Even Prof
| Franklin at UC Berkeley I think would back me up on this :D
| :D
| GuiA wrote:
| Seeing your product shilled so blatantly repeatedly as
| one goes down the comments in this thread is pretty off
| putting.
| denster wrote:
| Ouch! That hurts!
|
| My only response is this:
| https://youtu.be/Mm4epcGApnY?t=14
| derefr wrote:
| I think I get what you're talking about. Some systems are
| designed in such a way where the "platform" is formed in
| two layers: a low level, which exposes a set of
| primitives; and then a set of _abstracting core
| libraries_ , implemented in terms of those primitives.
| Users are expected, idiomatically, to create business
| logic by making calls into the core libraries; but
| they're also free to call on the low-level primitives
| directly. In such a system, the "userland" sits directly
| on the primitives, with the core libraries as a sibling.
|
| This is the pattern adopted by some, but not all,
| "runtimes." For example, Erlang has the low-level BEAM
| VM, and then has the Erlang "kernel" implemented as BEAM
| bytecode, rather than as native emulator support code.
| For another example, MOOs (object-oriented MUDs, e.g.
| LambdaMOO) only had the barest object-graph
| infrastructure specified in native code; everything else
| about the foundations of a MOO was defined in terms of
| objects and classes held in the MOO's state database.
|
| In such systems, you have a sort of "intermediate" level
| of access to the native API surface, greater than the
| kind you have from the userland of a traditional VM or OS
| kernel.
|
| Still, this "intermediate" level of access still doesn't
| allow you to break through the abstraction layer that the
| low-level primitives are founded upon. If there are any
| "complex" primitives implemented entirely natively (e.g.
| Erlang's `term_to_binary` function), then you can't
| "break into" that primitive to extend it unless the
| native runtime has been extended with an explicit
| "upcall" hook back into the VM userland.
| taurath wrote:
| > I think the false premise here is that non-experts can build
| on the work done by experts.
|
| I'll take a different side to that argument - it is dependent
| on the expert to establish the bounds and rules of change to a
| system. How a system naturally grows from people with less
| context is one of the architectural traits of the system that
| can be traded on.
|
| I have often seen systems which can ONLY be worked on by the
| so-called "expert" who wrote it. Even when you hire a new
| "expert" level person to work on it, it takes forever and
| success is not gauranteed.
|
| On the other end - a system that actively works against doing
| things the wrong way. It has an established core idea with
| clear boundaries between the roles of interlocking parts. For
| the intended usecase of the system, it is as extensible as it
| needs to be, while still remaining within the bounds of the
| intended usecase. It does now allow a vacuum cleaner to become
| a microwave oven, but it does let you add custom attachments,
| modify and swap out drive systems, adjust suction power, and
| change body style and hoses for the vacuum. Those can
| absolutely be done by non-experts, and the system is still very
| malleable.
|
| Think of all the code on github for libraries people use every
| day that is added by non-experts, or hobbyists, or people who
| are new.
| saagarjha wrote:
| I strongly disagree, and I think your example actually supports
| this position. Most people don't modify their cars at all, but
| for the people that do find great pleasure in it. We see this
| with software, too. I think that opposing people who would like
| to mess with the things they use is limiting and fundamentally
| somewhat disappointing. It's essentially impossible to make
| software that caters to everyone's needs, but I think the best
| you can do is make something that works for most people out-of-
| the-box and let the few people who want to tweak things to
| their liking themselves. (To extend your analogy, I don't know
| the first thing about cars but I have very few complaints with
| mine. If I didn't like something about it, locking me out from
| changing it prevents me from taking it to my car-enthusiast
| friend.)
| megous wrote:
| And yet there are tens of thousands of userscripts, even
| without any "malleability" intended by website authors, just
| because platform allows some introspection and extension:
|
| https://userscripts-mirror.org/scripts.html
| codr7 wrote:
| Emacs makes a pretty good example from my perspective, but if
| you haven't used it I suppose it makes little sense. Perhaps
| AutoCAD from what I understand, but I don't have enough
| experience with extending it to say for sure.
|
| It's not that you have to extend it yourself, the point is to
| make it possible.
|
| Annie in accounting (can't believe you got away clean with that
| one :) might ask someone else in the company to help her add a
| shortcut or whatever, or the company might hire an outside
| consultant.
|
| There's an entire gradient from non-technical to expert that's
| effectively shut out from modifying most software.
|
| Now I'm as guilty as anyone, getting a client to pay for an
| advantage they can't imagine the consequences of isn't
| happening much. But I can certainly see the value.
| oblib wrote:
| >> from the hillbilly type VM bug/truck combination to the
| amazing Cobra replica that few can tell from the real thing.
|
| lol! I'm a hillbilly living in the Ozarks who used to make
| custom cars for movie stars in Hollywood and race cars for guys
| like Larry Fullerton and Tony Nancy.
|
| Thanks for the laugh!
| throw1234651234 wrote:
| Our software always starts out as super-clean, easy to change,
| human-readable, etc.
|
| Then requirements change 100s of times, on a deadline, and that
| it's no longer a pinnacle of those qualities.
| mikejulietbravo wrote:
| This would make a lot of sense for designing things around Web
| 2.0 - it's as easy to create content as to consume it.
|
| For software in general? This is insane. The key reason? Domain
| knowledge.
| aey wrote:
| The unfortunate outcome is more yaml and less lisp or small talk
| :(
| hugozap wrote:
| Complexity has to go somewhere. Because systems are just piles of
| abstractions and conventions "easy to change" is very relative. A
| compromise will always be required. A simplification here means
| pushing complexity somewhere else.
|
| What I think is a practical way to see it is to have a good match
| between your audience mental models and the system conventions.
| kccqzy wrote:
| > A simplification here means pushing complexity somewhere
| else.
|
| And it is a good idea to concentrate complexity on a few small
| pieces of software that only experts are contributing to. Think
| your typical web applications and databases: your app doesn't
| need to think about how data is laid out on disk and how on-
| disk indices are implemented; all of those complexities are
| pushed into the database. It's a good compromise.
| searchableguy wrote:
| I don't agree with it.
|
| A good deal of complex software is abstracting away on existing
| complex systems that you run on. without understanding the
| underlying system, you can make guesses about what something is
| doing but that wouldn't be ideal always.
|
| For example, package management. Your package manager might
| verify the files, check for existing configuration, setup
| permissions, directories, do dependency resolution, and lot more.
|
| In practice, it is just package manager install something.
|
| How will you modify the package manager without understanding
| what exactly is it abstracting away from you?
| souprock wrote:
| I do this. Just yesterday, I changed a large piece of software.
|
| I didn't have any source code for it. I think it may have been
| written in C++, but that didn't matter. I had the *.exe file,
| which was all I needed.
|
| I used IDA Pro to study the software. You could use Ghidra,
| Binary Ninja, or Hopper Disassembler. They are pretty similar. I
| used xxd and joe to modify the software. You could use dd and
| echo, or a proper hex editor.
|
| I found the function that was annoying me, practically causing
| the software to be malware. I inserted the bytes 33 DB (a XOR
| opcode) near the end of a function, then removed the bytes CC CC
| (alignment padding) from right after the function.
|
| I seem to have hit most of the points in that article. The big
| miss was the unreasonable dream of "all experience levels". That
| just won't ever be reality. Mastery of a disassembler is not a
| beginner skill.
| MaxBarraclough wrote:
| This is just silly. No, a C++ compiler cannot be as easy to
| change as it is to use. Come on now.
| wtetzner wrote:
| For compilers that are written in C++, changing the compiler
| _is_ using it. ;)
| amicin wrote:
| Solution: make the C++ compiler harder to use!
| saagarjha wrote:
| I wouldn't go as far as to say it's (or should be) "as easy to
| change", but making compilers that allow for modification is
| not novel or unusual: Clang lets you load optimizer plugins
| written in C++, for example; Rust lets you write macros in Rust
| itself that give you access to the token stream, and Lisps, of
| course, are homoiconic.
| rubiquity wrote:
| I leave this for you without comment:
| http://nibblestew.blogspot.com/2020/04/your-statement-is-100...
| saagarjha wrote:
| FWIW, I consider posting a link that has a title matching the
| point you're trying to make, without further clarification or
| constructive feedback, fairly lazy.
| rubiquity wrote:
| My effort matches that of the person I was replying to. But
| yeah overall a bit out of character for me. Extremely
| polarizing examples to deter something could be progress is
| a pet peeve.
| saagarjha wrote:
| When possible, I think it's nice to aim for something
| better than that. While brusque, I don't think I the
| comment was in bad faith, so I think it deserved better.
| xkapastel wrote:
| Of course it can. You can do pretty much anything you like with
| software as long as you have the vision. A plugin/extension
| architecture can certainly make modifying a compiler easy. What
| makes you think it can't?
| MaxBarraclough wrote:
| Except it doesn't work like that. Sensible architecture
| doesn't make compiler engineering trivial.
|
| Compiler engineering is a highly technical area of software
| engineering. Think an average C++ programmer could take an
| old C++ compiler like OpenWatcom and make the necessary
| improvements to make it comply with the latest C++ language
| standard? Not a chance, that would be the work of a lifetime.
| They might have a shot at making small contributions to a
| compiler, but they'd have to set their sights quite low.
|
| Another example might be operating systems. The abstractions
| offered by modern operating systems are terribly easy to use,
| but there's a high skills barrier to doing meaningful work on
| the kernel. Similarly, the average web developer stands
| little chance of making a contribution to V8 or WebKit.
|
| This strikes me as analogous to discussing whether it should
| be harder to design and build a car, than to drive one. I
| don't like to be uncharitable but I stand by my earlier
| choice of words: this is silliness. Difficult engineering
| fields cannot be made easy.
|
| I see that another commenter, 'gm', has done a good job
| expressing similar points.
| m0zg wrote:
| Been in the industry for 20+ years and never once have I seen
| anything remotely resembling what this manifesto describes. I've
| seen several attempts to go in this approximate direction,
| though, each ending in a disaster because what's described there
| calls for a drastic, "be all end all" over-design that either
| doesn't do anything useful at all (example: "zero code"), or is
| so complicated that nobody can figure out how to use it (example:
| one of the distributed systems frameworks I worked on at Google -
| very general, reusable and modular, but you'd need a PhD to even
| understand it conceptually).
|
| This seems to be written by someone who doesn't really know what
| they're talking about, but would like to "help" by "writing".
| Reminds me of this scene from "The Fifth Element":
| https://www.youtube.com/watch?v=CYHO7FRsQAA
|
| It's akin to looking down into a shaft of a coal mine and
| suggesting that miners should breathe fresh air and stay above
| ground, because what they currently do is not good for their
| health.
| goatlover wrote:
| Smalltalk, Lisp, Cedar, Emacs, Hypercard and Lotus Notes come
| to mind.
| cosmotic wrote:
| I'm sorry, how is emacs easy to use (as per manifesto)?
| goatlover wrote:
| There is a bit of a learning curve. I guess Hypercard and
| Lotus Notes would have be the easiest to learn. Maybe throw
| Excel in also since it can be used (or abused) for a lot of
| things.
| shalabhc wrote:
| This isn't about building software similar to what we currently
| have and just making it more end user configurable. This is about
| rethinking software so that end user malleability makes sense.
|
| What does such software even look like? We want some kind of end
| user modifiable artifacts, still contained within some
| constrained substrate. Think Minecraft or Excel - I can give you
| a spreadsheet to calculate some taxes, but you can then dig in,
| change the formulae, remix with other sheets, and so on. Most
| software is not like this - typically you get some pre canned
| views and switches, not a canvas of composition.
| jcelerier wrote:
| plenty of people use software such as Max/MSP, PureData to do
| exactly that
| denster wrote:
| This is exactly what we built at MintData. [1]
|
| A new way to construct software by using a spreadsheet to
| define application logic, instead of today's spreadsheets which
| breed chaos.
|
| "A canvas of composition" - I really like that phrase to
| describe this approach of re-mixable software creation and
| usage.
|
| ---
|
| [1] I'd add a link here, but I think folks below might be
| sharpening their pitchforks by now :D
| duxup wrote:
| I feel like I could spend infinite amounts of time coding and
| recoding to make things easy to change ... and not get anywhere /
| add a lot of unneeded abstraction.
|
| I've certainly run into plenty of hard coded narrow code that is
| brutal to change, but the changes I make are were probabbly not
| obvious to the guy who wrote the code in the first place.
| GuiA wrote:
| A worthy mission, but if the best examples of it are emacs,
| HyperCard, and a bunch of academic papers no one wants to read (I
| say this as a former HCI academic :), the road ahead is long and
| arduous indeed.
|
| It'd be nice to see the authors of this manifesto make a small
| program (image editor, chat client, etc) that embodies the values
| they have in mind.
| mwcampbell wrote:
| Sometimes malleability can backfire. By coincidence, just
| yesterday a friend of mine sent me this Joel on Software classic:
|
| https://www.joelonsoftware.com/2000/04/12/choices/
|
| Particularly relevant here is the part about the user who made
| their taskbar take up half the screen, making their computer
| unusable.
| vsareto wrote:
| Hah, you can still do that on Win10.
|
| I wonder why they even bother letting it go to half-screen?
| mellow2020 wrote:
| Why not? Maybe I have a lot of monitors and want to dedicate
| a small one to a taskbar where I see the full pathname of
| each editor that has a file open.
|
| People who just randomly click things without even realizing
| they're clicking may just as well delete random files or
| worse, the taskbar taking up half the screen is about the
| most harmless consequence I can think of. If it's really such
| a worry, add a dialog that asks the user "are you sure you
| want this?" for anything "weird", with a checkbox to "never
| ask again". If people "accidentally" click _that_ , too, that
| is really their problem.
| marcosdumay wrote:
| You know, there are plenty of drawbacks on the act of offering
| options to the user, but the article touches on none of them.
|
| It has really the wrong focus. It talks about pop-ups and
| distracting messages; it talks about surprising interfaces; it
| talks about actions that are hard to undo. But it doesn't talk
| about any problem that options cause by themselves.
| cptnapalm wrote:
| Knew a girl who complained that her computer was too slow. As
| it turns out, she had added every add-on toolbar to Internet
| Explorer she ever came across. Her usable window was about two
| inches tall. Yet, it was the speed she complained about, not
| the utterly unusable web browser window.
| fjallstrom wrote:
| 20 year old article? still fantastic content. wow.
| mellow2020 wrote:
| > It's true that the first time they realized you could
| completely remap the keyboard in Word, they changed everything
| around to be more to their liking, but as soon as they upgraded
| to Windows 95 those settings got lost, and they weren't the
| same at work, and eventually they just stopped reconfiguring
| things.
|
| Who is "we"? That didn't describe me in 2000 and describes me
| even less today.
|
| Being able to moving the taskbar is bad because his friend shot
| herself in the foot this one time, but "we all love Winamp
| skins" -- because the person whose winamp turned unusable
| because they double clicked the wrong file just didn't happen
| to be friends with Joel. Sure, don't make software for me, but
| don't try to rationalize it with such gymnastics.
| saagarjha wrote:
| I disagree with the point made in that article:
|
| > Every time you provide an option, you're asking the user to
| make a decision.
|
| The best-of-both-worlds is when you give users an option, and
| then you pick a sensible default for it. Some of the best
| options are the ones that 90% of people don't even know about,
| but the 10% that do can find when they need it. I can't tell
| you how many hidden "defaults" commands I have run that are not
| even exposed to the UI but make my life much, much nicer.
| ChrisMarshallNY wrote:
| I tend to design software in what I call a "layer cake" fashion.
|
| Lots of layers, with clearly defined domains, strict APIs, and
| each with its own project lifecycle.
|
| I also tend to "design with SDKs." I treat each module asn an
| SDK, which means that I pretend I don't know exactly how it will
| be used, and I use my "S.Q.U.I.D." methodology on it.
|
| https://littlegreenviper.com/miscellany/bluetooth/itcb-04/#s...
| hypfer wrote:
| "a community space for those interested in redefining our
| relationship with software by dismantling the boundaries of
| contemporary applications."
|
| "the collective's mission to get an idea of the revolution we're
| working towards"
|
| It's an art project, isn't it? This needs to stop.
| fakedrake wrote:
| I miss vimperator :(
| save_ferris wrote:
| I agree with this in theory, but doesn't this go against YAGNI,
| agile, etc.?
|
| In most commercial applications I've worked on, supporting every
| type of interop or integration would never fly from an iterative
| development perspective. Or perhaps I'm misunderstanding the
| thesis here.
| iopeak wrote:
| When I read the concerns addressed here I cannot help but think
| of the end user (not a developer per say). There is an entire
| category of EUSE products that try to accommodate these concerns,
| however fall quite short. We need to rethink the entire paradigm
| of development, define sectors that need specialized product
| concerns (embedded vs games vs cloud) and build holistic
| ecosystems around them. There are startups doing this, yet how to
| categorize these types of tools is still not established;
| therefore hard to point at.
___________________________________________________________________
(page generated 2020-04-13 23:00 UTC)