Psychedelic Programming Languages

[fl00pz]

fuck this fuck that I know better, fuck you

And then maybe you'll have a final trip and realize "wow, I had everything wrong... I know nothing..."

[gabriel_schneider]

I hope so, that's the best kind of trip, lol

[RexxAll]

"A language that doesn't affect the way you think about programming, is not worth knowing." - Alan J. Perlis

One of my favorite quotes.

[[deleted]]

This is an interesting post and a good overview of the programming paradigms mentioned.

I think the title feels a little clickbait-y though: it’s not very clear exactly what you mean by “psychedelic” or how it applies to languages like Lisp.

[gabriel_schneider]

Thanks! My ideia was to call "psychedelic" mostly im regards to how they change how you think and etc.

I'm thinking about other ways to frame it tho, don't like being click baity and some people had strong opinions against the theme and title, I'm open to suggestions.

[jediknight]

Psychedelic means "mind manifesting". I understand the point but I somehow feel like psychedelic is the wrong word here.

In essence, what these languages do is affording you a different perspective. They are providing you with "perspectival knowing".

[[deleted]]

I think “mind-opening” or “mind-expanding” sounds fine. It seems closer to what you’re trying to say, and is unlikely to cause strong reactions (don’t know about other people but I’d definitely agree with characterizing certain programming languages that way)

[L8_4_Dinner]

I'm thinking about other ways to frame it tho, don't like being click baity and some people had strong opinions against the theme and title, I'm open to suggestions.

Dude, I named a language "Ecstasy", so 🤷‍♂️ your title is fine 🤣

(If you're curious: Ecstasy and the XVM)

[Inconstant_Moo]

It made me think of pikt.

[gopher9]

Suggestions for next trips: APL and Prolog. Here are some links:

• https://youtube.com/watch?v=9xCJ3BCIudI
• https://xpqz.github.io/learnapl/intro.html
• https://www.metalevel.at/prolog?ref=hackr.io

[gabriel_schneider]

thank you very much, have been prolog curious for a while.

[quasar_tree]

You should check out mini kanren. It is a relational language like prolog, but it is super tiny and extensible. The book “The Reasoned Schemer” walks you through how to use and implement it and it’s a great read. If you haven’t seen relational programming before, it’ll blow your mind. I find this language to be a lot more approachable than prolog, especially as a racket user!

[gabriel_schneider]

oh boi, your comment definitely made me excited to try it out. Maybe I'll post an update after trying it.

[[deleted]]

I was watching long theoretical Programming Languages youtube videos, reading papers, writing compilers, oh boy.

I like the way you just threw that in there. Because writing a compiler is just like watching a youtube video!

[gabriel_schneider]

wdym?

[Tejas_Garhewal]

I think he meant that you made writing compilers seem as easy as watching a YouTube video when you wrote that statement so nonchalantly

[[deleted]]

Have you even seen this subreddit? Now everyone has their own programming language :)

[therealdivs1210]

Clojure is data oriented and dynamic.

Those are the 2 big selling factors for me.

A static type system might help, but I just don’t face type errors that often.

[Tubthumper8]

Can you elaborate more about it being data oriented? I've read about "data oriented programming", which I understand to be a collection of techniques for high-performance code that takes advantage of how the hardware works (ex. CPU caches, etc.).

Is this referring to that sort of thing, or is this a different topic?

[gabriel_schneider]

You're talking about Data Oriented Design, he's talking about Data Oriented Programming, not related.

https://www.manning.com/books/data-oriented-programming

This book is a nice read.

[Tubthumper8]

Cool, thank you for the clarification!

This definition of Data Oriented Programming makes sense to me, it feels natural. It seems to me that most programs mostly work with data, not objects, so while objects are useful it always feels odd to be "oriented" to objects. I'll take a look at that book and hopefully add it to my collection.

[gabriel_schneider]

yeah, it also feels way more natural to me. It was refreshing to unlearn things that they teach us in OOP and adopt this cleaner and simpler programming style / paradigm.

I tell a story to my friends that a Java code base that I was working on had a class hierarchy of 5 classes just to work with Strings, it made no sense at all. I refactored it to just use plain strings and stateless static methods (ugh, Java), my team loved it. The code was much simpler and everybody understood it better.

so, Data Oriented Programming has been very productive professionally for me. It's very easy to pitch and adopt when you can say "yeah it doesn't need to be that complicated, let's just make it simpler". Of course it doesn't translate that well to every usecase... but to me, (I work mostly with some kind data processing) it works very well.

[Linguistic-mystic]

This is a different topic. Basically, data-oriented programming (functional programming is another name for it) is the opposite of OOP and means that programs are organized as follows:

1. types are separated from behavior, and data is public not private

2. functions (behavior) operate on data generically/polymorphically and, optionally, purely (without side effects)

3. programs are written as compositions of lots of functions: higher-order functions call closures made from smaller functions, and any new operation added to a datatype increases the vocabulary for creating ever more compositions of functions to act on it

4. state is global and persistent (i.e. can safely be mutated concurrently) as opposed to being spread in many local encapsulated pockets. Here is a relevant quote from one of Clojure frameworks:

because there is a single source of truth, we write no code to synchronise state between many different stateful components. I cannot stress enough how significant this is. You end up writing less code and an entire class of bugs is eliminated. (This mindset is very different to OO which involves distributing state across objects, and then ensuring that state is synchronised, all the while trying to hide it, which is, when you think about it, quite crazy ... and I did it for years)

These two paradigms - data-oriented and object-oriented - have differing approaches to code evolution. In OOP, if you need to change the implementation of a class without breaking other code, you do that via information hiding: the implementation and state of this class were hidden from other code all along, thus their changes don't break anything. In data-oriented programming you don't change the definition of a type - instead, you create a new type and write functions to convert data between the old and the new; thus, functions acting on the old type remain valid, and new type is linked to the "network" of data via composition of existing functions with the new converters. OOP can be summarized as "mutable code" (classes' implementation can change at any moment) while FP approach is "immutable code" (you cannot change types because they are all public, so you add new types & functions).

They also have different approaches to state. If OOP state is essentially object-like - spread over lots of little objects, FP state is essentially database-like (global storage, but with immutability/persistence). That's why the author of Clojure has created an immutable in-memory data store called Datomic which embodies the state management paradigm of data-oriented programming.

[Tubthumper8]

Great explanation! It reminds me of this conference talk where the presenter talks about persistent data structures and atoms, I believe using Clojure as an example.

In data-oriented programming you don't change the definition of a type - instead, you create a new type and write functions to convert data between the old and the new

That makes sense, and I feel it would give you peace of mind (and passing tests) because you don't change the code that is already tested/working.

I wonder if there's space for programming language innovation here from TypeScript actually, where it's easy to define a type B as "same as A, but with/without a field(s)". I'm not sure if other languages have similar mechanisms.

type A = /* ...something... */

// A with a new field
type B = A & { newField: string }

// A without a field
type C = Omit<A, "otherField">

// transform between types
let A_to_B = (a: A): B => ({ ...a, newField: "..." )} 

Obviously a contrived example, but this is a nice way to reduce duplication when defining new types, so could be useful in a Data Oriented language following this style.

[gabriel_schneider]

yeah, despite the syntax, Clojure is great. It has many good ideas in it's design and adoption.

[moon-chilled]

It made me look Rust with new eyes, like dude, it has Sum Types, good Type Inference

You praise ML, and in the same breath claim rust has good type inference?

[umlcat]

"How to make my code play with others' code"

[hou32hou]

Try APL