I dont get it... Why is everyone from science schools so obsessed with Perl and Python when we got C?

[DavidS]

Pointers are the most natural element of programming.

Hi David, yes, you're right that pointers make it possible to write some beautiful efficient and elegant algorithms, mainly because they help in not having to move data around.

But!

Pointers are hard to grok for some people, and easy to shoot oneself in the foot with if one is not careful.

Programming with pointers is a craftmanship that needs more time and attention than writing in a language that cleans up automatically the stuff that is left behind (namely, the objects and data that are no longer referenced). Time and attention that many people nowadays don't have anymore, or are unwilling to spend.

Fair points. I must admit I did not know that poitners really are difficult for some people to understand. Though I have been playing with them since I was a child (having come up through the 1980's, ebeing born int the later half of the 1970's), so my perspective is a bit skewed.

[DavidS]

DavidS,

So it is that one of the arguments in favor of Python is that it is as simple as Basic while being more capable than Basic.

Python is far more capable than any language with "BASIC" in it's name that I have seen.

sitting back giggling at the conversation.
...
And now the arguments are that if you wish to use pointers you should not be using Python?

I think it's rude to be giggling at us.

It's also not a wise thing to do given that you are displaying a level of ignorance and misunderstanding that could cause us to rupture a gut laughing at you.
... ...

And then you go on to provide a very limited case example.

If you want to be to the point, then show accessing many different data structures in one area of code from a single pointer (as is very easy in BBC BASIC, and doable in C), without using any other variables.

[Heater]

jahboater,

(unless you are allergic to pre-processors because Javascript doesn't have one ).

Hah!

JS has no pre-processor because JS is it's own pre-processor if I want it to be

For example TypeScript pre-processes JS. Babel preprocesses JS, etc. They are written in JS.

I'm don't like the C pre-processor much and excessive use of macros because it's a crude and ugly hack bodge.

[jahboater]

I'm don't like the C pre-processor much and excessive use of macros because it's a crude and ugly hack bodge.

Fair enough.

I just stick this in a common header file and forget about it.

Code: Select all

/*
 *  C extensions.
 */
#define repeat for(;;)
#define elif else if
#define aligned _Alignas(16)
#define noreturn _Noreturn void
enum { no, yes };  // bool

I definately think the "repeat" one makes code more readable, but then I hate infinite loops with random jumps out of the middle! I agree with Hippy here.

[DavidS]

I'm don't like the C pre-processor much and excessive use of macros because it's a crude and ugly hack bodge.

Fair enough.

I just stick this in a common header file and forget about it.

Code: Select all

/*
 *  C extensions.
 */
#define repeat for(;;)
#define elif else if
#define aligned _Alignas(16)
#define noreturn _Noreturn void
enum { no, yes };  // bool

I definately think the repeat one makes code more readable, but then I hate infinite loops with random jumps out of the middle! I agree with Hippy here.

+1 on the dislike of infinite loops where unneeded. Though if programming for the X Windowing System, Win16, Win32, Macintosh System Software, DR-GEM, or most other Windowing Systems at least one infinite loop is needed (without any break [until the program is done running]). In all of these cases messages from other programs as well as about mouse/keyboard input are given as the reply to a poll call that is part of the infinite loop that orchestrates everything.

It is interesting that in most Windowing Systems using a poll loop for this saves us a lot in CPU time, as we normally specify flags to the poll call of the system in question in a way that it either does not return until an event happens, or it waits at least a certain period of time before returning. This gives us a form of extended control over saving processor time even in some Preemptive Multitasking systems, and even more in Cooperative Multitasking systems. I guess that a feature of Cooperative Multitasking that carries over the Windowing Systems on Preemptive Multitasking systems turns out to be a huge advantage in task management .

[Heater]

DavidS,

I must admit I did not know that poitners really are difficult for some people to understand.

Pointers are not difficult for anyone to understand.

Using them correctly in non-trivial programs turns to be almost impossible. They have been the source of millions of bugs in all kind of code since forever. Especially where large teams are involved and code passes though many hands in it's life span. And that is in code written my skilled, experienced, intelligent programmers.

For this reason so much effort has been put into the "sanitizer" tools you now find in Clang/LLVM and GCC.

Just have a look though all the security vulnerabilities reported on all kind of projects to understand what I'm talking about.

And then you go on to provide a very limited case example.

What is wrong with that. It a short an sweet example to demonstrate the point. As examples should be. The idea there is easily expandable to whatever size of program and complexity you like.

If you want to be to the point, then show accessing many different data structures in one area of code from a single pointer (as is very easy in BBC BASIC, and doable in C), without using any other variables.

You mean like this:

Code: Select all

let data0 = {
    x: 50,
    y: 60
}

let data1 = {
    t: "Hello",
    u: "world"
}

let node2 = {
    a: [1, 2, 3, 4],
    b: 99.2
}

myPointer = data0
console.log(myPointer.x)

pointer = data1
console.log(myPointer.u)

pointer = data2
console.log(myPointer.a)

Of course what you want to do there is very bad programming practice. Using the same name to refer to very different types of things.

In C/C++ that sort of thing requires type casts which brings us to that world of bugs cause by mistakes using pointers. When you type cast pointer you are disabling the compilers ability of warning you of buggy situations. These bugs can be hard to spot and hard to debug.

[ejolson]

His suggestion goes something like this: ...

Thanks for providing the explanation.

I'm not sure I agree entirely, but I will admit I have done the following -

Code: Select all

done = False
while not done:
   if ...
   else:
      done = True

which is almost the same, and I'll use "repeat" as the variable and opposite logic when that makes more sense. I guess I just don't like "break' commands and their ilk.

All these loop constructs are serial in their semantics: Difficult for a compiler to vectorise and not easily translated to an explicit parallel loop.

Given the fact that maximum clock speeds have remained constant for the last 15 years and the hidden parallelism of wide pipelines with speculative execution have security implications, until quantum computing becomes personal the only thing left is a large number of cores. On modest desktop computers the core count is now 8, on upscale desktops 16 to 32 and on servers 32 to 64. As a result, it is silly to be promoting non-parallel loop structures in the name of performance. Simplicity is a different matter, but that is not how I understand the goal of the video or present thread.

[Heater]

jahboater,

Actually I quite like your endless loop macro. It's simple, direct and obvious. I would be inclined to call it "forever" though.

As for the business of random jumps out of loops, that is why there is a step 6 in the plan. When you have nailed down your algorithm then it's time to think about improving the clarity of your code in the loop constructs and adjust accordingly.

[jahboater]

Actually I quite like your endless loop macro. It's simple, direct and obvious. I would be inclined to call it "forever" though.

Yes I like "forever" too, I only called it "repeat" because I was used to that in B - shows my age

[Heater]

ejolson,

I'm totally with you on the parallelism thing. When it comes to vectorizing things or distributing work over cores like OpenMP, then the compilers need all the help they can get. Then you no doubt need sensible for loops iterating over arrays and such.

However, a lot of code is not amenable to parallelization. I can't see how one would parallelize the lexing or parsing of a source file for example. Which is the kind of thing a of of code does, even if the input data is not text.

[Heater]

jahboater,

Hey, what? I'm not sure I have ever spoken to anyone that has used B in anger. Your street cred has just shot through the roof

[ejolson]

DavidS,

I must admit I did not know that poitners really are difficult for some people to understand.

Pointers are not difficult for anyone to understand.

Using them correctly in non-trivial programs turns to be almost impossible.

Are pointers used in the Linux kernel?

Compare the statement "fractions are easy to understand but adding then correctly is almost impossible" to the statement "pointers are easy to understand but using them correctly is almost impossible." From a school examination point of view, if you cannot use something correctly then you haven't understood it. As a teacher, my conclusion is that both pointers and fractions are, in fact, difficult to understand.

A possible solution is to do away with fractions altogether. Since rational and irrational numbers can be characterized by repeating, terminating and non-repeating decimal expansions, one might claim those troublesome fractions aren't needed anyway. However, if one hasn't learned fractions in grade school, then university-level algebra including abstract quotient fields, Galois extensions and even the ancient Chinese remainder theorem really are impossible.

A similar solution is to do away with pointers. They aren't needed for shopping carts, payroll or finding anagrams anyway. However, if a beginner doesn't learn about pointers, memory addresses and memory management in the beginning, it later becomes difficult to understand a memory leak in a Basic interpreter and impossible to work on kernel code.

As with many difficult things, it is likely best to start learning about pointers as soon as possible to increase the chance of mastering them. Then the statement "fractions are impossible to use correctly" will no longer be true and the economy will prosper.

[ejolson]

However, a lot of code is not amenable to parallelization. I can't see how one would parallelize the lexing or parsing of a source file for example. Which is the kind of thing a of of code does, even if the input data is not text.

Almost by definition parsing a context-free grammar should be amenable to parallelization. Since make -j4 works so well, I suspect most people haven't bothered parallelizing the parser itself.

Maybe an easier example would be a parallel program that parses the spelling dictionary and catalogues which words are anagrams of the others.

[Heater]

ejolson,

Are pointers used in the Linux kernel?

I do believe they are. Lots of them.

And errors in using pointers are also a huge source of bugs and security vulnerabilities in the Linux kernel. There is a lot of work going on to analyse the code for them and root them out.

See for example:
"Does making the kernel harder make making the kernel harder?": https://www.youtube.com/watch?v=Gtjy7pWjW9M
and
"Making C Less Dangerous in the Linux kernel": https://www.youtube.com/watch?v=FY9SbqTO5GQ

Compare the statement "fractions are easy to understand but adding then correctly is almost impossible" to the statement "pointers are easy to understand but using them correctly is almost impossible."

Exactly. They compare vary well.

Fractions may well be easy to understand, but you can be sure that if you are working adding hundreds of fractions with thousands of digits in their dividends and divisors, in your head, you will make mistakes.

And so it goes with pointers in large code bases and large teams.

[Heater]

ejolson,

Almost by definition parsing a context-free grammar should be amenable to parallelization.

I'd have to brush up on my Chompsky before I understand what you are saying there. The use "Almost" and "should" is a bit of a cop out there.

But what about a typical source file from a language like C or C++?

I could attempt to lex and/or parse that in parallel over N threads/cores by chopping the file into N parts and feeding each part to a thread. That is clearly not going to work out.

But C like languages have basic building blocks, the functions, we could try chopping the file into N chunks with a single function each. That might work better.

But wait, we had to lex and/or parse the file serially in the first place to find those functions to extract into chunks.

I don't see how this is going to work.

[ejolson]

2.5seconds 'on your pc' means nothing, other than to you.

How does it run on you RaspberryPi (and model of course to compare)?

I currently don't own RasperryPI. I got a PINE64 ROCK64 board that I can use for testing, it should give some info about performance. Stay tuned...

To understand how your results compare with a real Pi, would you mind running my pichart program available here and reporting the output either here or in that thread?

[rpdom]

jahboater,

Hey, what? I'm not sure I have ever spoken to anyone that has used B in anger. Your street cred has just shot through the roof

I've written production code in B. Can't remember any of it now.

[jalih]

I have never understood why languages where that's considered fundamentally useful don't have 'forever { ... }' or 'do { ... } forever' constructs built-in, that there's no standard way of specifying such things, programmers being left to their own implementations of the same.

PL/I supports:

Code: Select all

do forever;
  /* do stuff */
end;

Of course it works the same as:

Code: Select all

do while('1'b);
  /* do stuff */
end;

[jalih]

To understand how your results compare with a real Pi, would you mind running my pichart program available here and reporting the output either here or in that thread?

I currently don't have dev tools installed except 8th. I installed gcc, make and build-essentials. When I tried to build with make, I get:

Code: Select all

pichart.h:4:22: fatal error: sys/time.h: Tiedostoa tai hakemistoa ei ole
 #include <sys/time.h>

What more do I need to install or configure to be able to build?

[hippy]

Fractions may well be easy to understand, but you can be sure that if you are working adding hundreds of fractions with thousands of digits in their dividends and divisors, in your head, you will make mistakes.

Most people cannot divide 99 by 2 in their heads.

Give the answer as 45.5

[PeterO]

Fractions may well be easy to understand, but you can be sure that if you are working adding hundreds of fractions with thousands of digits in their dividends and divisors, in your head, you will make mistakes.

Most people cannot divide 99 by 2 in their heads.

Give the answer as 45.5

Neither can you !
PeterO

[zwieblum]

Nothing beats the beauty of goto in these cases:

Code: Select all

loop:
	do_something();
	goto loop;

[Paeryn]

Most people cannot divide 99 by 2 in their heads.

Give the answer as 45.5

Neither can you !
PeterO

I think hippy was saying that most people give the answer 45.5, not that he thought the answer was 45.5. I take it those "most" people don't work it out as 100÷2 - 0.5, much easier to do.

[DougieLawson]

I take it those "most" people don't work it out as 100÷2 - 0.5, much easier to do.

I mustn't be one of "most" people as that's precisely how I was taught.

[ejolson]

To understand how your results compare with a real Pi, would you mind running my pichart program available here and reporting the output either here or in that thread?

I currently don't have dev tools installed except 8th. I installed gcc, make and build-essentials. When I tried to build with make, I get:

Code: Select all

pichart.h:4:22: fatal error: sys/time.h: Tiedostoa tai hakemistoa ei ole
 #include <sys/time.h>

What more do I need to install or configure to be able to build?

I think the missing file is in libc6-dev. If you can't find it, try simply commenting out the offending include in pichart.h because it may work without.