Live data from Hacker News

Unix as IDE

sanctum.geek.nz

81–90 of 214 posts

Re: Unix as IDE

#81
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. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. 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…

> Yet proposing a better, widely useful and backwards compatible alternative is extremely hard.

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.

Re: Unix as IDE

#82
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…

Hey, don't ask me. I'm an emacs user. I have a fully outfitted workbench on top of my workbench, specifically optimized for text editing, which can interface with the workbench beneath it, so you never have to leave.

Re: Unix as IDE

#83
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" for a variable called "map" and not pick up every comment that has the word "map" in it, or I can move a class to a new module and let it figure out all the call sites that need to change their using statements.

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.

Re: Unix as IDE

#84
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…

The I is Emacs. It adds a heapload of tools on top of what's already there, integrates what is already there, and is a frankly awesome enviroment. It has most of what you described, but it starts faster than an IDE, and is generally better: I don't think and IDE will be beating Paredit and Slime/Geiser, or JS2, or gdb-mode, any time soon.

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.

Re: Unix as IDE

#85
post #29

Earlier quoted context omitted.

Nice rant, but mostly wrong. > 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 in…

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

Re: Unix as IDE

#86
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. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. 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…

Git is just repeating all the same mistakes all over again, just when it looked like things were starting to maybe get a bit better. I'm amazed you're citing that as a positive example.

Re: Unix as IDE

#87

Earlier quoted context omitted.

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

> Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. 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 co…

Only certain types of information. It's not a great way to display, for example, a comparison between two similarly-edited movie trailers. Or a map of Bremen. Or the annotations on your 2016 second quarter financial sum-up spreadsheet.

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.

Re: Unix as IDE

#88
post #62

This instantly brought to mind the classic 1984 book, The Unix Programming Environment, by Brian Kernighan and Rob Pike [1]. Note that they call Unix a programming environment, not an operating system. This book shows that the original purpose of Unix is to be a tool for writing software. [1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...

Do you (or anyone else) know of a book in the same spirit covering the more recent Unix tools?

Re: Unix as IDE

#89

Earlier quoted context omitted.

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

Git is just repeating all the same mistakes all over again, just when it looked like things were starting to maybe get a bit better. I'm amazed you're citing that as a positive example.

If you're going to hate on something almost universally respected, you're going to have to explain yourself.

Re: Unix as IDE

#90
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…

> vi + shell + standard utilities + what I build

That is good. Can you tell us, what exactly did you build with "vi + shell + standard utilities + what I build"

Post reply on HN