Cicada – Unix shell written in Rust • Hacker News Board

Re: Cicada – Unix shell written in Rust

#151

Post by wtetzner » Sun, Jul 02, 2017, 12:49 PM UTC

eridius wrote: post #145

LukeShu wrote: post #143

Earlier quoted context omitted.

If you don't care about licensing, GPL is a fantastic choice. Definitely don't choose MIT or BSD. The only people who should ever choose MIT are people who do care about licensing and have specifically made the decision that they like what the MIT license does. But if you don't care about licensing, then you can't make an informed choice about whether MIT is appropriate, and it's far better to err on the side of usin…

No, I said if you can't make an informed decision, go with the licenses that are widely regarded as being the least restrictive. > You even slipped in some loaded propaganda words GPL proponents describe the GPL as viral, and I'd be surprised if anyone tried to argue that it's not a restrictive license, so I'd hardly call that "propaganda". > If you don't care about licensing, GPL is a fantastic choice. This is incre…

> it's literally the worst possible license choice for someone who doesn't care about the license.

Why is that? Because with the GPL you can't as easily capitalize commercially on the work of others at no cost? Or because picking a more permissive permissive license means that other people can keep their improvements to the source you provided proprietary?

The GPL seems like the safest choice if you don't know what to pick.

Re: Cicada – Unix shell written in Rust

#152

Post by wtetzner » Sun, Jul 02, 2017, 12:59 PM UTC

int_19h wrote: post #136

still_grokking wrote: post #65

Earlier quoted context omitted.

> What's really needed is something simple that's data-centric, like JSON, but with a complete toolchain to define schemas and perform transformations, like XML (but without the warts and overengineering) . What would it be? Is there a real alternative to XML with those features out there? I don't think so. When you would want to have the features of XML and would design it from scratch I'm quite sure it would have t…

> When you would want to have the features of XML and would design it from scratch I'm quite sure it would have the complexity of XML again. I don't think so. The problem with the XML stack is that it has been designed with some very "enterprisey" (for the lack of better term) scenarios in mind - stuff like SOAP. Consequently, it was all design by committee in the worst possible sense of the word, and it shows. To se…

> A data representation language must be concise enough, powerful enough, and flexible enough to make it possible to use it to define its own schema and transformations, without it being a painful experience, while also being simple enough that a single person can write a parser for it in a reasonable amount of time.

Seems like a standardized S-expression format would fit the bill.

You could even try to make it work with existing XML tools by specifying a way to generate XML SAX events from the S-expressions.

Re: Cicada – Unix shell written in Rust

#153

Post by vidarh » Sun, Jul 02, 2017, 1:21 PM UTC

falcolas wrote: post #80

kemayo wrote: post #79

Earlier quoted context omitted.

Again, not saying this is a good thing, but it's an understandable consequence of the standardization partially involving "let's document how the browsers existing JS implementations deal with running eval on a string". It's easier to write the standard so that existing implementations fit it, rather than requiring changes from everyone.

I imagine it depends on your aims. If your aim is just to document existing behavior, that's one thing. But if your aim is to create a new, simple, data interchange format, documenting existing implementations is only going to limit its usefulness. It could have forced the current implementations fixed instead of setting the bar. As pointed out upstream, we're dealing with a lot of data these days, and such limitatio…

The point is that JSON started out as "data you can eval() in Javascript" pretty much. It gained the traction it did because it is literally a subset of javascript object notation so it was trivial to support.

Re: Cicada – Unix shell written in Rust

#154

Post by jplatte » Sun, Jul 02, 2017, 3:06 PM UTC

vbernat wrote: post #28

icebraining wrote: post #26

Earlier quoted context omitted.

$ echo $((1 + 2 * 3 - 4)) 3

With zsh, you can even save a few keystrokes. function c() { echo $(($@)) } alias c='noglob c'

zsh can handle floating point arithmetic too, while bash can't.

Re: Cicada – Unix shell written in Rust

#155

Post by zdkl » Sun, Jul 02, 2017, 4:24 PM UTC

vidarh wrote: post #153

falcolas wrote: post #80

Earlier quoted context omitted.

I imagine it depends on your aims. If your aim is just to document existing behavior, that's one thing. But if your aim is to create a new, simple, data interchange format, documenting existing implementations is only going to limit its usefulness. It could have forced the current implementations fixed instead of setting the bar. As pointed out upstream, we're dealing with a lot of data these days, and such limitatio…

The point is that JSON started out as "data you can eval() in Javascript" pretty much. It gained the traction it did because it is literally a subset of javascript object notation so it was trivial to support.

By the way is this whence the "stringly typed" phrase originated or are there previous instances?

Re: Cicada – Unix shell written in Rust

#156

Post by eridius » Sun, Jul 02, 2017, 7:15 PM UTC

wtetzner wrote: post #151

eridius wrote: post #145

Earlier quoted context omitted.

No, I said if you can't make an informed decision, go with the licenses that are widely regarded as being the least restrictive. > You even slipped in some loaded propaganda words GPL proponents describe the GPL as viral, and I'd be surprised if anyone tried to argue that it's not a restrictive license, so I'd hardly call that "propaganda". > If you don't care about licensing, GPL is a fantastic choice. This is incre…

> it's literally the worst possible license choice for someone who doesn't care about the license. Why is that? Because with the GPL you can't as easily capitalize commercially on the work of others at no cost? Or because picking a more permissive permissive license means that other people can keep their improvements to the source you provided proprietary? The GPL seems like the safest choice if you don't know what t…

It's only "safest" in that it puts a bunch of restrictions that the original developer hopefully cares about. If the original developer doesn't care about licensing, then they don't care about those restrictions and so having them in place is counterproductive.

GPL is the worst choice because it's basically the most restrictive license I can think of, and it's intentionally viral, which makes GPL-licensed software dangerous to work with (the source of) by anyone who hasn't already bought into the GPL ecosystem.

Re: Cicada – Unix shell written in Rust

#157

Post by slowmovintarget » Sun, Jul 02, 2017, 10:39 PM UTC

brandur wrote: post #3

Amazing work! Between this, Alacritty [1], and coreutils [2], we're getting pretty close to a plausible all-Rust CLI stack. While Cicada is pretty clearly modeled on the "old" generation of shells (sh, Bash, Zsh, etc.), one has to wonder what a more modern shell might look to address some of the problems of its predecessors like pipes that are essentially text-only, poor composability (see `cut` or `xargs`), and terr…

You've remindeded me of this talk: https://www.destroyallsoftware.com/talks/a-whole-new-world

Near the end, he starts talking about terminals and making a new terminal standard (~ 17:30 mins in).

Re: Cicada – Unix shell written in Rust

#158

Post by int_19h » Mon, Jul 03, 2017, 12:32 AM UTC

wtetzner wrote: post #152

int_19h wrote: post #136

Earlier quoted context omitted.

> When you would want to have the features of XML and would design it from scratch I'm quite sure it would have the complexity of XML again. I don't think so. The problem with the XML stack is that it has been designed with some very "enterprisey" (for the lack of better term) scenarios in mind - stuff like SOAP. Consequently, it was all design by committee in the worst possible sense of the word, and it shows. To se…

> A data representation language must be concise enough, powerful enough, and flexible enough to make it possible to use it to define its own schema and transformations, without it being a painful experience, while also being simple enough that a single person can write a parser for it in a reasonable amount of time. Seems like a standardized S-expression format would fit the bill. You could even try to make it work…

I'd prefer a format that distinguishes between sequences and associative arrays a bit more clearly. You can do that with S-exprs with some additional structure imposed on top, but then that gets more verbose than it has to be.

JSON is actually pretty decent, if only it had comments, richer data types, and some relaxed rules around syntax (e.g. allow trailing commas and unquoted keys).

Re: Cicada – Unix shell written in Rust

#159

Post by vidarh » Mon, Jul 03, 2017, 3:22 AM UTC

pjmlp wrote: post #127

vidarh wrote: post #41

Earlier quoted context omitted.

I still miss AmigaOS, where command options parsing was largely standardised ca. 1987 via ReadArgs() (barring the occasional poor/direct port from other OS's) [1]. It wasn't perfect (it only provided a very basic usage summary), but it was typed, and it was there . [1] http://www.pjhutchison.org/tutorial/cmdline_arrgs.html

If it was only that, what about libraries for handling all kinds of file formats via the OS plugin system?

There are lots of things I miss. Datatypes is definitively one of them. AREXX ports everywhere (I hate the language, but you don't need the language to make use of AREXX ports; Dbus is like what you get if you take AREXX and give it to a committee; the beauty of AREXX was the sheer simplicity that made it so trivial to add support for it to "everything" to the extent that many tools built their central message loop around checking for AREXX commands and built their application around dispatching AREXX like commands between different parts of the app).

Assigns is another one (for the non-Amiga aware that stumble on this, on the Amiga, I'd refer to my files with "Home:", but unlike on a Unix/Linux, Home: is not an environment variable that needs to be interpreted like $HOME or something that needs to be expanded like "~" - it is recognised by the OS as a valid filesystem path, assigned at runtime; similarly, instead of having a $PATH that needs to be interpreted, all my binaries would be accessible via "C:" for "command" - "C:" is an assign made up of multiple actual directories, one of which would typically be Sys:C, where Sys: is the System volume, and Sys: itself is an assign pointing to whatever drive you booted; Assigns are like dynamic symlinks with multiple targets, or like $PATH's interpreted by the OS)

Re: Cicada – Unix shell written in Rust

#160

Post by wtetzner » Mon, Jul 03, 2017, 11:50 AM UTC

int_19h wrote: post #158

wtetzner wrote: post #152

Earlier quoted context omitted.

> A data representation language must be concise enough, powerful enough, and flexible enough to make it possible to use it to define its own schema and transformations, without it being a painful experience, while also being simple enough that a single person can write a parser for it in a reasonable amount of time. Seems like a standardized S-expression format would fit the bill. You could even try to make it work…

I'd prefer a format that distinguishes between sequences and associative arrays a bit more clearly. You can do that with S-exprs with some additional structure imposed on top, but then that gets more verbose than it has to be. JSON is actually pretty decent, if only it had comments, richer data types, and some relaxed rules around syntax (e.g. allow trailing commas and unquoted keys).

Maybe something like EDN? https://github.com/edn-format/edn