Imagine a world where you are only allowed to work for cooperations such a this.
Putting all the bureaucracy aside, to be filtered like this is such a Kafkaesque feeling.
People in Japan reliably observe societal norms. If a capsule hotel floor is for sleeping and getting dressed, then the only noises you'll hear are people sleeping and getting dressed. Think of the door as a "quiet please" sign rather than a physical light/sound suppressor.
It's almost the opposite of the US, where people take pride in exercising their right to be assholes. Talking in movie theaters, taking speakerphone calls in public, watching videos on phone speakers in airport lounges, etc. are unimaginable in Japan but sadly commonplace here in the US.
In the hotels where I stayed, there were usually little airplane-style vents supplying cool air, so you could reach up to the top of the capsule and dial whatever level of ventilation you wanted. Barely audible.
The US is a big place. There are certainly huge areas of the country in which social norms have deteriorated to the point you’re describing, but it’s not the case across the nation. There are still plenty of small towns in rural US (and Canada) where speaking in a movie theatre, playing music on a bus, or littering on the street are generally not tolerated and at worst might even invite a polite confrontation. In the area I grew up and now own a home in, it’s not uncommon to see unoccupied roadside produce stands (with incredibly food) which are entirely cash and self serve. It’s not hard to explain why stands like that don’t exist in urban America.
I’ve spent half my time in NYC and Seattle the past couple years. I think it really can’t be understated how different rural and urban America are in their social norms and behaviors.
Agree. The language is different. The standard library is different. The runtime is different. The last two quite substantially at that. JavaScript is more like Ruby than Elixir is. I'm tempted to say Go and Jave are more Ruby than Elixir is.
FWIW, I've been using elixir for about a year now, and I think it's fantastic. I still use node & ruby for scripts (which can get complicated, but almost always for one-offs and asynchronous processing), Go for anything I actively want to share memory (though, started using Crystal, can't wait for threads), and OpenResty for any web proxy/middleware stuff. But Elixir is now the lions share for me and I find it fun and productive.
I want to build a language that focuses on developing microservices. Which should be performant and easy to write. This is why Rooby has Ruby's user friendly syntax and is written in Go."
At least Crystal brings new features like static typing, light threads, and compilation. From the README I don’t see what Rooby is bringing to the table.
Maybe not being static typed is what could make it appealing to Ruby developers. For example I don't like to have to declare types or generics. Type inference is ok.
There is a wide range of languages to pick the one that better suits our style from. That's great and I like that people keeps trying.
Static typing doesn’t mean you have to declare types. Type inference means you can write code just like a non-typed language but you get the safety + it executes faster. IMHO, except for toy languages, not having (strict) typing in 2017 is a language design flaw.
It's a tradeoff between safety and convenience. It's swinging toward safety now and it will swing back towards convenience again. At best we're living in a damped harmonic oscillator. Maybe type inference is the equilibrium point.
I still haven't found a clear answer to that, but using the LGPL license could pose a problem, because you need to allow the user to recompile the application with his own version of Qt.
On iOS shared libraries are not allowed on the store, so you should distribute the files for static linking... it becomes quite messy and sort of unclear from the legal point of view.
Even if it's wasn't clear before now it's pretty clear - you must buy commercial license if you want to be on App Store. There was Qt license change[1] in January 2016 and there is no longer LGPLv2.1 licensed version since Qt 5.7.
Only option for commercial software currently is LGPLv3 and it's doesn't allow tivoization.
Hey thanks. I wasn't aware of the dylib appstore restriction. Is this still the case with iOS8 and if not, could a dynamic LGPL Qt app be put on the store. I hope they allow this going forward.
The fun thing about printed books in Iran(well im not sure about other states but at least about Tehran) is that you can almost find any censored book you want if you try, maybe just not in the bookstores, perhaps street.
Also the censorship in Islamic TV is just stupidly ridiculous but it's not that stupid comparing it to printed books.
Another fun thing about this topic is that I wouldnt have heard about this biggest(?! come on :|) bookstore if it werent for the folk who submitted this link.
Hmm I actually like the fact that the arguments of a function are defined using square brackets.
It just reminds me of Clojure, especially the "defn" macro, which sounds pleasant to me.
I wonder what Lispers would say about that since I heard that not having a homoiconic syntax might cause some troubles at metaprogramming(macro) level.
It is homoiconic, because the data structures used to describe code are also data structure provided by the language. However, brackets mean that you pass arguments as arrays instead of lists: there is little reason except aesthetics to have this distinction in source code. I prefer parenthesis everywhere, but some people really dislike that.
I think vectors for argument lists is mainly a usability affordance. Which gives you aesthetics for free. (If you happen to find it more aesthetic.)
> Common LISP and Scheme are not simple in this sense, in their use of parens because the use of parentheses in those languages is overloaded. Parens wrap calls. They wrap grouping. They wrap data structures. And that overloading is a form of complexity by the definition I gave you. (https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)
Elsewhere, he critiques Clojure's use of vectors for argument lists. Because a vector implies order, so every caller must put arguments in the right order. (To decomplect, you'd use maps instead of vectors. But vectors win you brevity. Many notice that with longer argument lists, maps increasingly become more attractive than long argument lists.)
Should braces in both cases represent the same internal data structures? Probably not, the first one is for structure members and the other one for a block of statements. But in Lisp, characters are used to parse the same kind of data, which means they are same structure in all contexts. The Lisp reader has a simple approach to parsing, you don't generally change the readtable's binding based on which form you are reading (but strings, comments and code are not read the same way). Using different characters for semantics has its limit.
In Clojure, take [a b] out of context. Which element is evaluated, a, b, none or both? The fact that it is a vector does not help you, because it could be a binding, an argument list or a vector constructor.
Also, how something is stored inside the AST has nothing to do with its meaning at runtime. Argument lists could be passed using the stack, but you don't actually write a stack inside the source code. The fact that they are written as vectors or lists does not matter either, you still have to know the semantics. And semantics is almost never context-free.
I found that definition, applied liberally, lost its effectiveness.
I've never found the use of parenthesis to be an inhibiting factor in the complexity of Lisp code. It's a piece of syntax that has a single use and isn't ever over-loaded. A parameter list... is a list. A form... is a list with a specific structure. Surprise. The hyper-spec is very clear on this (i.e.: there is no over-loading).
I don't think his justification for [] was really necessary. If you want a different syntax for the defun macro you're free to have at it in Lisp. Clojure did nothing special there. Most schemes could interchange braces if you wanted to. You could easily write your own defn macro with your preferred syntax. It is no great innovation to use a different syntax so I don't know why he bothered making that remark about Lisp.
In most Scheme implementations, which this Lisp somewhat resembles, it's permissible to use "(" or "[" as long as the opening bracket matches the closing one. With that choice, each user can have the "esthetic" that is preferred. Personally, I agree that using parentheses exclusively is nicest, but it's not that big a deal either way.
I'm not familiar with Clojure, but briefly reviewed the Carp documentation, sparse as it is. The part about "[]" meaning array hadn't quite sunk in when I commented about the syntax. Thanks for pointing that out, the Carp syntax makes perfect sense. I think it's a project worth keeping an eye on as it looks like it could have interesting capabilities.
