Slashdot Mirror
'The Problem With Programming and How To Fix It' (alarmingdevelopment.org)
Jonathan Edwards has been programming since 1969 (starting on a PDP-11/20). "Programming today," he writes, "is exactly what you'd expect to get by paying an isolated subculture of nerdy young men to entertain themselves for fifty years. You get a cross between Dungeons & Dragons and Rubik's Cube, elaborated a thousand-fold."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
Maybe I misread/misunderstood this article but I read this as, 'let's dumb down computer programming".
... to be competent when you are incompetent? Sounds like a question posed by a Marxist.
Although it would be nice if computers could program themselves, and in a way they are only starting to do so in limited ways due to careful techniques by knowledgeable individuals, it is still wishful thinking for it to happen in general.
Captcha: honing (these captchas are erily psychic)
Please. Google's talent is waaaayyyy over-hyped. And some of the shit I've seen them do is cringe worthy.
Arduino?
relative to many other tech things.
What you get when you let coders decide where to go is nothing. Ever. At least nothing that's ever done. Mostly because you get this and that and something else because all of those things are absolutely necessary, and then eternity to accomplish it all. If programmers were to make a toaster, it could toast anything from bread to waffles to muffins and even your sweater, because someone sometimes thought it might be helpful (but we don't remember who said that, but we also can't remove that sweater-module anymore without breaking the rest), it would measure its own temperature based on all the toasting done before to determine the perfect toasting temperature and time (both would be measured by three different sensors and devices), you'd have to give detailed feedback on your toasting and eating experience that would then be used to create a heuristic based on world wide averages... Well, that's the theory. Right now it's basically a stove top with a pan attached.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
>> 100k lines of doc, full stack means you need to know what you're doing, wah wah wah
Tldr: coding is hard and I'm a moron.
There are plenty of jobs in real estate at the moment - why don't you apply for one of those and leave those of us who make the world work alone.
I see that many professionals might be able to use basic programming skills to be more efficient and productive. But most programming tasks require basic logic, math, reading comprehension and critical thinking skills. The very skills many entities in our education system are failing in their attempts to teach. Not to mention the drift away from the 3 R's and the moves to gender and social focus points of our educational curriculum
;)
I wonder what percentage of individuals have the core foundation to even absorb how to write code.
Just my 2 cents
There are so many javascript web frameworks that let incredibly poor programmers produce useful tools. They may be horridly inefficient and buggy but they work. What Edward wants has already been the trend for decades. Excellent programmers building complex frameworks that abstract away all the hard bits allowing for rapid development of the relatively few business cases out there. Exactly how many companies do you think are doing anything novel or inventive with their web tech?
The trend is going to continue anyway. At some point we'll reach a level where there is a solid framework either produced by one company making bank or as an open source project that makes slapping together the common web site functionality so easy an MBA can do it. Companies will realize their dream of cutting out the unnecessary nerd that they have to pay too much. Alternatively, replace them with high school interns.
I don't get why the notion of "full stack developer" is such a big deal. I mean, do people go to build a home and say, "I want an 'all trades craftsman'."? Or do people go looking for a doctor and say, "I want an 'all specialties surgeon'."?
Of course not. Certainly there are people in every skilled profession who could be classified as generalists. They can probably handle most small things that are not very highly specialized and, if they are good at their profession, they know when something is outside of their skillset and can provide a link to a specialist that can handle it.
I am not saying that we should make technology and programming more difficult than they need to be. But, let's face it, there is a tremendous amount of knowledge, skill, and experience one must acquire in order to be a good programmer. It is very difficult to acquire all of that for what would qualify as "full stack."
I think it was Stroustrup (or maybe Dijkstra), speaking on the idea of making programming "easier" so more people could be programmers with far less training and education, who said something to the effect of "I wouldn't want a surgeon operating on me who only had 6 weeks of training."
The article proposes no solution. The author simply whines about programming being hard. He suggests there's "simple small-scale problems" which don't need "rock stars" to solve. No examples of these problems or what programming might be like if it were fixed.
...python or Arduino. Basic still exists, by the way but has been supplanted by python. Or there's scratch, or Excel, or Lego mind storms. We managed to learn programming back before having access to the Internet, when I had to ask for a book on x86 assembly language for my birthday.
Programmers and Program Designers still do not understand the objectives or how the âoereal worldâ works. Meaning that they donâ(TM)t get the problem and donâ(TM)t have any idea what a proper solution might look like. Which explains handily the opening assertion.
There is only one direction in complexity and that is toward more complexity. There is an arrow and it only points in one direction. Eventually there will be a complexity collapse and things will start over.
E Proelio Veritas.
This is because we (or weak technical managers) let programmers change their language/framework/paradigm based on boredom. Bored with PHP/Python? Use NodeJS! Bored with your site being complete and only needing minor fixes? Make it a Single Page App and now you have to struggle with webpack and babel and angular/react. “Sorry boss, I gotta rewrite the app to use typescript, trust me it needs to be done, it’s the way the industry is going!
I say this as someone who got stuck in web dev and has to go along with my coworkers as they chase te latest trend.
If I were more cynical I’d have said “job security” instead of “boredom”.
He states the problem. He says it should be better. He doesn't go into "how".
The fix should be to have software write the code. Input the behavior you want in any programming language — maybe a new one, but old ones to start with.
Then the software translates it into whatever other language, replaces the easy to understand loops and such with efficient implementations that provide the same result and are provably secure, identifies sequence points, breaks it all up into parrallelizable nuggets, and sends the whole thing to a scheduler that runs it on a set of CPUs.
... people don't want to learn. No doubt tools can always be better but knowing how to improve them is a non trivial undertaking. They want easier to use tools but those "easy to use tools" take decades of research and development to make. If good tools were so easy to make they would already exist.
Computers programs are only as good as the coneptual and modelling approach you use. Consider many 2D videogames who render spries as largely square/rectangle block, if you want two sprites to do something complex like melt into one another, that would require 1) faking it or 2) coming up with an entirely new way to model and animate sprites that broke them down into individual pixels/atomic components.
The problem with computers for normal people, is that computers force you to specify and make clear your thoughts and most peoples thoughts are hopelessly vague. That's why people are frustrated they simply do not know nor understand the complexity of the work they are asking when the want some problem "they think is easy" to be be rigorously quantified before you can code up a solution in a program.
He seems a lot smarter than I am and so I do not want to dismiss what he is saying... but I cannot possibly see how programming is harder than it used to be.
It seems like he is looking at the languages and tool chains used in the enterprise, and complaining that they are not suitable to get Joe Sixpack programming, while ignoring all the incredibly easy ways for somebody to make something useful at home. And, I'm sorry to say it, but the most obvious counter-example to what he is saying is... Python.
The Daddy casts sleep on the Baby. The Baby resists!
The problem is that computers are still not idealized Turing machines. Execution times are not zero and memory is not infinite. Knowing how to break a problem in proper structure is what requires years of knowledge, not large manuals of libraries, but rather the knowledge of how to map the problem to the available libraries or do you need to create something new. To manage queries on the US population do you need a list, an ordered list, a tree, a hash table, a distributed hash table or something else? Which of those is going to able to sustain 1000's of queries a second?
It's not the 80s anymore. Useful systems are complex, have many layers, and tend to grow new layers over time.
In the 90s, a web page was a static .html file. Some minimum understanding was enough to make one.
Later, CGIs were added. Now you need some understanding of HTTP.
Add a database. Now you need to understand SQL, and related matters, like SQL injection.
Add JavaScript. A whole new language to deal with.
Add dynamic content. Suddenly, the page isn't a static thing, there's a DOM that's being modified in real time.
Add a growing internet, with many users of your page. Now you need to know how to make a scalable system, and how to design a proper database.
Add cloud computing, where the underlying infrastructure itself can be scaled in real time, and where you can get extra database servers if you need them for a couple hours.
Add internationalization, and now the programmer has to be aware of Unicode, different date formats and so on.
With each added feature and with each added layer the complexity grows. And you can't just throw your hands up and say "fuck this, let's do it like we did in the 90s", because all those things were added for a reason. Without Unicode, you have problems with your international clients. Without dynamic content your page is clunky and slow compared to the competition. Without planning for scalability, your infrastructure falls down right when your business is on the front page of Reddit.
I get the nostalgia for the good old and simple times, but that never lasts. As soon as a new tech emerges, people build on top of it, and then on top of that, and so on, and things escalate until it's hard for a single person to deal with all of it anymore.
Anyone can program.
Hell when I started I could crank code like it was nothing. But guess what. That code was total crap. I mean it was *very* *very* *very* badly written.
Once I learned a good amount of CS I became much better. I did not make terrible memory mistakes. Big 'oh' is a thing and it matters at all levels memory, cycles, instructions, time, etc. It maters it takes a decent math foundation to understand it.
Once I got the CS degree I still was fairly 'mediocre' at it. At least my code was not terrible. It was not exactly great either. That has take years of practice and time. Tooling around it has helped pick off the silly 'typo' mistakes. But not all. Also more practice. This is an art. We are craftsman. We can use science and math to build our art. But art it is. Once you realize that you can figure out how to make CS great again.
One of the biggest lessons is. Do not worry about 'stacks'. HR worries about them because the managers think they need to worry about them. What you want is well rounded individuals who can grok the idea of how the stack you are using works and is not an ass to work with.
We have ended up with giant sweeping stacks that no one person can understand because of 'crunch'. Everyone in the industry wears it like a badge 'I work X hours per week'. That sort of work ethic create crap. You are not stopping and using the the thing holding your ears apart on how people will use your 'latest greatest API which is trending #1 on stackoverflow'.
Leaky abstractions are dead easy to make. Ones that 'just work'. Those are hard to make. I am currently in the process of picking up spring. What an un-holy mess of a stack. Oh you can do great things fairly quickly. But the one thing everyone bitches about is 'how do I debug this bitch with its 200 line stack traces'. That is one of the 'popular' ones! So everyone is floundering around trying different stacks and transpilers to spackle over the defects of a poor language choice in our browsers. We are also winding up to create the worlds largest lockin of code ever with webassembly. Then deriding our languages for the 'bad' things that are going on (hell I just did it). So we invent 3 more that do pretty much the same mistakes eventually.
So yeah CS/Programming is hard. Because we are too busy trying to be the next vendor lockin and putting in way too many hours on stacks that just do not help get shit done. But hey at least I am trending and have a banging blog and youtube video series that no one gives a crap about!
I am sure all the snarky comments to come will prove his assertion about the programming subculture. After 30 years of programming professionally, I can barely stand it myself...
I have the same problem with Electrical Engineering: why do you need to know stuff in order to do EE? They should make the tools simpler so everyone can participate. You know, have like blocks that fit together so you can build a robot or a rearrange to build a mobile phone, etc.
Everyone must be a surgeon.
Not those rare few uppity elites who can afford the education.
It's discrimination I say!
We need to change how the human body operates to make it easier for more people to work on.
You might as well suggest that people could master painting or mechanical engineering or something without putting in a time investment.
I'm all for getting more people to code. I'm all for an introductory language for new coders.
But when it comes to the big league heavy lifting coding, it is going to be complicated because it is complicated.
It isn't complicated because some "nerds" made it complicated. It was complicated before anyone coded at all. It is inherently complicated.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
The problem with saying "we need to make ???? easier so that everybody can use it" is that you need highly technical people to make ???? easier for everybody else. I see Javascript as being an example of this mindset. It was created to make it possible for basic programmers to create intelligent web pages - for teaching basic programming and implementing simple functions (like convert inches to centimetres) it's pretty good. But, choices made to keep things simple resulted in the language becoming incredibly complex to implement more than simple functions.
Mimetics Inc. Twitter
> There are so many javascript web frameworks that let incredibly poor programmers produce useful tools. They may be horridly inefficient and buggy but they work.
Yes, they seem to pretty much work, when they receive the expected inputs. Since the person who wrote it doesn't know what they're doing, inputs they didn't anticipate result in yet another $20 million breach.
There is a place for something like Hypercard, macros, etc - on your own desktop, to make your job easier. Programming that's going to be exposed to hundreds or thousands of attacks per day, programming on the web, needs to be done right.
"Done right" doesn't just mean "a professional", an English major given the title "Programmer". It means someone who actually knows what they are doing.
I was pretty much done with this article when he said,
"I don't blame the kids." So where were you when the shit went down? Farting around in your ivory tower?
And then he said,
"most people are stupid compared to computer science professors."
and I was completely done with this piece of pissant shit.
AC
Reading the article, I feel like the solution is adding meaningful instruction in programming at grade school and continuing it through a person's education. From here, programming platforms for the masses will become obvious and well supported.
Sometimes when the common denominator is too low, you have to change it rather than cater to it.
Mimetics Inc. Twitter
"Dungeons & Dragons requires mastery of an encyclopedia of minutiae"
No, it really doesn't. It requires the ability to tell stories.
Something in the style Hypercard or OS macfos, or Excel macros can be very helpful to partially automate your job. Rather than clicking the same thing over and over, you can script your task. That doesn't always require a lot of expertise.
Contrast that with code exposed on the internet, which potentially connects to your company's critical databases. Being on the web, that code will be attacked hundreds or thousands of times per day. Sometimes, attacked by very skilled attackers. These are two VERY different situations.
On your desktop, sure go ahead and script autoreplies to common emails. For code on web, being attacked thousands and thousands of times, which can result in multi-million dollar losses, that's best done by someone who really knows what they are doing.
That does NOT mean a "professional programmer" who was hired as a programmer because he "knows a lot about computers". That means someone who has actually studied how to architect and author secure systems to be robust while under attack, and continues to study. Twenty years into my career, I still study several hours per week, because the black hat hackers keep learning new ways to attack us.
He mentions VB as an example of an easier language. WTF?
It was a steaming pile of confusing layers of incomprehensible and inconsistent cruft
Just about everything was a special case that had to be learned and remembered
Is it an object? or just a function left over from the old days?
It it a method? or an attribute?
I'm so happy to be done with it
The reason it is impossible to learn everything to be a "full stack developer" is that there are so many tools and libraries out there freely available which make development go so much faster. Microsoft even wrote a Javascript library to write Autocad files, for god's sake.
There's no reason to be a full-stack developer because that's so much less efficient. There is literally no scenario where it makes sense to build everything unless you're building a vanity site for yourself and want to do it just for the sake of doing it.
Find a profitable niche and stick with it.
And for teaching kids you can just teach them Python. There are tons of ways to make it fun and interesting and the language itself is not as brittle as say C.
Users demand more sophistication than the 80x40 character-based applications I first wrote starting out. Back then, I could churn out a working departmental application inside of a week, including data tables, using a 4GL.
Who wants to go back to those days? Now we have internet instead of LANs, GUI, events, threads, all sorts of data stores, and layers of abstraction to manage it all. I don't see it getting any simpler.
If you post it, they will read.
They=> The
ugh. can't edit in /.
If you post it, they will read.
If you want to do something simple in software, well it is pretty easy in some scripting language. But as soon as say want to catch issues, like network problem, overflow, input sanitizing, authenticating, etc, it gets complicated. Network alone can exponentially increase the difficulty because well, so many things can go wrong. And you can't just lump it into "network problem" if you want to be smart about it and try to do something intelligent based on the type of problem.
Having gone from ANSI C to Java and C# and Python and today's languages, I spend more time figuring out the libraries than actually solving problems.
There are times when I'm doing UI stuff, I wonder if would be easier just to roll my own than have to deal with writing a whole class to inherit a bunch of shit or end up with:
object.object.object.object.method(object.object.object.method(object.object(class(object(class))))).method().variable = obj.class.method.......
just to have some stupid little thing in a window that used to be just an entry in a resource file back in 1994.
Yeah yeah yeah, I programmed in the snow, uphill, both ways.
is a simple programming language with extensible builtin data structure. Add to that an IDE for writing code, debugging and version control.
I created a Forth-derived language, embedded in C (link below) to tap into some of that old school simplicity without loosing contact with the bigger picture. Even Python is too complicated for my taste when it comes to whipping out simple tools, and not integrated deep enough with C to use as an embedded scripting language. Suggest JS at your own peril. https://github.com/basic-gongf... https://github.com/basic-gongf...
What are the constraints on the imagination in a computing system?
A Civil Architect has to worry about physical constraints; weight, load capacity, material cost.
A Social Architect, social constraints; psychology, sociology, and so forth.
And a Software Architect? Pure comprehension is the problem.
And in order to really understand the system at hand, you have to practice believing in whatever you want to believe in; trying one theory after the next; and run it until it prooves itself out, and then continue on. However there are a lot of ways to accomplish something, and not all of them are "right" by another person's standard.
And because of that, computers, and what they represent to people hiring programmers, can represent a trap of believing in whatever you want to believe in.
Those get really annoying over using standards. Especially in Java where you can potentially have TONS of frameworks. Also Groovy? You can compile with it pure Java so just write the Java and skip the middle man. I swear sometimes people make things to complicated or dumb things down to much.
Yes, sure. The whole thing where a guy thinks you can simplify complicated things by using what you think is a "simple" tool. Because the task all of a sudden will become simple as well, right? I guess we should all start learning Scratch.
There, fixed that for you.
Bingo!
And that complexity makes it nigh upon impossible for any one person to understand everything about how their site works. (Well, I guess, unless you're a rock star.) Even then, though, you see job ads with a laundry list of "must haves", "should haves", etc. as though any one person could have an in-depth understanding of how all those technologies work---and their potential security problems if used improperly. I am still seeing emails from recruiters for what's described as an "entry-level" position that lists more requirements than I can view on my big monitor without scrolling with many of the requirements also wanting several year's worth of experience. (I can only assume that the reason these are still being sent out by recruiters is that a hiring manager hasn't quite figured out the oxymoron that is "entry-level software engineer with years of experience".) And don't think that concentrating on a major vendor's web application environment will make fully understanding how it all works together not a daunting task when the environment is made up of software tools developed by small vendors that the company bought up and cobbled together with little-to-no effort made to have them conform to a consistent look-n-feel. And that's just the crazy quilt knowledge base you need to absorb just to support the resulting web site(s). I can't imagine having to develop in such an environment without wanting to run screaming for the door.
CUR ALLOC 20195.....5804M
lol, "#CSForAll movement" ... this MS shilling... was SlashDot acquired by Microsoft like GitHub?
The line between using a computer and programming one used to be thinner. HyperCard and spreadsheets are great examples of how people brought programming to the masses. (Visual Basic, I'm not so sure of.) Shells of all kinds and other environments like MATLAB did some of the same things. Macro languages in programs like WordPerfect likewise empowered the user and lowered the barrier to entry.
My favorite example is RPL on HP 28/48 calculators. It took a little doing to learn how to use a postfix calculator, but once you did, all you had to do was enclose the keystrokes you'd normally use inside a <<>> and BOOM, you're programming. Then users, having already stepped over the low barrier to entry, could gradually learn additional constructs as needed instead of needing a full 'intro to programming' class before they could do anything useful.
Thing is, none of the good examples that come to mind date from 1990 or later. Our ideas about how users interact with computers have for roughly thirty years been too stagnant or too simplifying and un-empowering.
I have to disagree. The necessary CRUD, GUI, and relational idioms to do the job of typical business applications are mostly the same as the 80's. The web and silly fads came in and mucked it up, turning bicycle science into rocket science by pounding a square peg into a round hole.
Nobody seems interested in exploring and developing new standards to make CRUD and productivity applications easier again. The arcane fidgety nature of the state of the art is too much job security: simplification may trigger an IT bust.
For example, the Oracle Forms developers at our shop can crank out applications at about 1/7 the pace of the "web" oriented developers. The result is not aesthetic, but they work and get the job done. (Oracle is a jerk in other ways, but Forms just works.)
But our shop has to migrate away from Oracle Forms because Oracle stopped making a Forms client and converted it to Java. Java doesn't get along with our security infrastructure. Flash and Java made the same mistake of making their client into do-all behemoth, which resulted in security holes. If they or the industry had focused on making just a "GUI browser" (hopefully with an open standard), we could toss HTML browsers for productivity applications. HTML browsers are better for e-brochures, and not eCRUD.
So, if you want to fix it, learn from past products that work, and produce a stateful "GUI Browser" standard. Let's go back to coordinate based clients instead of client-size auto-flow placement. The server side can resize for the client size as needed. That way we have one placement engine instead of the 50+ placement engines we have now (browser brands & versions). Client-side layout sucks big productivity donkey dicks. (This is not the same as proposing only WYSIWYG as some critics have claimed, because the server can still do auto-flow if desired.)
Put on the client just enough to get the client job done, shifting the rest to the server, but otherwise learn from the failure Java applets and Flash and don't make the client into a do-everything monstrosity. (Resisting Emacs jokes.)
Table-ized A.I.
Every time someone does that, their "simple" tools end up being used for problems far more large and complex than they were designed for, and we get a godawful mess. Think shell programming, Perl, PHP, Excel, etc. (Spreasheets have been used to produce the most opaque, incomprehensible modeling code I've ever encountered.) It's the Peter Principle for programming languages and tools.
The NCIS school of programming.
Programming used to be easy before because:
1. You didn't care about the security at all.
- HTTP is much more easy to setup and test than HTTPS, especially when you need to consider security certificates
- HTTPS is slower, especially on connection time, which requires you to design the whole system differently than you would with HTTP.
- You need to setup a way how to change certificates etc. as they usually age within few years.
> It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems,"
FoxPro on DOS fits that.
People have been saying "programming should be easier" forever.
Many have tried, all have failed.
And the task keeps getting bigger because the uses and requirements keep expanding. From one simple input (keyboard) from one source (user) to a variable domain of many complex inputs from many sources. From one simple output (answer) to a variable domain of many complex outputs to many destinations. And the core tasks, too, aside from input and output, are far more complex than they were.
If you have one hex nut to loosen and tighten, you can make a simple wrench to do it. If you have to be able to work on an infinite number fasteners—hex nuts, machine screws, torx screws, allen bolts, grommets, flip latches, tumbler locks, screw-down locks, snap fittings, adhesive strips, magnetic plates, snap rings, cotter pins, etc. and the domain of tasks goes from loosen and tighten to loosen, tighten, open, close, diverge, converge, adjust left, adjust right, increase weight, decrease weight, etc. and the number of possible surfaces increases from two adjoined flat surfaces to be bolted together to N surfaces of M possible shapes... Well, you're going to end up with a shed full of tools, each one of them reliant on a different kind of knowledge and experience.
Life is complicated. Programming is approaching use in virtually every domain of life. Ergo, programming will be complicated.
You want programming to be simple, you may as well start off by trying to make life simple—that's the root of the problem.
STOP . AMERICA . NOW
...without considering that the problem space is inherently hard.
That's what all plattforms are.
To emphasise: Today we do applications in a webbrowser and the avantgarde is done in a scripting language of which - if you had said it would rule the world 20 years ago - people would've stuck you in the l00ny-bin.
The biggest remaining problem today is that visual stuff (builders, modellers, DMIs etc.) is still 10 years behind what used to be the epitome of DMIs (direct manipulation interface ... look it up) called Flash. That was a prorpietary technology and had a shitty herald (Adobe) but it was cross-plattform and any idiot could wip up a feasible piece of software that was good looking and ran everywhere within a few hours.
Full-stack - and I presume we're talking about the web because, ... what else is "full-stack"? - looks the way it does because it's FOSS tech bolted on to FOSS tech each of which became popular for totally different reasons. I expect us to weed the problems out within the next decade or so and then programming will have universally become some neat DMI / BPM / Modelling thingie with code attached whenever needed and whenever an expert is needed. Today, we pay little more than a maintenance allowance for tools that used to cost as much as a luxury car (or an entire luxury carpark), if we pay at all.
Plattforms will become a fashion choice, nothing more. See Apple for how this is done well. And programming will be easyer than ever with most work done by bots anyway. Just look and see what is happening in the middleware and ERP space right now - high profile toolkits and the high-profile specialised jobs that come with it are dropping left, right and center and we flexible FOSS tookit and web proggers are going to have the bots on our heels aswell. Sooner than most would like to believe.
My 2 Eurocents.
We suffer more in our imagination than in reality. - Seneca
We can start by redefining pi to a couple decimal places.
Users have to be whipped? "It's in black and white", "there's no mouse", "I don't want to crawl under the table to plug the USB stick in", "my i5 laptop is old and fucking slow!" (it's 2x faster than my desktop, but you don't know how to watch RAM usage and your 4GB are 150% full). All a bunch of whiners!
But not simpler...
Some guy said and it's applicable gere
I think the thing that this person may be missing about the 'internet age' is that people don't read all the documentation and understand every aspect before sitting down and starting a project. I think people are generally going to do a quick start or some tutorials and Google on anything else they need, or reference it then.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Far too much civil engineering depends on crusty old math books and has historically been the province of white male nerds. We need to democratize civil engineering, teach bridge and road construction beginning at an elementary level, and ensure that people at all levels of society can participate in designing sewer systems.
There have been several attempts to simplify computer programming: BASIC, Visual Basic, LISP, FORTRAN, PASCAL, COBOL, 4 GLs, etc. all more or less fall in that category and they were all effective to some extent, but none proved superior.
Computer programming is one of the easiest things to learn, but is not a pariicularly useful skill, so we would not want everybody to learn it. There are currently about a hundred more active programmers (professional, programming on the side, hobby programmers, etc) than the world has use for. But the same thing goes for the number of poets, playwrights, novelists and musicians.
The result is that we have millions of programs that have (or come without a guarantee they don't have) bugs (logical errors) or exploits (a subtler class of logical errors). The conclusion must be that the computer industry off today is unable to design good quality software or hardware. Computers will not be ready for use in real life applications for years to come. We look to academic computer science to invent ways to design and verify software and hardware and to teach this knowledge to practicioners. It may help to introduce laws that create mandatory quality standards.
I don't think your solution of hiring just "a professional" works.
There are new exploits discovered all the time.
Even if a person actually knows what they're doing, with all the credentials and experience to "do it the right way", they still can get blindsided.
And by blindsided is a slow-burn attack leaking data out for years before discovery.
And all this expert professional would do is say: it's not me! it was X, Y, or Z.
If a solution takes a Business Analyst, an Architect, Security Expert, DBAs and Testers to deliver, why would you expect the actual coding to be simple?
> don't think your solution of hiring just "a professional" works.
I specifically said hiring just a "professional", someone hired as a programmer, is not sufficient. In my other post I mentioned that I still study several hours per week, because new vulnerabilities and attacks arise every week.
I also insisted on establishing code review / peer review at my job, where other people trained in security review all of my code before it's deployed. We have weekly sessions where someone on the team presents something related to security for the all of us to learn - continuing education every week. Those things are part of actual professionalism. Now, I'm learning more about how one of the best companies does security with software designed for top secret software. I'll apply what I learn, where appropriate. Lockheed Martin seems to take security very seriously, and do a pretty good job. If anyone reading this has worked for Lockheed, I'd enjoy talking to you.
I take it he has not done any actual programming/software design... Or he has never played D&D or seen a Rubrics cube.
They do: VB, Delphi/Lazarus, PowerBuilder, Oracle Forms, Paradox, Clarion, and a few others.
The problem was deployment, and NOT programming productivity. Nobody ever said, "Our GUI/CRUD tools make programming too tedious, let's go Web!" Deployment issues are what "sold" the web: reduction of client-side installs and updates. But, we should revisit the assumptions behind all this.
As I mentioned elsewhere, Oracle Forms used to have a thin client that was relatively easy to install and distribute, but they mucked that up when they converted it to Java: a really fat client.
The mantra of the Web was that in order to get easy or no deployment you had to live with a more complicated and layered development environment. You either hired 25 more deployment specialists (desktop support) or 10 more programmers, and the second looked cheaper to most bosses and owners. (It's why we've had a dev boom/bubble.)
Implied is a fundamental trade-off between simple development and simple deployment. The theory is that one MUST make this trade-off; that it's hard-wired into the Universe.
But I'm not convinced it's a Law of Nature. Nobody's produced something akin to Amdahl's Law for an inherent dev-vs-deployment tradeoff.
Pre-Java Oracle Forms seemed to just about get it right (with some fixable qualms). I believe if the client's and server's responsibilities are partitioned well to avoid a bloated client standard, we can have the best of both, or at least a better mix than the current web mess. A work-world-oriented "GUI browser" standard.
Table-ized A.I.
I was part of the generation of kids who latched on to the early 8 bit personal computers and learned to program in BASIC because, well ... that's what the manuals told you how to use them. As things got more advanced, I started a hobby of running my own computer BBS, and initially used software I wrote myself in BASIC. (By then, I was already hitting limitations of what the language would let me do, because BASIC had no way to collect input or produce output to and from my modem. I had to use a lower level assembly code driver program to handle the I/O. A friend of mine, who knew some assembly programming, helped code that and maintain it for me with updates for a while.)
By the time I'd done that for a few years, the Borland "Turbo" products for coding in PASCAL or C were becoming really popular, and friends of mine were modifying existing code-bases for PC compatible BBS packages using those languages. I was too invested in what I'd put together in BASIC to care about that, at the time.
When I finally went all-in on a PC clone (vs. my Tandy Color Computer 3) - I was sidetracked by other things in life, including learning to play guitar and playing for a while in a small, local band that some friends had put together, and taking college classes. When I re-visited software development for Windows, people were WAY ahead of me, using the visual development languages and object-oriented programming, which was a foreign thing to me.
I went on to a career in I.T., which I do to this day, but beyond your basic batch scripting, I really don't ever attempt to code anything. Truth is? There's SO much out there already, I struggle to imagine scenarios where I'd ever want to write something that hasn't already been done! It's a full-time job mastering several of the existing Enterprise-class products on the market that a given employer might expect me to be proficient in.
I think I understand what Jonathan Edwards is saying, because it's exactly what I experienced that drove me away from programming. But I'm not sure it's a "problem" anymore? The days of things like HyperCard are past us because the types of applications one would typically create with them are already readily available, and in the form of code that runs natively on the system without "helper" software interpreting it first. Even in my early days of using BASIC, I hit hard limitations on what it could do that forced me to use outside assistance (that assembly code device driver for modem I/O).
The expectations for the level of what applications, games or utilities do is high enough, today, that I think you need specialists, well versed in complex programming languages, to pull them off. There are times I really do missing coding in BASIC. To this day, I remember the commands and most of the syntax. But even with the "last gasp" of attempts to modernize traditional BASIC with those BASIC compilers they had for MS-DOS for a while? The language just couldn't DO enough to keep up with people's expectations.
This argument works just as well for other professions; allow me to demonstrate.
People have been building airplanes for roughly twice as long as their have been computers, but yet we are still paying hundreds of millions of dollars for top-end fighter jets. Why is that? Why have we not yet advanced to the point where building fighter jets is commoditized, and can be done with minimum wage workers with high school educations? Why do we still have to pay exorbitant salaries for so-called "experts", in this nerd-driven culture of exclusivity? #RocketScienceForAll
See, the answer is pretty simple, when you are enough of a "rock star nerd" to apply some simple logic. Making complex computer programs is "hard", and thus requires people with "intelligence" and "experience". It's the same in pretty much every specialized profession; programming is sorta the outlier because for some reason (media, outreach, or otherwise), people seem to have the misguided notion that if we were better at dumbing it down, we could make it accessible to everyone. The reality, though, is that for the same reasons that we don't have many high school only educated doctors, or lawyers, or physicists, or rocket scientists, etc., we also don't have (and it's not really possible to have) a plethora of minimally educated/experienced good software developers.
TL;DR: Don't be an idiot, good science/engineering is hard, and that's why "normal" people cannot magically be good engineers. Try to remember that good engineering is hard, even if ignorant people say programming should be easy.
It's why JavaScript, PHP, VB.NET, etc exist and are popular. The learning curve isn't so too steep and just about anyone can write small programs in them. If you want to make a large and complex program, well that's a tough job. I guess we should be sorry that we haven't made it easy to do hard things?
Car analogy: It's not too hard for an amateur to make a small steam engine or small electric motor. It's significantly more complex to make a fully working and safe car, that includes engine, brakes, rolling chassis, etc.
“Common sense is not so common.” — Voltaire
Yes, some tasks only require a quick solution without a lot of engineering; but complex systems that run frequently need skilled programmers to design and build them.
Back in the day, software had to be as small and efficient as possible because CPUs were slow, memory was limited, and storage took forever. Programmers would sometimes take days to squeeze out a few percentage points of efficiency in a single function. Today, all kinds of horrendous software can run fairly quickly if you put it on a fast enough machine. The cloud can make things even worse. An atrocious algorithm against a large data set can still get done in a less than a minute when it runs on a 1000 server cluster. The fact that it could have run even quicker on a 10 server cluster if the algorithms were changed, is rarely explored...after all it works, right?
I am building a new, general-purpose data management system. One of the best things for its development, was my insistence on testing it on a 10 year old Core 2 duo processor (Q8300) with only 4 GB of RAM and no SSD. It forced me to really optimize a bunch of things so that it was running fast on the old box and is thus lightning fast on the latest hardware. It is an object store that can do file system, database, and NoSQL operations within a single system. The database queries it runs have so far been about twice as fast as PostgreSQL in my benchmarks. It can store 100 million files and find them thousands of times faster than file systems like NTFS or Ext3. I am currently working on ingesting data exported from MongoDB (Json) to see how much faster I can make that run too.
Put numbers on each face of the cube. You can quickly manipulate the cube on your turn, then roll it like a die. add up all the numbers on a face and that is your result.
“Common sense is not so common.” — Voltaire
The problem with programming is that there's too many people doing it who haven't studied computer science. That is why there are so many things being created with tons of bugs and security holes.
See subject: Delphi = awesome & can build STATICALLY compiled VCL single .exe programs. I used it for APK Hosts File Engine 9.0++ SR-1 32/64-bit for Windows https://www.google.com/search?... that even registered /.ers like & use (small sampling w/ dozens more like it in reviews by /. peers) https://linux.slashdot.org/com...
THEY DID PUSH IN THAT DIRECTION FOR LINUX!
* TRY FreePascal 3.04 + Lazarus 1.8.2 IDE for it (EXACT duplicate of Delphi @ syntactic level + IDE)!
I used it to PORT the program above to Linux APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p
APK
P.S.=> Delphi BEAT C++ & VB in 4/6 tests in Visual Basic Programmer's Journal 1997 oct issue "Inside the VB5 Compiler" & tied 1 w/ C++ & lost only 1 (so did C++) to VB (ActiveX formload) ESPECIALLY in MATH & STRINGS by 2-4x FASTER... apk
The problem with programming is programmers.
Look at the use cases for computers in the 60s. 90% of that can be done by installing a package.
Or the 70s, or the 80s, or the 90s.
A million accountants worldwide program: They program a computer to read in data, manipulate it, transform it and output it again. They happen to use Excel to do this.
A million Android users automate their daily schedule. They use ITTT, or the new Samsung thing that got installed on my phone yesterday, or some other programmable automation tool.
Thousands of call centres are automated by people that barely know how to use a computer. They use Blue Prism or Automation Anywhere or an equivalent.
Full stack developers don't do this shit. They don't need to. They deal with more complex systems, that do more complex things, and write the tools that others use to do the easy shit.
Oddly enough it's hard. Robust, secure, scalable, performant code is easy, if you don't need it to do anything. When you're asked to make it do everything, and what 'everything' encompasses changes on a daily basis, and you're given a deadline that's too soon.. yeah, it's hard. So be professional, learn how to do it (including managing the requirements, the deadlines, the budgets and the ways to optimise the fuck out of the lot of them) and stop bitching.
But what the business needs hasn't really changed much for those types of apps. It's still a matter of maintaining master data and entering transaction data. Today's ERP apps generally look the same as 80x40 but inside a GUI window instead, and the reason is because the actual app requirements are the same: enter character based master and transactional data. There are some examples where graphics adds real value, like displaying images of items, or grids of detail with cut and paste, but most of the apps haven't changed much.
"layers of abstraction to manage it all"
That's the biggest problem in programming today, IMO. Our current systems have so many layers of abstraction piled on top of each other, that no one really knows what the fuck the computer is doing. Not only do programmers not know exactly what a particular abstraction is really doing inside it's black box, but they don't know how many abstractions are inside that abstraction.
Any proposal to make programming easier, is really asking for even more layers of abstraction. Piling more layers of crap on top of the existing crap just makes a bigger pile of crap.
Anytime I want to write a quick program for my linux system, I have to decide on which gui framework to use. And they all have big issues. 95% of my time is dealing with the issues - which change with each update and 5% is actually writing code to solve my problem du jour. I've resolved to writing things in the terminal with ncurses now (least common denominator. Screw all the gui idiosyncrasies and especially bugs.
Hypercard was THE answer. We could do something quick and dirty working just with graphic interface, or use Hypertalk if we needed something more sophisticated, or write an XCMD or XFNC in C or assem. if we needed more in capability or speed. Never having to deal with the Mac's graphic subsytem. It could have morphed into being the finder and the core interface for the Mac ala smalltalk. But Jobs was never a programmer's visionary. I would buy a Mac today, IF it came with a modern Hypercard. But it would probably be bogged down with so much baggage that it would be unrecognizable.
Software is a force multiplier - it doesn't inherently do anything, it allows people to multiply whatever they do.
It's good that software isn't a super-simple thing to do, because we don't need to multiply the level of retardation in the world.
If software becomes easy enough for everyone to write then everyone will write software, meaning every fucktard on the planet has equal influence over the world to the non-fucktards
The fucktards are more numerous so this would basically be an extinction level event.
Def: A developer who think he knows everything. He use expressions like "web scalable", "big data", "micro-services", "cloud enabled", ... in every sentences he say. He prefer using hundreds/thousands of "cloud instances" to run his new ''à la mode" social network site instead of optimizing his code. He runs everything on a NoSQL database even if it's not required because relational databases is an old technology from the last century. He is probably working on a Macbook Pro drinking a big overpriced Starbucks coffee because he's so cool... he's a Full Stack developer!
Will $CURRENT_YEAR be the year of the Linux Desktop?
Programming is easy. Many people can pick up programming, put them on a computer with logo and have them move the turtle. Et voila many people will pick up quickly how to move the turtle. And bam you are a programmer. But see the difference between a programmer and a developper is that there are certain more complex you have to understand to make something, e.g. security, how memory function for your framework, GUI concept, HMI concept, what is the difference beetween n.log n and n^2 , and is it relevant to your application, scalling, maintainability, normalisation and when to use it and so forth. The difference between programmer is the same as knowing how to apply cpr , and how to be a heart surgeon. Everybody can do the one, but it need training and understanding to do the second. I have 30 years of developpment training and often i think I feel I am still at the programmer level, butchering stuff rather than do good development. But at least those 30 years gave me to see that not everybody can do development and a lot of folk don't understand those important concept. I have had many *programmer* not understand the concept of maintainability and shit code which long run make us lose hard cash. Or use normalization haphazardly.
Making programming easier does not help one understand the more complicated concept, and thus it will not enhance the quality of our software. Just like not everybody has it to be pilot or heart surgeon, sorry, but many of us are not really developper, we are code butcher.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
you want a fail safe and simple solution that solves complex problems. I wish I thought of that, I'd make billions I tell you.
The thing is, programming IS easy, relatively speaking. It's easier to learn than say, learning to speak a foreign language fluently as an adult, or playing the violin. Merely learning how to program (rather than write good software) is entirely possible for an average person in 3 months.
What's hard is defining in advance what a computer should do in a near infinite amount of different situations... baring in mind, that a computer must now be doing multiple things at the same time and it must not become confused by this.
Another hard thing is finding out why a computer did something that you didn't expect, given you have no great way of finding out what it was actually doing at the time.
Software is now used to run most of the world's processes and it stands to reason that designing this software is at least as hard or harder than designing the human processes that they replaced. Humans may stop, reevaluate the situation, read between the lines and exercise their own judgement, computers can not.
So this is is why attempts to "dumb down computer programming" always fail. Computer programming was never the problem, designing software was always the problem. If you are truly capable of automating the world's work, then programming will be a piece of cake for you.
What about non-technical people? Well, you have to decide how you define "technical" first. Is being "technical" a matter of identity, wearing "geek" t-shirts, being the first person with a new toy, visiting Slashdot etc? Or is it a matter of being detail oriented, being able to zoom in on the individual steps of a grand plan to know what can go wrong with it. If it is the former, then being "technical" by identity and wearing the right t-shirts has no baring on your ability to program OR design software. If it is the latter, then if you're not detail oriented, then you're not going to be able to help the process more than you hinder in any capacity. Security vulnerabilities, DOS and crashes are all products of not seeing the details of what can go wrong.
It is long past time to return to designing tools not just for rock stars at Google
I guess he didn't notice Go? Why, even when discussing Go 2, the resistance to add complex features like generics is strong: https://github.com/golang/go/issues/19412
Don't get me wrong. The author is right about everything else. But Google is just barking up the wrong tree.
Funny you mention WordPress. Scheduled for the next sprint, we'll be programming detection for over 800 known vulnerabilities in WordPress plugins, and 300-400 in WordPress itself. If WordPress plugins are your example of programming by non-experts ...
In other words, let's pretend programming is easy and everyone can do it. Great advice! The result is known as Windows et al. Have fun!
Unless you can teach the average schmoe the difference between O(n^2) and O(nlogn), you've got no hope of bringing "programming" to the masses. I sped up a visualbasic "program" written by a "normal", by fixing their check for duplicate records by sorting *first*, then looking for dups, instead of going to each row, and checking every other row in the database for dups. Went from running 48 hours to less than 2.
Put another way, there are *lots* of ways to program poorly. Democratizing even the most basic tools won't prevent that.
He mentioned Hypercard. I'd say, bring back something like the CanDo programming environment that we used to have on Amiga.
Re: https://randocity.com/2018/03/...
This was amazingly accessible, like BASIC if you had a BASIC where everything was created visually with a GUI—which is very different from having a visual GUI editor as some kind of mere accessory sidecar. Rather than create your code in one IDE, and a GUI in another, and then try to graft them together (like IB on the Mac), CanDo had you create your GUI which you could then embed code objects into. Your bits of code were simply properties of GUI objects, although it was also possible to have dedicated code-holding objects with no visual presence. It wasn't perfect, because large projects could become disorganized, but for relatively smaller stuff it was brilliant.
So why didn't it get traction; why didn't it take over the world? For one, CanDo was an Amiga thing, and therefore unknown to most of the world. For another, it came out exactly at the time when the internet was taking off, and the rest of the world was going gaga over HTML and Java, while CanDo had no concept of network connectivity.
What you are saying is that you want to be a code monkey because you are too lazy to properly learn most of what is needed to do things properly and clean without taking short-cuts. You must be a millennial!
Tired of my customary (Score:1)
We used to be able to build GUIs with a few thousand lines of code, now you need hundreds of megabytes of js, css, html and whatever else, and everything interacts in strange ways and weeks breaking and getting broken in to. Its a clusterfuck of terrible design.
http://michaelsmith.id.au
Well boohoo. I like our nerdy culture. If you wanna be a sanctimonious white knight, there's always the Rust community.
The basics of computer science -or- one frontend boi
what is this documentation you speak of
Christopher Hitchens:
With writing, the bar is to be more interesting than silence.
With coding, the bar is to achieve a tiny modicum of formal consistency.
Most people suck at both.
And this is before you describe the operating environment, which 90% of those 100,000 pages of documentation are actually addressing.
The average internet user has trouble expressing his ideas, even after years of schooling. Considering they can't master the English language, I'd be surprised if they get any result out of the more formal computer languages.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
Programming today reminds me of the clutter pervading so many homes in the 70s, 80s and early 90s. No surface free from some sort of curio, knick-knack or souvenir. Some useful, some to document an important precept, or capture a moment, some just for entertainment.
Programming needs its own minimalism movement. Mental work surfaces free of clutter, with the sophistication baked into tools that are visible.
For instance, webMethods, a Java-based programming IDE from the 90s, had the right idea back then. A program statement in their native 'Flow' language was no longer a linear line of text. Instead, a line became a 2-D canvas, graphically showing all the in-scope stack variables (so you were reminded of what was in-scope). The variable types (Java objects, strings, arrays, etc) looked different and could be manipulated in the canvas -- so a single 'step' could do multiple assignments, math operations, etc. It also had nifty builtin operations to snapshot and restore the stack-frame (handy for debugging).
Unfortunately, the core webMethods language hasn't progressed much in the two decades it's been around. Neither is it open-source.
In principle, ok, but when you start showing pictures of Chairman Mao, er, I mean Basic... that's done an immeasurable amount of damage. Someone commented about Excel macros. If I need to script something, there's no way I'm using VBA. Writing a simple macro in 1-2-3 was, well, simple and quick. Need more? Use a powerful, more formal language.
Jonathan Edwards has been programming since 1969 (starting on a PDP-11/20).
According to Mr. Edwards' biographical page, he began programming in 1969, and he programmed on a PDP-11/20, but he doesn't indicate those events are connected. Given that the PDP-11 was introduced in 1970, the article seems to have misinterpreted Mr. Edwards' biography.
programming is definitely easier and more accessible to new people than it ever has been
I was writing code in the mid-70's, sold my first piece of software in 1981 so not quite as old as the author but close. I've worked with many languages, BASIC, Business BASIC, C, CFront, C++, LISP, TCL, Pascal, Java, APL, Fortran IV and 77, and COBOL. I've seen the hype through the years where BASIC was bashed, C++ was pushed to replace C, Delphi and Object Pascal were the answer, SmallTalk was the only one doing it right, Java was safer than C++, C# was better than Java, D beats C++, but Rust is even better, static typing sucks, Python is the way to go because Knuth said whitespace should be important, on and on and on.
Last week I was sitting in a room with a number o senior tech folks at our company and we were discussing some tech debt we needed to address. One of our main platforms is written in zOS assembly running on a mainframe and everyone felt it needed to be ported to serverless cloud technology. Me being me I simply asked why, how do we present a funding case to do the work. The answer "its old technology". One person said, "you have to use a green screen application to setup a new customer" by entering a couple of records in the configuration database.
I asked what it would be replaced with and was told "it needs to be a web application". When I asked what was the difference between a green screen application form that talks to a central server and an HTML form that does the same thing, it was like the scene from Star Trek episode "I, Mudd" where Spock looks at the identical robots and says "I love you, but I hate you" and they couldn't grasp the concept because they were the same.
Don't get me wrong, there is a valid business case to be made for rewriting this multi-million dollar earning platform and that is lack of support. We can't hire developers that know this code or are even willing to learn it so we're at the mercy of IBM consultants.
My point is that the architects in this room focused on the "oldness" of the technology as the justification for reworking it and not on the total cost of ownership.
But this brings forward some serious flaws in our current approach to software development - the magpie affect. So many of the folks in our field want to only work with the next hip and cool technology but none of them "stick". So we end up with a morass of applications built with different fleeting languages.
I always liked Business BASIC, thought it was the a good tool for the job. I prefer C over C++ when possible, or just use C++ as C with classes (much like CFront originally worked). Java effectively replaced COBOL as the enterprise platform and it is still going strong. I avoid the .Net/C# ecosystem because of vendor lock in, same reason I would agree with migrating off a mainframe system.
The author makes some decent points, tools like Hypercard allow non-developers to create solutions to problems they have. The professional developers may laugh at how bad Visual Basic or MS Access applications were but they do the job, don't require an army to support.
Nearly all developers or architects I've met at one time or another has used the phrase "best tool for the job", the problem is they spend so much time trying to find the absolute best tool that they ignore the good enough tool.
The problem, I think, is that the overall model is lost. That programing has become something different to doing things on the computer.
In younger days, I could program Lotus for DOS, even doing clever things like programmically hiding lines in print, or adding one's own menu to a spreadsheet. Then Windows came along, and it was all hidden in things like VBA. It no longer was a copy of the commands with logic.
When you could get into files, and see what was needed, you could program for it. I used an RTF file as a batch for a rexx processor, that created documents based on the user input file, and checking the file you could produce good copies of letters. It's a lot harder to do this with a binary file.
I still use REXX. It's a simple language, and IBM envisaged it as the glue of the OS. But they did not lock it up like visual basic. The thing is an extension of the command prompt, and you can write neat filters for things, or fiddle with INI and registry, and create desktop icons from a batch. The current install on my computer is to copy a directory structure, and run the batch file to create links to lots of programs.
OS/2 - because choice is a terrible thing to waste.
The comments here are mostly in two groups: (1) those who feel that programming is fundamentally simple and anyone should be able to do it, given simpler tools, and (2) those who feel it is fundamentally difficult and not everyone can do it.
Those in group (1) point to languages like Python and Basic as proof that anyone can program. However, there is an important issue that is missed in most of the comments: How productive a language is for the original programmer, versus how easy it is for someone else (on your team, or another team months later) to figure out your code and be able to modify it safely. These are very different things.
For an organization with lots of teams, it is very difficult to create maintainable, shareable code. It really takes a professional. I have been in many organizations that had to deal with "the end user computing problem". These organizations undertook large efforts to get code out of the hands of users and into the hands of professionals where it could be maintained properly.
Should it be so hard to code? No, but we are kind of stuck. The OSes and frameworks keep getting more complicated; and worse, the fundamental technology choices that underpin most things were deeply flawed choices - we are stuck with approaches that make things brittle and unnecessarily complicated. Thus, I see little hope of non-professionals being able to write code in the context of those flawed frameworks and technologies.
One of the biggest problems anyone sees if they look at the code being put into production is that whoever wrote the code never gave any thought to its being maintained later, after he/she departs the project. The coolest, froodiest, whiz-bang collection of libraries in use today may have been completely discarded when the next programmer comes along to fix the security hole written into the website/application/whatever, and perforce the new programmer MUST reinvent the wheel in order to repair what the first programmer never saw as a fault.
Languages such as COBOL survive because they are, in large part, self-documenting. (They also survive because no newer language is capable of accomplishing the job the original language did...but that's a separate argument.) While we slog our way through our next entry in the "Obfuscated C contest", similar code gets put into production as back-end processes for data mines, with predictably poor or unusable results, and after the programmer gets fired for not accomplishing the design goal in the PHB's time frame, the next poor sap dropped into the chair is left with trying to puzzle out what the first one was trying to do, and matching that up with whatever design specs the PHB expects to be met, and doing both in the same or shorter time frame as the first poor sap was given. Meanwhile, COBOL applications written 40 or more years ago continue to do the job they were designed to do, and do that job very well, and (provided one can still find a COBOL programmer) are maintained at comparatively low cost.
To avoid being accused of crossing Teddy Roosevelt's line (paraphrased as "Pointing out a problem without proposing a solution is called whining"), here's part of the answer: start programmers out on the KISS formula, and keep them writing code to that formula.
That's as far as I go.
All the world's an analog stage, and digital circuits play only bit parts.
How can you make things easy when what you're trying to achieve changes all the time? Sure, if you want static pages that work at desktop resolutions of 10 years ago, I think you've got the problem licked. Want something dynamic that changes style between desktop and mobile? Sure, you could design it now. By the time it's done and bug free, things would likely have moved enough that it won't fit the bill.
It's easy to make something that would be easy to use -- just limit its scope severely. There's pretty much no other way to do it (although AI might get to that some day, and you'll be looking for a new job). You already have a multitude of solutions of this sort. I can create a nifty site quite easily at Wix or a nice blog at WordPress.com. The only problem is, they're not what your client or your boss wants, and they will never be.
The first car my father had no electronics inside. We have been able to repair almost everything our self.
Try to open the hood on a modern car and you will not be able to identify how to even take it apart.
This is not a problem of programming.
It also cannot be unmade. We consume much higher quality products that are better because of much higher sophistication.
Trying to go back in time to make programming/car repair/getting food simple as it was does not work.
We need the higher sophistication and effectiveness (of the products, not manufacturing) to survive in much more crowded world.
Fantasize about returning to growing all your food/ repairing your own car/ programming web application on your own as long as you want, but it surely is not a thing for everyone anymore.
Good example is a number x that needs to be calculated using some old data and new data. Current application requires that user calculates it and inputs it. Well turns out people suck at calculation so the number is often wrong. So new version of the app calculates it automatically. But when implemented it turned out that no one knew how to actually calculate it. It took about a year requiring a lawyer several domain experts, architecture changes etc. to get it calculated.
This was just a one number that everyone thought was easy to calculate. Horros still wait because the number has been wrong for decades and someone needs to fix the mess.
https://xkcd.com/927/
The problem here is not to make programming easier but to classify the type of tasks you are trying to accomplish.
Some tasks are easy and can be accomplished by anybody without training, so the people without knowledge or sophisticated skills can work them easily. But other tasks are very critical and complex and well trained specialists need to work on them.
Don't try to put everyone in the same basket because you will obtain super complex and heavy things (when you need to do special programs with very easy and powerless tools), or super dangerous solutions (when you are trying to use those easy to use tools in critical environments).
Another issue is about the computers. Before everything was "Basic" because the machines were very simple, slow, with less resources, so only Basic or machine language was possible. But today the user machines are ultra powerful computing devices with many layers or complexity to deal with. An option is to go the Raspberry Pi path and to define small simple things on machines that only do one thing and can do it without a lot of complexity, and not to try to resolve all humanity problems with the current bloated operating environments that are excessive in everything they "try" to do. This is not a programming problem, this is a conceptualization one.
In case you didn't NOTICE shitbrain punk you are? I AM ON TOPIC about coding SPECIFICALLY on Delphi you dumb FUCK!
Additionally: Dear JEALOUS "Lil' Jowie" the "ne'er-do-well" do-nothing - I also don't OBEY a pusscake like YOU that STALKS ME via UNIDENTIFIABLE anonymous offtopic trollings... got it?
You're a POWERLESS little CUNT that can't stop me - accept it.
APK
P.S.=> Of course, IF you'd like to MEET ME IN PERSON & TRY MAKE ME OBEY YOU? You're more than WELCOME to try, straight to my face, man to man (so I can put you in the morgue, you chicken dick little cocksucking motherfucker)... apk
Okay, I'll share a peak into my history when it comes to programming. Started out with raw assembler on 68xx and 8051 8 bitters. Complex and frustrating for the first six months but then it was easy. Then came the RISC parts in assembler not too bad to adjust to. Then I changed jobs and created programs to run on DOS for production end of line testing using QuickBasic. I literally said to myself this is for kids given it's absolute simplicity. Then I shifted to C on embedded micros, very nice as it gave you almost as much flexibility as assembly did, but in a far more human like language, so I found it to be perfectly in the middle of assembler and basic. As the embedded processors got bigger and faster I stayed with C and let all the young whipper snappers go down the path of C++/prime/sharp and so on. For me those spin-offs just added complexity that to this day I still say is overly complicated even when running on Cortex M4s. Of course somebody came out with a zillion RTOS's to make life easier. I never went the way of RTOS, but my co workers did and seem to like it. But over the years I've shifted from software/firmware to hardware. I write enough code now to validate the functionality of the hardware, and C works very well in that environment. In short, I stuck with C and didn't bother with the babble and its complexities today. So, for embedded, I say C is the Language, it goes great with a bottle of Vodka too! But then of course there was a fellow I worked with 20 years ago that was stuck on embedded Fortran, he loved it!
Life is in a state of dynamic equilibrium, it both blows and sucks
Delphi is still in use. It's used for major application in the industrial and transportation sector. I work with it to create industrial GUI's and communication software.
It is better than ever, and is gaining very good cross platform capability.
In the bad old days of Basic, software structure and layers were non-existent. Good luck trying to reverse-engineer somebody else's old code! Today, programming has become much better structured, making it far easier to maintain and extend. There's no way I want to go back!
The hardest part of programming is not the coding. It's deciding exactly what you want the software to do! This is called engineering.
In a way, it's like road building. The hard part is not moving the dirt around and pouring concrete. The hard part is deciding where you want the road to go, buying the land where it will go, putting up with people who don't want the road nearby.
Linux is an excellent example of how we have migrated from a lucid, well written kernel to one dominated by corporate and military interests, that does all things for all devices and platforms. A study, that I can't cite, showed that open software eventually ends up in the hands of sophisticated specialists, thus refuting the cathedral vs bazaar argument of open software development.
SystemD is one more example of how the KISS principle has been sacrificed at the altar of sophistication.
If someone just finds a way to make Delphi/Lazarus easy to deploy (install & upgrade) on desktops, it might catch on in corporations. Desktop deployment headaches are mainly what made Web-based applications catch on. Solve the deployment problem and we can get away from the spaghetti web stacks, and UI's become simpler to make again. MUISA!
Some say Microsoft has greatly improved Windows WPF application deployment, making it automatically detect upgrades, prompting users; and optionally automatically upgrading without a prompt if the developers choose. The pendulum often swings, so maybe desktop apps are back.
Table-ized A.I.
Jonathan Edwards has been programming since 1969 (starting on a PDP-11/20). "Programming today," he writes, "is exactly what you'd expect to get by paying an isolated subculture of women to entertain themselves for fifty years.
Johnathan Edwards, yuou have outed yourself as a sexist bigot. Gotta remember my good sexist, if you Exchange "women" for "men", and it is considered sexist, the original statement was as well. I mean, it is politically accptable to blame matters on people by the basis of them having a penis, but that's their sex.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
where does this presumption that EVERYTHING must be graspable by EVERYONE?
what happened to BRAIN SURGERY FOR ALL?
or CHEMICAL ENGINEERING FOR ALL?
or PARTICLE PHYSICS FOR ALL?
basic and hypercard are never going to be able to write device drivers. what the fuck are we even talking about???
There has always been a field of computer science devoted to making it easier for people to create applications to get stuff done, and it has always been opposed by coders. "You have to hand code in machine language because only by abstracting what the computer is doing in your own mind can you understand what's going on and create precise and optimally efficient code. This new fangled assembly language will never work". And "You can't write an OS in a compiled language like C, it has to be done in assembly language to get the precision and efficiency needed". "You can't rely on builtin data types, or methods and garbage collection, you have to design data structures and allocate memory by hand for things to work and be efficient". Guess what wins out in terms of costs?
Edwards is just pointing out that today the approach has shifted to paying brilliant PhDs to spec, prototype then write code that scales up to billions of users and then rollout it out on cloud based systems rapidly. This way you, crush the opposition and gain a monopoly in what you want people to be doing. And of course whenever Governments try to copy this they produce IT systems that don't even work, with triple the original budget and take three times longer than planned. That is a barrier for the entry of competition into the market, which results in high profit margins. Barriers to IT adoption also limits the productivity of workers, which results in low paying jobs with poor conditions that only exist until the PhDs figure out how to abolish them entirely.
Instead you can return to devoting some computer science resources to make developing applications easier for people. In the last 30 years there have been systems developed that allow you to specify algorithms in a human readable format. You then feed them into a compiler that spits out code that is proved to be mathematically correct, and where every step is fully documented. They are finding use in complex aviation and defence systems where a single obscure bug can produce catastrophic results and regulators like the FAA require every step be documented for accident investigations. And after Toyota had to pay out $3b for an findable presumed bug that caused their cars to accelerate for no reason and crash, car manufacturers are looking at them too. After the Commonwealth Bank was fined $700m for a bug that resulted in their ATMs not logging transactions properly for reporting to the Australian anti-money laundering body, the finance sector might be looking at them too.
And if a professional contractor or worker in a business, who understand the problem first hand, can create an application, without a PhD and 10 years of experience in all the best coding techniques, then they become more productive and valuable. Instead of being replaced by a system full of bugs that doesn't do everything that was wanted. Anyway, that's Edward's idea, using computer science to expand programming into more areas, instead of just focusing on what's possible by geniuses at the bleeding edge.
I agree with the general sentiment. My own answer to this was something called "concept programming", which focuses on the translation of ideas into code. The following presentation gives an outline of what this means and a few early results: http://xlr.sourceforge.net/Con....
From that I derived a concept programming language called XL, https://github.com/c3d/XL. Which keeps evolving too fast to ever stabilize. Two semi-stable variants emerged, however, one called Tao3D for interactive real-time animations (http://tao3d.sourceforge.net), one for distributed programming and the Internet of Things (https://github.com/c3d/elfe).
Both variants demonstrate, technically, how well the concept programming approach works, and how well it answers the original posters questions. However, nobody cares. None of these languages ever reached a "good enough" status, i.e. a status where you can really make a living out of programming them.
I'm still working on this, though, and I still believe that the original idea is sound. It just needs more focus on execution, ironing out all the details (e.g. having a complete runtime support library), building a community, etc, things I never really had enough resources to do well enough.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Completely agree with "Computer science is not a prerequisite for most programming", after all, programming isn't Computer Science.
The amount of times I hear 'oh, I'm a Computer Scientist too' when, upon enquiring further, it turns out that they've spent 3 years at university essentially studying - no, scrap 'studying', insert 'learning' - some sort of framework and a bit of Java and Python ffs. Writing an Android app isn't studying Computer Science; and no, you're not a Computer Scientist. Now I will concede that at some institutions you will learn some proper CS-underpinning stuff, but only at some of the better institutions. My own had the right idea - they have a sign up saying 'The computers are for email and writing-up, please use the whiteboards for the Computer Science'.
There's nothing to be ashamed about either - if you find that you're actually not a Computer Scientist. Truth is, we don't really need very many Computer Scientists! Think of them as being more like theoretical physicists if you like. Or better still, Materials Scientists. Materials Scientists know a lot of chemistry and physics - you need to if you want to create new interesting materials: The Physics Nobel in 2010 was more or less a Nobel for Materials Scientists ("for ground-breaking experiments regarding the two-dimensional material graphene"). Materials Scientists create new materials which in turn are used by engineers, e.g., Civil Engineers. Civil Engineers don't need to understand the deepest underlying properties of a material in order to use it in a project. In turn, the workers actually building stuff don't need to be Civil Engineers and/or Architects - they have their own set of skills. At one end you have the few, at the other the many.
We've over used the term 'Computer Science' - after all - it sounds good doesn't, "I'm a scientists!". Drives me mad. A simple test - here's a link to some proper Computer Science. IF you can follow this - and a bit more than roughly, then you're good to go: https://eccc.weizmann.ac.il/re...
LoL. We, the hand programmers, can be useful too after the singularity.
More seriously, I think long term education on programming should focus on algorithms. Part 1 (data types, loops, sorting, graphs, recursion ... ) part 2 (complexity, distribution, scalability, of the part 1) part 3 (real time, prooved, machine drivers, machine Learning ...)
Algorithms are everywhere and unlike programming language they are not an hype technology.
The real difficulty is to teach a sound algoritmic framework ... that scales up from part 1 to part 3 and above. I think many programming languages share today the same paradigm and should belong to the same algorithmic notation.
I guess that all programming languages will belong to a teachable algorithm notation.
The difficulty of learning many programming languages seems to reapeat the history of math notation. Math notation has converged to a norm, for humans to detect errors and ambiguities. Even us programmers have been able to check our own math in high school. Some real mathematicians creates their own checkable (consistent ?) notation to proove their new math.
But programming languages have to be checked by the programmer, by the compiler. And maybe by the patent bureau ??
Of course there exist computer class on language design, and this class, with the algo class, should adress the diversity of programming languages.
Which is why there is still so much COBOL code still in use. People who hate COBOL and want to replace it with a Java, C# etc. application instead are not aware of how complicated and involved the COBOL code is, also how much money it cost to write and get rid of all the bugs. Writing software is a time consuming thing, and since time = money writing software starts to get VERY expensive.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
It's been tried - and rejected by the folks that pay salaries.
There was a programming language way back that utilized a flow chart type language with visual blocks that you simply filled in the logic parameters.
Arguably Visual Basic was accessible to non-compsci folks. Nope - they hired people to code still.
Hypercards died from lack of interest.
IBM had a database product with flexible field definitions assigned as a form.
Basically you picked a field type, gave it a name and label, slapped it on a form and the thing would create a database.
Filemaker used to be approachable in a simplistic manner.
Nope, truth of the matter is that business people simply want to offload responsibility for doing to doers and stick to managerial tasks.
Corrections:
Re: "can crank out applications at about 1/7 the pace"
It should be "at 7 times the pace": 7 applications per 1 application from the web stacks. I should also clarify it doesn't really speed up the analysis side of things by 7 times, but because they can make an actual product faster than others make examples and prototypes, it does speed up the feedback cycle with customers to a degree. (Our web stacks could probably be simplified to some degree also, but our shop is stuck in habits. With a well-tuned web-stack, per fitting our org, the ratio would probably be 3-to-1.)
Re: "learn from the failure Java applets and Flash"
Should be: "learn from the failure of Java applets and Flash"
Table-ized A.I.
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible.
I've seen many of these "technologies" which are supposed to make programming easier and more accessible, from the ones cited to things like true visual programming (e.g. LabView...) and the by far the biggest problem these "solutions" have is that they are only really applicable to trivial problems, and when you try to apply them to large real-life problems, they quickly become unusable and WAY more complicated than traditional approaches.
Sure, it might be easier to write "Hello World" with some of these, but try writing an enterprise app that has to handle hundreds of thousands of users with them: you're either not going to be able to or it's going to be a LOT more complicated than doing it the normal way.
TL;DR
Trivial solutions only work for trivial problems, and most real life problems are NOT trivial.
Two seconds into a discussion about how programming computers should be simple and easy to do without a CS degree and all our multiple coding/design/development designations - we get into wanking about Arduino or C++, frameworks, Java . . . You just don't get it do you (mostly) guys? It isn't about the tools you love to handle and the joy you get from them yourselves, it's about the ease and speed with which you develop a working, bug-free system for your client.
I opened Visual Studio 6.0, had no idea what to do in the IDE. So I opened the help, clicked on Getting Started. I got to a page that told me how great Visual Studio is. I clicked links to other pages, and other links there. And I just came to pages that told me how great it all is, and I did not get started at all. It was just a large loop between such pages.
And I already knew how to program, in Delphi, Pascal and Basic. I got along with Delphi without any outside help. But this Visual Studio was just impossible to get along with if on your own, without literature.
Web Code is a solved Problem: How about fixing Web UI next?
Table-ized A.I.