/tech/ - Technology★

>>980707 (OP)

Literally impossible, C is digital perfection incarnate.

>>980708

/thread

>>980708

>muh c

rust is better

>>980711

> CoC

> Garbage Collection with large overhead

kys

we need to start over. C is flawed and so is the compiler.

luajit almost got it right.

packages should be loaded in order and relatively without any headers or project file nonsense.

include should be a function.

>>980719

No we need headers we should always use headers

>>980720

in main.c:

lib.something()

"lib" is loaded, including everything it needs, then everything else is loaded in case it has side effects.

Just remove librust and delete rust compiled programs. You will be fine.

>>980707 (OP)

Macro declarations should have a syntax like: #define MYMACRO(a, {b})

a is a normal argument, b has to be written in curly brackets (compiler error otherwise) and can contain commas. This allows you to pass blocks of code, array/struct initializers to macros.

delete it all and add Haskell

How about interpretive C?

Have GCC running as a VM, with access to kernel via function calls, and host a userspace for everything else.

>>980762

I think we already have enough interpretive languages.

>>980741

I bet you can't write an interrupt routine in Haskell, you little faggot

big brain: ATS

smol brain: Zig

unironically though, I might add Zig as an output target for ATS. Maybe next year.

ATS lets you write everything you can in C, exactly as you can in C, but brings a ton of static checking to the table, so that you can be sure that some code can't run off the end of an array, or dereference a NULL pointer. And that's just the start.

of Zig, my first impressions were poor because it does a bad job selling itself, but it's again a language that can work hip-against-thigh with C while improving on it. Zig for example has compile-time capabilities and guaranteed inlining that let it do stuff with code that you'd need the preprocessor for in C. Zig just goes more in the direction of comfiness than in safety, although for safety it still has integer-overrun checks for example.

You can use both of these languages now, but neither is super mature. In particular, neither document their standard library yet.

>>980712

>Rust

>GC

what are you niggerfaggots on?

>>980844

RAII is still a GC

replace the preprocessor with a module system, templates, and proper compile time introspection

>>980707 (OP)

>we write a proper compiler.

"Someone who is not me will hopefully write a compiler."

Proper arrays, templates and better multibyte encodings support (other than converting to gay wide chars).

Extend preprocessor, maybe make m4 the standard.

Add lambdas from C++.

Add namespacing from C++.

Purge unsafe functions (gets, non-"n" variants for string.h functions).

Add some way of keeping track of array lengths.

???

Profit!

(Not really C related, but I wish Linux gave you the ability to drop to debugger when a program crashes, without necessarily running it from a debugger.)

sudo apt-get install vala

done

>>980964

>make m4 the standard

autoshitter detected

>>980708

this

>>980711

rust is for faggot jews, so it should be perfect for (((you)))

>>980923

>templates

>>980946

>vectors

>>980964

>lambdas, namespaces

You do that c++ already exists, yes? Go use this instead.

>>980994

You know, if C++ was only C with classes, it would be used. Too bad a loser that never did program anything of value made it.

>>980723

>lib.something()

>in main.c

Is that a function being called though a function pointer inside a struct called lib or is it that the C hater can't into basic c programming? My money is on the latter.

>>980964

>Extend preprocessor, maybe make m4 the standard.

No, you should see the sick abuses in some of the code. eg. 3-4 layered macros used for function definitions with ##, # and variable lengths of arguments. I could not use any search functionality to find function definitions and had to spend fucking hours deciphering those layers of shit before even having any idea of what the function does.

I think this was in the iw code somewhere.

>>980707 (OP)

C is really an extensive language that lets programmers have nearly full reign on the computer. Those who complain don't understand how the compiler or interpreter of their languages work. They complain about memory management mostly, but that is entirely laziness on the programmer. Memory management is not difficult, especially with C. How do they think all those other language compilers/interpreters were made: in assembly?

>>981042

In c++, mostly

>>981045

(after RIIR)

>other language compilers/interpreters were mostly made in Rust, anon.

>>981042

>y-you are just lazy

When I am programming I would rather focus on how to solve the problem rather than how the computer should solve the problem which is the job of the compiler. Would you rather concatenate to strings by:

1. "Hello " <> "World"

2. const char *hello = "Hello "; const char *world = "World"; const char *res = malloc(strlen(hello) + strlen(world) + 1); strcpy(res, hello); strcat(res, world); return res;

In the first I simply describe that I want to append one string monoid to another, but in the latter I have to do all this busy work of creating buffers, and copying stuff into them.

>>981049

see >>979788

Yet another situation where gnu has already extended c so we dont have to.

>>981049

Write your own libraries. Problem solved.

>>980707 (OP)

Add common structures like trees, hashmaps, and graphs in the standard library so my shitty fizzbuzz program that relies on 3 different libraries doesn't have 3 versions of these structures with their associated methods thrashing my cache.

Also replace the preprocessor with an actual programming language like js.

>>980707 (OP)

I'd love a golang-style single-function built-in server. Something like

err = listen(8080, &responseStruct, &otherShit)

>>980707 (OP)

Range based for over arrays.

Why?

Take a look at a common way:

// Crufty, and if you malloc array after compile-time, it gets more crufty. The attack surface widens. Try to count by other than 1's, it's easy to make off by one error.
for (int i = 0; i < sizeof(array) / sizeof(typeofArray); i++)

Instead, can do:

for (typeofArray atom, array)

https://github.com/combinatorylogic/clike

>>981094

>what are libraries

>>981049

your programming problems dont require c if the nuances of const, pointers, and libraries just get in the way

What do you think about some kind of macro system where you can overwrite C syntax?

For example

typedef struct Something {
	int x;
	char* name;
	float foo;
}
Something niggerFunction(Something me, int number) {
	me.x += number;
	return me;
}
#syntax (Something, '+', value) \
	niggerFunction(Something, value)

Something faggot;
faggot = faggot + 500;
// the above turns into following:
// faggot = niggerFunction(faggot, 500);

>>981181

So almost no software then.

>>981191

what are you trying to say? you want to be able to extend the syntax like >>981186 suggests? because, if you are talking about enhancing the macro system, we are now talking money

There's only 2 things I want. Default values for structs, and syntactic sugar "methods".

typedef struct gaystruct {
	int health = 100;
}
void gaystruct.lynch (gaystruct* this, int strength) {
	this->health -= strength;
}

gaystruct op;
gaystruct op = {.health = 100}; // identical to above due to default value
op.lynch(10);
gaystruct.lynch(&op, 10); // identical to above

https://nim-lang.org

Any big and radical features are definitely out of questions, there's a good reason why all C extensions were relatively small.

As convenient as it may be, new string type would probably result in a complete mess unless it was compatible with the current ones. Something that's easily and concisely converted both ways might be acceptable.

>>981090 would be worth it, but maybe make it optional, so that there's a standard way to check whether it exists, because small/minimal platforms and implementations probably would not implement it either way.

>>981208 isn't terribly invasive and does make stuff more readable

RAII could be worth it in some form, but that might be pushing it.

Namespaces.

No overloading.

Templates are nice, but seeing what templates did to C++, there would have to be something preventing template spam. Maybe have the whole special templated header and force people to define the types during inclusion like this

/* footemplate.hh */
#template A B
struct foo<> {
  A a;
  int i;
...

/* main.c */
#include "footemplate.hh" {int, double} "_intdouble
...
  struct foo_intdouble x;

>>981225

>no overloading

Ups, meant no operator overloading.

>>981049

>muh semigroups

>>981186

>using thatSyntax()

kys

>>981230

fuck_off_larper(YOU);

>>981231

NoYou(faggot)

>>981230

>arguing about typing preferences

non-programmer detected

>>981233

This syntax deserves all the hates that it gets, it's the ugliest shit ever and every time I have to use SFML, Irrlicht, Bullet Physics and many other libraries, I have to stare at this shit. Either do_this() OrThis() but not that halfAssedSyntax().

>>981234

>hes a wannabe gayme dev

that explains it. fuck off to /v/

>>981235

Fuck off to india if you want to code like a pajeet.

>>981236

Look kid finish up school, fail to get a game dev job, put 10 years in the real industry, then come back.

>>981237

Nobody needs 10 years in "the real industry" to know that you code like shit.

>>981241

OkBudSure_Thing()

>write serious effort(-ish)post

>people argue about naming conventions instead

This is worse than /g/, they would at least make a logo.

>>981229

It's mode specifically a monoid as you have mempty = "".

You can't fix it.

Get rid of postfix operators.

Change (function) pointer declaration syntax.

Change assignment from = to :=.

Better variadic functions or none at all.

Forgot the standard library ever existed.

Incorporate a better means of cooperative tasks (plan9 libthread).

Have the stack programmable for user supplied garbage collection (precise), and exceptions libraries.

No shitty preprocessor, use real module declarations with explicit import and export.

Standard library should have hash tables, lists, vectors, but no trees or graphs.

Meta programming is a maybe.

>>982127

Also, standardise computed GOTO.

Allow functions to be referenced before declaration.

Nested procedures are another maybe.

Get rid of union and enum, substitute with proper tagged union.

Structures should be abstract, no need to worry about packing. (Abi concerns arise however).

No bit fields.

Top level expressions should be permitted and be implicitly invoked at program entry, no need to manually initialise libraries, just import them.

Parameters/special variables from common lisp/scheme preferred to raw global variables.

>>982188

Multiple return values would help reduce the need for pointer arguments.

>>982198

Return a struct with a variable stating the type and a union holding the value you want returned. Not difficult.

>>980856

So are stack frames

>>980994

>not using templates

Compare qsort's performance to that of a templated sort and stop being retarded.

>>981042

>C is really an extensive language that lets programmers have nearly full reign on the computer.

>this is what larpers genuinely believe

So I don't have to give you another (You) try implementing a context switch or checking flags in C. The only thing C gives full access to is the C abstract model of a computer.

>>982215

Use the asm keyword if you have the absolute need to check flags. As for a context switch, why would a struct not work here to preserve state?

>>982228

>asm

Technically in the standard as an extension, but implementation defined.

>struct to preserve state

You need asm to access the registers.

>>982215

Just tested it, macros and templates lead to equally quick qsort functions (at any optimization level). But the C version compiles twice as fast. C++ BTFO

Arguments against function templates:

> Functions that don't operate on variable's content, but instead on the variable itself, can easily work with use of void*. Moreover, the size detection can be very simply made with use of sizeof.

> Functions that operate on the variable's content that can work with generic functions usually are completely unsuitable for abstract types, which require separate functions for their handling.

>>982571

> Functions that don't operate on variable's content, but instead on the variable itself, can easily work with use of void*. Moreover, the size detection can be very simply made with use of sizeof.

Sometimes, you want to avoid passing pointers and passing by copy is more desirable, not least because it simplifies memory allocation.

> Functions that operate on the variable's content that can work with generic functions usually are completely unsuitable for abstract types, which require separate functions for their handling.

That's a fair point, though it doesn't invalidate the other use. Moreover, the templating system could allows for automatic inference of method names for the type (and fail compilation if it doesn't exist), kinda like TYPE##_to_string in cpp. This isn't the most important use tho.

>>982555

Most of my recommendations are existing extensions provided by gnu.

They wouldn't require significant restructuring of an existing c compiler, it's not like I'm suggesting closures, templates or object systems.

The feature is want most is modules/namespaces, I would redact top level statements/expressions and special variables however.

Improving a language requires breaking compatibility while maintaining the "spirit of the language", extending it results in people using the old crusty methods and bloated specs like c++.

>>980708

kys

>>980711

kys even more

>>980734

Macros should die in a fire first and foremost.

>>981225

>Templates are nice, but seeing what templates did to C++, there would have to be something preventing template spam.

Compile time CAPTCHAs?

>>981242

DELET THIS

>>982753

As a huge fan of macros I agree that they don't really belong in c.

But the temptation still exists to use them.

My best use of macros in C was for a 6502 emulator, all Opcode's were defined in a header file that was shared by the CPU core and debugger, this technique is called "x macros".

It let me change the interpreter from direct threaded, indirect threaded, switch dispatch, etc. with minimal changes to code.

The only other good use i know is to have coroutine's / state machines using a macro YIELD defined like

#define yield
{
  _label_ cont;
  state = &&cont;
  return;
cont:
  0;
}

A coroutine would define static void *state and jump to it right away.

Although it worked, it would cause problems with the optimiser and obviously doesn't preserve local state, but is much better than makecontext/setcontext.

I originally seen a variant of this in "game programming gems" that made a DSL for state machines in c that did message passing.

The only reason I mention this is because I personally can't think of a better way to do these tasks (in c) without loads of boilerplate.

Perhaps the ideal way is to generate programmes in whatever language you prefer in the style of yacc/bison?

>>982813

I had a fun time writing this last night. Hellish abuse of macros, ugly as all hell, shouldn't be used in serious programs, but fun to code. I only wish a macro call could itself define macros, would make certain things much prettier.

https://pastebin.com/krUV32vY

Obviously I need to add a way to pass data to the coroutine.

In their most basic usage, macros work. Using them to define simple functions that operate irrespective of types (eg #define ABS(c) ((c)>0?(c):-(c))) is fine. They are way to fragile to use for more complicated things, which is generally when you should start thinking about other languages. I like the idea of doing a simple coroutine thing, but I can't think of a way of keeping it simple enough to still be c, while complete enough to be useful.

>>982947

>>982813

why haven't you learned Zig yet? If I were either of you, instead of me (into ATS), I would be crying with joy over Zig. Manual memory management, doesn't have macros because it doesn't need them with its comptime capabilities (that extend to implementing printf, parsing its format string, and considering what to do with the types of arguments to it--all at compiletime, in normal Zig code), can write type-generic code without going full templates, etc.

The author says shit like "I'm not smart enough to be productive in Rust" without shame. Zig is literally your language if C is 90% acceptable to you.

>>982716

>remove frequently used operator

>change the most frequently used operator

>reinvent the whole stdlib

>remove the frequently used cpp

<it's basically just an extension guys, trust me!

Yeah, totally. You just break almost all C code in the process, without easy means to fix it.

I'll work on the logo.

>>983019

++go[fuck++]--, yourself

>>983166

I may have given you benefit of doubt, if it stopped at post increment. But when you suggested replacing = with := purely for looks, as a language extension, I knew you're an idiot.

>>983171

C is a perfect language. In 1000 years we will all use c. No improvements to C or Unix can be made.

>>983171

Be honest, you've accidentally used assignment in place of equality more than once.

>>983178

And the compiler issued a warning. Yes, if I was writing a new language, I might consider it, but only a complete and utter moron would think that turning use of the single most frequently used operator into a syntax error is a good language extension.

>>983216

so don't make it a syntax error in old code. make it a syntax error after an #include <std/2018.h>

>>983218

That's stupid and introduces completely unnecessary complexity.

>>983216

You're hurting my feelings ;_; which violates my proposed CoC for nuC.

Seriously though I'm not going to debate banal lexical conventions.

It's not like anyone here is gonna read this thread then go hacking tcc.

>>983263

And before I start shitposting again I might as well leave this here

http://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9

>>982188

>no bit fields

What is wrong with bit fields?

>>983264

Those plan9 fuckers really thought things through. Too bad most of this stuff is OS level not language level. Basically impossible to take advantage of it without installing 9front. The few language level changes have filtered down into modern c. Utf-8 in particular is the standard for unicode handling (when c programmers bother to support unicode).

>>983279

since processors work with bytes that should be the atomic unit. let me tell you about lisp machines...

>>981234

>wahh the first letter isn't uppercase

>>981049

Then don't use C, which is for low level code. nignog.

>>983330

That's the dumbest thing I have heard all day.

Protip: not all architectures necessarily deal in bytes. Also there is that thing called network, where you can send 8 as many booleans per packet with bitfields

This thread is now almost a week old. How's your new language going?

>>983570

Nowhere, because everyone either has a different idea of a new language or describes what C++ currently is

How about a parenthesised version of C with macros to allow for experimentation?

I started such a program months ago and it was a working POC but I abandoned it.

The main issue was the type of macro language to use, I used syntax-rules which might not be the best but is the simplest hygienic solution.

Here's something that isn't exactly an extension, but I've thought about it occasionally. It clearly isn't that important, but part of me wishes that @ was used for pointers instead of *. It is literally an address sign, it seems like the obvious choice. Maybe there is a historical reason, but I have only seen newer things using the @ character.

>>983687

@ is a pain in the ass to type in some keyboard layouts (Alt Gr + 2). People will steer even further away from low level languages if they have to keep typing that every 5 seconds.

>>983689

Well, C syntax sucks in European ISO QWERTY keyboards and nobody complains about that. C-style languages are amongst the most used programming languages in Europe, as well.

The choice of * is terrible, though. It is used as a type modifier (which doesn't modify the type, but the variable itself, because some guys at UNIX labs thought writing int twice was too much typing), multiplication sign and dereferenciation operator. The asterisk is so overloaded it fucking sucks. We should all go back to keyword-based languages; no operator nonsense, and equally uncomfortable in every keyboard layout, but highly autocompletable

>>983691

function whynot arguments endarguments begin

string myvariable set "just no"

print myvariable

end

>>980719

>include should be a function

That would mean loading libraries at runtime.

Hello /tech/!

I am currently designing an operating system called CabalOS!

Here is a typical program in NefariousC

IDENTIFICATION DIVISION
PROGNAME <"displ_on_scrn">
AUTHOR <"Anon">
LICENSE <"Proprietary">
CONDUCT <"Contributor Covenant">
END

FUNCTION DIVISION <"fuckyou">
  SECTION ARGUMENTS
    ABYSS 
  END

  ✡This is a comment.
  ✡ABYSS is a special variable that has the same meaning as "void" or "NIL" has in other languages. 

  SECTION BODY
    PRINTS(STDOUT, "fuck You\n")
  END
PERISH

N.B. BaphometOS doesn't support keyboards. You must either use punch cards or use the mouse and the on-screen keyboard.

>>983753

Retards will end up fucking it all up again and you'll have wasted immeasurable amounts of time.

>>983757

Or you can remove their ability to do so.

>>983737

I'm against his suggestion, but isn't that essentially what ld.so does?

>>983949

I think Processors before Pentium 2 are safe.

A Pentium 200mhz with 64mb of ram is way more usable then any z80 or 68k will ever be

>>982127

>>982188

You should look at Ada.

>>983753

>emit "," instead of "."

That's typical UNIX text bullshit. If the shader code was binary, not only would parsing and code generation be faster, but you won't have to worry about details of syntax. When UNIX weenies think of binary, they think of hex dumps, but it just means a data structure that uses binary codes instead of text. Text is for humans and binary is for computers and programs. Most of what sucks about UNIX comes from using text for computers, which sucks. If someone has a stupid format, like ls and ps, they can never change it because UNIX pipes mean that any program that produces text might be used by another program instead of only being read by a user.

>the world is fucked beyond repair.

C is not the world even though UNIX weenies believe it is.

   The idea of using in-band "escape" sequences to do
   out-of-band control functions is so far from being
   Unix-specific that I'm not sure what you're trying to
   say....

Suppose every time you wrote a file out to disk you had to
worry that the disk controller would try to interpret some
of the data you were trying to store as commands that might
reposition the disk heads.  You might have a file named
something like "/etc/diskcap" that every program that used
the disk would have to read and decode before it could use
the disk safely.

Weenies would tell you it was your own fault when you
destroyed your file system because you accidentally tried to
store some data that contained some disk controller escape
sequences.  You might feel that there was an important level
of abstraction missing, but the weenies would
condescendingly explain that ``in-band "escape" sequences''
were a well established idea.  When you explained that
twenty years ago there were operating systems that didn't
have this problem, they would reply: ``What problem?  I'm
not sure what you're trying to say.''

I understand that our representatives at TLA are now in the
process of re-educating Mr. DE.

By the way folks, the traffic on Unix-Haters seems to be
increasing of late.  I'm not threatening to do anything
about it, but you all might want to think twice before just
firing off a quick note to this list.  Let's keep the volume
low and the quality high.

>>983953

Nope. Everything 386+ has SMM.

>>984059

Ada suffers a lot of the problems C has and is basically dead. Not to mention feminist bait.

We should look into Forth, Clojure, or Go.

>>983753

This is what happens when you try to use a low-level "portable" assembly language to write a properly internationalized user application. C's only useful purpose is bootstrapping compilers for better languages.

>>984066

>We should look into Forth, Clojure, or Go.

Which of these three languages have you started looking into?

>>984078

GCC has a front-end for Ada, brah. You don't have the semblance of a point. You are just an ignorant shit poster.

>>984082

No Go: it's from the same people who brought us C.

>>981225

I prefer the golang style of using "interfaces" instead of templates to produce generic code.

Also, most of GCC extensions are good, like union casting, ranges for switch/case and typeof operator.

>>984089

Go was developed to remedy the problems that were present in C and throws out a lot of the old mainframe shit.

>>984101

>old mainframe shit.

such as?

>>984107

Well, strings actually exist for one.

Another language worth studying is golang or vala.

>>984111

What makes c strings "mainframe shit"?

>>984082

>Forth

Forth is certainly a much better language than C - it can go low, it can go high, it can look like a DSL, you can graft on advanced features (OO, GC, TCO) more easily than you'd believe.

but, Forth is a bad language 'for other people'. It doesn't help you at all, and the stack and all the weird things words can do make it inherently hard to read. And in 2018, there is still not a libre Forth implementation with quality comparable to gcc - not even if you put optimization aside. There's not even an implementation as good as Chicken Scheme, for Scheme. So Forth can only be one of the tools in your toolbox, and that only if you don't mind that people will rather rewrite your Forth in some other language, rather than collaborate with you.

>Clojure

is shit. Use CL instead.

>Go

is shit. Use C instead.

>>984066

>Ada suffers a lot of the problems C has and is basically dead.

Ada does a lot more for the user. Ada has packages, generics, exception handling, programmer-defined numeric types, discriminants, real arrays, interfaces, multitasking, and standard containers. Ada some of the problems C has, like not having a GC and some static compile-time limitations, but Ada has better solutions than C does, like containers and generics.

>>984071

>a low-level "portable" assembly language

That's marketing bullshit even though today it makes C look bad. Originally, UNIX weenies were saying UNIX was written in a high-level language just like PL/I in Multics and Lisp in Lisp machines. The "portable assembly" slogan was the excuse for why those languages do a lot more than C does, instead of saying AT&T employees didn't know how to implement a better language.

>>984078

Most computers before the 90s had nothing to do with C and UNIX, even PCs and Macs. UNIX weenie culture was created by AT&T shills in the 80s. They wanted you to only focus on products that would get them more licensing fees. This is no longer true, but the mentality still exists even though weenies today have no idea why.

>>984101

>throws out a lot of the old mainframe shit.

The PDP-11 is a 16-bit minicomputer. There was no "old mainframe shit" in C in the first place. If there was, C would be more like PL/I, especially with decimal types, strings, and record I/O.

>>984114

>What makes c strings "mainframe shit"?

They're not. Mainframes have instructions for counted strings because the main programs were in Cobol and PL/I and had a lot of string handling, so C strings would be much slower on a mainframe than on a PDP-11. They have nothing to do with the PDP-11 either. C has null-terminated "strings" for the same reason the UNIX kernel would panic on errors (which, funnily enough, are right next to each other in the UNIX source). It was a quick hack that started when UNIX was written in assembly and wasn't meant to be real software. Imagine you're using a shitty assembler, like UNIX as. You can write <UNIX sucks\0> for a null-terminated string instead of having to count bytes.

https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1/u0.s

2:
	</etc/init\0> / UNIX looks for strings term, noted by nul\0

panic:
	clr    ps

https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1/u5.s

	mov	(r2)+,r3 / word of free storage map in r3
	bne	1f / branch if any free blocks in this word
	add	$16.,r1
	cmp	r1 ,(sp) / have we examined all free storage bytes
	blo	1b
	jmp	panic / found no free storage

If your disk, tape, or drum runs out of free storage, UNIX would panic. Now it doesn't matter that you can't save whatever you were working on because it's gone. A real OS would pause the copy and let you delete or move files to free up space, then it would let you retry.

>> I once went to hear a talk by Thompson at MIT.  Thompson
>> said one of the professors had said to him, "I hate you.
>> UNIX stopped all research in operating systems."  Thompson
>> apologized.

    Actually, it's more the hardware vendors fault.  For
about 15 years now, the solution has been to throw more
hardware (memory, cpu cycles, graphics co-processors, and so
on) at the users.  UNIX has the dubious advantage of looking
more like "a real operating system" to the microprocessor
crowd (who are used to CPM/MSDOS/etc).

    So they think that by installing unix, it makes their
system into a "real computer".  In fact, unix is just a
minicomputer operating system (at best).  So what they end
up with is a box with more MIPs than a 70s mainframe, more
memory than a 70s mainframe, more disk than a 70s mainframe,
and a 70s minicomputer operating system.  And it runs about
as fast as a 70s minicomputer, asn supports as many users.

The wonder is that anyone is surprised.

Prefix and postfix operators are abominations that easily lead to runtime errors. Gut them and remove them entirely, it should be fucking illegal to make use of them.

Just use += you fucking troglodytes.

>>984487

prefix and postfix operators are convenient shorthands with no downsides whatsoever.

you think they have downsides, and that you have removed those downsides by removing these operators, because you are a moron.

>>984489

Sacrificing clear and concise code for the convenience of having to type fewer characters is how I know you're a fucking retard.

You can use += 1 for a nearly equally sized shorthand. There is no upside to prefix and postfix other than autism. They are sinful operators that do more than what they should (adding 1 or subtracting 1) just to appease faggots who want to make everything look pretty and reduce code text. Code text doesn't matter, what matters is code readability, and it is often not clear what will happen to a call stack with a prefix or postfix in it when it would be immediately clear if you weren't a mong and used += instead. Furthermore, what really matters are cpu cycles, and the goal of using these operators is to increment or decrement a variable, and both ++ and +=1 create the same number of assembly code lines for the operation of adding 1 to a value.

It's syntactical bullshit that is completely unnecessary and only has the additional effect of accomplishing the same thing as += 1 with the added downside of being able to easily produce bugs.

Downside being that they fuck with the perceived order of operations. If you want to do two things with one operator, back the fuck up and use multiple sets of parentheses so that your intentions are EXPLICITLY FUCKING CLEAR.

>>983010

Can it move for great justice though?

>>983178

nevar

>>983737

>he never heard about constexpr functions

>>984059

>If the shader code was binary, not only would parsing and code generation be faster, but you won't have to worry about details of syntax.

You literally just described SPIR-V, moron.

>>984872

it turns out that llvm's built-in support for great justice is quite lame, so zig is planning to do that itself, but it'll have to wait for the self-hosted compiler

I would take complaints about C more seriously if there was a viable alternative that doesn't kill performance, and people bitching about it didn't frequently only do so as an excuse for their own laziness and inability to do simple things correctly. It's always possible to make something better than what we already have, but the sheer amount of incompetent people that think they are much better than they actually are means that everything else very unlikely to improve nowadays. Everything that doesn't stay the same will probably only get even worse. Technology is so shitty and stagnant at this point that unless there is a collapse that somehow gets rid of all the people getting in the way, nothing will ever be reinvented well.

>>984963

>viable alternative that doesn't kill performance

no GC? ATS, C++, D (betterC), Rust, Zig

yes GC? ATS, Chicken Scheme, D, LuaJIT, Nim, OCaml

they all have their problems. They all have reasonable performance. What other concerns do you have re. viability?

>>984963

>wah wah technology is shitty and stagnant and never changes

>but people who complain about C are just being lazy though

You might without realizing be one of those people in the way of the much needed change you're talking about.

>>984152

Why does everyone here shill for chicken scheme when chez scheme is now free software?

>>985221

Chicken Scheme's always been free software and it's really, really good. And, I don't know anything about Chez Scheme.

>>980708

lol no atomics

>>985331

Chez scheme is super fast and jit compiled. Now that it's free software it is clearly the superior scheme implementation

>>984967

These are not alternatives because they're a lot more abstracted and complex; if you spend your time looking at the retarded doc (which isn't in manpages, of course) to find how to do something instead of having the means of easily reimplementing it, your language isn't a C replacement.

Jai looks like an alternative, but it's likely to be vaporware.

>>985485

>which isn't in manpages, of course

the documentation certainly sucks for all of them in comparison to C

but for many of them, the docs aren't bad. C will never see much improvement, but a single person can massively improve the documentation for a language in a week

Zig and OCaml are relatively simple and understandable. Zig more obviously, but OCaml, really. Take some time to appreciate the type system. It's not Haskell, where people think their ability to tolerate doing things badly and obscurely is a proof of their intelligence.

LuaJit and Chicken Scheme are certainly much more abstracted. That's a trade-off for them being much more pleasant languages. But I list them because they don't have unnecessarily shit performance. There really are a lot of applications where you could say, eh, instead of C, I'll use this.

ATS, C++, and Rust are more in the nightmare territory. C++ because it's so huge. Rust because the language is awful. ATS because the tooling is awful and there are multiple sublanguages to learn and the most familiar of those languages is basically OCaml. But with the nightmare you get the biggest benefits. There are really compelling reasons to venture onto nightmare territory. With ATS you can write runtime-unchecked code that will never see a buffer overflow, and even if you drunkenly edit an overflow bug into that code, you'll just get a compile time GTFO-with-that.

>Jai

take a look at Zig. The documentation is "here are some implementation notes" level, with nothing at all about the extensive stdlib yet, but it's a target for the next release. Zig at least ain't vaporware, and you can do cool stuff with it. https://www.youtube.com/watch?v=mdzkTOsSxW8 starts with Zig's comptime stuff, AKA the reason he started hacking on a C compiler to make a few small improvements to C because that's all he thought C needed.

>>985485

>>985489

>Jai is vaporware

>but Zig isn't

Jai has quite a bit of push behind it. Jonblow knows a lot of people in the games industry and plans to use it for games going forward in his game studio, not to mention release an medium sized open source game/engine made with Jai.

>>985499

>this vaporware is very credible tho

I believe you anon

I just don't personally care about Jai

although it seems other language designers care about it, since that 'delay' thing supposedly came from it and has already infiltrated multiple other languages

>>984464

okay lisp machine friend, let's compromise. Let's make an equivalent of C with S-expressions.

(#include "stdio.h"
  (#include "stdlib.h"
    (defn int main '(int argc) '(char * * argv)
        (printf "Hello, world!\n")
        (return EXIT_SUCCESS)
    )
  )
)

Look, more lines of functional lisp code than have been written since 1970.

>>984496

If you think that replacing postfix operator with full inline code will have any readability advantage, you're an idiot.

>>985364

>lol no atomics

No stm either

>>985621

>nesting includes

Consider another career.

>>985699

>I want the features of a database built into my programming language runtime

t. retarded memelangs like haskell

>>985774

It's what lispfags deserve.

holy crap dude: https://godbolt.org/z/w6yxPs

>>985853

cfags BTFO! all the c++ objections are 20 years out of date at this point.

>Compilers are free. Versions exist for Linux and Windows, although the Linux port is currently incomplete 

And no Turing, thus ignored

Slightly unrelated but quick question: Is glib2 a good extension to the standard library to reduce the boilerplate required when writing simple programs? I've seen that a fair number of projects use it, but by far not everyone uses it, so I'd like to hear from other people what they think about it.

From what I've seen it includes a lot of primitive types and utility/portability functions as well as sane error handling, all of which sound very nice.

Mexicans.

>>985774

I was just writing it in a way that appealed to lispfriends. It's also why I included stdlib.h even though I didn't use it in the code. I might need it later.

>>984082

Go has replaced all of my Python shit. It's as easy (or easier) than Python but is more performant and is compiled. Well-written Go is about 80 percent as fast as well-written C.

>>985973

I usually don't like it just because of the size. If you're going to re-write about half of it, just use the library. Otherwise, roll your own. The documentation for glib2 is also occasionally misleading.

>>986281

The size is imo a non-issue when most if not all linux systems ship it, and although I agree with just rolling your own when using a really small part of it for a very specific purpose, I was mostly asking about it in terms of getting shit done quickly while not having it hold me back when the project grows larger.

Thanks for your input, though. I guess I just have to git gud at C before I feel more comfortable using it, anyway.

>>986244

>easier than python

>pointer and type bureaucracy

kys

>>983691

>>983732

Bullshit, Lua does it just fine:

function justyes()
  print("Not that many words because that would get hard to work with.")
end

>>986476

>functionname()

>print(calling_with_args)

>"string"

yeah it's crazy how lua manages to only use keywords for syntax

>>983691

>>983732

Problem with keyword languages is that you have to dance around 500 keywords when you name your own variables, and you basically NEED syntax highlighting to read it at a reasonable pace. Something like pointer casting/dereferencing will also become a nightmare to read.

somestruct* somenump = *(somestruct**)(somepointer);
vs
somestruct pointer somenump set derefer cast somestruct pointer pointer endcast somepointer

>>986774

It's not a big problem anyway, all sane programmers just use eng layout regardless of whether it's their first language.

>>986778

That's not what I mean. I mean that "switch" and "case" are actual words that you might want to use as variable names, but since they're syntax words you now have to use something different like "thecase" or "myswitch". If everything in the language is a word then the problem becomes a lot worse.

It's non-English speaking Pajeets that are affected least negatively.

>>986778

>eng layout

<not being a part of the unicode symbols for operators master race

>>986904

>unicode symbols

>at all, ever

>>986932

this

>>986904

you're just stretching compile time for a weird delusion

>>986932

keyboardlet detected

>>986904

:^) https://www.youtube.com/watch?v=0j74jcxSunY

>>987107

<computerphile

No, I'm talking about using it in the source code of your program. You can use λ when defining a lambda, or ℤ when you are talking about integers. When you want to use an arrow you can just use → instead of ->. You can actually write out equality operators like ≤, ≥, or ≠. There's tons of unicode characters that are useful for programming.