3 ms·

This is so pessimistic! What is the basis for thinking there are large barriers to most people becoming software makers? I was in high school 12 years ago, whe

This is so pessimistic! What is the basis for thinking there are large barriers to most people becoming software makers? I was in high school 12 years ago, when iphones just hit the market at like 800 bucks each and there was no firebase or react native or Medium articles or youtube tutorials covering 1st step code generation commands to deployment for every tech stack. The language of the day was Java. There was no npm and not a trillion python libraries that you can do anything imaginable with. Is there any specific reason a 16 year old today couldn't make the app this guy did? As a software engineer I like the idea that I do a black magic that nobody could ever understand, but I genuinely don't think it's true.

vorpalhex 7y ago
12 years ago most folks had little webpages they cobbled together from snippets and ugly widget generators. It worked well enough. I've spent most of this week figuring out how best generate device specific thumbnails for my blog.
- yaitsyaboi 7y ago
  12 years ago the author of this post would have had a little website and now he has the ability to record and instantly share video with his family in a pretty delightful app :)
  - ori_b 7y ago
    12 years ago, half the not-so-technical people I knew had little websites. Now, there's this one author.
  - peanutz454 7y ago
    So are you saying the barrier remains the same? Earlier we had less access to stuff, and could write simpler software. Now we have more access, but software has become complex
    - nonbirithm 7y ago
      I think as computers have advanced in power the technology that runs on them increases in complexity to utilize the new power. With economies that prioritize growth, people in charge of things like web standards want new ways to innovate over their competitors. Developers don't want the power afforded by additional computing cycles to go to waste. They also find things lacking, like the difficulty of accomplishing "holy-grail" webpage layouts. Standards are expanded to accommodate these pain points, and new features are added, but nothing can be taken away as this would break things that already work. This continues to the point where the web implodes under a plethora of animated SVG hammers striking anvils and autoplaying videos. Thinking of it another way, computers of a long time ago could do only basic things like printing strings or drawing lines. Computers of today can still do those things, in addition to a host of other things that are now only possible due to technological advancement, like streaming video. But in some environments it is possible to limit yourself to having the computer do just the simple things - it's just a matter of deliberately opting-in rather than doing the only thing that's possible to do. For example I'm trying to write a "Web 1.0" webpage in the style of early 2000's design like Praystation[1], ignoring the shiny new technologies that do a lot more, because I believe that "more" is not necessarily "better". I believe you have to be ideologically motivated to do this now, because it seems like a lot of average web users have come to expect SPA-style apps with fancy animations and client-side interactivity, and that's where a lot of interest in web design appears to lie at present. Of course, for a video-sharing app this doesn't really apply because the platform it runs on was proliferated fairly recently. The oldest model in the smartphone lineage came out at the start of 2007, and in order to build apps for it, it was necessary to install a full-blown developer toolchain with visual layouting tools and hundreds of APIs available for use. That's the simplest it can get. In the 1980's you could just 20 PRINT "HELLO WORLD". I think it would greatly help if the author published the source code, as he briefly mentions considering. At least then it would be possible to judge exactly how technically complex the software is, and people could learn from it also. However, at the point where you need to rely on complex cloud infrastructure like AWS to build things like video sharing applications, it might turn off anyone not completely interested/invested in app building. Although, I do believe a completely invested/motivated 16-year-old could pull off something similar, given the amount of documentation and free libraries on the web. That's not discounting the difficulty of actually accomplishing such a thing - for a young newcomer it would be necessary to learn many disjoint concepts for such a thing as video streaming. But given a significant amount of effort and motivation, it's at least possible to do in the present age. [1] https://joshuadavis.com/ps2-praystation-v4 https://joshuadavis.com/ps2-praystation-v4
TeMPOraL 7y ago
> What is the basis for thinking there are large barriers to most people becoming software makers? You have an idea for an app. How do you build it? Your options generally are: 1) Do it the hard way: get Xcode/Android Studio, spend years learning to a) program, b) deal with the bloated and overly complicated frameworks, c) deal with the bloated and overly complicated build and deployment infrastructure. Also pay the platform owner for the ability to make it work / distribute it to someone. 2) Do it the easy way: pay some service so that you can make the app in a simplified/low-code way. Now your app is tied to someone else's service. 3) Do it the expensive way: pay someone else a lot of money to do 1) or 2) for you. What's missing is the option 4): build it in some free, low-code tool, distribute it for free to whoever you want, without entering a relationship with any company whatsoever. That would be "the HyperCard for mobile". On top of that, these days you're likely to want to have capabilities that are available only either through option 1), or through an API, requiring entering another relationship with some other third party. Closest thing to 4) I've seen on Android is Tasker, with its ability to dump an .apk containing whatever UIs and if-this-then-that rulesets you created. But it's not exactly ergonomic, it's Android-only, and doesn't solve the distribution problem.
- scroot 7y ago
  Unfortunately there is an entire generation or two now of mainstream developers who never had the opportunity to experience things like Hypercard firsthand. It is always difficult to describe the full extent of the power of systems like it without being immersed in it, and we don't really have contemporary equivalents to make the case.
- dickjocke 7y ago
  I don't see why it would take years to learn to write an app in Swift or Kotlin (or React Native or Flutter), even starting from zero. I'm not trying to be cute here. There are probably 50 high quality end to end tutorial for building a video streaming app. I guess using Firebase is tying you in to a service, but so what? If it's for 4 friends it doesn't have to be infinitely scalable. Just by writing an iOS app you're tied to Apple, right? And surely an app isnt a failure just because it has dependencies?

vorpalhex 7y ago

12 years ago most folks had little webpages they cobbled together from snippets and ugly widget generators. It worked well enough. I've spent most of this week figuring out how best generate device specific thumbnails for my blog.

yaitsyaboi 7y ago
12 years ago the author of this post would have had a little website and now he has the ability to record and instantly share video with his family in a pretty delightful app :)
- ori_b 7y ago
  12 years ago, half the not-so-technical people I knew had little websites. Now, there's this one author.
- peanutz454 7y ago
  So are you saying the barrier remains the same? Earlier we had less access to stuff, and could write simpler software. Now we have more access, but software has become complex
  - nonbirithm 7y ago
    I think as computers have advanced in power the technology that runs on them increases in complexity to utilize the new power. With economies that prioritize growth, people in charge of things like web standards want new ways to innovate over their competitors. Developers don't want the power afforded by additional computing cycles to go to waste. They also find things lacking, like the difficulty of accomplishing "holy-grail" webpage layouts. Standards are expanded to accommodate these pain points, and new features are added, but nothing can be taken away as this would break things that already work. This continues to the point where the web implodes under a plethora of animated SVG hammers striking anvils and autoplaying videos. Thinking of it another way, computers of a long time ago could do only basic things like printing strings or drawing lines. Computers of today can still do those things, in addition to a host of other things that are now only possible due to technological advancement, like streaming video. But in some environments it is possible to limit yourself to having the computer do just the simple things - it's just a matter of deliberately opting-in rather than doing the only thing that's possible to do. For example I'm trying to write a "Web 1.0" webpage in the style of early 2000's design like Praystation[1], ignoring the shiny new technologies that do a lot more, because I believe that "more" is not necessarily "better". I believe you have to be ideologically motivated to do this now, because it seems like a lot of average web users have come to expect SPA-style apps with fancy animations and client-side interactivity, and that's where a lot of interest in web design appears to lie at present. Of course, for a video-sharing app this doesn't really apply because the platform it runs on was proliferated fairly recently. The oldest model in the smartphone lineage came out at the start of 2007, and in order to build apps for it, it was necessary to install a full-blown developer toolchain with visual layouting tools and hundreds of APIs available for use. That's the simplest it can get. In the 1980's you could just 20 PRINT "HELLO WORLD". I think it would greatly help if the author published the source code, as he briefly mentions considering. At least then it would be possible to judge exactly how technically complex the software is, and people could learn from it also. However, at the point where you need to rely on complex cloud infrastructure like AWS to build things like video sharing applications, it might turn off anyone not completely interested/invested in app building. Although, I do believe a completely invested/motivated 16-year-old could pull off something similar, given the amount of documentation and free libraries on the web. That's not discounting the difficulty of actually accomplishing such a thing - for a young newcomer it would be necessary to learn many disjoint concepts for such a thing as video streaming. But given a significant amount of effort and motivation, it's at least possible to do in the present age. [1] https://joshuadavis.com/ps2-praystation-v4 https://joshuadavis.com/ps2-praystation-v4

TeMPOraL 7y ago

> What is the basis for thinking there are large barriers to most people becoming software makers? You have an idea for an app. How do you build it? Your options generally are: 1) Do it the hard way: get Xcode/Android Studio, spend years learning to a) program, b) deal with the bloated and overly complicated frameworks, c) deal with the bloated and overly complicated build and deployment infrastructure. Also pay the platform owner for the ability to make it work / distribute it to someone. 2) Do it the easy way: pay some service so that you can make the app in a simplified/low-code way. Now your app is tied to someone else's service. 3) Do it the expensive way: pay someone else a lot of money to do 1) or 2) for you. What's missing is the option 4): build it in some free, low-code tool, distribute it for free to whoever you want, without entering a relationship with any company whatsoever. That would be "the HyperCard for mobile". On top of that, these days you're likely to want to have capabilities that are available only either through option 1), or through an API, requiring entering another relationship with some other third party. Closest thing to 4) I've seen on Android is Tasker, with its ability to dump an .apk containing whatever UIs and if-this-then-that rulesets you created. But it's not exactly ergonomic, it's Android-only, and doesn't solve the distribution problem.

scroot 7y ago
Unfortunately there is an entire generation or two now of mainstream developers who never had the opportunity to experience things like Hypercard firsthand. It is always difficult to describe the full extent of the power of systems like it without being immersed in it, and we don't really have contemporary equivalents to make the case.
dickjocke 7y ago
I don't see why it would take years to learn to write an app in Swift or Kotlin (or React Native or Flutter), even starting from zero. I'm not trying to be cute here. There are probably 50 high quality end to end tutorial for building a video streaming app. I guess using Firebase is tying you in to a service, but so what? If it's for 4 friends it doesn't have to be infinitely scalable. Just by writing an iOS app you're tied to Apple, right? And surely an app isnt a failure just because it has dependencies?