So, what is this board's consensus on the pursue of these values in software development? A good example of this being put in practice is suckless, my experience with their programs is usually on par with what they preach. Modifying source code in order to configure them sounds extreme, but it doesn't take too long to do and it isn't so hard, for me at least.
Do you guys feel like they are a bit too extreme in their ways, or do they have a point?
Suckless are retarded fags who think a statically linked linux is a good idea.
Suckless is autism. Code should be designed to be malleable even if that means bloat. Minimalism is only of value in teaching. Optimization is the only transform on malleable code you should consider, and that is the enemy of minimalism.
...
Suckless is vulnerable by design, dynamic linking is a best practise for security.
They have a point (but static linking is mostly retarded). Minimalism brings too much advantages (less bugs, easier to understand, modularity) to ignore it.
Static linking is entirely retarded. The only place I do it is when making squashfs firmware where some tool needs to exist outside of it but won't have any libraries available. I have musl just for that case as glibc static linking is like some sort of troll.
I believe that software freedom is fundamentally more important. When I have freedom, I can make my software as minimalist as I desire. I think it's easier to start with software that has too many features and remove the bits that I don't need. That is easier than to start with nothing and build something from that.
lol is it still the 70s?
Yeah, they're correct.
Sometimes they can be autists who take the idea too far though, like that guy on their mailing lists who made a shell with even less than the thompson shell.
cat-v express the philosophy better. It shouldnt come with a disregard for interface, it should be an attempt to simultaneously make the actual computing being done and the interface to it fundementally simple.
Thats a clumsy, poorly worded way of describing it, but im not a writer. I have extremely strong distaste for the idea that its OK if code is incomprehensible if it does the thing right when you run it.
The general idea in Unix is that you make small tools and they work together, instead of making big tools with lots of features. So suckless makes sense in that context.
It falls appart if you go extreme and make tools that are missing basic functionality that you can't get from pipping to/from other programs, or when the overhead or added complication of IPC is too high. And don't forget that if one program fails (for whatever reason), you have to handle it somewhere.
You're more free when you can combine simple things to do what you want then if you're reliant upon some 'professional' to add it to your program.
Unless you are that 'professional', of course.
What's retarded about static linking ?
"Suckless" is not really about minimalism, it's about UNIX-isms and not about what actually reduces bloat and makes smaller software. The "software tools" and "little languages" philosophy leads to bloat and duplication. You wouldn't need any of them with a scripting language like Perl or Python. They only exist to get around the deficiency of the shell.
The suckless style of minimalism also sucks because they think cutting out important features would keep users from wanting them. It doesn't work and everything ends up being tacked on anyway but it's a huge mess because nobody cares about how it all fits together.
I've written entire websites that were smaller than the minified javashit on this page.
Yeah we should just use Python and avoid all those bloated "software tools". lmao
What's retarded about programming via copy+paste?
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
“..At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” – C.A.R. Hoare
This guy explains it really well.
Libraries are still "copy pasted" they're just not built in. Are you retarded or something ?
Good lord, you have no idea what you're talking about, do you. Why are you calling others retarded? How are they "copy+pasted"?
I like minimal code with maximum impact. Minimalist GUI design, I detest. It gets worse when you realize most (not suckless to be fair) of these programs are bloated pieces of shit. Horizontal menus don't take up much space and are more intuitive than three bars, for example. Minimalist icons and flat design are also poor. Case in point, look at how Adobe icons have devolved. I can understand if you don't want to waste resources on compositing effects, but at least put some artistic effort into your design.
rm -r /usr/lib/*
Good luck!
Use Lisp. Design simple interfaces, build robust software.
Is it as fast as C though?
Minimalism in regards to what? I think the suckless way of having to re-compile your application in order to configure it is retarded as fuck.
Minimalism should be about the user interface. This means instead of providing many options programs should be designed to be plugged into each other. You can then put together more complex systems yourself as you see fit with piping and a bit of awk/perl scripting as glue when necessary.
For more complex applications I like the idea of a DSL or a scripting language. Not every application can be as simple as ls, and for those you want to provide a simple way for the user to provide configurations. I really like the way Neovim does it: instead of the extension language being built into the editor, the editor provides an interface for the extension language. You can then add a client and write Neovim plugins in any language you want. Just look at this list:
github.com
In Vim the extension language was built into the editor, so all the maintenance burden was on Vim, which was an unsustainable nightmare. With Neovim now that the interface is in place it is up to the individual client developers to keep their clients working. Using a well-defined interface makes to surface of contact between editor and client very clear, much easier to maintain than having things wired together directly like in Vim.
Check out SBCL or Chez. Short answer: it's competitive.
Their programs take few tens of seconds to compile. How often do you change your terminal applications' settings?
Not often, but when I change them I want to try out many changes in quick succession. If I have to re-compile every time I need to 1) have the source code around or re-download it, 2) look up the settings, 3) locate them in the source code, 4) change the setting, 5) re-compile, 6) try out the setting, 7 goto 2)
Is it impossible to deal with? Of course not, but it is really cumbersome. And if you want to share the same config on more than one machine you have to carry around the source code instead of just a config file. What if you want to update the program, do you then turn your changes into a patch file and apply the patch to the new source code? (I assume all the setting are isolated into a header file or something like that) What if you want to change a setting just for one session? Do you seriously re-compile the source and then revert it back five minutes later? This is the sort of thing command-line arguments and environment variables exist for.
t.ricer
You sound like you've never tried using any suckless stuff.
Most of their stuff compiles in seconds just compile a few different versions, would solve some of your other complaints too.
that is exactly what they do though.
'minimalism' means simplicity, which implies that naturally.
HTML is not minimalist and simple enough.
(title "SEML Example")(meta 'charset "UTF-8")(stylesheet "/static/style/styles.sess")(script "/static/script/main.cl" :type 'common-lisp)(body(paragraph :class 'main-p This is a (bold SEML) testing page.)(paragraph (emphasis SEML) is meant to be a cleaner markup language through the usage of S-Expressions.)(list :ordered nil (item Lisp-like syntax) (item Easier to write) (item More advantages here))(section :class 'outer (section :class 'inner This will be red)))
(rule :class 'main-p (set 'padding (rem 2)) (set 'font-size (px 18)))(rule :class 'outer (rule :class 'inner (set 'foreground-color #xFF0000)))
The simplicity and beauty of generating or ingesting XML via s-expressions really puts all non-lisp languages to shame.
How do we make this a thing?
objectivly wrong.
brainlet klabnikposter
We don't. The best thing you can use is a generator that takes in S-expressions and puts out HTML.
But seriously, how did something ugly like SGML ever become a thing when S-expressions do exist?
It is a thing. Use Lisp.
Check out some of the examples on Racket's website: docs.racket-lang.org
And Racket's XML library:
> (require xml)> (xexpr->string '(html (head (title "Hello world!")) (body (p "Hey out there!"))))"Hello world!Hey out there!"
Sex-pressions lol
Smaller individual programs are also better from a security standpoint. Much easier to audit small programs than huge ones.
Here is how it became a thing:
That's minimalism for you, kid. Multiple dispatch? Java originally didn't have generics because
You misunderstand minimalism, it's not about stripping out features, but forming them in such a way that they are built from the same fundamental principles as the rest of the system.
Lisp has incredibly simple semantics and syntax, SICP famously used Scheme because the entire language could be taught in 30 minutes and then forgotten.
Despite their simplicity, Lisp's small set of axiomatic principles - sexps, symbols, code-as-data - naturally give rise to a great wealth of language features that don't need any kind of explicit support.
This simplicity naturally leads to a simple implementation too, it's trivial to implement a Lisp on a stack machine and often posed as an intermediate exercise.
Java, on the other hand, has a great wealth of hieroglyphs to go along with the various rituals needed to invoke its separate language features, all of which amount to less than what Lisp accomplished out of the box 35 years ago. It's a chore to write, forcing the programmer to keep in his mind a slew of unnecessary details and corner cases, all while existing on top of a VM implementation which is itself just as complex.
A nice example is the fact that Java (and other languages) have special support for anonymous functions using the 'lambda' keyword, inspired by Lisp. However, in Lisp lambda really doesn't mean much at all, it's just the normal way to declare a function since all functions can be used and passed around as data, define or defun are typically macros which declare a function and bind it to a symbol in the current environment.
Complexity built upon complexity soon leads to nothing but a complex pile of rubble.
its not just that its consistent, autistic dedication to consistency at all costs can lead to gross complexity.
its that the features you choose work together to make everything youd do with them uncomplicated, while being conceptually simple and actually so in reality themselves, too.
"given a few carefully implemented abstractions it is possible to produce a small operating system that provides support for the largest systems on a variety of architectures and networks."
specifically talking about namespaces in plan9, but it gets at what im saying.
to put that better, its about forming features in such a way that you need as few as possible.
Simplicity in lisp is about much more than what you've just mention. Since the language has a uses s-expressions, you can trivially "extend" the language in a natural and fluid way by simply binding new functions and (when changing control flow is desired) creating macros (which work very well since they're working on the AST).
This all facilitates language oriented design where you create a new language in which to express the solution to the problem you're trying to solve. When you do this, your solution is expressed in a concise straight forward language that fits the solution like a glove.
made by jews - made for jews.
I'm just waiting for suckless to make a decent browser
If you don't like CLisp, use any other Lisp implementation you fucking brainlet.
Use qutebrowser. In the CY+2 it's about as good as a browser gets.
That's called netsurf.
I'll switch to it when Gentoo gets its shit together, but it has nothing to this thread. At all.
FWIW Gentoo just (finally!) managed to update qutebrowser: gitweb.gentoo.org
4/10 made me smirk.
We still need to wait for qt-5.9, pyqt-5.9 and python-3.5. Gentoo can be hell sometimes.
I thought you can install stuff which isn't marked as stable yet selectively?
But yeah, stuff is more outdated than in Debian Stable...
Void.
Posting this from qutebrowser with a more or less up to date QTWebEngine backend.
Plus no systemPottering.
Wait can't Gentoo install from source?
I thought you guys could just download a tarball.
Any linux can do that. It just is generally a major pain in the ass.
Yes. You can. You set it in package.accept_keywords. I have python 3.5 on my gentoo install.
Doesn't Gentoo handle keeping track of source installs. Whereas nearly all other distros only handle packages.
I thought the point of Gentoo was you could install whatever you wanted because you were building it all from source.
I like the idea of working towards a permanent unchanging codebase. With minimal updates for security, and compatibility. There seems to be a pervasive philosophy in programming that there must be constant updates, and features added to everything.
Urbit has an interesting blog post about it "Toward a frozen operating system"
It's mostly the agile cancer. With proper software development you figure out what you're trying to make before you go to make it. Amongst other things, this allows you to know when you're finished. The other big contributor to the problem is using shit tier bug-prone languages/tools.
interesting
it's the same as Arch and the AUR. You can write your own ebuilds if you really want. It's more of a port of the BSD ports tree style of package management into Linux.
"""Programmers""" try to write software that applies to everyone. They miss the point that they should write software within mind of different user needs. Not all users need programs to suck their dicks, because not all users have dicks.
Portage and ebuilds are a real waste of time. If anyone is thinking of installing gentoo: install it, emerge --sync the very first time, never emerge --sync again. The lesson is gentoo users should write their own ebuilds and run their own local repository.
With Qt 5.8, which was the most buggy QtWebEngine release so far :-/
...
is this a parody thread, because it took you sixty words to say 'keep it simple, stupid'
Are you gnew to GNU/Linux? These versions are in the main tree, but if you use them, it'll break some other shit. Stabilization work is needed.
t.gentoo babby
Still haven't finished their javascript engine so much of the web isn't usable and what's the point of browsing the web if you're just going to gimp yourself.
minimalism isn't an end in itself. it should be balanced with functionality. I could always make a more maintainable program than yours by making it do less things, so why not make all programs be hello-world or fizzbuzz? Those can be easily made bug-free, amirite?
en.wikipedia.org
It's like you have never programmed past introductory tutorials, or never had contact with the theory behind relational databases.
Static linking is the definition of unmaintainable. Was a library updated to patch a security hole?, good luck recompiling *all* binaries that depend on it.
Fundamental parts of the system like error handling, string processing, user interfaces, data storage, and so on should never be "minimal", they should just do their job. Why should everyone who wants to "do it right" have to make their own solution because the OS and library developers were too lazy and/or ignorant to do it themselves? Why should we use this bad software in the first place? Programs are bloated because the OS doesn't provide enough. By not doing it right one time, in the OS or a standard library, everyone else has to do it multiple times.
I think minimalism is only useful when the problem itself is minimal and can be solved with a minimal solution. By "doing it right", you can fit a whole GUI in the boot firmware and a whole office suite on a couple floppies, but that's not minimalism. Programs don't have to be minimal to be tiny. That's what makes the demoscene so impressive. Their programs are small, but not minimal. The Turbo Pascal compiler, written in assembly, was about 40 KB. Microsoft BASIC was even smaller, and that wasn't minimal. It included graphics and sound.
Anything that can be that simple to do what it needs to should be. cat is a good example. fizzbuzz tier cat > non-trivial cat
That post is a complete non-argument, why exactly are the features from the other guys program even desireable? Why shouldnt they be done as seperate progams that combine together, or by combining already existing things?
Noone thinks minimalism is a goal in and of itself any more than people think complexity is a goal in and of itself. People like minimalism because they think that things are better when they're minimal, but that depends on how its done and what it is. If someone liked "featureful" software it wouldnt be because they just loved the complexity, but because they think its better, but they wouldnt immediately like anything that had more shit in it just because lol eksdee
Cutting a tumor off isnt "gimping yourself". Most every site worth visting without having to is fine in netsurf, itd just be shit having to use a seperate browser for the necessary but shit things.
Premature optimization is the root of all evil. Overly zealous application of the Unix "do one thing" mantra can lead to a turing tarpit for the end user of the software.
It also leads to not seeing the big picture and formulating everything based on the string output of specific commands.
Really jogs the noggin.
I believe in this concept in all aspects of life. If you keep dividing things you end up having an atom. They're really useful objects.
Minimalism means different things to different people. Are they talking about whole systems, individual programs, libraries, instructions, or what? At the right level of abstraction, anything can be called minimalist. Unicode is more minimalist than needing separate character sets and font renderers for each language it supports.
If you have two command shells and one includes the commands built-in and the other uses external programs, which one is more minimal? The shell with built-in commands gets to share parts of the source and binary for all of them, keeping size and complexity down. The smaller shell needs more external programs and if you added them all up it would be bigger.
People tend to use it to mean either 'simplicity'(of what it 'really is', ie design and code), 'binary size', or 'anything less bloated than windows/macos/gnome-kde-etc', and I can never really tell exactly which.
My interpretation of unix minimalism is that you want programs wich are as simple(Design, code) as possible that can be used by themselves or combined with others to do many possible things in a simple(in terms of how you used or combined the program/s_) way.
the better you do this, the simpler the overall use of it is too, demonstrating how the concept of "user experience", atomized into a term spoken about by itself and used as justification for shitting up the design is completely fucking backwards.
minimal software can be badly designed, when the designers dont consider how it fits in to the rest of the system. I like a lot of suckless stuff though, I dont think they do that too often.