/tech/ - Technology★

yeah i sure love writing my own data structures from scratch everytime i use c, great language!

You create a thing

Its core is super optimized Assembly

Rest is C++

neat future

>>969102

>Patching st takes absolutely no time at all. It's just as easy as making changes to your vimrc file.

>I don't know a lick of C, and yet I am able to run patch and make. Fuck right off.

I don't know a lick of C

I don't know a lick of C

I don't know a lick of C

>>969540 (OP)

C is great but not perfect. There's features that could improve it and make writing programs more comfortable without sacrificing the level of control you have, but they will never get implemented because C is not being developed beyond some fixes or whatever.

Syntactic sugar methods, destructors, namespace related mechanics, no headers, syntax for string/array concatenating, default values for structs/functions, optional function arguments, better variadic arguments, better type inferring so you don't have to cast everything all the time (like if you send a struct to a function, you have to send (sometype){x, y, z} instead of just {x, y, z}), deprecating functions/structs without removing them (see: gives compile warning if used), more condensed for loop headers...

Yeah ok bud keep LARPing, C is fun but it's neither great nor practical. Go learn D.

C's also great in that it really is the "write once, run anywhere" that was the failed promise of Java. Everything has a FFI to C, and I've even started compiling my C to webassembly as an experiment in replacing javascript. One language for everything is fucking awesome.

When MS said "It's a feature, not a bug" you all mocked it but when someone exposes C (or Linux's) flaws then "The user is stupid."

Your cognitive dissonance shows. Newsflash: you're one of those retards you complain about.

>>969574

Unlike Microsoft, C actually provides value to mankind: it is platform independent and yet low-level like no other language.

>>969593

<Cognitive dissonance is OK if we do it

>>969540 (OP)

polnigger C LARPer: the post. i'm just going to post this every time i see one now

>>969542

t. JS programmer

>>969599

And instead of posting a similarly portable and low-level language you're wasting everyone's electricity and time with that post.

>>969553

uhh C99 added variable length arrays n sheeit

>Syntactic sugar methods, destructors, namespace related mechanics, no headers, syntax for string/array concatenating, default values for structs/functions, optional function arguments, better variadic arguments, better type inferring so you don't have to cast everything all the time (like if you send a struct to a function, you have to send (sometype){x, y, z} instead of just {x, y, z}), deprecating functions/structs without removing them (see: gives compile warning if used), more condensed for loop headers...

fuck you. kill yourself so we never have to deal with the possibility of C being fucked up even more in this way. type inference in C is a terrible idea

>>969607

C isn't easily portable, and especially not for any LARPer

>hurr durr it segfaults when I run it on any of these 3 archs what's the problem!!!111

>i can fix it with uint32_t XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

if you spend more time arguing about what language other people should use than actually making software yourself then die

A very insightful contrarian comment about the nature of C appears in an AlexanderStepanov (C++ STL designer) interview by Al Stevens in DrDobbsJournal (3/1995) (http://www.sgi.com/tech/stl/drdobbs-interview.html):
"Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time---but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it." (emphasis added)

>>969615

Better without code tags (these didn't give boxes like that without JS, before):

A very insightful contrarian comment about the nature of C appears in an AlexanderStepanov (C++ STL designer) interview by Al Stevens in DrDobbsJournal (3/1995) (http://www.sgi.com/tech/stl/drdobbs-interview.html):

"Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time---but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it." (emphasis added)

>>969609

>C99 added variable length arrays n sheeit

I said better varargs, because C's are really clumsy. To begin with you have to manually provide as an argument how many items you're sending.

>type inference in C is a terrible idea

No it isn't. It's fucking retarded to have to cast into something when it's obvious what should happen. For example this code is invalid:

> Vec2 something;

> something = {1, 2};

Even though this is not:

> Vec2 something = {1, 2};

Similarly for this function

> void whatever (Vec2 pos1, Vec2 pos2) {}

You will have to do

> whatever((Vec2){1, 2}, (Vec2){5, 6});

instead of just

> whatever({1, 2}, {5, 6});

>>969618

this is solved in c++11

works exactly like you showed in your post.

>>969621

I don't want C++ though. It's like you're telling me to move to a shitty new house in a nigger neigbourhood because the house has a better toilet like I wanted.

Forth isn't great despite the fact that you can fuck up your entire system with it. Forth is great because you can fuck up your entire system with it.

To sum it up quite nicely: with great power comes great responsibility (don't make this a spiderman thread). Forth gives you all the tools you need to make your program truely slim while being just abstract enough to understand it all (try coding complex programs in assembly i fucking dare you).

Anyone complaining about Forth being unsafe have the same level of intelligence as people who think that owning a gun somehow means your home is more dangerous.

Other languages are great for quick scripts, but for a large program there really isn't anything that can replace Forth.

Elixir/OTP isn't great despite the fact that you can fuck up your entire system with it. Elixir/OTP is great because you can fuck up your entire system with it.

To sum it up quite nicely: with great power comes great responsibility (don't make this a spiderman thread). Elixir/OTP gives you all the tools you need to make your program truely slim while being just abstract enough to understand it all (try coding complex programs in assembly i fucking dare you).

Anyone complaining about Elixir/OTP being unsafe have the same level of intelligence as people who think that owning a gun somehow means your home is more dangerous.

Other languages are great for quick scripts, but for a large program there really isn't anything that can replace Elixir/OTP.

>>969625

Although I have to correct myself, Erlang/OTP really can't fuck up it's entire system, that's the point.

Oracle Java isn't great despite the fact that you can fuck up your entire system with it. Oracle Java is great because you can fuck up your entire system with it.

To sum it up quite nicely: with great power comes great responsibility (don't make this a spiderman thread). Oracle Java gives you all the tools you need to make your program truely slim while being just abstract enough to understand it all (try coding complex programs in assembly i fucking dare you).

Anyone complaining about Oracle Java being unsafe have the same level of intelligence as people who think that owning a gun somehow means your home is more dangerous.

Other languages are great for quick scripts, but for a large program there really isn't anything that can replace Oracle Java.

>>969610

C doesn't take your freedom to write platform-independent code. What's your complaint, again? That you don't know how to use the language correctly?

>>969618

go back to C++ and stay there

>muh varargs

who the fuck cares? varargs are a gimmick in any language

>>969622

C has enough features the problem is the bad design that makes it too hard to write reliable code let alone remember the syntax

>inb4 muh (*)(*nigger((*jew*)*))[123][123] is soo easy to remember if i just practice every day making 4d arrays of function pointers to 2d arrays of function pointers

>>969637

>That you don't know how to use the language correctly?

>XDDD C is easy XDDDDDDD

t. doesn't know how to use C correctly

>>969640

>go back to C++ and stay there

Argument not found

>who the fuck cares

Just because you don't need it doesn't mean I don't. It doesn't even need to be complicated, I could technically make do with sending a pointer to an array literal along with a item count, but the problem to begin with was that if the language supports varargs properly it becomes a lot more comfortable and simple to do that.

>>969640

>>That you don't know how to use the language correctly?

>>XDDD C is easy XDDDDDDD

>t. doesn't know how to use C correctly

1 Still not an argument about the language but an ad hominem 2. you still didn't name a comparable alternative

>>969644

you don't need varargs. literally nobody has ever needed varargs. varargs is fucking terrible in every language anyone uses. it makes problems stemming up to the type level

>>969649

I program C fuckface, I'm not arguing against it, I'm stating facts about it. Literally every other language is portable and better at it than C. You can't have portability and low level at the same time, which is exactly how C fails. You can write portable code that's efficient due to use of low level mechanics (as opposed to something that would be efficient in _any_ language) in C but few people know how to do it.

>>969653

I agree with your general premise, but tell that to LLVM or Go's pseudoassembler

>>969653

>you don't need varargs. literally nobody has ever needed varargs

Okay. Then what do you do when you want to call a function across several objects? Let's say you want to find the center position of N objects in space, or a bounding box that surrounds all of them. Or what if you want to merge several objects for some purpose. Are you going to write those calculations manually every single time you want to do it rather than just sending them to a varag function that does it?

You're asking me to keep writing shit like this:

float x_min, x_max, y_min, y_max;
Vec2f positions[] = {{1, 2}, {6, 2}, {0, 6}, {6, 6}};
for (int i=0; i<4; i++) {
	x_min = min(x_min, positions[i].x);
	y_min = min(y_min, positions[i].y);
	x_max = max(x_max, positions[i].x);
	y_max = max(y_max, positions[i].y);
}
Vec2f center = {x_min+(x_max-x_min)/2, y_min+(y_max-y_min)/2};

Instead of this:

Vec2f center = findCenter({1, 2}, {6, 2}, {0, 6}, {6, 6});

>>969618

>you have to manually provide as an argument how many items you're sending.

Not if you null terminate. The same thing happens if you pass an array instead.

>>969662

...did you not know you could pass arrays?

>

Vec2f center = findCenter(4, positions);

wow so difficult

>>969668

>did you not know you could pass arrays?

Did you even read the argument at all?

>>969670

>if the language supports varargs properly it becomes a lot more comfortable and simple to do that.

For comparison, here's how it works in python:

def func1(*args):
    for a in args:
        print(a)
def func2(*args):
     return func1(*args)
myarray = [i*i for i in range(6)]
func2(*myarray)

Why is is "a lot more comfortable and simple" if we just get rid of all the fucking dereference operators?

>>969679

Maybe "a lot" is subjective, but I hate having to deal with the argument counter and casting and shit manually. To me

> something({a, b, c, d});

would be a lot more clear and easy to use than

> something(4, (Vec2[]){a, b, c, d});

There's 2 extra components that are completely useless and makes it harder to read and more tedious to manage.

Come to think of it maybe this doesn't even count as "variadic arguments". I imagine them as the same thing.

>>969540 (OP)

This. I purposefully seek and disable any program not written in C or C++ or anything that needs memelibrary to function.

>>969662

as the other guy said, literally why can't you just pass an array or other list structure?

>>969685

yes it would stop you from having to pass an array length, but at what cost? what if you iterate over the varargs the wrong way? what broken states or memory corruption can result?

>>969679

varargs are absolute shit in python as well. anyone who thinks varargs matter are to be suspected as n00bs

>>969705

Oh and also now I can't randomly access my arguments unless I waste cycles counting arguments which is just wonderful.

>>969702

>why can't you just pass an array or other list structure?

I could, as mentioned >>969685 which has it's own problems.

>what if you iterate over the varargs the wrong way

Wrong how? The number of items should be available automatically based on how many items I send, that's what I mean with "improved varargs". If C arrays had length information then that would basically solve half of the problem. Obvious type inferrence would solve the second problem.

>>969705

>>969707

>oh no I have options on how to pass the length of the array, and have to pick the best one for the situation!

>my indian code camp didn't prepare me for this!

>>969709

>lol so what if there's a better way to do it, this is the C way and I'm proud of it!

>>969540 (OP)

>C is great because you can fuck up your entire system with it.

Only C weenies consider that a feature.

>Anyone complaining about C being unsafe have the same level of intelligence as people who think that owning a gun somehow means your home is more dangerous.

C weenies have the same level of intelligence as people who think a browser is great because you can get exploited by viewing a JPEG.

>>969574

>When MS said "It's a feature, not a bug" you all mocked it but when someone exposes C (or Linux's) flaws then "The user is stupid."

That mentality was created by AT&T in the 80s. They blamed the user for every single mistake until they believed they really were responsible for every bug. UNIX weenies think it's their job to fix bugs in AT&T's broken software that they paid for.

>>969593

>C actually provides value to mankind: it is platform independent and

C takes away value. Computers are less reliable, software is buggier, programs need tens of millions more lines of code, more than a half century of research is ignored because it won't work with C, and so on. It only provides value to people who are paid to fix bugs and enjoy that mind-numbing bullshit more than actually improving software.

>yet low-level like no other language.

Bullshit. Ada, Forth, PL/I, and many other languages can do the same "low level" things you can do with C, if you use the C definition of "low level" as being able to work with pointers.

>>969653

>you don't need varargs. literally nobody has ever needed varargs. varargs is fucking terrible in every language anyone uses. it makes problems stemming up to the type level

It works in Common Lisp and Scheme. Common Lisp provides a &rest argument, which is passed as a list.

>Literally every other language is portable and better at it than C. You can't have portability and low level at the same time, which is exactly how C fails.

That's true. Low level depends on how a specific machine architecture works and C is based on how the PDP-11 works. Most programming languages can use the features of the machine natively, but C requires you to emulate a PDP-11 on top of the real machine. Fortran and Pascal on Lisp machines use Lisp strings, arrays, integers (bignums), floats, and complex numbers for their own data types. C on Lisp machines has to emulate null-terminated strings on top of hardware already designed to work with strings and pretend Lisp types are machine words.

>You can write portable code that's efficient due to use of low level mechanics (as opposed to something that would be efficient in _any_ language) in C but few people know how to do it.

Low level depends on the hardware so it can't be portable except to different models of the same architecture. Flat memory pointer arithmetic is the only "low level" thing C gives you, which works on the PDP-11 but not x86 unless you ignore a major part of the memory model (segmentation). On a PDP-11 and x86, overflow sets the flags. On MIPS, it can trap or be ignored depending on the instruction. On a Lisp machine, it converts the number to a bignum.

    This poor user tried to use Unix's poor excuse for
DEFSYSTEM.  He is immediately sucked into the Unix "group of
uncooperative tools" philosophy, with a dash of the usual
unix braindead mailer lossage for old times' sake.

    Of course, used to the usual unix weenie response of
"no, the tool's not broken, it was user error" the poor user
sadly (and incorrectly) concluded that it was human error,
not unix braindamage, which led to his travails.

>>969717

>could easily be delegated to the compiler

then do, faggot

#define myvariadicfunction(...) _myvariadicfunction(sizeof(__VA_ARGS__)/sizeof(*__VA_ARGS__), __VA_ARGS__)

or better yet

struct my_list {int n; TYPE * data};

>c is bad because it doesn't hold your hand

>>969735

Having to type pointlessly literal extra shit when there's really no reason to is exactly what makes people prefer other languages.

>>969738

>having to understand what happens in order for sugar to work is why pajeets can't program in c

>>969740

After you've learned how it works, you begin to want to stop having to type all that shit all the time.

You're putting more importance on teaching Pajeets than letting experienced programmers do their work effectively.

>>969735

You also still have to populate that struct retard.

>>969744

if typing speed is your bottleneck when programming, you are doing something very wrong. In any case, if done properly, it should require very few characters.

>>969750

Yeah. Write a macro to create the struct, and then pass the struct to your function. Dead easy.

>>969749

I debug macros all the time. Here's my standard script:

 gcc -E $1 -o - | sed '/^#/d' | clang-format > ${1//.c/.i}

Either look at the .i directly, or compile it and step through it in a debugger. This is directly comparable to compiling with -S, and looking at the asm.

>>969755

> gcc -E $1 -o - | sed '/^#/d' | clang-format > ${1//.c/.i}

>${1//.c/.i}

>using bashnigger features when they're not needed

Gas.

>>969759

>not using the programs on your machine to their full extent

I swore someone would complain that I used both gcc and clang

Anyways, how do you do this in posix shell? bonus points if you don't use external programs.

>>969768

This is jsfag level autism.

Holy shit this thread is filled with butthurt.

>>969770

>how dare he look at the intermediate output of his compiler

>real programmers debug exclusively with printf

>>969707

it's unlikely you care about cycles when you're fucking around with varargs

>>969717

>this job could be easily delegated to the compiler at absolutely no cost to the programmer

false. if we added every feature some fags on the internet wanted, we'd have JS, Java, or C++

>your code is unmaintainable garbage because you didn't use varargs

>Uncle Bob's clean code

u fuckin wot m8. you were just subtly trolling all along?

>>969738

meanwhile, varargs is shit and full of edge cases in every other language as well as in C.

for example it makes it non-obvious what code should do in these 2 examples:

https://stackoverflow.com/questions/8529501/method-overloading-using-varargs-in-java

https://stackoverflow.com/questions/17728425/varargs-method-modifies-callers-array-instead-of-its-own-copy/17728529#17728529

the only thing being shitted up here is the language

>>969542

Program them once, reuse them later.

>>969785

No faggot, you shouldn't need anything more than your code and GDB.

>>969798

...and gcc ofc. sed and clang-format are niceties, feel free to just run gcc -E.

>>969804

No, you should never need your compiler for debugging runtime.

>>969809

You need a compiler for compiling, retard.

>never looking at the assembly for your programs

enjoy having slow code.

>>969806

>m.wikipedia.org

kys

>>969791

>varargs is shit and full of edge cases in every other language as well as in C

Then how about you stop using Java and make a good varargs feature instead.

I'm a little confused about the exact definition of varargs at this point, but what I want is basically to send an array of things without having to type pointless shit every time. This is what my perfect "varargs" looks like (function header syntax up to debate):

void doStuff (int foo, int stuff[int stuff_count]..., float things[int things_count]...) {
	for (int i=0; i<stuff_count; i++) {
		printf("stuff integer %i is %i\n", i, stuff[i]);
	}
	for (int i=0; i<things_count; i++) {
		printf("things float %i is %f\n", i, stuff[i]);
	}
}

doStuff(500, [10, 2, 30, 4], [5.5, 0.1, 3.333]);

// output:
/*
	stuff integer 0 is 10
	stuff integer 1 is 2
	stuff integer 2 is 30
	stuff integer 3 is 4
	things float 0 is 5.5000000
	things float 1 is 0.1000000
	things float 2 is 0.3330000
*/

// non-literal arrays also usable if you really want
doStuff(500, (int[4])somearray, (float[3])otherarray);

>This is what my perfect "varargs" looks like (function header syntax up to debate):

>this features requires adding new syntax to _headers_, fundamentally changing the language, so i can save like 1 line of typing a year

stop trolling

>>969836

>I'm too lazy to improve the language so everyone should use an inferior feature instead

Great argument.

>fundamentally changing the language

You mean mildly changing how a function header is parsed. You have an interesting definition of "fundamentally changing the language".

Ada has advanced support for type checking, you can create types with specific ranges (e.g. an integer with values from 0 to 12), you can write modules, exceptions (in other languages the system gives you an error code, you can't just ignore it or the software will crash), 'generics' which means you can write a data structure (like lists) which will work on different kinds of data, like integers, floating point numbers, and strings. So, by writing just one function for all data types instead of writing functions for all data types specifically, the language has run-time checking and so many other features.

The kicker of Ada is that it's a higher level language than C and about a million times safer. The GCC compiler framework generates the fastest code for C, but GCC also supports Ada and the code generated for Ada is nearly as fast as the code for C. It also supports every architecture/platform that is supported by GCC.

Why do programmers hate Ada? C programmers in the 80's would use so many bullshit excuses like that the compilers for the language were expensive, or the language is too complicated (it's much simpler than C in day to day usage). The real reason is because they're just too lazy to learn Ada.

The reason for 'bloat' is because C makes it difficult to write good, maintainable, secure code. To you morons everything that isn't C is "bondage-and-discipline". Imagine the horror of using 1950's programming language features and practices.

>>969856

I'd probably be more willing to use Ada if it didn't have such a linguified syntax.

>fcloses a opened file

>fails because of "muh undefined behavior"

yeah sure it is great and "well designed ;D"

>>969817

varargs is just C programmers knowing how function calls work under the hood and wanting access to the arguments they know can be passed in any quantity but in a portable way. The difficulty is not everything is passed as a single word size so the varargs implementation needs to know the type to know how many words were used to pass it. It's trivial to understand if you know assembly but the edge-cases are confusing as fuck if you're coming from a HLL background. It's absolutely not meant for passing arbitrary length arrays, though.

	for (int i=0; i<things_count; i++) {
		printf("things float %i is %f\n", i, stuff[i]);
	}

Congrats on reading past the end of an array.

>>969768

Are you retarded? "${1%.c}.i"

>>969914

>It's absolutely not meant for passing arbitrary length arrays

In that case I guess I don't care about varargs. I can imagine things that being able to push arbitrary things into a function would make more convenient, but I wouldn't feel comfortable doing that because it makes it hard to see and control exactly what you're doing.

>Congrats on reading past the end of an array

Typo that I didn't bother to delete and repost for.

>>970198

what the fuck nigger, i just realized you aren't even asking for varargs in this entire thread. you can already do variable length arrays in C99:

#include <stdio.h>
void nigger(int numnigs, int nigs[numnigs]) {
for (int i=0;i<numnigs;i++) printf("%d\n",nigs[i]);
}
int main() {
int nigs[3]={1,2,3};
nigger(3,nigs);
nigger(4,(int[]){1,2,3,4});
return 0;
}

it's a feature that you pass the length explicitly. C is for low level code, it doesn't bend over to make it easy to pass a bunch of array literals everywhere. you can easily pass some subset of an array for example nigger(2,nigs+1);

>>970221

Yes, I already mentioned that method and explained why I hate it in this thread.

TL;DR: I already know what's happening, so I no longer want to be forced to type extra shit I don't need to because it makes writing and reading and maintaining the code slower and more annoying.

I really do not understand this idea of "be as literal and verbose as you possibly can even though it's obvious what should happen if you wrote less".

>>969759

>>970134

${parameter%word} is POSIX. Try man dash next time.

>>970239

But that's what I said, nigger? He used ${var//pat/repl}. Also, dash isn't entirely POSIX, it's better to look at http://pubs.opengroup.org/onlinepubs/9699919799/.

>>970192

>function pointers

function pointers syntax is cancer.

>Pointer arithmetic is a boon

It is only defined for doing so inside of an array plus one past the end.

>C is just so amazing, I love it

How can you enjoy using that piece of unix weenie garbage?

Why does literally everyone here hate Unix?

>>970436

>How can you enjoy using that piece of unix weenie garbage?

How can you not? I think the people who created, maintained, and standardized the C language were intelligent and thoughtful. Certainly their work has gone to see more success than anything preceding it. But all you want to do is argue opinion because you don't have a foot stand on when all computers today operate nearly identical regardless of the programming language used.

>>975172

They are likely a bunch of try-hard academics who realized that their MIT CS degree doesn't mean jack in the real world of business and application. They want everyone to work on their LISP machines because it favors their worthless education regardless to the debilitating condition that LISP machines impose on users.

They also could be die-hard Stallman losers who cannot foment a single, solitary thought of their own without his approval. They agree with Stallman that the GPL should remove all rights from a person about their labor, and that software cannot be sold for profit.

>>975172

>>975200

>... C language were intelligent and thoughtful

If that was true why is function pointer syntax so poor? Why doesn't the C language include lambdas? Why doesn't the C language support interrupts?

>>975205

>and that software cannot be sold for profit

The GPL does not prevent you from charging for your software.

>>975210

>why is function pointer syntax so poor?

Opinion.

>Why doesn't the C language include lambdas?

Opinion.

Why doesn't the C language support interrupts?

Opinion.

>The GPL does not prevent you from charging for your software.

Yes it does. It only grants you license to sell physical copies or technical support. It does not allow you to sell the copyright to your software while it is licensed under GPL.

>>975228

<Th-thats just like your opinion man

Doesn't make C any better.

>It does not allow you to sell the copyright to your software while it is licensed under GPL.

I don't see how this would be true.

C was awesome and there are some good reasons to hate it.

Prove me wrong.

>>975172

because it's garbage?

t. gentoo lUNIX user

>>975210

>Why doesn't the C language support interrupts?

What would that even mean? Some ad hoc bullshit instead of setting up the function pointers yourself? How many instances of interrupt handling code do you have that merits a language feature (assuming the feature even accomplishes anything, which i doubt)

>>975273

I don't argue opinion. The GPL regulates how source code is distributed, therefore, it usurps control of the copyright to the software.

>>975210

>If that was true why is function pointer syntax so poor?

Function pointer syntax is fine, it's when you abuse function pointers inside arrays inside structs that things get ugly. That's because of one of Cs best features: that ugly things look ugly.

>Why doesn't the C language include lambdas?

>a lambda is a function definition that is not bound to an identifier.

I'm not sure what you think c is missing here. Just name your function _tmp123 or something, problem solved.

>Why doesn't the C language support interrupts?

UNIX supports signals, which behave like interupts.

>>969558

to go with your gun analogy, it's only more dangerous to have a gun in your house if you don't know how to use it properly

>>975293

Yes, but if you own it you have full control over the copyright.You always have the ability to change the license, make it proprietary, or sell the copyright for it to someone else.

>>975433

>I'm not sure what you think c is missing here. Just name your function _tmp123 or something, problem solved.

C is turing complete, so yes it can emulate any feature from any other turing complete language. The problem is that it is going to be more verbose.

>>975465

You always have the ability to ... sell the copyright for it to someone else.

Not if the license is GPL.

>>975473

If you own the copyright on the code you can. If we want to pretend in your silly rule that you can't, then you can just relicense the code to be proprietary and then sell it.

>>975465

If char count is what matters, then name your function "a" or something. This isn't exactly brainfuck level, turing tarpit style verbosity. What I don't get is why you think lambdas are the pinnacle of language design.

>>975484

>What I don't get is why you think lambdas are the pinnacle of language design.

lambdas are not just a separate function. They share the same scope as where it is defined. The reason why it is important is that I don't want to crate a trivial function for every HOF I want to use.

>>975480

That's exactly what the GPL says.

>>975492

It doesn't matter what the GPL says because you own the copyright. You get to make the rules.

>>975494

Then none of the GPL matters.

>>975500

Yes, the GPL does not matter to the person who owns copyright over the entire codebase.

>>975205

>>975210

>>975228

>>975273

>>975293

>>975465

>>975473

>>975480

>>975494

>>975500

>>975501

Goddammit is this a long argument over fucking nothing. With the GPL you can relicense your code under a new license, which will apply to any new code going forward, however you cannot rescind the old license on the old code. This latter term is the whole point of the GPL, so its elimination would be retarded. However the former point applies only to you, the copyright holder, and is explicitly banned by the gpl for everyone else.

>>975488

GCC supports inline functions, but not closures. Note that you can get many of the effects of lambdas using tricky macros. In general though, abuse of functional style programming is made difficult in c for good reason.

>>975504

>however you cannot rescind the old license on the old code.

This is my point. You lose copyright to that original work because of the GPL usurpation of the copyright.

>>975172

Because it's popular.

>>975172

Because it sucks. The linker sucks. The memory model sucks. The error handling sucks. Shoving everything into the kernel sucks. It has hundreds of commands that overlap in functionality and all have their own rules. The "man" pages don't fully describe how things work and have bugs sections. It has hundreds of system calls but weenies brag about it being "simple and elegant" because they don't know anything else. When you get into the details of how things actually work, it's even worse.

>>975200

Popularity does not make something intelligent and thoughtful. Look at JavaScript and PHP. "All computers today operate nearly identical" because C and UNIX are a PDP-11 language and PDP-11 OS. Anything too different from a PDP-11 and they would end up avoiding most of the hardware (like segmentation on x86) or have to fake an "abstract machine" (like C on Lisp machines). It used to be that intelligent and thoughtful language designers were the ones who cared about all this, not the ones who force you to use a specific memory model because that's what they were stuck with in the 70s. Ada can run on tagged architectures with GC, flat memory, or segmented memory. That's intelligent and thoughtful design. Most programming languages like Lisp, BASIC, Fortran, Cobol, Algol, Pascal, and so on are high level enough that they could run on any memory model.

>>975205

>They want everyone to work on their LISP machines because it favors their worthless education regardless to the debilitating condition that LISP machines impose on users.

The only people I have ever seen impose their OS on anyone and "want everyone to work on" it are UNIX weenies. Lisp machines have no "debilitating condition" but they do have "signalling and catching exceptional conditions" instead of segfaults and panic. UNIX weenies were able to fool 8-bit and PC users because they didn't know how protected memory or multitasking work. Bugs on mainframes never cause panics. A broken disk drive can be replaced while the computer is running. Weenies might say this doesn't matter, but it does when you have hundreds of people logged in at the same time and the computer is also doing payroll processing and important business or university work. One of the reasons for Multics security was to reduce the number of separate machines and it worked. This is only a problem today because they ignore that research which was all done in the 60s.

>>975277

C always sucked. Null-terminated strings were always a bad idea. There were already better ways to handle arrays. Most of the problems with C were solved before C existed, but UNIX weenies ignore everything before C and after C that didn't come from AT&T, which is why they can't find the solutions.

>>975433

>Function pointer syntax is fine, it's when you abuse function pointers inside arrays inside structs that things get ugly. That's because of one of Cs best features: that ugly things look ugly.

It's only considered ugly because it's C and everything in C is ugly. There's nothing wrong with "function pointers inside arrays inside structs" in any language besides C.

>>975465

>The problem is that it is going to be more verbose.

These problems might just be a few extra lines of code for FizzBuzz or Hello World programs, but for an OS it becomes millions of extra lines of code.

>>975526

UNIX-Haters hated UNIX because they were required to use it and replace their existing OSes with it. Linux is proof of how much UNIX and C suck. A kernel used to be a few kilobytes of code and could handle errors reliably. Linux is a multi-billion dollar project that needs thousands of people and it still panics and kills processes when it runs out of memory.

    This article is indicative of the UNIX methodology; if
your daemon process stays up for 24 hours straight without
coredumping or just vanishing into a puff of smoke, you're
doing great!  And if not, here's an elegant solution:

    No really, this is the way all system software will work
in the future; No one can REALLY debug software, even if
they did have access the sources.  I mean, why did the the
Lisp Machine go to all the trouble of signalling and
catching exceptional conditions, and so on (condition-case),
when it's so much simpler to wait and see if your process
dies, oh every 60 seconds or so, and start another one?  Of
course what if your process which is watching your other
process dies mysteriously?  Well, start another one!

C is slightly worse than Rust, but only slightly. I have a lot of respect for DMR, rip in pease, but he left a lot undone and unfortunately the bad got set in stone before improvements came to be well defined. C++ fixed a lot of these issue, it's necessity for backwards compatibility, and the fact that many of it older parts are literally C with classes makes it filled with it's own issues. At least in C++ these are actively being addressed by the vibrant and growing community. I see no such attitude in general on the part of the C community. They have the arrogance of the old-school Novell business managers "Why worry?"

>>975488

GCC supports scoped functions in C as a language extension tho.

int foo(int x)
{
        int y = 3;
        int bar(int a)
        {
                return a*(x+y);
        }
        return bar(1) + bar(2);
}

>>975669

>segmentation on x86

You still haven't explained why anyone would want that. Also C supports segmentation.

>>975928

Yes, but that is beside the point. We are talking about the people who designed and standardized the C language. We are not talking about the developers behind GCC.

>>975963

If you haven't noticed, nearly all the improvements to the language that appear in newer revisions of the ISO standard have started as nonstandard extensions in one of the big compilers. You can think of this as a testing ground for ideas - if any of these proves practical and useful enough, it eventually graduates to be part of the standard (possibly modified to polish rough edges discovered in the original implementation). If it doesn't, it will not bloat the language with deprecated cruft. I find that a very practical and forward-looking approach to standard development.

So maybe nested functions are the future of ISO C. Or maybe they're not useful enough and will be forgotten. Who knows?

>>975669

>Popularity does not make something intelligent and thoughtful.

That's not what I said.

>The only people I have ever seen impose their OS on anyone and "want everyone to work on" it are UNIX weenies.

>Continues on how OP just can't stand UNIX and everyone else must accept another operating system

That's called foot-in-mouth disease that you have.

>>969540 (OP)

>Anyone complaining about C being unsafe have the same level of intelligence as people who think that owning a gun somehow means your home is more dangerous.

Look, dude, I have to hire these dumb motherfuckers in order to do things. realize how many of these pieces of shit work for Google, Microsoft, and Mozilla working on whatever browser you happen to use (Opera has the same issues). You can't get away from these dumb-fucks because their parents insist on sending them to college. And the dumb-fucks in HR insist on hiring them. I've got all of these dumb-fuck, worthless, invariably liberal programmers that I have to hire to get shit done. They NEED something that doesn't ALLOW them to be the fuckups they are.

>>976089

Serves you right for working in a commie corpo.

>>975669

>PDP-11

>UNIX weenies

>posts mail archives in code box

kys UNIX hater

>inb4 I'm a C programmer and your're stupid

kek that bullshit doesn't work on me!

>UNIX-Haters hated UNIX because

It's just you anon. Your the only one abusing code boxes this hard.

Just stop.