Hacker News Reader

Comment by b3morales | Hacker News Reader

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.)

View on HN

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.

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.

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.

He's not confusing it with something else. He's describing ~VB4-6.

https://en.wikipedia.org/wiki/Visual_Basic_(classic)

Yes, VB from the 90s. I moved to web development and haven’t looked at it again since - they may have improved it since.

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."

https://en.wikipedia.org/wiki/Visual_programming_language

So the original comment sounded perfectly reasonable to me, except it sounded like a critique of something other than VB.

I remember this from the 90s, although I never used it:

https://en.wikipedia.org/wiki/Prograph

> 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.

Just for the flavour of the experience I'm describing:

"REPL":

https://youtu.be/X-5gZwfFPVM

What it actually looked like:

https://youtu.be/z_jWcgwgmwg

(Not my videos, just pulled of the internet)

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.

> 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.

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.

> 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.

> 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.

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.

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."

> 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).

> 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).

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.

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.

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.

https://www.tutorialspoint.com/d_programming/d_programming_p...

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.

> 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.

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

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%.

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.

Reply on news.ycombinator.com