Return Styles: Pseud0ch, Terminal, Valhalla, Blue Moon.

Pages: 1-

The spread of C and UNIX

Name: Anonymous 2017-11-05 16:48

This article explains why C and UNIX have spread. Other programmers will use C, reluctantly, but Ctards will refuse to use anything else, not even C++. They use C for the same reason Muslims eat halal. It is religious dogma spread by the Ctard and UNIX cults.

Computer companies were like the West with Islam. They let C into their systems, into their ``countries'' so to speak, and buffer overflows spread, compatibility between languages was reduced from data descriptors for all types (a la VMS) to the types used by C, POSIX functions and UNIX-like shells were added, code became buggier and more obfuscated, and compilers did insane acts in the name of ``optimization''.

So if you want your language to spread, you have to be more intolerant than the Ctards. You must say ``If there is a single line of C, I will not use it.'' Just like peanut-free food, you can impose your will on the majority.

Name: Anonymous 2017-11-05 17:35

It is religious dogma spread by the Ctard and UNIX cults.
They became ``cults'' for a good reason, while they were not perfect, they worked.

Name: Anonymous 2017-11-05 17:41

You idea will not work. The software stacks are intertwined with C.
Operating systems, libraries, programs has to be rewritten:
not just replaced by C-free code, which doesn't eliminate the original.
Consider Linux: its a brand and a system built on top of C.
If you create an alternative CFreeLinux it will compete with Linux and its programmers.
You'll have to cultivate a culture of CFreeLinux and attract programmers to it, it will have to
sell your alternative language X as something better than C(not just as fast as good as equal to C but presenting a tangible advantage).
Its essentially the task of creating a new ecosystem from the bottom:
a few early errors and interest will fizzle out, do it slower and risk obscurity.
You can't just demand C-free code as if programmers choose their ecosystem by popular decree:you have to sell it as the better tool.

Name: Anonymous 2017-11-05 17:47

You also need the backing of a major corporation, systemd, for example is complete garbage, but the mainline distros adopted it due to underhanded political tactics, Poettering's ego and Red Hat's money. UNIX and C came about because of the work done at Bell Labs, backed by AT&T. So quality isn't really a factor at all, you just need huge corporate backing and memeitic influence.

Name: Anonymous 2017-11-05 18:50

UNIX and C became cults because they didn't work, but they were too intolerant to use something that does. The UNIX cult is able to pass off the inferior UNIX designs as the same thing as better operating systems, even though they're not. The cults ``evangelize'' by spreading inferiority until it is the only thing left.

The users of C and UNIX rewrote RFCs by refusing to adopt the solution correctly, not by being better. You don't need to be better. It's better to be better, but that doesn't have any effect on this phenomenon.

You don't need that either. All you have to do is be intolerant. C was created because they were intolerant to standards, like length-prefixed strings. Newer languages added a null-terminated string type because they are tolerant of C.

Name: Anonymous 2017-11-05 18:55

the inferior UNIX designs
Inferior to what? UNIX worked and Plan 9 only further improved it.

Name: Anonymous 2017-11-05 19:05

Name: Anonymous 2017-11-05 19:10

I don't think the Quran actually says anything about using C.

Name: Anonymous 2017-11-05 19:11

C strings won because they we the superior format
1.Unlimited length
2.Essentially a pointer
3.Length can be passed/stored as unrelated parameter/variable, the speed advantage of storing the length doesn't exist.
Length-prefix string:
1.A struct with length offset(different for each type of string).
2.Limited to 255^n char.
3.Requires special-case code to decode.

Name: Anonymous 2017-11-05 19:17

char youCantHaveLongPascalStrings[200000];
char CompileTimeStringLength[]="This string has a fixed, known length";

Name: Anonymous 2017-11-05 20:02

Name: Anonymous 2017-11-05 20:17

Lol, Nikita BTFO.

Name: Anonymous 2017-11-06 0:06

Most of the time, unlimited length is not an advantage. You might be able to make this argument in the days of 8-bit processors, but with 32-bit and even 64-bit architectures aplenty, the limitation is utterly irrelevant. If you have a four billion byte string, representing it as a continuous block of memory is doing it wrong.

Likewise, being ``essentially a pointer'' is not an advantage. It is completely meaningless unless you are a cetard who can't understand anything that is not implemented the way a cetard would implement it i.e. stupid. This very thing can be seen in your characterization of pointers with offsets as ``structs''. On just about any CPU nowadays, a dereference and a dereference offset by a constant have the same cost, but to the crippled C mind, the latter is a ``struct'' which feels slow because C is a retarded language that couldn't pass structs around for years and forces you to handle them the same way you'd handle an 800MB object. The next time you're about to spout some shit about performance, consider that the only ``hardware'' you seem to know about is the abstract C machine and not an actual piece of silicon. C isn't close to any extant hardware; it's just stupid.

3.Length can be passed/stored as unrelated parameter/variable, the speed advantage of storing the length doesn't exist.
And this, right here, is the essence of C-faggotry. There is no deeper thought put into it beyond some ``clever'' hack that (a) prevents sane behavior (b) is hilariously bugprone and/or (c) straight up doesn't even do the fucking job, but OMG OPTIMIZED THAT ONE EXTRA CYCLE THAT GETS EATEN BY MEMORY LATENCY WILL CERTAINLY MAKE UP FOR ALL THE RCE VULNERABILITIES.

Unix is a mental illness.

Name: Anonymous 2017-11-06 0:35

Most of the time, unlimited length is not an advantage. You might be able to make this argument in the days of 8-bit processors, but with 32-bit and even 64-bit architectures aplenty, the limitation is utterly irrelevant.
This is the excuse why software leads to feature creep and bloat with this type of thinking. EXCELLENT TROLLING, 8/10

Name: Anonymous 2017-11-06 1:19

Those who don't understand C are condemned to reinvent it, poorly.
Dynamic Array of Char
aOldString: Array of Char;
SetLength(aOldString, 5);
aOldString[0] := 'a';
aOldString[1] := 'b';
aOldString[2] := 'c';
aOldString[3] := 'd';

Name: Anonymous 2017-11-06 1:34

>Likewise, being ``essentially a pointer'' is not an advantage.
C strings are essentially pointers(memory blocks), that makes them format agnostic(see >>15 link), compact and fast.
You can memcpy them around, pass them as single variable, use any offset as start of new string,truncate them with a single char assignment:
char str1[]="this is a string";
char*str2=&str1[4];//substring pointer,try that in pascal
str[9]=0;//truncate the string in-place

Name: Anonymous 2017-11-06 1:42

Psst, pascal kids:
Fast(stack allocated), Variable-length Strings(with sizeof returning their size) as common extension:

Name: Anonymous 2017-11-06 2:04

Name a single situation where not being able to represent a 4GB+ string as a block of memory is a disadvantage. I'm being generous, 64-bit sizes allow up to 16EB. Doing things correctly isn't bloat and feature creep, but forcing everybody to reimplement basic language features on top of your broken ones causes it.

Format-agnostic except for the fact that they can't store NUL bytes? Is this Unix™-format-agnostic, to go with the Unix™-compatibility and Unix™-working?
You can memcpy them around
So you can with other strings.
pass them as single variable
So you can with other strings, if your language isn't called C.
use any offset as start of new string, truncate them with a single char assignment
Length prefixed strings can do the exact converse. There isn't any advantage of C here, just a low-level tradeoff that doesn't matter anyway because HLLs will implement substrings as pointer+offset+length or something similar anyway to allow memory sharing.

Name: Anonymous 2017-11-06 2:17

Its Okay to Write C

Name: Anonymous 2017-11-06 2:18

being ``essentially a pointer'' is not an advantage
Actually pointers are at the lowest level of abstraction, directly supported by hardware, which is an advantage. Any higher level string format is up to the developers.

Name: Anonymous 2017-11-06 2:23

Compiled code is also directly supported by the hardware.

Name: Anonymous 2017-11-06 3:01

So is assembly.

Name: Anonymous 2017-11-06 5:51

What's with the C hate? It's perfectly fine. Now, SEPPLES on the other hand...

Name: Anonymous 2017-11-06 5:53

what if I wanted to write memory safe code?

Name: Anonymous 2017-11-06 5:55

Then you write it so you don't have those issues. C is not a hand-holding language.

Name: Anonymous 2017-11-06 5:59

Name: Anonymous 2017-11-06 7:03

what if I wanted to write hand-holding memory safe code in a systems programming language?

Name: FrozenVoid !MhMRSATORI!!4OoxRUEgeA 2017-11-06 8:06

You get out of systems programming.

Name: Anonymous 2017-11-06 12:13

"just write it without the bugs"

Name: Anonymous 2017-11-06 14:26

Whom are you quoting?

Name: Anonymous 2017-11-08 3:11


Name: Anonymous 2017-11-08 8:22

but this doesn't promise memory safety. it promises that it's formally verified to comply with C standard, which does not promise memory safety.

Name: Anonymous 2017-11-08 8:24

check my dubs

Name: Anonymous 2017-11-08 9:48

Consider them checked.

Name: Anonymous 2017-11-08 10:07

thank you!

Name: Anonymous 2017-11-08 16:49

Back to the imageboards, please.

Name: Anonymous 2017-11-08 16:57

Exactly, C is not a hand-holding language. I can see why you redditors wouldn't like that.

Name: Anonymous 2017-11-09 0:36

C is the language of Satan.

Name: Anonymous 2017-11-11 14:57

C is the language of Satan awesomeness.

Don't change these.
Name: Email:
Entire Thread Thread List