Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoreUtils implemented in pure JavaScript

github.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: CoreUtils implemented in pure JavaScript

#71

Post by betenoire »

karmabadger wrote: post #6
cyphar wrote: 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?

Machine code sucks. For the love, how can we ever get past that?

Re: CoreUtils implemented in pure JavaScript

#72

Post by elmigranto »

AnkhMorporkian wrote: post #45
manyxcxi wrote: post #43

Earlier quoted context omitted.

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this? EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lo…

In instances like this, there's no issue with it being ES5. However, in the web world, ES6 modules have a huge (pardon the pun) advantage that's just being realized. Because of the static nature of ES6 imports, you can eliminate unused code when you package it all together. The newest Webpack versions and Rollup are both taking advantage of this, and it can result in huge savings in filesize. For example, lodash is a…

I imagine most libraries has some common functions that ones from public API rely on (and of course some exports can be used within module itself).

Let's say you never import `helperX` and `helperY` from a library, but you import `usefulFunction` which relies on `helperX`. How would webpack know to exclude `helperY` but not `helperX`?

Unless it does some kind of code analysis, or lib is split in "module per function" or similar manner, I can't really see a way to achieve it. And if library is common core plus a bunch of modules per function it exports, how is that different in CommonJS versus ES6 modules?

Am I missing something?

Re: CoreUtils implemented in pure JavaScript

#73

Post by notalaser »

JoBrad wrote: post #34
notalaser wrote: post #12

Earlier quoted context omitted.

Powershell is a great programming language an not a bad shell in and of itself, but using it in the same manner as a shell is quite painful. I tried to rewrite some of my ksh stuff in Powershell after getting a job at a mostly Windows-only shop. Basically every ten-line function ended up into a fourty-line superthing that's subtly incomprehensible to anyone who doesn't know .net. I get why Powershell is great for sys…

From my own experience learning bat scripting then sh scripting and then powershell, the 40-line monstrosity is what happens when you first learn another scripting language. Sometimes the paradigm can be so different that simply trying to port one script to another language ends up being more difficult (but better, from a learning standpoint, for me) than simply starting over.

Well, I never claimed I properly learned Powershell :-).

Like everything on the Internet, lack of success with a technology should be taken to mean a failure of that technology as much as a failure of the programmer attempting to use it. It may well have been a problem above the application layer.

Re: CoreUtils implemented in pure JavaScript

#76

Post by na85 »

rhinoceraptor wrote: post #39

It's always mind blowing how when someone makes a neat project like this and the comments are nothing but complaining, vitriol, etc.

Lots of vitriol because it's yet another "I took something that works and rewrote it to be slower, less functional, and JavaScript"

Making computing worse, one fork at a time.

Re: CoreUtils implemented in pure JavaScript

#78

Post by pjc50 »

pdpi wrote: post #30
cyphar wrote: post #7

Earlier quoted context omitted.

> UNIX shells suck. Javascript sucks. How could one implement a UNIX shell in Javascript and have it not suck? What do you mean by "UNIX shells suck"? I'm fairly sure most people would consider UNIX shells to be one of the bigger revolutions in computing.

Perhaps it's my own shortcoming, but for any given script I write, I find that, say, 20% of all my code is productive, and the remaining 80% is massaging the output of one tool into a shape that's compatible with the input of the next tool. Compare with the exprience of using Windows PowerShell where cmdlets return objects and you can grab precisely the fields you want with minimum ceremony. Things are better now wit…

I keep wanting to like PowerShell but finding it limited in silly ways. Text output is crippled, and there's no sensible way to save the intermediate value of a pipeline in a file.

The security ceremony required around PS is also an obstacle to getting started. And of course Microsoft have missed the opportunity to fix the path separator.

I admit that Bourne shell is not great for anything over a few lines, and find it better to drop into perl or python where filename-separator issues are mostly eliminated.

Re: CoreUtils implemented in pure JavaScript

#79

Post by dsp1234 »

pjc50 wrote: post #78
pdpi wrote: post #30

Earlier quoted context omitted.

Perhaps it's my own shortcoming, but for any given script I write, I find that, say, 20% of all my code is productive, and the remaining 80% is massaging the output of one tool into a shape that's compatible with the input of the next tool. Compare with the exprience of using Windows PowerShell where cmdlets return objects and you can grab precisely the fields you want with minimum ceremony. Things are better now wit…

I keep wanting to like PowerShell but finding it limited in silly ways. Text output is crippled, and there's no sensible way to save the intermediate value of a pipeline in a file. The security ceremony required around PS is also an obstacle to getting started. And of course Microsoft have missed the opportunity to fix the path separator. I admit that Bourne shell is not great for anything over a few lines, and find…

and there's no sensible way to save the intermediate value of a pipeline in a file

Sounds like you are looking for Tee-Object[0].

"Saves command output in a file or variable and also sends it down the pipeline."

And of course Microsoft have missed the opportunity to fix the path separator.

Windows supports both path separators in pretty much all cases (open files, changing directories, etc)

  PS C:\> d:
  PS D:\> cd /projects/node_modules/immutable/node_modules/uglify-js/node_modules
  PS D:\projects\node_modules\immutable\node_modules\uglify-js\node_modules>
Text output is crippled

I guess this depends on what you want out of the system. Some options are:

"format-table -auto" which provides a nicely formatted table view of the data

"format-list" which provides each property on a separate line with a blank line between objects

"format-custom" which allows you to create your own views of objects (with a very readable default), which has ultimate flexibility

"converto-csv" which output the object as a CSV (or with custom delimiters such as TSV)

"converto-html" which outputs the object as an html table (with somewhat customizable markup)

"convertto-xml" similar to the above

But really, if it's possible, then it makes sense to use the object pipeline until you're done (so that different parts of the pipeline can use different parts of the object). Then spitting out CSV, TSV, XML, etc should get interop with basically every other tool that's going to process text in some way.

[0] - https://technet.microsoft.com/en-us/library/hh849937.aspx

Re: CoreUtils implemented in pure JavaScript

#80

Post by striking »

callumlocke wrote: post #68
striking wrote: post #58

Earlier quoted context omitted.

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?

> Having a working knowledge of C won't kill you. I do have some knowledge of C, and I could learn more. But unless I change career, I'll always be faster and more effective in JavaScript because I think in it all day, so I'll almost always choose JS over C. I'm not disparaging anyone who uses C, just answering @faaef's question about why people "feel the need" to make everything in JavaScript – because they can, the…

JS is definitely the wrong language for a number of programming projects. JS lacks a number of features that other languages have... on its own, that doesn't make it a bad language, but it means it's less useful for certain projects.

Like this one. Like the POSIX API that is actually compatible with other applications.

And by that definition of used, C and Java are pretty strong competitors, seeing as every SIM card and Bluray player and so many more run Java... and then there's Linux and its embedded RTOS cousins, etc., etc., that are written in C or C++. I think embedded devices beat out JS pretty well.

Post reply on HN