Earlier quoted context omitted.
Modal? I want composable .
With evil-mode, which is what spacemacs is based on, you get it.
Interesting. Does it have text objects?
Unix as IDE
111–120 of 214 posts
Re: Unix as IDE
#112This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. 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 popu…
The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages"…
There really needs to be a standard interface that all compiler toolchains can deal with for emitting program structure. All implementations deal with this problem their own way.
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.
Re: Unix as IDE
#113Earlier quoted context omitted.
> There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too. 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…
>The program you're piping to can certainly parse "import foobar", but how will it know what's in "foobar"? 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 y…
> That's the "understanding which language you're in" part comes 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.
Re: Unix as IDE
#114Earlier quoted context omitted.
If you're going to hate on something almost universally respected, you're going to have to explain yourself.
Git was made in, what, 2005. We knew about discoverability then. We knew about accessibility then. We knew about user testing, about UX. Git makes use of zero of those concepts. In fact, it seems to be actively hostile towards its users^. 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 Subvers…
> 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.
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.
Re: Unix as IDE
#115Earlier quoted context omitted.
This is of course such a transparently good idea that Acme and 9term adopted it too.
I was never as much a fan of Acme. It was a neat idea, but I don't think it was executed as well as Emacs was. And it doesn't work super well outside plan9. And I need to edit over SSH a lot. And keyboard > mouse, IMHO.
> And I need to edit over SSH a lot.
Try sshfs :) Surprising that someone who has tried Plan 9 hasn't come to love specialized filesystems!
Re: Unix as IDE
#116Re: Unix as IDE
#117Earlier quoted context omitted.
>The program you're piping to can certainly parse "import foobar", but how will it know what's in "foobar"? 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 y…
> That's the "understanding which language you're in" part comes 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 la…
> 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.
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.
Re: Unix as IDE
#118This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. 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 popu…
The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages"…
> And unix can never be a very good IDE, comparatively, because "text streams" are not a sufficiently good data structure for representing program structure.
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.
Re: Unix as IDE
#119Earlier quoted context omitted.
I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear:…
I don't know. I'm not a CL user. I understand that they actually do have a type system, which can be used to verify that your inputs are of the correct type and match your assumptions. As for contracts, I wouldn't be surprised if someone wrote a macro for it: they're not exactly rocket science, at their simplest. Don't ask me: I'm using Chicken Scheme, which provides both (to an extent: The documentation is worryingl…
Checking alone isn't the point. As things stand, it's no better than C, where the type checker can approve your code, yet it still has undefined behavior.
Re: Unix as IDE
#120Earlier quoted context omitted.
> 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again. 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 f…
...exactly. So there's computing power to spare.
To spare, you say? I want to use that computing power for my own purposes. I suddenly decided I want to multiply gigantic matrices.