Edit: I meant to ask what your setup is like, such that you would describe yourself as being somewhere between "have switched" and "have not switched". It seems to me like it would be one or the other.
Well, zsh isn't much better than Bash. Fish beats both, but the web-based stuff annoys me. Given Windows has the super-powerful and elegant PowerShell, I think a new shell language is definitely needed.
There was a powershell-like shell project for linux. Instead of a unified runtime it used d-bus to automatically pipe objects from a process to another.
Due to the d-bus dependency and other details, I remember it being a Gnome/RH-related project but I cannot remember the name.
(I'm not persuaded that d-bus is the best choice here, but still, it was an interesting project)
Can you be more specific? I think the language features and the ability to pass structured data vs text, the OOP features are what all shells should be doing in the new millennium.
It's a play on the name "Scheme" and "Schemers" which was continued by the "Racket" and "Racketeers" name. There's something of a history of naming things like this in the LISP community. Wikipedia says:
"Scheme was originally called 'Schemer', in the tradition of other Lisp-derived languages like Planner or Conniver."
Your reaction is, however, valid. People outside the Scheme community and it's closely related communities are unlikely to know this etymology.
Maybe some lisp hackers gradually find out that a lot of parenthesis is not that fun for everyone. Not meant to enrage Lisp hackers, I actually find parenthesis bearable.
There is also Pyret(http://www.pyret.org/) created by some people on the PLT team (you can confirm this by looking at the owner of their Github repo https://github.com/brownplt/pyret-lang). But more surprisingly it's implemented in JavaScript...
As usual, one just need a paredit equivalent to forget about parens forever. I also remember an extension (maybe emacs, or a scheme SRFI) removing the top-level parens (implicit rewriting rule).
repl> defun id (x) x
repl> defun fact (n)
(if (< n 2)
1
(* n (recur (1- n))))
A little more pleasant for people used in curly braces I'd say.
paredit makes editing parens easier, but reading them is still difficult for the unskilled (rainbow parens help, but it's still far from painless). Compare this to how autocompletion makes it easier to write a VeryVeryVeryVeryVeryVeryVeryLongMethodName but doesn't make it any easier to read.
I don't know, properly abstracted LISP code is 'supposed' to be tiny (you have all you need to write nice DSL/API) so you don't have long winded things on screen.
And I have a differing opinion about code meant to be read. This is a side effect of syntaxful languages read statically in buffer editors. You want to understand LISP ? you load the code, play with and evaluate sub expressions, and sexps/paredit is of great help here.
--Nope-- Kinda, I actually blended this with something else, which was more of a simple editor hack to avoid typing the top parens. Now things are clear. Thanks for the link though.
Pyret is implemented in JavaScript so we can have a completely in-browser runtime. And since the Pyret compiler is implemented in Pyret, that comes along for free and can be run in the browser as well. JS is far from an ideal compilation target (especially for a functional language, it requires jumping through some extra hoops [1]), but compiling to it lets us deliver the language to students with no installation necessary [2].
Personally, I am not a big fan of putting more acl/config/monitor requirements to the shell. New features add complexity, possible bugs and hacking vectors.
Fundamentally, it's not an issue of syntax. The problem is that the way commodity systems are set up, the capabilities of a script or program come from the environment in which it is run. There is no way that a user can easily tell what a script will do, even if it isn't malicious or doesn't have a code injection vulnerability.
44 comments
[ 3.2 ms ] story [ 102 ms ] threadI've all but switched to zsh on my dev boxes but this looks to be a great option for production environments.
Edit: I meant to ask what your setup is like, such that you would describe yourself as being somewhere between "have switched" and "have not switched". It seems to me like it would be one or the other.
I've been doing this for some time: https://github.com/xiaq/elvish (https://news.ycombinator.com/item?id=8090534)
Due to the d-bus dependency and other details, I remember it being a Gnome/RH-related project but I cannot remember the name.
(I'm not persuaded that d-bus is the best choice here, but still, it was an interesting project)
Anyone remembers it?
1: https://pypi.python.org/pypi/hotwire
Another detail I remember: its website or the blog of its author was surely online in 2011/2012 and it has a slightly brownish/reddish theme
I'd agree, unfortunately it's pronounced PowersHell.
(by those who have to use it)
it's just a cute name
"Scheme was originally called 'Schemer', in the tradition of other Lisp-derived languages like Planner or Conniver."
Your reaction is, however, valid. People outside the Scheme community and it's closely related communities are unlikely to know this etymology.
There is also Pyret(http://www.pyret.org/) created by some people on the PLT team (you can confirm this by looking at the owner of their Github repo https://github.com/brownplt/pyret-lang). But more surprisingly it's implemented in JavaScript...
paredit makes editing parens easier, but reading them is still difficult for the unskilled (rainbow parens help, but it's still far from painless). Compare this to how autocompletion makes it easier to write a VeryVeryVeryVeryVeryVeryVeryLongMethodName but doesn't make it any easier to read.
And I have a differing opinion about code meant to be read. This is a side effect of syntaxful languages read statically in buffer editors. You want to understand LISP ? you load the code, play with and evaluate sub expressions, and sexps/paredit is of great help here.
Anybody actually wrote code in sw-exps ?
[1] http://www.ustream.tv/recorded/43777177 [2] https://code.pyret.org
http://lush.sourceforge.net/
Prefer just simply "git add /{etc,bin,sbin,lib} /usr/{bin,sbin,lib} ... && git commit "
And daily cron jobs run a "git status" would give me some idea, trigger and confident if someone have "hack into" the server.
It seems most shell vulnerabilities (including shellshock) fundamentally come from the awful and dangerous syntax.