[HN Gopher] First step in making programming easier is to be con...
___________________________________________________________________
First step in making programming easier is to be conscious of what
makes it hard
Author : b3morales
Score : 46 points
Date : 2021-08-13 17:32 UTC (5 hours ago)
(HTM) web link (lighttable.com)
(TXT) w3m dump (lighttable.com)
| jamii wrote:
| Hi. I'm the author. Such nostalgia. With tools like airtable and
| notion around today, we're actually making substantial progress
| towards making simple tasks easy.
|
| These days I'm writing at https://scattered-thoughts.net/ and
| working on https://github.com/jamii/dida and
| https://github.com/jamii/imp. Same ideals, but backed by many
| more years of ~~failure~~ experience.
|
| Also still complaining about things https://scattered-
| thoughts.net/writing/against-sql and breaking things
| https://scattered-thoughts.net/writing/internal-consistency-...
| panzagl wrote:
| Does anybody have the inside baseball on what happened to this
| after YC got involved? It seems like there should be more of a
| lesson here than just to not back software kickstarters.
| H8crilA wrote:
| Serious question: why make something you're good at easier for
| others? The only effect would be to depress your own salary.
| Animats wrote:
| Sometimes it looks like programming for banal tasks peaked with
| Visual Basic.
|
| How did the web environment get botched so badly that creating
| pages with GUI tools disappeared?
| stupidcar wrote:
| There are myriad GUI tools targeting the web platform. If none
| have achieved the success of VB, it's not through a lack of
| capability.
| Olreich wrote:
| Wix, Squarespace, etc.
| wyuenho wrote:
| For a time Front Page and Dreamweaver existed and it spit out
| all kinds of proprietary code with weirdly named functions and
| classes. Generally, it's not for a lack of trying but the devs
| that get handed source code these tools generated had a hard
| time modifying it. When they succeeded, these tools had a hard
| time recognizing the manual changes devs made. So the tools
| were fighting with the devs all the time, and then the "pros"
| came in, and decided to hand code everything with text editors.
|
| Similar stories still happen with Wix and Squarespace. The web
| pages they generate are powerful, but also full of dead code
| that is only useful to the editors, not the end product.
| ChrisLTD wrote:
| Many folks are attracted to new tools and techniques rather
| than outcomes. And since our tools and techniques are
| constantly in flux, few reach a level of stability and maturity
| where a GUI tool would work well.
| gmiller123456 wrote:
| Back then, we could tell the user that they had to have a
| screen resolution of at least 800x600, and couldn't resize the
| window, and they liked it. Kids today have higher expectations.
| zamfi wrote:
| (2014)
|
| Today, writing actual code is the programming of last resort.
| Software like Airtable and other no-code tools would handle these
| examples without the need for some poor inexperienced programmer
| to write code from scratch using a bespoke IDE.
|
| I'd add that in 2014 there was another super-relevant Ko & Myers
| paper literally about _what makes programming hard for users_ :
| https://faculty.washington.edu/ajko/papers/Ko2004LearningBar...
|
| That paper is worth a read for everyone who wants to be helping
| novice programmers with new tools!
| haolez wrote:
| I somewhat agree with you, but I've seen a lot of smart people
| struggle with Airtable and no code tools. I can't explain why.
| jandrese wrote:
| Tools like that try to tell you that they'll handle all of
| the complexity for you, but they do this by adding a whole
| new layer of complexity. So they tend to demo well but blow
| up in your face when you try to use the tool in anger. As
| soon as you're asking the system to do something the
| developer didn't consider you now have an additional layer of
| complexity to understand before you can even start to solve
| your original problem.
| haolez wrote:
| That's what I saw at my company: it looked great in theory,
| but in practice we need programmers to help fix (and
| sometimes create) the automation workflows.
| civilized wrote:
| Would these people find it straightforward to program
| equivalent functionality from scratch?
| haolez wrote:
| No. I'm talking about business people (or a sample of
| those). They have difficulties trying to create tools.
| b3morales wrote:
| I don't understand why the article thinks it's reasonable for
| someone with literally 0 experience to develop an application
| with multiple features and integrations with other systems from
| scratch, on their own. The point about space age machines
| notwithstanding, this is inherently complex and skilled work.
|
| We don't expect someone who's never touched a chisel to be able
| to fabricate and install a full set of kitchen cabinets, either.
| And there's no shame in that -- they just need to spend time
| learning. Or they can do the "google -> stack overflow ->
| copy/paste" thing by going down to their local home goods store
| and buying some prefab particle board units and watching a
| YouTube video on how to hang them. (And again, no shame -- online
| video can be an excellent source of craft information.)
| karmakaze wrote:
| Yeah I was following long with the End User story and went Wow
| to myself when I saw 'lein', really? We'd first have to tell
| them there's this thing called Terminal or Command Prompt.
| jamii wrote:
| Most of the tasks in the article can now be solved by tools
| like airtable or notion with minimal training. Certainly much
| less training than would be required to do the same thing using
| traditional programming tools. So not only is the problem
| reasonable, we are actually making progress.
| civilized wrote:
| What is airtable capable of these days? Last I checked, years
| ago, it was mainly an easy way to build and maintain a
| database.
|
| To be fair, though, a lot of apps are just a database with a
| CRUD UI
| jamii wrote:
| A shared database with permissions and forms covers most of
| the task in the article. Airtable also now has an
| event/workflow system and a ton of integrations and plugins
| for doing stuff like sending email.
|
| https://www.airtable.com/product/views
| https://www.airtable.com/product/automations
| https://www.airtable.com/integrations
|
| It's getting to the point where it can handle most of the
| internal software needs of a small-medium company and also
| has a ton of javascript hooks for covering that last 20%.
| majormajor wrote:
| In some ways programming should be easier than carpentry like
| that. In either case, you don't know what you don't know, and
| you have to learn what's possible, what's practical, and what
| tools to use for what. But in carpentry you also have to
| practice physical skills. "I know this router will let me do
| what I want but I'm not able to hold it steady enough," say.
| You have to translate "what I want to build" into "here are the
| discrete components, joints, cuts, etc" but also there's a
| physical skill and ability needed to perform the actions.
|
| In programming, though, turning what you want to happen into
| statements the language can compile is purely a problem of that
| translation phase. There is a lot we can do in the language and
| environment to make that easier - consider all the overhead of
| a map operation in Java (with `.stream()` and `.collect()` and
| restrictions like "lambdas can't throw checked exceptions") vs
| a list comprehension in Python. A newcomer is going to be able
| to pick up the latter much more quickly.
|
| I don't think that looks like "0 experience -> complex app in
| one day" but I think it could be a lot easier than it is today.
| It's already a lot easier than it was 20 years ago.
| dkersten wrote:
| > But in carpentry you also have to practice physical skills
|
| In programming you have to practice mental skills. That is,
| abstract problem solving, logic, bigger-picture-how-things-
| fit-together. There's a reason many beginners struggle with
| concepts like pointers or recursion/recursive data types.
| These things become second nature with practice, just like
| the physical skills do, but to a beginner who has not
| practiced such things, they're equally difficult.
| Jtsummers wrote:
| Pointers are a great example of accidental complexity.
| Outside of very specific domains, most people writing
| software _never need pointers_.
|
| Introducing them to the end user who just wants a way to
| track project status is a great way to bar them from
| actively participating in developing their own solutions.
| Forcing them to be beholden to the IT department, rather
| than empowering them to accomplish their goals.
| bruce343434 wrote:
| > Outside of very specific domains, most people writing
| software never need pointers.
|
| You know it's not true. Pointers, references, whatever
| you call them. They exist for a reason.
| majormajor wrote:
| They exist for a reason in the same way that there are a
| bunch of different types of fasteners - there are
| situations where it's critically important, but writing
| the average line-of-business application isn't one of
| those, in the same way that you can bang together a
| custom shelf without knowing about more than a drill and
| screws.
|
| We're talking about accessibility for getting started.
| Pointers and recursion are good ways to scare people
| away. They were all my highschool CS teacher cared
| about... guess who avoided CS for a few years as a result
| until figuring out ways to use other languages to solve
| specific problems in non-CS courses several years into
| college?
| bruce343434 wrote:
| Yes, mastering programming, like anything, takes time,
| practice and patience. Yes, school sucks. Now what is
| your point? To dumb down everything about programming to
| the most common denominator so that 1 day old noobs may
| be equal to grand masters? Not gonna happen.
|
| Why do you never hear these types of complaints when
| people say it takes 10000hr to master the piano? People
| never suggest taking shortcuts and people accept and
| respect the path of becoming a master. But when it
| concerns programming, everyone immediately jumps to "how
| can we make this as dumb as possible?"
|
| Guys. Shit takes time and effort. The freshmen will be
| fine.
| Jtsummers wrote:
| > Yes, mastering programming, like anything, takes time,
| practice and patience. Yes, school sucks. Now what is
| your point? To dumb down everything about programming to
| the most common denominator so that 1 day old noobs may
| be equal to grand masters? Not gonna happen.
|
| Ah yes, those stupid noobs, fuck them all. The objective
| is not to "dumb down" but to permit the expression of
| intent by people to achieve their own ends, without the
| need for intervention by members of the programming
| guild.
|
| Not everyone needs to master programming, they need to
| achieve a goal. Just as someone can build a table without
| ever becoming a master carpenter (it's a saw, sandpaper,
| and a drill and screws or hammer and nails, done), many
| people have problems that could be solved with
| programming if only the manner of interfacing and
| directing a computer were not unnecessarily arcane.
|
| > Guys. Shit takes time and effort. The freshmen will be
| fine.
|
| Guy, it's not about the freshmen. It's about people who
| need to get shit done. It'll be fine if professional
| programmers aren't the only ones who can achieve their
| ends with programming tools.
| bruce343434 wrote:
| > without the need for intervention by members of the
| programming guild.
|
| "Self" learning is a pipe dream. You are always being
| guided. Be it statically and indirectly by the tutorial
| writer, the comments of the youtube tutorial, or some
| discord community helping you out. This is not a bad
| thing. Stop acting like I'm advocating for some evil
| elite.
|
| > Not everyone needs to master programming, they need to
| achieve a goal
|
| Great! For them exists python.
|
| > if only the manner of interfacing and directing a
| computer were not unnecessarily arcane.
|
| I agree that it would be a net win if the likes of linux
| tutorials stopped using vim. Once we look past that we
| can see there are plenty of ides out there today that
| perform the function of the article's subject.
| Underlining faulty expressions, suggestions on how to fix
| it, a nice debug output at the bottom.
|
| > It's about people who need to get shit done
|
| You need a good baseline. You just do. Plenty of people
| won't do their own plumbing either. It would take a bit
| of time to learn the basics to fix your sink (python
| script), but to become someone who can design the pipage
| in a building ("business software")? That just takes time
| and experience. No way around it.
| anigbrowl wrote:
| _> Not everyone needs to master programming, they need to
| achieve a goal
|
| Great! For them exists python._
|
| And there I was hoping that I wasn't unfairly
| stereotyping you.
| anigbrowl wrote:
| _Why do you never hear these types of complaints when
| people say it takes 10000hr to master the piano? People
| never suggest taking shortcuts and people accept and
| respect the path of becoming a master. But when it
| concerns programming, everyone immediately jumps to "how
| can we make this as dumb as possible?"_
|
| If you want to play classical piano that's true. If you
| want to play piano in a band there are lots of tricks to
| make improvisation and harmonization easier. Every music
| store sells 'fake books', which document the lyrics and
| melody of popular songs with simplified harmony using
| basic chords so you can knock out songs in a bar or at an
| event that will be easily recognized by casual audience.
| If you use electronic keyboards they either have 'auto
| accompaniment' or sequencing features built-in so you can
| vamp in one key or just play chords and have an
| arpeggiator pump out a riff, which tools have given rise
| to new musical styles of their own.
|
| Likewise bass players often use shapes to navigate the
| fretboard just as guitar players may use capos or slides
| to make chording easier. Lots of great musicians get by
| with little music theory or even literacy; Dave Brubeck
| was nearly thrown out of music school when they found out
| he couldn't read music and had just been copying his
| instructors or recordings by ear, and he had to sign an
| agreement that he would never teach music in order to
| graduate.
|
| Theory is important, but it's not the whole story by any
| means. There are lots of excellent pianists who are not
| skilled at improvisation and have never composed
| anything.
|
| Bringing it back to computing, this is _Hacker_ News, not
| Engineer News or Computer Scientist News. Tinkering and
| _bricolage_ are a key part of hacking, which is often
| about tactical problem solving rather than industrial
| reliability or pure craftsmanship. What I 'm hearing from
| you is an emphasis on process rather than result, which
| is good for developing one kind of skill but closes the
| door to many other possibility. It reminds me of the
| derision for 'toy languages' like Python when they first
| appeared - and yet the latter is now the most widely used
| programming language of all, because it's accessible.
|
| That doesn't make knowledge of C any less valuable (or
| aesthetically satisfying) but it does mean that people
| can get tasks done without necessarily needing a low
| level understanding of types, memory management and so
| on. I _like_ pointers and the beautiful simplicity of the
| structures you can build with them, and I like the
| feeling of omniscience I get reversing something in a
| debugger and reading assembler. But I also like writing
| craptastic working prototypes of things in an hour and
| using them for weeks or months before rebuilding them
| into something reliable that I can leave running
| unattended.
|
| I'm strongly in favor of programming tools that make
| things fun, accessible, and results-oriented rather than
| forcing everyone through a period of misery in order to
| gain elite status. Yes, this will increase the number of
| half-ass programmers and half-ass software projects, but
| also equip a much wider number of people with some useful
| skills that can be refined to find their own level, just
| the same as people with some DIY skills can be handy and
| are in a better position to learn advanced skills than
| people who have never worked with their hands at all.
| majormajor wrote:
| What are you even on about? Nobody is saying mastery
| should happen on day one. We're saying _getting started
| could be easier_.
|
| I don't understand how that's offensive or so counter-
| intuitive.
|
| The piano is a perfect example of something accessible:
| you push a key, you get a note. You push a different one,
| you get a different one. That doesn't prevent there from
| being a lot of complexity and practice needed for
| mastering it.
|
| Your plumbing example from elsewhere in the discussion is
| also a perfect example:
|
| > It would take a bit of time to learn the basics to fix
| your sink (python script), but to become someone who can
| design the pipage in a building ("business software")?
| That just takes time and experience.
|
| Python exists. It makes "fixing the sink" task easier
| than C. C makes it easier than assembly. Why on earth
| would suggesting that we could peel off even more of the
| rough edges for beginners be insane? That's literally an
| example of how we've done it in the past. Obviously
| Python exists. Obviously it doesn't need pointer
| knowledge to use. Just like we were saying.
| Jtsummers wrote:
| > You know it's not true.
|
| No, I don't.
|
| > Pointers, references, whatever you call them.
|
| References are not pointers, and I stand by what I said.
| _Pointers_ are not needed by most people writing software
| outside of very specific domains.
|
| _References_ are a related but distinct concept. I can
| "hold a reference" to something without ever being able
| to read what its memory address is or change what memory
| address that reference points to. The power to do that is
| unnecessary for most programs that are written.
|
| > They exist for a reason.
|
| Did I ever say otherwise?
|
| EDIT: Expanding on the notion of "need". A programmer
| using a C library "needs" pointers because the C library
| almost certainly makes use of them. The user may or may
| not _need_ to use pointers themselves to interact with
| the library (that is, it may offer an interface based on
| values and not pointers). A programmer on any OS I can
| think of will be making use of pointers through similar
| levels of indirection. As an Erlang hobbyist, the
| implementation almost certainly uses pointers internally,
| but as an Erlang programmer I wouldn 't use them
| directly. In order to write a program in Erlang, I never
| need a _pointer_ , though I may make use of some kind of
| _reference_ (process IDs are a kind of references, but
| they are not pointers).
| bruce343434 wrote:
| > The power to do that is unnecessary for most programs
| that are written.
|
| Ok. So don't use that power then. Or use references
| instead, which are conceptually the same thing.
|
| > Did I ever say otherwise?
|
| You quite clearly stated their purpose was very niche. I
| think you took my statement a bit to literally, as what I
| meant to convey was: no, they are not niche.
|
| Edit: after reading your edit, I would like to remind you
| we were discussing the needs of learning the concept of
| pointers. While what you mention may not be literal C
| pointers, that is besides the point (haha) because they
| (methods of indirection) are conceptually equal.
| Jtsummers wrote:
| > Or use references instead, which are conceptually the
| same thing.
|
| In the same sense that a donut is topologically the same
| as a coffee mug, sure.
|
| > You quite clearly stated their purpose was very niche.
|
| I did not. I said they weren't needed outside of specific
| domains, which is not the same as "niche".
|
| > we were discussing the needs of learning the concept of
| pointers
|
| Per my original comment, no, we were not. I wrote of
| needing pointers. I said nothing about the needs of
| learning the concept of pointers.
|
| My comment was, and I stand by this, that pointers are a
| fantastic example of accidental complexity. They are
| present in many programming languages, and are a thing
| people have to use as a consequence but which are not
| themselves necessary for the problems that many people
| intend or need to solve. _References_ , which are not the
| same as pointers except again in the sense of _donut =
| coffee mug_ , are a more general concept that has broader
| utility than _pointers_ without the added complexity that
| pointers bring to the table (though depending on the
| manner of the references they may bring in their own, see
| both Python and Java and the unintentionally altered
| collection values).
| bruce343434 wrote:
| Lets not get stuck on defining what niche means. Its
| meaning has been defined for a while already. Niche =
| specific domain related. Anyway.
|
| In which ways are references of broader utility? And what
| is so complex about pointers? The fact that it doesn't
| hide behind language magic? Well, that you can just
| ignore: I don't _need_ to see or edit the address it
| holds.
| [deleted]
| philipswood wrote:
| Agreed. Skill comes with practice, but the on-ramp is steep
| today, and seemingly getting steeper.
|
| Even while todays tools can do so more, I remember my first 16k
| microcomputer with nostalgia.
|
| It booted immediately and into a simple known state.
|
| If you got onto trouble you could switch it on and off again.
|
| It booted into a REPL, a ROM-based BASIC.
|
| The language was simple, immediate, and with accompanying
| manuals discoverable.
|
| It could immediately let you program things that seemed to
| matter to you; text, simple sounds and graphics where all easy.
|
| The first way to use it, and the first entry point it gave was
| programming it.
|
| You could load programs from disk, but it was obvious that they
| were things that could be made - and taken sometimes taken
| apart (although some where understandable, some weren't. And
| that was a prompt to learn more).
|
| The hardware was easy to get to, even if it wasn't easy to
| understand, some of it was visible (like the memory mapped
| display).
|
| I help juniors without a lot of technical background today and
| there seems to be books of lore to digest before getting to
| something tangible.
| commandlinefan wrote:
| It makes me wonder if attempts to simplify programming have
| actually made it _harder_. I remember Visual Basic: you
| couldn 't ask for simpler than that. Want a button? Drag a
| button onto your form. Want tabs? Drag tabs. Want a list that
| contained entries from a database? Drag the list and specify
| the database.
|
| VB made trivial projects trivially trivial. But whenever you
| tried to apply it to any real-world scenario, you'd get stuck
| trying to infer all of the "hidden state" that the too-simple
| interface was trying to shield you from.
|
| I had the misfortune of working with the original no-code
| too, Salesforce, for a couple of years - in spite of the
| name, it's not all that "sales" focused; it's actually more a
| "VB for web-based enterprise applications" with a sales
| instantiation implemented in it. It had the same problems as
| VB, too - it was _too_ simple for any actual problems.
| Simplicity was obtained by hiding details... that turned out
| to be crucial for basic business functionality (and don 't
| even think about performance).
| bsder wrote:
| > Salesforce, for a couple of years - in spite of the name,
| it's not all that "sales" focused; it's actually more a "VB
| for web-based enterprise applications" with a sales
| instantiation implemented in it.
|
| You know, this is the first time anybody has ever been able
| to explain to me what Salesforce actually _does_.
| jfax wrote:
| This is why I admired TempleOS, which confronted these some of
| these questions and tackled it from the ground up. Why should it
| be hard to program graphics to the screen? It shouldn't be more
| than one code include, if any. Why plaintext source code, and not
| hypertext? Etc.
| akomtu wrote:
| Imo, programming isn't very different than assembling cars or
| jets. What makes it difficult is the uniqueness of every project:
| it's always a novel car engine, developed by a team who came up
| with a new combustion process, and it's a novel car frame with
| bespoke electronics that the engine needs to be hooked up to.
| Don't expect 12V from the battery: you'll need to build a custom
| adapter for it. Even the wheels aren't standard. Everything is in
| flux, every single component has its quirks, unexpected
| behaviors, and is constantly updated. Just attaching wheels needs
| the mechanic to be an expert in wheel and car frames
| manufacturing, because the unique steel recipe used to make this
| frame may be incompatible with this particular type of rubber.
|
| What would make programming easier is hardcore standardisation of
| everything, so wheels are always round, engines have standard
| bolt patterns and car frames have standard size room for an
| engine and wheels. What makes such standardisation difficult is
| the complexity of what needs to be standardized: nobody has
| enough mental capacity to fully grasp the software equivalent of
| the car engine and make a sound standard for it. This is why most
| standards are a mess of exceptions on hundreds of pages.
| rektide wrote:
| > _Much of the pain in programming is taken for granted. After
| years of repetition it fades into the background and is
| forgotten. The first step in making programming easier is to be
| con[s]cious of what makes it hard._
|
| I think there's an invaluable starting place here, & that we
| should all spend a lot of time writing down & identifying this.
|
| A huge amount of programming & it's difficulty lies in having
| your bearings. Knowing what you have, & having some sense of
| direction forward or destination. Being able to see & comprehend
| what is about us, what we have can be a challenge. Or one could
| be lacking a sense of what to do to progress forward. Or perhaps
| one doesn't really know where the code needs to have, doesn't
| have a good picture in mind of the object.
|
| The human mind wants to have the full model, of where we are,
| where to go, and where to end up: a view of the current
| _structure,_ the _operation_ to advance, which yields us a new
| _structure._
|
| Programming is ultimately about consciousness, an understanding
| of the pieces of this allagmatic flow. Having good tools &
| environments that tell us what is about us, that show us the
| objects around, the processes/operations that are occuring, to
| let us know/predict where the state is going to end up, is a kind
| of meta-causal comprehension skill that programming rests upon.
| Trying to think of what is hard is good, but we also ought be
| trying to turbo-charge our exploration of what new capabilities
| instruments, tools & environments can do to augment our views &
| vantages of code, state, & their execution.
| kazinator wrote:
| Speaking of bearings, I'd introduce newbies to the Context
| Diagram:
|
| https://en.wikipedia.org/wiki/System_context_diagram
|
| OK, that bubble in the middle is your program. How does it fit
| into the world?
|
| While drawing the context diagram, we should keep in mind two
| questions (at least):
|
| - is the bubble at the center of it necessary at all? Can we
| remove it, such the other pieces around it function just fine
| without it? Is it just a "middleman" that can be "cut out"?
|
| - if the bubble is necessary, does it have to be a computer
| program, or can it exist just fine as some non-computerized
| process? Can _some_ of it be computerized, and some of it not?
|
| - if the computer program is necessary, does it have one that
| we make, or can we find an existing one?
|
| - if the program has to be one we make, or can we modify or
| extend another program we already made?
___________________________________________________________________
(page generated 2021-08-13 23:02 UTC)