Unix as IDE
51–60 of 214 posts
Re: Unix as IDE
#52This 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…
> And I still maintain that tool tips [...] is a stupidly rude anti-pattern Amen, brother
Re: Unix as IDE
#53>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...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.
http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em... "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…
Re: Unix as IDE
#54Earlier quoted context omitted.
Yeah, emacs would be a great operating system, if only it came with a decent text editor. (ducks)
Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org. (runs)
Re: Unix as IDE
#55Earlier 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…
Making a better alternative isn't hard. Getting everyone to use it is.
Re: Unix as IDE
#56At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool . And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.
The C64 was like that. Not Lisp but it booted right into a BASIC REPL. BASIC was the C64's operating system. I still think there is a niche for such a system today (mainly for developing rapidly changing business applications you'd nowadays use Excel for, as well as education).
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.
Re: Unix as IDE
#57Re: Unix as IDE
#58Earlier quoted context omitted.
It's funny but, in the embedded world, it's scary how archaic things are. 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 -_-
Back when I was working on embedded, I typically wouldn't even bother looking at the debugger. They never helped. 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 keyboa…
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)
Re: Unix as IDE
#59Earlier quoted context omitted.
If you can't debug with just print statements, you're doing it wrong :)
It's funny but, in the embedded world, it's scary how archaic things are. 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 -_-
Re: Unix as IDE
#60Earlier quoted context omitted.
It's funny but, in the embedded world, it's scary how archaic things are. 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 -_-
Back when I was working on embedded, I typically wouldn't even bother looking at the debugger. They never helped. 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 keyboa…
The BSPs are still as scary as they ever were, though.