Live data from Hacker News

CoreUtils implemented in pure JavaScript

github.com

51–60 of 128 posts

Re: CoreUtils implemented in pure JavaScript

#51
post #33
post #16

Earlier quoted context omitted.

The next step up would then be a REPL shell. As much as I love the idea of us running Lisp machines, at least $SHELL has a moderate enough learning curve that both beginners and experts can exploit many of it's features. Plus while many (most?) of us are programmers, there are quite a number of administrators who don't enjoy coding or even can't code at all. $SHELL is entry level enough that even they can chain a few…

Unix shells are notoriously not user friendly. The commands and their interfaces are full of insonsistencies and often really strange. Reading man pages is horror. The shell languages are not much better. There are some useful concepts, but in general Unix shells are used despite their user unfriendliness. The shells of the various Lisp Machines were quite different. The Symbolics shell, later called Dynamic Lisp Lis…

> Unix shells are notoriously not user friendly. The commands and their interfaces are full of insonsistencies and often really strange. Reading man pages is horror.

They're not that bad (GNU coreutils is generally pretty good) and you usually remember the edge cases fairly quickly (eg `dd`). Sadly you get inconsistencies in all coding frameworks, whether it's semantic, function names in the core libraries or whatever.

UNIX shells do have a lot of hidden gotchya's which can make life "interesting" (read: "oh fuck oh fuck oh fuck" lol). But the power of being able to use reusable blocks of any language through pipelining (and to a lesser extent, exit codes) is genius. It means one can mix and match LISP, Java, Perl, Python, C++, Go all inside one shell script.

I do understand the hate towards UNIX shells. There are a lot of faults and a lot of times I I'd be halfway through writing a Bash script and then be wondering if I should have just written it in Perl or Go instead. But no tool is perfect and pragmatically I've found shells to be far more productive than anything I've ever attempted to replace it with. Which is the real crux of why we use these tools. But like anything in IT, this is just my personal preference. Your mileage may vary.

Re: CoreUtils implemented in pure JavaScript

#52
Writing cross platform build scripts for web projects can be a pain when you want to rely on commands like cat, rm etc. This looks like it could relieve a lot of that. Nice job.

P.S. I'm constantly amazed by the number of non-JS developers that pile onto JS-related HN threads to tell us how much JS sucks. I'd like there to be less of it, it's getting a bit old. It seems like any amount of familiarity with the web, or the fact that someone once wrote a JS function sometime makes people feel entitled to weigh in on modern JS development. Look after your own communities and let us plough our own furrow ... we think lots of small modules is an interesting approach, and we'd like to see where we can get with it.

Re: CoreUtils implemented in pure JavaScript

#55
post #51
post #33

Earlier quoted context omitted.

Unix shells are notoriously not user friendly. The commands and their interfaces are full of insonsistencies and often really strange. Reading man pages is horror. The shell languages are not much better. There are some useful concepts, but in general Unix shells are used despite their user unfriendliness. The shells of the various Lisp Machines were quite different. The Symbolics shell, later called Dynamic Lisp Lis…

> Unix shells are notoriously not user friendly. The commands and their interfaces are full of insonsistencies and often really strange. Reading man pages is horror. They're not that bad (GNU coreutils is generally pretty good) and you usually remember the edge cases fairly quickly (eg `dd`). Sadly you get inconsistencies in all coding frameworks, whether it's semantic, function names in the core libraries or whateve…

> They're not that bad (GNU coreutils is generally pretty good) and you usually remember the edge cases fairly quickly (eg `dd`). Sadly you get inconsistencies in all coding frameworks, whether it's semantic, function names in the core libraries or whatever.

Generally this is all awful and low-level. Just see the UI interface difference between 'dd' and 'Copy File' on a Lisp Machine. The UI is worlds away.

> UNIX shells do have a lot of hidden gotchya's which can make life "interesting" (read: "oh fuck oh fuck oh fuck" lol). But the power of being able to use reusable blocks of any language through pipelining (and to a lesser extent, exit codes) is genius. It means one can mix and match LISP, Java, Perl, Python, C++, Go all inside one shell script.

You can do that on a Lisp Machine, too. With the difference that no pipelining of text is necessary. Just reuse the objects. The data is all fully object-oriented and self identifying.

Note that I'm using Unix and other OS variants since the 80s and I'm fully aware of command line UIs from VMS, SUN OS, Cisco, IBM AIX, OSX, GNU, Plan9, Oberon OS, and various others.

> I do understand the hate towards UNIX shells.

It's not hate. Most Unix shells are just fully dumb. Many people like to use primitive text based UIs with lots of corner cases, which makes them look intelligent for remembering obscure commands, obscure options without real UI help.

Take cp.

The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it. It can't provide any help when the syntax is wrong. It can't deal with errors during command execution. There is no in-context help. It can't reusing prior commands other that just editing them on a textual base. The output of the command is just text and not structured data. There are really really zillions of problems.

There have been attempts to address this putting different user interfaces on top. For example IBM provided an extensive menu based administration tool for AIX.

> But no tool is perfect and pragmatically I've found shells to be far more productive than anything I've ever attempted to replace it with. Which is the real crux of why we use these tools. But like anything in IT, this is just my personal preference. Your mileage may vary.

Many people have found shell productive. That's why there is a zillion of different shells. You can even use Lisp-based shells like scsh and esh (http://www.serpentine.com/blog/2007/02/16/esh-the-fabulous-f...) or GNU Emacs.

But for most part all these attempts stay in that little box and don't escape the general problems.

Re: CoreUtils implemented in pure JavaScript

#56
post #53

Apart from this being of questionable usability, why do people feel the need to solve every problem with (Node)JS? I can think about a ton of languages better suited for systems programming at the top of the hat.

Because JavaScript is the most widely used language in the world.

As a web developer, I know JavaScript very well. I have already encountered thousands of its idiosyncrasies and I am very good at making it work for me.

Therefore any tool written in JavaScript is automatically easy for me to understand and modify. If that tool could have been more elegantly written in another language, that's awesome for people who know that other language, but it's irrelevant to me. Even if I kind of know my way around the other language, I'm never going to be as effective with it as the language I use every day. And a lot of people use JavaScript every day. This is the reason why people feel the need to solve problems in JavaScript.

Re: CoreUtils implemented in pure JavaScript

#57
post #5

As far as I can see, what's been implemented is a shell in JavaScript, which emulates a bunch of coreutils by treating them as built-in keywords. It's kinda cool I guess (I don't use Windows), I just don't get why the tagline is "Cross-platform Linux without the suck". Apart from the phrase "cross-platform Linux" not making sense in this context, I don't see why other implementations inherently "suck".

I don't understand this at all. UNIX shells suck. Javascript sucks. How could one implement a UNIX shell in Javascript and have it not suck? Does the result suck so bad that it just wraps around becomes good again? Is the "way forward" recombining and rehashing the terrible technologies everyone is familiar with already, indefinitely?

There's a module available to put each command on your PATH:

  npm install cash-global -g

Re: CoreUtils implemented in pure JavaScript

#58
post #53

Apart from this being of questionable usability, why do people feel the need to solve every problem with (Node)JS? I can think about a ton of languages better suited for systems programming at the top of the hat.

Because JavaScript is the most widely used language in the world. As a web developer, I know JavaScript very well. I have already encountered thousands of its idiosyncrasies and I am very good at making it work for me. Therefore any tool written in JavaScript is automatically easy for me to understand and modify. If that tool could have been more elegantly written in another language, that's awesome for people who kn…

But JS can't solve every problem, nor can it solve certain problems well.

I understand people feel the need to solve problems in JS because they're scared or inconvenienced by learning a new programming language.

But why not learn a new language? Having a working knowledge of C won't kill you.

edit: could you explain how JS is the most widely used language in the world?

Re: CoreUtils implemented in pure JavaScript

#59
post #16
post #8

Earlier quoted context omitted.

Some people would agree with both statements. UNIX shells are amazing and the recent improvements in their UX and environment integration is great. (git repo status, programming environments, intelligent completion, the whole of oh-my-zsh, ...) But as soon as you want to do anything moderately interesting, it's better to grab a real programming language, because UNIX shells suck. Escaping failures, whitespace handlin…

The next step up would then be a REPL shell. As much as I love the idea of us running Lisp machines, at least $SHELL has a moderate enough learning curve that both beginners and experts can exploit many of it's features. Plus while many (most?) of us are programmers, there are quite a number of administrators who don't enjoy coding or even can't code at all. $SHELL is entry level enough that even they can chain a few…

>The next step up would then be a REPL shell.

I had been juggling the idea of using a modified REPL for shell work, but I haven't written much code. However, someone has written such a shell, namely Avesh[0]. Check out the Reddit comments as well [1].

I haven't used it yet, but the examples seem to fit what I would want in a Common Lisp shell: * Simple sh-like commands with flags (e.g. ls -o, grep -i) * Handling commands and piping as native CL functions (e.g. | (| ls (grep c))(grep r) ).

[0] = https://gitlab.com/ralt/avesh [1] = https://www.reddit.com/r/lisp/comments/48r70b/avesh_the_supe...

Re: CoreUtils implemented in pure JavaScript

#60
post #53

Apart from this being of questionable usability, why do people feel the need to solve every problem with (Node)JS? I can think about a ton of languages better suited for systems programming at the top of the hat.

Because JavaScript is the most widely used language in the world. As a web developer, I know JavaScript very well. I have already encountered thousands of its idiosyncrasies and I am very good at making it work for me. Therefore any tool written in JavaScript is automatically easy for me to understand and modify. If that tool could have been more elegantly written in another language, that's awesome for people who kn…

I'm not talking necessarily about elegance, but performance, safety, the ability to run on embedded devices, a widely-available toolchain and so on.

Apart from that, it's great to have a favorite language, but choosing a hammer for every task does not seem like the mark of a great craftsman for me.

Post reply on HN