/tech/ - Technology★

Each one has its place

You're allowed to read more than one book.

t. guy who has gone through both

Also go watch the original SICP lectures on youtube

just get both

Both obsolete.

Get a book 'bout Rust. Unironically.

>>897314

>Rust

I'm not a sjw soyboy who has nothing at all against shitty ersatz ingredients like high fructose syrup or hardened palm oil, but for some reason hates gluten and lactose with a passion because xe was conditioned to.

>>897315

Stay unemployed, LARPer.

>>897316

>only rust soyboys have jobs nowadays

ok

>>897280 (OP)

Are these the only two 10/10 programming books out there? If not, what others are there?

>>897317

>>897318

>Forth

why

>>897317

>>897318

can someone the books in OP and not this?

>>897287

>SICP lectures

Too bad Dennis Ritche didn't give lectures (at least there's none I'd be aware of).

>>897482

Pretty sure they're in the gentoomen library.

>>897477

Because Forth> C >>>> Everything else

>>897280 (OP)

They are all bad. All are absolutely full of shitty runtime errors because of things that are trivially statically checkable.

if you have to ask, you probably are retarded.

tcpl should come first and is more of a tutorial and style guideline

sicp takes a while, and offers challenges you'll find tricky on the first read.

SICP is the greatest book I've ever read, ch4&5 blew my mind.

SICP teaches you algorithms, imperative code, functional code, logic programming, lazy programming, discrete logic, language design, interpreters, compilers, register machines / instruction set simulation, assembly language.

SICP is a fucking joke. The hardest parts of it are the few cases where the order of evaluation matters and the ass shit Lisp syntax. Only a legit mentally retarded code monkey would struggle with its math too. It's clearly a /g/-tier book. Also, FP is a meme for people who aren't intellectually capable of dealing with program states.

K&R is the designated shitting street of programming books.

>>897527

>I enjoy shitty software full of bugs

>>897530

>using functions for loops prevents bugs

Guaranteed you never made it past fizzbuzz.

>>897535

I don't use functional programming languages, but it's true and not controversial that excessive state causes bugs. It's one of the reasons global variables are discouraged.

The more the execution of the body of a function is affected by state outside it, the harder it is to reason about it. A purely functional function takes it to the logical conclusion and only allows execution to be affected by the arguments explicitly passed into the function.

>>897492

>Too bad Dennis Ritche didn't give lectures

What would he lecture about? How to program like pajeet?

>We went to lunch afterward, and I remarked to Dennis that easily half the materials I was installing in the basement were water and sewer pipes. He said, "We left all that stuff out. If there's an urge to take a shit, we have this bucket called panic, and when you shit, you squat over it, and you holler down the hall, 'Hey, dump it.'"

>>897538

Painfully true. You never had to deal with a mess of global arrays in Tcl. It's enough to make you want to ban use of states permanently

>>897540

>everything that was ever written in C (such as embedded software, firmware, drivers, kernels, low level systems and network software, high-performance high level software etc. etc.) is result of pajeet-tier programming

What useful and/or widely deployed things were programmed in Lisp again?

>>897603

This is a non-sequitur, and therefore not an argument.

>>897603

>>897605

Although, if you really want to know, tons of expert systems are written in Lisp, as are AutoCAD plugins, or GIMP plugins. Those are widely deployed, therefore fulfilling your request for useful or widely deployed.

>>897538

>global variables are discouraged

lol you passing in 50 variables into every function... oh wait ding ding ding I think we have an OOP tard.

>>897603

The airline search and pricing software used by most major US airlines and lots of sites like Orbitz is written in Common Lisp. Most people who have taken a commercial flight in the US or on a US carrier in the last 2 decades have used the software either directly or indirectly. That's millions of flights affecting millions of people involving billions of dollars.

>>897477

It runs great on even the smallest 8-bit computers and microcontrollers.

>>897280 (OP)

left if you're newbie (nothing wrong wth that, reading this will level you up) and right if you're intermediate

I learned C with K&R and my Amiga 500. Worked out pretty well. Getting paid well now. Knowing how a computer actually works gets you money. Don't believe the "fearless concurrency" and "if it compiles then it's error free" hype from the new Rust kids. Compile-time checks are not a replacement for actual understanding and they are not a free pass. The restrictions that Rust imposes will force you into non-optimal code. From what I've seen, it encourages an arrogant attitude towards memory, memory allocation, and understanding how this impacts performance and stability.

>>897613

If you'd need to pass 50 variables into each function your program is already fucked. Don't do that. Keep your functions small, reusable and understandable.

>>897280 (OP)

The C book is just a basic reference guide. SICP is clearly superior.

Lisp if you're a soyboy hipster who wants to wank over his "superior" code; C if you want to actually get shit done.

>>897627

>Amiga 500

Good old days, in a sense. But in another sense not so much - it was way more difficult to get things like software, books, or even information on what to learn and what you need to learn it (such as books and software). I would have loved to have a C compiler at my disposal in my Amiga days, but never had one because as mentioned above information and software wasn't just a click away as it is these days.

>>897280 (OP)

Both. K&R will teach you how to get work done, SICP will teach you how to not shit up your code. They are different books for different purposes, one is a language reference, the other is a textbook.

>>897613

If you need to pass that many variables you have already fucked up. That said, Racket has a great solution to global variables: paremeters.

https://docs.racket-lang.org/guide/parameterize.html

Basically, you have a "global variable" which you can mutate temporarily, and once to scope is left it reverts back to its original value. For example, the 'current-output-port' is basically stdout, but you can parameterize it to a file, call a writing procedure, and when it's done the parameter reverts back to stdout.

KnR C is like 100 pages. Why wouldn't you read it, even if just to read it to mock other people who do or don't read it.

>>897730

Mine is 270 pages. But yeah, it's short. Just read it.

>>897712

t. nodev

>>897736

It's deceptively short though, as working through it thoroughly can take quite some time. And even then returning to it after some time may have you notice and learn something you didn't before. It's a part of the book's "magic" I guess.

>>897661

Functions stay small and understandable if you aren't memed away from globals.

>>897725

It's kinda interesting but it's hardly the same thing.

>>897736

>nodev

Stop projecting, Lispfag.

You've had 60 years and the best thing to come out of your shitty language is a bloated text editor made by some pedo commie that eats his own toejam.

>>897769

>Functions stay small and understandable if you aren't memed away from globals.

No, because if you count all the explicit parameters and used globals and come out at 50 it's much too complated.

>>897715

You could have mail ordered a C compiler if you didn't have a nearby shop that sold Amiga software. There were always tons of ads in magazines, with phone number to call and/or mailing address to send off for a catalog. I ordered some Fred Fish disks this way to get PD software, since I didn't have a modem.

Computer books were pretty easy to get this way too, at least for the ones still in print.

So basically you really just needed a magazine subscription to keep informed back then.

>>897280 (OP)

1st will become obsolete (and already is to some extent)

2nd is timeless, as it's not about any specific programming language.

also if you're a competent programmer, you should be able to pick up a language simply by checking out the official specification/docs. PL books are usually bloat, unless the language comes with some unique concepts (C is not one of them).

>>897855

>1st will become obsolete (and already is to some extent)

because of C or because another book made it obsolete

>>897861

both, but mostly because of C

>>897864

Why do you say this ? And what do you see replacing C ?

Not baiting you or anything it's just that I see people along your line of thought all the time but I never engage in discussion.

C is obsolete enjoy writing programs with heaps of vulnerabilities

>>897823

Maybe for you brainlet

>>897868

>And what do you see replacing C ?

Rust

>>897892

Ha! Nope.

>>897868

you need not any spaces before '?'.

>Why do you say this?

C is a footgun, and takes too much developers' time on mundane shit.

>And what do you see replacing C?

C++ (very unlikely but possible if they manage to finally unfuck it in another 10 years), Zig, Rust, or nothing (kind of likely; that would also mean we as a civilization would be sent back several decades)

>>897910

…or maybe also a next version of C which will be unfucked enough to be viable again.

after all, the latest C standard is somewhat less of a shit bomb than the first versions were.

>>897910

>you need not any spaces before '?'.

Maybe he's french. they put spaces before '?' and '!' (go figure).

>>897855

>PL books are usually bloat,

If they weren't they how could they justify the price? At least 8 out of ten of those yuge 800+ page texbooks is >60% bloat, but thanks to its intimidating size they can keep charging $100 or more per copy. Nobody would pay 100 bucks for a 300 page book (even if it had exactly the same content as the 800+ one but none of the bloat, saving the reader lotsa time, ironically).

>>897986

>how could they justify the price?

oh man… there's a lot of things that get bought all the time despite them being worthless.

you just made me sad again by reminding about this.

>>897317

>>897318

Forth is like everything I like about LISP Polish notation, self boot-strapping and expandability and C close to the metal, fast and light on memory rolled into one.

Is functional C even possible? Maybe lambdas and closures are not possible, but passing pure data over everywhere should be possible.

#include <functional.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int my_reduce_func(int sum, int item) { return sum + item; }
// reduce_int created by MAKE_REDUCE(int, reduce_int); predefined

int my_filter(int num) { return num > 25; }
void my_map(int num) { printf("%d ", num); }

int main(void) {
  srand(time(NULL));
  printf("%d\n", reduce_int((int[4]){1,2,3,4}, my_reduce_func));
  map_int(filter_int(make_array(int, 20, rand), my_filter), my_map);
  puts("");
}

>>898119

Possible, but not probable.

>>898119

The issue with c is that its very difficult to make safe abstractions. For example if you want to make a generic list / vector / map / function whatever you have to make the type void*. This means you are going to end up manually casting all the fucking time, very error prone.

>>897314

I like Go better.

>>898278

What's Go's runtime overhead like? Wondering mainly about time. I'm curious which meme langs would be suited for system utils.

>>898372

It's relative. Think of Go like a statically linked java.

>>898433

any other language will be better than C for this.

>>898459

>any other language

Including assembly?

>>898475

There's no such language.

If you mean all of the assembly languages, it surely depends on the architecture.

And, most of the times, however funny, you still have less of Undefined Behavior when writing in some assembly. Go figure.

>>898477

>depends on the architecture

>less of Undefined Behavior

just lol

Every time I write a program in C, I have to rewrite half the functions from the Scheme run-time before things become bearable.

>>898119

yeah. just generate code at runtime.

Not recommended, something along the lines of this (needs changes to work)

void *lambda(void *fun, void *dat)
{
  char code[] =
    {
      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
      /* 0: */	0x48, 0x8d, 0x05, 0xe9, 0xff, 0xff, 0xff, /* lea    -0x17(%rip),%rax */
      /* 7: */	0x4d, 0x89, 0xc1,             	          /* mov    %r8,%r9          */
      /* a: */	0x49, 0x89, 0xc8,             	          /* mov    %rcx,%r8         */
      /* d: */	0x48, 0x89, 0xd1,             	          /* mov    %rdx,%rcx        */
      /*10: */	0x48, 0x89, 0xf2,             	          /* mov    %rsi,%rdx        */
      /*13: */	0x48, 0x89, 0xfe,             	          /* mov    %rdi,%rsi        */
      /*16: */	0x48, 0x8b, 0x38,             	          /* mov    (%rax),%rdi      */
      /*19: */	0x48, 0x8b, 0x40, 0x08,                   /* mov    0x8(%rax),%rax   */
      /*1d: */  0xff, 0xe0,                               /* jmpq   *%rax            */
      /*1f: */  0x90,                  	                  /* nop                     */
    };
  char *x = palloc(64);
  void *p1 = dat;
  void *p2 = &fun;
  memcpy(x, code, 48);
  memcpy(&x[0], &p1, 8);
  memcpy(&x[8], &p2, 8);
  return &x[16];
}

>>898526

for each one of them, there's only 1 architecture.

>>898640

and even if you finish this book you will still write vulnerable code in C.

Writing bug free code in C is hard as fuck and if you want to do it you spent all your time debugging memory corruption stuff.

>>898628

>palloc

Is the memory allocated by this function executable?

>>898686

>Only thing that is trivially type checkable

This is just wrong.

>>898824

I'll post a working demo after din-din.

>>898640

>K&R C is a good introduction to C, though it's insufficient on its own (and full of a bunch of flaws by necessity; tons of the examples are vulnerable to buffer overflow and other handfuls of errors because the proper error checking code would at least triple the sizes of the examples).

Now you understand it. A well-written C book would have been very bad news for C and RISC too. C with proper error checking code would be much bigger and slower than the same program in other languages, and it would still be buggier. RISC running that program would be slower than hardware designed to do the checks in parallel, like the Lisp machines. C would be slower (but safer) on a Lisp machine because it has to execute redundant code to do things the hardware already does.

Subject: why Unix sucks

Some Andrew weenie, writing of Unix buffer-length bugs, says:
> The big ones are grep(1) and sort(1).  Their "silent
> truncation" have introduced the most heinous of subtle bugs
> in shell script database programs.  Bugs that don't show up
> until the system has been working perfectly for a long time,
> and when they do show up, their only clue might be that some
> inverted index doesn't have as many matches as were expected.


Unix encourages, by egregious example, the most
irresponsible programming style imaginable.  No error
checking.  No error messages.  No conscience.  If a student
here turned in code like that, I'd flunk his ass.

Unix software comes as close to real software as Teenage
Mutant Ninja Turtles comes to the classic Three Musketeers:
a childish, vulgar, totally unsatisfying imitation.

>>898824

Pretty cool. I have also tried writing my own JIT compiler before.

Some ideas. You might want to make a code generation API. It's like an assembler: you just make calls such as emit(opcode, arguments...) or opcode(arguments...) and it accumulates the output in a dynamic array. You can use regular memory for this part. Once you're done, you transfer the whole thing to the executable page and turn off its write bit.

>>898891

look at that kid go, programming his abacus

>>898628

surely this is not cross platform anymore?

why bother with C at this point if you can build directly on top of your assembler of choice?

>>898979

Of course it's not cross platform. Assemblers don't exist at runtime.

Rustfags insulting C.

Juliafags insulting R.

PHP and JS shit everywhere

>>899204

>If you use C you waste time.

>trying to use C will result in worse performance and infinitely more bugs.

FTFY

>>897864

Any time you see someone talk about "C" being replaced here it is Rustcuck talking to you.

>>898686

>type checking is hard

maybe in your dependent typed haskell with 30 extensions or shitty ocaml or whatever hipster bullshit system you use

>>898983

Never read that one.

I should also point out that I was referring to how good the books are in terms of CS introduction, rather than teaching coding style.

As for coding style, SICP is much better for containing proper programming vocabulary and ideology.

In my opinion, one should ideally read The Elements of Computing Systems first, then SICP if he finds it proper, then whatever he finds necesarry if he does so.

>>899729

>C was for compiler construction, and is more of an UNCOL paired with an ABI.

They used C because it was the only compiled language guaranteed to exist on Unix. C's poor support for data structures make it a bad language for compiler construction.

>Why it caught on as *the* systems programming language?

It's because of the PC and Windows. These also made x86 the most popular architecture even though 68K and ALPHA were faster at the time.

>Why not Algol? Bliss? Pascal?

Because Microsoft chose to write Windows in C, which made other languages on Windows second-class. Microsoft had a C compiler. If the Mac was more popular than the PC at the time, we would probably be using Pascal. They were talking about making a successor to Algol 68 in the 80s. If IBM went with CP/M, we would probably be using PL/I. Microsoft killed classic VB when it was their most popular language. Those all failed for business or "political" reasons, not technological ones.

>My guess is ken's cc was the most studied peice of "real world" code, whereas other languages were fucked over by ivory-tower commitee driven design.

Most early 80s programming books don't mention C, and as the 80s went on, C started showing up gradually. Most C code was written after ANSI standardization in 1989. There were a lot more active ANSI and ISO standards groups back then (Pascal, PL/I, Algol, APL, Basic, Lisp, Prolog), so C was just another language at the time. There was a clear continuity from the 50s to the early 90s and then when C became popular, that knowledge and technology was lost.

http://www.pascal-central.com/padvoc.html

>Personally, I would never switch if I had any choice whatsoever. C is an atrocious language to begin learning programming, and C++ is not much better. You may as well be using assembly language. It's as if all the progress in programming languages that was made from about 1956 to 1986 was suddenly thrown out the window just because C was the language of Unix.

>The very best students can begin to learn programming with Lisp; all others should use Pascal. They can switch to C++ or Java or God knows what when they need to get a job -- if they get that kind of job and if something else hasn't become fashionable by then. The principles that really count are much clearer in Pascal that anything else, for most students.

>>898836

What's with the Unix Haters fags and calling people weenies? It sounds whiny and retarded.

>>900242

>There was a clear continuity from the 50s to the early 90s and then when C became popular, that knowledge and technology was lost.

Yeah seriously. I wasn't big on reading CS papers, I thought they were all irrelevant theoretical crap... But when I started browsing these older papers I got hooked. It's impressive how much our antecessors have accomplished... Many of our databases are based on 70s technology and science. I used to think technology of today was state of the art, but when I look at some older IBMs I doubt that notion. Areas that today are pretty much dead, such as programming languages and operating systems research, used to be brimming with life. I started collecting these papers... And I'm always worried that I'm missing some hidden gem that was lost to time.

I wish there was an extensive, annotated bibliography.

Is this the end of /tech/ pretending that C is a good language?

>>900254

Do you think people are going to call other people "retard monkey niggers" on their school email? Some of the excerpts are from mailing lists for their compsci department.

>>900391

I hope so anon

Why did we stop using Pascal? It is really nice and can go about as low level as C, maybe just slightly less, but you'd be lying if you say most of the programs written in C need all of C's low level.

>>900494

They probably thought Pascal is too academic, since it was originally designed for teaching structured programming. But it can do anything C can, and has real strings. Ada is another good choice.

Scheme and C are literally the only two languages you need, so you should end up reading both. I think SICP is better to start off with because it is so divorced from the realities of computer architecture. This is important because computer science has fuck all to to with computers.

Also functional programmers usually have no problem picking up imperative code, but the reverse isn't necessarily true.

>>900509

>are literally the only two languages you need...

If you want to write useless meme software, or a toy project to re-invent unix for the 1000th time because you think you know better.

>>900509

What do you use Scheme for?

>>901406

He uses it for writing scheme interpreters like ever other undergrad has done 10 thousand times.

>>901406

Scheme suffers from its relative lack of libraries, but it's a very powerful language.

>>901508

Nice dodge

>>901406

Web software, typesetting, music composition. Basically anything without stringent realtime performance requirements, because the safety/saved development time more than makes up for that.

>>902149

Yeah scheme is very safe for web devs.

>>902149

>Real time performance requirements

>because the safety

Scheme is not known for either of those things

>>902316

>Scheme is not known for either of those things

If its fallacies you want, scheme is the safest language based on CVEs.

What languages are known to be fast and secure?

Scheme in general appears to be more performant than perl, php, python, node.js, and possibly java.

chez scheme is fast and balanced when it comes to throughput vs latency (vs safety).

Scheme is second only to the ML family in terms of performance (ignoring fortran, c, c++, etc.)

I can't speak for safety, but I'm willing to bet most implementations are safe enough to trusted as a CGI.

What is the attack vector? eval? read-time eval? compiler bugs? unspecified behaivour?

The RNRS run-time is small enough to be thoroughly audited for safety by an individual.

>>902340

This is old news, but there was a point in time where the vendor's C and Pascal compilers were btfo'd by scheme.

http://haskell.cs.yale.edu/wp-content/uploads/2011/02/retrospective.pdf

http://repository.readscheme.org/ftp/papers/orbit-thesis.pdf

>>902340

>based on CVEs.

Because no one uses it. Lots of languages have literally no CVEs.

>Scheme in general appears to be more performant than perl, php, python, node.js

All horrible shitty scripting languages.

>chez scheme

I agree is the best Schema

>Scheme is second only to the ML family

If you exclude literally every language known to be fast.

>>902377

Even with "etc" its a copout.

>its fast except for all these things that are fast etc

>>902378

to be fair, the only point I'm trying to make is that scheme is the only "dynamic" language worth using as it is more similiar to well researched languages like ocaml rather than adhoc shit like python, with only half the autism from haskel.

>>902380

I like that scheme is fairly strongly typed without type coercion. When something is wrong it errors instead of just randomly trying to push on and fucking everything up. If I have to deal with a dynamic language I would want it to be scheme.

>>902340

>scheme is the safest language

>>902377

>its literally the safest language

hmm I'll have to learn this safest language

>>902380

>scheme is the only "dynamic" language worth using

oh shit what have I been missing out on

>>902385

>When something is wrong it errors instead of just randomly trying to push on and fucking everything up

damn tell me more about this feature?

>>902410

>damn tell me more about this feature?

Most dynamic languages just change the type of the value if you use it wrong and propagate the value. This leads to a shit ton of errors. Scheme just errors.

Both are decent, but bad places to start. In my experience, using K&R as a resource if you're completely new to programming is pointless. I learned using "C Primer Plus" by Prata. He isn't exactly "excellent" (and some would argue a giant book for the C language is wrong, on a philisophical level - but if you're completely new, you'll appreciate the verbosity). But, you definitely should read K&R once you have wrapped your head around the language.

>>902504

>"C Primer Plus" by Prata

One of the better ones, but not *the* best though - the consensus seems that "C Programming - A Modern Approach" by King is currently the best book to learn C from. I have yet to find something factually inacurate in King's book, while I do remember some minor inaccuracies in Prata's book (such as considering declarations to be statements, or stating that all hexadecimally represented integers are always unsigned, both of which are wrong in C).

>>897314

Rust sucks and looks to be going nowhere fast

>>897315

>>897330

The community surrounding a language =/= the language

>>897910

>c++