[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]

λ - programming

/lam/bda /lam/bda duck
Name
Email
Subject
Comment
File
Password (For file deletion.)
BUY LAINCHAN STICKERS HERE

STREAM » LainTV « STREAM
[Return][Go to bottom]

File: 1446244063159.png (186.72 KB, 600x450, cmonks.png) ImgOps iqdb

 No.11201[Last 50 Posts]

Happy Dennis Ritchie Day, Lains!

Pay respects to your lord and savior for creating the greatest language of all time: C.
>>

 No.11203

File: 1446244707661.png (491.5 KB, 724x674, 1436550309041.png) ImgOps iqdb

c is actually poorly designed with ugly syntax and ugly semantics but it's understandable considering the hardware limitations of the time. really sad that there still are people programming in C today without being forcing to. the same people that is PLT illiterate; couldn't even tell the difference between a statement and an expression.

>>

 No.11207

>>11201
No.

>>11203
FORTRAN, Lisp, Algol, APL, Simula, Forth, PL/I, Pascal, and even Smalltalk all existed before C.
C is a very poorly designed language derived from derivations of Algol made to run decently on hardware from 50 years ago and it really shows. The fact that UNIX has set OS research back by decades just makes things worse.

>couldn't even tell the difference between a statement and an expression.
There is no reason they should be separate concepts.

>>

 No.11208

>>11207
UNIX took the best aspects out of Multics and made it pragmatic for every
purpose, from very small to large. Scalability is just as important a feature as
"innovation". Now of course C isn't without its warts, but at the time it was
really the fastest "high level" language available. C is still being used where
performance matters because it maps well to the von Neumann architecture, and is
less painful to program in than, say, x86 asm. It's still a necessary language
today because nothing can quite beat software that's built on C. I think RMS
said it best that the foundation should be in C, with other software like Lisp
environments built on top of it. Will C be around forever? Probably not, but
for now a vast majority of software is dependent on it, so regardless of what
language you consider to be better to program with, it's honestly still worth
knowing and respecting C for its raw power and versatility.

>>

 No.11209

>>11208
I think you have some reading to do.
http://www.multicians.org/myths.html

>>

 No.11211

File: 1446250345935.png (156.82 KB, 457x463, comfy.png) ImgOps iqdb

GNU C11 + GNU Guile is literally the comfiest way to program.

>>

 No.11212

>>11211
What's the FFI like?

>>

 No.11213

>>11209
Nice read thaanks anon
Now that we are having a programming language flame war, i must say, forth is love

>>

 No.11214

>>11208
>UNIX took the best aspects out of Multics and made it pragmatic for every
purpose, from very small to large.

What? It was literally made because the computers were too shitty to run MULTICS so they made some ghetto knockoff.

>>

 No.11215

>>11214
Large C software: Emacs
Small C software: ed

>>

 No.11217

>>11215
What does that have to do with UNIX at all? It was never made to take "the good stuff" from MULTICS, it was made because they had to nigger-rig something to work on their shitty PDP-8s or whatever

>>

 No.11218

>>11217
You act like that's a bad thing. I'd rather be using the "nigger-rigged" system right away than waiting all morning for my Lisp Machine to boot up.

>>

 No.11219

>>11218
https://www.refheap.com/69099cf0476222e5ec0734a16
Engineering is all about trade offs, Lain!

>>

 No.11220

>>11213
Forth and Common Lisp are a really great team.
Common Lisp is very high level and offers so much to the programmer.
Forth is lower level than C, yet offers metaprogramming and a simple look into exactly what the system is doing. Forth is about %80 of what makes Lisp great with about %5 of the effort.

>>

 No.11241

File: 1446316287077.jpg (16.56 KB, 315x209, 1445995765258.jpg) ImgOps Exif iqdb

This thread makes me kinda bummed, Ive spent the last 3 months learning C...I thought it would teach me more about how computers work than java has. What do I do now?!

Also I pay my respects to Dennis

>>

 No.11242

>>11241
Assembler language actually details the inner workings of your computer. X86 has a large family of assemblers to pick from, some very powerful.

C simply does not teach you how a computer actually works. It makes you manage memory manually and is designed in a way that encourages certain classes of bugs. C also introduces many UNIX-isms that don't apply outside of that world.

>>

 No.11246

>>11242
>C also introduces many UNIX-isms that don't apply outside of that world.
While this is true, UNIX is the only family of operating systems in widespread use today (besides windoze, yeah, but it don't count). So if you're using a computer, you are most probably using unix

>>

 No.11247

>>11241
I wouldn't worry too much, this thread is full of angry contrarians.

>>

 No.11250

File: 1446325916324.jpg (55.87 KB, 600x600, yume1.jpg) ImgOps Exif iqdb

>>11211
>GNU C11 + GNU Guile is literally the comfiest way to program.
I went to check it out and you're right.

>>

 No.11251

>>11242
While that's true about C not teaching you about how a computer really works, the performance between an x86 and a C program is negligible, so C's way of handling memory is more convenient than swapping registry addresses and having to resort to harmful constructs like GOTO. Also, what's with all the C hate here? Programming in C is much safer than in pure ASM. But if you're looking to only learn architecture, you should be using MIPS.

>>

 No.11252

>>11220
Shame nobody uses Forth in the real world, though.

>>

 No.11253

>>11251
>the performance between an x86 and a C program is negligible
Really? At this point I thought C was faster than hand coded assembly.

>>

 No.11254

>>11252
Oh I'm sure there's some engineering firm somewhere.

>>

 No.11256

>>11253
Depends if it's an assembly wizard writing the code.

A compiler will never be as good as a real human bean.

>>

 No.11257

File: 1446327667866.jpg (298.91 KB, 500x500, 404.jpg) ImgOps Exif iqdb

>>11203
>c is actually poorly designed with ugly syntax and ugly semantics
What do you find ugly about C syntax and semantics?

>>

 No.11258

>>11256
Why not? I don't know of any theoretical limits and at this point processors are supposed to be such a cluster fuarrrk that optimizing compilers aren't even guaranteed to output readable assembly.

>>

 No.11260

>>11257
In C, reserved words use curly braces as delimiters and function calls use parentheses as delimiters. There's a special set of functions called operators that are either infix or prefix. Instead of parentheses, operators have complicated precedence rules based off of the conventions used by mathematicians. These precedence rules can be overridden with parentheses. Everything must be terminated with a semicolon unless it ends with a curly brace except not always. There are several different assignment operators. The way to include code from other files and libraries involves using a special pre-processor language that's different from ordinary C. There's a special ternary operator. The 'void' type means nothing, but the 'void *' type means a pointer to anything. The syntax is very complicated compared to something like Scheme or SmallTalk.

>>

 No.11262

>>11260
>reserved words use curly braces as delimiters
What? No, braces denote scope rules.

If there's one thing to complain about C, it's the text macros, which are powerful but messy.

>>

 No.11263

>>11262
>What? No, braces denote scope rules.
Among other things.


if (foo) {
  bar();
  baz();
}
// is different than
if (foo)
  bar();
  baz();

// What scope rules am I denoting?
struct myStruct{
    int one;
    int two;
};

// What about now?
int[] foo = { 1, 2, 3, 4 };

>>

 No.11264

>>11260
And as for the semantics. There's the wonky useless type system that makes it hard to statically verify anything. There's the lack of bounds checking on arrays that make it easy to overwrite important data without crashing the program; a security concern. There's the ability to return a pointer to an automatic variable. There's the plethora of undefined behavior. C functions have to be predeclared. The ternary expression works on lvalues in assignment for god knows why. There's an arbitrary distinction between expressions and statements. Numbers silently overflow when they become too big.

>>

 No.11265

>>11241
Listen to >>11247
Most of the criticisms in this thread are right, but C is still useful to know.

>>

 No.11267

>>11264
>There's the wonky useless type system that makes it hard to statically verify anything.
I like C's type system. It's no HM, but it gets the job done and all the types pretty much make sense to me.

>There's the lack of bounds checking on arrays that make it easy to overwrite important data without crashing the program; a security concern. There's the ability to return a pointer to an automatic variable.
Both of those issues are bad programmer mistakes. A powerful PL like C shouldn't need to hold the programmer's hand.

>There's the plethora of undefined behavior.
Thank goodness for debuggers.

>C functions have to be predeclared.
I like this feature, it means better code organization.

The ternary expression works on lvalues in assignment for god knows why.
If you don't like ?:, you don't have to use it.

>There's an arbitrary distinction between expressions and statements.
Because a statement doesn't evaluate values? Sounds like a nit-pick to me. How does this affect your C coding?

>Numbers silently overflow when they become too big.
You should be enabling warnings then.

>>

 No.11268

>>11251
I would never recommend x86 to someone. It's a complete failure of an architecture and is more complicated than many other computer languages, complete with its own security holes baked in to the silicone.

>But if you're looking to only learn architecture, you should be using MIPS.
Agreed. The only disadvantage is that MIPS is extremely RISC. Quite a few convenient constructs are actually pseudo-instructions, including move, which just adds zero to a register and sends the result to another.

>>11252
You just never hear about it because Forth programs in machinery seem to not result in mass deaths every now and then, like you see with modern cars programmed in C.

>>11253
>>11258
It depends on the architecture. GCC actually has a superoptimizer, which means it computes every possible combination and chooses the most efficient, but it can only do this for small optimizations. Compilers are forced to comply with ABIs and calling conventions and you'd be surprised with how inefficient some of the unreadable assembly outputted is because of thunks and all.

Here's a nice blog:
https://gustedt.wordpress.com/

If you'd like a glimpse into the insanity of C zealots, look no further than discussions about musl libc:
https://gustedt.wordpress.com/2010/11/07/dont-use-null/
http://www.openwall.com/lists/musl/2013/01/09/1

>Every C implementation implements NULL "incorrectly". If only they were more enlightened like us and followed the very ambiguous standard, since we're clearly correct.
>We should just patch C programs to correct this behavior or they should just not use NULL at all.

It's rather strange to have a language so broken that people advocate against using a simple abstraction.

>>11267
You sound like you have stockholm syndrome.
Forth is simpler and all around better for a variety of reasons, including being able to perform your own optimizations by talking to the compiler directly and also being simple enough to implement on your own.

>>

 No.11269

>>11268
>Quite a few convenient constructs are actually pseudo-instructions, including move, which just adds zero to a register and sends the result to another.

# RISU (Reduced Instruction Set Unix)
alias rename="mv"

>>

 No.11270

>>11207
Before C existed, most programming languages were coupled with specific hardware.

The whole point of C and UNIX was to have an operating system that could be on many machines -- hardware agnostic.

It has done that and more. It was successful.

>>

 No.11271

>>11270
>The whole point of C and UNIX was to have an operating system that could be on many machines -- hardware agnostic.
Yes, of course.
https://www.jwz.org/doc/worse-is-better.html

>>

 No.11272

So many of these complaints levelled against C, especially the ones to do with weird undefined behaviour and other odd corners of the standard, are entirely the fault of ISO and ANSI. GNU C or MSVC are far from simple, too. More "featured" languages like Go are far less bloated. Dennis is rolling in his fuarrrking grave. If you want a picture of how C can actually be simple, and truly follow "less is more" and do so much with so little, take a good look at Plan 9 C. No nested #include hell, a sane standard library, decent function names, idiomatically-implemented standard containers not in glib's [sic; not glibc] wannabe OOP style, cross-compilation as easy as changing a compiler name... The list goes on. That's the C that Dennis worked with later. He wasn't incredibly happy about the original standard, and C99 made him very unhappy. The tooling is even worse. C was thrown into a world that didn't need its beauty, just a bunch of placeboed self-professed "hackers" who to this day crop up, enticed by the idea that C is "low-level". Do yourself a favor. Give Plan 9's C a try. Unlearn UNIX and ANSI for a weekend.

And just before somebody bitches about zero real world usage, the Plan 9 C compilers and standard library were used to write the Go compiler for all platforms up until the language became self-hosting. Therefore, Plan 9 C has been responsible, via one level of indirection, for services many of you use from day to day, such as bit.ly, payments via Square, Google's download server, Docker (which powers this site), Soundcloud, and many, many others.

Thank you, Dennis, and save the world from your fans.

>>

 No.11274

>>11257
There a lot to say about C's syntax and semantics. Anything related to arrays, for example.

>>11268
Anyone who programmed in assembly (like myself) would tell you that x86 is actually the best ISA for the programmer and a joy for the compiler engineer. It's less tedious, easier to optimize, the smaller set of registers make it more suitable for multi-processing, you can ditch the bad parts (segmentation, x87, ...)

here more x86 reading from a guy who actually had to work with a lot of architectures: http://yarchive.net/comp/linux/x86.html

>>

 No.11276

>>11270
>Before C existed, most programming languages were coupled with specific hardware.
This is not true. Implementations were specific to sets of hardware or operating systems, but this is also true of C. Besides that, portable C is hard to write purely because of the ambiguity and lack of features C has.

>The whole point of C and UNIX was to have an operating system that could be on many machines -- hardware agnostic.
>It has done that and more. It was successful.
Yes. It really appeals to the lowest common denominator well.
MULTICS existed before UNIX and was written in PL/I.

>>11272
Regardless, C is unnecessarily complicated when compared to a language like Forth, which also got a decent standardization. Just looking at the overly complex grammar for the language is appalling.
If you're looking for simplicity, why not go for real simplicity? A simple Forth system can fit in 1K and can be used as the entire operating system.

I'm not trying to be some Forth zealot. What I'm really saying is this: If you want simplicity, don't think "this is a simplification of UNIX and that is awesome". Instead, question if UNIX and Plan 9 are actually simple and elegant systems, which they aren't. They're both unnecessarily complex and based around efficiency while making very bad efficiency decisions, like null-terminated strings and the concept of a shell constantly parsing and serializing instead of a real language REPL.

>>

 No.11277

>>11276
Hate to do this but sentences have one space after a period, not two.

Anyway, not the guy you quoted, but Forth looks great. I think C was a great language for its time but doing a new project in 2015 with it (unless it's embedded or an OS) is silly.

>>

 No.11279

>>11276
I'm curious what distinction you are making between a "real" REPL and a *sh (or python/perl/ruby/whatever) REPL. Do you want the REPL to use the same language as whatever the system is using? Having to do work in a FORTH REPL sounds horrible.


>>

 No.11282

>>11277
>Hate to do this but sentences have one space after a period, not two.
Blasphemy. That's what I was taught and that's how I do things. I even asked RMS once and he does the same because that's the heuristic Emacs uses to distinguish sentences.

>Anyway, not the guy you quoted, but Forth looks great. I think C was a great language for its time but doing a new project in 2015 with it (unless it's embedded or an OS) is silly.
Yeah. I've been meaning to understand some firmware written in C, but it's a mess.

>>11279
>I'm curious what distinction you are making between a "real" REPL and a *sh (or python/perl/ruby/whatever) REPL.
Think about how TempleOS has a Holy C REPL. Think of mv and all of the other commands as functions instead. Instead of each function constantly needing to parse its arguments as text and then serialize its results to text in order pipe them to another command, they could instead return unserialized values, like in a "real REPL". This is much more efficient and also more flexible.

>Do you want the REPL to use the same language as whatever the system is using?
I don't see anything wrong with that. I already use a language REPL for most things.

>Having to do work in a FORTH REPL sounds horrible.
I can understand that. I'm not saying it would have to be Forth. Any language would probably do. A C REPL would be better than sh.

>>

 No.11283

>>11282
How is it more flexible? If the data is serialized to a text stream then either end could be c, java, haskell, python, really any language that can parse text. If the data has some notion of the underlying types/language then it is married to that particular platform/language.

>>

 No.11284

>>11283
I'm mainly highlighting how the shell constantly parses and serializes the data it processes, whereas "real" languages don't. This is incredibly inefficient.
If you do need interoperability, you could just serialize it when you actually need to. Simple.

>>

 No.11285

>>11284
Or you could just write glue logic around a couple of libraries if serialization is an issue. Simple.

Not sure why choosing efficiency over interoperability is the more elegant solution.

>>

 No.11286

>>11285
I don't understand how you can defend sh over "real" REPLs.

>>

 No.11287

>>11276
Because the term "real" is subjective and a matter of taste in the context you're using it in. I admire Forth and APL for their simplicity, and it's incredibly sad that their lessons have been lost on the world, but in ths case of Forth, our computers simply aren't pure stack machines. If you want to see how well pure stack machines fare in the world, look at how ~wonderfully simple and elegant~ being a pure stack machine makes the JVM.

>>

 No.11288

>>11287
I don't see how your comparison is relevant.

The original reason I brought up sh was to show how the UNIX focus on efficiency is a farce. The so-called ivory tower is more efficient than the "practical" crowd in the same way that a lumberjack using a simple ax and his bare hands while feeling superior is inefficient in comparison to more complicated machinery, like a chainsaw made by people who actually study and know the better way to do things.

>>

 No.11289

>>11288
>the UNIX focus on efficiency is a farce
The UNIX focus on efficiency is a myth perpetrated by script kiddies and I'm ashamed to be associated with them by merely appreciating UNIX. The lessons of UNIX, in terms of its response to the unbearable complexity of Multics, have largely been lost on most people who claim to be UNIX "fans" or "hackers". Plan 9 adopts these lessons in a context free of historical baggage, but even ESR discredits it and says that UNIX systems are just better off absorbing Plan 9's features (http://www.catb.org/esr/writings/taoup/html/plan9.html). When a hick like this is at the forefront of the UNIX name, the accepted definition becomes that UNIX is a rusty, crusty, fat museum piece compared to what it started as, plastered in ad-hoc band-aids. No wonder that "practicality" meme is so huge in those circles.

Bell Labs and the BSD dev teams are reasonably "ivory-tower" and Plan 9 is all about abstractions, specifically picking exactly the right ones and no more than that.

Your comparison isn't particularly apt.

>>

 No.11290

>>11289
I meant to finish that first paragraph with:
'No wonder that "practicality" meme is so huge in those circles: *it's the same argument that Windows fans use.*'

From: Rob Pike <robpike@gma...>
Subject: Q: moving directories? hard links?
Date: Sat, 16 Apr 2011 11:56:46 -0700

On Sat, Apr 16, 2011 at 11:17 AM, Skip Tavakkolian wrote:
> Linux has slowly become Windows-lite

Except for the lite part.

-rob

>>

 No.11291

>>11289
>>11290
From what I've read about MULTICS, it seemed to be a pleasant system with a decent amount of the "unbearable complexity" covering error-handling.
Am I to understand that Plan 9 C does away with null-terminated strings and other pitfalls in C's design?

>Your comparison isn't particularly apt.
It got the point across well enough.

>>

 No.11292

>>11291
Since we're celebrating Ritchie, or something, here's a word form the man himself: "[Multics was] ...overdesigned and overbuilt and over everything. It was close to unusable. They (i.e., Massachusetts Institute of Technology) still claim it’s a monstrous success, but it just clearly wasn't. ... the things that I liked enough (about Multics) to actually take were the hierarchical file system and the shell—a separate process that you can replace with some other process."

>>

 No.11293

>>11291
>Am I to understand that Plan 9 C does away with null-terminated strings and other pitfalls in C's design?

It doesn't get rid of null-terminated strings. However, nice features such as auto-zeroed stack space do away with a lot of what's wrong with null-terminated strings on today's POSIX systems. I'm curious what you consider C's other pitfalls.

>>

 No.11294

>>11293
>I'm curious what you consider C's other pitfalls.
This list is incomplete, but it's what I can think of right now:

overcomplicated grammar in comparison to languages like Forth and Scheme
expressions and statements are different
complicated operator precedence
operators and functions are different
#include is required to include the standard library, separated into many chunks, while the language is incapable of generating functions at runtime
no module system is available
functions are not first class
there is a great deal of undefined behavior (191 cases from C99)
portability is made difficult by many basic datatypes being allowed to be many different sizes
no semantically aware macros
no standardized way to communicate with or change the compiler (metaprogramming)
variadic functions are clumsy
the standard library is rather bare
buffer overflows are made easy
array decay

I feel that these are all valid complaints that make writing or reading C a pain.

>>

 No.11296

>>11294
>overcomplicated grammar in comparison to languages like Forth and Scheme
Sure, but on the grand spectrum, it's simpler than almost everything else popular, and many of its contemporaries.
>expressions and statements are different
A statement is just an expression with a semicolon, or one of the special control structures. The language is imperative; what do you expect?
>complicated operator precedence
The same can be said for mathematics as a whole. It's reasonably easy to memorize.
>operators and functions are different
Even Scheme has special forms.
>#include is required to include the standard library, separated into many chunks, while the language is incapable of generating functions at runtime
Imagine the nightmare on embedded systems with an implicit standard library. Good-bye, whatever limited memory you had.
On Plan 9, you have to do minimal includes compared to UNIX.
>no module system is available
Perhaps C's greatest shortcoming in terms or programming in the large. I concede this.
>there is a great deal of undefined behavior (191 cases from C99
There's much less in Plan 9 C due to its simpler nature. C99 is basically Hitler. Anybody who calls it C is a heretic.
>portability is made difficult by many basic datatypes being allowed to be many different sizes
This is indeed a mess. Go's explicit built-in sized typenames are much nicer.
>no semantically aware macros
"pitfall" doesn't mean "lacks something I like".
>no standardized way to communicate with or change the compiler (metaprogramming)
The preprocessor, while limited, does in fact facilitate metaprogramming.
>variadic functions are clumsy
True. Go's way of doing this is, again, better. I concede this.
>the standard library is rather bare
Plan 9's is smaller but richer.
>buffer overflows are made easy
So are many useful things.
>array decay
Yeah, arrays are a mess.

C is flawed, but I don't find any of these features to be a dealbreaker. Some of these are a matter of taste; others are true-blue flaws. Yeah, Go has replaced C in my day-to-day programming, but that's because the tooling and interfaces are a lot more like Plan 9 C than GNU C, but using the plan 9 C compilers isn't particularly well-documented outside of Plan 9 and the Go compilers.

>>

 No.11297

>>11296
I guess as an addendum, I should add that Go does do away with a lot of what you cite, except having to #include (you still have to import just about anything), and the lack of metaprogramming. But those I don't miss.

>>

 No.11300

>>11296
>>11297
>Sure, but on the grand spectrum, it's simpler than almost everything else popular, and many of its contemporaries.
My point stands.
>A statement is just an expression with a semicolon, or one of the special control structures. The language is imperative; what do you expect?
It really ties in to the previous point.
>The same can be said for mathematics as a whole. It's reasonably easy to memorize.
Mathematics gets to piggyback on what almost all humans know. Can you tell me the operator precedence for << off the top of your head? There's 15 levels of precedence.
>Even Scheme has special forms.
They evaluate their arguments differently. They use the same syntax.
>Imagine the nightmare on embedded systems with an implicit standard library. Good-bye, whatever limited memory you had.
>On Plan 9, you have to do minimal includes compared to UNIX.
The point is that the compiler could very easily only include what is actually used, since functions can't be created at runtime.
>The preprocessor, while limited, does in fact facilitate metaprogramming.
Text macros enable metaprogramming like brainfuck enables turing completeness.
>So are many useful things.
Name some of these things.

>>

 No.11305

>>11300
>>Imagine the nightmare on embedded systems with an implicit standard library. Good-bye, whatever limited memory you had.
>>On Plan 9, you have to do minimal includes compared to UNIX.
>The point is that the compiler could very easily only include what is actually used, since functions can't be created at runtime.
Are you talking about the linker or the compiler? The linker for any embedded compiler already does this. If you just don't like how, say, string.h is separate from stdio.h that seems pretty superficial. How is it a pitfall?

>>

 No.11309

>>11203
>>11207
"X is bad."
"15 reasons why Y must go."
"Why Z is holding us back."

What is this? Some boilerplate article from Cracked?

>>

 No.11310

>>11309
>"X is bad."
Yeah, I agree.
Lets hope that Wayland will be better.

>>

 No.11311

>>11305
The point is that the standard language forces the programmer to painstakingly point out exactly what they're using, while that is completely unnecessary.

>>

 No.11312

>>11309
Posting evidence makes arguments better. Stop responding emotionally.

>>

 No.11316

%%Pressed F.%%

He's a great guy, even if C is soykaf . You may ask: why all of you are talking about C not UNIX? I second the question. UNIX was as great as Ritchie.

By the way, he shoul be remembered more than Steve.

>>

 No.11317

>>11300
>Mathematics gets to piggyback on what almost all humans know. Can you tell me the operator precedence for << off the top of your head? There's 15 levels of precedence.
Looser than arithmetic and subscripting; tighter than comparison and logical. It's not that hard to learn. Neither is mathematics.
>They evaluate their arguments differently. They use the same syntax.
So the work gets thrown on the lexer instead of the parser. Whoa, how revolutionary.
>The point is that the compiler could very easily only include what is actually used, since functions can't be created at runtime.
#include <u.h>
#include <libc.h>

Tadaa, and the linker throws out whatever you don't need.
>Text macros enable metaprogramming like brainfuck enables turing completeness.
They're for occasional utility, whereas in other languages with more advanced, AST-based macro systems, macros are one of the primary means of abstraction. If you need massively complex macros in C, you're probably not actually writing C, you're writing some other language *in* C. For all I care you can consider that language superior.
>Name some of these things.
Treating data as a raw, untyped block of bytes when necessary, among other low-level manipulations that would take involved stack dancing in Forth.

>>

 No.11321

>>11311
That sounds like an annoyance (I agree, it can get very annoying), but I don't see how it is a pitfall.


>>

 No.11582

>>11316
C's only reason was to program unix. without unix, there no c.

>>

 No.11584

>>11312
Dude, ever heard about listing reasons for *and* against something?

Saying that something is "obsolete" or "must" go and then list reasons is just ex post rationalization.

>>

 No.11598

File: 1446820383302.png (295.72 KB, 370x460, 1437880944607.png) ImgOps iqdb

>>11584
Everything isn't subjective.

>>

 No.11603

File: 1446831195492.jpg (518.32 KB, 1440x792, Aspect-Emperor.jpg) ImgOps Exif iqdb

I ordered K&R at a book store today. Within 10-14 days, nothing can stop me.

>>

 No.11615

>>11603
k&r is piece of crap. c primer plus is the only decent book on C.

>>

 No.11616

>>11615
That's definetly not true.
Even if it's not the best textbook for learning C, it's still an important piece of UNIX history and worth a read on that basis.

>>

 No.11625

>>11615
Deep C Secrets is the best C-related book I've read so far.

>>

 No.11639

File: 1446886244080.jpg (129.21 KB, 997x595, Bashrag-v-Nonman_sm.jpg) ImgOps Exif iqdb

>>11615
>>11616
To say that there's a conflict between a good teaching book and a good reference book is only partly true. For us who know that programming is just applied mathematics a good reference book is the best teacher.

Pic related, me to the right using C to fight some horrible OOP creation that uses 4 Kb of memory per instance.

>>11625
Thanks! I'll check it out too.

>>

 No.11640

File: 1446887298719.jpg (66.92 KB, 590x632, 161017757_44042348.jpg) ImgOps Exif iqdb

>>11639
>For us who know that programming is just applied mathematics
lel, k tard.
http://plato.stanford.edu/entries/computer-science/#Pro

>>

 No.11641

>>11639
> some horrible OOP creation that uses 4 Kb of memory per instance.
Nice meme. What's up with all the C fanboys thinking they hold the ultimate truth and everyone else is wrong?

>>

 No.11642

File: 1446893949762.jpg (56.99 KB, 500x600, C vs OOP in Oracle Java.jpg) ImgOps Exif iqdb

>>11640
A good algorithm on an low-performing computer will always beat a bad algorithm on a high-performing computer.

And exactly where did your link contradict me? Applied mathematics implies a lots of physical manifestations. Paper, pen, eraser, black/whiteboard, calculator, rulers, etc, etc, etc.

Also applied mathematics doesn't imply that it has to be fancy. Consider COBOL. It's made for accounting. True, you could say that it's more calculations than pure mathematics. But still, a better algorithm will make the tedious tasks better. Let's say that you want to calculate the price of something before a VAT of 15% was added. Here's a really bad way to do it:

price_no_vat = price_with_vat / 115;
price_no_vat *= 100;


And here's a better way:

price_no_vat = price_with_vat / 1.15;


Pretty basic algebra. Let's up the ante, shall we? Let's calculate the value of VAT. Here's a bad way:

vat_amount = price_with_vat / 115;
vat_amount *= 15;


And here's the better way:

vat_amount = price_with_vat * 15 / 115;


And it works even better if VAT is a variable:

vat_amount = price_with_vat * vat / (100 + vat);


Multiply this task with a few 100 000 or 1 000 000 and you'll see why it's better. :P


>>11641
Well, C is the base of C++, C#, Objective-C and so on. But do try to fiddle around with "bare metal" using Java C#. B-) Of course I will learn C++ and Objective-C. But as for now, the gnosis of C will do.

>>

 No.11645

>>11642
I'm sure it's pretty cool from a mathematical point of view, but please never use floats for money in a real system, they are inaccurate and someone will lose money on it.

>>

 No.11646

>>11642
What point are you trying to make by solving a trivial pen and paper problem in the most long-winded way possible?
>>11645
No types were defined, why do you assume he's using floats?

>>

 No.11654

>>11645
Good point! Thanks!

>>11646
The case for good algorithm is still valid. Of course I could use a more cumbersome example. Buy this was more simple.

>>

 No.11655

>>11642
I don't understand what the difference is between the "good" one and the first "bad" one. At best the "good" is slightly slower than the "bad" one. Sure, it is more flexible but from what I can tell your goal is to make it faster. It would also be easy to make the first one just as flexible as the last one by making the value 115 a variable.

Writing everything on one line does not, in fact, make the code run faster.

>>

 No.11660

>>11642
: vat  15 115 */ ;

C programmers are truly enlightened.

On a 32-bit machine, this uses a 64-bit intermediate result.

>>

 No.11666

>>11642
>And exactly where did your link contradict me?
have you read

7. Programming
7.1 Programming as a Mathematical Activity
7.2 Programming as Engineering Design
7.3 Programming as Theory Construction

>>

 No.11669

File: 1446931625812.jpg (1.87 MB, 2000x2610, c_unites_workers.jpg) ImgOps Exif iqdb

>>11641
Because the lower level you go, the more hardcore you grow.

>>

 No.11672

>>11241
>thought it would teach me more about how computers work than java has
In a way it does. You learn about pointers, manual memory handling and difference of signed/unsigned. But then you realize it's all just abstraction and design choices anyways. Don't worry, learning C is very good but don't think it's "closer to the metal". It's still a compiled language that doesn't map directly to hardware.

>>

 No.11684

>>11639
Programming in C is about as far as you can be from "programming as applied mathematics".

The fact that you're even talking about "memory" is evidence of that. What is "memory" to mathematics?

C programming is "applied von neumann computer fiddling".

>>

 No.11685

>>11684
Perhaps the concept of memory is where the "applied" part comes from.

>>

 No.11692

>>11685
That's stupid. By that logic, everything is "applied mathematics", mathematics with accumulated circumstantial limitations that have no universally applicable principles. Not mathematics at all then, just fiddling with a thing that doesn't work how it really should.

Low level programming is the opposite of mathematics, because it forces you to deal with non-mathematical mechanisms. High level programming is mathematical specifically because it abstracts away the non-mathematical reality of the computer and allows you to apply mathematics directly, so long as you have a fast enough computer.

And our computers are now very, very fast.

>>

 No.11706

>>11692
Memory usage and time are the only two resources that are accounted for when discussing an algorithm. I certainly remember my algorithms class talking about the space complexity of certain algorithms, and even discussing whether the algorithm can be done in place (which in general will only affect the constant in front of the space complexity).

Sure, you can argue that C forces you to consider the constant factors of space complexity. But to say that if you aren't ignoring memory usage you aren't doing applied math is wrong.

>And our computers are now very, very fast.
Then why does everything on my phone take seconds to load? Why does my phone lag? Why do half the programs I use at work put up a splash screen when loading? I'm sick of waiting for my computer and later reading that computers are "fast". If my computer really was fast I wouldn't need to be reminded.

>>

 No.11738

>>11706
Not the same guy but
Your phone lags because it's using jabba
And it's soykaf you should've saved a little more and buy a good one
It bothers you because you're unaware of all it might have to do to keep up with your playing angry birds while the facebook and google apps send all your sensitive data to the juice.
And computers are very fast, they've been steadily growing in speed for the past few decades, but you didn't really get to use a 386, you expect your phone to be faster than it is, amd so you think it's really slow.
In fact, computers are now so fast, that developers don't care much about efficiency nowadays, let an app interpreted by a virtual machine run an interpreted language itself, and let that language have poor algorithms doing fancy useless stuff on top of a hundred frameworks all piled up on top of each other because that's what an elite js programmer do, put eveey possible framework in a website evem if there's no need for it

>>

 No.11741

>>11738
Those were rhetorical questions.

>>

 No.11757

https://www.youtube.com/watch?v=1S1fISh-pag

>>

 No.11766

File: 1447076947192.jpg (27.92 KB, 668x491, Pascals triangle.jpg) ImgOps Exif iqdb

>>11666
Nope. Please post some quotations that supports your case the best.

>>11692
>And our computers are now very, very fast.
Still no excuses for sloppy algorithms. Consider Pascal's triangle. One of the things it is a representation of possible combinations (foobar) of participants (bar) and those who show up (bar).

When foo is 0, then bar must be 0 and foobar is 1, and so on:
foo 1, bar 1, foobar 1
foo 3, bar 2, foobar 3 etc...

One atrociously sloppy way to calculate foobar is to let foo be the bit length of a digit and bar the amount of 1:s. Then you decide the largest foo-length binary number with bar 1:s and start to count down to the smallest number with bar 1:s:
foo 3, bar 1

100 - foobar++
011
010 - foobar++
001 - foobar++
This was just a simple case with only one negative hit. But if foo = 20 20 and bar = 5, then the amount of negatives are just too much.

The simplest way to decide foobar is to use a binominal equation (something that I can't do yet). One middle way is to use a matrix that simply creates a Pascal triangle. Not as efficient as that equation, but far better than than wading trough lots of negative hits.

My 2 cents? A C-64 using the matrix method can probably calculate the foobar of really high foos better than a modern computer using the "bit-method".


>>11706
Well, I'm taught that there's no excuses for bad algorithms. Consider this:
foobar = foo + 1 + bar - 1
Any middle school pupil realizes that the +-1 is just filling and will simplify it to:
foobar = foo + bar
But this simplification won't happen in the compiling, because the compiler can't decide that "This is just soykaf, I'll disregard it."

And of course programming is lots of other things than applied mathematics. But the fact that I prefer to sit on a comfy chair by my desk when I program doesn't make programming applied mathematics + a comfy chair.

>>

 No.11787

>>11642
I stand corrected. The two-line algoritm of vat_amount is just a little slwoer than the one-line. And both are far better than the third, really convoluted I believed was best:
#include <stdio.h>
#include <time.h>
int main()
{
    clock_t begin_process[3], end_process[3];
    double time_spent[3];
    int algo = 0, total_algos = 3;
    float price_with_VAT, VAT_percentage, VAT_absolute;
    long int i, algo_loop;

    printf("This program tests the efficiency of various algorithms of calculating the VAT.\n\n");
    printf("Enter the price with VAT: "); scanf("%f", &price_with_VAT);
    printf("\nEnter the percentage of VAT: "); scanf("%f", &VAT_percentage);
    printf("\nEnter how many times you want the algorithm to be looped: "); scanf("%d", &algo_loop);

    for(i = 1, begin_process[algo] = clock(); i < algo_loop; i++) {
        VAT_absolute = price_with_VAT / (100 + VAT_percentage);
        VAT_absolute *= VAT_percentage;
        }

    end_process[algo] = clock();
    time_spent[algo] = (double)(end_process[algo] - begin_process[algo]) * 1000.0 / CLOCKS_PER_SEC;
    algo++;

    for(i = 1, begin_process[algo] = clock(); i < algo_loop; i++) {
        VAT_absolute = price_with_VAT * VAT_percentage / (100 + VAT_percentage);
        }

    end_process[algo] = clock();
    time_spent[algo] = (double)(end_process[algo] - begin_process[algo]) * 1000.0 / CLOCKS_PER_SEC;
    algo++; 

    for(i = 1, begin_process[algo] = clock(); i < algo_loop; i++) {
        VAT_absolute = price_with_VAT / ((100 + VAT_percentage) / VAT_percentage);
        }

    end_process[algo] = clock();
    time_spent[algo] = (double)(end_process[algo] - begin_process[algo]) * 1000.0 / CLOCKS_PER_SEC;
    algo = 0;

    printf("\n\nVAT_absolute = price_with_VAT / (100 + VAT_percentage)\nVAT_absolute *= VAT_percentage");
    printf("\nTime passed: %f ms", time_spent[algo]);

    algo++;

    printf("\n\nVAT_absolute = price_with_VAT * VAT_percentage / (100 + VAT_percentage)");
    printf("\nTime passed: %f ms", time_spent[algo]);

    algo++;

    printf("\n\nVAT_absolute = price_with_VAT / ((100 + VAT_percentage) / VAT_percentage)");
    printf("\nTime passed: %f ms", time_spent[algo]);
}

>>

 No.11794

>>11766
>But this simplification won't happen in the compiling, because the compiler can't decide that "This is just soykaf, I'll disregard it."
Actually that's exactly what happens.
$ cat a.c 
int add(int foo, int bar)
{
return foo + 1 + bar - 1;
}
$ cc -c -Os a.c
$ objdump -S a.o

a.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <add>:
   0:8d 04 37             lea    (%rdi,%rsi,1),%eax
   3:c3                   retq

>>

 No.11802

>>11794
So exactly how much leeway will a compiler give you?

>>

 No.11809

>>11802
Modern compilers give you lots. They do as much as they can to optimise the resulting code, though it can be disabled through compiler flags. This specific example is known as constant folding.

>>

 No.11811

>>11809
So disabling the compiler flags is good for you?

>>

 No.11813

>>11794
>>11802
>>11809
>>11811
The problem with C is it doesn't provide any standard way to communicate with the compiler, except for register and perhaps one or two other things I'm forgetting.

This is why C compilers are now millions of lines long, because they need that to have an optimized program.

>>

 No.11926

>>11262
Fuck macros. Nearly puke every time I see a code macro.

>>

 No.11949

>>11813
What's your point? That optimizing compilers are bad?

>>

 No.11951

>>11949
Complicated compilers are bad.

Really, I'm skeptical that any program _needs_ to be 1000 lines long.

Now, if a standard library has 1000 functions, you're probably not going to be able to implement it in 1000 lines, but I think you get my point.

>>

 No.11953

>>11951

>Really, I'm skeptical that any program _needs_ to be 1000 lines long.

I hope this is rhetorical

>>

 No.11955

>>11953
I don't know what you mean.

Obviously you can extend programs with your own customizations, like you see with text editors, but operating systems and probably anything else can fit in 1000 lines if you try.

It's hard to do if you're going to just write a program without thinking, but careful consideration can make very efficient and very compact programs.

>>

 No.11956

>>11955
>operating systems and probably anything else can fit in 1000 lines if you try
I'm not sure if you're trolling.

>>

 No.11957

>>11956
I'm not trolling.

Do you think all of the operating systems for microcomputers and others were thousands of lines long, to give some examples?

>>

 No.11961

>>11955
>operating systems and probably anything else can fit in 1000 lines if you try.

I've written very very small operating systems.

The smallest one with any features you could reasonably expect today was well over 1000 lines.

>>

 No.11963

File: 1447463621282.png (51.23 KB, 1199x224, ide.png) ImgOps iqdb

>>11961
Chuck's site is currently having issues and so I can't get to the distribution to judge exactly how large the system is, but colorForth may have all or most of the functionality in under 1000 lines.
Here's an IDE driver in 5 lines:
http://www.colorforth.com/ide.html

Forget about operating systems though. Think about other programs now. Can you think of anything else that _must_ be expressed in more than 1000 lines?

>>

 No.11964

>>11963
an IDE driver is not the same thing as a full virtual file system.

as for other applications, I'd point to video games.

>>

 No.11967

>>11964
>an IDE driver is not the same thing as a full virtual file system.
ColorForth just writes directly to disk blocks. There is no filesystem. There's only numbered blocks.

>as for other applications, I'd point to video games.
That's similar to the above example of a standard library. If you're designing a video game, just the writing may take up tens of thousands of lines.

There's obvious limits on what you can fit in so much space, but I still don't think so many programs need to be 50,000 lines or however long. If you want a concession, I seriously doubt any program I use needs to be more than 10,000 lines long.

Try looking at TempleOS as another example. It fits games, documentation, and everything else in less than 100,000 lines. It's actually auditable by a single person. It's important to have software that a single person can fully understand.

Just trying to read some program sources isn't feasible because there will be thousands of lines alone dedicated to header includes and other cpp needs.

>>

 No.11969

>>11957
Sure. I don't disagree with the idea that useful and correct software can be written in 1000 lines. But there are large and complex systems that need to be controlled, and complicated languages that need to be compiled, as well. I don't think you could write an OS/compiler/etc. for those in under 1000 lines.

>>

 No.11982

>>11967
>There's obvious limits on what you can fit in so much space, but I still don't think so many programs need to be 50,000 lines or however long. If you want a concession, I seriously doubt any program I use needs to be more than 10,000 lines long.
How do you read and post to this website? cURL running on an rtos?

>>

 No.11987

>>11982
>How do you read and post to this website? cURL running on an rtos?
I currently use Firefox. I really hate it. It crashes constantly.
Lainchan is one of the only websites I use anymore and certainly the only one that I have problems browsing with links or eww.
It has a simple API, so I have considered building a utility specifically for using the site. I'm busy with a few other things though, so it's on the back burner.

>>

 No.12059

>>11201
>reading through k&r
>word count program
>copy code to the letter
>compile and run
>the word count of "Hello world": 1431706545
the fuarrrk?

>>

 No.12061

>>12059
nvm forgot to initialize

>>

 No.12097

File: 1447863091816.jpg (222.89 KB, 900x675, 1434472323789.jpg) ImgOps Exif iqdb

>>11309
You have successfully cracked the patter in posts where people fake knowledge in the topic.


Delete Post [ ]
[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]
[ Return / Go to top /