Do you care about software minimalism?

> Because planning and forethought never helped anyone ever.
You'd fit right in working at M$

> Should we also ditch the internal combustion engine
But we totally should.

Attached: image.jpg (1400x840, 257K)

Imagine not believing in progress and sticking with the first thing that happened to work

>it's [current year] so we need to turn everything upside down again
t. Android design monkey
Aren't you supposed to paint all panels in white and moving tabs on bottom for illusion of work?

>believing in progress

Attached: 1546795962667-g.png (703x800, 37K)

living is bloat

It's not like there are pdfs on that site explaining it
JSON is not a regular language neither

Only to some extent.
I like software to do exactly what I want and nothing more. Achieving this with minor resource usage and a well structured code base is a plus.
What I don't care about is circlejerking about how many LoC some project has or people who tell you that you should change your workflow, because it involves bloated software.

If you look at the "less harmful alternatives":
>JSON, CSV, ndb(6), plain(UTF-8) text
They are specifically talking about using XML as a database format rather than a markup language for structured documents.

This might be my autism speaking, but it annoys me they conflate C++, python, and Java. They need to be on different rows for clarity otherwise some autist won't get the point

Yes

Attached: cruxlogo.png (262x68, 9K)

what is most simple for the end user isnt always what is most simple to code

Yes because its good for me and for the developer

minimalism is retarded.
What you're looking for is software simplicity.

Attached: 2019-01-11-1547246917.png (1366x768, 1.56M)

Why UTF-8?

What about the people who don't speak English and need the special characters?

>What you're looking for is software simplicity.
Which freetards can't into also.

Attached: 1544787592829.png (817x443, 44K)

Minimalism is a latch ditch attempt to remain in control. Some people can't get over their mortality. It pisses them off that it would take them their entire lives to review and understand the entire Firefox code. So they go for some plain alternative and pretend added functionality is just bloat. Whenever faced with the legit shortcomings of simple software, they just say that nothing matters: browsing the internet as intended doesn't matter, playing videogames doesn't matter, animations don't matter, images don't matter, enriched-text doesn't matter. If it can't be displayed in a 1970 console, it doesn't matter.

I think you got the columns mixed, UTF-8 is the less harmful alternative.

yes st is the best

No. But, more and more I do believe in auditable code for booting machines. If there is no root of trust from the moment of power-on, then the machine is not trustworthy and it doesn't matter what you run on top of it in the name of 'security.'

We have this absurd notion that we should verify ourselves to the machine and yet are completely comfortable with the machine never veryfing itself to us.

things become harder when you can't keep whole program design in head
things become harder when you can't return to program after some time and get full understanding again in less than a day
it's easy to create convoluted clusterfuck and throw more shit on the pile
but simplifications always emerge from growing complexity and are no less cheaper nor effortless than other development
I really like the rule of "with reasonable knowledge of the program, you should be able to reimplement it from scratch in a week" as a measurement

but shilling something because "muh terminal" without ever reading and understanding the source code (ala the Jow Forumsway) is a reliable mark of mental deficiency

also JSON sucks

Having created a parser for both JSON and XML... JSON is quite a bit nicer, because its rules are more simple and strict. Take this xml:

// Legal
// Legal
// Legal

vs

{"foo":"bar"} // legal
{"foo":'bar'} // Illegal

The xml is particularly frustrating as there are self closing tags without a closing slash, which means you have to account for exceptions like:

Attached: 1549333599341.jpg (1158x585, 277K)

Having created a parser for both JSON and XML... JSON is quite a bit nicer, because its rules are more simple and strict. Take this xml:

// Legal
// Legal
// Legal

vs
{"foo":"bar"} // legal
{"foo":'bar'} // Illegal

The xml is particularly frustrating as there are self closing tags without a closing slash, which means you have to account for exceptions like:

Not him, but aren't there some blocks in UTF-16 and UTF-32 which cannot be (reasonably) encoded to UTF-8? Or surrogate pairs or combining characters or whatever the fuck.

>exceptions
Then it's not XML.

>It pisses them off that it would take them their entire lives to review and understand the entire Firefox code
How do you not see the security problem with this?

>What about the people who don't speak English and need the special characters?
UTF-8 basically was created with that in mind. It even includes the most obscure of Chinese hieroglyphs.

>I like software to do exactly what I want and nothing more. Achieving this with minor resource usage and a well structured code base is a plus.
>What I don't care about is circlejerking about how many LoC some project has or people who tell you that you should change your workflow, because it involves bloated software.
Exactly this.

>there are self closing tags without a closing slash
That's not XML, it's HTML or SGML. XML specifically disallows things like that to make it easier to parse.

en.wikipedia.org/wiki/XHTML#Relationship_to_HTML

True. I made a mistake equating xhtml to html. None the less,

is an exception as a rule, meaning that you can use both single and double quotes for arguments. That complicates parsing needlessly.

Attached: 1536525807549.png (817x656, 127K)

Btw, here's a reason about it:
benlynn.blogspot.com/2011/02/utf-8-good-utf-16-bad_07.html
>There’s no upside. But there are plenty of downsides to UTF-16:
>1. We must worry about byte ordering because UTF-16 deals with 16 bits at a time. A related drawback is the loss of self-synchronization at the byte level.
>2. We lose backwards compatibility with ASCII.
>3. We lose backwards compatibility with code treating NUL as a string terminator.
>4. We cannot losslessly convert from byte streams.
>5. The encoding is inflexible: hopefully 0x110000 code points should be enough, but if it were extended (again), UTF-16 would need major surgery. In contrast, by simply allowing up to 6 bytes, UTF-8 can handle up to 231 code points.
>6. Ugly encoding: it’s the reason why U+D800 to U+DFFF is reserved (though thankfully UTF-16 is self-synchronizing with 16-bit granularity).

I want UTF-32 REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

Why?

i think he was clearly being hyperbolic there. Anyone can agree that code unreviewed or non-visible to the public is sketchy code to say the absolute least, but just because a program is too big for ONE person to review completely doesn't make the program inherently bad, because it was more than likely made by a team and reviewed by a team. So, no, i's not necessarily a problem, but yes, it can lead to problems.

What are the rationalisations for most of the things on the left?
Also, didn't this dude suicide?

>fixed length
>1:1 mapping to Unicode code point value
>random access strings
>more trivial algorithms that are simpler to optimize
>while larger, at least gets compressed to same sizes
it's the most simplistic from Unicode encodings, no killer benefits though

The problem with "minimalism" is that most people believe that the goal is software that is functionally crippled for no reason, or software that does "one thing" when this "one thing" is hard to define in the first place, hence the main issue with "muh Unix philosophy".
It's not even about using fewer resources. A desirable quality, for sure, but it comes second.

The main problem with "bloated" software is that it has an unnecessarily large codebase, which makes it effectively impossible to study, edit and customize, thus defying the main goal of free software. Bloated free software is, de facto nonfree.
That problem is caused by C. Doing anything in C needs a lot of code. Code is duplicated many times and everyone has to reinvent wheels instead of doing it once and sharing the code. Better languages can do more with less code. Using it goes directly against the main goal of a small LOC count.
"Minimalism" in terms of resources is desirable, as I said, but it comes second.
"Minimalism" in terms of functionality is never desirable, and it's only a compromise to reduce the codebase.
Minimalism in terms of a small codebase is the real goal which everyone should aspire to.

Except they don't work.

Define "software simplicity" and compare it with "minimalism".

> the UNIX philosophy didn't work and didn't set the standard for literally every piece of software with exception WangBlows
I think your disk needs defragging again pajeet

Doesn't mean it's a good thing. Also, no operating system on earth follows the "Unix philosophy" with the possible exception of OpenBSD.
Working like Unix != Unix philosophy.

Linux follows a lot of unix philosophy.
What kind of retard does not understand this?

Attached: JuliaMaid.png (306x600, 70K)

>git
>minimalism

Attached: Satanic laugh.gif (540x304, 1.52M)

>Better languages can do more with less code. Using it goes directly against the main goal of a small LOC count.
go read some clever one-liners in perl or awk and then tell me again how fewer lines of code equates to clearer and more understandable.

Worrying about having a tiny piece of software running on top of an OS that's 10s of millions LoC is missing the point.

Nigga, delete what you wrote.

>monolithic kernel
>unix philosophy
Made me kek hard.

why?

>that github page
Why? You can use #define to make "generics" in C.

>perl or awk are the only languages besides c

Attached: 1525464115484.jpg (800x600, 53K)

>wants Unix philosophy
>doesn't use one of the several available Unices

At some point in the past web goblins migrated from XML to JSON as data serialization format for their usual goblin reasons. The "xml bad json good" meme remained from that time.

Two very common symbols (< and >) are used for mark up, rather than something like a curly brace which is far less used.

Let's be honest here, JSON does have some problems, but overall, it's often much better than XML. The latter's complexity is just overkill for many situations.

>XML
>Needs to be told what a paragraph is
>When even nroff from the fucking early 70s knows that normal text with a gap is a paragraph

That's simplicity, not minimalism.

Are you saying we should all start using CP/M?
cpm.z80.de/

>Pereira

The most common niggername in BRland. Why should i care about a nigger faggot's autismus?

I care about usability, monks aren't welcome anywhere, they live like pariahs.

>object key can only be string
>need extension for raw binary data
2 big weak points of JSON

Fuck me, this is a massive headache.

Attached: 1548459092651.gif (504x279, 2.28M)

>whats a hash?
kys

>"Minimalism" in terms of functionality is never desirable
Want to view an image? Open it in Photoshop.

you have no idea of what you are talking about

what's the connection to JSON supposed to be?

The stronghold of unix - bash - doesn't follow unix philosophy. Scripting is clearly not a feature of shell.

Let's be honest here, "xml bad json good" meme exists because web goblins went through the migration process. And it spilled over everything because goblins are numerous and programming is webdev. Also later YAML, TOML, HAML, markdown and rst joined the party and capitalized on the meme.

Define "web goblins".

imagine choosing JSON over XML because of regex

Attached: holyfuck.png (842x792, 82K)

do I look poor to you?

You look like every other user on Jow Forums, so yes. You look poor.

>harmful shit: things used in industry by professionals
>less harmful alternatives: things only used by a group of 50 neckbeards on suckless mailing list, also things that Google develops

Keep dreaming python fag

Lets say you need to parse a JSON document.
If you are a retard, you will probably use regular expressions. Otherwise the sensible thing is to parse it around a Map if the json document is relatively small, or a Hash if you are dealing with a lot of data.

Now imagine how bad of an idea this is:
QMap dynamicMap; // key, value

You want your keys to be static ffs, otherwise you are going to drastically increase the complexity of the parser, which will hurt performance and introduce innumerable pitfalls... for what added benefit?

Attached: 1535489540346.png (418x359, 13K)

Being used in the industry by professionals doesn't make something good.
Not to say that being used by 50 neckbeards does either.

Arguing something is harmful for one thing (say, systems programming with python) when it fits my use case (say, data science with python) doesn't make it bad either.

innovation is progress
reinventing the wheel on the other hand, is not

the industry uses whatever it uses because its cheap and gets the thing done quickly not because its the best. if they can use some shitty framework to do the thing quicker then they will even if it uses 100 times more cpu on the end user device. they dont care about such things at all.

The industry is very nuanced.
If you are a pajeet, being paid per line of code, then you are going to start using Java.

Attached: 1537410441573.png (629x454, 448K)

Imagine thinking that new is inherently better

"Latest and greatest," sweetie.

I laughed out loud at this picture like, three times.

New isn't necessarily better. But neither is old.
Old shit should be objectively judged and criticized by today's standards instead of being put on a pedestal.
There are many things about software that we could do better nowadays, but instead are just historical baggage.

>criticized by today's standards
SGI are shit because they don't have Fortnite and can't play Youtube videos.

>Keep dreaming python fag
I don't know python :^) And don't refer to HashMaps as "hash" because you sound retarded.

Only if it lines up with my pragmatism.

>(((uriel)))
and nothing of value was lost

>Policeman - GAL男宣言
nice

Attached: FoolhardyRegalGrosbeak-small.gif (480x368, 548K)

it's always summer of 2010 in my mind user.

pretty sure he was Portuguese.