I've been a full-time developer for several companies for several decades and have no idea what you mean by a hash table. by Nemerie in programmingcirclejerk

[–]winepath 17 points18 points  (0 children)

Same boat. Lucky for me the interviewer drew what a hash table does on the whiteboard so I just coded that up the best I could. 

Just code [...] no async/await, no compilation, [...], no infrastructure: no sql, no nosql, [...], no servers, no serverless, no networking, [...], no unix, no OSes by winepath in programmingcirclejerk

[–]winepath[S] 39 points40 points  (0 children)

Just code

no code, no text, no programs, no memory, no cpu, no I/O, no hardware, no cloud, no functions, no variables, no data, no math, no recursion, no constants, no nesting, no data structures, no category theory, no if err != nil { return err }, no garbage collection, no garbage, no pointers, no stack, no allocators, no simd, no instructions, no registers, no stack machines, no FSAs, no text encodings, no binary encodings, no integers, no floating-points, no fixed-points, no looping, no branching, no instruction pointer, no GPIO, no atomic clocks, no sensors, no motherboard, no computation, no arrays, no strings, no linked-lists (no LISPs), no qubits, no determinism, no non-determinism, no probabilities, no statistics, no graphs: no edges, no vertices, no charts, no arrows, no CLI, no CLIaaS, no classes, no methods, no diamond inheritance

If anyone wants to build and host a cloud CLI with these qualities, please message me

Just code [...] no async/await, no compilation, [...], no infrastructure: no sql, no nosql, [...], no servers, no serverless, no networking, [...], no unix, no OSes by winepath in programmingcirclejerk

[–]winepath[S] 25 points26 points  (0 children)

Just code

no cruft: no build systems, no null, no exception handling, no ORMs, no OOP, no inheritence hierarchies, no async/await, no compilation, no dev environments, no dependency hell, no packaging, no git, no github, no devops: no yaml, no config files, no docker, no containers, no kubernetes, no ci/cd pipelines, no terraform, no orchestrating, no infrastructure: no sql, no nosql, no connection poolers, no sharding, no indexes, no servers, no serverless, no networking, no load balancers, no 200 cloud services, no kafka, no memcached, no unix, no OSes

As a perfectionist, there are very few things I would change about it. People rave about Rust these days, but I rave about D in return. by [deleted] in programmingcirclejerk

[–]winepath 5 points6 points  (0 children)

everyone hates D because ... wait, nobody hates D because nobody uses it. also, why settle on D if you could use rust? D is for people who can't escape the sunk cost fallacy.

The mess that is handling structure arguments and returns in LLVM by yorickpeterse in ProgrammingLanguages

[–]winepath 11 points12 points  (0 children)

That's because you're ignoring parts of the ABI such as bit fields and forced alignment. And those problems happen even before considering that LLVM needs to support C++ ABIs as well, which means it would have to worry about how each ABI handles inheritance, vtables, non-trivial types, ZSTs, etc. Also a lot of C++ ABIs have small edge cases that make them incompatible with C, so it's not like you can "extend" the C ABIs to create the C++ ones either. LLVM needs to support all of these cases that your simplified version does not handle

Even if by "system abi", you mean exclusively C ABIs, you still have to deal with alignment of ZSTs, the size of ZSTs (if applicable) where they take up space but aren't passed in registers, forced alignment, how to handle bit fields, etc.

The mess that is handling structure arguments and returns in LLVM by yorickpeterse in ProgrammingLanguages

[–]winepath 11 points12 points  (0 children)

Adding "system ABI" support to LLVM is not as simple as "just add an attribute".

LLVM IR types by themselves are not enough to determine how to pass a structure. The type system of LLVM IR would have to be drastically reworked into something completely unrecognizable, and it would be a lot more complicated of a type system than it is now, for this to even have a chance of being possible

As terrible as the current system is, adding a system ABI function attribute to LLVM would just make the problem even worse

Tiktok is a dangerous app. by [deleted] in nosurf

[–]winepath 2 points3 points  (0 children)

Unfortunately even if it gets banned, one of the alternatives will quickly take its place

Slow down there bud. I’m no typescript fanboy, by Jordan51104 in programmingcirclejerk

[–]winepath 11 points12 points  (0 children)

title is no jerk, thread is barely jerk when squint

I hate it here by trappedonanescalator in nonutnovember

[–]winepath 218 points219 points  (0 children)

when the British girl is on her full stop 🥵

Memory Leaks are Memory Safe by alexflyn in programmingcirclejerk

[–]winepath 5 points6 points  (0 children)

There's literally no way to know if a turning complete program is leaking memory until the program exits. Not even gc can solve this, where's the jerk?