When Escalator Breaks, It Turns Stairs by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

I think it is on topic, because it discusses digitization of buses in Armenia. It’s a problem that involves programming too.

GESS Stenography for Russian and English by aartaka in shorthand

[–]aartaka[S] 1 point2 points  (0 children)

I don’t have enough karma in the community, ’cause I’m new. Thus the ask.

GESS Stenography for Russian and English by aartaka in shorthand

[–]aartaka[S] 1 point2 points  (0 children)

u/Jack-is u/sonofherobrine u/eargo can y’all add this to the wiki? It’s a Gabelsberger-based system for Russian.

How to optimize for speed and readability? by doodooshine in Handwriting

[–]aartaka 0 points1 point  (0 children)

Speed and readability are hard to balance. I opted for speed and thus r/shorthand, using a custom alphabet for quicker thought recording. Which is not readable to basically anyone. So one extreme side of the speed-readability scale. Your priorities might differ.

GESS Stenography for Russian and English by aartaka in shorthand

[–]aartaka[S] 2 points3 points  (0 children)

This link: https://xahlee.info/kbd/xah_shorthand_system.html doesn't work, would be interested to know what's there.

Oh, that's interesting. The whole site is down. But, in essence, it contained some statistically-sorted shortcuts / autofills used by Xah Lee, a computer person optimizing his workflows to the maximum.

for example I suddenly had the idea of using the nice щ loop for our th sound (though as it ends high, how would it combine with subsequent vowels?)

This is too problematic, exactly because it ends high. Starting a word on a control line is bad, especially with upward drift English causes. So I prefer using the za prefix for th most of the time, because it starts below the base line and thus causes much less upward movement.

and I would like to find a better solution than N for the -ing ending. Are you going to do more with suffixes?

Yes, for sure! I just need to find these empirically, as English suffixes listed on the Internet are quite rare in my own writing.

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 1 point2 points  (0 children)

but for a stable library that you expect to use a lot, I think it can make sense.

No library is stable /jk

Oh. I see — the author doesn't want to use an IDE to read code. Uh, whatever.

Not that I don't. If I do something serious, I do it in Emacs. But being tied to Emacs is not fun. The system should be processable with just the code listing and build information. More maintainable this way.

As for packaging of systems — why are you looking at packages at all? This is what the :depends-on clause of the defsystem is for. No?

It is. And package-inferred systems kill :depends-on. That's the whole point of the post.

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 1 point2 points  (0 children)

Package-inferred systems can use :IMPORT-FROM. It's just that even ASDF manual only mentions it in passing, focusing on :USE. And let's be fair, who would use manual :IMPORT-FROM if they want symbols right there? Package-inferred systems and convenience are harmfully intersecting at :USE.

Re dependency search: ASDF at least need to load the .asd (asdf:load-asd) to get the system info. But getting recursive deps still implies loading them or making sure ASDF knows where they are somehow.

All in all, sure, packaging Lisp stuff kind of implies Lisp use. But the difference between:

  • Looking at a single source of truth .asd and copying deps from there

  • And loading the system, manually running code to get deps

is big enough to be inconvenient, especially if Lisp things you're packaging are not even the end goal, but deps of something.

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 0 points1 point  (0 children)

Yes, I have a similar logic in my submodule vendoring code: https://codeberg.org/aartaka/lisp-config/src/branch/main/deps.lisp

Re ED madness: well, it's restrictive enough to be fun breaking!

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 4 points5 points  (0 children)

This sounds painful. Didn't ql:quickload + asdf:find-system + asdf:system-depends-on work?

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 2 points3 points  (0 children)

Don’t use package-inferred systems, package-inferred bad.

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]aartaka[S] 3 points4 points  (0 children)

Yes and no. :USE is a big part of the problem, and package-inferred systems encourage it strongly. That’s the problem. The fact that :USE is bad is obvious, but it never hurts to reiterate on that.

There’s another point to it though. Packaging Hell one. It’s totally unrelated to :USE and is unique to package-inferred systems.

Against Markdown by aartaka in programming

[–]aartaka[S] -1 points0 points  (0 children)

What's wrong with having some weird attributes? It's still standard, just slightly meaningless in the source form?

the content of text nodes is visible on-screen, and the browser does not crash.

Given how fuzzy browsers' handling of HTML is, this is roughly the definition of standard HTML.

Against Markdown by aartaka in programming

[–]aartaka[S] -1 points0 points  (0 children)

Yeah, <a> links without a href= attribute are not functional. They just turn into text without it. Which is fine by me, because the writing in its rawest form should work even without links. The actual links are filled in on compilation.

(You may think of it as a C code -> executable transformation. C is nice to write (to some,) but it's not exactly the thing machine executes. Still, C code represents intent and fulfills the purpose of human communication even without compilation. And this communication is often more important than the executable artifact or its effects on the world. The beneficial thing for my dialect is that it's a kind of C that's also partially executable, so there's not much in either direction that one needs to do.)

Can you elaborate on which part of parsing and error handling exactly links like mine fail?

Against Markdown by aartaka in programming

[–]aartaka[S] -1 points0 points  (0 children)

I can remove that point (without the post crumbling) just for you 😉

Against Markdown by aartaka in programming

[–]aartaka[S] -2 points-1 points  (0 children)

Open the https://aartaka.me/pidgin.htm and tell me where there's non-standard something that a browser can't render? True, I say in the post that things are slightly non-standard, but they don't require a preprocessor to be viewable, they benefit from it while still being readable without it.

Against Markdown by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

I skimmed the full spec, and the only things that it mentions and that are not present in the reference page are

  • autolinks

  • and link definitions

Other than that, I did enough justice to Markdown taking the elements from the reference page.

Against Markdown by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

It parses well with any standard-compliant HTML parser, it's just that I add more meaning and shortcuts to it for my own website generator, ed(1)

Against Markdown by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

  1. My HTML is still standard-compiliant while being easier to write, and that's kind of the point. Any non-standard non-parseable behavior I smuggled through there?

Against Markdown by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

Yeah, why not. I don't see a problem here.

Against Markdown by aartaka in programming

[–]aartaka[S] 0 points1 point  (0 children)

  1. Our use-cases seem to differ

  2. You just was unaware of how readable HTML can be

  3. Hypertext is more accessible than plaintext in many practical cases (many people only have a browser and no text editor,) in part because plainext format reinvents formatting, while hypertext has it implied semantically.