spsesk117's comments

What got you excited about this field in the first place? Try and get back in touch with that maybe.

Try exploring another side of the field, like systems programming, or a language like Haskell. Maybe play around with Python ML libraries.

I realize this doesn't really answer your question, but for me personally, passion for messing around with computers has been a constant in my life.

Other things come and go, but there is always something interesting to be done with computers. If one area starts feeling boring or uninteresting, there is a staggering fractcal of interesting problem areas in computing, that seem to spiral out infinitely.

If Web/JS/React/etc feels boring and uninteresting, maybe look at some other space in that fractal.

This is excellent advice. I just wanted to add, don't underestimate the haircut. I've used this strategy several times to make clear dividing lines in between various periods of my life. For me creates a strangely tangible distinction between what are ultimately arbitrary points from the outside looking in.

I use regex101.com a lot for writing complex regex.

It provides a very quick feedback loop for thinking about how I want to struct regex and be performant/safe in my implementation.

I'm interested in whether the technologists employed by this company will be able to pull it off. I'm by no means an expert, but my understanding is that in order to support a large scale social network, with typical social network features, the implementer needs to have some pretty robust solutions for a large breadth of different problems/design considerations.

On the one hand, a lot of the technology used (in what I imagine a typical high level social network design would be) is readily available and well understood by actors in the job market (I think?). On the other, assuming there is a wide audience who would be interested in immediately using this product, I wonder if they'll be able to pull it off without being plagued by D(D)oS attacks, targeted hacks, etc etc.

Note: To be clear I'm just riffing on the technical challenges of this undertaking (making a new social network) and not trying to get into a political/ideological argument.

I definitely agree with the line of thinking posited, what I'm less clear on is what the discrete implementation of these ideas looks like.

I worked at a company once with huge monolith system, mainly revolving around a relational database. We tried for years to break out of this, and if my understanding is correct this organization is still on this monolith today. There were a number of challenges, and we tried a number of different solutions (NoSQL models/object stores/etc), but it felt like there were base level assumptions about the availability of data in the core application that felt impossible to address without a full scale rewrite and reevaluation of all previous assumptions.

Perhaps I've answered my own question here -- it just needed to be completely redesigned from the ground up. Short of doing that however, would anyone care to provide high level insight on how they'd break down this problem, and what technology they might use to address it?

Thanks for the link, I'll definitely check it out! What actually piqued my interest was the surface impression of something like a Lispier Perl/Python.

Oh awesome, thanks for sharing, I have already been looking at some community examples on there!

Wow! Some really cool projects, thanks for sharing, I'll definitely check out Freja later this evening!

Thanks so much for the info and commentary!

This looks really interesting, going to check this out later today. Anyone using Janet for anything that would care to comment on their experience?

Wow. Thanks for all of this info and for your very interesting perspective. I have a passing familiarity from HN and elsewhere with some of these new shells, but am not well informed enough to really comment on their usefulness/etc. With that said, you've given an excellent primer in your comment -- thanks very much!

A few things you said stuck out to me:

> For me, the great thing about a shell language is that it's a programming language I get to _live_ in.

> The idea with these new shells is to try to find a way to enhance the programming capabilities of shells without making them any less convenient for navigating the filesystem and performing simple tasks with external programs.

Generally, I agree, and I actually use `eshell` in Emacs for this kind of thing a lot. Being in a pseudo-shell LISP layer allows me to get arbitrarily manipulate text I get back from the command line with elisp and allows for some really flexible workflows. With that said, eshell does of course have many trade offs and limitations, which I won't get into here.

I think where these things always fall apart for me though is in the Elvish shell example you provided. To me, that is not functionally better than using Bash and jq, it's just different. Maybe it's better, I'm not sure, but my first impression is that it's neither more concise or more readable, it's just different syntax.

I think there is a credible argument to be made for "batteries included" type shells, with something like native json parsing, but at what point does it then tip into being like Powershell or Python, where once again you've gotten away from the native/accessible experience because you need to support `n` kinds of structured data inputs/outputs on `n` platforms?

As I was reading your comment, the thought that occurred to me was: Why not just make a python library that can be loaded into the REPL that abstracts over some of the more cumbersome parts of interacting with the OS/filesystem in a shell like way? That seems to be the best of both worlds, and from what I gather that seems like what Rush and Xonsh are doing? I need to look into them further.

> Developers and sysadmins want to be able to pull in structured data from whatever source and query it and manipulate it right there inside their shells. But each format gets its own utilities for that kind of querying and manipulation, and they don't necessarily know how to talk to each other.

I agree re: structured data manipulation, but I think the solution that has naturally emerged exists for a reason. I can use pipes, and programs like jq to push and pull data into and out of whatever format I need, and each layer of that ecosystem can be maintained in parallel, adapting to changes in the overall landscape. In a sentence, it's the core of the Unix philosophy. One thing and one thing well and all that.

I dunno. I've thought a lot about it while typing this comment out. I think it sounds like I'm disagreeing with you, but I'm not. I don't even really think we're debating. I think these new ideas for shells are good things, and I will definitely investigate them more and see if they make my life easier. I just can't seem to shake this feeling that we can't have our cake and eat it too. Maybe I'm looking at it the wrong way though.

Maybe in 20 years time shells like Oil and Elvish will be the norm, and we'll be complaining about how they don't handle quantum data structures well without lots of pipes and fd's :D

Either way, this has been a very interesting digression. Thanks again for your thoughtful comment and insight.

Thanks for the reply.

I do use magit, daily, and I really enjoy it. I think what I don't understand about the OP's point is that, why is that the shells problem? Tar is a utility that works great, and is typically pretty easy to use on the CLI. If however, I don't particularly like it, or would rather use a GUI that's totally understandable.

The OP could even implement one in elisp for emacs.

I guess my thought is that, why is the burden on the author of this magical new shell to write a piece of software that can GUIfy tar, than the user of tar who doesn't like it's ergonomics? Maybe that's not what the author is saying, but to me it just seems like something not really related to the shell, or a discussion on shells.

If you like using GUIs, find a GUI for tar, or write one. I don't say that to be flippant, but more to reiterate my misunderstanding of how this relates to a discussion on shells.

Thanks for the reply. I think you make a fair point regarding shells as programming languages.

I guess what I meant regarding missing the point is that, from my perspective, the shell was and is a basic way to interface with your computer system. Basic is a keyword here -- there are other ways to do it (native programs, syscalls, etc), but as a basic interface into operating and running programs on a computer, I think most shells do a pretty good job.

As I said in my original comment, maybe they could be doing a better job and I'm just not seeing it, but this is in essence my thought. If Bash is too messy, there are a wealth of other highly portable and maintainable languages to do cross platform scripting on. Python comes to mind, as does Rust, and even older things such as Perl.

I'm rambling a bit, I'm not sure my thoughts on the matter are that coherent. I guess in summation I'd just say, I think it's fine if shells are shells, and if they can't be stretched to accommodate hyper specific workflows and patterns, maybe consider writing it another language? Do shells languages have to be as capable as general purpose programming languages, and if so, why?

Sometimes it seems like I'm the only person that doesn't feel like they need "a better shell". This topic comes up a lot on HN.

Maybe if a better shell came along I'd be surprised, not knowing what I was missing. Perhaps I'm just in the dark or not imaginative enough to conceive of what one would look like.

With that said, whenever the discussion comes up, it seems to revolve around user specific workflow cases and "do what I want you to do, not what I tell you to do" design patterns, that would (from my perspective at least) feel hard to get right for everyone. As a result, we have lots of different shells now that make different trade offs and take different design approaches. That's great, right?

I don't know -- I'm rambling I suppose, I just don't ever really feel like Bash (or fish/zsh/whatever) is holding me back or making my work more difficult than it needs to be. We can argue about the esotericisms of shell scripting and how it's silly to emulate old terminal escape sequences in virtual terminals, but I feel like it misses the point.

I don't know, I'm certainly willing to change my mind here, it's just that for all of the problems I have day to day in sysadmin/programming job functions, the shell is the least of my worries most of the time.

I may be the odd one out here, but I wasn't that "wow'd" by the trailer. I loved the cinematography of the original films, that seemed to embrace the dystopic vision of a world permanently trapped on the verge of Y2K. I also found myself disappointed to not see Huge Weaving or Lawrence Fishburn in the trailer, perhaps they weren't available?

Either way I'm looking forward to the film and seeing how the setting fares in a modern context, but was just surprised by how different the trailer felt tonally to the originals.

I love playing Factorio, but it's moments like above when it starts to stop feeling like a game and it starts to feel like refactoring code at work.

Wow this looks great, didn't know about this tool. Thanks for the recommendation!

+1. `strace` can be very helpful here, to see if a process is stuck waiting on something or whether it's just zooming along with no output.

The last software team I was on used Zola for a lot of our internal documentation publishing. It worked great and we were really happy with it!