Crush: A command line shell that is also a powerful modern programming language - <AUTHOR> https://github.com/liljencrantz/crush <comment><USER2> I think that these 'improved shell' projects (incl. crush and nushell) that try to copy powershell somewhat miss the point of the shell in the first place. If I want a high-level language that's tightly integrated with the unix environment, I already have perl and tcl. Little more power (maybe less integration, but greater capacity to build new integration) and I can use raku or lisp. The point of shell is that it interoperates freely with _all_ programs and _all_ programs share a language. If now, suddenly, I can only use commands that have been explicitly rewritten to support your environment; or regular commands are second-class citizens and need support code to interact with your environment's higher-level functionality——

Then your environment is useless to me. Because I have better programming languages which, despite being able to interact with the system and its commands, don't pretend to be one with the system. As a result, the core high- level language constructs mesh better, because they're not trying to serve two goals at once. It's not possible for something that's not a 'real' shell (including fish, zsh, even csh) to integrate with the system the way a real shell does, because the _system itself_ was designed around the shell.

<comment><USER3> Not many young people know Perl or Tcl (or even lisp for that matter).

>> The point of shell is that it interoperates freely with all programs and all programs share a language.

Also doesn't mean people should stop trying to come up with these new shells. May be some "new" shell will catch up and tomorrow's "all" programs will be compatible with that shell. For example, now on Mac OS X, now ZSH is the default shell.

<comment><USER4> > Not many young people know Perl or Tcl

There are more young people who know Perl or Tcl or Lisp than know Crush. I've never understood this reasoning - "Hardly anyone knows X. Let's replace it with something nobody knows." At most, you're making an argument about a lack of sunk cost.

> May be some "new" shell will catch up and tomorrow's "all" programs will be > compatible with that shell

Think of it like transitioning to life in a wheelchair. You can't "catch up" with your house - it just wasn't designed for wheelchair use. Renovating all the narrow corridors, random steps, tight angles and vertical reaches probably costs more than rebuilding.

In this comparison, the mobility mode is your shell.

<comment><USER5> "Hardly anyone knows X. Let's replace it with something nobody knows."

Because there's a value proposition. Just like TCL, Perl, and Lisp had value propositions over other available languages. It's fine if you don't see the value proposition in Crush but progress sometimes forces us to learn new things instead of sticking with what we have.

</comment></comment></comment></comment><comment><USER6> While I do like the new wave of the structured shells(elvish, uxy, nushell, crush, etc...), I don't think anything will actually succeed unless there's a big change in the operating system.

(I'm not suggesting these aren't valuable - these are valuable experiments, but I'm saying for them to succeed, a new OS is needed.)

The native OS doesn't really embrace structured communication, and so commands will still have to treat the structured shell as a second-level citizen.

In an ideal world, for the structured shell to work, 'npm list' should return a table (or whatever the native data structure is) and you should be able to do 'npm list | where {deduped==false}'. In the real world, 'npm list' won't support the structured shell, so you would be writing 'npm list --json | jq '<obscure commands>' | json:from | where {deduped==false}'. And then 'npm list | grep -v 'deduped' is more simpler, so you don't really feel the advantages of the structured shell.

I think for this to be solved, the OS's primary communication system should be structured, so you can guarantee that every command will be a table. Then the programmers for the tools of that OS will output a table, and the users will be able to take advantage of this. Until then... it's basically a fun experiment.

<comment><USER7> It doesn't have to be this black and white, in my opinion. The most common data structures I've interacted with on the command line are _newline separated_ or _JSON_. What if your shell allowed parsing of JSON natively?

npm list --json | ({ json }) => json.somePackage.author.name

What if it allowed parsing of XML natively, allowing instant scrapers to be written in a single command?

curl www.example.com | ({ xml }) => xml.find('.importantInformation') > scraped_info.txt

<comment><USER8> jq makes handling json in existing bash scripts simple. It can even do some simple data wrangling via built-in functions like map. It's not a universally standard command yet, but it's available for most modern systems.

I'm not sure about similar xml cli tools, but they probably exist.

Point is, both of these should be cli tools, not shell built-ins.

<comment><USER9> > I'm not sure about similar xml cli tools, but they probably exist.

I :heart: xmlstarlet (sometimes installed as that name, sometimes as just "xml"): [https://formulae.brew.sh/formula/xmlstarlet#default](https://formulae.brew.sh/formula/xmlstarlet#default) => [https://xmlstar.sourceforge.io/](https://xmlstar.sourceforge.io/)

The xsltproc that ships with libxslt1 is also pretty handy, although more verbose

While not quite xml, pup is super handy for doing quick html selections: [https://formulae.brew.sh/formula/pup#default](https://formulae.brew.sh/formula/pup#default) => [https://github.com/EricChiang/pup#readme](https://github.com/EricChiang/pup#readme)

</comment></comment></comment></comment><comment><USER10> Your shell is not for me. Here's why.

1) I don't want shell to be full-blown high level programming language. POSIX, Bash scripts/languages are enough for my shell uses.

2) For anything high level or for tasks shell would become complex, We do have dozens of fully matured languages. I would rather use those instead of this/any shell script.

3) Features desirable for shell include syntax highlighting, autosuggestions,command-not-found helper,tab autocomplete, flag complete. My shell already has it.

4) I like bash and zsh as shell. Bash is simple,i like it,but it doesn't have few features that i mentioned. So,I don't use bash as my main shell. zsh also is compatible with most bash/POSIX and it has all tte features that i mentioned in (3).fish also has these features but it's syntax is different which i don't tend to use. So,i don't use fish. zsh has all features that i like in fish too(mentioned in (3)) .

<comment><USER11> > Your shell is not for me.

And that's okay. Personally, I'm thrilled by the idea of a new shell. I don't plan to use Crush in production (yet?!) but I definitely plan on installing it on my laptop.

I'm excited to see how things go. I understand, for a while, it won't have all the bells and whistles of zsh. But that's okay. Everything has to start somewhere. I remember back when alacritty didn't even have easy scrollback!

Best of luck to Crosh and its author, liljencrantz!

<comment><USER8> I'm curious if you've taken the time to learn Powershell?

It's a supercharged version of bash that works with Windows, but instead of piping character-only data, it can pipe structured data between commands in the form of objects. The reason I ask is because, while it adds a ton of flexibility to shell scripting (to the point where I consider it to be a language), it is also quite complex.

The benefit of shell scripting is that it is simple enough to have as a tertiary language that you can pickup and use after a six month hiatus. Once you get into more powerful language territory, there are a lot more components to memorize and it becomes difficult (for me at least) to keep those idioms in my head if they go unused for months.

<comment><USER12> > The benefit of shell scripting is that it is simple enough to have as a > tertiary language that you can pickup and use after a six month hiatus.

I definitely did not find that to be the case. I've learned and relearned shell scripting a bunch of times. I always forget it and need to relearn it. Worse than perl.

</comment></comment></comment></comment><comment><USER13> Speaking of fancy alternative shells, I tried [http://xon.sh/](http://xon.sh/) for a while, whose selling point is that its language is a superset of Python.

While it was neat for interactive use to have stuff like proper string manipulation and list comprehensions, writing scripts with it (.xsh files) was horrible, because the sorta-but-not-really-Python-ness meant that no tooling worked. Syntax highlighting was messed up, code autoformatters barfed, linters barfed, autocompletion didn't work.

I actually find writing scripts in Bash, aided by the amazing linter [https://www.shellcheck.net/](https://www.shellcheck.net/) to feel almost like it's now a compiled language. It goes from being a fraught endeavor, to being kinda fun and educational. It's like pair programming with someone who has an encyclopedic knowledge of the language quirks. Hook it up to automatically run on-save in your editor!

<comment><USER14> I check in on Xonsh every once in a while. The first test I do is try and suspend a sleep into the background. This has never worked on xonsh afaict. I am excited to give Xonsh a spin, but I can't until it gets its job control story sorted out.

<comment><USER15> They are unfortunately not implementing posix correctly. Instead of using proper processes they use threads to control certain things which makes <ctrl-z> not work properly.

This would actually be possible to fix, but it's quite a bit of work.

</comment></comment></comment><comment><AUTHOR> The author, Axel Liljencrantz, was also the initial developer of fish, so has form in shell development.

<comment><USER16> Had a quick look: Fish is in C++, Crush is in Rust.

I also feel Crush addresses some issues I had with Fish. Still on Zsh though (I like pastable scripts).

<comment><USER17> I was curious how crush compared to fish (having glanced cursorily once or twice at the latter). Want to expand on the "issues you had with fish"?

</comment></comment></comment><comment><USER18> A similar idea is Mario, for Python code in shell pipelines. Its most novel feature is (optional) async commands, so you can pipe in a list of urls, make many concurrent requests, and then process them in a single line.

        cat urls.txt | mario async-map 'await asks.get ! x.json()' apply len

[https://github.com/python-mario/mario](https://github.com/python-mario/mario)

Nushell also seems cool, it's somewhat similar to Powershell. [https://github.com/nushell/nushell](https://github.com/nushell/nushell)

</comment><comment><USER19> > I also feel that tying a shell to COM objects is a poor fit.

This is not correct. Powershell allows calling into COM, .NET or straight DLLs for that matter.

It is also what I see as missing opportunity in most UNIX shells that failed to build up on Xerox PARC, Lisp Machines and ETHZ experiments.

The ability to directly plug into shared libraries, UNIX IPC, and modern mechanisms like DBUS and gRPC, alongside live debugging capabilities, thus exposing the whole OS stack to the CLI, making it a proper REPL experience.

Other than that, it looks quite cool.

<comment><USER20> I agree 100 %, shells should provide convenient, high level native access to all major RPC mechanisms.

There should simple be a grpc command that you use to instantiate a connection to a grpc server with, and that lets you do discovery, send commands, etc.

It's on my todo list for crush to do that for grpc and dbus.

</comment></comment><comment><USER21> Oil shell should be mentioned here, an alternative approach at a modern shell. It tries to be a (more sane?) upgrade path to bash: [https://www.oilshell.org/](https://www.oilshell.org/)

<comment><USER22> Thanks for the mention! That's an accurate way of describing it. I updated the home page with the one page description: _Oil is our upgrade path from bash to a better language and runtime._

The ability to run existing POSIX and bash scripts is the biggest difference between Oil and other new shells (something I'm often asked). Unfortunately that's also why it's such a long implementation effort. But in reading the comments here, I still think that was the right choice.

\----

FWIW Oil's approach to structured data is to use interchange formats over pipes. You can already pipe JSON, HTML, and CSV/TSV over pipes, and people do. There are many command line toolkits that do this.

[https://github.com/oilshell/oil/wiki/Structured-Data-in- Oil](https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil)

However the shell is also missing few things which would help that approach, so I'd like to build some native understanding of those formats into it, without requiring any special "plugin interface". Plugins are simply _processes_ in Oil.

For example, Oil already has a QSN "Quoted String Notation" to properly escape byte strings like filenames (this happens to be the format of Rust string literals, which are similar to C and JSON string literals). So you don't have to do parsing and splitting.

The approach to tables will likely be built on QSN in TSV or QSV. And then you can enhance "npm list" and "dpkg" just to print that to stdout, without having to integrate into any special "plugin system". It just works with normal Unix processes and the kernel.

[https://github.com/oilshell/oil/wiki/TSV2-Proposal](https://github.com/oilshell/oil/wiki/TSV2-Proposal) (not implemented)

<comment><USER22> Update: I just wrote a draft of "Why Use Oil?"

[http://www.oilshell.org/why.html](http://www.oilshell.org/why.html)

Let me know what you think! (feedback link in the article)

</comment></comment></comment><comment><USER23> I believe a good fit for Unix commands is using a pipeline where the output of your command (say, ls) is converted to JSON, so that later in the pipeline you can use jq to filter / count / etc in a structured, non-whitespace-dependent way. A combination of jc ([https://github.com/kellyjonbrazil/jc](https://github.com/kellyjonbrazil/jc)) and jq fits the bill for me:

        ls -l /usr/bin | jc --ls | jq '.[] | select(.size > 50000000)'

<comment><USER24> $ ls -l /usr/bin | awk '$5 > 50000000'

-rwxr-xr-x 1 root root 51859776 Jan 26 2018 pandoc

<comment><USER25> can you do that with netstat? :) (ls was one of the more simple parsers to write, aside from some corner cases)

</comment></comment></comment><comment><USER26> We need SQshell, a shell that uses SQL for operations such as listing files, processes, all that stuff where a structured query language is useful. SQL join syntax is not that different from piping. In my opinion, SQL knowledge is timeless, most other IT knowledge seems to have a "best before" date, but SQL never expires.

<comment><USER27> The thing is with SQL is many devs seem to be in one of 3 states with it. Allergic to it, will not touch it. Enough to be dangerous, and make very bad decisions with it. Amazing at it and fixing poor decisions. I am not sure what it is about SQL but it really seems to rub people the wrong way. I think it is the order of the statements. I think if they had switched the from and select statement around people would 'get' it more.

SQL is a neat tool for what it is. But command line bashing does not seem like a good fit to me. I get what you are saying though. I just would be kind of miffed to have to do something like 'select * from folders(/foldera/folderb/folderc) where lastcreatedate > getutcdate('1970') order by lastcreatedate desc' when I can currently do something like 'ls -ltar'. It is not that I can't do that. But it takes a cognitive load to do it for a command I use a lot. Of course I could make a program to do it. But then I am kind of back where I started? I could get behind SQL in addition to what I have. But in replacement I think that would be a tough sell.

<comment><USER28> I am definitely in the "enough to be dangerous" category, but isn't it technically possible to write SQL queries the way you describe? IE, the only reasons to write them in SELECT .. FROM order are (1) tradition / what others expect, and (2) optimizations made by the dbs that assume the traditional order? But in terms of returning correct results, FROM .. SELECT should work fine, I think.

<comment><USER27> Having not written a SQL parser. But I would assume there is a grammar parser in there that puts the items into some IR like language or structure that runs it. The big ones call it a query plan. So you in theory could flip them around as long as the query plan was the same. You would just need to basically convince MS and Oracle and all the other DB projects to do/try it. Not sure they would see the benefit though. In my head they are backwards but in their design it may be fine. Ideally the keywords could be in any order. But that would probably break some implicit ideas that those keywords convey (looking at you having and group by).

<comment><USER28> Hmm, I thought I remembered reading something to the effect that this was _currently_ possible, but now trying to find more information about it I'm coming up empty.

<comment><USER27> With oracle if it exists would probably be a compiler directive. In MSSQL would be some sort of DBCC command. Not sure with the other DBs as I do not use them as much and have not needed to tweak them at that level.

</comment></comment></comment></comment></comment></comment><comment><USER29> For Clojure aficionados, there's a flavour of Clojure made for scripting and the command line: Babashka [https://github.com/borkdude/babashka](https://github.com/borkdude/babashka)

And a proper shell, Closh: [https://github.com/dundalek/closh](https://github.com/dundalek/closh)

</comment><comment><USER30> If you like the sql-like filesystem interaction, check out:

[https://github.com/jhspetersson/fselect](https://github.com/jhspetersson/fselect)

I've integrated this into my workflow, it's a polished tool.

<comment><USER31> This is really cool! I've been waiting for something like this for a long time since I don't use `find` often enough to remember its command line arguments. Finally

<comment><USER32> If you like the idea of find, but can't be bothered to remember the args (me neither), might I recommend `fd`! It's like find, only faster and with a more intuitive, grep-like interface

</comment></comment></comment><comment><USER33> This sounds similar to the ideas found in PowerShell, which I really quite like in principle

</comment><comment><USER34> This is a shell for people who either don't know Unix or don't like Unix. The normal Unix tools do all these things, often with less typing, and they're a lot more flexible and transferrable to other environments.

I get that many Unix commands are obscure, and the syntax is often inconsistent, but once you're familiar with them, you can do everything this shell does and a whole lot more. And for anything more complex you've got a million other languages to choose from.

<comment><USER20> I am the author of Crush, I designed Crush for myself: a very happy Unix user for 23 years and someone who can honestly say I love Unix and the Unix philosophy. As such, I feel that I can say with some authority that your first statement is wrong.

The rest of your command is subjective, but I find that being able to see e.g. what user has used a lot of CPU and has many processes running via the command `ps | group ^user cpu={sum ^cpu} proc_count={count}` is both useful and far harder to do in a traditional shell. YMMV.

</comment></comment><comment><USER30> Upon further thinking, I think the fact that running and integrating non- built-ins is so clunky makes this less a shell and more just a shell-like programming language, and at that point why not python?

Like it or not, the Unix pipe model of command integration is what enables programs to "know" about each other without ever really knowing about each other. Crush looks like its foregoing that.

<comment><USER35> The author was very clear that they're focusing on the programming language part first and the running non-built-ins part is just a proof of concept to be fleshed out later.

</comment></comment><comment><USER36> I like these attempts at innovating the shell. Hardcore Unix users will say it is practically impossible to replace universal text streams and sh. But what if we had said the same thing before Unix wasn't a thing? Then we wouldn't have come this far today. One advantage projects like Nushell and Crush have is that they have second-mover advantage after seeing what PowerShell didn't get right. For instance whilst PowerShell is highly consistent, it's also very verbose as a result (unless you tweak it to mimic bash with aliases and then you might as well use bash anyway). Another example is that, whilst the idea of objects in pipes is theoretically interesting, it creates a lot of complexity in creating meaningful pipes (it's a lot faster to do xargs over a series of words rather than remembering how to do a for loop in pwsh). Maybe these people are striking the right balance with the flexibility of text and the rigour of tables / columns.

<comment><USER37> All nonsence. 2nd mover ? This would be like 100th mover... a testament its very hard to maintain such shell which is the reason nobody else succeded so far.

This is repeated ad infunum by the anti posh crew, while good arguments are presented against such attitude all the time.

Also, xargs is simply awful compared to what posh gives and awful without any comparrison.

<comment><USER36> xargs is quite powerful and, most importantly, simple.

<comment><USER37> Not simpler then PowerShell way. And not even close in power.

</comment></comment></comment></comment><comment><USER38> Since there are lots of alternative shells being mentioned, I thought I'd give my tuppence. I want two things from a shell:

\- Easy process execution, including branching on exit codes, overriding env vars, providing a working directory, etc. This must support concurrent processes (e.g. pipelines).

\- Easy file and stdio management (i.e. piping). This must support streaming (passing along chunks of data as they arrive, rather than gathering them into big intermediate values).

Scripting language REPLs provide everything else I care about (string handling, looping, variables, etc.). Their built-in support for these two things is usually really bad, but libraries can plug that gap. I've tried a few for Python, Haskell, Scala, etc. but the best experience I had was Racket's shell-pipeline library ( [https://docs.racket-lang.org/shell- pipeline](https://docs.racket-lang.org/shell-pipeline) it's also used by the Rash shell that I've not used [https://docs.racket- lang.org/rash](https://docs.racket-lang.org/rash) ). This makes really good use of Racket features, e.g.

\- Quasiquoting for mixing commands with normal functions in a simple, sane way

\- S-expression syntax works well for shell-like code, e.g. no comma- separation, distinguishing between (unquoted) symbols for names, flags, etc. and quoted strings for data, allowing special characters in names (e.g. to allow things like > in our pipeline), etc. Of course, Racket can be written with I-expressions, sweet-expressions, etc. too, but I've never bothered.

\- Stdio redirection works with Racket's existing "ports" mechanism

\- Env vars can be managed using Racket "parameters" (dynamically-scoped variables)

(Note that the API seems to have changed a bit since the version I used, so I'm not sure how the new stuff like laziness fits in)

</comment><comment><USER39> The improved-shell-piping-objects space is getting crowded. My entry is marcel: [https://marceltheshell.org](https://marceltheshell.org).

Trying to create a combined shell/programming language is a mistake, in my opinion. Marcel exposes bits of python on the command line, e.g. for writing predicates. For more serious programming, marcel offers a Python API that allows the use of shell commands inside Python, neatly integrated into the language. For example you can write a series of commands, connected by pipes, and the result defines a Python iterator so that you can use the pipeline results in a for loop.

See the website for more details and discussions.

</comment><comment><USER40> Looks like a unix-ish take on PowerShell.

I love the idea behind PowerShell, but the verbosity turns me off.

PowerShell, of course, has the pipelines but also COM integration, which is a big deal for Windows (you can script "the desktop" via COM; for instance you could create a new instance of Microsoft Word and call objects inside Word to do something to a document.)

Unix has dbus and some similar things, but nothing quite so critical as COM is to Windows.

<comment><USER41> The verbosity is one of PowerShell's best features. There is so much less guess work about what a command or argument does, or whether it is '-a' or '-A', or any of that garbage. You can usually guess how to do things because there's a reasonable consistency to the Verb-Noun structure. The extra typing is mitigated by everything being tab-complete including commands, arguments, and even variables. Not to mention you can just alias commonly used commands into shorter versions anyway!

Did I mention it also makes readings scripts at least 100 times easier?

<comment><USER40> Around the time powershell came out I got into the (bad) habit of writing super-concise bash scripts that write bash scripts, for instance:

       ls *.txt | awk '{print "mv" $1 "/somewhere/"}' | bash

You're really not supposed to do this because if your character escaping is less than perfect somebody can corrupt the bash script that your script writes (like SQL injection) but it is so much fun...

</comment></comment></comment><comment><USER42> Publishing a project at this level of immaturity doesn't do it any good. While it definitely "works", it works as an experiment about techniques to write an interactive command interpreter in Rust, not as a shell for people to use.

Currently there is no documentation beyond the introductory GitHub page. But this isn't a fork of sh that only needs documentation of the minor ways in which it departs from POSIX compliance: there is an unknown set of internal commands, each with a complex table format for its output (it is necessary to know all relevant column names to do anything), which depends on a large set of non-text types, which have complex object-oriented behaviour, with "serialization" to a variety of file formats, with an unspecified script and command line syntax.

Such complex features, on par with serious frameworks in full-fledged programming languages, need to be defined and documented very thoroughly, or nobody will understand, trust and use them. Unfortunately, there are many hints that not only documentation is vastly behind schedule, but that important aspects and practical considerations haven't been addressed.

For example: how can I quote file names containing nasty characters? How can I use environment variables? What is my home directory? Why is executing an executable program difficult, with complex and unclear mechanisms that mess with the command line? Given a very simple and very portable traditional shell script (e.g. ps -eaf | grep foo | sort) how can I do the same in Crush with minimal effort? If I load a very large file, does the shell choke attempting to load it all to memory, or does it process it in a proper streaming fashion?

Other issues are more fundamental. How can I perform relational queries between multiple tables, e.g. a join between ls output and a file listing users? If I can't, what can I do with tables that cannot be done more easily and flexibly with awk, jq, and other established tools?

<comment><USER43> I have zero interest in this project, but disagree that it "doesn't do any good" to share. People with similar inclinations and interests can collaborate on software that isn't ready, but that scratches their itch.

Theres nothing wrong with that, as long as you don't create unrealistic expectations.

<comment><USER42> The problem with novel shells, compared with other kinds of itch to scratch, is that existing shells have had about 50 years of evolution: doing better in a few months of work is quite unlikely.

A new shell must be similar to existing ones for compatibility with an enormous ecosystem of command line tools that work well in a typical shell; it must do almost everything that traditional shells do equally well (this includes documentation; documentation is non-negotiable) but it must also have some compelling advantage.

The right way to collaborate on designing a shell is to discuss possible designs of command syntax and behaviour, then if some promising idea comes out of the brainstorming refine it to a full specification, then if the idea survives (without mutating into a less ambitious scripting language, or a library for an existing language or shell, or a small change to an existing shell) begin an implementation. Starting with a proof of concept without a well developed and well documented design is the wrong way to offer a "product" but also the wrong way to learn.

<comment><USER44> You either have no idea about open source software, or you have no idea what it feels like to love programming, or both.

</comment></comment></comment></comment><comment><USER45> I love this. Yes, there are higher level languages that can be used for accomplishing these things, but people find themselves at the command line a lot, and having the ability to efficiently express your intent using a familiar language, without getting hand-cuffed by a poor underlying representation seems very useful.

</comment><comment><USER46> I'm struggling today as well with this shit:

I just wanna write a few small lines of a shell script which downloads stuff;

It is very very stupid through what loops you hvae to jump to do this with curl and bash script in a good way including readability and error handling.

Is a perl script really better?

Perl 5,6 and 7 did not make it very sane to me, managing and installing and working with perl is also less trivial then having a shell like bash, sh or dash available to you.

Something inbetween bash and go is missing, i like the approach of crush. I think thats the biggest misstake happening in bash: playing around with strings and auto expansion and substition etc. Its weird, its error prone, it doesn't have a proper clean well defined ecosysem.

<comment><USER47> If you're open to learning it, Tcl is actually a good middle ground here. The best way I can describe it is "structured shell script" \- still very string oriented, but the syntax and command set is much more well thought out, and its better for building libraries in (having namespacing, among other things). You even have a choice among object systems if you need one.

You don't lose much in terms of shell interop though - the native exec command understands a lot of the basics (file redirection, pipelining, background execution). In the simplest case, it's just one more word:

      exec wget $URL

You do have simple exceptions too, which terminate by default unless you catch them (unfortunately, the stack traces aren't really useful). AFAIK exec throws on a non-zero exit, and you can use it in your own code too:

      # Dead
      error "IO error"

      # Not dead
      if {catch [error "IO error"] error_or_result} {
        # The error
        puts "Caught: $error_or_result"
      } else {
        # The result
        puts "OK: $error_or_result"
      }

</comment></comment><comment><USER48> This looks to be in a similar vein to the Ion shell, which was developed for Redox [1]. Both written in Rust, both not (seemingly) perfectly POSIX- compatible, etc. I'm not sure I'd personally choose to go with either one over shell if I knew anyone else was going to need to use it, but it's cool to see iteration and experimentation on things that I usually consider to be the fundamentals of the computing environment.

[1] [https://github.com/redox-os/ion](https://github.com/redox-os/ion)

</comment><comment><USER49> if the only problem with PowerShell is that it feels clunky and annoying, why not try to extend/improve it (like Kotlin over Java)? Why start a new project that will maybe catch up in X years?

<comment><USER50> PowerShell is tied to the CLR APIs. You shouldn't have to run a Mono instance just to get basic shell behavior.

<comment><USER51> Pretty sure you don't need Mono to use any modern version of PowerShell.

</comment></comment></comment><comment><USER52> Nice idea that corresponds with my idée fixe - a sane, usable output format for Unix utilities. There are differences, of course - I prefer a text-table format as universal panacea, but I'm glad that more and more people notice a mess in Unix environment ("simple" doesn't mean "consistent" and even Plan9 suffers from that).

See also [https://github.com/aniou/cof/wiki/Draft](https://github.com/aniou/cof/wiki/Draft)

</comment><comment><USER53> Reminds me of elvish (elv.sh), which has a similar focus.

</comment><comment><USER54> Curious how this compares to Xonsh (IIUC, pretty similar idea, tho I Xonsh is actual Python, vs Crush using its own new lang).

</comment><comment><USER41> I really want something like this as a replacement for sh in tiny busybox- backed use-cases, so I find it really annoying that developers insist I install rust and compile it instead of offering a statically compiled binary I can use.

And if it can't do that because of a reliance on shared libs, then that's even worse!

</comment><comment><USER55> This looks absolutely brilliant.

</comment><comment><USER56> I have recently been partial to python and the sh library. This and the other associate projects look interesting but are they secure and will they catch on?

</comment><comment><USER57> The main innovation I see is tokenization into columns instead of character streams. If I want to do that in a traditional shell, I use awk.

</comment><comment><USER58> A better PowerShell? I'll take it! What's the story behind the name 'Crush'?

<comment><USER16> cRUSh shares a few letters with Rust (the prog lang of the project). The author made Fish before, a new shell+lang in C++.

</comment></comment><comment><USER59> Somebody just give me a rust REPL already (that is not the slow as snails evcxr)

</comment><comment><USER60>
        crush> ls | where {type == "directory"}

Thank you!

<comment><USER61> What is wrong with:

      ls -l | grep '^d'

<comment><USER62> It is minimal, so does not meet the modern aesthetics of computer world.

<comment><USER5> Until you want something more specific like listing absolute paths of those directories without the metadata

ls -l | grep '^d' | awk '{print $9}' | xargs realpath

Or

ls -ld "$PWD"/* | grep '^d' | awk '{print $9}'

Guessing Crush could just add another property called Fullpath you can echo in the next pipe after filtering.

ls | where {type == "directory"} | select %Fullpath

Maybe he adds a --dir flag

ls --dir | select %Fullpath

<comment><USER63> % find . -maxdepth 1 -type d | xargs realpath

How long do these tools exist? Over 20 years?

<comment><USER5> The example works but you need to understand the idiosyncrasies of all the tools involved and the text format. Once you learn that you're passing around structured data and you access it the same way it becomes trivial get data.

<comment><USER63> Yes, you have to learn the idiosyncrasies of the tools involved. My point was, these are standard tools that are there for more than 20 years, and they work just fine. People should just RTFM and learn by experience instead of inventing something new which looks shiny on surface but most certainly will have unhandled hidden edge cases and serious limitations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER64> for the people who use powershell on mac, and as someone who used neither, which one would you recommend to integrate into my workflow powershell or crush?

<comment><USER65> Crush seems very alpha stage right now (no terminal support), or for actual usage PowerShell may be your only current option.

</comment></comment><comment><USER66> Doesn't AWK already do all of this?

</comment><comment><USER67> Has anyone got this to compile on macOS?

<comment><USER3> Yes, not working for me too. Ran the

curl --proto '=https' \--tlsv1.2 -sSf [https://sh.rustup.rs](https://sh.rustup.rs) | sh

command also which upgraded by Rustc to rustc 1.45.2 (d3fb005a3 2020-07-31).

This is one problem I have faced with Rust quite frequently. Try to clone and run a random (not famous) project from Github and it doesn't compile.

Love Java when it comes to this. It's easy to see which version of the JDK is needed from the Maven file. If you have that version of JDK, the projects almost always run.

</comment></comment><comment><USER68> Neat! Definitely going to try this out.</comment>


Is anyone doing "Tinder, but with video"? Why not? - <AUTHOR> Certainly it will require some deep thought and lots of coding, but the concept is easy to understand - like Tinder, but with video which users upload right from their devices.<p>Has anyone built this, and if not, why? It seems like something that should already exist and be in common use, like Tinder, Bumble, etc. <comment><USER2> Adding video is pretty trivial from an effort standpoint, so this probably falls under a class of startups where the differentiation is not enough to justify a standalone service.

Video costs are higher and probably no additional revenue, so Tinder isn't doing it on thier own. If you put a bunch of energy into such a product and it looked like it would take off... bam... Tinder now has videos and you're dead.

<comment><USER3> >...If you put a bunch of energy into such a product and it looked like it would take off... bam... Tinder now has videos and you're dead.

Or he could be sufficiently irritating that he is approached for acquisition.

There are segments of the consumer base out there he could go after and use cases we probably are not considering.

Tinder is global and in my country, it has a (bad) reputation as hookup app i.e sex-for-pay. This alienates that group of people looking for something more substantial than a sexual encounter. That's one thing not going for it.

There are other drawbacks. People post their profile pictures, sure, but still misrepresent themselves in other ways.They write glowing tributes about oneself which other people might not agree with .... I for one would appreciate a one minute video of prospective matches to learn more before committing fully . So, an app with a different angle of attack would generate interest.

Dating is nowhere near a conquered market.

<comment><USER4> Match group corp dev will buy essentially anything over 15k mau so the acquisition angle isn't wrong

</comment></comment></comment><comment><USER5> I don't think most people would do this. They're likely too shy and/or don't want to put the effort in. In my city, about 25% of profiles are blank on Tinder.

Tinder has gifs now, and you can connect your Instagram to most apps. The functionality exists and isn't used much. Even IG is still mostly photos.

<comment><USER6> _I don 't think most people would do this._

Sounds like a good filter then.

</comment></comment><comment><USER7> [https://techcrunch.com/2018/04/04/tinder-begins-testing- its-...](https://techcrunch.com/2018/04/04/tinder-begins-testing-its-first- video-feature-tinder-loops/)

<comment><AUTHOR> This is truly horrible. These kinds of looping gifs have all the appeal of watching 4-year-old pick her nose.

</comment></comment><comment><USER8> Dating apps are only valuable based off their user base. The coding is not the hard part. The app is not the hard part. Well over 90% of the difficulty of dating apps is successfully marketing them.

<comment><USER9> Yep and the fact that it's a terrible crowded market. If you told me you had 1M users and were growing 10% monthly I'd personally still probably be very reluctant to invest.

</comment></comment><comment><USER10> I agree. I used to own a domain with the intention of building one.

'Video Dating' used to be 'a thing' back in the 80s.

There's a classic old video on YouTube showing them. [https://www.youtube.com/watch?v=0bomkgXeDkE](https://www.youtube.com/watch?v=0bomkgXeDkE)

</comment><comment><USER3> Bash out an MVP and get a few people to try it. Tinder is vulnerable to a strong competitor

I think its a reasonable idea and you never can tell what the customer really wants or what the market will reward.

<comment><USER11> The technical part is the easy part. What's interesting to me is how tinder, which unlike twitter or Instagram for example requires a certain mass of active users in the same physical area, established themeselves in the first place.

My only thought on how to make a "Tinder of X" is start hyper local, somewhere like a college campus or a single neighborhood. The small local userbase could well become a selling point too, giving the product the image of exclusivity. Starting hyper local also may help with the "ok so he looks cute but what if he's actually an axe murderer or Russian troll" problem.

</comment></comment><comment><USER12> because I'm ugly looking, don't want to take a video.

because while on toilet, don't want nearby stalls hear what I'm watching.

</comment><comment><USER13> Well, there was Chatroulette: [https://en.wikipedia.org/wiki/Chatroulette](https://en.wikipedia.org/wiki/Chatroulette)

Mmhh..looks like there still _is_ Chatroulette (NSFW!) [https://chatroulette.com](https://chatroulette.com)

</comment><comment><USER14> That's literally how "YouTube" was born. Registered on Valentine's Day as a way to share interesting videos of yourself to find dates.

</comment><comment><USER15> I would argue that creating a Tinder but only with voice is much more exciting. Imaging going on a blind date and the only thing you know is the voice.

</comment><comment><USER16> For the French speaking dating pool

[http://www.tuttiflirty.com/](http://www.tuttiflirty.com/)

</comment><comment><USER17> Transpose videos to gifs with audio and I think you will have something. No one does it with raw video because of the hosting cost.

<comment><USER18> >Transpose videos to gifs with audio and I think you will have something. No one does it with raw video because of the hosting cost

Umm, you do realize that videos provide a way _better_ compression than GIF+audio, right?

</comment></comment><comment><USER19> Probably all of the intricate privacy issues surrounding how the video is hosted since the service would likely be abused.

</comment><comment><USER20> Probably same reason you dont need to see video of the food in a restaurant or video of your room in a hotel.

<comment><USER17> Idk about that. If I could see in video that the dish waiters bring to table actually look like the pictures it would be more enticing. Also, just getting the vibe, feel, and size of a restaurant or hotel could have a big influence.

</comment></comment><comment><USER21> Video is not an improvement over text.

</comment><comment><AUTHOR> Thanks everyone - good feedback.</comment>


99 Things to do instead of Twittering - <AUTHOR>

<comment><USER2> #2 Do the top two things you've been meaning to do all day/week, then feel good.

</comment><comment><AUTHOR> #1 Leave a comment on someone's blog you usually visit, but never comment on.</comment>


Scientists induce retina regeneration in mice, curing blindness - <AUTHOR> http://www.biologynews.net/archives/2008/03/18/scientists_successfully_awaken_sleeping_stem_cells.html <comment><USER3> Ah yes, blogging by press release is alive and well.

Try this search: [http://search.yahoo.com/search?p=%22Eye+Research+Institute+h...](http://search.yahoo.com/search?p=%22Eye+Research+Institute+have+discovered+what+chemical+in+the+eye+triggers+the+dormant+capacity+of+certain+non- neuronal+cells+to+transform+into+progenitor+cells%22&ei=UTF-8&fr=moz2)

Especially in science blogging, what's the point of copy/pasting press releases? Where is the critical eye? Where is the independent thinking - <USER2> peer review?

Pierre

<comment><USER4> Are there many science bloggers that cover scientific research with a critical eye? Biology News does press release copy/paste, sure, but he also does original summaries of some papers.

If you know of any good science bloggers, I'd love some to add to my list...

</comment></comment><comment><USER5> these press releases really need to start linking to the papers..

full paper here:

<http://www.iovs.org/cgi/content/abstract/49/3/1142>

</comment><comment><USER6> YES! Now I can ignore that raster burn and keep working no matter how bad it is on my eyes! Seriously though, that is really great news since I'm sure it could lead to some really great human treatments.</comment>


Ask HN: How come there are no durable laptops anymore? - <AUTHOR> In the last years the desktop market has become more or less stable. Mainboard manufacturers are competing these days on making the most durable and high quality boards with components like Anti-Sulfur Resistors design, Surge LAN Protection, Japanese made capacitors and more.
But contrary to this trend the build quality of PC laptops has declined tremoundlesy in terms of components quality. You can find quality motherboards or capacitors and it seems that there will be a demand for it in the market. <comment><USER2> do laptops really need such measures? laptops use much lower power across the system, chips are not pushed anywhere near as hard as in desktop implementations, in many cases ive found laptops to last longer than PC mainboards do, just look at the amount of old Thinkpads around.

personally on average i expect a laptop to last about 3-5 years generally the ones ive had have lasted longer than that, adding those sorts of components would only serve to make systems more expensive and likely heavier amongst other things

<comment><AUTHOR> The thinkpads you see lying around are exactly the models from 5-7 years ago that are still kicking because of the various options to fix them. You can't say this for example on the last models (like the X280)

<comment><USER2> there are plenty of ones even older than that still kicking and in regular use, just check out r/thinkpad, im typing this on a 2012 X1 carbon which shows no signs of dying despite being used heavily every day.

that being said current laptops, thinkpads included are all now using components which output too much heat for the cooling systems, almost every modern i7 laptop has some level of thermal throttling which could well shorten the life of other components but i guess only time will tell on that.

i still dont think its enough to warrant the inevitable increase in price (and likely weight and size to a degree) that using higher end components would incur</comment></comment></comment>


Failure: A Checklist - <AUTHOR> http://www.fool.com/investing/general/2016/01/28/failure-a-checklist.aspx <comment><AUTHOR> Much like the "Associate complexity with added value", for example, we see unlimited challenges in the computer science field that don't move the needle at the big picture level.</comment>


Microsoft updates Windows Phone 7 logo: Now it's a square - <AUTHOR> http://techcrunch.com/2011/08/01/windows-phone-logo-refresh-fits-a-square-peg-in-a-round-hole

<comment><USER2> I think this goes to show how Microsoft misses the details. I never liked the round logo on my phone. I never new why, but it always looked off. If you want to view the old logo, it's still on the Microsoft Windows Phone page <http://www.microsoft.com/windowsphone/en-us/default.aspx>

I just rebooted my Mango phone to see if I get the square logo, and I do. It makes so much more sense than the circle.

How did Microsoft not notice that everything about WP7 was square, and then give it a round logo, with a square inside.

Hopefully somebody there now is paying attention to these details.

</comment><comment><USER3> It goes well with the _metro_ UI.</comment>


Launch: Mental health classes for people in startups - <AUTHOR> https://medium.com/@anonent/introducing-sanctus-59a8b408bc0d#.kvqp6pfx9 <comment><USER2> You might be interested in "Recovery College" from UK.

Here's a video from the Health foundation about it.

[http://www.health.org.uk/recovery-college](http://www.health.org.uk/recovery- college)

There are two "Tackling stigma" campaigns you might be interested in. One is "Time to Change" from England. They have a range of great materials. (I've had some minor involvement with a Time to Change project): [http://www.time-to- change.org.uk/](http://www.time-to-change.org.uk/)

The other is the Australian "Soften the Fuck Up": [http://softenthefckup.spurprojects.org/](http://softenthefckup.spurprojects.org/)

Good luck! I'd be really interested to hear about the results.

</comment><comment><AUTHOR> I want to help people in startups ride the rollercoaster with a series of mental health classes & workshops

I've published this post which goes into more detail on my vision for this and the first product

I'd absolutely love any feedback from you guys either in the comments or by e-mail

Thanks :D

<comment><USER3> Curious if the facilitators are licensed clinicians.

<comment><USER2> There's a bit of a push for "per led support". Some of the jargon includes "co production" and "co delivery".

Here's a nice introduction to co-production: [http://www.mind.org.uk/information-support/your- stories/co-p...](http://www.mind.org.uk/information-support/your-stories/co- production-in-mental-health-why-everybody-wins/#.VyoPm9IrK00)

>Co-production is essentially where professionals and citizens share power to plan and deliver support services together, recognising that both partners have a vital contribution to make. One example of a co-produced approach we reviewed is the Service User Network in Croydon. The network has been designed jointly by psychiatrists and service users who work together on an ongoing basis to deliver it. The network combines professional and lived experience and creates active networks that support people's recovery.

You're right that it's a bit scary, and that care needs to be taken around clinical governance and data governance.

<comment><USER3> There's peer to peer to support within a clinical model and peer to peer to support absent one. The cartoons in the article illustrate the breadth of possibility within the latter.</comment></comment></comment></comment>


Simple, beautiful, innovative design to keep headphone cords untangled - <AUTHOR> http://www.engadget.com/2011/09/12/sinch-takes-aim-at-headphone-tangles-we-go-hands-on/

<comment><USER2> Why not a simple rubber band?

<comment><USER3> agreed, this is silly. a simple half-hitch works better, period.</comment></comment>


The city that won't stop growing - <AUTHOR> http://www.bbc.co.uk/news/resources/idt-sh/lagos <comment><AUTHOR> I'm keen to hear a few viewpoints from the HN community: 1.) how technology might ameliorate typical problems 2.) Lagos-based startups that are pursuing the same</comment>


Ask HN: Getting Clients That Are Clients of Another Agency - <AUTHOR> I constantly see websites that are horrendously out of date that I'd love to approach to acquire them as a client. However, I notice that they are clients of another agency via tag at the bottom of the page.
Has anybody ever dealt with this situation and how did you approach them to try and get their business?
Second case: how does this change when the agency is extremely out of date with design?  (Sites that were barely passable in the 90's) <comment><USER2> Just because a site was built by an agency doesn't mean that the client still has a relationship with them. Reach out to the website owners and see if they would be interested in talking about a redesign.

<comment><AUTHOR> Follow up....how do you go about finding the proper person to talk to? Do you ask for the owner? Ask for who's responsible for their marketing? What's the process usually look like?

Sorry if this should be obvious. I know there's people on here with a lot of experience and would know the ways that are best received by the potential clients.

<comment><USER3> Given a website as an example, ask for the person that hired the last team/person that worked on it. This could be anyone – the owner, marketing department, IT, etc. – so just cut to the chase and ask for whoever is currently responsible for it.

<comment><AUTHOR> Ahhh okay, that's a good blanket statement, thanks eswat

</comment></comment></comment></comment><comment><USER4> Consider the possibility that it sucks because there is no money for an update and/or it isn't a priority. Try to verify that this is a viable business and that an update would at least pay for itself, preferably more than pay for itself.

Consider the possibility that obvious need of an overhaul (in your eyes) is not very good evidence that these are good prospective clients. If you are offering charity, obvious need is a good metric for whom to target. But if you want a healthy business relationship, that is insufficient. A healthy relationship is symbiotic. It is one where both sides benefit. If they can't afford to pay you or just do not care, the suckiness of their site is not a good argument for viewing them as good people to target as future clients.

Don't hesitate to email them and pitch them. But don't be shocked if the success rate is low. You may need to come up with additional metrics to define "good prospective clients."

<comment><AUTHOR> All valid points, thanks for the insight Mz

</comment></comment><comment><USER5> An out of date website is a _poor_ lead because the likelihood that the company does not see value in their website is _higher_ than if the company has a great up to date one. A low quality out of date website can be symptomatic of not spending money on web design/development.

On top of that, telling a company that their website sucks is a low closing strategy whenever the company values their website. First because it is often contrary to their opinion, and second because the website may in fact work for their business and that what horrifies a designer is orthogonal to the business's bottom line.

Good luck.

</comment><comment><USER6> > how did you approach them to try and get their business?

There is an art & science to prospecting and pitching new clients. It's a learned and practiced skill. If you can master this, it will change your business and life.

On this subject, Mike Weinberg's advice is huge > [http://www.goodreads.com/book/show/15863998-new-sales- simpli...](http://www.goodreads.com/book/show/15863998-new-sales-simplified)

</comment><comment><USER7> But, the main thing would be knowing the pricing what the client is willing to pay and negotiating with them.</comment>


A conversation with Alan Kay (2004) - <AUTHOR> http://www.doc.ic.ac.uk/~susan/475/AlanKay.html

<comment><USER2> This comes up on HN once or twice a year, and I always vote it up. It's brilliant and loaded with great quotes. Like a great novel, you can reread it and enjoy it every time.

I haven't seen anything come out of Alan's VPRI group for a while. Does anyone have an update?

<comment><USER3> They're putting out annual reports: <http://vpri.org/html/writings.php>

Recent HN discussion: <http://news.ycombinator.com/item?id=3878661>

<comment><USER2> Thanks for the link to the recent HN discussion -- I missed that and it's very interesting.

</comment></comment></comment><comment><USER4> The problem is scaling and complexity: if you have 100 interacting entities, and add one more, it increases complexity by a factor of 100x.

The solution is to subdivide it into modules that can be treated as a single entity. The complexity within each module is much less because there are fewer entities within it, and there is less complexity between modules because there are fewer modules (which can be seen as entities at a higher level - and we can nest modules, to further reduce complexity).

The problem with _this_ is that it is hard to find the right modules, that minimize interactions within them and between them. It takes a lot of data, a lot of insight and a lot of trial-and-error to find modularities that work well - it amounts to a theory of the data. In science, most theories take a long time to be discovered and a long time to be improved on - but we expect to do this routinely on each individual software project...

[ One way this is done in practice is when someone decides to tackle a generally needed problem, and wrap it up as a component (e.g. 3rd party library). To the extent that this is the _right_ modularity, it will not only reduce the work a user needs to do to use it, but also reduce overall complexity in the total system (including for the component designer). ]

Instead of expecting it to be easy to find the right modularity, we should expect it to be hard; instead of insisting on a simple theory that explains everything, we should celebrate every small step towards better theories. This is what all practitioners facing empirical complexity in the real world end up doing.

> I feel like my answers are quite trivial since nobody really knows how to > design a good language, including me.

</comment><comment><USER5> _The idea of using those things has a common origin in the hardware of a machine called the Burroughs B5000 from the early 1960s, which the establishment hated...The problem was that the DP managers didn't want to learn new ways of computing, or even how to compute. IBM realized that and Burroughs didn't._

A good summary of many of the cultural impedance mismatches of Smalltalk. Even today, Smalltalk is weird. However, many of the things developed there now have widespread traction. Java, Python, Ruby, .Net -- these communities have adopted many of the great things from the Smalltalk world.

</comment><comment><USER6> "Now we get around the efficiency stuff the same way Barton did on the B5000: by just saying, "Screw it, we're going to execute this important stuff as directly as we possibly can."

We're not going to worry about whether we can compile it into a von Neumann computer or not, and we will make the microcode do whatever we need to get around these inefficiencies because a lot of the inefficiencies are just putting stuff on obsolete hardware architectures."

</comment><comment><USER7> It's always a treat to hear Alan Kay go on about how smart Alan Kay is. Those were the days, I guess? Sorry about this whole PC-internet revolution thing.

<comment><USER2> I can see how he can come across that way. The progress that was made before 1980, of which we're entirely still surfing on, has to be connected with the simplicity and lack of patterns. It was like the 60's in music; no one knew what to expect so everything was possible.

On the other hand, considering the PC-internet revolution is _all_ based on technologies that he and his colleagues developed, you should check yourself. Maybe if our industry had an ounce of history and a modicum of respect, we wouldn't be swimming in the mess we're in.

In my opinion, there's no one alive in this field that you should respect more than Dr. Kay.

<comment><AUTHOR> Also, the PC revolution exploded so quickly that it fractured the hacker community which had fostered it. It took on a life of its own, and the very people that invented it have often publicly questioned the various directions it has taken since. While it could be taken as similar to saying, "I liked the Internet before it was cool", Kay's remark about Pop phenomena struck me as utterly insightful.</comment></comment></comment>


Ask HN: Rails or Flask for new API project in 2019? - <AUTHOR> <comment><USER2> What do you actually expect from this question? Obviously a lot of Rails users / enthusiasts are going to respond "Rails", a lot of Flask users / enthusiasts are going to respond "Flask", then I'm going to respond and say "Neither, use Grails", and so on. And at the end of it all, what will you know that you don't already know?

</comment><comment><USER3> Whatever you're comfortable and already know. If you'd rather learn something new, then perhaps Elixir + Phoenix.

</comment><comment><USER4> Not enough information. Please provide more information... (Blinking cursor)</comment>


Egypt's Startup Scene - <AUTHOR> http://kerningcultures.com/episodes/egypt-startup-scene <comment><USER2> Do you think you caught a good representation of Egyptian entrepreneurial society?

Most Egyptians I know have given up on Egyptian society and politics following the Sisi led coup and now see their future either outside of Egypt or within the 'internet culture'.

In many ways, Sisi indicates to the youth that the democratic system doesn't work in Egypt and that the only way to survive is to leave.

Disrupting society online carries it's own risks under the military government (i.e. disappearing.)

What are your thoughts?

<comment><USER3> This is an incredibly complex topic. Believe me, most of my Egyptian friends and family will wax poetic of the same difficulties and desire to leave/ have already left. There's no way to do a response justice in a post, but we are working as we speak on episode about brain drain from Egypt in attempt to make sense of the complexities. Would love you input, if you'd like to be involved: hebah [at] kerningcultures.com

</comment></comment><comment><USER3> We spent a few weeks researching for this piece, happy to answer any questions you might have!

<comment><USER4> You're tying up the re-birth of entrepreneurship to the 2011 revolution that happened in Egypt. But isn't the ousting of past-elected president and the forced takeover by el-Sisi (a military man) a sign of complacency from the youth in particular?

You're basing your whole point on this revolution that was undone soon after, which really takes away from the core points of your article. That said I can definitely imagine how much of a positive impact an _attempted_ revolution could have on people's appetite for change.

<comment><USER5> I wonder if you would have cared so much if the previous "elected" president were German national socialists? Because the previous "elected" were Muslim Brotherhood rats.

<comment><USER4> I don't like commenting on others' politics and governments (Egypt in this case). I do for my own because I have the right to. But wouldn't a predominantely Muslim country vote for a Muslim government? Wouldn't a Christian-founded country like the US ensure its president is Christian? I think it's fair and logical.

My understanding is that the people of Egypt voted for a Muslim representation. They got just that (for better or worse). Until el-Sisi, with his military power, decided it didn't suit his own views.

</comment></comment></comment></comment><comment><USER6> What are the religious leanings of statup founders and workers? More liberal? Much more liberal?</comment>


Ask HN: What languages include implicit condition checking? - <AUTHOR>

Not even sure if I'm using the right name.  I've been doing a lot of precondition / type checking in PHP, and it occurred to me that it might be a cool language feature to bake into a language.  For example, perhaps I could write `$i = count($keys) = count($values)` if I want $i to be set only on the conditions that $keys and $values are equi-lengthed array.  An more advanced implementation could include auto checking a function's inputs, based on some set of rules defined in syntax or comments. <comment><USER2> If what you're thinking is the so called Design by Contract (using preconditions and postconditions), there are plenty of languages with that feature:

The original one is Eiffel, if I'm not mistaken: [http://en.wikipedia.org/wiki/Precondition#Eiffel_example](http://en.wikipedia.org/wiki/Precondition#Eiffel_example)

Clojure: [http://blog.fogus.me/2009/12/21/clojures-pre-and- post/](http://blog.fogus.me/2009/12/21/clojures-pre-and-post/)

Ada 2012, apparently: [http://www.adacore.com/uploads/technical- papers/Ada2012_Rati...](http://www.adacore.com/uploads/technical- papers/Ada2012_Rationale_Chp1_contracts_and_aspects.pdf)

The slightly lesser known Cobra: [http://cobra- language.com/trac/cobra/wiki/Contracts](http://cobra- language.com/trac/cobra/wiki/Contracts)

(of these, I only ever wrote Clojure, and I've used a couple preconditions in production, I definitely like the concept)

<comment><AUTHOR> Thanks for the name and links!

</comment></comment><comment><USER3> I know it's not _exactly_ the same, but couldn't you achieve the same thing with getters and setters?

[http://www.php.net/manual/en/language.oop5.overloading.php#o...](http://www.php.net/manual/en/language.oop5.overloading.php#object.set)

<comment><AUTHOR> Yes and know, I'm mostly doing this in the constructor and some creation functions that call the constructor, not so much when the variables themselves are changed. Great link though! :)</comment></comment>


When Twitter Bans Extremists, Gab Puts Out the Welcome Mat - _-_T_-_ https://www.adl.org/blog/when-twitter-bans-extremists-gab-puts-out-the-welcome-mat <comment> _-_T_-_ The first in a series of reports co-authored by the Network Contagion Research Institute and ADL's Center on Extremism.

[http://ncri.io/about-us/](http://ncri.io/about-us/)

The Network Contagion Research Institute (NCRI) deploys machine learning tools to expose hate on digital social networks within a cross-platform, public- minded, and global framework. We are a multidisciplinary group of scientists and engineers who apply our technical skills to further public insight into the problem of online hate. We examine how hateful images and language grow within and between Web communities and how the infection of hate spreads between the online and the real world.

The condition of hate afflicts our capacity to see ourselves clearly, speak plainly to one another, and to assume collective and personal responsibility for our conditions.</comment>