Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
How does knowing philosophy help you implement a programming language?
What is "true"? What is "false"? What is binary? What is the best programming language? Why are Rust devs such insufferable faggots? The sphere of inquiry that proposes answers to these questions is philosophy. Remember, mathematics and logic are subfields of philosophy, as are science and engineering.

A lot of people think that engineering rules the world of programming. It ought to be more prevalent, but in practice, practically everything boils down to philosophical argument. The optimizations GCC can perform are a consequence of its design choice of GIMPLE as its IR.
 
A project I'm tinkering with might require multigraphs, and I already feel my hair graying. I'm too smooth brained for that shit
 
Then why are philosophers and other humanities scum so notorious for being unable to understand mathematics? Rhetorical question.
continental-philosophy-versus-analytical-philosophy.png
 
from quick googling scheme is made for kids?

by simplicity is key I was more leaning towards writing efficient code over picking languages

it's sad that nobody really gets taught assembler and reverse-enginerding anymore (at least in the college I went to, so I suspect it's the same in others), you have to specialize

<insert terry a, davis quote here>
 
Last edited:
from quick googling scheme is made for kids?
no it isn't, scheme is made for white people and taught to kids because it's that fucking simple ( the entire r5rs spec is about 50 pages long)
it can also be quite fast if you write it in a way that cooperates nicely with the compiler (many scheme environments have easy-to-access commands to print register-machine disassemblies of various program fragments)
by simplicity is key I was more leaning towards writing efficient code over picking languages
the most efficient code for any given hardware will certainly not be simple at all
an important part of building programs that aren't brittle, broken, and retarded premature optimizationslop is carefully picking your battles
it's sad that nobody really gets taught assembler and reverse-engineer anymore
assembly is important but if you always write everything in assembly you are retarded
much like how being able to shoot a gun is also very useful sometimes, but you don't go around shooting everybody you see
 
no it isn't, scheme is made for white people and taught to kids because it's that fucking simple ( the entire r5rs spec is about 50 pages long)
A lot of what goes into Scheme is pretty easy to understand (in my opinion) but the brevity of the spec does not make all of it "simple". (Said brevity also raises the far more practical quandary of balkanized implementations.)
 
A lot of what goes into Scheme is pretty easy to understand (in my opinion) but the brevity of the spec does not make all of it "simple".
yeah there might be 17 phd thesis floating around about various techniques for implementing hygienic macro expanders, but i find it doesn't leak that bad into the actual experience of using the language to write programs YES YOU HASKELL
(Said brevity also raises the far more practical quandary of balkanized implementations.)
true, which is why there are srfis that sort of help and new rnrses that also sort of help
however, at the end of the day most schemers just pick an implementation and target that, because generally implementations are decently portable

also recent standardization efforts in module systems and certain semantics have made it somewhat easier to get around the balkanized implementation problem if you really needed to
 
yeah there might be 17 phd thesis floating around about various techniques for implementing hygienic macro expanders, but i find it doesn't leak that bad into the actual experience of using the language to write programs YES YOU HASKELL

true, which is why there are srfis that sort of help and new rnrses that also sort of help
however, at the end of the day most schemers just pick an implementation and target that, because generally implementations are decently portable

also recent standardization efforts in module systems and certain semantics have made it somewhat easier to get around the balkanized implementation problem if you really needed to
Do you have a preferred scheme implimentation? Secondly, what’s your opinion on non-Scheme Lisps (Common, Emacs, Pico, Clojure, etc.)? I’ve mucked around with Lisp for as long as I’ve had any interest in programming, but I’ve never been able to get too far into it.
 
Very often char* points to a string literal such as "dGhlIGwhatever".

That string literal gets placed in the .rodata section of the process image which is mapped read-only. Try mutating it and you *do* get a segfault.
Not to be too much of a pedantic nigger o algo, but modifying string literals isn't necessarily a segfault. The standard only says that modifying them is undefined behaviour, so you could be on an architecture that doesn't support read-only segments, or maybe you have a very retarded compiler that puts it in .data and you won't get a segfault

I looked up whether or not you could force compilers to treat string literals differently and found out that Clang has -fwritable-strings, which does exactly what I mentioned and places string literals in the .data segment. GCC used to have this option but it was removed in GCC 4
C:
#include <stdint.h>
#include <stdio.h>

void set_data(void *data) { *(uint64_t *)data = 431197875827; }

int main(void)
{
        char const *s = "dGhlIgdhbWU=";
        set_data(s);
        printf("%s\n", s);
        return 0;
}
When compiled with -fwritable-strings, it outputs "sneed" as expected. Running objdump confirms this: Contents of section .data: 0000 6447686c 49676468 6257553d 0025730a dGhlIgdhbWU=.%s.
Basically, all of this to say that the original image is complete retarded coal made by some 1st-year CS troon
 
Do you have a preferred scheme implimentation?
gnu guile is pretty fucking good, there have been some very neat things written in it
no scheme implementation seems to be a silver bullet imo, but guile is decently fast, has a fairly decent set of libraries, has decent documentation, and is overall decent
the only disadvantage is it being almost completely broken on windows but i have heard they are trying to fix that
Secondly, what’s your opinion on non-Scheme Lisps (Common, Emacs, Pico, Clojure, etc.)?
they are varying degrees of based but none of them are quite as based as scheme with its guaranteed proper tail calls and general "this is how lisp is meant to be" design
implementing various looping constructs as a macro over a goto primitive is neat, but there's just something properly autistic about implementing looping constructs by literally just using function calls

it is general consensus among everybody, diehard emacs users included, that elisp is fucking retarded. however, it is merely the most retarded lisp, which makes it far less retarded than something like tcl
common lisp is pretty ok but it's also kind of old and crusty. thankfully the different implementations' ways of doing e.g. threading tend to be more similar to permit compatibility and there are some libraries for taking the pain out of portability too
clojure is weird and i've never touched it but there seems to be a small but very dedicated userbase like the haskell people
and finally this may be a hot take but i think a lot of these nu-lisps shouldn't even be bunched in with lisps or referred to as lisps. some of them don't even have pairs as a first-class type, which fucking destroys the magic
I’ve mucked around with Lisp for as long as I’ve had any interest in programming, but I’ve never been able to get too far into it.
you should probably pick exactly one and make something cool in it. you could use elisp and hack together emacs things (and yes, stalker, you should be using emacs. for some reason it seems that 97% of lisp programmers out there use emacs) or maybe you could try your hand at guile and fuck around with gnu guix
if you want you could also pick a nice scheme that compiles to c, like chicken, and make a video game or something
 
no it isn't, scheme is made for white people and taught to kids because it's that fucking simple ( the entire r5rs spec is about 50 pages long)
it can also be quite fast if you write it in a way that cooperates nicely with the compiler (many scheme environments have easy-to-access commands to print register-machine disassemblies of various program fragments)
I think you misunderstood my post a bit, and I will clarify - I just woke up when I posted, so I wasn't fully awake yet.

Low-level programming is easier to optimize in the micro sense because you actually control the resources the CPU cares about, like registers, stack layout, alignment, instruction mix, cache lines, branchy vs branchless code, prefetching, and SIMD lanes.

If you want predictable cycle counts, fix register allocation and instruction scheduling yourself, hand-tune loop tiling to hit L1/L2, avoid GC allocations, and you’ve removed most of the abstraction barriers a compiler or runtime has to reason about.

That’s why embedded and kernel developers, as well as crypto folks still handcraft "hot" paths.

However, in my opinion “easier” also equals narrower: it’s easier to reason about micro optimizations when you control the machine, but doing that across a large codebase is a nightmare, ABI compatibility, portability, correctness, and maintenance blow up fast, so we agree on something :)

High-level code gives you flexibility and lets modern compilers / JITs (along with escape analysis, SSA optimizations, auto-vectorization, inline caching or whatever other compiler optimizations you chose to enable) do the heavy lifting that you would otherwise have to implement manually. Most real perfomance comes from algorithmic changes, better data structures, and improving locality, not rewriting everything in ASM.

I said it’s a shame barely anyone gets taught it now unless they specialize. *sigh*

Knowing how the machine actually behaves is useful, even if you don’t go full caveman and assemble your entire app manually.

Anyway, thank you for telling me about Scheme, it actually does look interesting.
 
Last edited by a moderator:
I'm thinking about picking up programming again after a break of 20+ years, but I don't ever want to come in contact with trannies or even worse: become a tranny myself. Just a thought.
I've been doing it exclusively in my own company just digging around in books and consulting with LLMs about theory/concepts and it's been quite satisfying. There may be some downsides, sure, but I've been making some solid headway, I'm definitly satisfied and consistently learning stuff.
 
Jersh was right as per usual, LLMs truly are fantastic when it comes to code. Even for just finding the keywords you need to search further
 
However, in my opinion “easier” also equals narrower: it’s easier to reason about micro optimizations when you control the machine, but doing that across a large codebase is a nightmare, ABI compatibility, portability, correctness, and maintenance blow up fast, so we agree on somethin
Both extremes of the imperative-declarative spectrum are a pain in the ass for different reasons
I'm thinking about picking up programming again after a break of 20+ years, but I don't ever want to come in contact with trannies or even worse: become a tranny myself. Just a thought.
Make sure you use FreeBSD instead of Linux so that you don't end up with AIDS:
 
I'm thinking about picking up programming again after a break of 20+ years, but I don't ever want to come in contact with trannies or even worse: become a tranny myself. Just a thought.
I would suggest trying Advent of Code; it is a good tool for learning. Think of it as programming Puzzles. The idea is that every day until Christmas (now only to the 12), a new puzzle with 2 parts is given, and you try to solve it. It is language agnostic, and I use it when I want to maintain or train a new language. Now, if you're very new, I would maybe start with an earlier year, as there is more documentation out there to help.

Plus, it is fun if you like puzzles.
 
Back
Top Bottom