NP Thur April 23 2020

[ijuin 572]

4 hours ago, mlooney said:

I'll see you C and raise you perl style regular expressions.

https://xkcd.com/208/

[Darth Fluffy 302]

2 hours ago, hkmaly said:

The "obscure symbology" drives home the point that if you don't understand the code you shouldn't try to write it.

Also, C isn't using so much obscure symbology. Compared to C++. Or Perl.

Doesn't help. Sure, people are putting lot of efforts into optimizing C, but some statements in C can't be optimized simply because the compiler can't prove the sideefects won't matter.

... and C, which is best suited for programming.

 

There are aspects of C which were very innovative when they were introduced; how it interfaces with its UNIX host; but the syntax sucks, it is error prone. If you've used it for twenty years, you know the quirks and avoid them, and you probably think in C, but your learning curve was steep. As you point out, much more verbose Pascal is a good teaching language, precisely because it is intrinsically clear, it says what it is doing. Point of fact, much pseudocode, in the thinking the problem through phase is essentially Pascal, which is then transcribed into, well, typically C, of some more recent variant.

Additionally, Pascal among many languages handle much for the designer and coder. Bounds checking, for example. How often has C's lack of these features, reliance on the designer and coder to implement them, bitten your butt? Another point of fact, much of software, big packages, in the last decades has been written in C++; much of software, big packages, are plagues with memory leaks. Correlation is not causation, however I find it suspicious that the language family that leaves things up to the developer is the one with the issues.

Yeah, but it goes fast! Yeah, because it is skipping many of the important steps. Doy!

You've made mistakes in C because things did not work the way you thought they would, you just don't remember. C++ has even more pitfalls. But if you're a true believer, you aren't going to believe me.

I don't hate C, I like it's contributions. But I'd rather use Pascal syntax.

 

2 hours ago, hkmaly said:

Also, C isn't using so much obscure symbology. Compared to C++. Or Perl.

Perl style regular expressions are quite logical extension of regular regular expression into context-free grammars. Actually using them as such is still bad idea.

How?

Regular expressions are one aspect where the obscure syntax seems warranted; the density makes it readable. But unfortunately, there is not just one consistent system of 'regular expressions', there is a base set and extensions. Such ambiguity is the bane of getting it done correctly.

The presence of regular expressions in both should highlight the relationship. C <--> Unix <--> Perl

 

2 hours ago, hkmaly said:

side effects

Explicit tends to be less trouble than side effects, although see above, some things should automatically happen; bounds checking would in a sense be a side effect.

 

I feel like we are coming from different universes here.

 

 

[hkmaly 490]

16 hours ago, Darth Fluffy said:

There are aspects of C which were very innovative when they were introduced; how it interfaces with its UNIX host; but the syntax sucks, it is error prone. If you've used it for twenty years, you know the quirks and avoid them, and you probably think in C, but your learning curve was steep. As you point out, much more verbose Pascal is a good teaching language, precisely because it is intrinsically clear, it says what it is doing. Point of fact, much pseudocode, in the thinking the problem through phase is essentially Pascal, which is then transcribed into, well, typically C, of some more recent variant.

Can you give examples in how C's SYNTAX is error prone? It may take little time to get used to block being delimited by parentheses instead of words like begin/end, but it's not more likely to cause errors - and in fact, the fact the parenthesis always matches helps: in pascal, "end" may end different things.

17 hours ago, Darth Fluffy said:

Additionally, Pascal among many languages handle much for the designer and coder. Bounds checking, for example. How often has C's lack of these features, reliance on the designer and coder to implement them, bitten your butt? Another point of fact, much of software, big packages, in the last decades has been written in C++; much of software, big packages, are plagues with memory leaks. Correlation is not causation, however I find it suspicious that the language family that leaves things up to the developer is the one with the issues.

Yeah, but it goes fast! Yeah, because it is skipping many of the important steps. Doy!

It's interesting how much are you willing to excuse to cobol due to it's age yet you don't excuse anything to C. Sure, lack of bounds checking can leads to errors, but at the time C was developed it really speeded up things. Even today, doing boundary check on every access to array would make the program unusable - BUT now, we have compilers capable of optimizing code and finding out where the boundary checks are really needed and where not.

And memory leaks are not caused by bound checking. Memory leaks are caused by mistakes in hand-made memory management. Alternative to that is garbage collecting ... which basically works by not releasing memory until it hits limit, then stopping the program to look what needs to be released. NEITHER is acceptable on computer with small memory in program dealing with I/O and therefore needing to respond. Again, even now it can be problem, and it's only not that serious because we have more memory, faster CPUs and much more effective algorithms for garbage collecting.

Sure, it's easier to leave the work with memory allocations on programming language. Until it breaks and then it's impossible to fix because it's INSIDE the language itself. (Lot of garbage collecting languages had or still have problems with cyclic data structures . Of course, not LISP - but I'm sure there is reason why mark&sweep garbage collecting is not used more widely.) Note that javascript, a language having garbage collector, is famous for serious memory leaks caused by failure to collect cyclic data structures.

... and, of course, Pascal requires manual memory management as well.

Note also that surprising number of today's programs is unable to correctly recover from not enough memory OR disk space. People actually used to do stuff like manual memory management are less likely to make such mistakes ... and no, language CANT fix this for you.

17 hours ago, Darth Fluffy said:

Regular expressions are one aspect where the obscure syntax seems warranted; the density makes it readable. But unfortunately, there is not just one consistent system of 'regular expressions', there is a base set and extensions. Such ambiguity is the bane of getting it done correctly.

The presence of regular expressions in both should highlight the relationship. C <--> Unix <--> Perl

There are no regular expressions in C. Unlike basically any modern language - in many, regular expressions are part of language itself, in rest, core library.

17 hours ago, Darth Fluffy said:

20 hours ago, hkmaly said:

side effects

Explicit tends to be less trouble than side effects, although see above, some things should automatically happen; bounds checking would in a sense be a side effect.

From a formal language theory point of view, everything you actually want the program to do is a side efect, including but not limited to any input or output.

However, to show an example:

for i := 1 to max_i() do
   for j := 1 to max_j() do
     something(i,j)
   end
end

In C, it is possible that max_j, despite having no arguments, in some hidden way depends on i or on something something(i,j) is doing. Therefore, the compiler is not allowed to switch those cycles without checking carefully - and not at all if those three functions are part of different file and therefore not known in time of compilation.

In Fortran, it can. I don't actually know how it works, I only read it as an example. Maybe max_j is guaranteed to not have any sideefects, that is, to not depend on i because it didn't get i as argument. Maybe it's something else. But it's definitely useful, as if it's matrix multiplication, it's something happening extremely often and the compiler may know how to do it in way which makes memory accesses less random. It may even do multiple cycles in parallel.

[Darth Fluffy 302]

On 4/30/2020 at 7:43 PM, hkmaly said:

It's interesting how much are you willing to excuse to cobol due to it's age yet you don't excuse anything to C.

COBOL is good at what it did when it did it. That it is still in use is a good indication that managers do not understand how saving money up front can cost them greatly in the long run. But it is not unusable, especially for the relatively simple tasks demanded of it, and if the pay is good enough, sure, I'd do it. It wasn't hard to learn the one time I needed to fix something. That's not excusing much, is it? Hell, you wouldn't even have to write in COBOL; make a translation program.

As far as C goes, C was groundbreaking in context; with respect to UNIX and a certain programing philosophy. That doesn't mean it's not with out it's faults. You can write clear code in C, but it lends itself to not do so; that's why there is so much verbiage in the C community with respect to how to properly format and comment your code. Because is needs to be addressed.

Look, it's similar to a situation that you brought up, Dykstra's ranting about gotos. He makes a fair point, but there is a counterpoint; one of my instructors many years ago, teaching structured programming in Pascal, pointed out how using a goto to exit a loop could be the easiest to follow, if properly documented (now generally replaced by EXIT statements, this was a while ago). Yet I have seen the other side of this; cleaning up crappy, sloppy, cobbled together code. The first step is invariably to untwist the spaghetti.

You CAN write clean code in C, I'll even bet YOU probably do. But it is by no means a given.

Take note, this contest exists for C, not for Pascal, nor even COBOL, nor BASIC.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

Can you give examples in how C's SYNTAX is error prone?

What is strange about that question is that I'm fairly certain you could come up with a much better list than I could. I recall macros being interpreted other than how they were intended, and order of operation ambiguities.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

And memory leaks are not caused by bound checking. Memory leaks are caused by mistakes in hand-made memory management. Alternative to that is garbage collecting ... which basically works by not releasing memory until it hits limit, then stopping the program to look what needs to be released. NEITHER is acceptable on computer with small memory in program dealing with I/O and therefore needing to respond. Again, even now it can be problem, and it's only not that serious because we have more memory, faster CPUs and much more effective algorithms for garbage collecting.

Sure, it's easier to leave the work with memory allocations on programming language. Until it breaks and then it's impossible to fix because it's INSIDE the language itself. (Lot of garbage collecting languages had or still have problems with cyclic data structures . Of course, not LISP - but I'm sure there is reason why mark&sweep garbage collecting is not used more widely.) Note that javascript, a language having garbage collector, is famous for serious memory leaks caused by failure to collect cyclic data structures.

... and, of course, Pascal requires manual memory management as well.

Note also that surprising number of today's programs is unable to correctly recover from not enough memory OR disk space. People actually used to do stuff like manual memory management are less likely to make such mistakes ... and no, language CANT fix this for you.

Good points.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

There are no regular expressions in C. Unlike basically any modern language - in many, regular expressions are part of language itself, in rest, core library.

Fair, but core library is a major part of a language's identity. Refer back to "Why use Fortran?"

 

On 4/30/2020 at 7:43 PM, hkmaly said:

From a formal language theory point of view, everything you actually want the program to do is a side effect, including but not limited to any input or output.

That's a weak semantic argument. We are a collection of cells. That hardly describes us.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

However, to show an example:

for i := 1 to max_i() do
   for j := 1 to max_j() do
     something(i,j)
   end
end

In C, it is possible that max_j, despite having no arguments, in some hidden way depends on i or on something something(i,j) is doing. Therefore, the compiler is not allowed to switch those cycles without checking carefully - and not at all if those three functions are part of different file and therefore not known in time of compilation.

That's a really bad example, and is a good answer for your "How is C error prone?" question. Not a bad example in the sense of not illustrating your point, more in the sense of letting a child play with a loaded gun. I'm sure there's a reason for it, but having a statement inside the loop modify the loop parameters ina way that is not transparent ... accident waiting to happen.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

In Fortran, it can. I don't actually know how it works, ...

I read something long ago about the development of Fortran; apparently, neither did the developers; they had only a vague notion of where they were headed.

 

On 4/30/2020 at 7:43 PM, hkmaly said:

In Fortran, it can. I don't actually know how it works, I only read it as an example. Maybe max_j is guaranteed to not have any sideefects, that is, to not depend on i because it didn't get i as argument. Maybe it's something else. But it's definitely useful, as if it's matrix multiplication, it's something happening extremely often and the compiler may know how to do it in way which makes memory accesses less random. It may even do multiple cycles in parallel.

I think it's normal that subroutines only operate on the scope of the thing they are handling. They don't edit the calling routine.

 

[hkmaly 490]

18 hours ago, Darth Fluffy said:

that's why there is so much verbiage in the C community with respect to how to properly format and comment your code. Because is needs to be addressed.

No it doesn't and lot of those people just have too much free time. As long as whole project is formatted consistently and commented enough, you don't need to follow some of those anal standards ...

18 hours ago, Darth Fluffy said:

Look, it's similar to a situation that you brought up, Dykstra's ranting about gotos. He makes a fair point, but there is a counterpoint; one of my instructors many years ago, teaching structured programming in Pascal, pointed out how using a goto to exit a loop could be the easiest to follow, if properly documented (now generally replaced by EXIT statements, this was a while ago). Yet I have seen the other side of this; cleaning up crappy, sloppy, cobbled together code. The first step is invariably to untwist the spaghetti.

Some programming languages have break(number) to leave multiple loops, but yes, goto is actually easiest for such cases. Note that it IS (or at least recently was) used in linux kernel in such way. Also, I think that current replacement is to make sure you have the loops divided into functions nicely and use return.

18 hours ago, Darth Fluffy said:

On 5/1/2020 at 1:43 AM, hkmaly said:

Can you give examples in how C's SYNTAX is error prone?

What is strange about that question is that I'm fairly certain you could come up with a much better list than I could. I recall macros being interpreted other than how they were intended, and order of operation ambiguities.

Technically, the macro language is independent to C itself. But you have point that the C preprocessor language is error prone and actually the most likely error is when you assume it's part of C language - it's not and there are cases where it matters.

There is no problem with order of operation ambiguities. There are just people lazy to use parenthesis.

18 hours ago, Darth Fluffy said:

On 5/1/2020 at 1:43 AM, hkmaly said:

There are no regular expressions in C. Unlike basically any modern language - in many, regular expressions are part of language itself, in rest, core library.

Fair, but core library is a major part of a language's identity. Refer back to "Why use Fortran?"

Exactly. Yet there are no regular expressions in C core library.

18 hours ago, Darth Fluffy said:

That's a really bad example, and is a good answer for your "How is C error prone?" question. Not a bad example in the sense of not illustrating your point, more in the sense of letting a child play with a loaded gun. I'm sure there's a reason for it, but having a statement inside the loop modify the loop parameters ina way that is not transparent ... accident waiting to happen.

... I've saw some saying how in (was it pascal? Unlikely ...) everything was childproofed, while C gives you razor and assumes you will use it to shave yourself and not to cut yourself.

So yes, you're right that it wouldn't be good programming and is an accident waiting to happen. And in most cases, even in C, there really ISN'T any problem like this ... but, unless the compiler can prove it, it must assume the worst.

18 hours ago, Darth Fluffy said:

I think it's normal that subroutines only operate on the scope of the thing they are handling. They don't edit the calling routine.

It's definitely not normal. Few examples: read. printf. open. fork (that one doesn't get ANY arguments). exec. XCreateWindow. mysql_query. Seriously, you can't write program without using subroutines with sideefects which would still be good for something.

Also, when you have nontrivial data structure - think something like DOM - you typically give one pointer (or object reference) to subroutine, but that doesn't mean the subroutine is not going to modify something in completely different part of that structure. If you have balanced tree, inserting element somewhere can trigger rebalancing and change whole tree.

That said, yes, it is usually considered good practice to reduce number of global variables and their use and let as much subroutines as possible operate only on their arguments. It's just that as most good practices, following it to letter and not having ANY global variables can lead to even worse code.

To return to the given example, it's completely possible that max_i is reading from terminal, or that something(i,j) is operating on file. Even when it's written better as something(fd,i,j), the compiler would need lot of intelligence to realize that there is hidden variable - the file position - which depends on i and j without it being obvious and that reordering the switches will break the code, because something(fd,i,j) is not expecting it and is not doing something like seek(fd, i*max_j+j) on start just to support reordering.

[Darth Fluffy 302]

22 minutes ago, hkmaly said:

... lot of those people just have too much free time.

Too true, I can't argue that.

 

22 minutes ago, hkmaly said:

There is no problem with order of operation ambiguities. There are just people lazy to use parenthesis.

I have to agree with you, I like the egregious use of parens to make intent clear.

 

22 minutes ago, hkmaly said:

Exactly. Yet there are no regular expressions in C core library.

Hmm. Well, one thing I've noticed about regular expressions is there are variant schemes; inclusion in the core library should serve to consolidate that. Too useful to ignore.

 

22 minutes ago, hkmaly said:

C gives you razor and assumes you will use it to shave yourself and not to cut yourself.

That is my impression, and I may quote you on that.

 

 

[mlooney 3,417]

7 minutes ago, Darth Fluffy said:

I have to agree with you, I like the egregious use of parens to make intent clear.

Back when I was in charge of a team of programmers I had some very strong rules about use of parens.  Like use them even if the operator precedence order said you didn't need to.   

[ijuin 572]

6 hours ago, hkmaly said:

... I've saw some saying how in (was it pascal? Unlikely ...) everything was childproofed, while C gives you razor and assumes you will use it to shave yourself and not to cut yourself.

I like that comparison. C allows you to have microscopic control of the system in ways that usually only Assembler or other very low-level languages permit, but the drawback is that you have to do everything yourself--i.e. you can't afford to overlook the tiny details, because the system will not cover your errors for you.

[Haylo 57]

More or less the same thing I learned from multiple sources -- C will always give you enough rope to hang yourself, so better learn how to avoid coding traps. On the up side, C doesn't make you spend more time dodging language limitations than doing the job.

[mlooney 3,417]

The best way to learn good C coding practices is to code for 286 protected mode.  Almost all the bad things you can do in C result in an INT-D being tossed, which while it does crash out your program, it doesn't hurt the rest of the system and if your debugger and editor are set up correctly you will be dropped on the offending line of code.  Also use lint on all your source code before you commit it to your code base.

[hkmaly 490]

20 hours ago, Darth Fluffy said:

22 hours ago, hkmaly said:

Exactly. Yet there are no regular expressions in C core library.

Hmm. Well, one thing I've noticed about regular expressions is there are variant schemes; inclusion in the core library should serve to consolidate that. Too useful to ignore.

There is just one PCRE I think ... https://www.pcre.org/
 

20 hours ago, Darth Fluffy said:

22 hours ago, hkmaly said:

C gives you razor and assumes you will use it to shave yourself and not to cut yourself.

That is my impression, and I may quote you on that.

It might be better to find the original quote instead of relying to my re-back-translation ... I found this one but that's probably not that.

13 hours ago, Haylo said:

More or less the same thing I learned from multiple sources -- C will always give you enough rope to hang yourself, so better learn how to avoid coding traps. On the up side, C doesn't make you spend more time dodging language limitations than doing the job.

It is definitely harder to shave yourself without anything sharp ...

12 hours ago, mlooney said:

The best way to learn good C coding practices is to code for 286 protected mode.  Almost all the bad things you can do in C result in an INT-D being tossed, which while it does crash out your program, it doesn't hurt the rest of the system and if your debugger and editor are set up correctly you will be dropped on the offending line of code.  Also use lint on all your source code before you commit it to your code base.

Not sure what you speak about but it's definitely not 286 protected mode. Only thing specific to 286 protected mode is that the error is INT-D while on 386 most of them are INT-E.

Either you mean protected mode in general as opposed to real mode - which is definitely true, in real mode, errors like this will cause undefined behaviour, while in protected mode, most of them will be caught by protection mechanism - or you speak of specific IDE.

Note that in linux, this class of errors will be reported to your program as SIGSEGV.  Which you can not just catch, but also recover from - indeed, you CAN implement virtual memory in userspace linux program by automatically memory mapping a page on SIGSEGV then returning from the signal handler, which will make the program continue where it was interrupted. Of course, if it's error, you probably don't want to let the program continue.

 

[Darth Fluffy 302]

8 hours ago, hkmaly said:

There is just one PCRE I think ... https://www.pcre.org/

My perspective is dated; doubtless there has been some consolidation. Still, not only PERL has regular expressions.

 

8 hours ago, hkmaly said:

It might be better to find the original quote instead of relying to my re-back-translation ... I found this one but that's probably not that.

I like that one.

 

8 hours ago, hkmaly said:

It is definitely harder to shave yourself without anything sharp ...

Lol, true. And there's that whole thing about who shaves you if you're a barber that shaves people who don't shave themselves.

 

[hkmaly 490]

16 hours ago, Darth Fluffy said:

On 5/7/2020 at 0:50 AM, hkmaly said:

There is just one PCRE I think ... https://www.pcre.org/

My perspective is dated; doubtless there has been some consolidation. Still, not only PERL has regular expressions.

There is definitely lot of other regular expressions libraries, but the PCRE one (which, while compatible with perl, is NOT the same one perl is using) is the most feature-rich, making it obvious choice in lot of cases. Packages using it includes not just php and grep, but also syslog-ng, apache, slang, proftpd, nmap, git, clamav ...

16 hours ago, Darth Fluffy said:

On 5/7/2020 at 0:50 AM, hkmaly said:

It is definitely harder to shave yourself without anything sharp ...

Lol, true. And there's that whole thing about who shaves you if you're a barber that shaves people who don't shave themselves.

Obviously, he does, but it's for free, so he needs to keep it secret, especially from IRS.

[Darth Fluffy 302]

1 hour ago, hkmaly said:

17 hours ago, Darth Fluffy said:

... And there's that whole thing about who shaves you if you're a barber that shaves people who don't shave themselves.

Obviously, he does, but it's for free, so he needs to keep it secret, especially from IRS.

You'd better tell Russel, ... oh, wait, he's dead. Never mind.

On a related note, it is a good thing for crocodiles that they do not discuss logic.

[hkmaly 490]

1 hour ago, Darth Fluffy said:

You'd better tell Russel, ... oh, wait, he's dead. Never mind.

Russel approached the dilemma from strictly logical standpoint and got to paradox. His results are valid and important, but not directly applicable in real world. Similarly, the famous liar paradox, while logically valid, is not applicable in real world for the simple reason that even the most experienced liars - in fact, often ESPECIALLY the most experienced liars - are saying truth most of the time. The most effective lie is one which is mostly true. Or even COMPLETELY true - just not answering the question which was asked.

1 hour ago, Darth Fluffy said:

On a related note, it is a good thing for crocodiles that they do not discuss logic.

Also, yes, crocodiles usually simply eat the child without asking any questions.
And the famous trick with one guard telling truth and one lying can only be realised with magical guardians, because human ones will always answer the adventurer truthfully in non-verbal way, most even BEFORE he throws them through the door they labeled as safe.

 

I personally really enjoy the paradoxes, but that doesn't stop me from knowing some of the unsaid assumptions making them work only theoretically.

[Darth Fluffy 302]

1 minute ago, hkmaly said:

And the famous trick with one guard telling truth and one lying ...

I like the Order of the Stick one about that, but I'll refrain from re-posting, because it's already been here once or twice.

Short version, Haley shoots one in the foot.

[hkmaly 490]

52 minutes ago, Darth Fluffy said:

57 minutes ago, hkmaly said:

And the famous trick with one guard telling truth and one lying ...

I like the Order of the Stick one about that, but I'll refrain from re-posting, because it's already been here once or twice.

Short version, Haley shoots one in the foot.

I won't. And yes, also good example.