Programming thread

[306h4Ge5eJUJ]

[...]

Either way is fine, really. Just pick what's consistent with the rest so that you don't have some functions which take a from_end argument and some which don't.

 

[y a t s]

So Ocaml is a functional language. All its variables are immutable. But unlike, say, Haskell, it isn't purely functional.

I do think functional programming will improve your code, it makes things more debuggable and readable, and harder to fuck up.

But some algorithms simply are easier to reason about with side effects. Not all, and I do encourage people to try and reimagine their algorithms in a functional way. Functional programming, where it works, does pay dividends.

But it's not universal. Again, I'm not a purist.

This is one of my favorite parts of functional programming. FP is really more of a mindset above anything, since every function composition is a new reference frame.

Managing side effects in a purely functional sense is like constructing a mini world and defining the rules by which an observer can interact with it. It's hard not to draw the obvious parallels with life, the universe, and the human experience.

 

[Belisarius Cawl]

Managing side effects in a purely functional sense is like constructing a mini world and defining the rules by which an observer can interact with it. It's hard not to draw the obvious parallels with life, the universe, and the human experience.

Could you elaborate on the last point? I don't know enough about FP to comment exactly but was reminded of the following book by Rudy Rucker:

https://www.rudyrucker.com/lifebox/

 

[y a t s]

Could you elaborate on the last point? I don't know enough about FP to comment exactly but was reminded of the following book by Rudy Rucker:

https://www.rudyrucker.com/lifebox/

Sure. The big no-no in pure functional programming is the existence of unmanaged side-effects. But who's to say we can't just manage them instead? What if we reframe our perspective a little and start explicitly describing an environment (or "world") in which these effects can occur? This is where it gets really interesting.

In lambda calculus, recall that lambda functions are curried unary functions. In linear algebra, we pay a lot of attention to linear independence and, consequently, the dimension of vector spaces. What these boil down to is that when describing a multi-variate system, each dimension/independent variable is basically another layer of function compositions. Note the term "layer" is highly relative here.

To draw some heavily simplified real-world parallels, let's consider the motion of water or air molecules as a group. Together, we can model the overall periodic motion of them—seen as a pretty ocean wave or heard as a sound—as a sinusoidal function with some asymmetry. Though, we can model the motion of each molecule, each individual particle, etc. at some arbitrary depth as well. Whether these systems affect the values of other neighboring systems is a physical manifestation of dependence. These are all function compositions that you can define and combine at essentially infinite depths, depending on your level of autism and the task at hand.

So now let's take this idea of arbitrarily deep reference frames and apply it to programming: we can define an action we wish to take in our "world" and we can describe how such action affects the world state. This is typically done using monads. If we ensure the value of a monad is bound in a function that computes another monad of the same type, what we have is a chain of causality, where the result of each action is passed as input needed to perform the next action. The monad acts as an abstraction layer for observing and interacting with our created world, much like how our brains can be seen as computers, possible to model functionally, interacting with an inconceivably huge mathematical model (the Universe) using our bodies to observe and interact with it.

I hadn't heard of that book before, but it looks fascinating. If you look, you'll see this concept of function compositions everywhere. Geometry is a good model to reason about it with. Cool, huh?

 

[ADHD Mate]

https://www.rudyrucker.com/lifebox/

What if everything is a computation?

Angry Penrose noises.

 

[Belisarius Cawl]

Angry Penrose noises.

I see your angry Penrose noises and raise you a

Also besides Rudy Rucker and his writings you can look into the thoughts of Stephen Wolfram (who can be seen reviewing The Lifebox very favorably) and even Konrad Zuse (who, AFAIK, built the first truly general computer but you know what they say about history being written by the victors—his first machine was destroyed in a bombing raid and ENIAC got to steal the thunder).

 

[Safir]

So instead of using rsplit(), why not have something like split(from_start=False)? Something like that.

The biggest reason to not have this is privileging one split over the other for no good reason. Unlike the "list" (which isn't a real list in python), the string is immutable and doesn't have a privileged end. At any time you want rsplit instead of the regular split, you also want max_splits. So it's two arguments to cut something off the other end. But it doesn't seem to me like wanting the first x items comes up more often that wanting the last x items. If split was one function and took an optional argument, more people would want a "partial" shorthand for "split from end" than there are people who decide from which end to split at runtime.

 

[Belisarius Cawl]

One criticism that I have in mind is that if you really need to separate these two splitting functions, you should name them appropriately, we are not programming in C in the 80's anymore: split_from_left and split_from_right let you immediately understand what they do instead of having split and rsplit.

I've done verbose variable naming like this before but ultimately realized it can go too far. Would I rather see names like itertools become iterator_tools and so forth until the code can't fit on single lines? Certainly not. One area where Python definitely nails it is statements like import pandas as pd and import numpy as np which don't pollute the global namespace like R does but are still reasonably compact.

 

[ADHD Mate]

Would I rather see names like itertools become iterator_tools

Obviously iteratorTools is the correct answer

Spoiler

However, commonly used functions definitely should have shorter names.
split/rsplit is pretty self explanatory, and English is read from left to right which makes it easy which one is reverse.
Imagine calling vector.reserveMemory() because reverve what?!
Naming is truly the hardest problem.

Is there something else as a reason, or just this?

I would argue passing boolean as argument is in most of cases a code smell.
Why would you prefer passing argument and having additional if/else inside over using separate functions?
Seems like unnecessary branching where it might not even be needed.

Also it's unreadable without named arguments. s.split(true)? s.split(false)?
I would only considered using boolean as parameter to function if functions itself is relatively big and bool affects only small portions of it, and even then only in language which supports named args.

 

[y a t s]

I've done verbose variable naming like this before but ultimately realized it can go too far. Would I rather see names like itertools become iterator_tools and so forth until the code can't fit on single lines? Certainly not. One area where Python definitely nails it is statements like import pandas as pd and import numpy as np which don't pollute the global namespace like R does but are still reasonably compact.

I 100% agree. As a rule of thumb, a specific form/implementation is best when I can glance at it and understand it in one quick step. The more verbose you are, the more data your brain has to strip away to isolate the basic meaning of what's written. Also, rsplit can be distinguished from split by using the first few letters. split_from_{left,right} requires traversing the whole phrase to do this. All of this mental effort (I'm being serious here) adds up quickly when you consider how much you need to parse on average every second. We were built for simple stuff like poke bear with big stick; hope bear doesn't poke back.

This was a thing I picked up doing kernel development. My sleep-deprived ass needs to fully understand the garbage I just spent the past few hours writing.

 

[Sperg Coalition]

I've done verbose variable naming like this before but ultimately realized it can go too far.

It's up to you to be competent enough to understand when a variable's name becomes too verbose. Part of your job (and to make things easier to you and/or other programmers that might read your code later on) is to document your code on what it does (the *how* is not that important most of the time) and self descriptive variables coupled with clear and concise comments can seriously save you a lot of time in the future when you decide/need to get back to your code base.
Don't underestimate correct variable naming and self documenting code.

 

[Marvin]

It's up to you to be competent enough to understand when a variable's name becomes too verbose.

"How many screens up do I need to scroll to read the original context of this name?"

Within the same screen, they can be very short.

If the function or module is larger, or especially if it's a reference from a different file, I'll be a lot more verbose.

I generally don't use single letter variable names, I'll always use at least idx or res (for result) or things like that. But that's just personal taste.

 

[${Sandy}]

Im doing the free c# class and the examples they use piss me off because I am wondering at what point would anyone in the real world use their actual fingers to type something so fucking niggerlicious as Console.WriteLine("Windows" + 1 + 1);
Could they not come up with an example of how any of this shit would be used in the real world?

 

[Mr. 0]

Could they not come up with an example of how any of this shit would be used in the real world?

"one day you will need this so that you can be talked down to and lectured on stackoverflow for not understanding it"

 

[ADHD Mate]

Console.WriteLine("Windows" + 1 + 1);

I don't think anyone would, but it might serve as example of how operator overloading works?
However being able to concat string and integer with + operator is very niggerlicious indeed.

 

[Sperg Coalition]

However being able to concat string and integer with + operator is very niggerlicious indeed.

The ability of overloading operators is super niggerlicious.

 

[306h4Ge5eJUJ]

The ability of overloading operators is super niggerlicious.

Distinguishing between operators and functions at all is niggerlicious.

 

[Sperg Coalition]

Distinguishing between operators and functions at all is niggerlicious.

Lisp truly is the white man's language but nothing will compare God's own programming language HolyC, provided by the blessed messenger Terry Davis.
Sometimes I think about him and I shed a tear...

 

[ADHD Mate]

In my heart there is only std::cout << "Windows" << 1 << 1 << std::endl;.

Spoiler

Lisp truly is the white man's language

I have recently started to play around with Guile.
Haven't played with macros yet, but syntax really starts to grow on me. Polish notations is just the best.
I miss types though.

 

[Agent Sandoval]

Haven't played with macros yet

When you decide it's time, I strongly endorse syntax-rules for the merely eccentric.

Depending on what you miss about types it might be covered either in SRFI-9 or GOOPS. You won't get types at definition without moving over to something like Racket, but a lot of very desirable features of type systems are provided by those modules.