.DS_Store
Kissaki @ Kissaki @programming.dev Posts 27Comments 449Joined 2 yr. ago
Kissaki @ Kissaki @programming.dev
Posts
27
Comments
449
Joined
2 yr. ago
is exactly the same as programming case sensitivity
Me working on a case insensitive DB collation 🤡🚀🐱🏍
Reads (including the article links) like PostgreSQL supports json and Microsoft focuses on bson.
Depends on context, but
- Notepad++
- Visual Studio
- Visual Studio Code
- Double Commander "quick"-editor
- vim
- micro
- Firefox dev tools (console, dom edit)
When I write HTML, I don't use IDE features but accept them in Visual Studio.
I feel like it's very varied, but I'm not one to listen to metal or much rock. What I listen to changes from time to time.
I know the meme/prejudice of programmers listening to metal, and having long hair. I can't say I've ever felt like it was confirmed or justified. But it's not like I have that much exposure or insight to many either.
I'm not even sure I can list genres; I feel like it'd be too many and unspecific anyway. Chillhop, chillsynth, hip-hop, deep house, some pop, some german and japanese music, some chiptune, some classics of the last century; some are shared on https://soundcloud.com/kissaki
Nushell requires the programs to understand Nushell
My point was that with Nushell you don't need various command line tools like you do on bash or whatever. The question of whether those integrate well with Nushell doesn't even come up/is not central - although it does work with text just fine.
Nushell integrates very well into various data formats. It can handle text pipelines, but the advantage is in using structured data. You skip the entire text-pipelinie and work on structured data throughout, and don't need grep or awk or find or du or df or whatever cli tools you would use in a simpler/classic Linux shell.
More specifically answering your question of is it worth learning:
It's very interesting because it's very different to other shells.
- Structured data piping
- Native format transformations
- Think of Nu as a Compiled Language
- Data centered approach, more than command oriented
I always had an aversion to PowerShell syntax.
They're certainly both object shells. If you're already familiar with PowerShell, there's probably no reason or need to switch. I'm not familiar with PowerShell enough to identify where else they differ.
What do you mean by standard tools?
I feel like many if not most of what I would consider those are CLI tools other shells require because they themselves do not provide the functionality, whereas Nushell does.
What do you mean by PowerShell is designed with that in mind while Nushell isn't?
Yes, absolutely.
I've been using it for a while. I'm not super/very command-line centered, but I use it as my default shell on Windows. I did not set it up as a default shell on [my] Linux servers.
There was a bit of a time investment in making the switch, but I enjoy it a lot, and have used a few data querying and transformation functionalities that would have been much harder in other shells, requiring additional apps; I would have probably created custom C# CLI apps for them. Nushell allowed me to do those in the shell, directly, with native operations.
I've also set up a few very useful aliases and commands; Like dl for yt-dlp, and dl opus for downloading highest quality opus audio. Or ff for a few ffmpeg conversions.
I've also contributed a bit upstream. Maybe I'll get more into Rust and be able to contribute more, and to the core.
I have my setup/configuration and scripts in a public nushell-config repo.
Examples, of how I used it productively:
Download my paged Steam reviews because Steam doesn't provide GDPR compliant exports, transforming the awful shitty HTML with query web into structured data, and transforming it into Markdown files for my website.
At work; For a list of device IDs, create JSON command files, transform them into BSON via CLI call, en-mass. (We have multiple hundreds such devices. Configuration and firmware updates require mass-updates via individually addressed command files.)
Parse and analyze DMARC reports for reported issues, and to identify report format differences from different reporters.
I'm sure I did more things, but that's what came to mind right now.
Because of how much I love Nushell, I've created a community a little while ago, !nushell@programming.dev, if you're interested.
I accidentally deleted it lol.
Sounds like it did not win nor tie at the end.
How do you intend to present your GitHub portfolio to your potential employers? Nobody's going to do a full, in-depth, or even basic analysis of your repos unless maybe with automated tools or what GitHub itself provides.
Your CV and interview are much more important. Solutions [and projects] matter much more than details. Experience and that you can talk about your work or experience is much more important than technical details.
A hash table library doesn't sound like particularly noteworthy expertise. Adding a dependency and calling simple documented methods on it in a simple, standard behavior manner isn't noteworthy.
If you're implementing your own, I wonder if "simply" implies a non-noteworthy implementation, or in-depth exploration of hashing and storage indexing. The latter would be a different project though, putting your other on hold.
I don't see it making a difference for employers what you pick here specifically.
If you're interested in implementing one or learning about the technicalities of it go ahead. Otherwise use a library and continue with your project or other interests.
Disclaimer: I'm not in the recruiting space nor do I have that much or recent experience being interviewed/the broader companies hiring processes.
Yes, every unfamiliar language requires some learning. But I don't think the bash syntax is particularly approachable.
I searched and picked the first result, but this seems to present what I mean pretty well https://unix.stackexchange.com/questions/248164/bash-if-syntax-confusion which doesn't even include the alternative if parens https://stackoverflow.com/questions/12765340/difference-between-parentheses-and-brackets-in-bash-conditionals
I find other languages syntaxes much more approachable.
I also mentioned the magic variable expansion operators. https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
Most other languages are more expressive.
OP could pick any language and have the same problem. Except maybe Python, but even that strays into symbolic line noise once a project gets big enough.
Personally, I don't see python far off from bash. Decent for small scripts, bad for anything bigger. While not necessarily natively available, it's readily available and more portable (Windows), and has a rich library ecosystem.
Personally, I dislike the indent syntax. And the various tooling and complexities don't feel approachable or stable, and structuring not good.
But maybe that's me. Many people seem to enjoy or reach for python even for complex systems.
More structured and stable programming languages do not have these issues.
that assumes you don't write any SQL
I love the description as well. "One." "Zero."
I found the comments/answers about backwards compatibility of not defined booleans and negative true interesting and plausible.
What I first thought of was that TRUE and FALSE can be redefined, so it serves as ensurance that within the library consistent values are being used no matter what other libs and callers do with their typing and definitions.
Microsoft SQL Server has a bit type and you always use 0 and 1 and cast/convert them. No native bool type. It's a hassle.
In your own description you added a bunch of considerations, requirements of following specific practices, having specific knowledge, and a ton of environmental requirements.
For simple scripts or duck tape schedules all of that is fine. For anything else, I would be at least mindful if not skeptical of bash being a good tool for the job.
Bash is installed on all linux systems. I would not be very concerned about some dependencies like sqlite, if that is what you're using. But very concerned about others, like jq, which is an additional tool and requirement where you or others will eventually struggle with diffuse dependencies or managing a managed environment.
Even if you query sqlite or whatever tool with the command line query tool, you have to be aware that getting a value like that into bash means you lose a lot of typing and structure information. That's fine if you get only one or very few values. But I would have strong aversions when it goes beyond that.
You seem to be familiar with Bash syntax. But others may not be. It's not a simple syntax to get into and intuitively understand without mistakes. There's too many alternatives of if-ing and comparing values. It ends up as magic. In your example, if you read code, you may guess that :- means fallback, but it's not necessarily obvious. And certainly not other magic flags and operators.
As an anecdote, I guess the most complex thing I have done with Bash was scripting a deployment and starting test-runs onto a distributed system (and I think collecting results? I don't remember). Bash was available and copying and starting processes via ssh was simple and robust enough. Notably, the scope and env requirements were very limited.
Case insensitive handling protects end-users from doing "bad" things and confusion.