I would like to see improvements in the speed of feedback - particularly from language servers - but the value of those 'basic' guarantees is more than worth the current cost. Unexpected side effects are responsible for almost every trip I've taken with a debugger in any large Java or C++ project I've ever worked on.
I can remember about 20 years ago a colleague getting quite frustrated that a bug he had been looking at for quite a long time came down to someone doing something bizarre in an overloaded assignment operator in C++.
Complexity is mostly exponentiellt worse in the unknowns and you can not graph what you already know.
The point in the article is that when we read code we need another visualization to change or mental model. I can scan code and find most bugs fast, but when you are stuck a complexity by row/column sure would be handy to find overloaded assignments.
Nushell is quite nice. Tables are nice to work with and look at, and the cross-platform support is top notch. It feels like what Powershell would have been, had it been designed by people who have actually used a command-line before. The main issues I have are bugs. Most recently, I find that it can't properly handle files with square brackets in the name, which isn't really all that uncommon.
I wouldn't recommend it for day-to-day, production usage just yet, but definitely worth keeping an eye on if you're not a huge fan of the typical stringly-typed shells.
One advantage or Powershell though is that in it you can put something into the pipeline from anywhere in your code, even within imperative code like in the middle a loop, just by mentioning a bare value at nearly any spot. And traditional shells are the same way (though they only support byte streams output), where you can send stuff to stdout/err at any point.
But in nu, it's more like you're just dealing with collections as in most programming languages. If your collection isn't amenable to being generated by a simple expression like a map or fold, then you have to create a collection, prep the collection to be what you want it to be, then you return it.
In that sense it's really different from both Powershell and traditional shells, and more like just using a traditional programming language. So in Nu I miss being able to just "yield" a value from anywhere without staging into a temporary collection first.
> if your collection isn't amenable to being generated by a simple expression like a map or fold, then you have to create a collection, prep the collection to be what you want it to be, then you return it.
This release added the ability to "yield" values via a generator fashion. It's called `unfold`, but will be renamed to `generate` in the next release: https://www.nushell.sh/commands/docs/unfold.html.
> if you're not a huge fan of the typical stringly-typed shells.
What aspect of the other shells qualify them as 'stringly-typed'? Shells seem quite happy piping raw binary data, and there are commands that can deal with binary streams (like wc). The shell also doesn't seem to do anything with the data, unless specifically asked to do so (eval, backticks, etc). (genuinely ignorant and curious).
"Stringly typed" is usually used as a derogatory term for the alternative to strong typing, which often looks like manipulating raw strings when higher level code would have either better error handling or less boilerplate.
In this sense, dealing with raw bytes is worse.
There is no reason we can't use CLIs that provide higher level operations, but there's just not enough standardization.
I think they are refering to the fact that variables are always strings. You can write stuff like i=0;i=$(( i + 1 ) which looks like you are dealing with integers, but in reality, the shell only deals with strings.
You know those status bars in dwm and similar window managers? Those are usually generated from a pipeline outputting a line every few seconds or so.
To make it display something as trivial as the frequency of your CPU, the network speed, etc, you have to randomly parse some ad-hoc, program-dependent format that may be locale-dependent! If these could speak a proper language, one could just take the value of this field/object/element and be done with it.
Where have you seen a service describing something posted less than 12 hours ago as being "posted last week" rather than "posted yesterday"/"posted today"?
The point is that both are technically correct. At 12:00am on January 1 that happens to fall on a Monday something that occurred 1 second ago can be considered to have taken place: last week (depending on when you consider weeks to start/end), last month, last year, yesterday, etc.
Sure, they’re both technically correct, but that wasn’t the question. The question was
> Where have you seen a service describing something posted less than 12 hours ago as being "posted last week" rather than "posted yesterday"/"posted today"?
Every single time display library I have seen will do as the poster explained, and show more granular information the closer it is (generally starting at “X seconds ago”). Your technicality is certainly true, but a strawman.
Actually, it's that question that is the straw man. jstanley's point is that to the reader "posted last week" could mean almost no time at all ago. It's not about the display library choosing to label recent things as this. It's about humans reading such a label and not receiving the intended information, because humans don't cut off what they understand "last week" to mean at some arbitrary 12-hours-ago mark.
Except they do get the intended information. The label doesn’t exist in a vacuum; the user would have seen other examples showing the specificity at intervals other than “last week” which sensitizes them to the cutoff points.
This is literally a non-problem. If a library behaved in the way the parent commenter makes them seem like, then, sure, they have a point. But they don’t. Something that occurred a second ago would say “a second ago”. Something that occurred 5 minutes and 43 seconds ago would say “6 minutes ago”, etc. There is no library in the world which takes a timestamp a second ago and outputs “a week ago” and pretending like there is is, literally, a strawman.
Yeah, I've seen enough examples to know that no 2 websites implement the same logic so I shouldn't try to second-guess anything more than what the text literally says.
But… users don’t. Literally no library out there does what the parent commenter claims they could do. They all use sensible cutovers for relative dates.
The point is that if a user sees "last week" it's ambiguous. They DON'T KNOW that your libraries don't behave that way. All they see is "last week". Are you really not getting this?
I got quite annoyed with Neovim config at some point and tried out Kakoune, and ended up contributing some window splitting code to the main repo for Sway. I liked it quite a lot, but it's not built with Windows in mind so I ended up crawling back to Neovim. I'd be interested to hear of any Kakoune-like editors with better cross-platform support/design.
I'm mostly indifferent to it because it doesn't really harm readability, and it's not hard to know when to use it, but I can seem why it might be more strongly disliked. You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. It's also annoying if you find that you can refactor `func(T*)` to `func(T&)` and now you have to replace all `->`s with `.`s.
> You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement.
That's true but I think the bigger motivation is avoiding ambiguity than seeing when an indirection is happening. (You also can't see whether a method is virtual, i.e. indirecting via the vtable, from the call site.) In C++ references don't have any standalone methods or operators so there's no ambiguity from using methods via a reference just using a dot.
Is writing a simple CSS file and some HTML code really too much effort for a personal blog? Clicking around this site the only non-trivial things are the RSS feed and the paginated scrolling (which seems wholly unnecessary) on the homepage.
Anyone got other useful tools for debugging within (neo)vim? Just seamlessly putting down breakpoints, stepping through code execution, and getting a fully fledged debugging UI experience (a la Visual Studio or Remedy BG)? This is possibly the only thing I miss from developing on Windows, and it's a shame!
EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.
Shameless plug, but my development environment [1] may be close to what you're looking for. (There's pictures!)
A couple of details have changed since that post. The only one that you might care about is that I now have two tmux panes with gdb-dashboard. This is meant to use space better. One pane has all of the variables and nothing else. The other has everything else.
If you care about that, I'll tell you how to do it.
This is very cool! I created this small convenience script without the intent to customize `Termdebug` itself, leaving any preferences to the users. But I can see many nice things you added there that can combine very well with the two!
I'm surprised nvim-dap-ui wasn't mentioned yet. It still has less features than vimspector, but personally I prefer the nvim-dap ecosystem. No memory viewer is a bummer though.
So over the weekend I just went through a vim reworking for myself after discovering astronvim. I replaced my config with that one and installed nvim-dap-python through the user template, was able to attach and debug like I was using pycharm in a few hours of tweaking. I really like it
I did have a couple of plugins I cant really live without (ZoomWinTab and A.vim) so Im working on porting them to lua with the help of chatgpt. Really like the experience so far. Def worth checking out astronvim / nvchad
Finding astronvim through this comment and it looks like it may be time to move on from my regular vim to nvim. I like keeping things light so I'll probably just steal some plugins used there but the functionality looks like things I already have except with better UX. Thanks for sharing!
Came here to say pretty much the same thing, except I use the Neovim extension for VS Code. It uses Neovim as the backend and, from my experience, behaves a lot more like (Neo)Vim. It is much easier to setup, since debugging is handled by VS Code. The main drawback is VS Code does not work in a terminal, which is okay IMHO since you still have access to Neovim from the shell.
VSCode with the CodeLLDB or MS C/C++ extensions both usually work out of the box for debugging most compiled languages (so far I tried C/C++, Rust and Zig), but compared to proper Visual Studio it's very bare bones (especially the variable view panel).
Debugging in proper Visual Studio is by far the most pleasant experience I have ever had. Flame graphs, call graphs, memory and CPU utilisation graphs, straightforward call stacks and variable views... FOSS debugging utilities don't even come close to the debugging productivity on VS 2022.
I tried nvim-dap but it is somewhat clunky, unintuitive to use. Turn out that that using delve, gdb, pydb directly on the command line is fine, I don't really need editor integration.
termdebug (used by the tool linked in the topic) basically does this for anything you can debug in GDB. It's the tightest integration of debuggers and (neo)vim I have used.
There are also DAP-based integrations, which I have put the effort into using.
I think the official Zig website already does a good enough job at expressing what the the language has to offer, to the extent C devs can read a couple of pages and know whether or not they vibe with the language. The only thing it's missing is quoted praise from its users.
