Any language as based as C?

C is awesome. I love to feel like a pr0 h4xx0rz and ignore all common sense modern programming language features in favor of the risky simple programming. Just like driving without a seatbelt makes me a better driver, programming with a 50-year-old type system makes me a better programmer! I'm such an interesting person...

Attached: boomer.png (376x349, 56K)

>no it doesn't. both compile times and runtime are slow due to core design limitations.
>even things written with standard library have poor portability

>using the c runtime, or linking against the standard library ever

Attached: 32627.jpg (906x936, 849K)

please explain further.
I dont like it because it "ignores all common sense modern programming language features" but because I can do stuff other languages wont let me do. Its also not really comparable to driving without seatbelt. Only if removing the seatbelt gave significant speed advantages.
Also, what is wrong with the type system? a good programmer should know all variable types at compile time, and if you really need variable types, you can cast anything to anything.

If you think C is powerful, you don't know what power means.
Examples of powerful languages: Lisps (I prefer Scheme), Haskell

>Just like driving without a seatbelt makes me a better driver
Not if your seatbelt halves your car's gas mileage, or makes it drive at 1/10th of its potential speed, or suddenly stops for a few miliseconds while it picks garbage off the ground for no reason whatsoever.

ASM > C

Agreed, which is why you should check the output of your compiler to make sure it's not doing anything stupid.

>I can do stuff other languages wont let me do.
Such as?

>(((lisp)))

>It doesnt mangle function names like C++ does.
It does

>Name one language that comes close to C.
I can't. They're all light years ahead of it.

>fast compile times
Have you ever even tried Go?

>IF... THEN GOTO
>FUNCTION... END FUNCTION
What an ugly language.

Maybe a better question is: How do we prevent anyone from writing code in any language that isn't C?

Have you ever tried generics?

Generics are a crutch, good programmers know what functions they need and write optimal ones for each case.

Yeah I love using generics in my C programs haha

Attached: aoba_question_mark.jpg (898x709, 162K)

>which would be a really nice feature to have imo.
Disagree desu. It is a lot harder to understand someone elses code when this non-feature is used. It obfuscates things.

Which dialect do you use? I have been wanting to learn scheme but the idea of not having loops seems unnecessarily inconvenient to me.

C doesn't even have fucking strings

>#include
>???
>profit

The standard library shouldn't be considered C.

Uhm sweaty there's char[]

typedef char* string;

>using String builtin
>not using a character array for ultimate granular control and no overhead.

Forth

ok im drunk so it's time for a tryhardpost
>Its plain and beautiful
193 cases of undefined behavior, unsanitized preprocessor macros, weak type system, and no thread safety. not exactly beautiful.
don't get me wrong, C is great for certain things. It is the gold standard for embedded, operating systems/drivers, media codecs, and all crypto libraries which are not handwritten in assembly.
However, C is an ugly language designed for an ugly task. Using it above ring 0, with the exceptions I mentioned above, is naive.
Having maintained large C codebases in the past, even with the vast suite of build systems, security and testing tools that will cost you countless man-hours to set up, it is really really infeasible to manage all the surfaces little bugs caused by compiler optimizations or human error that can cause anything from minor crash issues to critical CVEs.

Working with modern software requires a certain degree of abstraction capabilities that cannot be expressed in C. Most of these abstractions have minimal runtime cost. Even in cases with large runtime cost, modern hardware and compiler optimizations in languages which have the facilities to reason about pointer capture/escape/aliasing with certain language invariants can often produce more optimized code than hand-written C.

Again. any developer using C outside of the cases I have mentioned is either maintaining an older codebase or is high on pseudo-nostalgia and trying to live in the past.
Don't dismiss modern advancements in PL theory and compiler optimization as "unnecessary". You are falling for the e1337 C hecker meme as a result. You ridicule normalfags for submitting to artificial norms and brainwashing by media consumption, when you do just the same with Jow Forums.

What about writing a generalized library, where you can't afford the performance hit of interfaces?

> O(n) strlen
>st

>strcpy
shit, lets try again...
>strncpy
shit, lets try again...
>strncpy_s
phew, this will last the test of time

>Don't dismiss modern advancements in PL theory and compiler optimization as "unnecessary".
It's not that they're unnecessary. It's that they do more harm than good. Software abstractions are literally destroying civilization.

did you just watch that stupid jonathan blow video?

I have it playing in a loop 24 hours a day.

Go is like C in a lot of ways but with garbage collection and built in concurrency.

Dunno many others.

how is that like C then?

ZIG!
I
G
!

I just told you you glow in the dark nigger.

it's also radioactive garbage

Reminder to only use ANSI C.

Terry Davis said if you can improve C in a way that's not niggerlicious, then you are a genius

Terry was also a moron

>terry poster
ah, a fellow brainlet

Most of the people in this thread are idiots. C is a decent language, but there are some warts.

1. The preprocessor - it needs to be taken out back, shot, and replaced with something else that you can actually reason about. We don't need to go full C++ templates, but we need _something_ better than some of the nigh-unreadable crap I've seen done with the preprocessor.
2. Binary file embedding. We should not have to rely on compiler-specific magic (incbin) or a third party tool (xxd) to embed a file in a binary. It should be mandated by the spec.
3. Attribute cleanup GCC mandated by the official spec. It would be nice to get rid of half the remaining justified uses of goto.
4. Computed gotos mandated by the official spec. Gotta go fast.
5. Lambda functions.
6. Functions with void* parameters and return types should be convertable to functions with specific pointer parameters and back without having to cast. This is a weirdass hole in the spec leftover from when you couldn't guarantee that pointers of different types were the same size, but it's time to do the right and obvious thing here.

That's probably about it. I also wish the language had strong typedefs, fat pointers, and a string implementation that didn't suck ass, but those at least can be done with libraries. C does _not_ need classes, function overloading, or most of that garbage you idiots would recommend. constexpr would be nice, but is essentially opening a gigantic pandora's box for a simple language unless you can steal it from your C++ compiler (and not all C implementations can).

>3. Attribute cleanup GCC mandated by the official spec. It would be nice to get rid of half the remaining justified uses of goto.

Bad idea. This would essentially entail turning the language into C++. If you want C to be used in real-time contexts you need determinism, therefore you have to guarantee the order of cleanup and suddenly you have to redo the entire spec. Designated initializers have to be redone to be the gimped C++20 version, since you have to guarantee order of initialization of structs.

I'm learning COBOL in a sponsored course.
C is great.
I never fully realized the impact it had when it was created.

>dotlang.org/
Can't wait when this becomes available.

>COBOL
>2019
???????

Attached: 1453305269531.png (186x371, 92K)

i wish the precedence of inequalities wasn't weird. it needs a feature or two more, but otherwise mostly perfect

How does one go from making simple exercise programs to write webservers and games in C?

Attached: 1449255903914.png (500x523, 477K)

bigger meme than jai

planning

you don't want to do either of those in C

Sure you do. Webservers like nginx and apache are written in C.
And nobody needs to use that shitheap known as sepples to write games.

Just try and write more challenging programs, and spend time learning how to do it.
Being able to research and learn technologies on your own is an important skill for any programmer.

>And nobody needs to use that shitheap known as sepples to write games.
the shit part is the C compatibility

>And nobody needs to use that shitheap known as sepples to write games.
haha

guile scheme 2.9.2 just released and is very fast now. it now uses a forked version of gnu lightning for jit compilation. it has a lot of library support and a small but mostly helpful community.

the lack of loops is meant to force you into thinking about iteration differently. scheme was invented as a teaching language and a lot of the design decisions reflect that. after a short while you won't miss loops at all, you might even grow to dislike them. recursion is much easier than loops to follow once you get used to it.

Yes.
Go learn your JS node BS, fucking millenian

You don't want to write a webserver in C.
Game programming is far easier (and more fun), just download SDL and see if you can go from a buffer of pixel data to some simple graphics on screen, and then going from some raw PCM-encoded sounds (loaded from WAV files using dr_wav) to the sound card.

COBOL is ridiculously archaic. Literally its only use these days are in extremely legacy systems where they can't be fucked upgrading it.

enjoy your botnet riddled operating systems

Attached: 100_0358_1.jpg (1082x1370, 200K)

idk golangs environment is a bloated abortion. undesirable for systems programming

love the language, though. concurrency primitives are so cozy

>no if statement
>no loops
I'm already hard

Fuck no dude. I work at a company that exclusively uses C and some of these monkeys should NEVER touch C.

That's because strings are a non-primitive data type, and it would be counter productive to implement non-primitives into the standard of a language like C. You have char arrays for rpimitive strings, and if you need real strings, you can easily implement them with all the features you need and have the compiler type check for you, without making the language unusable on 8bit microcontrollers.

>it would be counter productive to implement non-primitives into the standard of a language like C
so what about arrays then?
oh yeah, C doesn't have them either
I guess strings and arrays are fairly counter-productive

> It compiles lightning fast.
Niggawhat. C scales O^2 with file count.

It's not that they're counterproductive, it's that as soon as you start defining features like that in the standard, you have to gaurantee they work the same way anytime you implement the language. Or end up with a useless standard and no gaurantee the code you write will work. And contrary to what undergrad CS students think, those features incur performance penalties. It's not a big deal for userspace programs running on an advanced ARM processor, x86 processor, the web, etc., and the benefits they confer to the programmer are worth it, but mandating them in the standard would be a disaster for C, since vanilla C can literally be compiled to virtually every programmable computer made in the last fifty (5-0) fucking years. C's sole purpose is to replace ASM as much as possible, and it only abstracts the most basic of all constructs; loops, functions, instructions, and various ways of pointing to memory locations. Every feature you add beyond what literally translates virtually line for line to assembler adds overhead, unacceptable in C. Promising memory safety when programming assembler is inherently unsafe destroys the premise of C. Adding an abstract memory handler destroys C's premise. malloc() and free() are literally not even C; they're functions. They're only available if you have a library that implements them. When you're programming embedded in bare metal C you literally just point at memory locations you pick, based on your knowledge of your microprocessor, unless you choose to abstract it away. There's nothing stopping you from implementing a garbage collector, or strings, or anything else in C, but it would be hugely counter productive to C's goals to demand such features be available in every implementation of C.

We're talking about strings and arrays you idiot
they're very unambigous data structures
I mean they're in C already, just badly implemented

an optional standard strings library is too large of a burden? this is why everyone with a brain moved onto c++

I like C. I understand it has lots of problems and idiosyncrasies, but there isn't really anything currently better than it in its current use domain. There is something I think lots of people (especially those who advocate replacing C with another language -- sepples, rust) misunderstand about that domain.

The only reason I write C is so I don't have to write assembly.

Every so called "C killer", misses this target. They all try to add on to the "shorthand for asm" idea with a bunch of other ideas like OO or memory safety, which, while they may be valid design decisions for what those languages are trying to go for, implementing them moves that language's use case outside of the "shorthand for asm" zone... and so I keep using C.

Attached: autism-pepe.jpg (1000x800, 61K)

>void*

That's because barely anyone has to write shorthand asm anymore, fuck knows why anyone uses C

You're literally retarded and don't know what you're talking about. Go fuck off talking about C until you've actually used it.
>they're very unambigous data structures
Oh fucking really? Arrays! What happens when you index a non-existant location? Behavior that has to be defined across 50 years worth of devices. Outside the scope of C. How do you append to the end of an array? Complex behavior that has to be defined for every device made in the last 50 years. Appending to the beginning? Inserting in the middle? This "unambigous" data structure actually has several behavior characteristics that have to be defined, implemented, and gauranteed. It's not a big issue on fast machines, which is why high level languages should implement arrays and define their behavior, but for C, that was designed, and is still used, to interface with the slowest, simplest microprocessors you can imagine, it's overheaded that's not needed unless you actually need proper arrays, in which case you should implement or find a library that implements proper arrays. And strings? Again, how the fuck is a string unambigous? What character set does it use? How is it delimited? How is it modified? Many questions that go well beyond the scope of C.

>Go fuck off talking about C until you've actually used it.
You can't be a programmer for long without having to use C
>What happens when you index a non-existant location? Behavior that has to be defined
You cite my lack of experience and you don't know what undefined behaviour is?
You don't even know what an array is apparently, it doesn't have insertion and append operations, you're thinking of lists
Strings have more options for implementation, but once you choose how you want to implement them they aren't ambigious, and C's implementation is the worst of the lot, null-terminated strings lol

Embedded programming and systems programming. I was writing some stuff inside for a second stage bootloader recently. Also writing code for an embedded platform. Did both in C.

You're right though. These things aren't exactly common, and basically everything in userland is better to write in some other language. It's just that there isn't really another language that can cover that systems/embedded use case as well as C.

Many languages cover "systems", like C++
Really low level stuff like embedded is really the only domain left

>use domain
What is its current use domain? Sure, embedded and kernel work. What else? Userland almost always requires to work with strings, time, unstructured data - and C sucks at that.

>this
Those kinds of people really just need to be pointed to the fact that in C, unless you have a library, you get dynamic memory by literally defining a pointer and pointing it to a literal location in memory and noting not to use it again later unless the reference dies. You literally cannot make a language in that domain memory safe.

>C's implementation is the worst of the lot, null-terminated strings lol
YOU ARE FUCKING RETARDED. THAT IS NOT A C IMPLEMENTATION. THAT IS A LIBRARY IMPLEMENTATION YOU FUCKING MORON. C HAS NO BUILTIN FUNCTIONS BEYOND OPERATORS. C HAS NO STRINGS. NO ARRAYS. ONLY POINTERS. GET THAT THROUGH YOUR THICK FUCKING SKULL.
Jesus Christ you are so fucking dumb and have no idea what you are talking about.
>You cite my lack of experience and you don't know what undefined behaviour is?
That is why you're a fucking idiot you brainlet. Defining that behavior is unneeded overhead in C, unless you need it to be defined, in which case, fucking define it. You claim that these data types are so simple and oh my God why doesn't C hold my hand and set up a nice comfy computing environment and define all these nice abstracted data types for me to use. It's because those definitions are outside the scope of abstracted assembler. Until you've used C in an embedded space, and it's clear you've never even come fucking close, just shut the fuck up. You have no idea what you're talking about, and why gauranteeing a universal set of behaviors for abstract data types like arrays and strings is a horrible idea in a language like C.

Not him and I'm not a C fanatic but if someone is too retarded to write programs in C then they are too retarded for any other programming language, and this holds for all languages. Programming languages are not like sports where being a manlet, for example, means basketball isn't for you but you can become a gymnast, intelligence is a general trait.

C has arrays, they're just awful because they don't store the length and decay into pointers
C has a standard implentation of strings, null-terminated, commonly known as "C strings"
Why are you calling someone dumb when you don't know the difference between an array and a list
Arrays and strings are like the least abstract data structures around
You think I'm complaining about C because it's too hard
C is easy, I'm complaining about C because it's an archaic language

When does it make code harder to understand?

What are your games about fren

>C has arrays
No, it really doesn't, and the fact that you think it does is incredibly hilarious. It has pointers and pointer arithmetic, and syntactic sugar to make them look like arrays and type checking to keep you from doing something stupid. It actually does not implement any kind of abstract data type, just gives you a convenient way of dealing with pointers.
>they're just awful because they don't store the length and decay into pointers
That is the fucking point, dumbass. Defining that behavior into the C standard would be FUCKING STUPID because it is too abstract.
>C has a standard implentation of strings, null-terminated, commonly known as "C strings"
Not, C does not you fucking moron. The standard library does, the language does not. The standard library is not even close to being universally available. C strings only exist if you use a library. They are not native to C. You literally don't know what you're talking about.

C should only be used by people who know what they are doing
And it also should only be used if the person using it has other
people who know how to use it to check it

It's to easy to leave memory addresses open and
Cause security issues

any language that uses keywords for describing codeblock should get erased

>nd syntactic sugar to make them look like arrays and type checking to keep you from doing something stupid
in other words, an array
>Not, C does not you fucking moron. The standard library does
>>C has a standard implentation
lmao

any language that doesn't use keywords for describing codeblocks should get erased

any language that doesn't use Layout for describing scope should get erased

Come back here when you are done with your tutorials.