Unix as IDE
sanctum.geek.nz
sanctum.geek.nz
Which is exactly what a good tool should be.
When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place?
I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs.
And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.
Comparing unix to an IDE is like comparing a CSV file to a relational database. They both store data in tables, but you're not going to replace Postgres with grep, I hope, even though you could do very basic "queries" with grep. And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
- it's more natural for me to have a shell as a starting point and jump into an editor, rather than the other way around; it suits my workflow much better
- I can combine tools in a very convenient way, `:!ls /tmp` real quick from my vim, fuzzy search some json file hidden inside an atrocious directory structure, `:!git status -s` to see what I've changed, and so on
- IDEs are often language specific, which implies learning a new IDE for every language; I only need to know vim, which I use for every language I use but Java
- I'm more of a keyboard person rather than a mouse person, so terminal based tools that have intuitive keyboard bindings suit me better than IDEs which often require you to learn some really awkward key combinations to do things that I do very quickly in vim; just take a look at the cheatsheets for e.g. PyCharm/IntelliJ and you'll see what I mean (yes I know about the vim plugin for IntelliJ, but as an experienced vim user, it's not that great)
Java does seem to be the big exception in that 1) it's so overly verbose it almost requires an IDE to handle all of the boilerplate, 2) has enough static typing to allow deterministic refactoring, 3) is popular enough to support massive IDE engineering efforts.
I use IntelliJ for Java (and sometimes Scala), and Emacs for pretty much everything else.
I use intellij, it has intelligent support for Python, JavaScript (including node), SQL, HTML, CSS and PHP all working out the box with very little setup required, its the sheer integration of things.
I'm aware I could get close with emacs (except frankly its web modes suck) but I'd have to find all those bits myself, integrate them and hope that it wasn't fragile (you know updated fizz which was a dependency of too but bar uses a different version) and at the end I'd still have what I would regard as an inferior less cohesive tool.
There are no absolutes in matters of taste and that's what it is I think.
But also, you seem to believe that somehow communication between applications is somehow limited to pipes, which makes the comparison inapt.
Ignoring the category error (text format in a data file vs. server application + storage), please explain what your IDE does that cannot be communicated over a socket? Or dbus (oh god please don't, but the point stands)?
The question is whether there is actually good refactoring support on the UNIX command line that can compete directly with the likes of ReSharper or IntelliJ IDEA? I haven't seen anything coming close to that yet.
The fact is, there are actually a few implementations of Tetris and Breakout for Excel, and probably a few command line refactoring tools here and there. But just as no one is going to play a clunky Tetris game in Excel just for the novelty of it, I don't see myself using an inconvenient and limited command-line refactoring tool.
There's nothing stopping people from making it. IDEA Community is open source; I haven't looked at the code but I trust it can be decoupled and made into a separate utility.
If you want an example that's out there, Go has support for refactoring via tools like eg and gorename, and you can use them in an IDE, in a text editor or in a terminal with nothing more than GNU coreutils.
Right now you've got very basic refactoring tools for Go and JRefactor. Maybe a few other tools I don't know.
But in that case I don't see what's the point of running this tool from the CLI instead of configuring VIM/Emacs/{insert your favourite IDE or Editor} to run it on the function under your cursor with just a few keystrokes.
Well, the text stream lacks context of related entities. Let's say you're piping a single source file. The program you're piping to can certainly parse "import foobar", but how will it know what's in "foobar"? You could argue that it could parse foobar, but then it would need to recursively parse all of "foobar"'s dependencies too, and so on, which seems pretty inefficient if you're doing that a lot compared to a program keeping it in memory. Sure you could create files to cache that data, but at that point you're sort of waltzing into IDE territory anyway.
Besides, the "unix as an IDE" idea is based on using general purpose utilities, not specialized language specific ones, and those utilities make no strong assumptions about the input text.
That's the "understanding which language you're in" part comes in.
> You could argue that it could parse foobar, but then it would need to recursively parse all of "foobar"'s dependencies too, and so on, which seems pretty inefficient if you're doing that a lot compared to a program keeping it in memory. Sure you could create files to cache that data, but at that point you're sort of waltzing into IDE territory anyway.
The whole point is that "Unix is your IDE". If a specialized tool benefits from caching, it can use it. If more than one tool can share the cache, pass it as a parameter or pipe it in. If it speaks in a universal language (ideally, simple text) and it's a specialized tool, it's certainly following the Unix way.
> Besides, the "unix as an IDE" idea is based on using general purpose utilities, not specialized language specific ones, and those utilities make no strong assumptions about the input text.
That's another arbitrary line. It makes sense that awk or grep work with any type of text. It doesn't make sense that gcc or a tool like I just explained "makes no strong assumptions" about what's coming in.
... which standard unix utilities can't do. grep and awk can't reliably determine if a symbol is in a comment, and I can't tell it "rename symbol Foo, but only if it's used as a type identifier in my project".
The question isn't if unix could theoretically work as well as an IDE if you added a few thousand custom userland programs that understood language context. The question is if unix, out of the box right now, is competitive with a high end IDE. It's not, because it can't possibly understand your code.
Whether you like IDE's or not, the entire point of an IDE is that it's more than a dumb text editor because it understand what you're typing into it. If all your IDE offers is text editing functionality unix can do, then it's a bad IDE.
You need to download tools for your language just like you downloaded an IDE. The whole point of Unix is that you have specialized, composable tools for your purpose. Don't move the goalposts.
There isn't much demand for a similar tool for Java, but I have no doubt that a few months of effort could build one out of Eclipse. Its startup time probably wouldn't be great though. We already have eclim, that treats Eclipse as a daemon serving refactoring APIs to clients, to mitigate the configuration and startup problems.
What empirical evidence do you have for this?
At one point I looked very hard for good Java tools for Unix and/or Emacs, and found nothing. I imagine many others have done similar investigations and came up empty.
So I think its an open question whether Java refactoring tools for Unix don't exist because there is no demand, or whether there are engineering and productivity reasons why such tools work better as part of an IDE.
(I will say, though, the existence of similar command line tools for Go indicate similar tools might be possible for Java, also. Or maybe this is just due to Go being designed to be easy to parse?)
Personally I sometimes use eclimd in Eclipse from emacs. But it's a bit flakey. Usually I switch between an IDE and emacs depending on whether the current task is text-intensive or not.
IMO the entire language-specific modes thing in emacs is a collection of hacks (eg.: using regexes for highlighting! highlighting as a characteristic of the text!) and woefully under-architected; this is a much bigger problem than lack of any language-specific tool. Until elisp is replaced with a faster language with less dynamic scope by default (Scheme would be fine), I don't really see it improving.
"here is nothing about a text streams that prohibit tools from understanding whatever language you're writing in"
Well it might be true that you can deduce the language of some text stream but you need to make a big step in order to interpret it. You are talking about a compiler. Well a compiler takes a compilation unit, not some stream of text. To infer the semantics of a program the program needs to be present, not a part of it. Granted, a program might be broken up in independent modules, of course.
Make no mistake, a 'dumb' editor like sublimetext could understand a php symfony or a java struts project, if it would get the same analysis tools available in eclipse for example. It could be done, but it is massively more difficult than just running a syntax highlighter and running a rough tagger on some text. Its sad because I believe that fast, slim, editors that know as much as a massive IDE is the best of both worlds.
I have seen the code for eclipse -- there is so much dancing, it's a miracle that handling a key press eventually completes in some time.
In many IDE's it barely does, I've had issues with Eclipse, Visual Studio and IntelliJ at some point regarding input latency or the total freeze of the UI while it tries to handle magic with my input in the background.
Visual Studio has gotten progressively better since VS2010, especially with Roslyn; IntelliJ-based products have made strides since IDEA 13 where they really started to focus on input latency; Eclipse was never quite as bad, but it's a pain to use compared to VS or IntelliJ so it's irrelevant that it freezes 10% less in my eyes.
And at that point, it would be an IDE.
But I don't want to do the gluing. I want to refactor code, not to teach the tool how o understand the code.
Why do you need text editor when everything are just bytes?
This is only true because purpose-built IDEs embed the tooling to do so, but nothing prevents said tooling to be extracted, to be used in any way fit by any editor or non-editor tool. Case in point: gocode/gorename, C#'s Roslyn project.
> And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
The article is not about Unix as pipes of streamed data (which BTW can very well be binary) but Unix as individual tools that compose into a greater whole.
I often even use auto-completion in eclipse to get the hang of a library and explore its capabilities.
Saying UNIX is like an CSV compared to a relational database is, frankly, a hugely ignorant comment. The real differences between UNIX and an IDE is that the tools available in an IDE are discoverable where as UNIX requires a little more research and self assembly.
I frequently flitter between using a GUI IDE and just working entirely in the terminal - depending on my mood. Generally I find the terminal to be more productive, albeit I've have 30 years of experience in command line environments so I'm very much at home in a terminal. However the one thing I do find quicker in a GUI IDE is switching between different functions on different source files. Not that it's slow in the command line either, but that's the biggest inconvenience I have. So these days I generally use a GUI text editor for reading and writing the code and the command line for code refactoring, compiling, debugging, etc. It's a ratio that seems to work well for me.
For C# there is OmniSharp based on NRefactory, and also Microsoft's Roslyn. For C++ there are tools based on libclang. Rust has Racer. It would be nice if there were an interface an editor could implement which gave access to all of these languages.
A toolchain to handle any/most languages?
This is a simplistic view of the system; you essentially have binary over streams and can use it to encode in any format you wish.
The problem is that this is a whole lot of cargo cult.
It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions.
Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals?
As far as the rest of it, everything accumulates cruft. That's why people write new things. And yes, there have been bad decisions. (Just, IMHO, meaningfully fewer than other OSes.) But perhaps I'm blinded by my cargo-cultish ways, can you point to an archaic limitation that you've run in to recently?
I'm ignoring "arbitrariness", as that generally is both highly opinion-driven and generally subject to correcting ignorance of the decision-making process that went it to it. So usually "arbitrary" things are actually one of the other listed categories.
I believe that's the official tagline for GNU Autoconf?
Perhaps you are not aware that cargo cult has a metaphorical meaning in computing that's about carrying forward baggage that's not relevant, because it worked/mattered in the past, and giving the whole past thing more importance than an objective view would.
>As far as the rest of it, everything accumulates cruft.
That's hardly an excuse not to get rid of it periodically in the fear of losing compatibility with some 30+ year old script or device mode.
Terminal EMULATORS are a perfect example in an age where someone close to 30 probably has never even seen an actual terminal.
I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet.
There is still a lot of innovation, though. 10 years ago, we didn't have git, or ag, or autojump. Gdb has improved A LOT in the past few years, even if it's not immediately obvious when you open it.
we keep inventing new stuff, but always end up just using it to emulate and display terminals in new and interesting ways.
even my new, shiny 4G LTE + iOS + touchscreen mobile device is used to run a terminal emulator over ssh half the time. i've even use its web browser to run a web RDP session .. to display a terminal console.
i think there's just something soothing about a screen full of text. it's a very efficient way of displaying information.
The big problem with the entire Unix philosophy is that it assumes all important data is text, when in the real world very little of it is. If you're one of the few people who can get away with text-based everything, it's great. If you're the vast majority of the population, it's a terrible idea.
True, UNIX was designed, in part, to make the processing of textual data as easy as possible. It was never intended to be running inside a photo camera or a drawing pad.
On the other hand, from the very beginning UNIX was just as capable of processing binary data as well as controlling various devices, such as typesetters and graphical displays as any other reasonably powerful OS of the time.
We also had source control packages that were not only easier to use, but had more features: TFS let you put a lock on files that don't merge well, for example. Both TFS and Subversion allowed you to check-out only small portions of the repository.
Git has some nice things. It's generally fast, for example. It allows developers to work offline. But when the developer community apparently unilaterally chose to adopt it, we threw away a lot of good stuff, let's not forget that.
I'd also question that Git is "universally respected". I've worked with a great many programmers who found it just as unpleasant and unfriendly as I do. The reason people use Git is because other developers demand it as a condition of employment, not because it's enjoyable. In that respect, it's in the same class of application as, say, OracleApps or Lotus Notes.
---
^ Yes, someone's going to come in here and say, "well it's a professional tool for professionals therefore it's ok that it's difficult to use and hostile and not accessibility to people who can't use a CLI due to physical limitations because it's a professional tool for professionals.
Well.
Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.
I was with you all the way here, and then suddenly...
> We also had source control packages that were not only easier to use, but had more features: TFS let you
Suddenly you mention TFS as an example of something good. Mind blown.
TFS is absolutely among the worst "popular" version control systems I've worked with, and maintaining several branches and merging between them is pure hell.
In TFS a branch is something heavy which moves at tectonic speeds. Trying to maintaining agility in a world of TFS is just not viable.
> TFS let you put a lock on files that don't merge well, for example.
A "key" feature which more often than not is a source of problems you only have with TFS.
90% of the failed merges I've had with TFS has been because of its completely inadequate handling of binary files.
> Both TFS and Subversion allowed you to check-out only small portions of the repository.
This has nothing to do with Git specifically. This is a difference between centralized and distributed. If you want the benefits of distributed source-control, you'll have to pay the cost.
> I'd also question that Git is "universally respected".
Yes. Universally will obviously be easily disproven. I'd say "widely respected" instead.
You need to work on your reading comprehension. The only claim I made about TFS is that it has a feature (locking files) that Git doesn't.
I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality.
> This has nothing to do with Git specifically. This is a difference between centralized and distributed. If you want the benefits of distributed source-control, you'll have to pay the cost.
Fine; but that's not the point.
The point is it's a feature that I want. And now that Git has seemingly taken-over the field of source control, I no longer have it. Nobody does. It's gone.
I'm not a fan of newer software having fewer features than older software.
Fair enough.
> This is a difference between centralized and distributed... Fine; but that's not the point. The point is it's a feature that I want.
But file-locking is realistically just not implementable in a distributed source-control system. This sort of mechanism does only have a home in centralized architectures.
> I'm not a fan of newer software having fewer features than older software.
This may be a nitpick about the way you decided to express yourself, but just in case: Your math is wrong here.
You've had 1 capability you appreciate removed, while having tons of others added. That still yields you new software with more features, not fewer.
Ok. Then I guess it was a bad technical choice to pick that system if it prevents you from matching the features of your competitors, wasn't it?
I get the sense you're still missing my point here, but whatever.
> You've had 1 capability you appreciate removed, while having tons of others added.
Like what? The only one I'm aware of is "work offline". Which TFS also offers in the newer versions.
(Also: again, work on your reading comprehension. I talked about two capabilities that TFS and Subversion have that Git lacks.)
I'd like to hear about these "tons" of features Git provides over its competitors.
But this is not really friendly to issue in a PR for, so git also allows you to rewrite your commit history by squashing commits, by reordering commits, and basically cleaning up after the fact or before publishing for code-review, or public release or whatever,
If you decide that code you've written in one private repo logically belongs in another public one, you can create a new repo for the select files in your private repo which you want to share without losing version control information or any revision data.
Git has a flexible diff-engine and lets you for instance plug in pandoc for diffing word-processing files, letting you actually handle non-VCS friendly formats like MS Word through Git.
Git is modular and lets you plug in pretty much any thing you like.
And people like to, so there's modules for pretty much everything around.
Like VCS-bridges converting TFS and SVN repos to Git (and allowing you to merge seamlessly, while commiting back to the monolith).
Etc etc. The list goes on.
Git gives me the flexibility I need, to do pretty much anything I can imagine.
Except locking files. I'll hand you that one. It wont let me do that. But I can setup a central Git-server where I'll reject commits which tamper with pre-agreed "locked" files. So work-arounds obviously exist.
I'm not saying Git is perfect, but it works for me, for the needs I have. Which is more than I can say for TFS or SVN.
Oh that's nonsense. First of all, because git is a CLI application you can easily build a GUI for it, and there are a lot of them for you to choose. You can't do the reverse, and good luck integrating your tightly coupled WinForms application with other tools.
Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
> Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.
Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
While I agree his example (TFS) is rubbish and all that, I'll hand it to Microsoft that they've at least considered developers.
TFS source control comes with fully scriptable command line tools, not to mention a web-based API.
You can automate TFS-based processes. The WinForms are just there to make it more useable for end-users (and obviously because nobody else is going to bother making a GUI for this source-control system)
And here we are talking about people not wanting to use IDE because how much they have invested in their favorite work flow mental model.
It's not the lack of a GUI, it's that the CLI interface is very poorly designed.
Ok...
> First of all, because git is a CLI application you can easily build a GUI for it,
Actually you can't, because Git has features like "pre-commit hooks" and it's literally impossible to translate the output/messages of those into reasonable form for a GUI to consume (since it's just freeform CLI output text). The best you can do is simply echo them back to the user in a stupid text dialog box. You'll notice all Git GUIs either don't support pre-commit hooks at all (always commit with them set to disabled), or display the output of them using the lazy text dialog box method.
The other limitation, of course, is that since Git has no library, it's impossible for a GUI to be based on Git without it actually using Git CLI commands in the background. Which means if the Git CLI changes its commands, suddenly its broken all GUIs built off of it. (GUI clients generally "solve" this problem by shipping their own Git binary and using it exclusively, even if a newer one is on the same system.)
(It's funny that you mention WinForms. What Git does with its CLI commands is pretty much exactly equivalent to a WinForms app with business logic in the event handlers. Except where any WinForms developer would say, "why are you mixing up the UI and the program logic? That's a terrible idea!" apparently Git developers think it's great and double-down.)
It's impossible to build a truly quality GUI without the product being designed with that in mind from the start. Git wasn't. And there was simply no excuse for that in 2005.
> You can't do the reverse,
The correct way of writing an application is to put all the functionality into a library, then keeping your user interfaces separate from that library. So while you're right that you can't do the reverse (build a quality CLI from a GUI application), if the developers of Git had done their job correctly, you wouldn't have to. Git would have a core library that anybody could build any kind of user interface from.
> Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
Dyslexia. I can manage in an IDE with a large dependence on auto-complete, but I can't do a CLI.
Since I grew up on Macs and it's only relatively recently that crud like Git has been seeping into the Windows development scene, this had never been a limitation for me in the past. Worse than being user-hostile, Git makes me feel disabled in a way no other program has.
> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
I'm sorry my examples do not meet your exacting standards.
I always preferred mercurial but that fight is largely lost, I could use a mercurial -> whatever bridge but I'd still need to know git for when things break.
Git's ui is simply horrible in my opinion.
Git is a necessary evil basically.
Unfortunately, software in that particular niche has to be really good or it'll engender a lot of hate. If you're Skype, people generally don't mind because Skype is relatively easy and pleasant to use. If you're Git, people are going to hate you.
Making a better alternative isn't hard. Getting everyone to use it is.
Amen, brother
Neal Stephenson expressed this same idea very eloquently:
That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"
That's a really stupid requirement.
In a java IDE the debugger steps through your source in the same editor view that you just used for editing. You can hover over each identifier while you code or debug to get the docs in a floating panel. Editing incrementally computes compilation errors while you type. Content assist has complete knowledge of the types at your caret position and thus can make accurate suggestions what can be inserted there. Saving the file while debugging automatically compiles the code, runs tests and splices it into the running VM so you can continue debugging the running process with the new code while also showing you which lines you changed relative to the most recent VCS commit. And of course there's more.
Not to mention, compared to most IDEs, Emacs is trivial to extend. You know those really simple plugins that provide a tiny amount of incredibly useful functionality? Yeah, we have those, but most of them are so trivial to implement that they're just snippets you can copy into your config. Once you get the hang of elisp, you can be writing real, useful commands in a matter of minutes. Sure, not the big stuff, but still things that matter.
This feeling is especially strong when you use an IDE that does more out of the box with fresh install, than you could make emacs do after 6 months of tinkering and tuning.
If Anders Hejlsberg does it, there's no shame in it.
I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.
Organized (multi verbose level) tracing built right into the application can go a long way before you actually need a debugger.
Same problem happens with other methods too: If you develop solely with unit and integration tests, it might actually be quite difficult to get a step-through debugger set up to debug your application. I worked at a company where I was the only one who used a step-through debugger, and some uses of compile-time metaprogramming would frequently break the debugger.
And if you use multiple techniques as appropriate(unit tests, printf or equivalent, step-through debugging), it's generally easy to use any of them as appropriate.
Sometimes I think the people who have success with debuggers often must be working on a different class of problems than I am familiar with.
Numerical problems can usually be fixed with a series of targeted asserts and logs.
For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-
For my 400 level embedded systems design paper (which was actually a hardware design paper, we weren't graded on the code), we built boards that we could program and debug with JTAG.
I was stuck on a pain point for hours until one of the tutors showed me how to use GDB with the boards via JTAG. It took me literally 5 minutes to fix the problem. Being able to step through the code line by line allowed me to see exactly where it was breaking, and why it was breaking.
If I'm ever doing embedded development again (unlikely as I'm now employed as a web developer), I don't think I'll be able to function at all without a proper debugging environment.
Should be enough for anyone. Some people used flashing LEDs to dump an entire firmware! ;)
The general workflow, when presented with a new system, was something like:
(a) Board would arrive. Admire it for a bit.
(b) Look suspiciously at the supplied CD. Gingerly insert it into computer. Oh, look, a Windows install.exe. Insert it into the Windows computer next to mine (with its screen and keyboard slaved to mine with x2vnc, which is great). Install.
(c) Load the terrifying, buggy, proprietary IDE. Close it again. (This was in the pre-Eclipse days. You really had no idea what you were going to get here.)
(d) Search through the vast pile of useless guff which it had installed for the embedded copy of gcc. Find it. Also find the BSP libraries, and link scripts.
(e) Realise it's a terrifying, buggy, proprietary-patched version of gcc where the source package doesn't match the binary.
(f) Attempt to find whatever terrifying, buggy, proprietary tool actually downloads images onto the board.
(g) From the command line, write a tiny makefile which uses everything found in (c) plus (f) plus the terrifyingly misspelt quote documentation unquote (supplied in a PDF on the CD) and attempt to produce and run a 'Hello world' image. Download and run it.
(h) Assuming (g) worked, bolt it on to our existing gcc-and-make based built automation and actually start work.
Any debugger was usually so tightly integrated to the IDE, which was always set up to assume a particular project layout which didn't match our source layout, that it was usually more trouble than it was worth; particular as our product had a lot of JIT stuff in it, which a source debugger couldn't help with much anyway.
The very best boards had an on-board monitor which gave you a Commodore PET-style assembler debugger. One even had hardware watch and breakpoints! The ability to single step through stuff, via a serial terminal, with no prior setup required, was amazing. It was sufficiently robust that even when the board really crashed badly it would drop into the monitor and you could examine what had gone wrong.
I have a particular hatred for the debuggers which required a slave task running on the board itself. (a) sucks to be you if you were running a different OS; (b) oddly enough, if your app crashed and scribbled all over memory, it tended to stop working...
</rant>
Edit: Oh, I forgot to say --- this was mostly before JTAG was ubiquitous, so debugging options were either a terrible, proprietary serial monitor or a terrifyingly expensive ICE unit. JTAG did come along later, and it was miraculous; you could even single-step through interrupt handlers with it! But it wasn't standardised and each board typically had its own interface, which wasn't supplied, plus its own software. Then not long after I got out of the game.
...I'm having flashbacks now. Downloading Java images onto an M-Core development board at 100-200 bytes per second with a 1 in 10 chance of a failed download for every megabyte. You think I'm exaggerating. I'm not. I still have the CPU from that board somewhere; I ripped it off once we were finished to make sure that nobody would ever have to use it again.
The BSPs are still as scary as they ever were, though.
This is why I have a stash of whiskey at my desk ;)
(though honestly I haven't touched it in a while. Impairs debugging, really)
There's a grain of truth in both cases - there's no energy efficiency like not needing to move around at all, and there's no memory/CPU/cost efficiency like not having sophisticated functionality in the first place.
But once you are used to the functionality that comes from heavyweight tools, "do without - it's better for you" is frustrating at best and more likely engenders hostility for the person saying it.
Arguably, to me, they are because making the tools produce results together through composition is a first class construct of the shell and vim/emacs.
...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
"It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of Emacs can be brought to bear."
That's definitely a great failing, but I think it has two greater still: not being written in Lisp, and being written in JavaScript.
The former could be overcome (Alpha was an amazing editor for the Mac written in TCL), and after all there are plenty of great programmes not written in Lisp (emacs, for example, has a C core …).
But JavaScript‽ JavaScript: there's got to be a better way. JavaScript: warn your friends about it. JavaScript: dissatisfaction guaranteed.
UNIX as an IDE never truly made sense until I discovered Acme. It was truly a zen-like experience.
Try sshfs :) Surprising that someone who has tried Plan 9 hasn't come to love specialized filesystems!
But as I've asked elsewhere, does acme have the ability to send text to an external repl on systems other than plan9 (a continuously running one, not a freshly-spawned one), preferably one running in another terminal window? Does it have indentation for Lisp? does it have syntax highlighting (not necessary, but handy)? does it have colorscheme customization (you'd be surprised how many programs generate illegible text in white-on-black terminals, and I've become quite fond of Solarized)? Can it look up documentation for the functions I'm using (very handy at times)?
I've got the tools I'm used to, and they provide things that Acme never will for me. Maybe I'm not experiencing ultimate Unix Philosophy Zen. Maybe using the mouse is a bit more efficient. But at the end of the day, I'm here to edit text, and Emacs works in my environment, and has some pretty good tools for that.
http://plan9.bell-labs.com/wiki/plan9/mouse_vs._keyboard/ind...
Not sure what you mean, I do remote development all the time.
> and need a repl
Why do you need a lisp repl in sam? The unix shell is a repl too, and I use it in a separate terminal, which talks to sam via the Plan 9 plumber.
I use multiple terminals and sometimes even multiple sam instances, and I consider this a big plus, rather than doing everything through a single program.
> autoindent
Sam supports autoindent just fine. But perhaps you mean some other form of "smart" indent though.
You're right that sam (and acme) don't have features. The functionality comes from programs interacting with each other through the plumber or some other method.
As I'm running a Unix (Linux, at present), I really don't have the full power of the plumber at my disposal.
As for autoindent, I was talking about Lisp code, which most autoindenters don't indent properly. This is one of several reasons that the original vi had a dedicated mode for editing lisp code. Yes, really. You can look it up.
Anyways, I'm an emacs user. Saying we do everything through one program is like saying that every Smalltalk program is the same: we do everything through one VM. It's not as elegant, true, but it works right now. And outside of plan 9, acme and sam are a little hit and miss by comparison.
(ducks)
(runs)
(dodges)
:-)
I was so glad when I left REPLs and then debuggers and IDEs, to compiled languages and text-editor + command-line compilation and open source-code. I just cannot fathom the trend of the last 5 years where I hear and read people who cannot live without an IDE, a debugger and a REPL. It feels like living in a jail cell for me; a cell I left 20-25 years ago.
Incidentally, I just had to install an IDE today, for HDL development. I urgently have to find a way to turn the process into a Makefile or I will throw the computer through the window before the week-end comes.
In Polish auto repair, if nowhere else:
http://www.popularmechanics.com/technology/gadgets/a23139/co...
Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it.
And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
Don't ask me: I'm using Chicken Scheme, which provides both (to an extent: The documentation is worryingly vague about how the type system handles failure).
But since you don't mind Lisp syntax, and really like type systems, have you tried Shen? (http://www.shenlanguage.org) it's an interesting project.
I also want:
(0) Type inference. Shen seems to require all typed code to be manually type-annotated.
(1) A decent module system. There seems to be no mention of abstract types in Shen's documentation.
(2) A guarantee that dynamically typed code won't break abstractions defined in statically typed code.
> Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages)
There are many more high-level features, than static semantics. Lisp is designed for runtime flexibility, not static semantics. Runtime flexibility allows lots of interesting high-level features.
> In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp.
Lisp ran fine on five MIPS machines. Current systems have several hundred times the compute power.
The hardware was explicitly designed for Lisp in the late 70s when nothing comparable was available (single-user powerful workstations for AI/Math researchers developing large systems like Macsyma) and most development took place on time-shared mainframes with many users. The market that demanded this was a high-end market, thus the systems were developed, even though the were expensive.
Starting in the mid 80s, Common Lisp was moved to 1 to 10 MIPS workstations from SUN, SGI, Apollo, DEC, IBM, NeXT, Tectronix, and many others. The main problem at that time was that it would need 10 MByte RAM to run efficiently, which was expensive in the early 80s.
10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again.
> Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
What made them expensive was the custom development for a small market, ten to twenty years ahead of their time. It was not the technology complexity of the hardware. People were buying future technology for lots of money, where comparable technology would appear 20 years later - the first Lisp Machines with object-oriented operating systems appeared in the late 70s for $100000 a piece.
Some of Lisp Machines used 8 bit ECC to provide error checking and correction, when memory wasn't that reliable. It made them even more expensive, because ECC memory was even more expensive than normal memory boards. With memory sizes from 4MB to 20MB.
Minor Lisp/Smalltalk support then went into the SPARC chips from SUN. Lisp ran quite well on those.
> dynamic typing and efficient dynamic allocation of lots of small objects
Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects.
If you want to see Lisp on a small machine, buy a Roomba cleaner.
http://www.irobot.com/For-the-Home/Vacuuming/Roomba.aspx
Their software was developed in Lisp already twenty years ago on tiniest hardware.
https://en.wikipedia.org/wiki/Roomba
L – A Common Lisp for Embedded Systems https://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
It will clean your home, using Lisp on tiny hardware.
My main desktop machine has 16 GB RAM, and its processor cycle speed is probably also 1600 times as much as that of a machine from back then. Why can't I get my computer to perform 1600 times as much concurrent work as back then?
> Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects.
That's a luxury that we can nowadays afford. Even the cheapest entry-level smartphone is ridiculously more powerful than an 80's era workstation. But the amount of work computers do for us hasn't grown proportionally to the amount of computing power.
Is that a real question?
> But the amount of work computers do for us hasn't grown proportionally to the amount of computing power.
I don't know about you, but my laptop is much faster than previous machines. Software which used to compile with the Lisp compiler in half an hour, now compiles in a few seconds.
Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented.
> Don't forget to use as few abstractions as possible
Maybe you're confusing abstraction with runtime dispatch?
> every function call takes valuable time and computation.
Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.
It's very simple:
(0) Runtime performance degradation is unacceptable.
(1) Increased compile times are annoying, but they're tolerable in exchange for more exhaustive automatic static analysis. Anything of interest that the compiler can't prove about my code, I would have to prove myself by hand anyway, which would take even more time than the slowest automated static analysis.
Requirements like these are not grounded in real software use.
In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Java-based software vs. the same written in C++.
In reliability terms: a more robust / slower software can be acceptable over a more expensive/faster software. Example: Erlang-based software vs. C++ software on a network switch.
And so on.
Abstract/absolutist requirements like 'Runtime performance degradation is unacceptable' is not often found in actual software development/use.
Software usually has a multitude of different important qualities. Raw performance is just one of these. Especially one then needs to say what performance exactly and how to measure it. Performance can be measured in many ways: throughput, latency, micro-benchmark speed, etc. etc. Optimizing one (say, throughput) then has effects on others (say, latency). To achieve faster throughput, some functionality can be affected.
If runtime perf degradation is really unacceptable to you, you shouldn't be writing in functional languages, or even C. You should be writing in raw asm, as low-level as possible.
Now, this is a fairly trivial example, and not too hard for a compiler to optimize out, IIRC, but it's just an example. Other instances of this are far harder to optimize away.
The further up you are from the hardware, the less aware you are of the perf tradeoffs, and the less you can do to fix it. So if you want the best perf, go for asm.
In ML, most of the time I don't work with objects at all. I work with values. The beauty of programming with values is that the language implementor can represent them however he wishes, as long as he respects the semantics of the operations on said values. For example:
(0) Multiple logical nodes of a recursive data structure can be represented as a single physical node, eliminating the need to store pointers between them. For example, an ML implementation can determine that `List.tabulate (n, f)` always creates a list with `n` elements, and thus always pre-allocate a single large enough buffer before actually computing the elements. In Lisp, this wouldn't be a valid optimization, because Lisp mandates that every cons cell has its own object identity.
(1) Values with large representations can be automatically deduplicated, hash-consed or whatever it takes to reduce their memory footprint. Again, this is only possible because physical identities don't matter in ML (except for mutable cells and arrays).
In other words, values give the language implementation freedom to make useful physical data structure choices. Unlike objects, which come tied to a fixed representation.
There is no tradeoff between abstraction and efficiency, when you use the right abstractions.
This depends a lot on the user. In the right hands it's extremely efficient.
That said, you get a lot of similar behavior to this in things like Clojure + CIDER, but due to the nature of the underlying JVM, you still have to restart it every once in a while.
Part of me still wonders what we could come up with if we took the principles behind a true interactive IDE + REPL (like Emacs + CIDER) but removed the concept of "wrapping" a VM that was designed for a "programming language", and added the concept of a longer-lived "VM". Not quite what LispMs were, nor even Smalltalk (which relied too heavily on a GUI and a monolithic "image state" rather than individual persist-able files).
The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.
IMO the inefficiency is more due to the fundamental brokenness of the Unix process model. A Unix process is sort of like a VM with none of the security, and all of the stuff that has been added to it over the years (signals, IPC, dynamic linking) just makes it worse and worse. Things like full machine virtualization and now over the past 15 years namespaces/cgroups/containers are very complicated, brittle ways of trying to work around the shortcomings of Unix processes. This IMO is the biggest advance plan9 made over Unix.
[1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
1. been forced to use a system with nothing but vi, ed, and ex, which was common for commercial unixes until the 90's
2. had to make thousands of edits to thousands of files in minutes without access to a scripting environment or other more advanced tools
3. had to edit and debug a program under the above conditions on a super laggy dialup internet connection
vi is a force multiplier for operating a terminal under duress in adverse network conditions. that's literally why it was developed. i say it does an even better job of it under good, modern conditions and unless you look at it through that lens, it's never going to make much sense to you. and those adverse conditions still pop up now and then, especially with wireless networks and public cloud shitstorms.
"[Bill] Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think."
Learn to speak vim — verbs, nouns, and modifiers! https://yanpritzker.com/learn-to-speak-vim-verbs-nouns-and-m...
"To move efficiently in vim, don’t try to do anything by pressing keys many times, instead speak to the editor in sentences
" delete the current word: diw (delete inside word)"
It took me two years to learn Vim well enough that I could objectively say it works better than standard text editors. I'm not surprised you didn't succeed in learning it all at once. It's like using a mouse for the first time ever that comes with 50 buttons. I don't think anyone could learn that and put it to use from muscle memory (that's where it really starts to pay off) in one sitting.
https://en.wikipedia.org/wiki/PWB/UNIX
It introduced version control (SCCS), make, lex, yacc and more.