Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix as IDE

sanctum.geek.nz

Post reply on HN
Print view View original

151–160 of 214 posts

Re: Unix as IDE

#151

Post by josteink »

mixedCase wrote: post #114
blakeyrat wrote: post #96

Earlier quoted context omitted.

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…

> 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.

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)

Re: Unix as IDE

#152

Post by fredsir »

superuser2 wrote: post #138
amelius wrote: post #34

Earlier quoted context omitted.

If you can't debug with just print statements, you're doing it wrong :)

This is just like the anti-car people. "People ought to be restricted to slow and unpleasant methods of transportation because they should not want to leave their immediate vicinities." 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 u…

That is som lousy anti-car people you have been talking to, it sounds like.

Re: Unix as IDE

#153

Post by coldtea »

__jal wrote: post #50
coldtea wrote: post #38

Earlier quoted context omitted.

> This 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. 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…

> The problem is that this is a whole lot of cargo cult. 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 archa…

>Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals?

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.

Re: Unix as IDE

#154

Post by laumars »

overgard wrote: post #83
__jal wrote: post #32

This 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"…

Code in an IDE is just a text editor with the aforementioned tools built in. Such tools are available for the terminal as well - both command line based and as vi or emacs plugins.

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.

Re: Unix as IDE

#155

Post by 4ad »

qwertyuiop924 wrote: post #48
Avshalom wrote: post #44

Earlier 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.

I generally use acme, but when I need to edit files on remote computers, I use sam. There's no better editor for that.

Re: Unix as IDE

#156

Post by lloeki »

the8472 wrote: post #33

It lacks the I in IDE. Those different tools are not integrated. 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 c…

> It lacks the I in IDE. Those different tools are not integrated.

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.

Re: Unix as IDE

#157

Post by qwertyuiop924 »

catnaroek wrote: post #119
qwertyuiop924 wrote: post #79

Earlier quoted context omitted.

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.

So you want exhaustive matching? I don't know if any lisp provides that by default. One of them probably does, somewhere.

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.

Re: Unix as IDE

#158

Post by qwertyuiop924 »

catnaroek wrote: post #120
qwertyuiop924 wrote: post #85

Earlier quoted context omitted.

...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.

Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.

Re: Unix as IDE

#159

Post by qwertyuiop924 »

mixedCase wrote: post #115
qwertyuiop924 wrote: post #48

Earlier quoted context omitted.

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!

I would, but in the locations I'm in, the only computer I can access is my school chromebook: no X. :-(

Re: Unix as IDE

#160

Post by qwertyuiop924 »

nerdponx wrote: post #111
qwertyuiop924 wrote: post #63

Earlier quoted context omitted.

With evil-mode, which is what spacemacs is based on, you get it.

Interesting. Does it have text objects?

Just checked the docs: Not only does it include text objects, you can write your own, if you don't mind getting your hands dirty with some elisp.
Post reply on HN