Programming thread

[ADHD Mate]

weird way Haskell people decided to do IO.

Akhstually IO monad is very clever solution for pure IO.

It basically has a type that looks like this: IO a = World -> (World, a), which means that your program is just a series of function transforming world, and returning a. (Well main is IO () which means returning unit, so always the same)

Same for more complex functions: String -> IO a = String -> World -> (World, a).
Because Haskell is curried it is equivalent to String -> (World -> (World, a)).
Which means that function applied to string returns function that will transform world and return a.

And world being wrapped inside monad ensures that only one copy of it exists. The only other way to handle it in pure manner would require linear types afaik.
The thing about Haskell is starting with IO is wrong order for learning, which is not really intuitive for people who learned procedural programming first.

 

[Horpach]

Akhstually IO monad is very clever solution for pure IO.

I know, I just personally preferred some other approaches (stream transformations) and am not really ideologically married to functional purity when it comes to IO, though granted that would defeat the stated purpose of Haskell.
This is the place where I will plug the Coalton project, they are trying to implement IO as aforementioned text (and byte?) stream monads. Lispy Haskell fusion is pretty cool, though fundamentally impure—if you care about that—since it has to strongly embed into CL.

Edit: I really cannot think of any other LISP dialect that really tried to implement a strong type theory before, Typed Clojure came close but I find it isn't any easier to use practically than using Coalton on top of Common Lisp, and leaves you with fewer available libraries too; Typed Racked is meh and is even more obscure. I really hope Coalton goes places, I would love to see a "Haskell of Lisps" gain traction.

 

[y a t s]

The thing about Haskell is starting with IO is wrong order for learning, which is not really intuitive for people who learned procedural programming first.

Procedural is much easier to think about in a linear fashion. Functional programming is a bit wacky in the sense that you're often building the various parts of your program from the inside out. Encapsulation is like moving the goalposts, shifting the start and end points of your frame of reference. It's very abstract; I sometimes feel like a lunatic trying to explain it to people.

Apropos to the monads topic, I'll leave by quoting what is probably my most autistic post on here to date

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.

 

[John Badman]

If you don’t like the syntax just write your own programming language.

 

[Marvin]

LISP isn't any harder to learn on the fly than Python

It really shouldn't be considered harder, and it really isn't, but many/most modern programmers are bitches.

Frankly, I think it's less that it's difficult, and more that various trends in the software industry have made entry into programming easy to people whose work really probably shouldn't be relied on in a commercial context.

I hesitate to make this argument, because I really don't like nerd elitism in software. We're always working on solutions to automate things and make things easier and I hate it when smug nerds shit on people actually taking advantage of those solutions.

Still, I think there's something to be said for a thirst for knowledge and a desire to learn how things work under the hood. There's nothing wrong with using an ORM, for example. But if you don't have any idea how it works under the hood and no desire to check it out, you're probably a moron and shouldn't be working in the industry. But a disturbing number of gainfully employed programmers fit this to a T.

They're cheap to employ and thanks to the automation, their solutions mostly work fine. Until they don't and you need to pay out the ass for a competent developer to come in to fix things.

These are the type of people who hear about Lisp and have no interest in learning it in their spare time. Even if you learn it and become a Lisp hater, that's at least a tick above just being a useless python code pajeet.

 

[Horpach]

BROOO LEARN HASKELL BROOO

The latter example is pretty routine Common Lisp, but I'm actually curious about what the former is supposed to do. I'll go out on a limb and say this is a joke and not your own code, and you can't tell me what p is, and which library's versions those ^. and if' are supposed to be (probably lens and utility-ht), right?

Edit: so, if you break this down,

import Control.Lens
import Data.Bool.HT

-- p = ???

biggestDiv :: Integer -> [Integer] -> Integer
biggestDiv = p (<*>) c $ p (<*>) b $ a
  where
    c = ((head ^.) . if' . (==) 1)
    b = (p (p if') b1 b2)
    b1 = (((==) 0 .) . (head ^.)  . mod)
    b2 = ((c biggestDiv <*>) . (head ^.) . div)
    a = (tail ^.) . biggestDiv

A whole bunch of things seem to have inconsistent types here, just try running the snippet for yourself. This may just be nonsense bad code after all

 

[888Flux]

I'll go out on a limb and say this is a joke and not your own code, and you can't tell me what p is, and which library's versions those ^. and if' are supposed to be, right?

I wouldn't be able to tell you what the average Python program does. the only reason I have any competency at all with computers is due to sheer stubbornness and autism.

 

[ADHD Mate]

The latter example is pretty routine Common Lisp, but I'm actually curious about what the former is supposed to do. I'll go out on a limb and say this is a joke and not your own code, and you can't tell me what p is, and which library's versions those ^. and if' are supposed to be (probably lens and utility-ht), right?

Edit: so, if you break this down,

import Control.Lens
import Data.Bool.HT

-- p = ???

biggestDiv :: Integer -> [Integer] -> Integer
biggestDiv = p (<*>) c $ p (<*>) b $ a
  where
    c = ((head ^.) . if' . (==) 1)
    b = (p (p if') b1 b2)
    b1 = (((==) 0 .) . (head ^.)  . mod)
    b2 = ((c biggestDiv <*>) . (head ^.) . div)
    a = (tail ^.) . biggestDiv

A whole bunch of things seem to have inconsistent types here, just try running the snippet for yourself. This may just be nonsense bad code after all

It's from this article. Someone tried to abuse point free expressions.

 

[Owlbear]

I have found myself programming with Rust in a professional environment. It is fucking gross and if not for all the python/JS programmers around here who can't handle a real systems language, I would firmly rather use C or even C++ for anything that is remotely close to the hardware.

There are also so many troons who just don't maintain anything in this ecosystem. They write a "crate" and publish it as though it is done and then later decide that once there are a bunch of users they are not interested in maintaining the thing. So here we are with some of these libraries woven into this production code that have no maintainer and have open github issues containing bugs.

 

[y a t s]

I have found myself programming with Rust in a professional environment. It is fucking gross and if not for all the python/JS programmers around here who can't handle a real systems language, I would firmly rather use C or even C++ for anything that is remotely close to the hardware.

Based. I only use Rust if I have to, like for PRs. It has a lot of potential as a language and concept, but it's made in the most infuriating and nannying way possible.

There are also so many troons who just don't maintain anything in this ecosystem. They write a "crate" and publish it as though it is done and then later decide that once there are a bunch of users they are not interested in maintaining the thing. So here we are with some of these libraries woven into this production code that have no maintainer and have open github issues containing bugs.

On the flip-side, there are tons of lads like me who have libraries no one (but us) actually uses. If one of my KF-related libs becomes more useful/relevant years down the road, I can't guarantee I have the same free time to handle bugs like I do now (which is already heavily limited).

 

[Kosher Dill]

but it's made in the most infuriating and nannying way possible.

You mean "mommying".

 

[Lard Shart]

You mean "mommying".

Is this a reference to cargo mommy?

 

[unleashthefreak]

I would firmly rather use C or even C++ for anything that is remotely close to the hardware.

But why? If you do not write something like le epic drivers, the disadvantages of c++ (god-forbid C) can be alleviated. Even something like Zig (or something more mature) is better than those two.

libraries woven into this production code that have no maintainer and have open github issues containing bugs

This is a bizarre thing to say.

• A library with "bugs" does not mean real problems, even in "production"
  • Tangential, but if it's a serious problem, just use "git" instead of crates.io in cargo.toml and get a drop-in replacement
• You're pulling random, unmaintained libraries with "bugs" into "production" and wildcarding of the version? The version should be reviewed and pinned
• This is a common thing independent of language / author, nothing about rust or troons makes it particularly relevant, much less a causal relationship

but it's made in the most infuriating and nannying way possible.

Do you have specific examples? I find most people who have similar complaints (I don't want to imply that you do), just don't understand the borrow checker/lifetime/etc. (understandable).

 

[Owlbear]

But why? If you do not write something like le epic drivers, the disadvantages of c++ (god-forbid C) can be alleviated. Even something like Zig (or something more mature) is better than those two.

Generally, when you work with other people, you aren't supposed to rewrite what they did unless you absolutely need to. Companies also sometimes have rules about languages you can use.

See the above also in reference to crates. If the crate goes through the corporate vetting process and someone else uses it, excising it is not the easiest thing to do. And no, this type of troonery for core libraries is unique to Javascript and Rust. Python, Go, and C++ libraries that get heavy enough use all gain a committed maintainer. Mostly because these language communities forcibly do that - if you don't maintain your shit, someone who wants to forks it and makes it public that this is their library now.

I'm pretty sure we do have pinned crate versions, but we aren't going to be raising that version number because there won't be fixes to any bugs.

 

[y a t s]

Do you have specific examples? I find most people who have similar complaints (I don't want to imply that you do), just don't understand the borrow checker/lifetime/etc. (understandable).

To name a few:

It is my experience that almost all "opinionated" projects are annoying, a configuration nightmare, and often end up causing widespread adoption of bad practices and style. Rust's faggot compiler bitching at me to use snake case and those GitHub bots that issue PRs on Python projects that use tabs instead of 4 spaces are a major part of what's wrong with modern programming and CS.

So then make an "opinionated" linter like pylint and leave it the fuck alone in the compiler. If GCC complained about me not following the GNU C style, I would track down Stallman, pay my respects, and then promptly punch him in the throat. Rust is perfectly capable of working and compiling without doing all the bullshit formatting stuff the compiler bitches about, so it shouldn't be the compiler's job to police said formatting.

I agree to an extent. A lot of these language-specific dependency managers are complete trash (e.g. pip) and often promote centralization. While most dependency managers support third-party repositories, almost no one actually uses them in practice, and they inevitably die from lack of adoption. This promotes dictatorial mindsets that lead to disgusting shit like crates.io and their thick, robust CoC.

I bring up crates specifically because Rust's very design strongly discourages anything but strict conformity to a set of rigid and subjective policies, and this mindset is pervasive among their community. They even outright say in their first paragraph on the page I linked that they're a "critical resource for the Rust ecosystem".

The broader, more vocal parts of the Rust community react with hostility to anything that disrupts their illusion of consensus. Polemics is core to Rust's philosophy, and it has resulted in one of the most famously hostile communities in CS. I don't want to get political in a post about programming, but it's unavoidable when talking about newer languages like Rust; this is the very problem.

Aside from big problems with centralization and a lack of third-party tooling, I find the language/compiler is set up in a way where it will constantly fight you on stuff that has little to do with memory safety (e.g. stylistic choices).
I find it all deeply unpleasant to deal with, especially for hours on end. Same goes for their community, even for little Q&A stuff.

And this "leave it to the compiler" culture you see in modern CS is deeply concerning to me. Modern compilers are starting to do way too much heavy lifting, well past typical optimization, and are becoming unwieldy and monolithic as a result.

 

[Private Tag Reporter]

77977 absolutely vindicated by real life examples of Rust dependency hell.

When I was a bit younger and more foolish, someone recommended Rust to me. I saw that the most prominent thing they advertise was that their mascot was a PROUD HECCIN NON-BINARY THEY/THEM (later retconned) and I thought that was the most retarded shit and that anyone promoting a non-binary mascot couldn't possibly design a competent systems language.

Lo and behold, Rust is flagrantly retarded.

 

[Kosher Dill]

Is this a reference to cargo mommy?

Of course, my special little boy and/or girl

 

[Owlbear]

And this "leave it to the compiler" culture you see in modern CS is deeply concerning to me. Modern compilers are starting to do way too much heavy lifting, well past typical optimization, and are becoming unwieldy and monolithic as a result.

The troons aren't going to like this, but it turns out that when you move past trivial problems (like the language game ones) and start going toward things like writing databases or other huge webservers, Rust code actually is meaningfully slower than C or C++ because (1) its definition of "safe" is so dogmatic and (2) Rust code seems to use more memory than the respective analogue in C or C++, and this causes cache pollution. It turns out there are lots of things between "catastrophic bug" and "what the borrow checker is okay with." It's still orders of magnitude better than Java, but there's a good reason a lot of database companies are using Go now and not Rust.

 

[Flatline]

On the flip-side, there are tons of lads like me who have libraries no one (but us) actually uses.

Can you post them?

 

[analrapist]

there's a good reason a lot of database companies are using Go now and not Rust

My Fortune 500 corporate programming experience was on a Big Iron Data Management product. That was all Java. In that environment, Java was being used for two reasons: Backcompat, and herding pajeets.

It is a lot harder to get good Rust devs, I'd reckon. Go is decidedly harder to shoot yourself in the foot with. If you're doing corporate dev work, being able to make midwits productive is important.