zygo_histo_morpheus @ zygo_histo_morpheus @programming.dev

Posts

1

Comments

176

Joined

2 yr. ago

As a terminal fan, my main reasons for preferring them over a gui (for some tasks) are:

1. It's faster to type than to navigate menus
2. If I don't know where something is and can't guess it instantly, it's usually faster to search for it in a man page than randomly digging through gui menus
3. You can combine commands with each other with pipes or $()
4. You can search through your command history to find previous commands
5. You can write scripts and aliases to automate common tasks
6. The terminal requires less context switching. Typing ten commands is less mentally taxing than opening ten different guis

The barrier for entry is higher with terminals but unless you need visual feedback (e.g. because you're editing an image) it's easier and faster for both common and rare tasks.

I am not going to install linux due to my program requirements for work not having official support

Fair!

That’s fine but it’s weird to expect widespread use when convenience is considered a waste

I don't think it's just about saving dev time (though that is also a big part of it) but also that many people, such as myself as well as most people who make open source programs, genuinely think that the terminal is more convenient than a gui. This is a niche position though and as you say an obstacle to mainstream use.

I do wonder how far away we are from a linux for casual use that you can use without the terminal, since there are already a couple of gui tools for common tasks. In my mind, the average casual user mostly uses maybe their browser, spotify, office products, steam (which may require installing a different graphic card driver, which isn't very user friendly), some messaging platform and photoshop or something. Honestly this shouldn't be that hard to do with just gui tools, modulo the graphic card drivers. Comparability with various programs is a problem though, you might have to settle for libre office and gimp instead of ms office and photoshop for example.

I work with programming so my experience of linux is obviously a bit different than an artist trying out linux for the first time. What are things you remember having to use the command line for? Installing packages is the most obvious one but there are graphical front ends for many package manager. Editing config files maybe? I wonder if part of the problem is that most tutorials when you google explain how to do things on the command line rather than how to do it through a gui.

While this isn't the only reason, I think part of it is that linux, windows and osx are good at different things. If you move from windows and try to install your favorite windows programs, you're probably going to have an experience that's worse than the windows one. If you move from linux to windows the experience is much worse in that regard. To really see the value of linux you have to get used to having e.g. a tiling window manager or a package manager (tbf, chocolatey on windows is ok). But when you're just getting into it, linux just feels weird and convoluted in comparison.

As a fan of functional programing, it is validating in a way to see the more functional approach being faster. The reason for not wanting to mutate is that it's easier to reason about pure code. Usually this is for the programmers benefit, but it can be good for the compiler too as we see here. Obviously there are many cases where it is faster to mutate (many data structures can benefit from mutation) but there is this general assumption that fp is slower which isn't exactly true either.

A lot of focus is on rusts memory management, thread safety and lack of surprise undefined behavious, which is all good. The thing that I miss the most about rust at my C++ $DAYJOB though, is that it has better tools for abstractions (ADTs with traits instead of classes), the error handling and that it has a more well put-together standard library. Rust is a very solid language in trems of expressiveness and having usefull abstractions, but it does require you to juggle memory and error management more which is sometimes good (languages with try catch throw often tend to have code that's just handles the happy path ime) but does require more dev time upfront.

Wow that is extremely irrelevant

And this is why you don’t trust tankies

What are you referring to here?

I think most people don't go to a platform because of how it is implemented but rather what content and what communities already exist there.

People on the fediverse now are using it not because of the content already here but more because of the promise of a platform designed in a different way that will ultimately enable a better internet experience. I think part of the reason why it's mostly techy people is that the sales pitch is complicated enough that mostly techy people will be able to appreciate it. Not to say that non-techy people are too stupid to get it, it's just that it requires a kind of abstract thinking that techy people are more used to.

It feels like lemmy seems to have a sense of nostalgia for old reddit in some ways, so I imagine that a lot of people on here where also on reddit maybe 5-15 years ago, which means that you are probably going to be older than the average reditor as well as techy. Can't speak for mastodon, honestly I find the culture on most instances I've seen to be kinda weird and unappealing but yes it seems to be older techy people as well there.

IIRC, it started of as a joke and an explicit nazi reference to make fun of PC gaming fanboys, and then they just embraced it without understanding the context?

Another important difference is that reddit concepts map better onto lemmy than twitter onto mastodon. Additionally, one important aspect of twitter is the proximity to journalists, celebrities and politicians. Reddit doesn't really have that (except for /r/iama).

I find that inheritance isn't that useful when it comes to helping me reason about programs, which is more important to me than avoiding code duplication. The ability to create subclasses can be convenient for adding new code but the same extensibility also means that I have to consider all potential future uses of a class when I'm using one. It's easy to make assumptions when writing code that uses a class than can then be broken by future subclasses. You can try to mitigate this by writing clear invariants in advance and updating them when you find that you need to make more assumptions, but then this means that you have to give up the flexibility of inheritance.

Hmm no, I can't say that I've ever writen code like that. For one, it might be better to use loop :: (a -> Either a b) -> a -> b instead so that you don't have to sort through the result afterwards with find.

I'm not sure exactly what you're trying to do, but maybe using the State monad could be a good idea? If a is an object with fields that you want to be able to read and update that sounds a bit like what you might want to use State for. This can be combined with maybe something from the loop section of Control.Monad.Extra to make the intention of the code a bit clearer.

If performance is critical you might be better of using a different language anyway (Haskell performance is okay but not amazing) but otherwise I don't think that this is really gonna slow down your code unacceptably much.

Monad transformers are monads that take another monad as a type argument and are for when you want to have severtal kinds of Monads at the same time. If you want to be able to throw errors, have state and perform IO you can use the type ExceptT ErrorType StateT StateType IO a for example.

IMO the biggest strengths of Haskell are that you can create very powerfull abstractions and that you have a greater ability to reason about your code. This is still true to some extent even if you have a lot of imperative-like State or IO code, so it can still valuable to write in Haskell. Of course, it's still good to avoid this when possible, and take it as a sign to rethink your design.

The main reasons why I don't program more in Haskell are that it can be un-ergonomic to write certain kinds of code (that use IO a lot for example), that it can be hard to reason about space leaks and primarily that it's basically pointless to convince anyone else at $DAYJOB that writing something in Haskell is a good idea (for not entierly bad reasons, it's good to have code that's maintainable by multiple people)

I use Either (for error handling) and State (for shared state in the program) fairly often, sometimes both at once with IO in a monad transformer stack. Having pure code is of course the best but error handling at least tends to sneak in through the program

A monad isn't "a thing", it's a common interface shared by several different types that have a common mathematical structure that happens to be useful for structuring programs around. I think that's why it's so confusing to people, other programming languages tend to not have as abstract abstractions front and center.

only good thing about javascript is that it forces people to put the squiggly brackets on the right

I sometimes play around with Helix and I almost always have a good time, but there are too many vim features that I have integrated in my workflow that there isn't any good equivalent to in Helix. I use ex commands, the quickfix list, snippets, the fugitive plugin and just little custom commands and mappings that I've accumulated. I don't see myself switching to any editor full time that doesn't have a replacement for most of these features, but Helix is very nice and fun to use occasionally.