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
so i can have two layouts and switch between them
nvm i cant
when i press alt gr x on the us layout while having the polish layout in the background it just inserts x instead of triggering M-x
i have no idea why it would work that way
Yeah I lived like this for a long time, but keeping the "state" of the keyboard in my mind was kind of annoying, especially if I wasn't just sitting at the computer, I sometimes even typed something out with the wrong keyboard, which sucks. As I hinted at, I recently made a custom layout that incorporates the symbols I use on top of the us keyboard (using alt gr, sometimes shift).
personally i really like having default things, im not a customization fan
and this way i dont need to fight my muscle memory when i have to use the default layout

so so far (neo)vim is better for this keyboard because the modifier keys are way too annoying to access
 
Using lisp for a database pool is retarded. It's even more retarded with mutexes.
Doing synchronization outside of the language would be doable, but that'd freeze up the whole process. Green threads vs OS threads.

I wanted to keep the whole project in one language when possible. That would mean playing nice with srfi-18 threading, which means mutexes.

I'd have preferred if there was a library for this. But it's not so terrible doing it myself. I'm just nervous about the concurrency. But beyond the concurrency, it's just pretty simple pointer bookkeeping.
 
...
guys i think arrays SHOULD start at 1
I like the way Ada handles this: every array type has an explicitly specified index type instead of just always being int or size_t or whatever. Because types and subtypes can be freely defined and the language actually cares about them beyond just aliases, this means arrays can start and end wherever you want, and it is always documented.

As to the actual merits of starting at 1, it fits the convention used in mathematics better. It's common in specifying ranges for both ends to be inclusive, so it's easier to say "from 1 to N" than "from 0 to N-1". On the other hand, it means that if you want to specify an empty range you need to do something gross like "2..1" instead of just "1..1".

I tend to still prefer starting at 0, though.
 
honestly i believe if arrays werent a syntax sugar over a pointer but their own object/abstraction they would start at one, since in mathematics first element of something is denoted using a "1" not "0"
but it does make math a little bit wonky, for example taking a mod of something would require adding a one and such
 
He appears to be the type of programmer who prematurely optimizes everything, not getting any actual work done.

"Premature optimization" is one of those idiotic terms strewn about by OOP cult members. The irony is that actual code optimization is an extremely rare skillset requiring strong knowledge of assembly that very few people possess anymore. It utilizes tools such as SIMD and, importantly, organizing the data and program architecture in a way that can take full advantage of each CPU clock cycle. The notion that this takes place "prematurely", as if someone is custom writing hand rolled assembly instead of doing other work, essentially never happens.

No, what OOP retards are talking about when they say "Premature optimization is bad", is actually, "pay absolutely no attention to performance at any stage of the project". They will then claim afterwards, "see, the real bottleneck is here, and optimizing code in any other section of the code base would have been premature".

What the retards like the guy I'm replying to fail to understand, however, is that if every part of your shit program runs terribly, then most of it won't even stand out from the rest as a bottleneck. They end up optimizing (more like un-shittifying) the extremely terrible parts of the code base, but the bar is so low anyway that it's still a laggy piece of shit anyway.

And because they paid zero attention to performance the entire project, now all of a sudden the code base is way too big and far too complicated to actually optimize.

No one writing performance code in data oriented design "prematurely optimizes". That's an idiotic notion. In reality, good programmers structure their entire programs in intelligent ways from the very start. It's not about optimizing, it's about NOT doing the opposite of optimizing.

honestly i believe if arrays werent a syntax sugar over a pointer but their own object/abstraction they would start at one, since in mathematics first element of something is denoted using a "1" not "0"
but it does make math a little bit wonky, for example taking a mod of something would require adding a one and such

....you realize you can already do this, right? Just call it a FagArray, store the length of the array as the first element and start at 1 while iterating.

Statements like this are exactly why students need to be taught with C. You're so lost in the esoteric bullshit side of programming that you have no idea how to do anything on the low level.
 
man having a non-us layout sucks for emacs
especially the thinkpad keyboard with the small fn in the bottom left and big ctrl next to it that i have to swap the function of in the bios because its mad annoying ottherwise

and the non us layout sucks because i dont have a right alt
M-x? no nigga you get ź
M-:? no nigga you get a dead key (equivalent to a tilde on windows)
M-v? „

neovim lowkey better because of that
M-x set-input-method polish-slash nigger
 
M-x set-input-method polish-slash nigger
yeah faggot as i said im a newfag so i dont know ts
and that still doesnt fix the problem of it not triggering M-x when i press M-x when i am switched to us layout but still having polish layout in the background as it still inserts x instead of triggering M-x
 
Yeah generally you want to plan out complicated projects ahead of time instead of vibe coding then realizing you have to rewrite 90% of the code because the project really needs to support websockets to work properly
 
"Premature optimization" is one of those idiotic terms strewn about by OOP cult members.

Nigger, the aphorism comes from Donald Fucking Knuth so watch your mouth.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Maybe it's only parroted by braindead OOPjeets in your world but the sentiment predates the paradigm and pertained to Structured Programming Using GOTO.
 
okay ive consulted with the clanker
the only fix to my problem is to set the us layout to be the default which i vill NOT do
vimchads win yet again
 
Nigger, the aphorism comes from Donald Fucking Knuth so watch your mouth.
It also was specifically in the context of microoptimizations such as doing bit twiddling and such shit, along with optimizing stuff like setup that runs literally once and already takes a few ms at most. Macrooptimizations like choosing the right datastructures or algos aren't premature in the vast majority of cases.

Just knowing what your hot loop is is a HUGE difference.
Maybe it's only parroted by braindead OOPjeets in your world but the sentiment predates the paradigm and pertained to Structured Programming Using GOTO.
Yep, it's in the same category as gotos (as used at the time) being awful and error prone. Goto's aren't harmful in of themselves, but rather jumping into random functions and such is.

fat camp intern just ignores any and all nuance, then calls his strawmanned version of things the truth and shits on it based on him being too dumb to figure out how dumb he is.
 
Nigger, the aphorism comes from Donald Fucking Knuth so watch your mouth.



Maybe it's only parroted by braindead OOPjeets in your world but the sentiment predates the paradigm and pertained to Structured Programming Using GOTO.
Nigger, the 'premature optimization' being strewn about in 99.9999% of cases around the world have absolutely nothing to do with Knuth's definition. It's not "my" world- it's "the" world, and is exactly why fags keep repeating such nonsense.

It also was specifically in the context of microoptimizations such as doing bit twiddling and such shit, along with optimizing stuff like setup that runs literally once and already takes a few ms at most. Macrooptimizations like choosing the right datastructures or algos aren't premature in the vast majority of cases.

Just knowing what your hot loop is is a HUGE difference.

Yep, it's in the same category as gotos (as used at the time) being awful and error prone. Goto's aren't harmful in of themselves, but rather jumping into random functions and such is.

fat camp intern just ignores any and all nuance, then calls his strawmanned version of things the truth and shits on it based on him being too dumb to figure out how dumb he is.
Bitch wtf are you talking about? you literally just agreed here with exactly what I was saying, then finish it with "and thats why fat camp intern is wrong". Lmao. Filthy jeet retards.
 
It also was specifically in the context of microoptimizations such as doing bit twiddling and such shit, along with optimizing stuff like setup that runs literally once and already takes a few ms at most. Macrooptimizations like choosing the right datastructures or algos aren't premature in the vast majority of cases.
My goodness, no. I cited the context of the paper: go to statements. This is Knuth firing back at Dijkstra's "Go To Considered Harmful", and is Knuth explaining that, no, GOTO commands are just fine, and shoehorning other control flow methods into the space where GOTO fits naturally is bad practice.

Some reading materials, because apparently people in this thread are illiterate.

https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare - Structured Programming by Dahl, Dijkstra, Hoare
https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf - go to Considered Harmful by Dijkstra
https://dl.acm.org/doi/epdf/10.1145/356635.356640 - Structured Programming with go to Statements by Knuth
 
...
guys i think arrays SHOULD start at 1
Why even bother with array indices? Any decent language worth using has support for foreach.

C:
#include <stdio.h>
#define foreach(e,a)for(__typeof__(*a)*e=a,*a##_last=(a+(sizeof(a)/sizeof(*a))-1);e<=a##_last;++e)
int main(void) {
    int xs[]={1,2,3,4,5};
    foreach(x,xs)*x=*x%2?*x*3+1:*x/2;
    foreach(x,xs)printf("%d%s",*x,x!=xs_last?", ":"\n");
}

This might look hideous, but this is next level memory management which saves multiple bytes of disk space by removing extranous whitespace and using minimal variable names. But I guess this sort of thing would probably go over the heads of a bunch of cave-dwelling webdevs who only know JavaScript... :story:
 
My goodness, no. I cited the context of the paper: go to statements. This is Knuth firing back at Dijkstra's "Go To Considered Harmful", and is Knuth explaining that, no, GOTO commands are just fine, and shoehorning other control flow methods into the space where GOTO fits naturally is bad practice.

Some reading materials, because apparently people in this thread are illiterate.

https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare - Structured Programming by Dahl, Dijkstra, Hoare
https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf - go to Considered Harmful by Dijkstra
https://dl.acm.org/doi/epdf/10.1145/356635.356640 - Structured Programming with go to Statements by Knuth
It's reassuring to know that programmers have been disagreeing since the dawn of time.

Goto is the tits. It's perfectly fine. In fact, it's literally just a jmp instruction. Languages without goto's are so clumsy with their control flow.
 
Back
Top Bottom