Design a better "C"

[bd139]

Go is very good, but in my case is a bad choice because its main-implementation depends on llvm/Clang, which is hard to be cross-compiled for PowerPC, SH and MIPS.

It's mostly profiled for mainstream architectures, mostly x86 and Arm.

The Ath5 SoC has a mips32-r1-be core, when I tried to make Go running on it ... I found thousand problems that I don't frankly want to deal with because my purpose is not "to fix Go on mips", but rather making the ath5 to work for my applications.

Ok that's a completely fair point. I still wouldn't us PHP 

In that case I'd use Python and profile it. The slow or ballooning memory bits would get rewritten in C.

If you think of Python as a tool for sticking bits of C together then it works for that.

[DiTBho]

If you think of Python as a tool for sticking bits of C together then it works for that.

Good idea, maybe for the next stage 

After all, months ago, I replaced my CASIO Casio FX-9860GII with a Casio FX-9860GIII mostly because the GIII runs ucPython, which needs to be hacked to support inline assembly.

The TCP/IP stack to connect ucPython to the lan is written in C. It's based on ucIP, addressed to the serial-link, and encapsulated into a kind-of-serial at 115200bps.

ucPython + inline assembly + C = power and elegance

[PlainName]

If I want to hold all 6-digit positive integers I need to use a uint32_t or equivalent. What's wrong with 3 bytes of BCD? Even the 6502 had a BCD mode!

Code: [Select]

printf("%s", BCD3bytes2asc(*bcdvar));

[TheCalligrapher]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

[SiliconWizard]

C + strings = php
Not good, but not too bad after a full training.

I had never seen PHP compared to C in any way or form until this. 

[SiliconWizard]

@cfbsoftware: I have considered Oberon actually. There's a lot to like about it. But I think Wirth went a bit too far with it. He removed so much that some things are even clunkier to express than with C.

Could you give me an example of where you think this applies please?

Oh, I would like to give an extensive answer to this to do Oberon fair justice. So, sorry if this is short and simple. Also, do not hesitate to tell me where I could have been wrong - I think I know Oberon fairly well, but obviously not nearly as well as you do. So I'll just give a few points off the top of my head:

- Keywords are all uppercase, and the language is case-sensitive. Uppercase keywords really annoy me and my fingers. They were justified back in the days when text editors didn't have syntax highlighting, but these days, they are just a major annoyance IMHO.

- Constants (CONST section) are typeless. They are essentially like macros. That bothers me. Not a huge dealbreaker, I admit, but I'd like typed constants. I know you can always declare variables, initialize them in the "body" of the module, and use them as constants, but they are not proper constants as they could be modified, at least within the module.

- Related: you can declare variables and make them private to a module, but you can't make variables constant (AFAIR, please correct me if I'm wrong). So, I think that's a limitation.

- Point I'm not 100% sure of: there are no array or record initializers. So initializing them is very clunky compared to other languages.

- Usually not much of a problem for embedded development (but Oberon is a general purpose language), but a bit more for higher-level stuff: there are no dynamic arrays. Wirth actually removed them from Oberon-2 IIRC. C doesn't have anything like this either, and you have to implement them by hand, but it would have been nice to have them in Oberon.

- Related, dynamic memory allocation is all based on a garbage collector. I don't reject GCs in all cases or as a principle, but I think it could be nice if it could alternatively use a static allocator instead.

- Something C was long plagued with as well: there are no fixed (and standard)-width integers. No unsigned integers in general either, except for the BYTE. So IIRC, you have BYTE (which should be an 8-bit unsigned integer on most platforms), and INTEGER, which is a signed integer. The width depends on the platform. If you need to define and/or access integers with a specific width, look elsewhere... you may have to resort to the SYSTEM module. Now see below as well.

- Probably a lot of other shortcomings I can't think of at the moment.

Not ALL the low-level stuff needs to be handled by SYSTEM now. Only the stuff that can lead to obscure problems caused by memory corruption e.g. typecasts, accessing absolute memory addresses etc. Note also that SYSTEM is actually a 'pseudo module'. What looks like a procedure call is, more often than not, inline code. SYSTEM is just there to highlight to the code reader / maintainer that they need to take extra care.

Well, for embedded development, you really can't do without this. Register access requires SYSTEM. Likewise and related to above: actually accessing memory with a defined width (such as 8-bit, 16-bit, 32-bit, etc) is impossible to guarantee without proper procedures in the SYSTEM module. Otherwise you're restricted to BYTE and INTEGER. The width of which is uh... not necessarily what you need for a given access, and unfortunately for portability, platform- and implementation-dependent. I don't completely mind having to use a dedicated module for this low-level stuff. But I do mind a little bit that the SYSTEM module may have to implement different functions and procedures depending on the platform, and that there's no standard way of accessing memory with a given width.

Anyway, don't take this as Oberon bashing at all. I think it's a nice language, but, and in particular the latest Oberon-07, it is an exercise in simplicity and I do think Wirth went too far with it (he clearly removed everything he could while keeping the language usable, nice but sometimes too much). I gave a few examples, I'm sure there are lots of others. But that said, it can certainly be used as an alternative to C. I'm just explaining here (shortly) why I personally think it's not quite fit for this. My own opinion.

[bd139]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

I disagree. Valgrind should be used continually to ensure you haven’t created yourself something that is expensive to fix later. All problems are yours until proven otherwise.

[SiliconWizard]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

I disagree. Valgrind should be used continually to ensure you haven’t created yourself something that is expensive to fix later. All problems are yours until proven otherwise.

Yeah. Guess what. However competent you are, your head is fallible. Static and dynamic analysis tools help you catch whatever mistake you may have inadvertently made. Someone thinking they never make any mistake because they are so competent is deluded.

Now of course tools shouldn't be a replacement for your brain. They are just there to complement it. So using those tools because you don't know what you're doing is, certainly, not going to work that well. But even experts make mistakes.

[DiTBho]

Valgrind

you : Valgrind  = me : ICE 

[bd139]

Ideally me = FORTH but no one wants that

[james_s]

Not every "embedded" application requires microsecond or even millisecond performance. And many microcontrollers now have speed and capacity comparable to our desktop computers in the 80s.

As an aside, it amuses me when someone reviews a i3 or Atom computer and says "It's ok for light use but you wouldn't want to run Photoshop on it".

Dude. We used to run Photoshop on 33 MHz machines with 8 MB RAM and thought we were lucky.

That's entirely true of course, but my experience playing with Micropython is that it's fun and a great replacement for something like the BASIC Stamp but it's not the most stable platform I've used and you end up needing a 32 bit ARM to do what could easily be done on an 8 bit microcontroller. It's a neat toy, but there is no reason to use an interpreted language to do embedded development, the less than perfect stability alone is reason not to. I have microcontroller projects I made that have been running for over 20 years and I've never had any of them crash or stop responding, they all run bare metal with no operating system at all. An interpreted embedded language is an operating system in itself and there is a lot of stuff going on under the hood that I can't see or control.

And yes, I remember running Photoshop on a 33MHz 486 and a 25MHz Mac and it was great, but Photoshop then and Photoshop now are two entirely different things. For a casual user like me the old one would probably still be adequate, but at the time I was using it a 640x480 image was high resolution. Now my photographer friend is regularly working with 12+ megapixel raw images. The hard drive on those old machines I used isn't big enough to hold them, much less the RAM.

[brucehoult]

And yes, I remember running Photoshop on a 33MHz 486 and a 25MHz Mac and it was great, but Photoshop then and Photoshop now are two entirely different things. For a casual user like me the old one would probably still be adequate, but at the time I was using it a 640x480 image was high resolution. Now my photographer friend is regularly working with 12+ megapixel raw images. The hard drive on those old machines I used isn't big enough to hold them, much less the RAM.

It was capable of a bit more than that :-)

I remember my clients using 68k Macs (which topped out at the 40 MHz Quadra 840AV) to routinely touch up 3000x2000 scans of 35 mm negatives (using a huge scanner that cost well into six digits -- you smeared the neg (or slide) with a transparent gel with a carefully controlled refractive index then taped it to a glass drum).

From time to time I got called into debug a 500 MB PostScript file that would not print. I used BBEdit to open / search / edit it -- on a machine with just a few MB of RAM. I remember using Perl for analysis also as soon as it became available on the Mac.

For a time I offered a service doing custom half-toning using some unique shapes and techniques a colleague and I developed. I would get a 300 DPI CMYK TIFF image of an A4 or A3 page and convert it to four 3387 DPI bitmaps. That's about 39600 x 28000 or 132 MB for each separation for A4. I could open those in Photoshop to check them on a 60 MHz PowerPC 601.

[tggzzz]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

You have a narrow definition of "programmer"; not all programes are written in the way you appear to be inferring.

I suspect you believe you are far more capable than the vast majority of C programmers. An attitude like yours is hubris, which is traditionally followed by nemesis - with the results we see in CERT advisories

[TheCalligrapher]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

I disagree. Valgrind should be used continually to ensure you haven’t created yourself something that is expensive to fix later. All problems are yours until proven otherwise.

Continually is fine. I'm just saying that "continually" means that QA/integration team runs valgrind on regular basis as part of their QA routine. And the issues found by valgrind are then passed back to the R&D for fixing or annotation. Many modern valgrind-like tools (as well as static anaysis tools) are deliberately designed to fit that purpose.

As for using valgrind as everyday debugging tool, as in "I don't know what's causing the problem and I'm too lazy to approach it directly, so I'll just run valgrind and hope that it finds the right culprit for me" - this is just a loser's way out.

Of course, not everybody works in an environment that provides such a clear-cut separation of responsibilities between teams, but still... valgrind is a periodic housecleaning tool, not an everyday debugging tool.

[westfw]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.

Ah.  The heart of the matter.  C isn't so much a "language" as at least three different languages:

• Portable Assembler C.  "Libraries are irrelevant because they all suck anyway.  I want to write my own bare metal manipulations, and anything that interferes with that is evil."
• Embedded C.   "I've only got 128k-2MB of program space and 32-256k of RAM, but it might be nice not to have to write my own USB stack."
• Desktop C.  "The whole problem space is pretty trivial compared to the resources I have, but I really want to avoid security bugs."
• High-level C: "I'm working on a hard problem, and I want a compiler that makes it work as well as inhumanly possible!"
• Computer-Science C: "I want an elegant way to express fancy algorithms in readable style."

(FIVE different languages!!)

(arguably, there have been lots of attempts at "Desktop C" replacements, and the usual ivory-tower "no one actually uses that in the real world" attempts for "Computer Science C")

For instance (from the valgrind homepage):

The Valgrind distribution currently includes seven production-quality tools: a memory error detector, two thread error detectors, a cache and branch-prediction profiler, a call-graph generating cache and branch-prediction profiler, and two different heap profilers.

It's been a long time since I cared much about 6 of those...  And I think the last time I cared about four of the others was on such a non-standard system that they would have been of limited use.)

(BTW: My impression is that modern C compilers include a lot of the error checking that you used to have to use things like lint to get.  Is that not true?)

[cfbsoftware]

Oh, I would like to give an extensive answer to this to do Oberon fair justice. So, sorry if this is short and simple. Also, do not hesitate to tell me where I could have been wrong - I think I know Oberon fairly well, but obviously not nearly as well as you do. So I'll just give a few points off the top of my head:

- Keywords are all uppercase, and the language is case-sensitive. Uppercase keywords really annoy me and my fingers. They were justified back in the days when text editors didn't have syntax highlighting, but these days, they are just a major annoyance IMHO.

This would have to be the most common gripe I have heard. To me it is like somebody saying they wouldn't drive a Ferrari because they can't get it in any colour other than red.

My typing isn't particularly good either and it was one of the major incentives for me to develop the Oberon-aware Astrobe IDE. One of its features is automatic capitalisation of keywords. You just continue typing in lowercase as normal and when it recognises the last word typed is a keyword it capitalises it for you. We've also catered for the rare occasions where you don't want this to happen and find it works extremely well in practice.

Actually it would have been easier to have modified the compiler to accept lowercase keywords as well. There are several reasons why I believe a case-sensitive language and uppercase keywords can be useful:

a) As long as you avoid all-uppercase identifiers you know you can use whatever word is the best choice for a particular variable.

e.g. some of the following would be invalid in Pascal:

Code: [Select]

colour := black; type := digital; case := plastic;
now := 2021; then := 1969;
b) If you avoid using all-uppercase characters in your own identifiers your program will never be invalidated at some future time if, and when, new keywords are added to the language.

c) The language designer has the freedom to select the most suitable keyword for a new feature rather than trying to avoid a word that is likely to break existing software.

d) Syntax-highlighting might be useful when working on a screen but monochrome printed program text and code samples in books have yet to disappear altogether.

e) Rather than using a Delphi-like convention of prefixing typenames with the letter T, or the horrendous Hungarian notation, you can use the Oberon convention of starting type names with a capital letter and variable names with a lower case letter:

Code: [Select]

list: TList;then becomes:

Code: [Select]

list: List;The thought of doing this can perplex Pascal / Delphi programmers who have had no hands-on Modula-2 / Oberon experience. It needs to be tried for a while before deciding whether you like it or not.

- Constants (CONST section) are typeless. They are essentially like macros. That bothers me. Not a huge dealbreaker, I admit, but I'd like typed constants. I know you can always declare variables, initialize them in the "body" of the module, and use them as constants, but they are not proper constants as they could be modified, at least within the module.

I'm not sure that I follow you here. Floating-point constants are REAL, string constants are character arrays, numeric constants are INTEGER. You can't assign a constant to a variable of a different type.

- Related: you can declare variables and make them private to a module, but you can't make variables constant (AFAIR, please correct me if I'm wrong). So, I think that's a limitation.

Stand corrected Exported variables cannot be directly modified in a client module. There would need to be a 'setter' procedure also declared in the exporting module to enable modification. The setter procedure could then do any necessary validation if required.

- Point I'm not 100% sure of: there are no array or record initializers. So initializing them is very clunky compared to other languages.

True. However, it is rarely a problem in practice for me as I rarely, if ever, use array or record initialisers even when using languages that allow them. When reading code where the record or array would be complex / large enough to make it clunky to initialize it, I have a great deal of difficulty comprehending which part of the array / record an alternative constant initialiser maps onto. While I accept that it would be irksome to those who like such initialisers I would be surprised if it was considered to be a deal-breaker.

- Usually not much of a problem for embedded development (but Oberon is a general purpose language), but a bit more for higher-level stuff: there are no dynamic arrays. Wirth actually removed them from Oberon-2 IIRC. C doesn't have anything like this either, and you have to implement them by hand, but it would have been nice to have them in Oberon.

True. However, I wouldn't recommend using Oberon-07 for anything other than embedded development. A programming language is a tool. Every competent programmer should understand the pros and cons of several languages and choose the most suitable tool for the task in hand. e.g. I use C# and Component Pascal (a superset of Oberon-2) for Windows GUI development such as the Astrobe IDE. I wouldn't dream of coding it in Oberon-07 any more than I would dream of coding it in C.

- Related, dynamic memory allocation is all based on a garbage collector. I don't reject GCs in all cases or as a principle, but I think it could be nice if it could alternatively use a static allocator instead.

A garbage collector is not mandated for Oberon-07. The Astrobe Cortex-M compilers have a safe, restricted, 'Dispose' function that works in a last-in / first out basis. Source code of the system's Memory Allocation module is available - it's only 80 lines of Oberon code so is easily understandable and modifiable.

- Something C was long plagued with as well: there are no fixed (and standard)-width integers. No unsigned integers in general either, except for the BYTE. So IIRC, you have BYTE (which should be an 8-bit unsigned integer on most platforms), and INTEGER, which is a signed integer. The width depends on the platform. If you need to define and/or access integers with a specific width, look elsewhere... you may have to resort to the SYSTEM module. Now see below as well.

An actual parameter declared as ARRAY OF BYTE can have ANY data type passed to it as long as it has the same size. You can then perform BYTE operations within the procedure. Although this is currently implemented in both the ARM Cortex-M and RISC5 FPGA compilers it is not yet defined in the Language Report so should currently be considered as a language extension. In Astrobe we also implemented built-in standard procedures BFI and BFX for bitfield insert and bitfield extract operations. These are extremely efficient on ARM Cortex-M processors because they directly use the corresponding BFI and BFX Thumb-2 instructions as inline code. Examples of this can be seen in the BitFields discussion on the Astrobe forum:

https://www.astrobe.com/forum/viewtopic.php?f=3&t=564

- Probably a lot of other shortcomings I can't think of at the moment.

Yes - you have covered most, if not all, of the common gripes. Every language has pros and cons. Much of the time these are subjective, Either the cons become insignificant over time or they become so bad that you swear never to use the language ever again. I won't mention any names ;-)

Anyway, don't take this as Oberon bashing at all.

Not at all. Thank you for your feedback. I very much appreciate the time and thought you have put into it.

[bd139]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

Nope. If you are a competent C programmer, "cppcheck or splint" works naturally in your head.

As for valgrind - this is a valuable tool, but a tool for the integration team. Programmers don't use valgrind, unless stuck panicking in a completely desperate situation.

I disagree. Valgrind should be used continually to ensure you haven’t created yourself something that is expensive to fix later. All problems are yours until proven otherwise.

Continually is fine. I'm just saying that "continually" means that QA/integration team runs valgrind on regular basis as part of their QA routine. And the issues found by valgrind are then passed back to the R&D for fixing or annotation. Many modern valgrind-like tools (as well as static anaysis tools) are deliberately designed to fit that purpose.

As for using valgrind as everyday debugging tool, as in "I don't know what's causing the problem and I'm too lazy to approach it directly, so I'll just run valgrind and hope that it finds the right culprit for me" - this is just a loser's way out.

Of course, not everybody works in an environment that provides such a clear-cut separation of responsibilities between teams, but still... valgrind is a periodic housecleaning tool, not an everyday debugging tool.

Nope. Valgrind should be an every day debugging tool. Static analysers as well. They stop your poor assumptions leaking into the integration suite where it’s harder to do a root cause analysis. You’re right that they’re not a substitute for thought but assuming your problem is someone else’s problem is one massive fault in most SDLC.

Guess who’s job it is running the team who picks up smouldering craters from that assumption on a regular basis.

[Siwastaja]

It took 25 minutes to process it and it used 24Gb of RAM. Code was 12Kb.
..
It took 18 seconds to process it and it used 4.2Gb of RAM. Code was 8Kb. [4 hours of development]

Would be interested in hearing about the development time for the first case.

[bd139]

It took them about a month, mostly of meetings, two false starts and several pages of confluence content generated and of course pair programming. That actually replaced a massive chunk of C# which was running for several years and took several hours to run doing horribly inefficient queries against SQL server. That broke when someone fired up a PO for a bigger SQL box and someone said no.

I will grant them the fact that they reverse engineered the C# thing in that time and bothered to write down what it was supposed to do which made my job easier.

[Siwastaja]

That is why I don't prefer to use RTOSes and don't understand people who market them as the best things since sliced bread for timing critical control.

NASA aren't afraid of a commercial RTOSs for controlling Martian rovers. Having one enabled them to "rescue" the Mars Pathfinder

Quite obviously, my comment was a simplification beyond being very useful.

In any case, my point regarding RTOS is that people seem to expect that RTOS's abstractions solve the difficulties regarding parallelism and timing determinism easily, providing a silver bullet. This is far from being true. Especially in simple cases, the added weight is a hindrance.

In a large, complex system, given very experienced developers and massive budgets, like at NASA, I'm sure using an RTOS instead of simple ad-hoc solutions above bare metal, is the right choice.

[Just_another_Dave]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.

Ah.  The heart of the matter.  C isn't so much a "language" as at least three different languages:

• Portable Assembler C.  "Libraries are irrelevant because they all suck anyway.  I want to write my own bare metal manipulations, and anything that interferes with that is evil."
• Embedded C.   "I've only got 128k-2MB of program space and 32-256k of RAM, but it might be nice not to have to write my own USB stack."
• Desktop C.  "The whole problem space is pretty trivial compared to the resources I have, but I really want to avoid security bugs."
• High-level C: "I'm working on a hard problem, and I want a compiler that makes it work as well as inhumanly possible!"
• Computer-Science C: "I want an elegant way to express fancy algorithms in readable style."

(FIVE different languages!!)

(arguably, there have been lots of attempts at "Desktop C" replacements, and the usual ivory-tower "no one actually uses that in the real world" attempts for "Computer Science C")

For instance (from the valgrind homepage):

The Valgrind distribution currently includes seven production-quality tools: a memory error detector, two thread error detectors, a cache and branch-prediction profiler, a call-graph generating cache and branch-prediction profiler, and two different heap profilers.

It's been a long time since I cared much about 6 of those...  And I think the last time I cared about four of the others was on such a non-standard system that they would have been of limited use.)

(BTW: My impression is that modern C compilers include a lot of the error checking that you used to have to use things like lint to get.  Is that not true?)

I think that one of the reasons why people tend to avoid using any standard library when using C as a portable assembler is that they were designed for being used and not for being ported. Being able to use printf to send messages through a serial connection (uart, i2c, etc) improves code portability and in some cases allows testing your program before having manufactured the prototype (if the standard library is used as a HAL and the rest of hardware dependent code is also encapsulated it is sometimes possible to test the program on a development board to test other parts of the circuit before having a prototype, which can be useful for debugging the high level part of the program). However, implementing the functions that need to be implemented usually depend on the compiler provided by the manufacturer, which usually is not precisely amazing.

Having a “standard HAL” could help changing that mindset, as that would mean that you need to provide an implementation for a well defined api to be able to use the standard library instead of some obscure compiler dependent functions. Nevertheless, some functions of the standard library that rely on having an operating system (like executing a command in the system shell) would still not be used, mainly because they aren’t needed in those applications (which doesn’t mean that they are not useful in other environments nor that they shouldn’t be available as part of the standard library, just that those particular applications don’t need it)

[tggzzz]

That is why I don't prefer to use RTOSes and don't understand people who market them as the best things since sliced bread for timing critical control.

NASA aren't afraid of a commercial RTOSs for controlling Martian rovers. Having one enabled them to "rescue" the Mars Pathfinder

Quite obviously, my comment was a simplification beyond being very useful.

In any case, my point regarding RTOS is that people seem to expect that RTOS's abstractions solve the difficulties regarding parallelism and timing determinism easily, providing a silver bullet. This is far from being true. Especially in simple cases, the added weight is a hindrance.

In a large, complex system, given very experienced developers and massive budgets, like at NASA, I'm sure using an RTOS instead of simple ad-hoc solutions above bare metal, is the right choice.

Agreed, except that I'd argue that a team of non-wizard programmers might be well advised to use an RTOS. It will provide

• a framework for guiding the high and low level designs
  
• demarcation boundaries between subsystems and programmers
  
• logging (and debugging) facilities so you can see what is actually happening

Those points are not so advantageous to an individual programmer working on small applicatons, of course.

[DiTBho]

• Computer-Science C: "I want an elegant way to express fancy algorithms in readable style."

Useful to pass any theoretical computer science exam, and even to express any algorithm like if it was an abstract mathematical fancy, perhaps even to describe the world without the need to have the time variable in its inner equations (which is the new frontier of physics and math) ... but, just, like it happens with some classes of Turing machines, the other side of the coin is that its implementation won't conclude its computation in any finite time.

[bd139]

On that note, it’s amazing how many computer scientists I see using various associative abstract data types (hash tables etc) with only two items in them. Oh for the purity.

[tggzzz]

On that note, it’s amazing how many computer scientists I see using various associative abstract data types (hash tables etc) with only two items in them. Oh for the purity.

Their counting scheme is probably (and quite reasonably!): zero, one, many.