News for hackers. Stuff that matters.
Re:Problem solving with Unix commands by TeMPOraL on Thursday February 14, 2019 @10:28AM (#19162553)
How is that not impressive for vast majority of developers?

For the past couple decades, the only other even remotely mainstream place where you could get a comparable experience was a Lisp REPL. And maaaybe Matlab, later on. Recently, projects like R, Jupyer, and (AFAIK) Julia have been introducing people to interactive development, but those are specific to scientific computing. For general programming, this approach is pretty much unknown outside of Lisp and Unix shell worlds.

Re:Problem solving with Unix commands by SomethingOrNot on Thursday February 14, 2019 @11:01AM (#19162872)
The author is an MS student in statistics. Seems that Unix is well-represented in STEM university fields.

Old-timey Unix (as opposed to things like Plan 9) won. When does widespread ’70s/’80s computing stop being impressive? You say “unknown” as if we were talking about some research software, or some old and largely forgotten software. Unix shell programming doesn’t have hipster cred.

Re:Problem solving with Unix commands by jolmg on Thursday February 14, 2019 @11:50AM (#19163314)
> When does widespread ’70s/’80s computing stop being impressive?

When the majority adopts it, or at least knows about it.

> You say “unknown” as if we were talking about some research software, or some old and largely forgotten software. Unix shell programming doesn’t have hipster cred.

It's unknown to those that are only experienced in working in a GUI, which I believe is still the majority of developers. In my experience, anyone of those people are always impressed when seeing me work in my screen filled with terminals, so it does seem to have some "hipster cred". :)

Re:Problem solving with Unix commands by TeMPOraL on Thursday February 14, 2019 @12:09PM (#19163565)
> When does widespread ’70s/’80s computing stop being impressive? You say “unknown” as if we were talking about some research software, or some old and largely forgotten software.

That's precisely what I'm talking about. The 70s/80s produced tons of insight into computer use in general, and programming in particular, that were mostly forgotten, and are slowly being rediscovered, or reinvented every couple years. Unix in fact was a step backwards in terms of capabilities exposed to users; it won because of economics.

Re:Problem solving with Unix commands by pjmlp on Thursday February 14, 2019 @01:03PM (#19164160)
Had Bell Labs been allowed to explore UNIX commercially, none of us would be having this discussion.
Re:Problem solving with Unix commands by all2 on Thursday February 14, 2019 @12:36PM (#19163850)
I'll toss a link to repl.it here.

It supports a large number of languages. I started using it while I was working through SICP. I've used the python and JS environments a little as well.

Re:Problem solving with Unix commands by pjmlp on Thursday February 14, 2019 @01:01PM (#19164140)
Smalltalk transcript, VB immediate window, Oberon (which inspired Plan 9), CamlLight, come to mind as my first experiences in such tooling.
Re:Problem solving with Unix commands by fwip on Thursday February 14, 2019 @10:52AM (#19162783)
The alternative is to write a program or script that does part of the job, run it (compiling if necessary), and see what happens. Then modify.

This loop is definitely slower than the shell or other REPL though.

Re:Problem solving with Unix commands by TeMPOraL on Thursday February 14, 2019 @12:04PM (#19163492)
It's much slower, and doesn't lend itself as well for building the program up from small, independently tested and refined pieces. The speed of that feedback loop really matters - the slower it is, the larger chunks you'll be writing before testing. I currently believe the popularity of TDD is primarily a symptom of not having a decent REPL (though REPL doesn't replace unit tests, especially in terms of regression testing).

BTW. there's another nice feature of Lisp-style interactive development - you're mutating a living program. You can change the data or define and redefine functions and classes as the program is executing them, without pausing the program. The other end of your REPL essentially becomes a small OS. This matters less when you're building a terminal utility, but it's useful for server and GUI software, and leads to wonders like this:

https://www.youtube.com/watch?v=gj5IzggEWKE

It's a different way of approaching programming, and I encourage everyone to try it out.

Re:Problem solving with Unix commands by pdkl95 on Thursday February 14, 2019 @04:14PM (#19166087)
> leads to wonders like this

The engineer in me that learned about computers on a 286 with 4MB of RAM and a Hercules graphics card screams in shock and horror at the thought of letting a Cray-2's worth of computing power burn in the background. The hacker in me thinks the engineer in me should shut up and realize that live-editing shader programs is fun[1] and a great way to play with interesting math[2].

[1] http://glslsandbox.com/e#41482.0

[2] http://glslsandbox.com/e#52411.1

Re:Problem solving with Unix commands by TeMPOraL on Friday February 15, 2019 @06:07AM (#19169944)
> The hacker in me thinks the engineer in me should shut up and realize that live-editing shader programs is fun[1] and a great way to play with interesting math[2].

Yeah, sure. My point is, I assume you're not impressed by shader technology here (i.e. it's not new), but the remaining parts are Lisp/Smalltalk 70s/80s stuff, just in the browser.