/tech/ - Technology

Technology & Computing


New Reply[×]
Name
Sage
Subject
Message
Files Max 5 files32MB total
Tegaki
Password
Captcha*Select the solid/filled icons
[New Reply]


1f7c379bd6ab88a7a30134a428ea996a71d38610202098131719562ad22e9f73.jpg
[Hide] (13.7KB, 300x200)
One of the cornerstones of the unix filosophy is extensibility, and is great piping all of these programs one onto the other, like a assembly line folding aluminum onto cans. But the world isn't the command line, nor some lisp machine, because programmers define the specifications and estrucure of data as the want.

How should all this different programs even live along? Because not even all programs even consider this method. Vast mayority of GUI Apps are designed to be its own data ecosystem, cause i would be neat if i could reuse their subroutines for my purposes (like plugging GIMP's filters onto Kdenlive pipeline, or inspecting CAD software path finding wiring algorithms)

Here i am talking of modular design, maybe even replaceable parts; but i am skiping a lot of implmentation. 

Although ou got monolytic black-boxes programs like ffmpeg, yt-dlp, imagemagik. They work so well, and their interface is very accesible, even if their internals are whole opaque.

You go too programs like Unreal Engine, Blender, Davinci Resolve, LaTex; they are walled gardens, but ther internal ecosystem is rich in scripting, and as factories, they spit a finalized can render product.

Dont even talk about interface. Is the low caliber pipe of plain text enought? By the way, Wich one? ini, cvs, xml, json?; Should we consider creating specifications, binary formats? Isn't that really propertary? But midi just works so well; Are you ready to enter the world of local net protocols?; Let's imagine more: Not delivering data, but access to data, and sending the subroutine-as-a-primitive that parses a shared memory location of opaque data structures.

Sometimes i feel unghinged. The world is spinning all without me, and people are working really well on those conditions; i am. The "People will use whatever we produce" has a positive side too, so look at the plethora of scripts that do extend walled gardens. Look at the other side of the fence, at linux ricers and their adventures at config land, where they see the vast lands between mouments of programs, Did you know that deep into the etc folder, Xorg created a programming language for their config files? Its so funny

I got stuck sorry. If you promise me staying another paragraph. Some lispers at Palo Alto did this, and created this graphical enviroments where all the data was passed as pure messages, though a byte code custom cpu, and all its partes could be changed, inspected, debugged and customized; GUI its not for the weak, its for productivity on the less keystrokes

Let's return to the final paragraph. So data... Its data a first orden citizen? How should data be shared between programs? As plain transparent codecs, or as routines for acess? File systems? How should programs request data to others without violating secutity?

Then, routines... Who's responsability for acessibility? The program or the OS? Should reuse be a hight priority? Or we cant stop fragmentation? Should web embrace the hacker remark of duck-taped pipes? It may be not so bad, the Excel team even designed their own C closed compliler. How should we cope with the harsh reality of fragmentation? Its extensibility the final goal of user computing? Remember that at this scale, scale that we surpassed a lot ago, since the times of IBM, programming is not about just computers: Its about Logistics and Sociology, and the sooner you recognice that, the sooner you can make steps on the right direction.

Hope this awakes insigthfull remarks
American_reading_comprehension.jpg
[Hide] (79.3KB, 894x960)
Popular software is proprietary, siloed, locked down cuckware because corporations want it that way and people are too dumb to resist, for example no phone OS choice, nobody uses open and interoperable chats, companies block objectively better frontends, removing software locks is illegal. Interoperability would kill their profits so they don't do it and actively fight it.

>would be neat if i could reuse their subroutines for my purposes
It would be. Sometimes the only thing preventing it is none of the volunteers care to make a standard, other times it would create complexity because interdependency between GIMP and Kdenlive, can't update filter system on one without rewriting the other. Photo and video filters could be incompatible because while video is a series of pictures, a filter could cause effects like shimmer seen in in video game AI upscalers.

>black-boxes programs like ffmpeg, yt-dlp, imagemagik
These are open source and a lot of it is modular code, libraries. If you need something specific they don't expose the way you want, the relevant code can be imported or copy pasted into a new tool. yt-dlp is a thousand python modules, it's not some single file spaghetti.

Proprietary like Adobe Premiere, Photoshop, CAD software, it would be nice if those were modular. Not gonna happen because this world is about treating other people like bitches and goyim, or being a freeloader making $500 a week using GIMP and not kicking back $1. Smart communism would solve this by governments taking over funding, smart capitalism would solve it by users supporting good practices. But there isn't anything smart where masses of propagandized goyim are involved.

>Should we consider creating specifications, binary formats? Isn't that really propertary?
No, open standards aren't proprietary. The JPG format is binary but not proprietary.

>How should data be shared between programs? As plain transparent codecs, or as routines for acess?
Doesn't matter as long as it's standardized. This isn't the issue, a lot of this is solved, people just don't care and get cucked for convenience instead.

>Is the low caliber pipe of plain text enought?
Unix pipe isn't plain text, it does binary too like mp3, mkv, midi, 3d models, a lot of programs do that internally.

>piping
Software sucks because users suck, people can't git gud at Fisher Price phone UI. I've seen some creative ways people switch between apps, they'll never learn the intended fast way. They don't have a clue and don't question where their contacts, photos, messages are stored. Anything more complex, a basic 5 line script, 99.9% are lost, they can't comprehend modular CLI shit. They will use the app that asks for an email, has a 9000 page forced arbitration ToS, steals and sells all personal data, as long as there are no more than 2 buttons on the screen.

How many wimn would own a computer if not for social media bing bing, how many would program as a hobby? Normies would never touch a computer in their life, they only care about outcomes. Eat up whatever software and hardware slop they're fed. What they're fed could be efficient, interoperable and suckless, normies would prefer it, but that's not in the best interest of corporations.
unix is bloated and backdoored since systemd. i only run templeos now. oh, nvm lambda is back, no need to use this cucked website that blocks my name
emacsconf.png
[Hide] (107.1KB, 1280x960)
How familiar are you with Emacs?  When it comes to extensibility, I think it is one of the best examples out there.  It's really a Lisp application platform that masquerades as a text editor.
https://emacsconf.org/
https://www.masteringemacs.org/
Replies: >>16901
>>16900
Emacs is more like a LISP machine emulator that for some dogforsaken reason is called a text editor. I don't have a problem with it per se, but the editor wars are quite stupid in hindsight if we accept that it is not an editor, and the conflict was really about keybindings all along.
Replies: >>16903
iq-meme-joke-i-am-not-saying-visual-studio-users-are-dumb.png
[Hide] (260.5KB, 1240x864)
>>16901
Bindings that you can just change if you're at all competent. Though that is easier in Emacs, because Emacs just makes customization in general easier, because of what it is. Plus vi bindings are flawed anyway (though hjkl itself is fine, everything else is no more ergonomic than Emacs other than in that it's modal, which Emacs can also be). But yes, Emacs is just a Lisp environment with a mostly text-based UI (though it has graphics as well, which is a considerable advantage) that can be used for anything. 

It helps that pretty much everything you do in a computer involves interacting with text anyway. Like, a file manager is ultimately a list of strings, so is writing commands in a shell (M-x shell allows you to use your Emacs bindings and functionality in a shell that just runs in a text buffer, without a terminal emulator), and so is a playlist in a media player, and so is an RSS client, and so is an email client (plus writing messages is text editing), and so is a chat client. And deleting a line is somewhat equivalent to deleting a file or message or whatever it is. Plus writing messages of any kind is text editing, so you might as well do that in your editor. And a lot of functionality that is useful in an editor is useful in other things as well, like searching (I use consult-line for that, and I have it in everything I do in Emacs, and can also use embark to export it to a buffer). Within Emacs, you get a consistent interface, and the same functionality, for everything.

An easy example of that is multiple cursors. You can have that in other editors, but if you add that to Emacs, you can then use it in everything you use Emacs for, because all packages inherit its user interface features (while in other editors, it's stuck within the editor, and you'd only have it if every individual program implemented it as well, the same way). I can match buffers in ibuffer, to add cursors to them, and then close all the matching buffers. I can do file management in dired with multiple cursors, I can use it in Elfeed to match different videos or articles and open them all at once. And I can use it to run my own functions, that I wrote (like for streaming videos with mpv, or downloading them with yt-dlp).

Other editors can't compare, because they are just editors, not a programmable environment applicable to any task. That's why GNU Emacs is still around despite its issues caused by 40 years of backwards compatibility, it's because not many programs have aimed to be what it is. I guess Lem is aiming to be that, but last time I checked, I could still crash it very easily, and it had no documentation built into it (which is another strength of Emacs). Plus it's still only usable as an editor, because catching up to Emacs' functionality is not easy at all. And if using Emacs is a niche, and developing it is a niche within a niche, developing an alternative for it in Common Lisp is a niche within a niche within a niche within a niche.
Replies: >>16904
>>16903
>Bindings that you can just change if you're at all competent. Though that is easier in Emacs, because Emacs just makes customization in general easier, because of what it is. Plus vi bindings are flawed anyway (though hjkl itself is fine, everything else is no more ergonomic than Emacs other than in that it's modal, which Emacs can also be). 
All I can say is that it seems like using evil mode is reasonably popular amongst Emacs users, meanwhile most people never heard of Vimacs:
https://www.vim.org/scripts/script.php?script_id=300
Replies: >>16912
>>16904
People that insist on using default Emacs bindings won't be moving to Vim in the first place. Especially if they do not want modal editing.
[New Reply]
7 replies | 4 files
Connecting...
Show Post Actions

Actions:

Captcha:

Select the solid/filled icons
- news - rules - faq -
jschan 1.7.3