Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
This would work fine, except in terms of success.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.



Pseudocode Libraries

To show how things are actually done, as well as to save time, and to standardise according to best practice
  (+9, -1)(+9, -1)
(+9, -1)
  [vote for,

What if you’re writing pseudocode, and you honestly don’t know how a computer would solve a certain problem or perform a certain task. There should be libraries available, standard, or foundation, that gather together a set of common tasks and describe in slightly further pseudocode detail how those tasks get performed in systemic manner (because most things a computer is programmed to do are not at all obvious that that was the way to accomplish it).
Ian Tindale, Nov 11 2010

Duff's device http://en.wikipedia...iki/Duff%27s_device
A 'case label fall-through' in the C programming language... Basically a quirk of the logic of a case statement that uses fewer processing steps than a 'normally' coded version. [Jinbish, Nov 11 2010]

Like this idea... Nested_20Cookbook
... but aplied to programming. [Jinbish, Nov 27 2010]


       Didn't Knuth do this in _Art of Computer Programming_ ?
mouseposture, Nov 11 2010

       [Ian]: So kind of like trying to bridge the gap between higher layer prog languages and, say, assembler?   

       (Like the kind of awareness *real* programmers needed back in the day when resources were truly limited.)
Jinbish, Nov 11 2010

       There's design patterns, not quite pseudo code, but nearly. Then there's maths.
zen_tom, Nov 11 2010

       ... and then there's moths.
FlyingToaster, Nov 12 2010

       [Jinbish] You may be thinking of microcode. Pseudo-code is what a programmer writes down while they are working out an attack on a problem. It's not meant to run; it's just there as a mnemonic for the programmer to come back to later and code in real code.   

       IF (thing)=TRUE {DO STUFF} UNTIL {other thing}
BunsenHoneydew, Nov 12 2010

       I was all set to rail on about how "Tips and Tricks" is no substitute for knowledge when it occurred to me that this might be a low-level rant against poor documentation, ie: you have something you want to do in a certain language/app, but it's not at all clear from the owner's manual if you can do it or not. Been there.   

       Auld 3GL's ("high level languages") documentation rarely if ever mention how a command does something, but the requirements and limitations are usually spelled out quite clearly.
FlyingToaster, Nov 18 2010

prufrax, Nov 18 2010

FlyingToaster, Nov 18 2010

       Programmers aren't always content with existing library code; they often reinvent the wheel for one reason or another, and its not wrong to reinvent the wheel if you have a good reason for it and you do a decent job. It is a lot easier though if you have a model to work from, and pseudocode would work well for that.
Spacecoyote, Nov 18 2010

       Most programming languages have terrible ergonomics. The only people that don’t seem to be bothered by the discomfort are programmers, while everyone else is simply repelled from it.   

       Pseudocode seems to be a much more comfortable and palatable way of tackling the immensely tedious and unrewarding task of having to write a program, because it avoids the defensive outer armour of idiosyncratic syntax. However, it doesn’t actually tell the user what to do next. What to type. What to write. What kind of process is required to do a certain task.   

       I mean, most programming examples I’ve ever seen seem to be constructed entirely backwards. There’s a certain task that needs to be done and the answer is a peculiar and frankly unintuitive set of leaps and contortions that nobody would have guessed in a million years, let alone somehow worked out that this contraption is the answer looked for. Given the answer, then yes, you can see how it might actually perform the job — but no-one would ever have guessed to begin with.   

       This is a library of lots of those. How to make a computer actually do tasks, because almost every task turns out to be far from straightforward. Unless you’re a computer programmer.
Ian Tindale, Nov 19 2010

       //because almost every task turns out to be far from straightforward. Unless you’re a computer programmer. //   

       I also hear that there are quite a few human languages that are difficult to understand unless you speak that language... physics textbooks which are gobbledygook to people who don't know anything about physics... which might not be what you mean but it sure sounds like it.
FlyingToaster, Nov 19 2010

       BASIC is pretty straight-forward, especially those flavours that don't force you to DIMension arrays. Most people should be able to understand what a suitably written BASIC program does.   

       FOR...NEXT loops might look unusual to people who aren't programmers - but appear in lots of programs. I think one of the problems with understanding programming that the uninitiated have is the sense of at what scale the computer operates. It's often a shock to discover how repetitive and stupid a computer is, and that it is usually necessary to solve a problem programatically in a way no human would consider solving it.   

       That disconnect isn't a function of how ergonomic a particular language is, it's more to do with how computers work as blind, repetitive machines that bear more resemblance to an automatic production line in a factory than a thoughtful, intelligent being. Despite this, the anthropomorphic notion that a computer is a robot-like person, who understands a 'language', performs 'commands', takes decisions, and 'welcomes' its users continues to flourish. It's that metaphor that's at fault. What's needed is some kind of machine, or factory metaphor showing inputs, functions and outputs. And there are various tools out there that do just this. Often they are linked with Business Process Modelling (BPM) and the current route-to-sales seems to be convincing non-technical decision makers to purchase a product that provides non programmers an environment that lets them create programs.
zen_tom, Nov 19 2010

       Well this is it, there’s a lot of people that either need to program, or require writing the odd program now and then, but have absolutely no desire to become a programmer, nor dedicate enough of their mindshare to “mastering” it.   

       The development of programming languages is happily escalating into emphasising the finer details and distinctions, but leaving behind the opportunity to cater for a programming language that acts as an appliance, essentially for people who aren’t going to take it apart to see how it works. Like an appliance, it should be ergonomically unirritating, and work the way a normal person would expect it to.   

       However, that doesn’t necessarily address the solving of problems, the executing of tasks, the writing of programs — that logic eludes everyone except experienced programmers. I’m not sure there’s a way round that, except for this kind of pseudocode library.   

       People would say “I need to do x” and the library would have examples of that mechanism in normal language, and you’d read it and say to yourself “well, who’d have thunk” and then just get on and use it, and get down the pub all the sooner.   

       Note, I’m not saying I’d like a programming language that has an easier syntax, although certainly I’d like a programming language that has an easier syntax. I’m saying that even if such a language were in front of a normal person, they still wouldn’t figure out in a reasonable amount of time, how to use that language to make x happen. It’s that that this addresses. I know what I want the computer to do, I know all the words in the language (or have a book that does), but there’s a huge gap in execution. How does this task become those words?
Ian Tindale, Nov 19 2010

       Really? So there’s no need for any of this idea at all?
Ian Tindale, Nov 19 2010

       I keep getting overdue notices from the pseudocode library.
normzone, Nov 19 2010

       Withdrawal symptoms.
Ian Tindale, Nov 19 2010

       No, how does one recognise what any of it means in the first place? You haven’t explained how the highly encoded program can be pushed backwards into something comprehensible, to enable any understanding whatsoever at the pseudocode level. You see, it’s all structured backwards as usual.
Ian Tindale, Nov 19 2010

       Also there are licensing concerns so you can't just go lifting code willy-nilly. With psuedocode its not a problem.
Spacecoyote, Nov 20 2010

       //there’s a huge gap in execution//   

       That's the commercial break. It drives the hangman nuts.
pertinax, Nov 20 2010

       //Most languages are roughly the same// That is either a very sophisticated comment or something else.
mouseposture, Nov 20 2010

       k, I'm curious: assuming you're reading a source code, what's it supposed to do, what language is it in, and why does it look backwards ?   

       If it's uncommented the reason might be security, ie: your understanding how the proggie does what it does isn't too far up their list of things to accomplish and they've decided to have a bit of fun with would-be reverse-engineers.
FlyingToaster, Nov 20 2010

       What are you talking about?
Ian Tindale, Nov 20 2010

       "You see it's all structured backwards, as usual"
FlyingToaster, Nov 20 2010

       That’s right, in my opinion. It is. Examples of how the programming for certain tasks work are usually so utterly arcane that they would never ever be arrived at by the ordinary reader of their own volition. However, once you’re there, and it is explained thoroughly enough, eventually it dawns how it works. In other words, you can get there easily if you start from there in the first place.
Ian Tindale, Nov 20 2010

       //ordinary reader// or, in the vernacular, a "compiler". What's supposed to read them is the computer; the exception would be a maintenance programmer who *does* need to be able to understand it but is usually trained to do so.   

       [edit] The linked "Duff's Device" is an example of what stupid crap happens when you're too cheap to purchase a C compiler with an inline assembler.
FlyingToaster, Nov 21 2010

       I still have no idea what you’re talking about. Are you replying to something on a different page?
Ian Tindale, Nov 21 2010

       No, I'm not.   

       Do you actually mean   

       "I wish those bloody programmers would put useful comments in their programs" ?(solution: hire better and/or English-speaking programmers)   


       "I wish I had a <language statement> to English translation" (solution: buy a "x programming for Dummies" book)   


       something else.
FlyingToaster, Nov 21 2010

       Hi, [Bunsen]. Thanks- Reading my comment back it might not seem like it, but I know what pseudocode is (my old 'C' lecturer was a stickler for pseudocode before he'd bother to look at your actual program).   

       The reason I commented like I did was because I was trying to tease out what [Ian] was really after - because real pseudocode is either a descriptive form of a flow chart, or it's a higher level "Program does this".   

       The bit that [Ian] suggests "slightly further detail" is the bit that got my attention. So, my original pseudocode says:"create variable called 'Dave'"; my C code says "char Dave"... That's all fine and lovely. But the C language is compiles to assembler and my assembler says god only knows what.
And therein is the point- a psuedocode library for a specific language level telling you what happens. ('Dave' copied to register X, Dave shifted 5 places... etc...
Jinbish, Nov 21 2010

       //The development of programming languages is happily escalating into emphasising the finer details and distinctions//   

       That's a load of shite.   

       //Like an appliance, it should be ergonomically unirritating, and work the way a normal person would expect it to.//   

       So's that.   

       Having read through your comments, [Ian], it does sound like complaining that programs should 'just work'. I'm pretty sure that's not quite what you mean; but that's what it looks like...
Jinbish, Nov 21 2010

       I wouldn’t have thought a word like “variable” has a place in pseudocode, it’d make it sound like you’re talking like a computer, in that monotone robotic voice. It’s more appropriate to say what you actually want to happen, rather than guess how the computer should do it. Then successively add detail until it looks like it can make the leap into an actual implementation, with variables and all those other things.   

       However, this still can’t happen unless there is or are: either libraries of pseudocode that show how certain things happen when a computer does it; or b] years of prior knowledge of how this sort of stuff happens.   

       Most people I’ve been conversing with over the past week have displayed a stunning stupidity. I don’t know why. They are certainly not open to the idea that people might not want to grow up to be programmers for a living. They also are not open to the idea that there is a requirement to program, now and then, without having to take a decade out to master such a task. They are also completely failing to discriminate between ‘easier’, and ‘simplified’.   

       I think that once a person goes into programming, they can’t get back out and perceive what is wrong with the paradigm at all. As such, the flaws will never ever be fixed at this rate.   

       Imagine instead what programming will be like in about ten generations, or a couple of hundred years. Absolutely nobody will have the slightest clue how any of today’s programs worked, because they are so complex, cryptic and unergonomic. Nobody will put up with this sort of nonsense for very long without improving the situation. I think future generations will be less able to learn programming, not more. I think they will be repelled by the increasing complexity and abstractness of the whole thing. Then a gap will grow between those older generations that still understand islands of the arcane knowledge, and younger generations that only know bits of newer frameworks. Those will increasingly be structured to the way that normal people actually think, rather than the way that professional programmers have been tediously and tortuously taught.   

       It’s fine if programming has no other end other than to be a programmer and to make programs, but this is not the reality. There’s so much else to do, and having to battle with programming is such a minor percentage of it all. Spending time learning programming will show up as insufficient time spent on creating the rest of a design or artwork or creation, and the whole thing suffers because of the disproportionate demands of one part, often with no actual reward until perhaps the last minute, if you’re lucky.   

       It’s not about comments in programs — what’s that got to do with anything? It’s also not about translating individual statements into understandable form. That’s too granular. It’s more about honestly not knowing how a computer would solve a certain problem or perform a certain task. Even without having to battle with some ridiculously fussy and hostile syntax, it’s essentially something that almost nobody finds natural.
Ian Tindale, Nov 21 2010

       You're right [Ian], I shouldn't have used 'variable' in my pseudocode example. Here's the thing I'm struggling with: pseudocode is really just a literal flow chart if what you want your program to do- at a high level of abstraction. To make the leap of actually making something happen you have to continue to elaborate and eventually leave that realm and start actually interfacing with the computer. It's not pseudocode that you're really after, it seems to me like the issue is transitioning to actual code... via some iteratively more detailed psuedocode process (is that what you're driving at?).
Jinbish, Nov 21 2010

       wot Jin said, bolstered by your statement...
//what's comments in a program got to do with it?//
which, since pseudocode usually ends up as the comments in the program and is exactly what your post said you were looking for....

       Can you fill in the blanks here ?   

       "I want to write a program that does <x>, and I want to do <y> as part of it, and I looked at example <link z> and I couldn't grok it."   

       solve for x,y,z
FlyingToaster, Nov 21 2010

       At one point in time, it was a whim, a notion, a single action, in the mind of someone who required it to happen.   

       I suppose if taken to the ridiculous extreme, pseudocode becomes management:   

       ‘When the blue button is pressed, the page I can see saves to the USB stick. Or I’ll cut your balls off.’   

       or more probably, with today’s restrictive employment laws:   

       ‘Write some of that code stuff that you do so that when the blue button is pressed, the page I can see saves to the USB stick. And have it ready by midday or you’re fired.’   

       But that would be too high level for this discussion. The level we probably come in at is that of a user and their own requirement loop:   

       ‘I can see a page on the screen and I want it to be on my USB stick
Make a button.
Make the button know which page I can see.
Make the button know where I want things saved.
When I press the button.
Save what I can see.’

       But that’s still too high level to match with what a computer can do. At this point, maybe we convince ourselves that a very very simplified programming language is needed, with graphic blocks and lines to draw and patchcords to hook up. It will look pretty and work like a front panel and allow things to be done. But it will be simplified, rather than easy.   

       Perhaps after using this for a year, the user may tire of it and find themselves shortcutting to the results that it invariably produces and start to tinker there. Or perhaps they stay at that comfortable level but the only other people they find at that level are other people like them. The expertise is not in that domain.   

       Instead, and again, using pseudocode, they may say to themselves:   

       ‘I can see a page on the screen and I want it to be on my USB stick
• Make a button.
•• How do I make a button? Draw a rectangle of a b size at x y coords.
• Make the button know which page I can see.
•• How? I’ve no idea.
• Make the button know where I want things saved.
•• How? Have it pop up a dialogue box and ask me, then save the result as the destination path.
• When I press the button.
•• Something about button events goes here
• Save what I can see.’

       Two things are going on. Well, three if you count learning programming.   

       1: the person is learning programming, painful syntax and all, and what they are primarily learning is how to avoid syntax errors, because they are depressing and stop the program from working and demonstrate that you’ve wasted all morning on something that amounts to nothing. Progress is measured as zero until it becomes 100%.
2: the person clarifies their requirements by breaking it down into pseudocode, step by step.
3: the person realises that there’s a fundamental chasm between being comfortable enough with a programming language to read what others have written, perhaps writing their own modifications without too many syntax errors; and understanding how what they want to do translates into those syntax words and sequences.

       In other words, what I want to do doesn’t pop up in my mind as computer programming language syntax. It never will. Unless I spend all day every day practicing this stuff like a programmer would, which I won’t. So how do I translate what I want done — the achievements in each step — into the way a program language would like it expressed. Not the actual syntax or words, but the processes and hoop-jumping and steps taken. There’s a massive gap in translating the actions required to achieve something. Once you see what someone else had given as an example, and you’ve achieved a certain level of comfort in the language enough to vaguely understand your way through the tutorial example, you understand how it works, but you’d certainly never ever have got there yourself. How did the tutorial author stumble upon the fact that that particular way of doing it is the answer?   

       That’s where the pseudocode libraries come in. Lots of library examples in pseudocode showing how problems are solved, in pseudocode, as procedures or steps or action sequences, none of which are apparent to the ordinary person at first.
Ian Tindale, Nov 21 2010

       What you’ve just said physically jolted me. It caused a very important realisation. Back soon.
Ian Tindale, Nov 21 2010

       The O'Reilly books tend to cover each language/topic from (at least) 3 different angles, you've got 'Leanring X' for people who like to be handheld through the fundamental building blocks, and introduced to the concepts one bit at a time; then you've got 'X in a Nutshell' where all of X is presented in a sort of indexed form with articles thrown in here and there about how a specific area works; and then finally, there's 'The X Cookbook' where lots of examples are provided showing X in a number of practical situations. Not pseudocode, the real thing, in a format that you are expected to pick up, drop into your own system and tweak to your own spec.
zen_tom, Nov 21 2010

       I’ve got Leanring Ruby, Leanring Java, and also up in the attic, Leanring Perl (which I didn’t). They’re very in-depth really. The title doesn’t do it justice. It makes it sound like they’re beginners guides, but far from it, they go a long way.
Ian Tindale, Nov 21 2010

       I promised to return to this, but I’m not ready. However, what’s been going through my head so far has unformed features such as the following:   

       Patterns are a kind of “mid way” between implementation and framework (where framework is essentially an encapsulation of best practice in library form, that often presents itself as a domain specific language).   

       This idea, pseudocode libraries, isn’t patterns, but it sits in the same place (so it sort of pushes patterns over a bit to make room). What it consists of is stories. Archetypes. Basically, fables that encapsulate problems or tasks and how they decompose into solutions.
Ian Tindale, Nov 27 2010

       {Pssst, [FT], it's 'Dijkstra'}
Jinbish, Nov 27 2010

       //Dijkstra// okay that makes more sense.... I was just responding to prufrax calling me a Knuth though.
FlyingToaster, Nov 27 2010

       Could've been worse, he could've kicked you in the Kleitman's.
Jinbish, Nov 28 2010

       Yourdon already ?
FlyingToaster, Dec 01 2010


back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle