Back in the end of 80s - 90s in the USSR/Russia were were lots of ZX Spectrum variants, and none of them had the ULA. They all were engineered to use the most popular and easy to obtain components.
It's the same concern I heard before the 1st Ipad announce: we want a MacOs on a tablet! No you don't. Coz MacOs apps knows nothing about the touch screen interface. And they know nothing about VR also, so nothing is changed here.
Do you realize that they all run the same kernel and OS underneath that's then restricted via feature flags? macOS can absolutely understand touch since it's all the same. This is also why their Continuity feature works so well, or why iOS apps can run natively on macOS.
In the sense that HackerNews, the non-startup promo part, is neither a "breaking news" site nor a vocational school. It's a social link posting website for things that interest hackers.
Whether the language is "old" or "dead" has absolutely no bearing to whether it's interesting, inspirational, worthy of study, and so on. Not to mention that hackers should know CS history too.
Actually, as Russian i know that most of classic Russian literature (before revolution of 1917) is highly depressing. I was attending a school while USSR was still alive, and even with relatively small number of classic russian books passed thru Soviet censorship, it was always like this: sad and depressing. Tolstoy, Nekrasov, Dostoevsky, Chekhov - no difference.
But to be fair, most of these systemd-[something] (sub)projects are part of "systemd", but not the systemd init system, which are different, apparently.
This is all right and all, but I have one question: why the hell it needs to be inside of a browser? To do what exactly?
I don't care about browsers, I care about applications. I don't want freaking Photoshop in my browser, because I want a browser to die.
This should be a part of the OS, not a freaking browser. Give me a built-in runtime with sandboxing, a delivery method, and an AppStore.
Give me next generation Java/Flash. I tired of a browser as an OS replacement. It is not and it shouldn't be.
Having the URL system also makes them so much better for sharing. Imagine being able to share a link that someone could click and it would open up your shared image inside of photoshop.
I do not see there any Elixir specific, it is all basically Erlang/Erlang VM/OTP stuff. When you using Erlang, you think in terms of actors/processes and message passing, and this is (IMHO) a natural way of thinking about distributed systems.
So this article is a perfect example how simple solutions can solve scalability issues if you're using right platform for that.
You're right. Elixir doesn't pretend to do anything except make using the wonderful erlang VM/OTP stuff easier.
The VM is an absolute marvel of engineering, and it's insane to me that it doesn't have more adoption yet in big tech companies.
My best theory is that engineers in top engineering companies are actually not the best engineers but simply career engineers that learn one skill (python/java/C++) and then explain to every employer that this technology is the best for the problem they have, over and over again.
Coordination problems get more difficult in larger teams/companies. Getting everyone to use a particular non-standard language is a coordination problem. Thus large companies are unlikely to experiment with languages.
It makes sense too - say it's 10x easier to write something in language X than Y. If there's only 10 other people that might interact with the thing / have to read the sources, that's a great tradeoff. If there's a thousand other people that might have to at some point understand how some part of your code works, suddenly all of them have to learn the new language X.
> and it's insane to me that it doesn't have more adoption yet in big tech companies.
elixir (and winter) is coming
> My best theory is that engineers in top engineering companies are actually not the best engineers but simply career engineers that learn one skill (python/java/C++) and then explain to every employer that this technology is the best for the problem they have, over and over again.
I am sure there are plenty of people who have a preferred Lisp. It does drive me nuts how if there is a post on R the top comments are people touting Python as being the bigger player in statistics and data science (Which it isn't) or a ton of other languages.
Came here to share my love for Racket. Parameterization, custodians, threading, channels, message inboxes, and the packaging tool is also great. I just recently published my first application to the Racket package repo, and I found it to be the least painful experience so far.
R is pretty pointless though. Unless you want to rewrite everything between prototyping in R and real deployment with a real language, you are better off writing in Python.
That right there is what I am talking about. I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years.
Why would you ever have to rewrite the code? Python isn't faster and has less function then R and if you want you can just drop a few lines of Python in a cell of a Notebook. I like Python and its a good choice but R is a great language that in fact that Python's pandas library is trying to make a R equivalent.
R is useful only more in pure analysis - interfacing to other systems and dealing with application/control logic is not it's strong point, so unless you are embedding R into a larger project (e.g. R batch scheduler), if you need these features, you'll likely need to rewrite.
>I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years.
That's not true though, R doesn't have anywhere near the ecosystem that Python does for Natural Language Processing, Web Frameworks, Machine Learning, Computer Algebra and Symbolic Reasoning, Systems Programming, Image Processing, Document Processing, and other things I don't know about but if I needed something else then I can use Python confidently that there will be good packages for them with a community around it.
The entirety of R's unique mindshare is that it has a million variations on linear regression and contingency table tests. And frankly they're all so simple to implement that if you can't be bothered to learn how to implement it in 2 lines of Python then you probably don't know what your program is actually doing.
R is something that caught on because it made its statistics package top-level, saving keystrokes for statistics and bio-statistics professors who never needed anything else and didn't know how to otherwise program. It's unique syntax has lead their poor students to have to learn C-family syntax many years after they could have been working and being productive with it.
Now some companies are accommodating R for their entry-level data scientist positions in order to hire cheaper help that can't find better options, but their skills are limited by being disconnected from the rest of the programming world in both packages and syntax.
Your comparing a general purpose language and a domain specific language.
Domain specific just talking in statistics and data science. I don't need a webframe work I need to make my report and have the charts work. I also push out my reports in Word and PowerPoint and I can't do that in Python but I can in R with ReportR library (The whole reason why I left Python and Pandas and came to R)
I say if you want to do more then the domain specific then sure Python is an awesome language and you can use your Python skills for more, but if you want the extras that the domain specific language gives you come on board.
To say R is a "Pointless Language" is very troll like especially with companies spend millions of investment and infrastructure that have come to R in the last 24 months.
I could also say what I always say about Python. It is the World's Great Second Best Lanaguge. It doesn't do anything "best", but it is a awesome second best and if that is fine with you have fun. I love Python but I also see the limits of the language. I thought 15 years ago Python would revolutionize everything and everything would be written in it. We now have Lua that took over for game scripting. We have C++ still ruling the day for applications. Web development has been dominated by JavaScript and Mobile development and Python is well .... So the two largest platforms aren't really impacted by Python.
> Now some companies are accommodating R for their entry-level data scientist positions in order to hire cheaper help
It isn't a clear picture but NO way is Python dominating in pay or work. R is a GREAT language and so is Python but for some weird reason Python community hates on R. While the developers of R and Python respect and work with eachother and help both sides. I am shocked you feel Python is so over powerfully awesome.
I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!
I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.
In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.
The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.
I think the motivation for making the sequence of arguments in function/macro definitions vectors instead of lists was primarily syntactic - to make them look different from the body. They're definitely vectors internally though.
To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.
If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader.
I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using data literals or tagged literals. There might be some random place where I need syntax beyond clojure's data literals, but I'm far more likely to use a combination of data literals + tags. If absolutely required (it hasn't been yet in 5 years of daily production usage), I could simulate custom grammar using clj-antlr and a macro. If, for some unknown reason, I needed a custom non-sexp grammar embedded in my lisp that I wanted to serialize exactly and then read back in the same syntax (probably because I hate myself and/or my team), I could hack it tools.reader.
tldr; you have reader macros if you want them. Nobody wants them who uses Clojure day to day. If they did want them, they could trivially extend tools.reader themselves.
Virtually nothing requires reader macros. That doesn't mean they aren't useful.
Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.
It has a reader as a library. It's entirely possible for you to change its lookup map to a defmethod and go to town altering s-expressions for arbitrary syntax if you wish. You're not hacking a new reader here, you'd refactoring something that probably should have been a generic method to begin with into one. Nobody has bothered with this because it's not useful to anyone, as far as I can tell. People who want non-data syntax write it with clj-antlr/instaparse (which are very easy to use) and use a macro when they want to interleave it into their code. These universally end up with a data-based AST that is readable and printable.
If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants.
There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as functions in the function position of an x-expression. There are things Clojure will not do such as reader macros. Clojure's syntax is a bit different, but generally reads cleaner in the same way one might say a font reads cleaner. YMMV.
> lists and other seq's as functions in the function position of an x-expression.
Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.
Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.
Pays back it code maintenance over time...
> but generally reads cleaner in the same way one might say a font reads cleaner.
I think it reads cleaner in the way PERL code is read cleaner.
Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.
Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.
But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.
I was under the impression that CL compilers already had to do a lot of fairly complicated static analysis to achieve acceptable performance, because of dynamic typing.
Depends. Since the developer can use low-level functions and provide type declarations, a compiler can generate usefully fast code without too much work. More advanced compilers need less declarations, since they do some amount of type inference. One of the costs: the compiler then usually is quite a bit slower.
>> The economist article actually provides a better solution. Visas shouldn't be tied to a particular employer. The employee should be able to transition to a new employer without a new visa application.
I'm surprised by the level of expertise, demonstrated by the economist, given the fact that current H1B system already works EXACTLY THAT WAY. H1B visa holder can transfer to a new employer any time, if new employer is willing to fill in the papers, even without notifying the current employer.
L1B visa is tied to a particular employer (because it just intracompany transfer), not H1B.
So i believe you still can build one for cheap.
This one was one of the most popular variants https://en.wikipedia.org/wiki/Pentagon_(computer)