Unix as IDE • Hacker News Board

Re: Unix as IDE

#41

Post by qwertyuiop924 » Thu, Oct 06, 2016, 9:04 PM UTC

tychuz wrote: post #26

qwertyuiop924 wrote: post #11

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

I bet Emacs has a plugin that makes it like Vim, so Emacs is not that bad. :-)

Evil mode: it's the basis of spacemacs. If you don't want the complexity of spacemacs and you don't mind writing a bit of elisp to get your bindings working, it's worth looking at.

Re: Unix as IDE

#42

Post by sdegutis » Thu, Oct 06, 2016, 9:05 PM UTC

TeMPOraL wrote: post #31

jcoffland wrote: post #19

Earlier quoted context omitted.

> And then I realized how horribly inefficient it is at being that. This depends a lot on the user. In the right hands it's extremely efficient.

It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.

Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk.

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

Re: Unix as IDE

#43

Post by qwertyuiop924 » Thu, Oct 06, 2016, 9:06 PM UTC

lispm wrote: post #29

catnaroek wrote: post #21

Earlier quoted context omitted.

Lisp's syntax is okay, but its semantics is absolutely horrendous. 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), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems l…

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…

As much as I frequently disagree with you, you hit it on the head here.

Re: Unix as IDE

#44

Post by Avshalom » Thu, Oct 06, 2016, 9:15 PM UTC

npsimons wrote: post #23

qwertyuiop924 wrote: post #11

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

This is of course such a transparently good idea that Acme and 9term adopted it too.

Re: Unix as IDE

#45

Post by david-given » Thu, Oct 06, 2016, 9:16 PM UTC

AceJohnny2 wrote: post #35

amelius wrote: post #34

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

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

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.

Re: Unix as IDE

#46

Post by combatentropy » Thu, Oct 06, 2016, 9:28 PM UTC

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

> And I still maintain that tool tips [...] is a stupidly rude anti-pattern

Amen, brother

Re: Unix as IDE

#47

Post by ktRolster » Thu, Oct 06, 2016, 9:31 PM UTC

amelius wrote: post #34

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…

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

"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg

If Anders Hejlsberg does it, there's no shame in it.

Re: Unix as IDE

#48

Post by qwertyuiop924 » Thu, Oct 06, 2016, 9:32 PM UTC

Avshalom wrote: post #44

npsimons wrote: post #23

Earlier quoted context omitted.

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…

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.

Re: Unix as IDE

#49

Post by sleepybrett » Thu, Oct 06, 2016, 9:35 PM UTC

npsimons wrote: post #23

qwertyuiop924 wrote: post #11

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

xiki

Re: Unix as IDE

#50

Post by __jal » Thu, Oct 06, 2016, 9:39 PM UTC

coldtea wrote: post #38

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

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