Blurring the Line Between User and Programmer(futureofcoding.org)
futureofcoding.org
Blurring the Line Between User and Programmer
https://futureofcoding.org/episodes/042
12 comments
You’re assuming such a language is necessary is where this goes wrong.
Non-technical people should be able to use their native cultures language to query for answers. Or in the case of scientists & mathematicians, the well defined symbols & glyphs of their field.
Programming is the act of organizing information for a specific context, ideally efficiently to the computer, but that’s not a requirement. Clearly organized results are the only real requirement of software. All the rules we add on these days are to the benefit of corporate keeping things tidy by pretending making software is like building a car.
As someone getting into data science as a hobby, I have no interest in Python or R syntax. Like with PGP & a host of other issues, terrible UX is an impediment, and an artificial shield for those that slog through learning what is really superfluous crap given their actual task of making sense of business data.
Give me an app where I can select a database, and compose a math equation with nothing but plain math, as like React components, or a word processor with scaled up Unicode symbols, or use a game engine like Unreal, for all I care.
And for day to day life things like Siri are fine.
This is my huge beef with the tech world is believing everyone needs to fetishize source code to use a computer.
The “design is life” era has resulted in a ton of boring/limited business “apps”, and over designed one off UX that lacks broad application.
Software as a marketplace in general is suffering the App Store problem: it’s so easy to copy-paste SOMETHING out the door via Github or however, we’re socializing around the most visible, IMO, well known concepts, minor iterations on known information.
Often wonder if there’s a theory there that might explain why society is where it is lately: we’re not generating enough emotionally unique information. Just fetishizing minor improvements to well known emotional norms.
Non-technical people should be able to use their native cultures language to query for answers. Or in the case of scientists & mathematicians, the well defined symbols & glyphs of their field.
Programming is the act of organizing information for a specific context, ideally efficiently to the computer, but that’s not a requirement. Clearly organized results are the only real requirement of software. All the rules we add on these days are to the benefit of corporate keeping things tidy by pretending making software is like building a car.
As someone getting into data science as a hobby, I have no interest in Python or R syntax. Like with PGP & a host of other issues, terrible UX is an impediment, and an artificial shield for those that slog through learning what is really superfluous crap given their actual task of making sense of business data.
Give me an app where I can select a database, and compose a math equation with nothing but plain math, as like React components, or a word processor with scaled up Unicode symbols, or use a game engine like Unreal, for all I care.
And for day to day life things like Siri are fine.
This is my huge beef with the tech world is believing everyone needs to fetishize source code to use a computer.
The “design is life” era has resulted in a ton of boring/limited business “apps”, and over designed one off UX that lacks broad application.
Software as a marketplace in general is suffering the App Store problem: it’s so easy to copy-paste SOMETHING out the door via Github or however, we’re socializing around the most visible, IMO, well known concepts, minor iterations on known information.
Often wonder if there’s a theory there that might explain why society is where it is lately: we’re not generating enough emotionally unique information. Just fetishizing minor improvements to well known emotional norms.
I have a friend, an engineer but not a programmer, who wrote a fortran program he's been using for decades to solve real problems.
But then recently he had to solve it for 10 different things instead of one. So he copy/pasted his calculations 10 times. He said the problem he was running into now was when he tweaked something, he had to change something in 10 places.
I think that's how normal people solve problems. They just bumble ahead doing what they know will work, but it's not pretty.
But then recently he had to solve it for 10 different things instead of one. So he copy/pasted his calculations 10 times. He said the problem he was running into now was when he tweaked something, he had to change something in 10 places.
I think that's how normal people solve problems. They just bumble ahead doing what they know will work, but it's not pretty.
As a programmer and every day user of really advanced Excel shenanigans, I can confirm your view is pretty spot on. The fact that I have the mental model of a programmer means I instinctively follow best practices that non-programmers simply can't get into their heads. Namely: keeping data and presentation separate, DRY, the concept of named variables, understanding how array formulas work and why you can map functions to intermediate in-memory vectors, the list goes on...
> A non-technical person CAN indeed make software... he just can't make maintainable software, and eventually his incompetence backfires.
Sure, and then they just pass it off to a competent technical person. It sure would be convenient if these people used the same language! Right now, when a non-programmer starts a project in Excel, and then hands it to a programmer to make into a good, maintainable version (perhaps as a native application, or a web application), the programmer has to start from scratch. That's an awkward discontinuity.
There's no reason I see it always has to be that way. We just haven't prioritized the ability for a non-technical person to make something, and also for a technical person to be able to pick it up and turn it into a full system.
Sure, and then they just pass it off to a competent technical person. It sure would be convenient if these people used the same language! Right now, when a non-programmer starts a project in Excel, and then hands it to a programmer to make into a good, maintainable version (perhaps as a native application, or a web application), the programmer has to start from scratch. That's an awkward discontinuity.
There's no reason I see it always has to be that way. We just haven't prioritized the ability for a non-technical person to make something, and also for a technical person to be able to pick it up and turn it into a full system.
One possible explanation for why non-technical people "can't" build software is simply that they don't want to learn how to do it. But that isn't the problem that Corda is trying to solve, I gather. The client avatar for Corda is, I reckon, the guy who wants to "hit the ground running" and become able to speak "software" to a programmer.
It would depend on the scope of what people are trying to achieve, at a certain point of complexity you pass from being a "non programmer" to being a programmer due to all of the inferred learning you get from experience.
I know a handful of non programers who can automates tasks in their everyday workflow but as you say they're not maintainable pieces of software or particularly transferable, they are custom tools they create for their own flow.
I know a handful of non programers who can automates tasks in their everyday workflow but as you say they're not maintainable pieces of software or particularly transferable, they are custom tools they create for their own flow.
Your input makes perfect sense! Is Corda the tool they need to "upgrade" their capabilities? Or is it something deeper that comes from "actual programming".
We seem to understand what a programmer is and what is not, but the "blurred line" between the hackers and the paper pushers is unknown.
We seem to understand what a programmer is and what is not, but the "blurred line" between the hackers and the paper pushers is unknown.
One of the worst type of projects we did was migrating overgrown excel bookshelves to a real database/app. The level of inconsistency and bare errors you’ll meet there is fubar. 90% chance of an integration failure because an entire business is not ready for that much to change and formalize.
That said, I believe that “dumbness” and non-evolution of excel (as a biggest player) is a root cause. If it wasn’t just a bunch of cells with chaotic references, but suggested a user to think in a strict “tabular datasets with comments, RLS and history” way, things could be much better (or worse, depending on how you use it).
Basically, in “show me your data, not code” excel is the latter, and that’s pushed to an innocent user. The result is pretty obvious.
That said, I believe that “dumbness” and non-evolution of excel (as a biggest player) is a root cause. If it wasn’t just a bunch of cells with chaotic references, but suggested a user to think in a strict “tabular datasets with comments, RLS and history” way, things could be much better (or worse, depending on how you use it).
Basically, in “show me your data, not code” excel is the latter, and that’s pushed to an innocent user. The result is pretty obvious.
From what I've heard, Lotus Improv (1991, failed 1996) was intended as a spreadsheet where each data set was stored in a separate namespace/object/table, which had named columns/rows, or even more than 2 dimensions. Apparently Quantrix is a successor used in the business/financial world, but is unfortunately not free or open-source. That's a shame, as I want something of that sort for casual scientific computation or statistical number crunching. Maybe I can use Python pandas or R dataframes, but spreadsheets have the useful trait that they're functional and side-effect-free, unlike scripts or notebooks.
Sounds like Access which always felt to me like a stepping stone between Excel and SQL Server with Visual Basic. My guess is that's what Microsoft has in mind anyway
You mean turn it into a different tool called Access or formerly FoxPro?
I see. Iirc, Access was too much developer-oriented last time I checked it around 20 years ago. As a developer you can just step up and try to take control, but users have no such courage. If excel merged parts of access later into a single product, suggesting, but not forcing users to maintain at least a partial scheme, then maybe. Sort of in-place gradual migration without “work here or go back” next morning ultimatums.
I agree with you, it's a basic problem for any skill. Anybody can draw, but drawing fine art requires the knowledge of the structure and tools used to draw it.
I suspect trying to build a programming language to stop having to think like a trained programmer, is a doomed project.
I suspect trying to build a programming language to stop having to think like a trained programmer, is a doomed project.
But, I can well imagine an art assisting program that I can feed my doodle to that can return a photographic (or other artistic) rendering of a person in that pose, even such that I can rotate the image, alter the pose, perhaps even animate it.
I still perhaps wouldn't understand why I should have chosen other poses, or why the lighting doesn't work, or why my material choice for the clothing fabrics hampers the expression I was seeking ... but it seems like an artist could come and touch up those elements.
Surely a similar level of thing could be done for programs (eventually)?
I'm a non-programmer in a new work environment where I'm feeling like I want to modify all the programs and add some functionality. In particular I've a lex-parse process I'd like to automate, relatively easy to describe sufficient to do it (with time I'll probably do it myself in PHP/python). But, doing that "doodle it" routine for such a simplistic app would be really useful.
I still perhaps wouldn't understand why I should have chosen other poses, or why the lighting doesn't work, or why my material choice for the clothing fabrics hampers the expression I was seeking ... but it seems like an artist could come and touch up those elements.
Surely a similar level of thing could be done for programs (eventually)?
I'm a non-programmer in a new work environment where I'm feeling like I want to modify all the programs and add some functionality. In particular I've a lex-parse process I'd like to automate, relatively easy to describe sufficient to do it (with time I'll probably do it myself in PHP/python). But, doing that "doodle it" routine for such a simplistic app would be really useful.
People always want to have that "now draw the rest of the fucking owl" step automated without them having to acquire the skill and do the hard and messy work to make it happen.
It doesn't work that way, and I'm relatively convinced it never will, within my lifetime. It's an inherently squishy target that it's trying to hit, with so many unstated assumptions and constraints. Trying to auto-scaffold software is worse.
Everything is easy when you're at the hand-wavy wireframes and stories stage; all the complexity and stupid yet necessary, yak shaving is glossed over, unless you have a engineer sitting in to rain on the parade.
It doesn't work that way, and I'm relatively convinced it never will, within my lifetime. It's an inherently squishy target that it's trying to hit, with so many unstated assumptions and constraints. Trying to auto-scaffold software is worse.
Everything is easy when you're at the hand-wavy wireframes and stories stage; all the complexity and stupid yet necessary, yak shaving is glossed over, unless you have a engineer sitting in to rain on the parade.
>but it seems like an artist could come and touch up those elements.
I don't think you can have artists or programmers 'touch up' a generated model post-facto without making compromises on the valuable bit of the project. Programmers will always be needed to understand the program inside and out, so it can be tweaked and controlled. Artists will always be needed to define the piece from top to bottom, so it can be controlled.
Either that or lots of hair being ripped out trying to control why the top lip on the 3d model keeps moving up and down when technically there's no muscle in your top lip, and it makes the one scene your big dramatic moment look janky as hell so you have to spend nights trying to figure out why the ML program made that, and it turns out nobody knows except the guy who made it and he's off in the bahamas helping take care of his sick wife so you have to scour the tech support community for hours...
Or that perfect line you drew across the face of a landscape painting is now pushed off to one side from running it through an art-style-transfer ML program and that destabilizes all the hidden geometry you were relying on to make the piece feel alive and now you have to know why the program did that, if you want to change it.
>Surely a similar level of thing could be done for programs (eventually)?
Yeah I think so. It's coming quite rapidly. Two minute papers is a scary youtube channel.
Any generative painting, cg model or computer program is going to fill the "kinda good enough" category and change the job of the trained professional to be controlling all the assumptions built into the generative program. You will make a super-powered tool, which is awesome, but alas human knowledge/skill/brains remains different to computers.
I don't think you can have artists or programmers 'touch up' a generated model post-facto without making compromises on the valuable bit of the project. Programmers will always be needed to understand the program inside and out, so it can be tweaked and controlled. Artists will always be needed to define the piece from top to bottom, so it can be controlled.
Either that or lots of hair being ripped out trying to control why the top lip on the 3d model keeps moving up and down when technically there's no muscle in your top lip, and it makes the one scene your big dramatic moment look janky as hell so you have to spend nights trying to figure out why the ML program made that, and it turns out nobody knows except the guy who made it and he's off in the bahamas helping take care of his sick wife so you have to scour the tech support community for hours...
Or that perfect line you drew across the face of a landscape painting is now pushed off to one side from running it through an art-style-transfer ML program and that destabilizes all the hidden geometry you were relying on to make the piece feel alive and now you have to know why the program did that, if you want to change it.
>Surely a similar level of thing could be done for programs (eventually)?
Yeah I think so. It's coming quite rapidly. Two minute papers is a scary youtube channel.
Any generative painting, cg model or computer program is going to fill the "kinda good enough" category and change the job of the trained professional to be controlling all the assumptions built into the generative program. You will make a super-powered tool, which is awesome, but alas human knowledge/skill/brains remains different to computers.
It's very hard to do high-quality generative art/music/poetry/anything without a complete model of human cultural associations, perceptions, and metaphorical frameworks for conceptualisation.
As you say, most generative work is empty because it's just form. Human creators manipulate form to communicate content. There's a message, and art is judged as much on the sophistication of the message as on the form it's carried in.
Form without content can be an interesting technical experiment, but it's culturally massless and kind of boring. Not to mention wrong in a destabilising way - like someone speaking random syllables that make occasional sense, but don't form a coherent message.
So the most successful generative work cheats by automating processes of cultural reference - like style transfer - or by adding levels of formal complexity that would be very difficult to handle by hand, but can at least produce something that seems a little original and surprising.
The less successful work doesn't even get that far.
Automated software generation is going to have similar problems. You have to parse intent, and then balance it against practicality. Getting that right is so hard humans really struggle with it, so I can't see machines being better at it any time soon.
As you say, most generative work is empty because it's just form. Human creators manipulate form to communicate content. There's a message, and art is judged as much on the sophistication of the message as on the form it's carried in.
Form without content can be an interesting technical experiment, but it's culturally massless and kind of boring. Not to mention wrong in a destabilising way - like someone speaking random syllables that make occasional sense, but don't form a coherent message.
So the most successful generative work cheats by automating processes of cultural reference - like style transfer - or by adding levels of formal complexity that would be very difficult to handle by hand, but can at least produce something that seems a little original and surprising.
The less successful work doesn't even get that far.
Automated software generation is going to have similar problems. You have to parse intent, and then balance it against practicality. Getting that right is so hard humans really struggle with it, so I can't see machines being better at it any time soon.
> Form without content can be an interesting technical experiment, but it's culturally massless and kind of boring. Not to mention wrong in a destabilising way - like someone speaking random syllables that make occasional sense, but don't form a coherent message.
Couldn't read that without being reminded of this: https://en.wikipedia.org/wiki/Prisencolinensinainciusol
As the composer says, "I thought that I would write a song which would only have as its theme the inability to communicate. And to do this, I had to write a song where the lyrics didn't mean anything." If you haven't heard it, pull it up on YouTube — it's quite an experience.
Couldn't read that without being reminded of this: https://en.wikipedia.org/wiki/Prisencolinensinainciusol
As the composer says, "I thought that I would write a song which would only have as its theme the inability to communicate. And to do this, I had to write a song where the lyrics didn't mean anything." If you haven't heard it, pull it up on YouTube — it's quite an experience.
...actually, there is one part of programming which already fits that description perfectly: Tuning some badly-performing SQL.
Seriously, look at the EXPLAIN of a complicated postgres query - hash joins, index scans, bitmap heap scans, materializing intermediate tables, and so on - it does the described conversion of high-level SQL to some really complicated code, and someone with in-depth knowledge can later use the plan to tweak the database or query to improve performance.
Seriously, look at the EXPLAIN of a complicated postgres query - hash joins, index scans, bitmap heap scans, materializing intermediate tables, and so on - it does the described conversion of high-level SQL to some really complicated code, and someone with in-depth knowledge can later use the plan to tweak the database or query to improve performance.
Aha! You perfectly expressed why I'm turned off by much of modern art - it's form, but no content (though sometimes the lack of content is the content, in a meta way, but it still makes for boring art).
I can’t tell whether this is “I just want to describe the high level and have an expert do the hard bits” (that’s what consultants do and how things normally work), or if it’s Dilbert Pointy haired boss “if I don’t understand it, it must be simple” where you imply the part you can do as an unskilled person is the important part, and the part an expert spends years learning is the trivia which can be tweaked after your important part is done - if it’s even needed at all.
Poser is one possible “3D human in a pose” software since 1995, like python and Delphi and Visual Basic are your rapid application development (RAD) tools that have been trying to do “programming as doodles” for years.
By the point you say “lex-parse process” you’ve already narrowed the scope from all possible software to a tiny area and used a lot of expertise to know that’s even a thing.
Choosing arrangement of 7 English letters has 8 billion or so possibles, “real words which people probably know” is four or five orders of magnitude smaller space of choices; maybe I just need to grunt some sounds to express what I want and a writer can tidy up the details of my comment later. But the choice of words is dozens of small choices which are inseparable from expressing myself. A writer, a consultant, doesn’t make your idea, they make their idea of your idea.
An artist could surely tell you why the choice of clothing doesn’t work, but the time you’ve got your artwork expressing what you want to the level where the choice of clothing fabric is the only thing left to tidy up, you are an artist already and have saved none of the important effort. You’re hiring Mozart to tell you why b-flat sounds off some fourteen minutes into your symphony.
It’s like gaining expertise is narrowing a space of options by orders of magnitude until we can jump close to a solution quickly. Being a non-expert is like assuming there is only a small space of possibilities that everts deal with and if we try to solve the problem we must end up in that space too and then all we need is an expert to nudge us to a settled location nearby. But instead we don’t see how big the space of billions of possibilities is and we go very far away, and an expert can only do the hard work of moving our solution to the space of possible answers - which is basically all the work and almost no better than starting from scratch.
It’s almost like we need the expert to jump near the solution space and then the non expert to nudge the details towards what they’d prefer. The program draws for you and you chose the clothing fabric and lighting. Like a computer game avatar generator where you just choose the hair colour and T-shirt colour - and equally unsatisfying because it’s not at all like you imagine you could express if only you knew what the expert knew.
Poser is one possible “3D human in a pose” software since 1995, like python and Delphi and Visual Basic are your rapid application development (RAD) tools that have been trying to do “programming as doodles” for years.
By the point you say “lex-parse process” you’ve already narrowed the scope from all possible software to a tiny area and used a lot of expertise to know that’s even a thing.
Choosing arrangement of 7 English letters has 8 billion or so possibles, “real words which people probably know” is four or five orders of magnitude smaller space of choices; maybe I just need to grunt some sounds to express what I want and a writer can tidy up the details of my comment later. But the choice of words is dozens of small choices which are inseparable from expressing myself. A writer, a consultant, doesn’t make your idea, they make their idea of your idea.
An artist could surely tell you why the choice of clothing doesn’t work, but the time you’ve got your artwork expressing what you want to the level where the choice of clothing fabric is the only thing left to tidy up, you are an artist already and have saved none of the important effort. You’re hiring Mozart to tell you why b-flat sounds off some fourteen minutes into your symphony.
It’s like gaining expertise is narrowing a space of options by orders of magnitude until we can jump close to a solution quickly. Being a non-expert is like assuming there is only a small space of possibilities that everts deal with and if we try to solve the problem we must end up in that space too and then all we need is an expert to nudge us to a settled location nearby. But instead we don’t see how big the space of billions of possibilities is and we go very far away, and an expert can only do the hard work of moving our solution to the space of possible answers - which is basically all the work and almost no better than starting from scratch.
It’s almost like we need the expert to jump near the solution space and then the non expert to nudge the details towards what they’d prefer. The program draws for you and you chose the clothing fabric and lighting. Like a computer game avatar generator where you just choose the hair colour and T-shirt colour - and equally unsatisfying because it’s not at all like you imagine you could express if only you knew what the expert knew.
>where you imply the part you can do as an unskilled person is the important part //
It's the important part, it's not the difficult part.
Like "I want a square, four tier cake with baby-blue royal icing, using a light fruit cake". That's super easy to say, hard to achieve. But the vital bit is contained in the simple definition.
The only other thing to say at this juncture is that in general there are two experts, domain-expert and programmer.
>I just need to grunt some sounds to express what I want and a writer can tidy up the details //
Well yes, we already have algorithmic story generation (eg ScienceDirect webpages), you "grunt" the topic and the program fills in the details.
It's the important part, it's not the difficult part.
Like "I want a square, four tier cake with baby-blue royal icing, using a light fruit cake". That's super easy to say, hard to achieve. But the vital bit is contained in the simple definition.
The only other thing to say at this juncture is that in general there are two experts, domain-expert and programmer.
>I just need to grunt some sounds to express what I want and a writer can tidy up the details //
Well yes, we already have algorithmic story generation (eg ScienceDirect webpages), you "grunt" the topic and the program fills in the details.
And the cake definition includes a lot of learned knowledge about humans, foods, rituals, pleasurable tastes, aesthetically pleasing looks; you practically are a domain expert on wedding cake already, you know what is possible, roughly how much it costs, how the difficulty scales with size, what isn’t possible, what isn’t reasonable, what options are available, how people will react, down to a very small scope of possibilities. what’s the cake equivalent for Martians who don’t eat and don’t have weddings and may not see in the human visual spectrum?
I want a thing which will be a centre of attention at an appropriate moment of their existence which their senses will experience .. an appropriate sensation to convey .. to achieve the appropriate goal of goodwill, at an appropriate amount of resource expenditure?
Does that still cover the important bit? If I say I want peace among nations, have I just done the important bit of international diplomacy, and it just needs some experts to tidy up the details?
I want a thing which will be a centre of attention at an appropriate moment of their existence which their senses will experience .. an appropriate sensation to convey .. to achieve the appropriate goal of goodwill, at an appropriate amount of resource expenditure?
Does that still cover the important bit? If I say I want peace among nations, have I just done the important bit of international diplomacy, and it just needs some experts to tidy up the details?
The difference between your cake and real life programs is that business processes tend to be rife with exceptions and details — frequently exceptions that are unknown at initial design time.
The whole reason for the existence of iterative processes like Scrum and friends is that your premise doesn't hold in the world of software, because then we could just use a waterfall process and be on time and budget every time.
The whole reason for the existence of iterative processes like Scrum and friends is that your premise doesn't hold in the world of software, because then we could just use a waterfall process and be on time and budget every time.
Yes, whenever I've had to help people struggling with their tools I found the problem starts well before they reach for the keyboard. They usually have problems decomposing the requirements to the constituent parts, often they can't even explain what they are trying to achieve.
I think iOS Shortcuts gets pretty close to a programming language for normal people. You aren't going to write anything super-complex, but regular users can eliminate some pain points in their daily grind with a small amount of effort.
A personal experience of a programmer who worked in a dozen different industries and in different roles up to CIO level is that non-programmers do not need tools but training. Once people raise to the level of their incompetence, they do not go back to school but persist in the old way of working or find comfortable workarounds.
Catching the moment when someone can not do their job efficiently anymore is an HR problem, and businesses can not rely on introspection and self-evaluation to work in this situation.
Catching the moment when someone can not do their job efficiently anymore is an HR problem, and businesses can not rely on introspection and self-evaluation to work in this situation.
Hah, most programmers can't make maintainable software.
I see programming mostly as a mindset. Like doing algebra. You couldn't do it as an infant, because you just didn't understand the concept of using letters instead of variables.
Of course, there usually is a level of complexity that you need to get used to as well, but you can also see this as a defect of most API's, or as an inherent quality of doing anything nontrivial.
I see programming mostly as a mindset. Like doing algebra. You couldn't do it as an infant, because you just didn't understand the concept of using letters instead of variables.
Of course, there usually is a level of complexity that you need to get used to as well, but you can also see this as a defect of most API's, or as an inherent quality of doing anything nontrivial.
If it's all about the mindset, why is the creator of one of the Excel behemoths not a programmer? It has a concept of variables (named cells even allows Excel users to name variables), If-else statements (while important for imperative languages, not all programming languages necessarily have if-else), loops (using array functions), and functions (often using another sheet for separate scope). Why do so many want to gatekeep out Excel users who have reached that level as not being programmers? Because the IDE is a GUI, and we've all been taught (sometimes via trying to make one) that GUI programming will "never" work/catch on? Because sometimes it needs to be ported to a different language? (Done that from python to Golang as a 'real' programmer.) Because they sometimes ask for help? (Stack overflow, anybody?) Because Excel sheets don't have unit tests? (Be real - there's tons of code out there that doesn't have tests.) Because their software causes messes when it has a bug? (I'm not ashamed to admit I've written code that has bug in it; ones that managed to make it into production, even!)
I wouldn't consider someone who's new to Excel and doesn't use formulas to be a programmer. But having seen some truely bohemoth spreadsheets from finance (and being asked to port them), I'm having a hard time drawing a line between the two.
I wouldn't consider someone who's new to Excel and doesn't use formulas to be a programmer. But having seen some truely bohemoth spreadsheets from finance (and being asked to port them), I'm having a hard time drawing a line between the two.
Indeed, making maintainable software is difficult.
To share your analogy: many folks have trouble with algebra. It's not that it's categorically impossible for them to do it; there could be any number of factors (bad math education, home troubles making school more difficult, etc.).
With a lot of time and dedication many of these folks could eventually get pretty good at doing algebra. I've tutored these folks before. Some of them have enough time and dedication to get better at it. But without that (and at least time is outside most of these folks' control), many of them will struggle.
So I don't think the parent comment was saying "Most people can't program in the same way a gorilla can't speak English", but instead "Most people can't program because they don't have the acquired skills to program." I would add that these folks' goal is often not programming but their original job.
To share your analogy: many folks have trouble with algebra. It's not that it's categorically impossible for them to do it; there could be any number of factors (bad math education, home troubles making school more difficult, etc.).
With a lot of time and dedication many of these folks could eventually get pretty good at doing algebra. I've tutored these folks before. Some of them have enough time and dedication to get better at it. But without that (and at least time is outside most of these folks' control), many of them will struggle.
So I don't think the parent comment was saying "Most people can't program in the same way a gorilla can't speak English", but instead "Most people can't program because they don't have the acquired skills to program." I would add that these folks' goal is often not programming but their original job.
Most people have their own domains and don't want to make softwares. But their jobs depend on softwares sometimes. When the software developers don't understand the domain, it's reasonable to provide a DSL for users to customize by themselves.
If the programming language is as natural as the human language, DSL is just the regular language.
After all, language is for the precise and concise communication, human to human or human to machine.
After all, language is for the precise and concise communication, human to human or human to machine.
> If the programming language is as natural as the human language,
In my experience, it isn't. Computers are much more pedantic and less forgiving than other people. Computers won't understand "what you meant to say".
Additionally people often have trouble communicating effectively with other people in their natural language. So a DSL being in that language doesn't necessarily guarantee the user's success in using that DSL correctly.
In my experience, it isn't. Computers are much more pedantic and less forgiving than other people. Computers won't understand "what you meant to say".
Additionally people often have trouble communicating effectively with other people in their natural language. So a DSL being in that language doesn't necessarily guarantee the user's success in using that DSL correctly.
The word technical in the original sense means being skilled in a craft. So anyone who can make software is by that definition "technical". Where would you draw the border between technical and non-technical persons?
https://en.wikipedia.org/wiki/Javelin_Software tried that; the people who liked it loved it, and then it crashed and burned.
> Imagine we build the ideal programming language that both technical and non-technical humans alike can understand. What does it look like?
I think it would look like a component architecture, with Elm syntax.
As someone that barely programs but still hacks on open-source, I just want the code for one thing to be in one place, not spread out across 4 different files.
And I want one action/object to have just one name. Not three names like createServer, newServer, server, etc
I think it would look like a component architecture, with Elm syntax.
As someone that barely programs but still hacks on open-source, I just want the code for one thing to be in one place, not spread out across 4 different files.
And I want one action/object to have just one name. Not three names like createServer, newServer, server, etc
I think you're wrong. System thinking and abstraction are required, unless the users have some mileage in it or a natural talent, they will hit a wall real quick.
I think you're right. System thinking and abstraction are natural talents. Not everyone is good at them.
I used to know someone who didn't get basic algebra. She wasn't stupid in other ways, but she just couldn't make that leap from arithmetic to the first level of symbolic abstraction.
If you spend all of your time working with people who find abstraction easy, it's hard to understand that a lot of people really don't.
I used to know someone who didn't get basic algebra. She wasn't stupid in other ways, but she just couldn't make that leap from arithmetic to the first level of symbolic abstraction.
If you spend all of your time working with people who find abstraction easy, it's hard to understand that a lot of people really don't.
note that I said training or talent, I don't think these topics are secrets only accessible to few, but thinking the tool is the craft is misguided. Even in college, I'd use C or Java blindly and made a mess. Anyways, you need to ensure some ideas are understood before letting people "program".
[deleted]
[deleted]
I think you are wrong. excel can be evil and cause immense pain and suffering https://qz.com/119578/damn-you-excel-spreadsheets-jp-morgan-...
Yep, more people should be starting from spreadsheets and figuring out how to make them more capable of correctness and maintainability, instead of starting from programming concepts and figuring out how to make them more accessible. Most people who work in businesses already know how to program, they just do it in formulas in spreadsheet cells.
Tool itself is at https://coda.io, seems similar to but more powerful than Notion, (https://notion.so) which I have used, with pricing to match.
Tangentially, it's good of Panic to link to the above at https://www.panic.com/coda/ - or perhaps they were just getting fed up with dealing with people in the wrong place!
Tangentially, it's good of Panic to link to the above at https://www.panic.com/coda/ - or perhaps they were just getting fed up with dealing with people in the wrong place!
Coda bought the name from Panic.
I'm a little bit obsessed with keeping up with solutions in this space, and I've been watching both Coda and Notion for a while.
Coda actually just released their v2.0 a few days ago which has brought some much needed bugfixes and stability improvements. I've had some time to discuss larger strategy with their team, and I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability.
I definitely like their product, and am following them going forward. If you're at all interested in this space, you should check out Coda just for the sake of seeing where we are (as a field) in solving this problem.
Coda actually just released their v2.0 a few days ago which has brought some much needed bugfixes and stability improvements. I've had some time to discuss larger strategy with their team, and I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability.
I definitely like their product, and am following them going forward. If you're at all interested in this space, you should check out Coda just for the sake of seeing where we are (as a field) in solving this problem.
> I can tell they're working really hard to "strike the right balance" between easy to use / discoverability and capability.
That's exactly it, I was saying to a colleague earlier that I wish* there were an open-source self-hostable option, but the closest I've found - Trilium Notes - is way further over to 'capability' than 'easy to use / discoverability', to use your spectrum. (I was a bit harsher, describing it as a spectrum from good UX to programmable.)
*(mainly because exports aren't that useful - Notion exports some but not all data, and then you've got to sanitise (or get lucky) the CSVs it does export for the new tool)
That's exactly it, I was saying to a colleague earlier that I wish* there were an open-source self-hostable option, but the closest I've found - Trilium Notes - is way further over to 'capability' than 'easy to use / discoverability', to use your spectrum. (I was a bit harsher, describing it as a spectrum from good UX to programmable.)
*(mainly because exports aren't that useful - Notion exports some but not all data, and then you've got to sanitise (or get lucky) the CSVs it does export for the new tool)
I have not looked into Coda yet, but have a few observations on the user / programmer divide.
To me, spreadsheets are just another programming paradigm. I have seen business users build impressive things using Excel (excluding here VBA). I'd even say that in terms of raw productivity (i.e., just in terms of business problems solved over time, without any consideration for maintainability etc), the spreadsheet paradigm is vastly superior to the regular textual programming paradigm – as long as the problem is simple enough. And most of normal business is dead simple.
As soon as the process or problem hits a certain complexity, the Excel solution becomes painful to use, understand and change. I believe this is in part specifically fault of the tool - while Microsoft has been doing a great job in terms of power user features (Power Query, PowerPivot), they have apparently not been willing to extend the spreadsheet paradigm itself to meet the requirements we demand from business software, which is a pity and missed opportunity.
Secondly, what I have also observed is that most users, even users building complex workbooks, are not willing to make the jump to textual programming (e.g., VBA). I think programming in general requires a high level of frustration tolerance that most people are not willing to bring up except when they really have to (e.g., to use Excel, which is basically unavoidable in 99% of businesses).
To summarize, there is still room to come up with a system that makes building simple things as simple as Excel, while being flexible enough that it scales to meet production software requirements.
To me, spreadsheets are just another programming paradigm. I have seen business users build impressive things using Excel (excluding here VBA). I'd even say that in terms of raw productivity (i.e., just in terms of business problems solved over time, without any consideration for maintainability etc), the spreadsheet paradigm is vastly superior to the regular textual programming paradigm – as long as the problem is simple enough. And most of normal business is dead simple.
As soon as the process or problem hits a certain complexity, the Excel solution becomes painful to use, understand and change. I believe this is in part specifically fault of the tool - while Microsoft has been doing a great job in terms of power user features (Power Query, PowerPivot), they have apparently not been willing to extend the spreadsheet paradigm itself to meet the requirements we demand from business software, which is a pity and missed opportunity.
Secondly, what I have also observed is that most users, even users building complex workbooks, are not willing to make the jump to textual programming (e.g., VBA). I think programming in general requires a high level of frustration tolerance that most people are not willing to bring up except when they really have to (e.g., to use Excel, which is basically unavoidable in 99% of businesses).
To summarize, there is still room to come up with a system that makes building simple things as simple as Excel, while being flexible enough that it scales to meet production software requirements.
I like going the other way where as a "Programmer" I don't need to program so many things. Most "things" can be declared: text, html, lists, trees, tables, databases, ...
For example in XFCE, I can add an "Applications Menu" to the menubar (panel) and use a custom menu file with a list (or tree) of programs to run. The icons, labels and how to run the programs are declared in .desktop files -- no "programming" required.
For example in XFCE, I can add an "Applications Menu" to the menubar (panel) and use a custom menu file with a list (or tree) of programs to run. The icons, labels and how to run the programs are declared in .desktop files -- no "programming" required.
I'm not terribly excited with the idea of making spreadsheet style programs easier, but I suppose it can't hurt, either.
Personally, I think programming languages becoming closer to spoken languages would be more useful. I first learned of that concept from this Reddit thread:
https://www.reddit.com/r/linux/comments/da718w/i_think_the_f...
There, the author of the thread talks about the benefits of Inform 7, a programming language specifically designed for creating interactive fiction games. It's an incredibly impressive bit of work, and is the most promising path toward getting regular folk into programming.
I also came across this interesting article from Wolfram:
https://blog.wolfram.com/2010/11/16/programming-with-natural...
which goes into natural-language programming and how they will (hopefully) become dominant in the future.
Personally, I think programming languages becoming closer to spoken languages would be more useful. I first learned of that concept from this Reddit thread:
https://www.reddit.com/r/linux/comments/da718w/i_think_the_f...
There, the author of the thread talks about the benefits of Inform 7, a programming language specifically designed for creating interactive fiction games. It's an incredibly impressive bit of work, and is the most promising path toward getting regular folk into programming.
I also came across this interesting article from Wolfram:
https://blog.wolfram.com/2010/11/16/programming-with-natural...
which goes into natural-language programming and how they will (hopefully) become dominant in the future.
We've all seen incredible things built in spreadsheets. Spreadsheets are plenty powerful. I haven't met a clever+motivated person yet that couldn't build something incredible in a spreadsheet.
What I think is missing is a way to help the author (and other team members) make sense of the artifact as it gets more complex.
Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs.
With spreadsheets for example, you are basically forced to find a cell that seems to have data you like. Then you have to back-track formula references + check for macros/scripts and hope that no references have broken.
I humbly submit this is a problem that a team like the Coda team should be solving.
What I think is missing is a way to help the author (and other team members) make sense of the artifact as it gets more complex.
Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs.
With spreadsheets for example, you are basically forced to find a cell that seems to have data you like. Then you have to back-track formula references + check for macros/scripts and hope that no references have broken.
I humbly submit this is a problem that a team like the Coda team should be solving.
Excel needs exactly one thing to blow open the doors on productive programming: a new "function" data type. Since it's just a data type, you put it in a cell just like any other data type. Have some way to call it, like `A1(arg1, arg2)` or something. Now you can leverage the full capabilities of Excel to manage it, name it (named ranges), etc just like other data.
A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.
A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.
Sounds like you want to move VBA into the cell. I issue no opinion on doing that, just offering an observation.
Actually you make a great point (thank you!), but honestly I wouldn't want it to have anything to do with VBA.
For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.
For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.
I completely agree and have been thinking the same thing for a while now. Another reason you need the function language to be really integrated with the rest of the spread sheet (unlike VBA) is so that global variables are also visible in the dependency tree and topological sort. For instance, imagine a cell containing the following lambda function:
function (x, y) { return A1*x + y; }
sounds like a great idea
Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.There are many programs, each does a different thing, you program your final product by composing programs. Users of the final product are the programmers.
I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven't finished it.
Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want!
Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it.
You may think the solution is to get people to publish accessible APIs. I think that's a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products.
I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
I found myself being frustrated recently at Lifx smart lights. I had wanted to put a slider widget on my home screen of my phone. There is no way to do that. The only way is for me to write my own program. I started work on it, then had to wade through ridiculous amounts of documentation on the lifx api site, android docs. I still haven't finished it.
Consider on the other hand, if android were a massive lisp environment where every API is available in the global scope - think emacs - how easy would it be to program the things you want!
Now I use Lifx as an example and I appear to be bashing them. I am not. At least Lifx publishes their API for consumption. Another time I tried to pipe an app that generates white noise for sleep to another program (TL;DR I was too cheap to buy a Sonos), but alas no publicly accessible API. I had to hijack the BT stream to do something remotely useful to it.
You may think the solution is to get people to publish accessible APIs. I think that's a band aid solution. The core issue is somehow programs have become less composable over time. Far from the original ideals. Programs become standalone products.
I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
Lisp as end-user extension language?
> The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp.
> It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
> (2) Bernie Greenberg says that Dan Weinreb's implementation of Emacs for the Lisp Machine came before Greenberg's implementation for Multics. I apologize for the mistake.
~ "My Lisp Experiences and the Development of GNU Emacs" (Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference). https://www.gnu.org/gnu/rms-lisp.html https://news.ycombinator.com/item?id=20374467
> The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp.
> It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
> (2) Bernie Greenberg says that Dan Weinreb's implementation of Emacs for the Lisp Machine came before Greenberg's implementation for Multics. I apologize for the mistake.
~ "My Lisp Experiences and the Development of GNU Emacs" (Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference). https://www.gnu.org/gnu/rms-lisp.html https://news.ycombinator.com/item?id=20374467
> Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.
It's the right attitude to take, but let's try to provide some definitions. What does it mean "to program"? Certainly we have contemporary ideas of what it all involves. But at the end of the day it's hard to come up with a more encompassing definition than "telling a computer what to do (and possibly what to do later)." This means that by merely "using" a computer (ie through a GUI or whatever -- manipulating it somehow) one is, by this definition, doing some kind of programming.
With that definition in mind, we now see that the systems we have provided users are completely hamstrung. We have given them limited environments and languages (languages here being mostly of a visual/UI variety) to work with.
What's worse is that we have goo examples from even recent history about how alternatives can work: Visicalc, Hypercard, Smalltalk, etc.
Insofar as these conversations rely on discussing "programming languages" -- a loaded term, and only part of the picture really -- rather than whole "computing environments," then we tread further down a losing path for everyone.
It's the right attitude to take, but let's try to provide some definitions. What does it mean "to program"? Certainly we have contemporary ideas of what it all involves. But at the end of the day it's hard to come up with a more encompassing definition than "telling a computer what to do (and possibly what to do later)." This means that by merely "using" a computer (ie through a GUI or whatever -- manipulating it somehow) one is, by this definition, doing some kind of programming.
With that definition in mind, we now see that the systems we have provided users are completely hamstrung. We have given them limited environments and languages (languages here being mostly of a visual/UI variety) to work with.
What's worse is that we have goo examples from even recent history about how alternatives can work: Visicalc, Hypercard, Smalltalk, etc.
Insofar as these conversations rely on discussing "programming languages" -- a loaded term, and only part of the picture really -- rather than whole "computing environments," then we tread further down a losing path for everyone.
> What does it mean "to program"?
Whatever definition you end up with, it must have equal representation of data and code.
Current GUIs are have the same problems as the 50's analog computers that required somebody inside them plugging cables all day long.
Whatever definition you end up with, it must have equal representation of data and code.
Current GUIs are have the same problems as the 50's analog computers that required somebody inside them plugging cables all day long.
>Sometimes I wonder if the people of the 1960s (i.e the people who came up with lisp, multics, unix) had the right idea: to use a computer you should program it.There are many programs, each does a different thing, you program your final product by composing programs. Users of the final product are the programmers.
So if I have a computer and I want to access the internet, I should have to write my own browser first?
No... "to use a computer you should program it" isn't a philosophy, it's a technical limitation from when "programs" were simple and everything ran in a terminal, and no one but engineers and students would ever be expected to touch a computer in the first place, and it doesn't scale.
Should people be able to write software for their own computers? Yes.
Should programming be considered a normal part of computer use, and be far more common than it is, with systems and software being more open than they are? Yes.
Should people need to write their own software? NO.
>I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
It wasn't entirely wrong. End users don't want to write software, they want to use their computers do to things - and most of those things now require multiple thousands or millions of lines of code written by engineers with domain specific knowledge. Turning programs into products is a way of managing the complexity necessary for software that's useful to people in modern society.
So if I have a computer and I want to access the internet, I should have to write my own browser first?
No... "to use a computer you should program it" isn't a philosophy, it's a technical limitation from when "programs" were simple and everything ran in a terminal, and no one but engineers and students would ever be expected to touch a computer in the first place, and it doesn't scale.
Should people be able to write software for their own computers? Yes.
Should programming be considered a normal part of computer use, and be far more common than it is, with systems and software being more open than they are? Yes.
Should people need to write their own software? NO.
>I think we as an industry made a wrong decision turning programs into products. We should have kept programs as programs - make them super composable, and then let the end user design their own products that fit them best.
It wasn't entirely wrong. End users don't want to write software, they want to use their computers do to things - and most of those things now require multiple thousands or millions of lines of code written by engineers with domain specific knowledge. Turning programs into products is a way of managing the complexity necessary for software that's useful to people in modern society.
Regarding browsers, a reasonable complaint is that even if you want to, and have the skills it is far too difficult to modify a browser or use its parts to build something else. This might be fixed by better design, as somebody noted in this recent HN comment [1]:
"... (browsers) are multiple different kinds of programs, welded together for no sensible reason: an http fetching daemon, a "runner" to open URLs, several document viewers, a virtual machine, an OS with an API, extensive libraries for everything that the OS below the OS already offered, one or several programming language JIT compiler(s) and runtime(s), and some bits and pieces. In a healthy environment, there would not be a second OS on top of the normal one. And all those parts would be separate software, with standardized interfaces. ..."
[1] https://news.ycombinator.com/item?id=21061067
"... (browsers) are multiple different kinds of programs, welded together for no sensible reason: an http fetching daemon, a "runner" to open URLs, several document viewers, a virtual machine, an OS with an API, extensive libraries for everything that the OS below the OS already offered, one or several programming language JIT compiler(s) and runtime(s), and some bits and pieces. In a healthy environment, there would not be a second OS on top of the normal one. And all those parts would be separate software, with standardized interfaces. ..."
[1] https://news.ycombinator.com/item?id=21061067
Separating all of that into components, each with its own interface, would be more elegant... but I don't think it would solve the complexity problem so much as decentralize and standardize it. A modern browser still needs all of that functionality, regardless of where it comes from, at least for most users.
It also potentially creates a similar problem to DLL hell in Windows, where updating or changing a component potentially breaks dependent software, or multiple versions of the same component need to be kept around. And then there's the "n+1 standard" problem, where everyone doesn't actually agree on what the "standardized" interfaces should be.
The real problem, to me, is that the FOSS model of every user being a programmer fundamentally breaks down when software reaches nontrivial complexity (wherever you choose to set that bar.) You could substitute the browser as the subject of your first sentence with just about any software people use - most of it is too complex for the average person to fully reason about, much less the average programmer.
I don't know how to solve that, other than require all software to be simple enough to fit in a single file and run in a REPL but that's obviously not feasible.
It also potentially creates a similar problem to DLL hell in Windows, where updating or changing a component potentially breaks dependent software, or multiple versions of the same component need to be kept around. And then there's the "n+1 standard" problem, where everyone doesn't actually agree on what the "standardized" interfaces should be.
The real problem, to me, is that the FOSS model of every user being a programmer fundamentally breaks down when software reaches nontrivial complexity (wherever you choose to set that bar.) You could substitute the browser as the subject of your first sentence with just about any software people use - most of it is too complex for the average person to fully reason about, much less the average programmer.
I don't know how to solve that, other than require all software to be simple enough to fit in a single file and run in a REPL but that's obviously not feasible.
Aaron Hsu’s talk on APL - I think this talk - https://youtube.com/watch?v=9xCJ3BCIudI - has a more radical interpretation; by the time you’re using lisp to compose lightbulb apis and Bluetooth stream hacking, you’re already past the point of divergence that you mention and are on the wrong side of it.
APL does the hard part of choosing composable functions and presents those to the user, as a simplified interface. Sorting isn’t a global namespace of thirty different sort algorithms so you can delight in picking the exact one you want, sorting is one character (⍋) so you can use it as a composable building block and not care about the details.
I might agree that the core issue is that programs have become less composable over time - but what you ask for doesn’t seem to address that at all. Part of the job of designers and creators is to make simplifying decisions on behalf of users; I don’t want the lightbulb raw interfaces to be exposed to me as an alternative to a crummy closed app product, I want a well designed composable app product as the api I use - all at once, so I don’t have to care about negotiating access tokens or header padding anymore than I have to care about LED heat dissipation or mains smoothing inside the bulb when I flick a light switch.
For composition I want Lego not a machine shop, and I accept compromises in ability to get that. I want grep not fopen().
When you say you want composition what you’re asking for is a machine shop; not a bad thing to ask for, but completely different from where you started out with Unix shell composing of finished product programs which you originally said you wanted.
APL does the hard part of choosing composable functions and presents those to the user, as a simplified interface. Sorting isn’t a global namespace of thirty different sort algorithms so you can delight in picking the exact one you want, sorting is one character (⍋) so you can use it as a composable building block and not care about the details.
I might agree that the core issue is that programs have become less composable over time - but what you ask for doesn’t seem to address that at all. Part of the job of designers and creators is to make simplifying decisions on behalf of users; I don’t want the lightbulb raw interfaces to be exposed to me as an alternative to a crummy closed app product, I want a well designed composable app product as the api I use - all at once, so I don’t have to care about negotiating access tokens or header padding anymore than I have to care about LED heat dissipation or mains smoothing inside the bulb when I flick a light switch.
For composition I want Lego not a machine shop, and I accept compromises in ability to get that. I want grep not fopen().
When you say you want composition what you’re asking for is a machine shop; not a bad thing to ask for, but completely different from where you started out with Unix shell composing of finished product programs which you originally said you wanted.
What id love to see more is blurring the line between user and designer. Too often software gets in the way of the user and simple tweaking to an interface etc. can make a world of difference. Unfortunately this is usually either not possible or involves a user navigating endless configuration options or worse configuration files. Maybe that’s not a big deal to us in the software industry but it is a huge problem for your average user.
I agree. There's no reason we can't have this, we've had tools like Delphi and VB for a long time now. Why can't I just choose widgets from a palette and make my own Outlook interface?
Maybe it could even be taken a step further and turn it into a UNIX pipeline composition equivalent in GUI form. Trying to imagine what a system could look like, I see a kind of tiling window manager in which you can place arbitrary widgets (list views, sliders, text entry, etc) and hook together their inputs and outputs, maybe with a little scripting glue.
Maybe it could even be taken a step further and turn it into a UNIX pipeline composition equivalent in GUI form. Trying to imagine what a system could look like, I see a kind of tiling window manager in which you can place arbitrary widgets (list views, sliders, text entry, etc) and hook together their inputs and outputs, maybe with a little scripting glue.
According to my own distinction, Blurring the Line Between User and Programmer is unpossible:
A user is someone who asks why a software is not working (and even in the 21st century this is still far more common than it should be).
A programmer is someone who asks why and how a software is working. Eventually this also includes failure modes, so the user's question above will not stay unanswered forever.
A user is someone who asks why a software is not working (and even in the 21st century this is still far more common than it should be).
A programmer is someone who asks why and how a software is working. Eventually this also includes failure modes, so the user's question above will not stay unanswered forever.
> Blurring the Line Between User and Programmer is unpossible
And why on earth do you believe that this difference in mindset cannot be taught?
And why on earth do you believe that this difference in mindset cannot be taught?
This is (sort of) one of the sticking points people like Kay and especially Papert made. Because all computing is interactive, it is always an ongoing part of a more general "learning process." There are many types of learners and ways that they can internalize otherwise complex systems/concepts. It is the job of the computing environment to be flexible enough to take advantage of each person's particular method for learning how to properly (and powerfully) manipulate it.
Lots of talk about spreadsheets in here, and rightly so. See also Hypercard. These systems are (were) incredibly popular, and regular people were able to do things with them that they could not in other media. It's largely because the systems they represented were well designed -- not because people had some particular competency in "abstract thought" or "systems thinking." We are all human and, for the most part, we all do that stuff one way or another.
Lots of talk about spreadsheets in here, and rightly so. See also Hypercard. These systems are (were) incredibly popular, and regular people were able to do things with them that they could not in other media. It's largely because the systems they represented were well designed -- not because people had some particular competency in "abstract thought" or "systems thinking." We are all human and, for the most part, we all do that stuff one way or another.
It is near impossible to teach a mindset that is not desired.
This reminds me a lot of Word. You can embed a spreadsheet and you can add code to the document (I even remember using VBScript back in the day). What's old is new again?
Not directly related, but The Whole Code Catalog seems to be a really interesting collection.
To avoid confusion, it's from the same author: https://futureofcoding.org/catalog/
I'm thinking about Excel spreadsheets. Let me elaborate: a non-technical guy creates a monstrosity: one of those spreadsheets that "works", and tasks the programmer with maintaining it. At every level, the non-technical understands what's going on, because he is familiar with most formulas (that's the beauty of Excel IMO). He just wants the programmer to focus on making sure that everything works "just fine".
Forget for a moment about what "just fine" means. Let's say they can go back and forth until they can convey what they mean to each other.
My point is that the very first sentence of the post is not correct.
> “The world’s been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one. It feels kind of broken,”
A non-technical person CAN indeed make software... he just can't make maintainable software, and eventually his incompetence backfires.
If I'm correct, then Corda and other tools aimed at "making the laymen build software" are solving the wrong problem. The spreadsheet, and before that a piece of paper, just solved that problem. What the laymen need are the mental tools that a programmer uses to "speak" about software, in the sense that what a human can see on the screen isn't the whole picture of what technical people mean by "software".
Hope I made myself understood. Can anyone assist? Am I wrong?