Programming thread

[Safir]

Keep in mind that most Redditors are mental midgets.

This. For a laugh, go to a reading subpeddit. They say things like "a challenging novel" and it's just a long book that doesn't have hit points in it.

 

[Sneed's Feed n Seed]

Programming per-se is never exhausting to me.
Dealing with gassed up mids who are "business" or "PM" or "design" or "product" gets fucking old.
QA is always chill. Go figure.

 

[ADHD Mate]

Half the comments are people describing the mental fatigue of programming jobs leaving them unable to do anything once they're home. I had a pretty basic office gig sans the bullying, but even comparing that to my manual labor job now, I got the energy to walk, read and shop within minutes of coming home whereas these soft value office roles just fry your brain.

For me, at least, is just that I need some physical activity. It's not optional. If I don't do some walking before working I am gonna be lethargic.
I think for most it's not that it's really that mentally demanding, but there is just not enough physical stimulation to wake people up.
In physical work, you are just stimulated by work itself.

 

[ChompChomp]

This.

Go back to reddit, you nonce.

 

[Meth Reindeer]

Half the comments are people describing the mental fatigue of programming jobs leaving them unable to do anything once they're home. I had a pretty basic office gig sans the bullying, but even comparing that to my manual labor job now, I got the energy to walk, read and shop within minutes of coming home whereas these soft value office roles just fry your brain.

The only thing that fatigues me is the retarded decision makers who don't get their hands dirty and just expect the details to take care of themselves. That and having my technical knowledge ignored, and being put on shitty projects (that's par for the course in most jobs I imagine.)

I once read that what actually tires out humans is making decisions.

I think that's partially true. But as mnt_ms said:

Once you get used to that activity, you can do most of it with your brain switched off.

And let's be frank, it's doubtful they're doing anything that requires huge amounts of thought.

Sure, I get exhausted after hours of hacking, but I doubt they're doing anything novel.

I feel like if you're hacking away for hours a day every day then you're likely being overworked. Unless you're actively running a one-man company. That or you might be working inefficiently. Automating the drudgery is what computers are for.

Let's remember these are Redditors so they're probably spending half their time complaining on Reddit rather than doing something even slightly productive.

 

[Orcinus Orca]

Give me discipline for learning php

 

[Safir]

Go back to reddit, you nonce.

Get raped, solzhenitsyn.

 

[CrunkLord420]

This.

You have been reported for using "This."

I agree with the report. This is a clear redditism and I am respectfully asking you to cease and desist.

 

[The Noise]

I've been convinced for a while that Uncle Bob never really liked programming. He just likes the prestige around being a "thought leader" in it.

All you need to know about Robert Martin is that (a) he has no successful software projects that he's worked on and can point to as accomplishments, which puts him significantly lower than Ed Yourdon on my "software methodology scam guru" tier list, and (b) he gave himself the disarmingly folksy nickname of "Uncle Bob", which is certifiable used car salesman behavior.

Years and years ago when I first started my degree I had to read this guy's Clean Code book for a freshman class. I specifically remember the chapter on functions and the best number of arguments. He argued (heh) that ideal functions have no arguments and that they should never, ever, have more than three arguments:


It's a sensible claim if you're making an argument for readability but I cannot stand the smug "and then shouldn't be used anyway," as if he can boldly claim there are never any situations where a function should have that many arguments. He goes on to talk about how it impacts the ease of writing tests but, like...ever written anything involving 3D vectors, Martin? Or quaternions? Angles? There are tons of situations where this philosophy doesn't apply.

The whole book is like this. It's a lot of advice that is either taken from elsewhere or is just Martin's personal preferences laundered through a book that's "just trying to make you write better code bro."

If you want a primer on coding style I honestly prefer the Linux kernel coding style guide. It's specifically for C but it contains some really good general advice and is honest about being opinionated. It doesn't contain tons of filler and smug holier-than-thou language to try and stretch itself to 460 pages and is actually funny at points.

 

[Aidan]

Give me discipline for learning php

You're welcome.

 

[canalCrab]

It's a sensible claim if you're making an argument for readability

And if its exclusively in an OOP context.

Yeah, write a c program where no function takes in any arguments, lets see how far you can go without making it impossible to work with due to all the globals. Oh wait, globals are also arguments, altough not explicit ones.

 

[Unimaginative Username]

This talk of not allowing people to pass "too many" parameters has reminded me of something: People like to make their own toy languages as a sort of "babby's first compiler" project, but back in the '90s there was a trend of them taking their otherwise useless languages, tweaking them a bit, and releasing them as tools for writing text adventures (what are now, rather pretentiously, called "interactive fiction"). A particularly freakish product of this trend was Archetype, released in 1995, and with the curious property that you could only pass a single value as a "message" to an object, which forced every method of said object that expected any parameters to become a state machine, as calling a method with N parameters was achieved by passing in the method name as a message, and then all the parameters as the next N messages. So instead of something like

anObject.aMethod(x, y, z);

you would be forced to write

'aMethod' -> anObject
x -> anObject
y -> anObject
z -> anObject

Needless to say, this concept in language design failed to catch on, but maybe Retard Martin can turn it into an industry standard.

edit: If you're doubting me, take a look at this excellent section straight out of the manual:

          Messages Pertaining to Parsing

          'ABBR'
               Sets the abbreviation level of the parsing.  This puts the
               system object into a state where it prepares to receive one
               numeric message; then it returns to idle.  Set the
               abbreviation as follows:
               'ABBR' -> system
               4      -> system
               This would have the effect of turning "calculator" into
               "calc", both when the vocabulary is built and when player
               commands are being parsed.

 

[Private Tag Reporter]

It's a sensible claim if you're making an argument for readability but I cannot stand the smug "and then shouldn't be used anyway," as if he can boldly claim there are never any situations where a function should have that many arguments. He goes on to talk about how it impacts the ease of writing tests but, like...ever written anything involving 3D vectors, Martin? Or quaternions? Angles? There are tons of situations where this philosophy doesn't apply.

Not trying to be smug but why wouldn't you use a context object at that point?

 

[The Noise]

Not trying to be smug but why wouldn't you use a context object at that point?

The book has a huge bias towards OOP but I can't recall a single time it actually talks about objects except to suggest methodology that is fundamentally obvious to even highschool programmers (i.e naming your classes after your problem domain.)

The book only makes sense if you assume the author thinks Java is the only language to ever exist. He has an entire chapter on how you should throw exceptions instead of returning error codes and makes literally zero mention of what you should do if you're programming in a language that does not throw exceptions like Java does. He even shits on returning error codes when that's one of the only ways to indicate failure in C. Completely worthless.

 

[UERISIMILITUDO]

The best advice is to learn many different languages. I've never used Forth for anything practical, but playing with it and reading books about it has still greatly improved how I design some systems. I'm learning Erlang currently, and the way it uses tuples is very similar to how REFAL uses doubly-linked lists in some respects, yet they're many decades apart. There are things Ada does better than Common Lisp and APL, and things each does better in turn. Importantly, this will free one from the notion of thinking any single language to be universally better than the rest, also known as becoming a weenie. Where most people make the mistake is in learning the same language repeatedly. They'll claim to know five languages—say C, C++, Python, Java, and JavaScript—without understanding how these are really just the same language five times with ultimately minor differences.

He argued (heh) that ideal functions have no arguments and that they should never, ever, have more than three arguments:

I suppose the object to be an implicit argument there, but that's still such worthless advice.

If you want a primer on coding style I honestly prefer the Linux kernel coding style guide.

It's pretty funny seeing the hostility to GNU here, but who's been castrated since then, Linus or RMS?

I'll mock it a bit without trying to be comprehensive:

There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

It sounds like they want some mustard with that weenie.

Data structures that have visibility outside the single-threaded environment they are created and destroyed in should always have reference counts. In the kernel, garbage collection doesn’t exist (and outside the kernel garbage collection is slow and inefficient), which means that you absolutely have to reference count all your uses.

I like when the program actually fucking works, and regularly read about people investigating some basic bitch issue in the Linux kernel that could've been prohibited automatically, but they'd rather waste a man's time than work on making the automation better. They do this because to understand what they should be doing would reveal all they've done so far to be wrong, and they wouldn't be able to handle that revelation.

For symbol names and documentation, avoid introducing new usage of ‘master / slave’ (or ‘slave’ independent of ‘master’) and ‘blacklist / whitelist’.

Recommended replacements for ‘master / slave’ are:

‘{primary,main} / {secondary,replica,subordinate}’ ‘{initiator,requester} / {target,responder}’ ‘{controller,host} / {device,worker,proxy}’ ‘leader / follower’ ‘director / performer’
Recommended replacements for ‘blacklist/whitelist’ are:

‘denylist / allowlist’ ‘blocklist / passlist’

I truly and honestly want to kill the little commie faggots trying to destroy my language like this. One nice way to avoid indentation is making it implicit, such as by using names which have the same lengths. It can't be done always, but it's good to try. That eventually got too easy for me, and I'm one of those guys who thinks monospaced fonts shouldn't be necessary for programming in some nicer future. Well, I got it in my head that using the same lengths and same count of syllables is even better. The words "blacklist" and "whitelist" are perfect already, but evil little bolsheviks trying to destroy our ability to communicate have to start somewhere, and everyone knows "white" can only mean whitey and "Black" can only mean the proud African race.

I can't defend "master" and "slave" in the same way, since they don't line up this nicely, but destroying common analogies is another goal of these fucking commies, can't have anyone thinking that slavery existed anywhere but the USA. I do like renaming things when they displease me in some way—I'd rather call a debugger a revealer—so "driver" and "cattle" feels adequately on the nose here.

5) namespace collisions when defining local variables in macros resembling functions:

#define FOO(x)                          \
({                                      \
        typeof(x) ret;                  \
        ret = calc_ret(x);              \
        (ret);                          \
})

ret is a common name for a local variable - __foo_ret is less likely to collide with an existing variable.

This is the funniest part of the whole damn document to me. Common Lisp has a function named GENSYM which exists primarily because macros—real macros—need to be able to generate variables that can't exist elsewhere; GENSYM generates a symbol guaranteed to be new for exactly this purpose. Trying to explain why they need this in a program tens of millions of lines long would be like trying to explain to an Indian why he should shit in a toilet.

 

[mnt_ms]

This is the funniest part of the whole damn document to me. Common Lisp has a function named GENSYM which exists primarily because macros—real macros—need to be able to generate variables that can't exist elsewhere; GENSYM generates a symbol guaranteed to be new for exactly this purpose. Trying to explain why they need this in a program tens of millions of lines long would be like trying to explain to an Indian why he should shit in a toilet.

Is it a problem though? I don't think so - name collisions are not so hard to avoid. I'd say this is the solution for a non-existent problem.

They'll claim to know five languages—say C, C++, Python, Java, and JavaScript—without understanding how these are really just the same language five times with ultimately minor differences.

Those languages are similar only on the surface. Even the C and C++ are vastly different - it's not only the syntax, it's also a bit of the culture.
Erlang is an interesting and beautiful language(dynamic typing is horrible though), but learning it won't be that useful in the other languages, really. It's very specific and has it's own way of doing things

 

[UERISIMILITUDO]

I forgot to mention how they still write do ... while (0) for macros. That's how Lisp started, but eventually it got PROGN to handle exactly the case where one wants to shove multiple expressions in a slot with only one space. They'll never write such a macro for themselves, and I leave the reason to your imaginations.

Is it a problem though? I don't think so - name collisions are not so hard to avoid. I'd say this is the solution for a non-existent problem.

It's one thing that could be done perfectly but, because they insist on using subpar tools, isn't. Also, sure, it's necessary in Lisp because of the complex macros that get used everywhere. In the C language, it's so hard to do just about anything of interest that they don't bother instead. Just look at how Bjarne threw Cfront together to get his C++ language started, because it couldn't support the extensions he wanted in any better way. An awful lot of time and money gets wasted making new programming languages that differ in only a few minor ways. There's a dead Common Lisp programmer, Erik Naggum, who said this:

There is a simple and elegant answer to this question: Just learn Common Lisp well first. New languages are exciting to people who know mostly new languages, so learn an old language before you learn new ones and get out of the maelstrom that will drown you in ever new languages that add nothing at all except some miniscule additional feature from another language that someone needed to make a whole new language to implement because he did not know (Common) Lisp to begin with. A "new" language that differs from the rest of the crop by one or a couple features is proof positive that both what it came from and what it has become are mutations about to die. There are tens if not hundreds of thousands of such "languages" that people have invented over the years, for all sorts of weird purposes where they just could not use whatever language they were already using, could not extend it, and could not fathom how to modify its tools without making a whole new language. They never stopped to think about how horribly wasteful this is, they just went on to create yet another language called Dodo, the Titanic, Edsel, Kyoto-agreement...

I believe I've already quoted this in here once now.

 

[Unimaginative Username]

Is it a problem though? I don't think so - name collisions are not so hard to avoid. I'd say this is the solution for a non-existent problem.

I don't think you understand how Lisp macros work. They are basically functions that are called at compile-time, with their parameters passed in unevaluated, and the value they return replaces the call in the source code. If you need for one of the parameters to appear in multiple places within the replacement code but only be evaluated once, you're going to need to bind it to a local variable, and you need for the name of that variable to be guaranteed to be distinct from any other variable in the program. Likewise, if you're actually generating labels and gotos, you need for the labels to be distinct.

Let's say you want to define a while loop in Common Lisp, with the form (while CONDITION BODY ...). You could do it like this:

(defmacro while (condition &body body)
  (let ((exit (gensym))
        (test (gensym)))
    `(tagbody
       ,test
       (if (not ,condition)
         (go ,exit))
       ,@body
       (go ,test)
       ,exit)))

This binds the local variables exit and test to a pair of generated symbols (guaranteed unique), and uses them as labels in the generated code. (The backquote ` forces the list following it to be treated as a template, where commas , unquote expressions that aren't meant to be literals within the template, and the comma-atsign ,@ unquotes a list whose elements are to be sequentially inserted in the template, where a comma would have inserted the list itself as a single item.)

I'll also note that reserving special names for these labels doesn't work in the general case, since that can cause conflicts when a macro is passed another macro call as an argument.

 

[mnt_ms]

I forgot to mention how they still write do ... while (0) for macros.

Isn't it just for semicolon at the end of macro invocation?
I don't remember the last time I saw do ... while(0) in the wild.
If you are planning to declare some variables in a macro, you should probably use macro-functions.
Don't remember about the earlier standards of the language, though.

In the C language, it's so hard to do just about anything of interest that they don't bother instead.

Well, they are just text substitution thingies. They should be treated as such.
I myself prefer it when the language has as few high-level features as possible - only the important stuff. The less implicit, the better. Sure, it's not really implicit nowadays, because the assembly it generates can be very different from what you've intended, but the alternatives are even more implicit.

I don't think you understand how Lisp macros work.

I am talking about how this feature is not that important in C.

 

[Meth Reindeer]

I can't defend "master" and "slave" in the same way, since they don't line up this nicely, but destroying common analogies is another goal of these fucking commies, can't have anyone thinking that slavery existed anywhere but the USA.

I was reading some of that coding style after it was linked and stopped at the word policing part.

Sorry but I'll use master, slave, whitelist, blacklist and other "problematic" words in my coding vernacular as much as possible. They've got deep meanings outside of their social justice broken brains. Leader/follower doesn't have the same connotations as master/slave. Allowlist and blocklist are cumbersome to say and a good litmus test of if someone is actually racist, as I've never worked with a person, including black people, who thought of racism when we spoke about such things. Hell we still use the term master for so many other things, degrees, ranks, master craftsman etc. that the whole PC language crap is clearly just an attempt to control thought.