Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

'The Problem With Programming and How To Fix It' (alarmingdevelopment.org) 560

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."
This discussion has been archived. No new comments can be posted.

'The Problem With Programming and How To Fix It'

Comments Filter:
  • Arduino?
  • by Opportunist ( 166417 ) on Saturday August 04, 2018 @09:49AM (#57068464)

    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.

    • by Darinbob ( 1142669 ) on Saturday August 04, 2018 @11:08AM (#57068870)

      You've got to factor in product and project managers too. As in "guys, we've got a big potential customer who suggested that sweaters might be toasted, so can you get this done by next week? I already told them we'll have a demo, so don't let me down." and "it would set us apart and be disruptive to the toaster industry if this could wash dishes too."

    • What you're describing sounds way more like what happens when you let managers with MBAs and the markering department make determine what features your product should have. Some over-eager programmers may suggest various improvements, which in your example would be things like making it easy to empty out the crumbs or ensuring it's well done but won't burn your fingers where you grab it after it's done, but most programmers I know only go overboard on how well they want to get it to achieve the intended tas
  • by oldgraybeard ( 2939809 ) on Saturday August 04, 2018 @09:50AM (#57068474)
    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 ;)
    • Interesting. The complaint I hear most often in the UK is that there's too much emphasis on exam results in core subjects (english, maths, science) at the expense of art and humanities.

      • I have a feeling that's mostly to do with how many people in particularly humanities end up in education as they don't have much else in terms of post-university job opportunities. When a larger and larger section of our youth end up in higher education and the outside-of-education employment prospects of these groups stay the same their share of people in the education sector will obviously go up and they're obviously going to be pushing their what they studied to be given more focus.

        Where I come from e
    • I think the actual skill that really matters is the ability to mentally model what is happening, manipulate the problem and solution abstractly and model the solution.

      I can see the limit on some people when trying to walk them through specific problems, drawing things on the white board, explaining the implications of X, Y and Z etc., and they really struggle to see it. But the people that are good get it naturally with limited information transfer.

      I do think that having an environment/set of tools t
    • I think proper exposure to coding is the main issue.

      I think that if you can show a kid in high school that there's a class of problems that a computer can do a lot more quickly and accurately and save them time by writing a few lines of code, they'd be more likely to code later in life.
      And I think one good way to achieve that is to give them a project that's relevant to their interests and have them work their way to a solution.

      When I was in grade school I remember this really annoying class, they made us w

  • by El Cubano ( 631386 ) on Saturday August 04, 2018 @09:51AM (#57068488)

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

    • by arth1 ( 260657 ) on Saturday August 04, 2018 @10:11AM (#57068598) Homepage Journal

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

      I want someone to be in charge of building my house that understand enough about wood, concrete and plumbing to safely fuse the different work, without it falling apart next year.
      And when I have surgery on my foot, and the surgeon spots a rupturing blood vessel, I want him to be able to deal and not have to put me on ice while attempting to find someone who knows something about veins.

      A strong base with branching out into special areas is what I want to see. Not specialists who have no fundamental knowledge, unskilled labor who fall apart when instructions don't match reality, nor generalists that are so general that they can't actually do anything.

      • by El Cubano ( 631386 ) on Saturday August 04, 2018 @10:54AM (#57068794)

        I want someone to be in charge of building my house that understand enough about wood, concrete and plumbing to safely fuse the different work, without it falling apart next year.

        That person is called a general contractor, the construction equivalent of a project manager. Of course, you don't expect that person to set the roof trusses one day, run the electrical the next day, and then figure out why the main train to the setpic tank backed up the following day. Yet, that is the equivalent of what is expected of "full stack developers."

        And when I have surgery on my foot, and the surgeon spots a rupturing blood vessel, I want him to be able to deal and not have to put me on ice while attempting to find someone who knows something about veins.

        I think the ability of the surgeon to deal with depends on a variety of factors. In some cases it might be likely that the surgeon could handle it on the spot, like if the surgeon is a vascular surgeon, and in other cases it might be less likely the surgeon could handle it on the spot. In any event, I would expect surgeons to have at least basic training in recognizing and even to a certain extent dealing with situations that might arise in the normal course of their work.

        A strong base with branching out into special areas is what I want to see. Not specialists who have no fundamental knowledge, unskilled labor who fall apart when instructions don't match reality, nor generalists that are so general that they can't actually do anything.

        I think I did not communicate myself well. The "full stack developer" postings I see and positions I hear people talk about are roughly the equivalent of "must be master-level skill in UI, back-end, algorithm performance, architecture design, (and so on for half a dozen other areas of expertise), must have 10+ years experience in each of those areas, and we will pay $50-75k". That sort of thing is just unrealistic. A good programmer I think can be expected to be really good at one major area of development for every ~10 years as a professional programmer, so to find someone that has excellent skills in three major areas would require 30 years programming experience. That is not at all the expectation of anyone I have heard of go looking for a "full stack developer".

        • by Junta ( 36770 )

          One thing is that it really depends on the complexity of what you are setting out to do. All too often a business assumes *any* software is as complex as building a skyscraper, and overthinks things.

          Another is that in my experience, a lot of companies will declare someone a 'project manager' who has no particular understanding of any of it. When I speak to a general contractor, they may not be 100% able to do everything, but they will know enough to actually provide valid feedback and assessments.

          The prob

    • by jareth-0205 ( 525594 ) on Saturday August 04, 2018 @10:14AM (#57068616) Homepage

      Agree on the 'full stack' craze, I also rail against the common mantra that you should use whatever programming language is best designed for the particular task... I tend to stick to the languages I know well rather than jump around. I know that I will probably suck if I switch languages outside the 2 or 3 I already know...

      Even the best programmers make a litany of errors each day, any surgeon who had the mistake rate of a rockstar programmer would be struck off immediately. We think we're so good, but computer science is so far behind every other profession.

      • Agree on the 'full stack' craze, I also rail against the common mantra that you should use whatever programming language is best designed for the particular task... I tend to stick to the languages I know well rather than jump around. I know that I will probably suck if I switch languages outside the 2 or 3 I already know...

        When I was fresh out of school, I would choose languages/technologies like this:

        • What is best for the job (i.e., in absolute terms)?
        • What is cool that I want to try out?

        These days, some number of years later, I do something like this:

        • What language is the existing system written in?
        • What language is best known by the development team?
        • What language provides a stable long term platform for development?
        • What languages project good integration points that work best to meet customer expectations?
        • What languages do I
        • We also knew more than one programming language in the past and used them regularly. Ie, the program is in C, the data is preprocessed in Perl, the mockup is in Lisp, and the build system is a web of shell scripts.

    • So my company has manufacturing, hardware, firmware, and software. Software is split into the parts that are important and must work from the parts that are fluffier. I do see a distinct type of skill sets in each of those areas, even though all of them involve some form of software.

      I think it's when you get to web based applications that the distinctions between areas of the product become fuzzier and then there's a desire for "full stack" programmers because they're more fungible and you can shift them a

  • 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.
  • Not "how to fix it" (Score:3, Informative)

    by Kohath ( 38547 ) on Saturday August 04, 2018 @09:58AM (#57068522)

    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.

  • The reality is... (Score:5, Insightful)

    by blahplusplus ( 757119 ) on Saturday August 04, 2018 @09:59AM (#57068532)

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

  • by chispito ( 1870390 ) on Saturday August 04, 2018 @09:59AM (#57068534)
    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.
    • by xtal ( 49134 )

      Python rocks.

      It has allowed me to forget about the abomination that is C++.

      C for everything else.

    • I'm sorry to say it, but the most obvious counter-example to what he is saying is... Python.

      Literally the first time I tried to use Python to do anything useful I C&P'd a code sample from a website and the browser destroyed the formatting. Even BASIC wouldn't do that.

      The mention of Hypercard does make me wonder, is there any free modern equivalent? There are of course commercial equivalents, and Filemaker springs immediately to mind. Once you know a little about programming (which is about how much I know) you can use Drupal in basically the same way. I was able to make a tool which interprete

    • by Kjella ( 173770 )

      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.

      Well, he seems to be conflating programming syntax with standard libraries, since he's talking about a hundred thousand pages. Like for example I looked at the Swift language reference and it's 676 pages long and that covers every bit of grammar in great detail. And even that is confusing the part that complex programming languages are there to make programming simple. A Turing machine is ridiculously simple, read the tape symbol, write new symbol, go to new state, move left/right on tape. It's also horribl

    • by Junta ( 36770 )

      There's a phenomenon where you forget how to be 'satisfied' with easy programming. When you start out, you don't know how to do much, but what you can do seems easy. As you acquire experience you become able to do so much more than you ever thought you could.

      Then one day years on you take a step back at how you do things and think 'man, this is much more complicated than when I started out'. What you fail to do, however, is try to use those simplistic approaches to solve a problem that you are now used t

    • When he says programming is harder, I think he means that for X% of problems, especially enterprise business apps, the amount of effort to do basic stuff has increased, and he's right. During the 80's I was creating business apps on midrange computers and the tools were pretty simple allowing us to be extremely productive. Far more productive than today when measured by how fast large enterprise apps can be built out.

      One problem I think he is seeing is that different technologies get introduced that sol
  • Yeah, no. (Score:5, Informative)

    by vadim_t ( 324782 ) on Saturday August 04, 2018 @10:00AM (#57068544) Homepage

    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.

    • by pjt33 ( 739471 )

      The point you make is a very valid one, but (on the basis of the summary) I'm not sure that you're necessarily in disagreement with the OP. Making a dynamic website requires you to understand a lot of layers, but there are useful systems which are very simple. Sometimes you just need to munge some data, and a skilled Perl user could do it in one line and no more than five minutes. Far more people have problems on that scale than need to make large websites, but most of them will do the data munging by hand

      • by vadim_t ( 324782 )

        That is dangerous in this day and age. Where does this data you need to munge come from? Where does it go to? How does your tool manipulate that data exactly? This munging is going to be one of the layers inside some kind of system, so you still need to consider how it fits into it.

        And then we have to consider other issues, like: does Perl even fit well into this system? Are you causing scalability issues by executing an external command? Are you creating a security problem or a bug by passing commandline a

    • You make it sound as if the choice were between simple-but-incapable and featureful-but-complicated. I'm absolutely not convinced that this is anything but a result of shortsighted convenience. This is a massive false dichotomy.https://developers.slashdot.org/story/18/08/04/055254/the-problem-with-programming-and-how-to-fix-it#
    • by Tablizer ( 95088 ) on Saturday August 04, 2018 @11:08AM (#57068866) Journal

      It's not the 80s anymore. Useful systems are complex, have many layers, and tend to grow new layers over time.

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

    • by Junta ( 36770 )

      Note that you don't *need* to have a database, server side execution, javascript assembled DOM, and such.

      I do that in some cases.

      There is however a documentation site I am responsible for that is just HTML and CSS. People originally said 'oh, it's going to have to be some complex CMS' but we went a different direction. Designers can play with the css and our technical writers just edit text and a build system kicks off to produce HTML and CSS and put to the site.

      As a result, much less surface for attacks

  • anyone can do it (Score:5, Insightful)

    by Anonymous Coward on Saturday August 04, 2018 @10:01AM (#57068554)

    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!

  • by Karmashock ( 2415832 ) on Saturday August 04, 2018 @10:04AM (#57068570)

    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.

    • by Greyfox ( 87712 )
      Yeah, and you're not going to get software from people who don't understand the problem you're trying to solve and who don't know something about the business you're in. Finding a person who can put all the pieces together and actually deliver a product is still hard.
    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Saturday August 04, 2018 @02:25PM (#57069668) Homepage Journal

      On one hand, you're entirely correct.

      On the other hand, why isn't there some Lego-like programming environment that wraps up complicated functionality in lick-and-stick modules, for those cases which are simple? Where you plop down modules, and drag outputs to inputs? So what if it only handled the majority of what noobs want to do, wouldn't that be enough to be useful?

      There have been numerous programming environments which take all the programming out of programming, at least for simple tasks. A user could get a lot out of Hypercard without writing any code, even making use of binary plugin blobs in some cases. Unfortunately, I feel much of what killed Hypercard due to disuse by the masses was the everyone-must-pay mentality in Mac-land. Much of what got me to give up using Macs is the high percentage of simple tools whose Linux or even Windows analogue is free, but which cost money on Macintosh — and not a dollar or two, either, but often tens of dollars for really very primitive functionality. If you wanted to do e.g. some simple serial port call and response in a Hypercard stack, you had to pay for that functionality, probably because the development tools were not only nonfree but actually expensive. It's a bit more confusing today, when Xcode costs nothing.

      Another example of programming taken out of programming is found in the various game creation kits, like SEUCK or any of the many text adventure builders — the latter more than the former, of course.

      With the full understanding that doing anything the software wasn't designed to do is going to require coding or at least scripting, why isn't there a drag-and-drop programming environment worth using by now?

  • 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 incred

  • by mykepredko ( 40154 ) on Saturday August 04, 2018 @10:13AM (#57068610) Homepage

    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.

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

  • 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.
  • Jonathan Edwards has been practicing brain surgery since 1969. "Brain surgery 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. "It is long past time to return to designing surgical tools not just for rock stars at the Mayo Clinic but the vast majority of doctors and laypeople with simple small-scale brain problems,"

    There, fixed that for you.

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

    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

  • 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,

  • 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,

    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 Pri [wikipedia.org]

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

  • 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 her

  • by Zobeid ( 314469 ) on Saturday August 04, 2018 @05:04PM (#57070186)

    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/... [randocity.com]

    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.

Trap full -- please empty.

Working...