People like you are rare. It seems like with the ever increasing scale of mechanisation, we are seeing an increasing detachment from everything that makes us human.

Today a highly-experienced CEO in the technology sector told me he thinks one of the reasons for which a lot of this is happening is, as he put it: "People can be victims for anything these days. HR has to be very careful about how they check and filter people. Companies can be sued for just-about anything. Even confirming someone graduated from university can be discriminatory or problematic from an equity perspective".

Not sure what to think.

I fail to understand this line of thinking. How often are you restarting the browser that this makes any significant difference in your productivity?

It was significant enough for me to notice. And it's about the subject. Doesn't matter how many times a day I launch my main browser.

The author says to "work on boring problems" but I think what it really boils down to is knowing why you are solving a problem. Just picking a problem depending on how hard or easy it seems is a research mindset. Of course it doesn't make sense to apply that same mindset to more business-oriented problems (unless the business itself is research)!

Both research and business related problems are interesting. You don't have to swing between two extremes every time you have an epiphany.

Just my two cents. Nice article!

With low hanging fruit you get baskets full in no time.

What didn't you like about it?

Typically I use vim+tmux, so I should have also probably set up some additional extension to add a tmux-like panel change shortcut, so I could save-and-run like I normally would on the command line.

It also didn’t seem to handle Jupyter cells well. I forget exactly, but sometimes it would jump from one panel to another instead I think?

There is always something once in a while that steals the focus from the text and forces you to click back.

That looks very hacky. Is there a reason for this limitation that you've found makes sense?

That doesn't look hacky, it looks written by someone with 3 months of programming experience. I would personally avoid relying on an editor written by programming newbies.

Something something logical fallacy [1].

[1] https://en.m.wikipedia.org/wiki/Ad_hominem

I always find it interesting how hostile some (many?) peoples take on source code can be. Rather than give benefit of doubt, they attack. But even if it is some stupid code, some late-night, tired-brain, foggy-flu-delirium .. so what?

I get it, don't run a project if you see some bad code and question the quality of the project. Quality that very well could, and likely will, impact you. From bugs to performance. Don't run it, of course. But to attack it, seemingly with such personal zeal.. can people not improve?

I dunno, i guess i just don't feel the software we write on average is actually good. We make compromises and mistakes constantly. Our house is the purist of glass and many of us are just chucking stones like there's no tomorrow.

Lets take a step back. Breathe. Point out flaws by all means, but maybe reduce the often apparent revelry in someone else's mistake.

... sorry for the high horse rant. I'm nursing coffee and i've just seen it a lot with Lemmy/Kbin recently. Also this isn't pointed at anyone here directly.. just a pattern i feel i frequently see.

What? No. An ad hominem is "I think your argument is wrong because your face is stupid". "This is bad software because it looks like it's made by amateurs" isn't attacking their character, it's attacking their ability to write good software, which is highly relevant.

"The code is bad because it was written by a novice dev" sounds like an ad hominem attack to me (as opposed to "the code is bad because of X attribute of the code itself").

It looks to me like it was written by someone quite intentionally to avoid allocations in the common case, and they punted on handling less common cases to later.

Maybe it's done like that for performance reasons?

I'm struggling to see how that function could be a bottleneck, and if it were, memoization would easily get rid of it without the ridiculous limitation.

It could be better for sure, but that function has been there for almost as long as the project has been open-source if I recall correctly. It probably hasn't been touched since then because it wasn't a high priority.

It seems relatively easy to send a PR to allow supporting any number of spaces (or at least increase the upper limit to 16).

> allow supporting any number of spaces

As long as nothing is depending on 'static lifetime further down the line. (EDIT: ignore and see below)

> (or at least increase the upper limit to 16)

That should be doable for sure. Even something like (I'm not a rust developer, just have a passing familiarity, so my syntax may be off):

    IndentStyle::Spaces(n) if 0 < n && n <= 16 => &"                "[0..n as usize],

I think that would condense it all down into one line, rather than having special cases for all of 1 through 16.

EDIT: after toying around in the rust playground, I think the following will support any indent level (within the bounds of the u8 type).

At the top level:

    static INDENTS: [u8: 256] = [' '; 256];

And then in the as_str function:

    IndentStyle::Spaces(n) => std::str::from_utf8(&INDENTS[0..n as usize]).unwrap()

The [0..n] slicing is what I was surprised to not see being done. As for what you're suggesting, using from_utf8 adds a overhead to check that you're giving it valid UTF-8 (this does not get optimized away). Dipping into unsafe can help here:

    const INDENTS: [u8; 256] = [b' '; 256];
    // ...
    IndentStyle::Spaces(n) => unsafe { std::str::from_utf8_unchecked(&INDENTS[0..n as usize]) },

But I would consider having INDENTS be a &str to get the cheap slicing without needing unsafe. Since putting in a string literal of 256 spaces is nasty I would use the const_format crate to generate the constant:

    const INDENTS: &str = str_repeat!(" ", 256);

Closing the loop, this is now implemented and on main, thanks to msdrigg: https://github.com/helix-editor/helix/pull/7429

This makes me happy, thanks for sharing

Nice!

I'm not sure I could justify bringing in a package for a one-liner, just to avoid an "unsafe" which could be easily documented in a comment as actually safe.

Its doing that to get a static str (no allocations). I assume it is for performance reasons, but I can’t speak to whether it’s actually a significant impact.

The real flaw here in my mind is the lack of comments :D

If this was a carefully observed decision, one that is prone to looking odd, it deserves an explanation for future selves to not chase the rabbit of understanding.

A sane implementation would be for the fallback to construct a string containing the desired number of spaces on the fly and memoize. Unfortunately, this is written in Rust, and the language makes it super awkward to implement caching patterns transparently as they involve passing around references to mutable state.

There’s a dozen ways to solve this… from arc to ref cell, the language provides all sorts of methods to solve this.

You can unify the purist (1) and the ex-nix (3) into a single label: the emotionally attached.

I'm glad to see this sentiment more vocally expressed lately. It's certainly nothing that hasn't been said before, but I think that reality hasn't caught up to the frustrations faced by knowledge workers. Imagine training as a musician, learning the fundamentals, and mastering your craft, only to be used as a glorified set of fingers for playing chords.

This discussion tends to get muddled whenever I bring it up with others because it's seen as an inability to be a team player, or that I'm just trying to daydream instead of "get things done", but my retort is always that you can't know what to get done until you have done the day-dreaming. We need it back.

I'm torn about this one. I personally (like most devs) am hyper-productive when I am focused on a problem that I'm interested in solving. But that often does not align with whatever is the most important for the company or the team or whatever is highest on the priority list. So yeah, I'd enjoy my job more if I could just work on fixing something that seems broken to me.

On the flip side, I've worked with a lot of folks who are way more interested in just... writing... more... code. And I would never give those people free reign, because in about two months you'd have doubled the size of your codebase, your complexity, and the amount of people you need to manage it.

Yeah and then you end up with a manager who hacks out a complicated solution to problems we don't have and ships it to prod.

And obviously you can't tell them it's a terrible idea because they're your manager.

When you say emulation, do you mean at the logic gate level?

I would caution that it's a matter of priorities.

Currently, statistical/data-driven approaches work best, and that's what you will be expected to use whether you are building your own products, or working for an employer. Most people don't care about the GOFAI approaches anymore, seeing them as outmoded in all respects.

However, if you are curious and want to understand more of the history of approaches we have tried, and learn some really interesting algorithms along the way, I think studying the old school problems and their solutions can be both intellectually stimulating, and potentially increase your depth of understanding. After all, it's only once you've tried to solve a problem and failed miserably that you start to appreciate the depth of its complexity.

That depth of appreciation is sorely lacking in today's new cohorts, who are basically blinded by the incredibly convincing outputs of our cream-of-the-crop LLMs.

Great content! I wish I had this as a beginner. It would have saved me so much pain and time lost in the depths of google search results.

I remember having used QuickC and Turbo C in the IDE...downloading DJGPP. Whole different world. And I thought the people that had been using GCC on UNIX systems for years were absolute wizards with what they knew.