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.
How did you choose Zig for Dida, and would that be your language of choice if you were considering a rewrite? You're super clear [0] that Zig was better for you than Rust in this instance.
Oh cool, I enjoyed the posts on differential dataflow and incremental/streaming systems on your new site! If you don't mind my asking, how did you get into independent research?
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.)
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.
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).
> 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.
I wonder if you are confusing Visual Basic with something else.
As far as I know, VBA, VBScript, and VB.Net are "regular" Turing complete programming languages that can access anything on a Windows machine and not some sort of visual programming as such. The VBA editor is not up to modern standards, but it's pretty nice from the perspective of someone who started out in the 1980s with various MS Basics. The various forms of the language are not simpler than old fashioned Basic, but have a fair amount added.
What fits your description more, in my experience, is Microsoft Power Automate, which is a sort of low/no code environment that is only slightly better that Malbolge IMO. It makes it incredibly difficult bordering on impossible to reuse logic.
Designing an interface layout by drag and drop has been around since basically the beginning of GUIs. It's not "no-code", it's just defining the interface in a standard way as data.
People have tried from time to time to make a programming environment to appeal to, that is graspable by, people who are allergic to entering code in a text editor. Sometimes it looks sort of like "programming" by drawing a flow chart.
And it generally, as far as I know, either fails to be easy enough for most people, or makes anything complex horribly cumbersome.
As I said, Power Automate is a (horrible) example.
"a visual programming language (VPL) is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually."
"The Visual Basic, Visual C#, Visual J# etc. languages of the Microsoft Visual Studio IDE are not visual programming languages: the representation of algorithms etc. is textual even though the IDE embellishes the editing and debugging activities with a rich user interface."
> Designing an interface layout by drag and drop has been around since basically the beginning of GUIs. It's not "no-code", it's just defining the interface in a standard way as data.
The GGP didn't call VB "no-code". That was referring to Salesforce.
My first programming class at a school was Visual Basic (Maybe 5 or 6.0?) and it was definitely very drag and drop GUI based.
Drag buttons and text fields onto a panel, click them and edit their Metadata in the sidebar, doubleclick them and Visual Studio would open a file with an auto generated OnClick() handler with an empty body and a bunch of comments surrounding it saying something along the lines of "do not edit anything before/after this line."
You'd run it by clicking the big green arrow button and I got an A in that class without ever knowing how to actually build and share an executable. I made a blackjack game and tried sharing it with some friends but it only ever ran on my machine (because only I had Visual Studio installed).
A better teacher would have helped too, haha. Nothing against him, from what I understand he was the business class teacher and taught 1 period of intro to programming because the school couldn't find a replacement for the previous years' teacher.
I’m more in agreement with GP. Legacy Visual Basic had a substantial use case of visual editing of forms and form elements with a programming language behind it so you could attach actions to events. What they said resonated with my unfortunate experience working in VB for around 6 months back in the mid to late 90s.
Having had a range of early programming experiences, including BASIC and assembler on a ZX Spectrum,Pascal on an ICL mini and PL/1 on an IBM Mainframe,nothing I had seen or worked with up until that point came close to Visual Basic for hitting that sweet spot between power and ease of use.
I never got a chance to use Delphi in any serious way,so that might have been an alternative contender,but certainly VB was orders of magnitude easier than building Windows apps in C++ and Microsoft Foundation Classes, which was the other main alternative offering at the time VB3 appeared.
Non-programmers could use it to put together something that looked reasonably good and would work reasonably well without having to fill up their heads with a hideous morass of technological complications,and if you did have past development experience then it took away immense amounts of the pain and frustration which had previously been an inherent part of programming for Windows.
Having worked for two separate companies which managed to create serious long-lived applications and make quite satisfactory amounts of money using VB5 and 6, I'd also reject the idea that the language was inherently incapable of giving you the kind of control needed to do serious real-world work.
The default solutions which the UI toolkit pointed you towards often ended up as dead ends (the data control bound to an ADO or RDO database was a particularly terrible way of managing business processes and yet it was the one which Microsoft seemed obsessed with pushing people towards) but the language offered plenty of ways to do things which weren't terrible if you took the time to work out how to do so.
Yes, if you pushed things far enough the limitations of the environment's abstractions, the fundamental sloppiness of its language design,and the choices which it decided to make for you would start to really hurt in terms of performance or ongoing maintenance. And version control was a joke, and testing and release integration were worse,and DLL hell was something which bit you on an all-too-regular basis.But you could get a pretty long way before that hurt became acute,and in the meantime you could do much that was useful and productive
with much less up-front effort than you'd need to do the same thing in any current .net language,or even in something as supposedly friendly and accessible as Python.
As a kid the REPL was always intimidating to me. I never liked it and was always frustrated trying to get it to work whenever I was dropped into DOS. I loved GUIs and gravitated to them as a user. It wasn't until much later that I developed an appreciation for the terminal.
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.
> 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.
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.
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).
> 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.
> 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).
The complexity is historic, not accidental. If you start with a linearly organised address space then you need some way to reference the items in it.
The physical address in the linear space [1] isn't just the obvious option, it's the only option. [2] It's a short step from there to indirect addressing via a linear lookup table, and/or simple address arithmetic to find items stored sequentially.
You can only avoid this by adding layers of abstraction which hide these mechanisms.
But you can only do that after the mechanisms are in place. Otherwise your "reference" is just an unimplementable idea with no meaning.
[1] Ignoring hardware paging, because that's usually invisible.
[2] Ignoring hypothetical magic associative O(1) key-value store hardware with the same speed as semiconductor RAM - which could be built at ludicrous expense, but would cause complexity issues of its own.
To be clear I'm using "accidental complexity" in the sense of Brooks. He breaks complexity in software systems, in his No Silver Bullet paper, into two categories: accidental and essential. My contention is that for most programers and programs pointers fall under the category of accidental complexity. That does not diminish their utility, nor mean that they never fall under the category of essential complexity (indeed, having spent most of my career on embedded systems, there are things we could not have done or done as easily without pointers). Just that, for most of the things people want to accomplish when programming a computer, pointers (though often not the broader sense of references) are accidental (i.e. unnecessary) complexity.
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.
Funnily enough, I really struggled going to Java and python coming from C++ originally. What do you mean I don't know if I'm getting a copy? The semantics of passing something to a function were so confusing and I was never sure if I got a copy or not. Pointers made so much sense.
I find D's implementation of pointers not only to be fairly easy and straightforward to understand, but quite powerful and useful. They basically fix most of the problems with C's pointers.
The toy virtual machine and language I built in D uses function pointers heavily to implement the machine's opcodes. They made it incredibly simple to program the 'CPU' of the virtual machine. The opcode functions are setup as an array of function pointers.
Whenever a byte that represents an opcode is read, it simply calls the function being pointed to at the corresponding index in the array. It allows for additional opcodes to be easily added without hassle or breaking things. Every other way I tried without pointers was convoluted and didn't work as expected. Using an array of function pointers just works.
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?
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.
What are you even on about? Nobody is saying mastery should happen on day one. We're saying getting started could be easier and that mastery isn't required for a lot of stuff. So much gets done by generalists or hackers...
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.
EDIT: Maybe the distillation of where I think you're not following the original article and argument here is that "the things that make programming hard to get started with" are not the same as "the things that make programming hard to master."
> 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.
> 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.
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.
> abstract problem solving, logic, bigger-picture-how-things-fit-together.
These skills are not unique to programming. It’s true that building sophisticated applications requires skills that need to be developed over time. But there are many many useful programs short of that that can be written with a beginner’s limited knowledge. We see already with python widespread use by non computer scientists in certain fields. I think going forward this will become more and more common across more fields and beyond academia.
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.
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.
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%.
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.
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.
What you describe though isn't a car building process, it is a Formula 1 team. In Formula 1 you get ahead by using non-standard everything, and even if there is a clear rule, the teams still try to stretch and loophole it to get advantage.
> 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.
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?
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.
Those tools hide the easy part of programming - typing, syntactic peculiarities of a programming language, etc. They do absolutely nothing about the meat of the task: distilling a vague idea into fully formal description, structuring and compressing that description by factorization and abstraction, and then iteratively refining your work as the computer repeatedly proves to you that you still don't have a fucking clue what you actually want. Computers don't accept bullshit.
The core of programming is truly figuring out the problem you're solving. Everything else is management of complexity.
> The core of programming is truly figuring out the problem you're solving. Everything else is management of complexity.
The second point is equally important, as you already said in "structuring and compressing that description".
The core of programming is try figuring out the problem (in your mind) and then serializing your thoughts in a way that both the computer _and_ other humans (or you yourself a year later) can easily understand.
The latter obviously is irrelevant if you write the code once, run it a few times and then throw it away, but we all know that most problems occur because this does not happen too often.
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.
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.
I don’t have the answer, but I suspect one piece of it is that the “code” part and the “logic” part can both be challenging. Exposing just the logic part (and hiding the code) like Airtable does can make things easier, but it’s definitely not a silver bullet.
As a sibling comment notes, part of the challenge with the logic part itself, is that many folks don’t know exactly what they want before they start building. They think they do, and on some level they actually do, but it is not the detailed level at which software systems operate. That’s a major reason why all software is built in iterative process, there’s exploration that happens, not just of the software systems, but also of the whole logical structure and requirements.
A platform that can make that process easier will transform the world!
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.
I assumed we were talking about the pre-.Net days of VB6 and earlier. Having a resizable window was certainly possible, but quite a bit of work, and not the norm.
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.
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.
I think this is the right answer. I've been thinking about this a lot lately as I have friends and colleagues who are so non-technical that they can barely use a command line, so I find myself wanting to make tools for obscure purposes that would also be really easy to use.
I liked VB back in the day for the ease to being able to throw together a simple GUI quickly though I don't miss the verbosity of Basic. There's a lot of RAD options available these days but few have hit that sweet spot of being relatively powerful while also accessible to first timers and bundled with a good variety of examples and helpers.
It's called low-code, the tools exist, can even build complex systems pretty well.
Outsystems and Mendix are some of the good ones.
But they cost money, they have a built-in lock-in, and programmers don't like them, because they simplify their jobs too much and are not good for the resume.
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.
CLIs just need better tutorials and wrappers out there. If you've got a bunch of wrappers/helper methods for doing mundane tasks for your OS it should curb most of the frustration and inefficiency.
Computers have always sucked it doesn't matter what OS you're using they're full of undefined behaviour. No one is employed to design the whole and make sure the development environment is integrated to the point where it's as easy as the writer wants it to be.
Alternatively what you'll get too remedy this is some commercial tool that works in a very specific context and with a specific set of services and most likely won't interoperate with other stuff.
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.
I’m remembering Think Pascal, where most of the toolbox was pre-included. It also initialized a drawing window and a text console, so you only had to learn QuickDraw if you wanted to use it.
Not to be rude, but: caring about people other than yourself. This reads to me like asking a doctor why they advocate healthy living seeing how that would lower their demand.
It's more like "doctors making sure there are not too many doctors", which in some countries they actually do (by having a say, via professional organizations/unions, how many student spots are there in medical schools).
There's an inherent difficulty in making difficult things easy. I think we're more likely to improve the ergonomics of writing software rather than make it easier for others to translate business logic into code.
I like to think that making software easier to write will just free up more capital to be spent on other software problems. I haven't seen many software projects where the client doesn't compromise features due to budget or time.
You're right, but "compromise features due to budget or time" happens in pretty much any industry. Take construction, everyone would like to have a larger house. And just to stick with construction, think of the salaries of the people involved, and why are they what they are. The person that makes the most in construction is the guy that trades the packaged MBSes because to even know what happens after you sign that mortgage document is not that easy to understand to the average Joe.
Is that really the only effect you can think of? The flip-side of lower salary is more people can do it, including hobbyists, non-profits and others creating useful things in the world that benefit everyone. It's not a zero sum game.
Playing this kind of knowledge gatekeeping can work for a time, but it's a double-edge sword. Yeah you might profit for a while, but eventually someone will come and yank the rug out from under you because you have no competitive or innovative muscle left.
The way I look at it is this: if someone can automate something they should. As a programmer I've never had a shortage of higher order problems to solve. The skills that make you a good programmer allow you to move up the foodchain as lower-level problems are solved. You should embrace this rather than fight against it.
Early in my career I was making websites for $2-5k a pop, now most of that can be done with Shopify or Squarespace for $5/month. Can you imagine if I was still clinging on to that business model today? I'm sure it would be a pretty anxious existence wondering when the clients will dry up, and frankly I'm pretty happy not worrying about SFTPing someones files somewhere and hoping they don't call me when they misplace their password.
So am I scared about no-code tools? Hell no, I welcome these developments. If more smart entrepreneurs can get started building cool things and get traction, it's only a matter of time before they outgrow those tools, and come to me asking how we can take it to the next level. Same goes for big data, ML, etc. All of these are tools, we are nowhere near general AI that will obsolete a smart human technical mind.
Because it’s a short sighted solution not to make it easier and to build consensus.
The real threat to programmers isn’t going to come from easier tools it’s going to come from the failures of programmers and the ability for large companies to capitalise on it. I work in a non-tech organisation. We (and this is the strategical we) would like nothing more than to sign the keys of our IT empire over to Microsoft, IBM or whomever and simply use standard software because using custom software has been nothing but a three decade long story of failed, delayed and over budget projects. I’m from a programming background myself, and I never actually believed in standard software because it always sucked worse than the specialised software, but that is changing.
Over the past 5 years we’ve replaced more than 25 independent solutions (and enough money that I’ve not had to cut down on staff because of it) by simply using Office365. We used to have a myriad of different project management tools, now they’re all handles by teams and planner which both seamlessly integrate to our ESDH system (public sector documentation and record keeping).
We’ve kept our own programmers on staff, and they are busy, because we still handle quite a bit of internal data or services in Python and Powershell and we do a massive amount of RPA (robot process automation), but guess what’s now part of our Azure license. Because Microsoft recently pitched automation anywhere, which happens to be our branch of RPA software because we did it a little different than E&Y types recommend, but it’s like 5% of the license fee to run a municipality with 10.000 employees suite of RPA with Azure Auromation compared to what it would cost to do so in its competition. Which is just crazy.
That will be the doom of programmers, and the shitty tools that lead to failed projects might be part of the reason.
Maybe the market will move fast enough that it’s not an issue. It wasn’t an issue for web-developers when small businesses started being capable of buying a standard webshop for almost nothing, and as I mentioned we still employ our own developers. But I’d frankly be worried if I was young and not careering into some non-replaceable part of programming and even then, I think you might find that plumbers will earn more money than you in 10 years when the market is also saturated with all the people we are currently herding toward IT degrees because we need a few hundred thousand extra right now.
Doesn't matter, we'll make it easier for ourselves. The personal computer revolution made it possible for the rest of us to make computers useful for ourselves, on our own terms. If necessary, we'll hack our way just deep enough into software with enough flexibility to support "coding," and we'll code. (For instance, Excel).
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-...