Fork me on GitHub
#off-topic
<
2020-05-30
>
craftybones14:05:39

Anyone know of a self hosted Tumblr kind of tool?

adamfeldman14:05:30

Potentially Ghost, with a Tumblr-like theme? https://github.com/TryGhost/Ghost

craftybones15:05:03

Thanks, I had already seen this. Looks almost exactly like what I need

šŸ‘ 4
craftybones14:05:04

Not wordpress. Other than wordpress šŸ˜„

craftybones14:05:10

Mastodon is federated, so I canā€™t ā€œprivatiseā€ it

Daniel Tan17:05:52

writing a custom questionnaire for my gf with randomly changing requirements made me appreaciate clojure way too much

David Pham20:05:54

Linus Torwald on 80 characters limit. https://lkml.org/lkml/2020/5/29/1038

šŸ‘ 8
p-himik20:05:17

I am genuinely surprised to see such a long message about 80 character limit in 2020.

ā˜ļø 4
dominicm06:05:11

Also in the character limit itself :)

p-himik07:05:41

Limit in 80 characters or a limit in general? Because the latter, if used as a warning, can make both the author and the reviewers think twice, which is a good thing.

David Pham07:05:23

In Clojure we have a 80 characters limit though

p-himik07:05:13

"We" as in "in the company I work with" or as in "in the Clojure community in general"?

dominicm08:05:39

@U2FRKM4TW I was pointing at the email's character limit.

dominicm08:05:46

There's probably some relevant context here. I suspect ~80 is still a guideline.

dominicm08:05:12

Lobsters discussion brought up the idea of 72 non-whitespace characters. In alignment with human reading limits.

p-himik08:05:34

Is there a link?

p-himik08:05:38

A common pitfall is to equal reading code to reading prose. IMO it's completely wrong and what's suitable for one is not suitable for the other.

āœ”ļø 8
Drew Verlee15:05:19

The issue can't be universally solved at the text level. It needs to be higher such that the text can be parsed into something with more structure and a program can read that and format it based on what ever preferences the reader has. Why isn't this possible now? Is it git:? are we all so used to it that we can't invent another way to track change? I seem to recall that Unison attempts to solve this issue.

phronmophobic17:05:16

it (literate programming) is possible now. itā€™s just not widely adopted

p-himik18:05:34

For a good reason, I imagine. I cannot think of a way to manage comments with that approach.

phronmophobic18:05:21

thatā€™s what the literate programming tools help you do

p-himik18:05:47

Could they help reformat a 120-character-wide ASCII diagram in a comment into an 80-character-wide one?

phronmophobic18:05:19

actually, yes, but you would never do that because most of these tools also allow you to embed actual diagrams

p-himik18:05:28

I can't find anything quickly - everything that I find seems utterly irrelevant. Do you have an example or at least a link that more or less clearly shows such capability?

p-himik19:05:53

OK, those are some of the examples that I've found. But I still don't get what you're saying. I'm using Jupyter notebooks from time to time. And they have nothing of what you describe. You can mix text and code there, yes, and the text will be laid out depending on how the notebook is represented. But the code will never be reformatted for you, ever.

phronmophobic19:05:01

in the example of tex (initially released in 1978), the source code is heavily reformatted. in the last 42 years, thereā€™s been lots of work/research/examples of literate programming. I donā€™t know how much reformatting is considered enough. basically, I donā€™t know it what it is youā€™re looking for.

p-himik19:05:04

I'm looking for an example where the source file formatting does not matter at all, where how a user sees the code depends only on the preferences of the user and not on how the file was initially formatted.

Drew Verlee19:05:02

I personal wasn't talking about literate programming. I was saying that ideally our tools (editor, version control) know about the abstract syntax tree of our language and are able to track changes at that level rather then text/whitespace/etc...

Drew Verlee19:05:02

you can set you editor write now to wrap lines at what ever you like. The big hurdle i see is that we track changes on git and so you can't reformat the entire project everytime.

phronmophobic19:05:06

structured editors do that, but I donā€™t think itā€™s very common outside structured editors because itā€™s not very useful. the main problem is that it causes issues with version control and that the alternative solution, making everyone that works on the code base adhere to a specific style guide (eg. gofmt) is much better.

Drew Verlee19:05:49

> the main problem is that it causes issues with version control Yes, because they track changes at a text level?

Drew Verlee19:05:56

Yea. That's the problem that needs fixing imo. Everything upstream of it is just pushing the complexity around.

phronmophobic19:05:42

and the benefits are much greater than just allowing you to change how whitespace is used in your program

phronmophobic19:05:30

you could technically achieve this while still using git, but youā€™d have to augment the git porcelain to make it usable

Drew Verlee19:05:04

I think unsion, which treats functions more like data in a database is probably a step in the right direction. I'm not aware of what porcelain does.

Drew Verlee19:05:28

oh i see. yea.

phronmophobic19:05:04

right, git commits are just a tree of of data.

phronmophobic19:05:33

so instead of storing text files, you could store the AST somehow

phronmophobic19:05:57

that would be a fun project

phronmophobic19:05:41

I think thereā€™s a talk where someone from cognitect started storing programs in datomic and found some interesting things you could do with that

phronmophobic19:05:55

you could still have formatting be user independent without solving the version control issue as long as a canonical formatting exists. for example, you run something like gofmt to format the code in your preferred style when you work on the code, but then you run the ā€œofficialā€ gofmt when you check code in.

didibus22:05:34

Can't you change git's diffing algorithms?

didibus22:05:38

Also just saying, I'm šŸ’Æ with Linus, at least go 120 if not more

didibus22:05:58

Personally I prefer having no line lengths. Let the dev put newlines wherever they think is best. And only have a formatter like cljfmt that indents and aligns, not one that wraps lines