31–40 of 72 posts
Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. T…
Unix was probably a great IDE by the standards of 1975, because literally every design decision about Unix was made based on the criterion of convenience for a 1970s programmer. Those decisions haven't aged well: fork() sucks, lack of completion-based async I/O sucks, ill-thought-out file, socket, and process APIs riddled with TOCTOU bugs suck, two-letter YAFIYGI commands suck, untyped pipes suck, and don't get me st…
"We should be expanding our horizons beyond what 1970s programmers found convenient …" You're right; we should be going back to the Lisp and Smalltalk machines of the 1980's. In that sense, I've found PowerShell to be something of a letdown. I was hoping for something that was an ergonomic abstraction over NT's primitives (or Linux's) and over the CLR's primitives at the same time, in much the same way that Lisp work…
Yes, the VSCode extension is the official ISE replacement.
What keeps VSCode around as the only Electron app I tolerate on my own computers, is the way Microsoft is pushing it for certain workloads.
Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. T…
What’s an example of a type of work where an IDE is more of a hindrance?
Earlier quoted context omitted.
"We should be expanding our horizons beyond what 1970s programmers found convenient …" You're right; we should be going back to the Lisp and Smalltalk machines of the 1980's. In that sense, I've found PowerShell to be something of a letdown. I was hoping for something that was an ergonomic abstraction over NT's primitives (or Linux's) and over the CLR's primitives at the same time, in much the same way that Lisp work…
It still find that PowerShell is the best we have from Smalltalk/Lisp Machine kind of ideas, even if the execution could be better. Yes, the VSCode extension is the official ISE replacement. What keeps VSCode around as the only Electron app I tolerate on my own computers, is the way Microsoft is pushing it for certain workloads.
The execution could be so, so much better.
I also think a lot about how some parts of PowerShell were inspired by CL on IBM i, and I find that I'm similarly frustrated when I can't just whack F4 in the middle of muddling through a command's parameters in order to be presented with a structured form interface for interactively filling out said parameters.
As much as I'd really like having Genera's hoverable and clickable command listener in PowerShell (like, imagine being able to do a `Get-ChildItem` and getting back an object display that allows you to left-click on an item to run `Get-Content` on it), I'd absolutely settle for the level of interactivity and hypertextuality offered by IBM i.
Unix is a DE, no I about it. This isn’t a ding against Unix, the integration provided by IDEs is great for some types of work, but it’s also more hindrance than help for other types of work. Also, the toolset that you get from a typical Unix environment is more or less language agnostic, so you have your tool toolset available to you even when you’re working on something obscure with poor dedicated tooling support. T…
What’s an example of a type of work where an IDE is more of a hindrance?
A lot of the time the error fix would boil down to some general rule so after I had fixed the error a bunch of times I would realise “ok when I see an error like this I need to change every ‘class’ in a template definition in this project into a ‘typename’ and every typedef of that class that looks like `typedef foo::::iterator iterator` to `typedef typename foo::::iterator iterator`[2]. Then once I realise the pattern I would write some find | perl -pie type thing to walk down the codebase from a certain point and fix all remaining instances of that particular error. These were typically more complex and subtle than the sort of autofixes/auto refactorings that I have seen available from IDEs although admittedly I’m sure the state of the art has improved beyond all recognition since then.
[1] Each of the errors were of the type described by Alexandrescu in “Debugging the error novel” in that they were probably about 10 pages of ascii template hell per error times tens of thousands of errors. So I actually made two copies of the output. One went unadulterated into my quickfix list and one went into a separate buffer that I ran a bunch of regexes over to get them into a state where I could understand the error message. Then I could work down the qf list one error at a time while also paring down my “working error file” in parallel.
[2] or something. It’s been a while.
Earlier quoted context omitted.
I agree that PowerShell is theoretically better since it can deal with structured data. But in practice, I could never get as efficient with it as I could with "the Unix way" (everything is a string). If I was writing a "production" script, then it's better. But when I'm just trying to quickly do something on the command line, the "everything is a string" approach is good enough.
The thing that we'd ideally want to happen, but will probably never will unless a mad person does it, would be to have something that wraps around a POSIX shell, and extends it in a sort of non-compatible way. Let's call this new tool $NEWSH. Larry Wall basically tried to do this with Perl but I guess his vision was too lax for such a pursuit, Perl tried to be everything, all at once. What I mean by this new approach…
Earlier quoted context omitted.
The thing that we'd ideally want to happen, but will probably never will unless a mad person does it, would be to have something that wraps around a POSIX shell, and extends it in a sort of non-compatible way. Let's call this new tool $NEWSH. Larry Wall basically tried to do this with Perl but I guess his vision was too lax for such a pursuit, Perl tried to be everything, all at once. What I mean by this new approach…
This resembles OSH/YSH, especially the v1/v2 layer things. http://www.oilshell.org/
Also, right now the project is a 1-man-show, for something of this magnitude to move fast enough it needs to become a full blown community project.
Oh, Oil also need to mature. Osh IMHO needs to be fully usable as interactive shell (I don't think it is), it needs to be packaged for everything.
It could be that Oil gets there but it's going to take a looong time. Oil itself was started in 2016, that was 7 years ago.
I'm keeping an eye on it for sure and hoping it succeeds.
Earlier quoted context omitted.
There are modern alternatives to many of the classic utils e.g. `fd` for find, with better CLI args and other improvements ripgrep for grep also comes to mind
I've totally switched to the newer, dev-orientated variants for my work. fd, sd, ag/rg, fzf, bat, xh/httpie all work how I'd expect them to and I don't need any archaic knowledge. Plus, fish's autocomplete does fill in blanks when I need it. I'd kind of consider tmux to be my ide rather than Unix. That's where I combine everything above (along with nvim), and it's as integrated as I need it to be.
Same for me. The "pipe streams of text" is so very powerful, I doubt anything can replace it.
Obviously, the "streams of text" need to make sense and have somewhat consistent structure - which most older tools don't really do - some mix tabs and spaces, others offer very little consistency between e.g. --verbose and normal. And modern ones often forego entirely. I hate it that docker pumps giant datastructures of JSON. And jq helps a lot there. Or ansible that has genormous blobs of json, mixed with yaml placed inside - I kid you not, cowsay - outputs. What I really want is just text, that I can minimize with flags and is delimited with spaces and newlines, so that a grep, cut, sed, sort, uniq, and, if all else fails, awk, can map/reduce me the data I need.
Simple text streams. If we can have that, we can bind everything togethe and "build" IDE features that no IDE can offer me without severe programming, plugins or other shenanigans.
Some things that I did this month, that I have no idea if VS code or Jetbrains can do:
- git log --format=format: --name-only | grep -v '^$' | sort | uniq -c | sort -nr | head -n 10 # Give me the 10 files with the highest churn - most often edited so potentially most problematic ones.
- - git log --reverse --pretty=format:"%H" | while read commit_sha; do git checkout "$commit_sha" -- . ./lint.sh 2>> linting.log done # Loop through all commits to record all linting violations so to find commits with exceptional amounts of linting violations.
People love their integrated IDEs. And I don’t want to spoil that happy feeling. But perhaps we should actually focus on making programming languages more human friendly so we do not need complicated tooling around them to make us feel productive.
OK. How?
We've once done a roundtable at our local developer meetup with this question. There were 20 people there. There were 20 different must-haves, requirements and ideas. We concluded that there's hardly a common denominator that isn't already present in most languages. And that all the other trade-offs in existing languages are warranted. Basically "it depends" :)