Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #11784 > unrolled thread

Alternatives to C (was Re: Safety of casting from 'long' to 'int')

Back to article view | Back to comp.lang.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 13:05 +0000
    Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 02:28 +0100
      Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 18:37 -0700
        Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 22:32 +0100
          Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') John Ames <commodorejohn@gmail.com> - 2026-05-12 15:28 -0700
            Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:49 +0200
          Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 23:21 +0000
            Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:53 +0200
              Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-13 14:15 +0000
                Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 12:30 -0700
                  Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:20 +0000
            SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 21:30 -0300
              Re: SPL/3000 (was Re: Alternatives to C) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:32 +0000
              Re: SPL/3000 (was Re: Alternatives to C) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:33 +0000
              Re: SPL/3000 (was Re: Alternatives to C) scott@slp53.sl.home (Scott Lurndal) - 2026-08-28 14:14 +0000
                Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 15:28 -0300
                  Re: SPL/3000 (was Re: Alternatives to C) scott@slp53.sl.home (Scott Lurndal) - 2026-08-28 19:18 +0000
                    Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 21:13 -0300
                    Re: SPL/3000 (was Re: Alternatives to C) Lars Poulsen <lars@beagle-ears.com> - 2026-08-29 06:14 -0700
                      Re: SPL/3000 (was Re: Alternatives to C) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 15:19 -0300
      Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 02:40 +0000
        Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 15:11 +0100
      Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 13:59 +0800

Page 2 of 2 — ← Prev page 1 [2]

#11787

In article <10ttvng$1j579$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>On 10/05/2026 14:05, Dan Cross wrote:
>> In article <10tpt9j$c3i4$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>>> On 10/05/2026 05:39, Janis Papanagnou wrote:
>>>> [snip]
>>>> What makes you think that I'd need to write an own language given that
>>>> there's a plethora of languages of all kinds and paradigms existing.
>>>
>>> So where's the one that works like mine?
>> 
>> I mean, Rust does exactly what you were just describing.
>
>Rust could hardly be more different than mine.

You were describing what Rust calls, `include_str!` and
`include_bytes!`.  That's what I was referring to.

https://doc.rust-lang.org/std/macro.include_str.html
https://doc.rust-lang.org/std/macro.include_bytes.html

>>> And why are there so many new ones still appearing? Most of them you
>>> will not know about.
>> 
>> Consider the possibility that you may be unique in the world in
>> possessing the combination of requirements and aesthetic
>> judgement that makes you feel you need a language like yours.
>
>My language fills the same niche that C does.
>
>I don't have much of a problem with the things that C can do, but with 
>how it does it, its syntax, its ancient baggage, its quirks, its 
>folklore, its Unix-centric ecosystem, its pointless UBs, its insistence 
>in working with every oddball processor, its solving every shortcoming 
>with macros, its adherents who will defend every misfeature to the death...
>
>Maybe the answer is to just create my own language?! I did exactly that, 
>and didn't to have to deal with C for 10-15 years, but you can't get 
>away from it because it's everywhere.

So like I said, you may be unique in the world in possessing the
combination of requirements _and aesthetic judgement_ that makes
you feel you need a language exactly like yours.

I think you'll find very few "adherents who will defend every
misfeature to the death."

>It is also frustrating looking at C forums and people thinking they are 
>too stupid to grasp something when it's language that could have been 
>better.

The problem you keep encountering here, specifically, is that by
your own admission you do not know C, the language, well enough
to accurately understand what would have made it a "language
that could have been better."

>> As for new languages, there are a number of reasons.  Most of
>> them are not particularly relevant here.
>> 
>> At this point, you may consider doing what Keith suggested, and
>> moving further discussion of your language to comp.lang.misc.
>
>Sure, a pretty much dead group.

Maybe you could liven it up.

        - Dan C.

[toc] | [prev] | [next] | [standalone]

#11788

On 12/05/2026 03:40, Dan Cross wrote:
> In article <10ttvng$1j579$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>> On 10/05/2026 14:05, Dan Cross wrote:
>>> In article <10tpt9j$c3i4$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>>>> On 10/05/2026 05:39, Janis Papanagnou wrote:
>>>>> [snip]
>>>>> What makes you think that I'd need to write an own language given that
>>>>> there's a plethora of languages of all kinds and paradigms existing.
>>>>
>>>> So where's the one that works like mine?
>>>
>>> I mean, Rust does exactly what you were just describing.
>>
>> Rust could hardly be more different than mine.
> 
> You were describing what Rust calls, `include_str!` and
> `include_bytes!`.  That's what I was referring to.
> 
> https://doc.rust-lang.org/std/macro.include_str.html
> https://doc.rust-lang.org/std/macro.include_bytes.html

OK, so some specific features. I don't know Rust, other than when I 
first starting testing its compiler in 2021, it was one of the slowest 
I'd ever tried.

However it is interesting that it includes both 'str' and 'byte' 
versions which mirror my 'strinclude/sinclude' and 'binclude'.

C23 now has '#embed', although its operation is much clunkier. To try it 
though I needed to download a new version, and used 16.x. I was 
interested in how fast it could deal with large embedded data, and tried 
this program:

   #include <stdio.h>
   #include <string.h>

   char str[] = {
       #embed "big.txt"
       ,0
   };

   int main(void) {
       printf("%zu\n", sizeof(str));
       printf("%zu\n", strlen(str));
   }

'big.txt' contains 100 million 'A's, not zero-terminated. The ',0' will 
do that (I understand attributes can be used to control that).

As for speed, I was pleasantly surprised: compiling this took 5 seconds.

(While #embed notionally produces a token list like 65,65,...., it must 
handle it internally far more efficiently, especially within the 
intermediate assembly.)

Still, with my language where it looks like this:

   []char str = sinclude("big.txt")     # sinclude adds the terminator

it took only one second. (However, I don't use intermediate ASM so it 
can be streamlined.)

>> It is also frustrating looking at C forums and people thinking they are
>> too stupid to grasp something when it's language that could have been
>> better.
> 
> The problem you keep encountering here, specifically, is that by
> your own admission you do not know C, the language, well enough
> to accurately understand what would have made it a "language
> that could have been better."

That's like saying I can't compare one car with another, because I don't 
understand the internals or rationale of the one I criticise.

I do however understand the tasks I expect them to do, and can speak 
about my experiences of using each.

So I don't need to care why that car behaves as it does; doing so will 
not make the experience any better!

I brought up a Model T analogy for C the other day, and it is apt.

This actually applies to anybody; they don't need to be involved in 
making their own vehicles. But if they are, then they will be in a 
position to fix shortcomings.

[toc] | [prev] | [next] | [standalone]

#11810

On 12/05/2026 9:28 AM, Bart wrote:
> On 10/05/2026 14:05, Dan Cross wrote:
>> In article <10tpt9j$c3i4$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
>>> On 10/05/2026 05:39, Janis Papanagnou wrote:
>>>> [snip]
>>>> What makes you think that I'd need to write an own language given that
>>>> there's a plethora of languages of all kinds and paradigms existing.
>>>
>>> So where's the one that works like mine?
>>
>> I mean, Rust does exactly what you were just describing.
> 
> Rust could hardly be more different than mine.
> 
>>> And why are there so many new ones still appearing? Most of them you
>>> will not know about.
>>
>> Consider the possibility that you may be unique in the world in
>> possessing the combination of requirements and aesthetic
>> judgement that makes you feel you need a language like yours.
> 
> My language fills the same niche that C does.
> 
> I don't have much of a problem with the things that C can do, but with 
> how it does it, its syntax, its ancient baggage, its quirks, its 
> folklore, its Unix-centric ecosystem, its pointless UBs, its insistence 
> in working with every oddball processor, its solving every shortcoming 
> with macros, its adherents who will defend every misfeature to the death...
> 
> Maybe the answer is to just create my own language?! I did exactly that, 
> and didn't to have to deal with C for 10-15 years, but you can't get 
> away from it because it's everywhere.
> 
> It is also frustrating looking at C forums and people thinking they are 
> too stupid to grasp something when it's language that could have been 
> better.
> 
>> As for new languages, there are a number of reasons.  Most of
>> them are not particularly relevant here.
>>
>> At this point, you may consider doing what Keith suggested, and
>> moving further discussion of your language to comp.lang.misc.
> 
> Sure, a pretty much dead group.
> 
> 

I disagree with Dan Cross, I believe Bart's language should absolutely
be discussed in comp.lang.c, and I'm keeping comp.lang.misc in this
discussion for the mentions of Rust.

Rust is a great programming language to make a C compiler, after all.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.misc

csiph-web