To Code, Or Not To Code? That is the question

Some visitors here rudely proclaim I am not a programmer because I eschew “C”. I’ve written a few lines in C, mostly configuring Linux builds or making tiny changes in other codes, but I’ve coded in more than a dozen programming languages over the years, from assembler on many machines to PASCAL, my favourite. It occurred to me that I might have relevant data on my hard drive. Scanning the directories where I generate PASCAL code and where I write web pages and web-applications, I find ~60K lines of code. Back in the day I wrote thousands of lines every year and I have none of that stuff I wrote for IBM 360. Nor do I have the BASIC codes I wrote for my SuperBoard II… I left a 2400 foot magnetic tape at a school in the Arctic as a museum-piece… It had a lot of my scientific computing codes which were written in Fortran. Without a tape-reader, they were rather useless to me. Now FLOSS provides me with a much larger universe of codes and I don’t have to carry them around, thanks to the Internet. So, I code a lot less and I’m certainly not in top form for lack of practice, but yes, I am a coder and will be until I die, I guess. I’ll leave you with one of my pieces in PASCAL, just to annoy the trolls.

This is shuffle, a programme written to randomize a simple list of items. I use it to randomize the order of things on web-pages or parameters to applications such as mplayer. Mplayer has a -shuffle option but others do not.

program shuffle;
uses math;
(*takes a stream of words from command-string and spits out the same words randomly ordered*)
{Copyright Robert Pogson 2016}
{This is Free Software. You can run, examine, modify and distribute it under the terms}
{of the GNU Public Licence Version 3 or Later. See https://www.gnu.org/licenses/gpl.html}
type
p=^leaf;
leaf=
record
x:real;
s:string;
left:p;
right:p
end;
procedure prt(j:p);
begin
if j <> nil then begin prt(j^.left);(*write(j^.x:5:2,’ ‘,j^.s)*) write(j^.s,’ ‘);prt(j^.right) end
end;
var head:leaf;
i,n:longint;
y:real;
q:string;
index,last:p;
f:file of char;
function random():real;
var k:longint;x:real;s:array[0..3] of char absolute k;
begin
{$I-}read(f,s[0],s[1],s[2],s[3]);{$I+}
x:=abs(float(k)/2147483648.0);random:=x
end;
begin
(*use /dev/urandom as the random number generator*)
{$I-}assign(f,’/dev/urandom’);reset(f);{$I+}
n:=paramcount();i:=n;(*writeln(‘paramcount=’,n);*)
if n>0 then
begin
head.x:=0.5;

head.s:=paramstr(i);
(*writeln(head.x:5:3,’ ‘,head.s);*)
head.left:=nil;
head.right:=nil;
dec(i);
while i>0 do
begin
index:=addr(head);last:=index;
y:=random();
(*writeln(‘i=’,i,’ ‘,y,’ ‘,paramstr(i));*)
while index<>nil do
if y< index^.x then begin last:=index;index:=index^.left; if index=nil then begin new(last^.left);last^.left^.left:=nil;last^.left^.right:=nil;last^.left^.x:=y;last^.left^.s:=paramstr(i) end end else begin last:=index;index:=index^.right;if index=nil then begin new(last^.right);last^.right^.left:=nil;last^.right^.right:=nil;last^.right^.x:=y;last^.right^.s:=paramstr(i) end end; dec(i) end; end; index:=addr(head); prt(index); end.

It’s not pretty, but it works, putting things into a tree in random order and then printing the tree on standard output. It should be in every GNU/Linux system but I could not find the likes of it so I wrote my own.
./shuffle dog cat frog walk talk jog in above at winnipeg florida thompson
walk dog above winnipeg cat jog thompson frog florida in at talk

Whether you find it useful or not. I wrote it. It’s mine, but you can use it, examine it, modify and distribute it. You are welcome.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

73 Responses to To Code, Or Not To Code? That is the question

  1. oiaohm wrote, “The pascal version is not going to screw up due to some odd ball char where the one you just did would.”

    To be fair I use a lot of BASH scripts for various purposes and one could use the shuf sequence to accomplish what I wanted but rather than chaining stuff together with pipes, creating a standalone application for the purpose had advantages. It’s faster for one, if I improve the scaling of the sort/search with some better algorithm, and it doesn’t depend on having shuf or any particular version of BASH to work. Perhaps its chief advantage and this was a surprise for me that it greatly annoys the trolls. I can’t imagine why. I should do more programming. I should finish my ballistics programming. Perhaps in the next winter. I decided not to do the long range shooting this summer but upgrading the IT system instead.

  2. oiaohm says:

    Dr Loser
    cat /tmp/fred.txt | shuf –random-source /dev/urandom | tr ‘\n’ ‘ ‘
    Remember how you picked on me going to posix about spaces and other crap causing issues trying to get a solution done.
    Guess what
    It is superior to your Pascal solution, in that it has no dependency outside the shell.
    This is incorrect. The pascal version is not going to screw up due to some odd ball char where the one you just did would. Using bash and pipes is not as straight forwards as it first appears.

    Yes passing ‘test\ntest’ is allowed by the posix command line. Demo by printf ‘test\ntest’ Yes instead of \n you can put a space in a arguement as well.

  3. oiaohm says:

    In 1974, Liskov and Zilles defined a strongly-typed language as one in which “whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function.”
    Sorry
    No it fscking DOES NOT, you fscking MORON, Fifi.
    No you are a F moron. The Liskov and Zilles define is directly based off of Lisp. Notice nothing requires strong typed to be complier. In fact when Liskov and Zilles wrote it they used Lisp runtime model as an example. So the first example of a strong typed language predate the define by 6 years. So if you are reference the first example to strong typed you are always referencing lisp as the term is written to describe Lisp language behaviour.

  4. Dr Loser, quoting facts not in evidence, wrote, “all four of us are far more knowledgeable and professional “coders” on the *nix platform that you have ever been, are now, or can ever hope to be.”

    1. How is that relevant to anything? Have I announced some contest for most “pro” developer?
    2. What on Earth are all you experts doing, wasting time here? Shouldn’t you be out coding some fantastic project in AI or such?
    3. For all we know some of you are teenagers living in your mother’s basement. I’m pretty sure The Wiz was some kind of high-powered system administrator. Perhaps he wasn’t such a good programmer or he made a career change. I’ve programmed on two continents, over decades on a variety of software and hardware platforms. I have learned a thing or two along the way.
  5. Dr Loser says:

    The term strong typing comes from Lisp.

    No it fscking DOES NOT, you fscking MORON, Fifi.

  6. Dr Loser says:

    Oh, and I forgot to mention.

    Do not ever call the likes of the Wiz, or Deaf Spy, or Kurks, or myself, a “Paid M$ shill” or an “astroturfer” or whatever.

    Because, Robert — on your own chosen ground, all four of us are far more knowledgeable and professional “coders” on the *nix platform that you have ever been, are now, or can ever hope to be.

    Saving keystrokes, indeed. You ancient old prat.

  7. Dr Loser says:

    Let’s try again, Robert, shall we? Here’s how you do this, on the Unix shell, using the Unix philosophy. I choose to populate a file called /tmp/fred.txt first. Naturally you can treat a file like anything else in Unix — it’s just a stream of bytes, after all. By design.

    cat /tmp/fred.txt | shuf --random-source /dev/urandom | tr '\n' ' '

    You will notice a few things about this superior solution, Robert.

    * It is superior to your Pascal solution, in that it has no dependency outside the shell.
    * It is minimalist, in terms of key strokes. tr is a whole character less than sed.
    * It utilizes the redirections and piping facilities of the Unix command line to the full.
    * More importantly, and very much unlike your disgusting and wretched and worthless solution, it allows the user to choose their own source of randomness. Command line parameters ftw!
    * This solution, because it depends upon nothing more than the bash shell, is supported by any number of upstream and downstream maintainers. I happened to use CentOS. You are welcome to use Debian, of any flavor. This solution is supported across the board.
    * Your nitwit solution is not supported by anybody but you. And nobody but you would consider it.

    Ah, but, I hear you say. Too many keystrokes! Too much arthritis!

    Seemples!

    Just toss the frickin’ thing into a shell script, optionally with a couple of parameters available (I can show you how to do that. You are apparently too ignorant to cope with that task yourself), and … job done.

    Well, I think I’ve just about had enough of your ludicrous posturing attempts at being half-way adequate as a “code monkey,” Robert. Each and every time you try to defend yourself, you simply sound more pathetic than the last time.

    It’s July 1st, which means it’s time for me to take my customary month-long vacation from your vacuity.

    Happy Canada Day!

  8. oiaohm says:

    The term strong typing comes from Lisp. All early strong typing languages are runtime strong typing not complier dependant to-do type checking. Reason computers 1958 when lisp was from are not that powerful to run though a program type checking everything with the complier.

    Modern Strong typed languages are either Strong typed at complier or Strong typed at complier and runtime.

    https://en.wikipedia.org/wiki/Pascal_%28programming_language%29

    Pascal is not a modern strong typed language but a historic one. So it as runtime type checking with complier type checking on top. The fact that it strong typed is written in the 1969 book about it. The demo Robert gave it classic to the book.

    So of course Pascal strong typed runtime with optional strong typed complier looks different to C# that is a strong typed complier with a possibility of a weak typed runtime. Same way Lisp and C# look different it all about age since the how power computers were when the language was designed defined how strong typing could be implemented.

    The one thing about runtime type checking you have to be very effective on your run-time error handling because that is when you are going to find out you had a type error. So saying a language is strong typed does not give you enough information to know what you are dealing with the words runtime and complier are required.

  9. oiaohm says:

    Still, Robert’s examples hold no water. They don’t demonstrate the benefits of strong-typing. We observe the behavor of the runtime / libraries. Nothing to do with data typing.

    Fifi, don’t get distracted. Don’t try to pick out straws. Go back to writeln(), little one.
    This is not picking at straws. In 1958 Lisp defined what strong runtime data typing was. Robert demonstration is with pascal is exactly what strong runtime typing is meant to-do. Javascript is a weak runtime typing.

    The problem here is you had complete over looked data typing rules is runtime and complier.

    Don’t bother telling me to got back to writeln any more you just showed you don’t know a what a base core concept means.

    Go read the wikipedia page it particular mentions lisp for a reason.
    https://en.wikipedia.org/wiki/Strong_and_weak_typing
    Lisp is a special case where the runtime is 100 percent responsible for the data-typing enforcement heavy lifting. List in 1958 was the first language to demo that strong typing did not have to be a complier feature. So when you start talking about strong and weak typing ignoring the existence of runtime strong and weak typing over looks many key differences.

    You are so wrong, Robert. “Strong typing” has nothing at all to do with “building the runtime and the libraries in.”
    Dr Loser you are wrong and have been wrong since 1958. This is simple forget one of the first strong typed languages Lisp. Where the type enforcement is purely runtime and libraries.

    Dr Loser following Deaf Spy the idiot leads did not help I provided a wikipedia link would have paid to read.

  10. Dr Loser wrote, “you can do the same thing with pipes and sed and shuf”.

    Sure, I can, but I don’t want to. I want to use less typing. That’s a good thing. There’s still the newlines which have to be removed with sed, an extra step. Is it so hard to consider that one wants to arrange stuff on a page in random order and not mess it up with extraneous characters?
    shuf -e a b c d|cat
    d
    c
    a
    b
    pogson@beast:~$ shuffle a b c d
    b d a c

  11. Dr Loser says:

    This is eerily like listening to an enthusiast for the old Texas Instruments TI-59.

    I was deeply impressed by the thing at the time. I, unlike you, Pog, have moved on.

    Mind you, if you want to buy cheap RAM … you can probably get those old mag-strips practically for free!

  12. Dr Loser says:

    Well, I have figured those out. Sure it could have been programmed in BASH but that’s still programming.

    You haven’t figured it out very well.

    First you claim that your feeble and grotesque Pascal program is FLOSS-worthy. Take it from me — it ain’t. The only worthiness it shows is that, in the modern world, you are completely unemployable as a programmer.

    But let’s just stipulate that you are correct and I am wrong. This … thing … is a worthy executable tool to be incorporated into the *nix command line.

    Well then. This means that it’s completely irrelevant — no matter what your ignorant and obtuse earlier claims might be — whether the input is line-oriented or word-orientated.

    I have pointed this out. You have failed to comprehend the obvious.

    And once you accept pipes and sed and any other tools you care to name, including shuf, it becomes very apparent that your “solution” is completely without value.

    In short, Robert, you can do the same thing with pipes and sed and shuf.

    And until you can prove the contrary, I am afraid that your best option when choosing to present yourself as an authority in IT would be:

    Just to shut up, and move on.

    Incidentally, did you know that shuf has a series of command line options? –random-source is one of them. Which removes the last, feeble, argument you might have in favor of your misbegotten abortion. (In which I might point out that your random source was what we day-to-day Computer Literates define as “irredeemably hard-coded.”)

    You really suck at programming, don’t you? Even *nix shell programming, which is about as trivial as it can get.

  13. Dr Loser says:

    That’s irrelevant. The strawman was that typing doesn’t matter. Those examples show clearly that it does.

    WHAT examples, you cretinous old fool?

    And in what way?

    And why should Pascal be held up as the cynosure of all “strongly typed” languages?

    What, for example, is wrong with Haskell in this respect?

  14. Dr Loser says:

    Such ignorance. This is all a consequence of strong typing.

    You are so wrong, Robert. “Strong typing” has nothing at all to do with “building the runtime and the libraries in.”

    You really haven’t been paying any attention at all since that catastrophic point, some twenty years or so ago, when you dropped your laptop on the tarmac and decided to blame everybody else for it, have you?

    I can, on demand, produce a self-contained executable for the platform of your choice, and given the requirement of really quite a lot of “scripting” languages that do not feature strong typing. With libraries and so on included.

    How does Perl grab you, for example? It’s slightly more “strongly typed” than, say, the Bash shell — of which, in re shuf and pipes, you have so far proved yourself woefully ignorant. But, yes, it is quite possible to produce an executable that is programmed in pure Perl.

    You really are an ignorant bloviating ninny dinosaur, aren’t you, Robert?

  15. Deaf Spy wrote, ” We observe the behavor of the runtime / libraries. Nothing to do with data typing.”

    Such ignorance. This is all a consequence of strong typing. The source code of the run-time and libraries can be built at the same time as the compiler. It’s all one code effectively, written in FreePascal.

  16. Deaf Spy says:

    I admit that JS will behave differently. parseInt() will convert the result to 9 and the program will work on happily.

    Still, Robert’s examples hold no water. They don’t demonstrate the benefits of strong-typing. We observe the behavor of the runtime / libraries. Nothing to do with data typing.

    Fifi, don’t get distracted. Don’t try to pick out straws. Go back to writeln(), little one.

  17. oiaohm says:

    Deaf Spy don’t have a clue stating javascript.
    parseInt()
    http://www.w3schools.com/jsref/jsref_parseint.asp
    Roberts example in javascript using parseInt it just ignores everything after the .
    In Pascal, if the input is “9.1”, an error will be flagged.
    This is correct for pascal as Robert said.
    In Javascript if input was 9.1using parseInt() the value would be 9 no error.
    will behave in exactly the same way.
    Deaf Spy it absolutely will not behave in the same way so Deaf Spy is talking out is ass.

    Depending on the C functions used it will either behave like Javascript or will be have like pascal.

  18. Deaf Spy says:

    Those examples show clearly that it does.

    No, they don’t. The same examples in C would behave in exactly the same way. The same examples in JavaScript (using parseInt() or parseFloat()) will behave in exactly the same way.

    You examples fail to prove your point, Robert. Plain and simple.

    P.S.
    Ah, Fifi, did you figure out how writeln() works? No? Then please shut up and don’t pollute the discussion.

  19. Deaf Spy, and others, constantly moving the goalposts wrote, “your example has absolutely nothing to do with strong-typing. It is all about understanding the difference between integer and floating-point numeric types. “

    That’s irrelevant. The strawman was that typing doesn’t matter. Those examples show clearly that it does. Programming languages that are sloppy about typing waste a lot of time and resources and constantly introduce bugs and vulnerabilities. Take C, for instance. Folks upgrade the compiler and they have to “fix” stuff in their code. That’s wrong. That is very rare with a strongly typed language like Pascal.

  20. oiaohm says:

    https://en.wikipedia.org/wiki/Strong_and_weak_typing
    Deaf Spy really you just showed you don’t have a clue.

    Technically pascal is stronger typed than C#.

    Next issue is Strong and Weak typing refer to two things not one.

    You can have a strong typed language at complier stage and weak typed at runtime. Pascal is strong typed at complier and strong typed at runtime.

    Even in your prior concern for NULLs, C# 7.0 would be perhaps the first wide-spread language to address the issue partially.
    One too many Microsoft conferences.

    Lisp that is a classic example of strong typed purely at runtime no complier side required other than recording the information for the runtime to process was really the first to address the issue 1958.

    Please deafspy stop pretending stuff does not exist Pre Microsoft.

  21. Deaf Spy says:

    Robert, your example has absolutely nothing to do with strong-typing. It is all about understanding the difference between integer and floating-point numeric types.

    In your first example, it is the runtime that will raise an error if the input is 9.1, not the compiler. Seems you don’t even understand the difference between compile-type and run-time.

    And keep pretending much more potent languages than Pascal in terms of strong-typing don’t exist. Even in your prior concern for NULLs, C# 7.0 would be perhaps the first wide-spread language to address the issue partially.

    Not to code, for sure.

  22. Wizard Emeritus says:

    “Thanks, Wiz. I couldn’t have stated it nearly as well.”

    You’re welcome. Glad to see that you contribution is down to its usual standard of irrelevancy.

  23. Dr Loser wrote, “that ridiculous assertion of yours that it matters (somehow) whether the input is a string of characters, an integer, or a floating point?”

    This is Comp Sci 101 or earlier.
    Suppose

    var k:integer;
    begin
    readln(k);
    repeat whatever;dec(k) until k=0;

    In Pascal, if the input is “9.1”, an error will be flagged. In the case of

    var k:real;
    begin
    readln(k);
    repeat whatever;k:=k-1 until k=0;

    The loop will not terminate until bad things happen. Strong type-checking matters. Type matters. Surely, you knew such things yet you prattled on as if it was your secret knowledge and unknown by anyone else. The greatest value of strong type-checking is making sure parameter-lists match for calling subprograms. Because of strong type-checking one can debug the called programme and the caller separately yet be sure they will work together. That’s a huge advantage for PASCAL over languages where anything goes, especially when you derive types of some structure passed as a pointer. That makes it so easy to mess things up without requiring matching types. It’s still possible to mess up a pointer but at least a PASCAL compiler reduces the number of ways you can mess it up. That speeds development and makes more reliable software.

  24. luvr says:

    Here are some of the best arguments that our respected Dr Loser uttered in his rantings here:

    You’re a raving nutter, Pog.
    You brain-dead old fart.
    You blithering idiot.
    You ancient old fool.
    You are a simpleton and a worthless hack.
    Worthless delusional pitiful old buffers like you.
    You are both too obdurate and too senile.
    A decrepit old wreck like yourself.

    As the great Wizard Emeritus will gladly confirm, here’s what these utterings mean:

    “So now having no arguments left you start with insults.”

    Thanks, Wiz. I couldn’t have stated it nearly as well.

  25. DrLoser wrote, “if you haven’t yet figured out Unix pipes and regexes and so on over the last sixteen years”.

    Well, I have figured those out. Sure it could have been programmed in BASH but that’s still programming. Why not use PASCAL? I like it better and it works for me. The problem is not one that pipes are necessary or useful. It’s about a simple parameter list and one doesn’t necessarily need to pipe it anywhere, just make it available to the application on the command line. e.g. appb `appa some list` instead of appa some list|appb or pams=$(appa some list);appb $pams. I prefer my notation. It’s more compact and I have some appbs that want the list on the command line, not stdin.

  26. Dr Loser says:

    Just out of interest, Robert, if you haven’t yet figured out Unix pipes and regexes and so on over the last sixteen years … then what exactly haveyou been doing in terms of IT?

    Apart from slowly parboiling frogs, spinning up an inconspicuously different local version of Da Kernel, and wrecking the futures of round about 2000 or so students at Easterville, of course.

  27. Dr Loser says:

    Any further comment on that ridiculous assertion of yours that it matters (somehow) whether the input is a string of characters, an integer, or a floating point?

    If I didn’t already know that you are omniscient and always on the ball, Robert, I would sadly have to conclude that you are totally clueless when it comes to the concept of “type.”

    No matter what the programming language is.

  28. Dr Loser says:

    Well, there’s where you’re going wrong. My little project was not to prepare input for shuf and it wasn’t line-oriented in the least but word-oriented. You should get some sleep.

    And you need new bifocals, apparently, old man. Or perhaps the eyes can process the text, but the brain fails you these days.

    You boasted that your program was worth offering to the wider FLOSS community. It isn’t. It’s wretched. And nobody is going to take the time to download the relevant Pascal compiler, which means that everybody who uses it will use it as a standalone executable.

    Which would be fine. Practically everything that is not built in to the shell in *nix is a standalone executable. And the whole point of this scheme is that you can link the output of one tool to the input of another tool. To quote the original text on the Unix Philosophy … which I’m sure you have been too busy to read, what with having to decipher a Chinese tractorette “manual” …

    (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features.”
    (ii) Expect the output of every program to become the input to another, as yet unknown, program . Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
    ( iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
    (iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

    I think I’ll take the liberty of reversing those wise yet ancient points.
    (iv) “Use tools in preference to unskilled help.” You lose immediately, Robert.
    (iii) You are guilty of premature optimization here, Robert. There are no clumsy parts to shuf, as you would have spotted if you had actually known about it in the first place, which you clearly did not. Consequently there is no need to rebuild it.
    (ii) Your purulent effort passes on this one. It could hardly be otherwise. I shall demolish the concept of added value, based on this, lower down.
    (i) You might pass on this one, Robert. See below, also. But since you provide no evidence (unit tests, etc) that your program does “one thing well,” there is no evidence that it passes the “does well” test.

    Inherent in this description of the *nix philosophy, Robert, is the principle of “structural agnosticism.” (As long as we’re dealing with ASCII-7, of course. Let’s assume we’re dealing with ASCII-7.) Both stdin and stdout — and for that matter, stderr, which I have occasionally seen being monstrously abused, but it’s wide open to that, hem hem ampersand 2 redirect — rely on this property.

    Thanks to structural agnosticism, it doesn’t actually matter whether the input is line-based or stream-based. Or whether it comes in any other form whatsoever, provided that the structural form in question consists of a series of “words,” which in turn can be formally described via a simple regex, separated by a series of whitespace, which, well, ditto.

    The way that any command-line works with this, Robert, and sadly you don’t quite seem to grok the concept, even after sixteen years, is not “magic.” It’s simply the serialized connection of the stdout of one tool with the stdin of another.

    Enough academic theory, you may cry. So what about the two realities? Here we go then.

    The Pascal abortion?

    * User input pipes to Pascal abortion pipes to command line output. Triffic! But what if the user input is derived from a file? Easy.

    * User input pipes to sed, which strips off the line terminators, which pipes to the Pascal abortion, which pipes to command line output.

    So much easier than the shuf version, eh? Except, not. Here are the equivalents.

    * User input pipes to sed, which adds in the line terminators, which pipes to shuf, which pipes to command line output. But what if the input is derived from a file? Easy!

    * User input pipes to shuf, which pipes to sed, which strips off the line terminators, and pipes to command line output.

    Works either way, Robert. And for Fifi’s benefit, I understand entirely that I have elided the distinction between Unix shell pipes and Unix shell redirection. The distinction is insignificant.

    Insignificant? Pretty much what you have been for the last sixteen years, Robert, if you haven’t yet quite got to grips with this stuff.

    It’s ridiculously outdated, but you’re never going to move on until you fully understand how software tech from the 1980s works, are you?

    I can follow up with a discussion of command-line options and arguments, if you want to feel even more miserable about your nitwit effort.

  29. Deaf Spy wrote, “You don’t even need a debugger, because, hm, you can’t even configure it to debug your application.”

    Mostly, I don’t need a debugger because if it compiles it runs thanks to strong type-checking and readability.

    So, yes, I can configure a debugger for Pascal programmes.

  30. Deaf Spy says:

    That is why people invented garbage collection, Robert. Unfortunately, Pascal is not invited to the party. The closest thing to automatic MM Pascal has is reference counting, available only for interfaces (got it because of COM, actually), and ugly as hell.

    Pascal is obsolete in any way possible. Strong-typing – C# is better. MM – GC-languages are better. Closures and generics – too little, too late, C# and Java are better. Functional features – basically zero.

    But hey, who needs these? You don’t even need a debugger, because, hm, you can’t even configure it to debug your application.

  31. joepf wrote, “If you are confused with pointers”.

    I am not confused with pointers but the compiler has no way to detect “use after free” and pointing to the wrong thing.

  32. joepf says:

    I will speak words of wisdom to you, Mr. Pogson. Write in C

  33. joepf says:

    If you are confused with pointers, you need some pointers for programming, they are not hard to understand. No offense, your program to shuffle words is cringeworthy. It does not take many lines to swap command line arguments randomly and print them out in a loop. Your variable naming is bad too.

  34. Dr Loser, having lost it, wrote, “the horribly difficult task of taking a stream of whitespace-separated tokens and converting them into the line-separated input expected by shuf”.

    Well, there’s where you’re going wrong. My little project was not to prepare input for shuf and it wasn’t line-oriented in the least but word-oriented. You should get some sleep.

  35. Dr Loser wrote, “What happened to your thrilling, although unfortunately as yet unexamined, defense of Pascal’s type safety”.

    Even Linus appreciates Pascal: “If I wanted a language that didn’t allow me to do anything wrong, I’d be using Pascal.”
    Amen. I do want a language that won’t allow me to do anything wrong. Of course that doesn’t exist, but Pascal comes closer than C by several miles. One can still mess up pointers or the terminal condition of a loop in Pascal. Pascal prevents obvious errors in syntax not errors in logic.

  36. Dr Loser wrote, of sed, “I believe it will do the job for you.”

    Yes it will. I wrote that already. Why are you repeating that information as if you knew something I did not? I’ve been using sed for ages to massage information.

  37. Dr Loser says:

    I hate to watch (in a theoretical sense, obviously) a decrepit old wreck like yourself struggle over the horribly difficult task of taking a stream of whitespace-separated tokens and converting them into the line-separated input expected by shuf, Robert.

    In fact, I make it a point of etiquette not to torture the old and halfway insane for longer than a couple of giggles or so. And I only giggle in private, so you have no need to be embarrassed by your very understandable failure here. What with you probably not having used the Bash shell for a week or so.

    Here’s a useful little tool that you may not have heard of, Robert: sed.

    I believe it will do the job for you.

    Oh, there’s this modern concept in the *nix shell called “pipes.” I encourage you to look “pipes” up. They are trifficly useful in these circumstances.

  38. Dr Loser says:

    Did you intentionally set out to prove yourself a fool when you started this thread, Robert?

    Or was it just a hilarious, yet inevitable, result of day to day IT reality catching up with you after all these years?

  39. Dr Loser says:

    What happened to your thrilling, although unfortunately as yet unexamined, defense of Pascal’s type safety, Robert?

    Admit it. Type safety is a complete red herring in this trivial little nonce of a student-level problem.

  40. Dr Loser says:

    shuf is close to what I want but it’s line-oriented.

    I’m sure you can see the fairly simple solution to this minor problem, Robert. Well, actually, I’m not at all sure. In fact, I don’t believe you can at all.

    Let me assist you with a little bit of (free! As in no money changes hands!) Senior Citizen education.

    1) No Pascal. What a stupid idea that was.
    2) Bash. People — well, you — profess to love Bash.
    3) Map “lines” into “array of words.”
    4) Use shuf.

    Regrettably, I had to repeat the cite for shuf, Robert. Because the evidence so far on this thread is that you are both too obdurate and too senile to go back and work out how to produce a proper solution using shuf.

    It’s all downhill from here, isn’t it, old man?

  41. Dr Loser says:

    There are debuggers available in PASCAL. There’s a specialized one built into the IDE and general ones used in GNU/Linux. I’ve used them a few times long ago. I don’t feel any need to use them lately so I don’t.

    Goodness knows what use a debugger would do you in this instance, you ancient old fool.

    Have you tried writing “unit tests?” They’re quite the rage in these post-Edwardian days. Oh, and if I (or anybody else) chooses to pluck a FLOSS gem off the Intertubes, we would expect such gem to be accompanied by Unit Tests in much the same way as your rancid little piece of Pascal is not. No FLOSS Soup For You!

    Perl does it. Python does it. Ruby does it. JavaScript does it. Hell, Robert, everybody does it … other than you.

    “One man, closing all the windows to reality…” A very fitting slogan you chose there, Robert. You’re not a “coder.” You have never been a “coder.” In “coder” terms, you are a simpleton and a worthless hack.

    I’m going to repeat this. I am not making a personal point. I am simply considering your “solution” on its own “merits.”

    If a guy/gal/bonobo turned up to an interview and offered me this “coding” as evidence of expertise, I would cut the interview short after twenty minutes.

    It would have been twenty seconds, but I don’t like to crush the aspirations of people … even when they are clearly worthless delusional pitiful old buffers like you, Robert.

  42. Wizard Emeritus says:

    “I don’t write software to please you, Wiz. ”

    REally? Yet you wrote

    “So, I code a lot less and I’m certainly not in top form for lack of practice, but yes, I am a coder and will be until I die, I guess. I’ll leave you with one of my pieces in PASCAL, just to annoy the trolls.”

    That sure sounds like you are an attempting to “please us” by “proving” that you know how to code in your chosen language.

    “It’s not a mess at all. It works very well for what it was intended to do.”

    How would anyone know . You are ostensibly presenting code that performs a function for any to add to their system. Your donation is not only lacking comments but all run together – which making no attempts at using space for readability.

    Very few people would consider such a slapdash presentation as anything other than a mess, and an untrustworthy one at that.

    “PS Ugliness is in the eye of the beholder.”

    That is absolutely true Robert Pogson! And in the eyes of this and I suspect other beholders who have any clue about what writing good code in any language. Your presentation is a mess as to be rejected out of hand

  43. Deaf Spy says:

    Typically, when I write software, I will write out values to confirm my understanding of the state of things so that the next code I generate will work. That’s nothing to do with debugging.

    Debugging is just one use of writelns. They do help internally document the software by showing values and sequences.

    At runtime. Which is exactly a function of debugging. Internal documentation, Robert, is done by using:
    1. Easier-to-read, self-documented code.
    2. Comments.

    Typically, when I write software, I will write out values to confirm my understanding of the state of things so that the next code I generate will work. That’s nothing to do with debugging.

    This is just what debugging is all about. Understanding what got wrong, so that you can improve it.

    Case is clear. Robert can’t debug a console app the input of which is the command line, using the tools there are to be had in Linux. To hide his shame, he claims he is not debugging by coming up with some twisted definition of the term.

    Robert, it is gibberish like this which reveals you are no programmer at all. The code does it, too, but to a lesser extent. But keep spilling utter non-sense, and you show yourself as total ignoramus in the area. You are not a programmer. You are simply a person who can fetch together a few lines of code to get some job done in a dirty and inefficient way. The same that happened with your Chinese tractor. You fixed it, on expense of many hours, and got lousy results, which a professional mechanic would best any day.

    Nothing bad with that. Indeed. Just admit it and don’t pretend to be competent in areas you are actually rather amateurish in.

  44. The Wiz wrote, “I don’t understand how you can present such a shabby mess as representative of what you are capable of programming Robert Pogson”.

    I don’t write software to please you, Wiz. I have not claimed that this snippet is representative at all, just recent stuff. It’s not a mess at all. It works very well for what it was intended to do. If I wanted it scalable and for general purpose, it would have some obvious optimizations and/or changes in structure but the basic concept is good. Sometimes you need stuff in an order different from collation and randomization is one choice. I could order by date or size too.

    PS Ugliness is in the eye of the beholder.

  45. Deaf Spy wrote, “a handful of writeln’s with clearly debugging purposes”.

    Debugging is just one use of writelns. They do help internally document the software by showing values and sequences. Typically, when I write software, I will write out values to confirm my understanding of the state of things so that the next code I generate will work. That’s nothing to do with debugging.

    There are debuggers available in PASCAL. There’s a specialized one built into the IDE and general ones used in GNU/Linux. I’ve used them a few times long ago. I don’t feel any need to use them lately so I don’t.

  46. Wizard Emeritus says:

    I don’t understand how you can present such a shabby mess as representative of what you are capable of programming Robert Pogson.

    Have you no pride?

  47. Deaf Spy says:

    Pascal programmes do what I say and what I want. I can read.

    Somehow I feel this simple line of text is deserving some attention. Let’s analyze it sentence by sentence.

    Don’t need one.

    Robert: I don’t have one, or I can’t get it to debug a console app, which requires command-line input. Damn, that is why I will sprinkle my code with writeln’s to see what goes wrong. Of course, I will comment them out once I’m done debugging my code.

    Pascal programmes do what I say and what I want.

    Somehow programmes, written in Pascal, have the unique ability to understand human speech and follow human instructions precisely. Pity all other programming languages do not have these wonderous features!

    I can read.

    This is purely puzzling. Readers, already dazzled by those magical abilities of Pascal programmes, are left to ponder how reading skills compensate the lack of a debugger, but require a handful of writeln’s with clearly debugging purposes.

  48. Deaf Spy wrote, “Robert, don’t you have a debugger?”

    Don’t need one. Pascal programmes do what I say and what I want. I can read.

  49. Deaf Spy says:

    (*writeln(‘paramcount=’,n);*)
    Robert, don’t you have a debugger?

  50. Dr Loser wrote, “let me help you out, you brain-dead old fart”.

    shuf is close to what I want but it’s line-oriented. I want permutations of character strings. shuf works in many places but shuffle works in others.
    e.g.
    shuf -e a b c d e f g
    e
    g
    c
    b
    a
    f
    d
    pogson@beast:~$ shuffle2 a b c d e f g
    a c d e f g b

    Of course, I could use shuf by just removing new lines, but then I wouldn’t have the fun of programming it. The man page points out that shuf can be pointed to a source of randomness so it’s probably better than some of the shuffling done in various programmes I’ve used.

  51. Dr Loser says:

    I hate to milk your utter stupidity, Robert, but these things nag at me.

    You can’t always get the same result using an integer or a floating point value in an expression so type matters.

    Well then. Let’s assume that you can somehow genericize that bit of Pascal to deal with parametric types. (I don’t think you can, but let’s please make that assumption.)

    A set of strings, space-delimited. A set of integers, space-delimited. A set of floating points, space-delimited. Let’s expand our horizons here. And for now we shall limit ourselves to homogeneous types, although I suspect we can extend the exercise through simple inference on the axioms.

    Tell me, Robert.

    Is there a good reason to “get the same result?”

    What with the whole purpose being randomization, and all?

    You haven’t really thought a single part of this futile exercise through in any way at all, have you?

  52. Dr Loser says:

    Some good has come of your idiocy, however, Robert. I now have the perfect telephone interview question to weed out the obviously thorough-going incompetents before I have to deal with them, face to face:

    “Using Pascal, how would you randomly permute a space-separated set of strings on the Linux command line?”

    If they come up with anything like your abortion, they fail. Cost/benefit about as good as it gets.

    Rather sadly, I shall have to retire my previous discriminant:

    “Do you now, or have you ever, slowly parboiled a frog?”

  53. Dr Loser says:

    You can’t always get the same result using an integer or a floating point value in an expression so type matters.

    It’s a sequence of space-separated strings, you blithering idiot. No integers. No floating points. As a matter of fact, and without checking, you only allow spaces (possibly whitespace) as a separator.

    Which is a profound weakness when dealing with piping input through the command line. See, for example, Awk, which does this stuff better.

  54. Dr Loser says:

    Prepending random bits to file names?

    You’re a raving nutter, Pog. In what possible universe would that be appropriate or in any way useful?

    Here, let me help you out, you brain-dead old fart.

    The man page for Linux shuf.

  55. Dr Loser, not comprehending “type” in programming, wrote, “perhaps you might deign to explain how “strong type checking” is relevant”

    You can’t always get the same result using an integer or a floating point value in an expression so type matters. I want to control it and not have the compiler fill in the blanks randomly and subject to change.

  56. Dr Loser says:

    And perhaps you might deign to explain how “strong type checking” is relevant to a series of space-separated strings on the stdin of a command line, Robert?

    It isn’t, is it?

  57. Dr Loser says:

    No use case then, Robert? Quelle surprise.

    I can think of several ways of doing it in BASH, like prepending random bits to file-names and using wildcards, putting filenames into arrays and generating random indices etc.

    A single example would do, O Programming Genius of the Wilderness. I’m sure it will be equally as contorted, and equally as useless.

    OTOH, I can do it the way I want, with PASCAL

    Which is thoroughly useless for everybody else. Your basic mantra, really, Why give back when you can sun yourself in your own inadequate technical reflection?

    rather nicely with strong type-checking and diagnostics and an optimizing compiler…

    Just one moment there, Robert. Hold up.

    What possible purpose could an optimizing compiler, let alone the rest, serve for this utterly despicable piece of syntactic gibberish that you have served up?

    Pray tell. How do those otherwise lost microseconds count?

    Considering that the pustulous little thing has no use case to answer in the first place, my theory is — not at all.

  58. Dr Loser says:

    To quote page 175 of The Unix Hater’s Handbook, Robert:

    Here’s what Kernighan and Mashey have to say about it in their seminal
    article, “The Unix Programming Environment:”
    One of the most productive aspects of the Unix environment is its provision of a rich set of small, generally useful programs —tools— for helping with day-to-day programming tasks. The programs shown below are among the more useful … For example,
    wc *.c
    counts a set of C source files …

    These are “among the most useful”?!?!
    Yep. That’s what much of this programmer’s work consists of. In fact, today I spent so much time counting my C files that I didn’t really have time to do anything else. I think I’ll go count them again.

    I used to laugh at that, Robert. I couldn’t conceive of a more useless, bombastic, tool than wc.

    But the scales have dropped from my eyes.

    You, Robert, have produced a far more fantastically useless tool than wc.

    You ole genius, you.

  59. Dr Loser, repeating himself, wrote, “The simple documentation of a use-case will suffice.
     
    In return for your beneficence on that use case, I promise to show you a more generally useful way of doing it in Bash.”

    I’ve already given the example, randomizing the order of files in some process. Of course, there must be a way of doing it in BASH but it’s not handy in one of the GNU utilities or anything I can readily find on Beast so I wrote one in Pascal. Don’t bother writing something in BASH if it will take you away from your love of TOOS.

    I can think of several ways of doing it in BASH, like prepending random bits to file-names and using wildcards, putting filenames into arrays and generating random indices etc. OTOH, I can do it the way I want, with PASCAL, rather nicely with strong type-checking and diagnostics and an optimizing compiler… Also, BASH is rather C-like and I hate the looping constructs and so forth. I do like pipes, however.

  60. Dr Loser says:

    I could do it in one line too, because of Pascal’s syntax.

    I don’t think semi-colons really count, Robert. Your little excrescense was nasty and useless enough at it was.

    Tell me, just out of interest. Why not just program it in Bash? Rather more generically useful and understandable, considering that all it does it to map one set of inputs on the command line to another one. Bit of a shame that there are plenty of other similar freely available solutions out there, but who knows? You might catch somebody’s interest.

    Open up an account on GitHub and give it a go, Robert.

    Oh, and one small other question that has nagged at me.

    What sort of brain-dead moron would find this functionality useful, Robert?

    The simple documentation of a use-case will suffice.

    In return for your beneficence on that use case, I promise to show you a more generally useful way of doing it in Bash.

  61. joncr wrote, “Pascal or C or whatever is just how we write it down.”

    True. These are both general-purpose programming languages and are mostly limited by what the hardware allows. I prefer Pascal over C simply because the language is more compact and I don’t have to choose this or that feature of the language to express myself. Still there are enough choices in Pascal: RAM or storage, linked lists or arrays, real or longint, … I also prefer really strongly typed languages so that I’m sure I know what the programme will do at run-time.

  62. joncr says:

    Choice of language is highly related to how each of us think. We are much better off using languages that allow us to express ourselves fluently and easily, rather than feeling compelled to use something becausr it is au courant.

    In any case, as in all creative efforts, *real* programming happens in our heads. Pascal or C or whatever is just how we write it down.

  63. Dr Loser wrote, “I am fully aware that I could program the same shuffling in about ten lines or less.”

    I had no objective to do it in as few lines as possible. I’m retired. Programming is fun for me. If I wanted to do it in fewer lines, I’d probably just hash and sort the entries or such. I could do it in one line too, because of Pascal’s syntax.

  64. DrLoser wrote, “it’s nothing to do with the language itself. It’s to do with the libraries, and the inept misuse of such.
     
    Or, to put it another way, this program doesn’t actually do what it claims to do.”

    Silly. The thing doesn’t use any libraries outside of Free Pascal. /dev/urandom is a part of Linux, well documented. It takes some entropy from the system and generates a stream of random bytes. It does work:
    ./shuffle a b c d e f g h i j k l m n o p
    n m g l k b o a p h c j f e d i
    ./shuffle a b c d e f g h i j k l m n o p
    o e i m c h a n l p g f b j k d

    Now, DrLoser may wish it did not exist or that it did something different but that’s his/her problem.

  65. Dr Loser says:

    Amongst other things, there is one tiny little problem with this extraordinarily verbose and utterly worthless snippet of programming cluelessness.

    Can you spot what it is, boys and girls?

    Clue: it’s nothing to do with the language itself. It’s to do with the libraries, and the inept misuse of such.

    Or, to put it another way, this program doesn’t actually do what it claims to do.

  66. Dr Loser says:

    Mission accomplished, apparently.

    Never annoyed when I’m laughing my arse off at ineptitude, Luvr.

  67. luvr says:

    “I’ll leave you with one of my pieces in PASCAL, just to annoy the trolls.”

    Mission accomplished, apparently. 🙂

  68. wizard emeritus says:

    Scratch your itch type programs that is…

  69. wizard emeritus says:

    “Why?”

    Considering the myriad of semi useless scratch your itch that have accretion like barnacles in the Linux toolspace, why not.

  70. Dr Loser says:

    Oh, and why not use Ruby or Python or Perl?

    I pick those languages, not in preference to C++ or Scala or even C#, Robert, but because I am fully aware that I could program the same shuffling in about ten lines or less.

    And it would be more intelligible and maintainable than that horrific mess that you have just concocted.

  71. Dr Loser says:

    It should be in every GNU/Linux system…

    Why?

  72. Dr Loser says:

    I’ll give you a simple opportunity at redemption, though. And I’ll let you do this in your favored language.

    Write us a recursive program in Pascal that uses pattern-matching.

    Not too difficult a challenge, I think.

  73. Dr Loser says:

    Some visitors here rudely proclaim I am not a programmer because I eschew “C”. I’ve written a few lines in C, mostly configuring Linux builds or making tiny changes in other codes, but I’ve coded in more than a dozen programming languages over the years, from assembler on many machines to PASCAL, my favourite.

    Rude or not, Robert, you are not a programmer. Perhaps you were, in simpler times, but you are not one now.

    Multi-threading? Socket programming? Object-relational programming? Sophisticated libraries?

    You’re not a programmer.

    The most remarkable thing of all, Robert, is that you have spent the last fifteen years or so despising C and proclaiming that you would rather program in Pascal.

    And you’ve spent the last fifteen years telling anybody that will listen that the OS of the future, complete with drivers and user hinterland and (gulp) GUIs, is an operating system that is preponderantly programmed in C.

    You might, I suppose, still qualify as a “programmer,” Robert. The reason that I use those scare quotes is that you have not yet qualified, and I suspect never will “qualify,” as a useful programmer.

    I don’t wish to discourage you, Robert.

    Carry on being useless.

Leave a Reply