Programming thread

as somebody who started out programming in PHP, and later in life moved onto python, it came to me as a pleasant surprise how much I could understand of rust. while I don't plan on ever working on programming in a professional capacity, it still is interesting learning how the stuff I use on my computer operates at a fundamental level. I feel like I gained a lot of insight on my journeys through messing around, with no particular goal in mind, with the three aforementioned languages.

I did try C once, but holy hell is it ugly and fiendishly complicated. even though rust is also designed as an only slightly higher level language than C, I felt like it was a million times easier to understand and comprehend its idiomatic paradigms. pretty impressive, considering how geared my "programming brain" is towards object oriented programming because of python. I hope rust has a fruitful future so dum dums like me can have a chance of programming with the big boys (in open source projects, at least).

Honestly the moment I realized all the shitty meme programming on reddit was how modern tech companies actually operated I realized I could never work in this field unless I was self employed.

not sure if you are talking about the same topic I have in mind, but, to me personally, the most repulsive aspect of professional programming is the fact that most of environments within it are like what this video illustrates:
I don't see myself ever working in a place where people like him are commonplace.
 
as somebody who started out programming in PHP, and later in life moved onto python, it came to me as a pleasant surprise how much I could understand of rust. while I don't plan on ever working on programming in a professional capacity, it still is interesting learning how the stuff I use on my computer operates at a fundamental level. I feel like I gained a lot of insight on my journeys through messing around, with no particular goal in mind, with the three aforementioned languages.

I did try C once, but holy hell is it ugly and fiendishly complicated. even though rust is also designed as an only slightly higher level language than C, I felt like it was a million times easier to understand and comprehend its idiomatic paradigms. pretty impressive, considering how geared my "programming brain" is towards object oriented programming because of python. I hope rust has a fruitful future so dum dums like me can have a chance of programming with the big boys (in open source projects, at least).



not sure if you are talking about the same topic I have in mind, but, to me personally, the most repulsive aspect of professional programming is the fact that most of environments within it are like what this video illustrates:
I don't see myself ever working in a place where people like him are commonplace.

That's a part of it but it doesn't even begin to describe the horrible ball of slightly different javascript implimentations you'll be installing packages onto.
Gotta love the soulless hellscape theme they've got going on in the vid tho. A normal office would have been less condescending. The "party" was even worse.

In regards to the rest of your post, C is pretty archaic (but good).
I think the best way to describe it is that structs are your objects and all their functions are in the global scope (So prefixes are a nasty neccesity).
 
In regards to the rest of your post, C is pretty archaic (but good).
I think the best way to describe it is that structs are your objects and all their functions are in the global scope (So prefixes are a nasty neccesity).
I noticed that C has structs like rust does, yeah, but it does not seem to have (at least as far as I was able to discern) an equivalent of rust's impl, which allows for grouping functionality of individual structs, like how structs group data.
 
  • Agree
Reactions: Coolio55
*Looks at thread, and decides it is way too sensible, meaning boring*; *Puts on his vest robe and a bush wizard hat;* *Ahem*
Python is a tool of Satan. If God really wanted the white-space to be used for structuring the code blocks, he wouldn't have created the curly braces, now would've he? Every line of Python written is essentially a prayer to Satan.
 
Last edited:
If you jump from Unity to Unreal how much of gap is there on trying to find all the tools again in order to do shit?

Also does Unreal take imported assets better than Unity, I import assets from Autodesk programs from FBX format and I always have to relink shit from unity.

I have everything modeled rigged and textured for a 3d third person game and I was hoping to just try and get the character moving in the environment over the weekend.
 
I noticed that C has structs like rust does, yeah, but it does not seem to have (at least as far as I was able to discern) an equivalent of rust's impl, which allows for grouping functionality of individual structs, like how structs group data.
Rust's structures and traits come from Ocaml and Haskell. Rust's enums are stolen directly from Ocaml and Haskell's sum types. It's traits are stolen directly from Haskell typeclasses. Both are distinguished from C by being completely typesafe.

You can compare them by reflecting on a general problem we're all trying to solve in programming: I want to write a function that takes a value, and that value can conform to one of several different and incompatible layouts. Say, in one case, the value is an integer. In another case, it is a string paired with a floating point value. In a third case, it's an array. How do I model this?

The object oriented approach is to use runtime polymorphism: have it so that I talk to the three different kinds of value through a common interface.

The C approach is to mash the three layouts together into a union and have some extra means of determining which of the three layouts you're working with, possibly using a type tag field. If you fuck this up, expect your program to break horribly. This is where C fails badly in terms of type-safety.

The Rust approach is just the C approach, but with the insistence that there is an implicit type tag, so nothing can break.

The Rust approach is particularly nice from a theoretical perspective, and very nice practically when combined with pattern matching, which allows you to bind variables to components of the structure you want at the same time as you discriminate between the layouts, to as many levels as you like.

The object oriented approach has the advantage that you don't have to decide up-front how many different layouts you're working with. You just need that common interface. The disadvantage is that you don't know up-front how many different layouts you have to deal with.
 
Last edited:
Rust's structures and traits come from Ocaml and Haskell. Rust's enums are stolen directly from Ocaml and Haskell's sum types. It's traits are stolen directly from Haskell typeclasses. Both are distinguished from C by being completely typesafe.

You can compare them by reflecting on a general problem we're all trying to solve in programming: I want to write a function that takes a value, and that value can conform to one of several different and incompatible layouts. Say, in one case, the value is an integer. In another case, it is a string paired with a floating point value. In a third case, it's an array. How do I model this?

The object oriented approach is to use runtime polymorphism: have it so that I talk to the three different kinds of value through a common interface.

The C approach is to mash the three layouts together into a union and have some extra means of determining which of the three layouts you're working with, possibly using a type tag field. If you fuck this up, expect your program to break horribly. This is where C fails badly in terms of type-safety.

The Rust approach is just the C approach, but with the insistence that there is an implicit type tag, so nothing can break.

The Rust approach is particularly nice from a theoretical perspective, and very nice practically when combined with pattern matching, which allows you to bind variables to components of the structure you want at the same time as you discriminate between the layouts, to as many levels as you like.

The object oriented approach has the advantage that you don't have to decide up-front how many different layouts you're working with. You just need that common interface. The disadvantage is that you don't know up-front how many different layouts you have to deal with.
sounds to me like rust got the best of every low level language out there then.

just as a general comment on rust's "niceness", in C I was not even able to print something out without it breaking down to shit. in rust, you get a macro for printing stuff, and the official introduction guide even goes into a lot of detail about parsing strings and the many inherent caveats associated with it. just in general, rust's "the book" is incredibly easy to understand even for somebody like me who never did low-level programming, until rust. even memory management in it is easy to understand, to me. not to mention the whole cargo/crate system.
 
Last edited:
sounds to me like rust got the best of every low level language out there then.

just as a general comment on rust's "niceness", in C I was not even able to print something out without it breaking down to shit. in rust, you get a macro for printing stuff, and the official introduction guide even goes into a lot of detail about parsing strings and the many inherent caveats associated with it. just in general, rust's "the book" is incredibly easy to understand even for somebody like me who never did low-level programming, until rust. even memory management in it is easy to understand, to me. not to mention the whole cargo/crate system.

Yeah, I would say that's broadly true, though it still has some incompatibility/difficultly with C, especially on the "stable" version, and that can cause issues with use in production.

 
If God really wanted the white-space to be used for structuring the code blocks, he wouldn't have created the curly braces, now would've he?
If God really wanted the curly braces to be used for structuring code blocks, he would have created debuggers and diff tools that take account of braces (and semicolons). Curly braces aren't needed if people structure their code vertically and make indents anyway.
 
If God really wanted the curly braces to be used for structuring code blocks, he would have created debuggers and diff tools that take account of braces (and semicolons). Curly braces aren't needed if people structure their code vertically and make indents anyway.

What the fuck did you just fucking say about me, you little bitch? I'll have you know I graduated top of my class in the CosaNostra Pizza University, and I've been involved in numerous mad dashes with my Deliverator through the TMAWH territory, and I have over 300 confirmed on-time pizza deliveries. I am trained in software related intel, and I'm the top microcode wizard in the entire Central Intelligence Corporation. You are nothing to me but just another target. I will wipe you the fuck out with precision the likes of which has never been seen before on this Earth, mark my fucking words. You think you can get away with saying that shit to me over the Metaverse? Think again, fucker. As we speak I am contacting my secret network of subverted Rat Things across the globe and your access terminal is being traced right now so you better prepare for the storm, maggot. The storm that wipes out the pathetic little thing you call your life. You're fucking dead, kid. I can be anywhere, anytime, and I can reprogram your brain stem in over seven hundred interesting ways, and that's just me whispering couple of syllables to you over the phone. Not only am I extensively trained in music, video and microcode intel, but I have access to the full vocabulary of ancient Sumerian, so don't be surprised, when after hearing something, that sounds like total gibberish to you next time you pick up a call, your lungs start involuntary panting to the tune of Rick Astley's "Never Gonna Give You Up", you little shit. If only you could have known what unholy retribution your little "clever" comment was about to bring down upon you, maybe you would have held your fucking tongue. But you couldn't, you didn't, and now you're paying the price, you goddamn idiot. I will shit fury all over you and you will drown in it. You're fucking dead, kiddo.
 
Last edited:
sounds to me like rust got the best of every low level language out there then.

just as a general comment on rust's "niceness", in C I was not even able to print something out without it breaking down to shit. in rust, you get a macro for printing stuff, and the official introduction guide even goes into a lot of detail about parsing strings and the many inherent caveats associated with it. just in general, rust's "the book" is incredibly easy to understand even for somebody like me who never did low-level programming, until rust. even memory management in it is easy to understand, to me. not to mention the whole cargo/crate system.
My school's CS curriculum is taught in C for the first year (yes, data structures is taught in C) so I'm probably biased, but I really don't see how Rust makes more "sense" than C. I actually consider C to be the most straightforward low-level programming language, and probably second-most of any mainstream language (Python being first).

C is the only language I've used that doesn't have seem to have any arbitrary bullshit. Sure, it doesn't have built-in dynamic arrays, but making one (and memory management as a whole) is extremely intuitive: just call malloc() with the number of bytes you want to reserve, and free() to unreserve it. Need to resize? Just keep track of its size and either call realloc() or just implement it yourself with the former two functions.

If you're having trouble printing stuff in C, you're probably not using the right format specifiers. That's very easy to fix.

Not saying C has the conveniences of other languages, but what it does have is very straightforward. If your code isn't working, it's because you made some trivial mistake, not some language quirk you don't know about.

Ironically, my favorite language is C++ (serious), but I imagine the problem most have with it is they try learning both C and the ++ at the same time and thus have trouble with understanding things like the difference between malloc()/free() and new/delete, and when & means a memory address or reference. If you're already proficient at C and dealing with multiple levels of pointers, learning C++ should be pretty easy.
 
This discussion has gone way too technical - this is not stackoverflow, faggots; Here are my tips for succeeding in IT, tried and tested:
1) Don't be afraid to lie on your CV, fake it until you make it, worst thing, that can happen is that you do not get the job - tried and tested by yours truly, worked for me when I moved from support monkey to dev, I've now worked on several multi-million projects successfully.
2)DO NOT call yourself a programmer if you have above the average ability AND some experience - you're a "developer". "Programmer" is essentially someone. who places text boxes on the screen as directed by his betters, "Developers" and "Architects" are deciding if this textbox is needed in the first place and command the premium salary over the lowly "programmer".
 
Last edited:
My school's CS curriculum is taught in C for the first year (yes, data structures is taught in C) so I'm probably biased, but I really don't see how Rust makes more "sense" than C. I actually consider C to be the most straightforward low-level programming language, and probably second-most of any mainstream language (Python being first).

C is the only language I've used that doesn't have seem to have any arbitrary bullshit. Sure, it doesn't have built-in dynamic arrays, but making one (and memory management as a whole) is extremely intuitive: just call malloc() with the number of bytes you want to reserve, and free() to unreserve it. Need to resize? Just keep track of its size and either call realloc() or just implement it yourself with the former two functions.

If you're having trouble printing stuff in C, you're probably not using the right format specifiers. That's very easy to fix.

Not saying C has the conveniences of other languages, but what it does have is very straightforward. If your code isn't working, it's because you made some trivial mistake, not some language quirk you don't know about.

Ironically, my favorite language is C++ (serious), but I imagine the problem most have with it is they try learning both C and the ++ at the same time and thus have trouble with understanding things like the difference between malloc()/free() and new/delete, and when & means a memory address or reference. If you're already proficient at C and dealing with multiple levels of pointers, learning C++ should be pretty easy.
C is basically designed to introduce heisenbugs. It's not that memory management is hard in a single example, it's that you need a consistent philosophy everywhere in your program constantly (not to mention differing memory management philosophy when interfacing with libraries) and that the language forces you to handle that consistency manually.

And it's not just arrays, but any complicated data structure. Hash tables, trees, linked lists, etc.

Like what I said in this post, if I was a teacher, I'd assign a project that requires the students to work on a project involving a complicated data structure, and I'd link the Boehm C garbage collector with their programs and pump data into it. If it detects a memory leak, they immediately fail.

You'd be surprised how often even somewhat simple programs can get fucked up because you forgot how some function is supposed to handle allocation (ie the caller or the user?).

There's a similar issue with pthreads (or similar threading models) when you have to deal with mutexes.
 
  • Agree
Reactions: Yotsubaaa
C is basically designed to introduce heisenbugs. It's not that memory management is hard in a single example, it's that you need a consistent philosophy everywhere in your program constantly (not to mention differing memory management philosophy when interfacing with libraries) and that the language forces you to handle that consistency manually.

And it's not just arrays, but any complicated data structure. Hash tables, trees, linked lists, etc.

Like what I said in this post, if I was a teacher, I'd assign a project that requires the students to work on a project involving a complicated data structure, and I'd link the Boehm C garbage collector with their programs and pump data into it. If it detects a memory leak, they immediately fail.

You'd be surprised how often even somewhat simple programs can get fucked up because you forgot how some function is supposed to handle allocation (ie the caller or the user?).

There's a similar issue with pthreads (or similar threading models) when you have to deal with mutexes.
As I said in that post, my data structures class was taught in C; I had to do everything you mentioned in it. There's even a final project worth 25% of the final grade that's almost exactly like your hypothetical one: writing a program handling nearly a gigabyte of data that would already be complicated on its own, having to use a self-balancing AVL tree to manage the data, and an automatic 50% deduction if there were any memory leaks in Valgrind. It's considered a weed-out and something like 50% change majors after it.

Thing is, by the end of the semester nearly all of my mistakes weren't memory-related. Less than an hour before submitting my final project I had to find what was causing a massive memory leak....the problem was mistyping a variable making all nodes get inserted as left children (I have no idea how the program even managed to work). Even memory management becomes natural with practice.
 
My school's CS curriculum is taught in C for the first year (yes, data structures is taught in C) so I'm probably biased, but I really don't see how Rust makes more "sense" than C. I actually consider C to be the most straightforward low-level programming language, and probably second-most of any mainstream language (Python being first).

well, there's your first misunderstanding: I never went to school for programming, and you did. I don't mean that in any negative way. it just means that I didn't spend several hours a day getting acquainted with C the way you did. on top of that you had every incentive of getting acquainted with it in order to pass university, since that is kind of the whole point of going to one. I bother with programming in any capacity whatsoever purely out of my own volition and the desire to observe the tech world.

C is the only language I've used that doesn't have seem to have any arbitrary bullshit. [...]

Not saying C has the conveniences of other languages, but what it does have is very straightforward. If your code isn't working, it's because you made some trivial mistake, not some language quirk you don't know about.

my confusion here is twofold:
1) if a language not being C was far easier for me to understand, without it being all that much more abstracted than C, why should I make everything harder for myself? that's essentially what you are objecting to here, as far as I can understand.
2) in this video it is explained how 70% of security bugs are memory safety issues, according to a study by microsoft. errors which are fixed by rust at compile time. from a purely pragmatic standpoint, it makes more sense to have some "arbitrary bullshit" than not. it doesn't take a programmer (as I am definitely not one) to see that something is not entirely true about your perception of languages designed as alternatives to C.
 
As I said in that post, my data structures class was taught in C; I had to do everything you mentioned in it. There's even a final project worth 25% of the final grade that's almost exactly like your hypothetical one: writing a program handling nearly a gigabyte of data that would already be complicated on its own, having to use a self-balancing AVL tree to manage the data, and an automatic 50% deduction if there were any memory leaks in Valgrind. It's considered a weed-out and something like 50% change majors after it.

Thing is, by the end of the semester nearly all of my mistakes weren't memory-related. Less than an hour before submitting my final project I had to find what was causing a massive memory leak....the problem was mistyping a variable making all nodes get inserted as left children (I have no idea how the program even managed to work). Even memory management becomes natural with practice.
There's no reason to expose yourself to even the potential of bugs like that though, no matter how low you get the error rate. And in everyday software development, you're constantly dealing with common things that make the error rate jump back up again. Things like using libraries with a different approach to memory management, or accepting patches from coworkers/contributors. When you're reviewing patches, even if you're the original author of the software (instead of the contributor), you can fuck up because you're suddenly thrust into a section of the code you haven't edited in awhile. You lose the linear context you originally had when you just sat down and wrote out the software.

The risk of memory management is an entirely unnecessary one to bear nowadays. I'd say it's downright dangerous.
 
There's no reason to expose yourself to even the potential of bugs like that though, no matter how low you get the error rate. And in everyday software development, you're constantly dealing with common things that make the error rate jump back up again. Things like using libraries with a different approach to memory management, or accepting patches from coworkers/contributors. When you're reviewing patches, even if you're the original author of the software (instead of the contributor), you can fuck up because you're suddenly thrust into a section of the code you haven't edited in awhile. You lose the linear context you originally had when you just sat down and wrote out the software.

The risk of memory management is an entirely unnecessary one to bear nowadays. I'd say it's downright dangerous.
I agree with you about plain C, but what about C++? Besides, other than Rust, I can't think of any language remotely as fast as C/C++. Though you likely have several times my programming experience so I'm not going to pretend I know more than you.
 
Anyone know why pyTorch doesn't want to enable CUDA for me? I'm not a Python guy, I'm not a CUDA guy, I just wanted to play around with that voice-thingie. (on Windows btw)
 
Anyone know why pyTorch doesn't want to enable CUDA for me? I'm not a Python guy, I'm not a CUDA guy, I just wanted to play around with that voice-thingie. (on Windows btw)
>pyTorch
There's your problem!
(Only half-shitposting: most of my more frustrating programming escapades recently have been trying to get Python/Java to play nice with Machine Learning stuff.)

I dunno, what specific errors are you getting? (Or is it just not recognising that you've got CUDA configured?)
 
Back