Nim Community Survey 2019 Results - open-source-ux https://nim-lang.org/blog/2020/02/18/community-survey-results-2019.html <comment><AUTHOR> Funny, today's when I finally decided to start learning Nim. I do C++ with CUDA and Python on top for work. Having looked at the Arraymancer lib, I became interested in the language. Between its outstanding meta programming features and its ability to be compiled to C++, I think it is perfect for the scientific computing domain.

<comment><USER2> Thanks for pointing it out, that library looks quite interesting. A question: it mentions it "Supports tensors of up to 6 dimensions.". Sadly some of us have to deal with tensors of even more dimensions sometimes. Does Nim support some kind of equivalent to C++'s variadic templates that would allow creating tensors with an arbitrary number of dimensions?

<comment><USER3> Author here:

Actually it's 7 [1]

But in my future backend revamp I plan to make the default 6 [2]

Note that the line can easily be updated to

        const MAXRANK* {.intdefine.} = 6

as in the planned revamp and then you would be able to change the MAXRANK with a compile parameter

        nim c -d:MAXRANK=16 path/to/my/app

[1]: [https://github.com/mratsim/Arraymancer/blob/6fddfa9a734ac01c...](https://github.com/mratsim/Arraymancer/blob/6fddfa9a734ac01c13a9595adccaac571aa75093/src/tensor/backend/global_config.nim#L22)

[2]: [https://github.com/numforge/laser/blob/d1e6ae6106564bfb350d4...](https://github.com/numforge/laser/blob/d1e6ae6106564bfb350d4e566261df97dbb578b3/laser/dynamic_stack_arrays.nim#L6)

</comment></comment></comment><comment><USER4> Nim would be really competitive in the gamedev/graphics field if there was a standard library that you can use without the GC. (Technically you can turn off the GC entirely, but you can't use the current standard library without it.) The language's especially good for gamedev because of its extensive metaprogramming facilities, a sane build system (which lets you write build scripts with a subset of Nim itself), and the fact that you can load C/C++ libraries with ease.

<comment><USER5> Unreal and Unity appear to be quite competitive with GC.

I love Tim Sweeney quotes:

"Programming languages without garbage collection send us down a long path of design decisions that lead to slow compile times and fragile runtime performance cliffs."

[https://twitter.com/timsweeneyepic/status/122367043109542707...](https://twitter.com/timsweeneyepic/status/1223670431095427072)

"It's interesting that many games can afford a constant 10x interpretation overhead for scripts, but not a spikey 1% for garbage collection."

[https://twitter.com/timsweeneyepic/status/880607734588211200](https://twitter.com/timsweeneyepic/status/880607734588211200)

<comment><USER6> Except, especially regarding the former tweet, I get the impression that he's having a pipe dream (with all respect), and he's heavily criticized. Did he actually program anything serious recently? He seems to be mostly tweeting about languages instead of actual technology.

Honestly I can't make sense of what he's saying there, so there's a chance I'm not getting an important detail, but GC has nothing to do with function specialization. What does the following even mean?

> Without garbage collection, offering an array of bytes where an array of > integers is required requires stack-allocating an array of integers and > converting each byte to an integer every time a subtype is used in place of > an actual type. This is so absurd that it's not done.

The only interpretation of this that I can come up with would be just factually wrong.

<comment><USER5> Except that ignores the small detail that his company is selling a game engine with heavy use of GC, via Blueprints and C++ classes marked as UOBJECT.

I bet he understands one or two things about shipping games with such engine.

The sense I get from those tweets are the usual anti-GC discussions, mostly by folks that usually are even against modern C++ (as recently seen on some C++20 related discussions), which eventually derailed the discussion into something else.

<comment><USER6> > Except that ignores the small detail that his company is selling a game > engine with heavy use of GC, via Blueprints and C++ classes marked as > UOBJECT.

Yes I've heard that there are some high-level things and _some_ amount of GC in there. And I'd wager that this is about where _your_ knowledge about UE ends as well. If that is so, better don't make bold statements like "heavy use of GC".

And Mr. Sweeny is obviously not only accomplished, but extremely sharp. But being sharp doesn't protect anybody from buying into stupid ideologies without any actual real world validation.

Just as it doesn't protect HN trolls from collecting little factual nuggets from the internet and then spreading misinterpretations (i.e. falsehoods) hundreds of times. For example, the kind of "Data oriented design" that has been all the rage recently is so definitely no concession to OOP.

Regarding Mr. Sweeney, the German Wikipedia page for example states that he didn't have any significant programming involvement anymore since Unreal Engine 3 (which was released in ~2006; Unreal Engine 2 was released in ~2002). Regarding programming, all I've read from him on twitter was just language related stuff, frequently mentioning theoretical blah-blah, such as covariance, monads, higher-kinded, blah-blah, and oh it is sooo practically relevant that C function pointer syntax is unusable if you want to return pointers to functions that return pointers to functions that return pointers to functions...

> The sense I get from those tweets are the usual anti-GC discussions

I suggest trying to make sense of his actual statements in the first place. Any offering from your side is very welcome! Again, I'll collect all the arrogance that I have in me, to criticize this man, who is obviously much sharper than myself, of blathering in this tweet a load of BS that hasn't undergone real world validation.

Again, I might be missing the valid interpretation of what he's saying, but to me all evidence points to him needing a little refresher regarding the real world, in practice.

<comment><USER5> Any C++ developer worth their salt is perfectly able to understand that blah- blah.

<comment><USER6> You know, I once learned category theory, at least to the point where I could explain from the ground up what a monad is, as well.

And the most important thing I've learned in the process is that these theoretical buzzwords don't have any relevance to programming whatsoever. This theory stuff is not a means to an end. It's a means unto itself.

> My answer to this is: the ultimate type system is constructive logic > (following the proofs-as-programs direction), the ultimate typechecker is a > theorem prover, and theorem proving technology improves over time. > [https://twitter.com/TimSweeneyEpic/status/123141241308757196...](https://twitter.com/TimSweeneyEpic/status/1231412413087571968)

People who say such things have simply drunken the kool-aid, big time. When it's about practice instead of theory, I prefer to listen to people who have actually made stuff in the last decade.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> 25% reported having never used the language. Surprising that so many people outside the Nim development community would fill out this survey.

<comment><USER8> I used it a few times before but I stopped once I realized it was a long way off from being worth using.

The lack of tooling, libraries, and numerous compiler bugs meant that it would be easier for me to write the same thing in C++ even though nim is a superior language.

I'd imagine many people came to realize this before even trying it out.

<comment><USER9> how long ago? I tried it maybe 3 years ago or so, and also ran into a lot of compiler bugs, which I reported. The good news is I saw all of them get fixed! Haven't tried the language since it hit 1.0 recently.

<comment><USER8> I don't remember, I tried it out a little before it was renamed from Nimrod I think.

<comment><USER10> I don't think you should be commenting about the current state of the programming language (which is how your first comment comes across) if you haven't used it in over 6 years.

<comment><USER8> I tried it a few times after that and it still seemed like it was many years away from being competitive with C++/Java/Go

</comment></comment></comment></comment></comment></comment><comment><USER11> Very happy to see Nim gaining some adoption. I started using Nim about a year ago and could not be happier with the language.

I do wonder what it might take to take Nim towards "main stream" status.

<comment><USER12> I think it needs a "killer library". The core language is pretty easy to learn if you've used Python, but there aren't a ton of third party libraries, and the ones that do exist seem to be incomplete, poorly documented, buggy, abandoned, or some combination thereof.

<comment><USER13> I got annoyed when it didn't have a decent standard library to handle command line flags and arguments.

The examples given so far, are mediocre.

parseopt is incredibly cumbersome.

docopt is an incredibly poor design, that I can't believe anyone thought this was a good idea.

And failing to have such basic libraries, I realized, this language has a long way to go.

I contemplated building my own library to handle such a need, but why, this doesn't solve my problem of building something. And if it's missing such basic libraries, then what else is it missing? The odds were too great, and too risky for me to commit my time to it.

<comment><USER14> There are many libraries for that, but I suggest cligen. It is the simplest command line parser I have found across all programming languages.

<comment><USER15> What if the Nim maintainers made some kind of continuous popularity measurement to let good libraries bubble up? Opens other problems I know, but may fix such scenario and accelerate Nim adoption?

<comment><USER14> There was an attempt a few months ago, but it was a little weird. But if you just want to find libraries relevant for your task (e.g. parsing the command line), there is [https://nimble.directory](https://nimble.directory) where all Nim libraries are listed

</comment></comment></comment></comment></comment></comment><comment><USER16> Speaking for myself, as an absolute novice, OOPs in Nim is not great. it feels shoehorned in, rather than being a primary citizen of the language design. There is too much fiddling with methods vs procs, pragmas and such involved for the most basic stuff.

I am tinkering on a small 2d game using Nim. I was planning on using OOPs for most of my game objects. Now I am debating if I should make the effort to actually learn OOPs the Nim way or just do it procedurally.

Considering that my project is tiny, I might go for the latter and skip OOPs altogether. So for me right now Nim is a better C, with nicer syntax, simple build system and a package manager.

<comment><USER17> I would say that this is in some ways by design. Nim offers some OOP features, but in general does its best to discourage the use of OOP. In that sense I would say you should skip OOP and implement everything in a procedural style (it will be more efficient too).

<comment><USER18> The only OOP-ish thing I've really missed in nim is interfaces. It seems to be a really convenient way to re-use code: "this function (proc) can operate on any type that has implementations of this and that other function (proc)".

Googling has left me with suggestions of using macros to re-implement similar functionality, which I guess is in line with nim's philosophy of "small core with powerful macro system". Looking into it however, developing macros seems like more effort than a simple interface.

Just the impressions of someone not super familiar with metaprogramming.

<comment><USER17> The idea I think is that someone needs to implement it using macros and get it into Nim's stdlib. Then we can all make use of it. If you're passionate enough about interfaces then you may just be able to implement something that works beautifully and get it merged into stdlib (that would be awesome).

</comment></comment></comment></comment><comment><USER19> I wonder what causes the strong European bias in the results, in general in those surveys I'm used to seeing USA #1.

Beyond that it actually looks pretty good for the language, it seems popular among experienced developers and they seem pretty happy with it and consider using it for serious work (although obviously the fact that they even bothered to reply to the survey probably biases that).

<comment><USER20> Of the top ten contributors on github, nine of them are Europeans. I think all nim meet-up/conferences have been in Europe.

Makes me wonder if the language would have more mainstream traction if it was more of a US project.

</comment></comment><comment><USER13> I like the Nim syntax, but I'm not certain why they chose to transpile it to C.

Why not just go all the way, and encode it in assembly?

Yes, I understand their reasoning, to make use of all the advanced C compilers out there. And to make the code compatible with existing C libraries and APIs.

But I feel this is more of a shortcut, and a crutch, that will prevent them from fulfilling their expectations, of being a C language and systems programming replacement.

I think the better approach would have been to target assembly code instead, and then, build connections to existing C APIs.

<comment><USER21> D doesn't compile to C code because I found C to be a rather limited platform. By generating native code, I could go beyond what C supported. The vagaries of various C compilers was also a problem.

<comment><USER22> Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?

<comment><USER21> 1\. cannot support anything but the C ABI

2\. cannot support exception handling

3\. cannot support types that C doesn't

4\. stuck with C symbolic debug info, not your language's

5\. cannot innovate with things like how strings are stored

6\. many C compilers do not emit COMDATs

7\. no thread local storage

8\. chained to slow compilation speeds

9\. stuck with trying to find a way to work around C compiler bugs

10\. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers

11\. C compiler can change, breaking your compiler

The original C++ compiler, cfront, had a LOT of problems with these issues.

<comment><USER22> Thanks for taking the time to respond, compilers are always interesting to learn about!

Point 7 was (finally!) addressed by C11.

Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me.

It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome.

On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system.

[1] [https://wiki.call-cc.org/chicken-compilation-process](https://wiki.call- cc.org/chicken-compilation-process)

[2] [https://www.cliki.net/ECL](https://www.cliki.net/ECL)

[3] [http://www.gigamonkeys.com/book/beyond-exception-handling- co...](http://www.gigamonkeys.com/book/beyond-exception-handling-conditions- and-restarts.html)

<comment><USER21> 2\. yes, it can be done with setjmp/longjmp, but that's a terrible solution

3\. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck.

I looked at the C code generated by C++ cfront. No thanks.

The worst is, the C compiler vendor owns you, and they couldn't care less about you.

</comment></comment></comment></comment></comment></comment><comment><USER23> Just discovered the HN 'past' tab. Went back 5 years in order to find something that also appeared today. Nim was the only topic I found in a front page article today and 5 years ago. Maybe just random but I'll give it a try and report back.

</comment><comment><USER24> > _Efficient, expressive, elegant_

      let people = [
        Person(name: "John", age: 45),
        Person(name: "Kate", age: 30)
      ]

Verbosity at its finest. Compare with C++:

      Person people[] {
        { "John", 45 },
        { "Kate", 30 }
      };

<comment><USER25> This is a false comparison because you're really comparing by-order-of- argument initialization/construction ("BOA constructors") versus keyword-value initialization/construction.

BOA is more compact, but it's possible to get the arguments wrong, and the type system won't save you if you exchange two arguments of the same type.

There is no reminder anywhere that 45 and 30 are ages.

That's also true in function calls that do not use keyword arguments (the vastly prevalent paradigm in mainstream languages), but function calls specify a function name which can reveal something, like set_age(john, 45).

Some languages have both.

No knowing anything about Nim, I have no reason to believe that it has no way to achieve a compact way for initializing an array or list of objects using just positional arguments, and no repetition of the type name. If nothing else, surely there has to be a way to write an array of tuples, and that aggregate can surely be passed to some function that iterates over it and constructs the implied Person objects.

On the C++ front, I seem to recall C++ recently adding C99 designated initializers or planning to. If so, then { .name = "John", .age = 45 } will be possible, and C++ coders will end up using it.

<comment><USER5> C++ designated initializers are not like C99 designated initializers, rather a subset.

For example, just like initialization lists on constructors, initialization order is relevant.

<comment><USER25> Order is unspecified in C initializers, including designated ones. That quickly becomes relevant when the program depends on it for expected behavior.</comment></comment></comment></comment>


Texas holds firm on physics closures - <AUTHOR> http://www.nature.com/news/2011/110924/full/news.2011.559.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+news%2Frss%2Fmost_recent+%28NatureNews+-+Most+recent+articles%29&utm_content=Google+Feedfetcher <comment><USER2> This plan runs the risk of lowering the standard for graduation in order to increase the number of graduates instead of its intended purpose which is to increase the quality of the instruction/instructors.

<comment><USER3> I doubt the issue is difficulty. It's probably an issue of enrollment/retaining students in the major.

<comment><USER2> You might be right, but this quote is what leave me to believe they are talking about quality of instruction, rather than enrollment issues:

"Until now, most faculty members thought their role was to do research and teach courses they were assigned. Now, researchers at institutions in Texas are going to have to take responsibility for students graduating successfully,"

</comment></comment></comment><comment><USER4> It sounds like Texas is doing the taxpayers a favor.

 _...Mario Díaz, a physicist at the University of Texas at Brownsville...says his department was able to raise more than US$5 million for research on gravitational wave astronomy from the US National Science Foundation, in part because reviewers were encouraged by the prospect of enticing minority students into science._

Now that Brownsville's physics program is kaput, maybe the NSF will be forced to send money to someone who is actually good at gravity wave astronomy?

(I'm assuming, based on the statement quoted above, that Diaz would not have gotten the grant on pure scientific merit. If this is incorrect, his claim is pointless.)

<comment><USER5> Are you familiar with his research? As much as I dislike affirmative action, I find it difficult to accept that as justification for writing off his work.

<comment><USER4> Did you read my parenthetical statement?

I don't know much about his work, and I fully realize it is possible that he might have gotten the grant even without minorities (in contradiction of the statement he made).

In that case, his statement is entirely pointless, since he would have gotten the grant with or without a physics undergrad program.

<comment><USER5> I can't believe I'm saying this but, is it constructive to be so critical in the absence of any apposite information?

<comment><USER6> if anything, google search for "gravitational wave astronomy" returns UTB CGWA as the 2nd result.

Besides, even OP states that affirmative action was only "in part" responsible for funding success.</comment></comment></comment></comment></comment>


Tesla Strikes Deal With Shanghai to Build Factory in China - <AUTHOR> https://www.wsj.com/articles/tesla-strikes-deal-with-shanghai-to-build-factory-in-china-1508670181?mod=e2fb&mg=prod/accounts-wsj <comment><USER2> The 5% stake in Tesla Tencent took a few months ago was extremely strategic. Not only did Tesla get some much needed capital for Model 3 production, I'm sure Elon's friends at Tencent were happy to introduce Tesla to the right people in the Chinese government to make this deal happen and boost their Tesla stake. A crucial step as China will likely soon represent the biggest market for EVs (if it isn't already?). Just goes to show every entrepreneur how valuable equity in your company can be not just for access to capital, but also access to people.

<comment><USER3> It's a bit sad that some Governments exercise so much control on businesses and knowing the right people means so much.

There should be a Goldilocks zone between Laissez-faire economy and extreme regulation.

<comment><USER4> "...knowing the right people means so much."

Doesn't it everywhere in life? Unless one prospects gold in the wilderness, I suppose.

<comment><USER5> Interesting that HN tend to swing between two extremes in this: "it is meritocracy, all is just about work" and "everything is corrupt and based on who you are friend with" (plus some who attempt to frame latter as former through it is not).

<comment><USER6> Keep in mind, HN isn't just one person.

<comment><USER5> Yes, but it as if the two groups never met, I don't recall discussion between the two. Also it is as if there would not be people in the middle (where I am) .

</comment></comment></comment></comment></comment></comment><comment><USER7> Seems like Tesla has been eying this move for over a year. Bloomberg [0] broke this story last year (June 2016) saying Tesla planned to invest $9 billion in Shanghai, according to a 'person with knowledge of the matter'. However, one key point from last year's article is:

 _Manufacturing in China would allow Palo Alto, Calif.-based Tesla to avoid a 25% import levy, making its electric vehicles more competitive against luxury- brand rivals, such as BMW and Audi, as well as local offerings by BYD and BAIC._

Last year, it sounded like Tesla's motivation to manufacture in China was to avoid this tariff. Now today's WSJ story says Tesla is still likely to pay the 25% tariff. Sounds like Tesla got shafted by Chinese protectionism.

[0] Non-paywalled Bloomberg article [http://www.industryweek.com/competitiveness/shanghai-said- be...](http://www.industryweek.com/competitiveness/shanghai-said-be-front- runner-tesla-china-production-site)

<comment><USER8> I thought China was part of the WTO and has most favored nation trade status with the US. Does the US have such high import taxes on Chinese goods? I don't think so. Googling around I found this[1] 2014 article about unfair taxes on US cars and a win for the US in the WTO court, but maybe China just ignores that ruling. It does not seem reasonable for the US to allow China to impose taxes and force tech transfer from the US, especially since the US has such a high trade deficit with China. There was some talk about this problem during the US election, but I have not seen any action on the issue yet.

[1] [http://www.latimes.com/business/la-fi-wto-autos- china-201405...](http://www.latimes.com/business/la-fi-wto-autos- china-20140524-story.html)

<comment><USER9> I think your comment needs a historical perspective. Protectionism and tariffs played an important economic part in the rise of all of the current world superpowers. Pretty much everyone from the USA, to GB to Sweden practiced heavy protectionism through tariffs and subsidies (which also featured in the civil war). While you can pick any window in history and adjudicate whats "fair", the alternative to "Chinese are sneaky" is that they're simply doing what others did before them to become dominant.

<comment><USER8> If you read my comment I am not talking about "fairness" or advancing some crypto Chinese racism. China is doing great and advancing quickly. Good for them. My perspective was from the other side and questioning weather or not the policy from the US side is a net good for the people in the US, aside from the top 0.01%.

<comment><USER9> I'm not suggesting you personally harbor ill towards them in a racial way. I could have worded it better, sorry ! My comment was political. A lot of commentators here seem to not understand the historical perspective on tariffs, and subsidies and protectionism.

I think people understand the 'every country will look out for themselves' part. What a lot of people don't is the 'this is what we used to do too' part.

</comment></comment></comment></comment></comment><comment><USER10> I wonder how concerned they are about leaking proprietary technology from Chinese employees. Apple constantly struggles with this since the employees are paid little, but the incentive to leak and "share" information is very lucrative.

<comment><USER11> I thought Tesla (unlike SpaceX, due to ITAR/etc.) was pretty open with their technology. I assume Elon would be happy if all of the non-EVs in China copied Tesla. OTOH, I think the Chinese market actually already has better EVs for 90% of the Chinese market, and the market for Tesla is the high-end prestige market which wouldn't be so affected by copying (they don't copy BMWs today)

[https://www.tesla.com/blog/all-our-patent-are-belong- you](https://www.tesla.com/blog/all-our-patent-are-belong-you)

<comment><USER12> I believe this only applies to charging tech so that the whole industry is standardized for charging stations. I don't think Tesla shares any of their chemistry, power management, and other high value IP.

<comment><USER13> As far as I know, it is _all_ patents. Here is another source, as linked in my above post:

[https://www.wired.com/2014/06/tesla-just-gave-all-its- patent...](https://www.wired.com/2014/06/tesla-just-gave-all-its-patents-away- to-competitors/)

<comment><USER14> From the article:

> Tesla CEO Elon Musk announced today that his company will not "initiate > patent lawsuits against anyone who, in good faith, wants to use our > technology."

The question really is - what defines "good faith" for Musk and Tesla.

Additionally, I am no patent expert but it will be interesting to see licensing terms, if any. Specially after what happened with React and Facebook.

<comment><USER13> The link in another response to me has a link to a clarification video from Musk. I didn't watch it, as the text was adequate. It looks like no licensing is required and that they've been legally dumped into the public domain in a binding fashion - maybe. That's not actually ever been ruled on in a court, from what I can find via Google.

That post suggests no company legal team would allow it. The article thinks Apple might use it, as an example of a user.

I am no expert, so I'll defer to others.

</comment></comment></comment></comment></comment></comment><comment><USER15> This should be a boon for China's air quality if they start to mandate EVs and ban fossil fuel vehicles. They are suffering from major, major pollution that makes 70's LAX smog look like child's play

<comment><USER16> I'm not sure EVs are going to make a difference unless they move from coal plants to something else.

<comment><USER17> Coal plants are more efficient than internal combustion engines.

<comment><USER18> At generating energy? Yes. At emissions per watt? Not necessarily. Coal is much, much dirtier fuel than gasoline.

<comment><USER19> Metropolitan emissions per mile would be the important metric, since gasoline in cars is at most ~30% efficient, and coal plants can be built away from the city.

</comment></comment></comment></comment></comment><comment> dis-sys People need to understand that 25% import tax is a feature not a bug, it allows Tesla to be classified as imported cars, separating itself from a long list of American/German cars made in China with a local partner. There are huge demand for such "imported" cars. Look at Porsche, every single one of its cars are imported into China with stupidly high taxes, yet 1/3 of its global sales are in China, you need to wait 3-6 months to get the most popular models (Macan and Cayenne).

<comment><USER20> Can a "cultural translator" explain why the Chinese consumer market is so highly susceptible to Western marketing of import brand marks, for highly- specific products, when otherwise they appear strongly nationalistic?

This doesn't seem to broadly carry over into all products. My gut-feel impressions from visiting China: Cars, yes. Phones, no. Scotch, yes. Watches, no. Clothes, no. Houses, no. Household appliances, no. Bottled water, no.

Americans have their yes/no list, various European citizens have theirs, and so on. And there are sub-groups (like I'm aware of a market for ultra-premium watches with 5-figure+ USD price tags among some hedge fund types), but I'm interested in characterizations at a broad national level. I'm curious to hear from Chinese or Chinese culture-fluent what factors in their opinions went into the make up the Chinese national variant of this list.

<comment><USER21> I'd just like to modify your list in that I think wealthy Chinese consumers are highly susceptible to certain designer clothing and accessories, ala Gucci, Louis Vuitton, etc.

I think everything else can be explained by a sort of clash between utilitarianism and a desire for status symbols. Tools that can be readily copied in China and produced much more cheaply are sold as that: tools. So phones, watches, appliances, etc. Cars and clothes can also be readily copied, but even in the west they show more status than the other things listed. So when it comes time to copy them, it's more apparent when you have a Chinese knockoff vs. an "original".

Scotch is hard to copy.

<comment><USER22> 1) Status 2) price+quality 3) localization 4) regulation 5) not necessarily in this order

For instance take a look at Xiaomi phones. They are better in every aspect than any western phone you could find in the < 500$ price range.

Western cars are designed for regulations that don't exist in China, think of emission controls and safety. Local manufacturers don't bother with that. Expect any western car to be overpriced and inappropriate for the china market.

Truly luxury brands like Apple and Porsche makes it because of status.

<comment><USER23> That's probably why the wealthy are buying Western cars, they're safer. Hard to be rich when you get crumpled like a tincan in a locally produced vehicle

</comment></comment></comment></comment></comment><comment><USER24> China doesn't believe in IP. Tesla should look within 1-2 years of startup of a Chinese plant for there to be other Chinese plants producing the exact same parts, but not for Tesla. If Tesla puts its "magic smoke" into that factory, they have given it away to multiple competitors.

<comment><USER25> That would however be in line with Tesla's stated mission:

 _The Mission of Tesla. Our goal when we created Tesla a decade ago was the same as it is today: to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to market as soon as possible._

</comment></comment><comment><USER26> This stinks of my cynicism, but I hope Tesla doesn't mind competing with unbranded, unlicensed Chinese copies of Tesla-designed vehicles.

Based on their blanket grant of royalty-free patent licenses, I wouldn't think so, but that might just be the sort of idealism you see when a competitor doesn't have you up against the ropes, pummeling the snot out of you. It's one thing to go read the patents and maybe add the parts you understand to your product. It's another thing entirely to be able to observe an entire functioning assembly line and copy it down to the millimeter.

And that is something that will happen to any factory Tesla sets up on mainland China. Then they start chopping off the more expensive bits. Tesla must be betting that the x% of the Chinese market that cares about brand and can also afford to pay for genuine goods would buy a real Tesla instead of a nigh-identical knockoff, at rates high enough to be significant against the 25% tariff. That kind of financial math is beyond my expertise, though.

</comment><comment><USER27> Wonder how this will impact the model 3 backlog. Many of the Tesla fans have bought into the US made, green, and disruptive angles - in various levels of importance.

Will be interesting to watch how the backlog develops with this change. Could be quite significant.

Also if we factor in the layoffs last week in California and now this move how long until Trump takes a punch on Twitter as Tesla?

</comment><comment><USER28> now let's see if chinese made teslas will be of higher quality than U.S. made units. The bar is set pretty low right now to surpass U.S. Tesla build quality.

</comment><comment><USER29> Why are there still import tariffs in the US?

<comment><USER30> Because Americans prefer to vote for politicians who take payments from industry groups in exchange for setting tariffs that protect them from international competition.

<comment><USER31> Are there car-producing countries that don't have import tariffs?

</comment></comment></comment><comment><USER32> What

<comment><USER7> _Edit: The parent comment was orignally asking about linking to non-paywalled secondary sources._

In the HN guidelines [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

> _Please submit the original source. If a post reports on something found on > another site, submit the latter._

Also, on paywalls [https://news.ycombinator.com/item?id=10178989](https://news.ycombinator.com/item?id=10178989)

<comment><USER33> So knowledge should be trapped behind a paywall?

<comment><USER34> We've been through this countless times, which is why it's in the FAQ. Paywalls suck, but HN would suck worse to do without NYT, WSJ, Economist, and New Yorker articles, to name a few. It's the lesser of two evils and it's off- topic to endlessly litigate this.

</comment></comment></comment></comment><comment><USER35> Bye bye US Government subsidies.

</comment><comment><USER36> To be read as the beginning of the end of Tesla factories in the US.

<comment><USER37> I doubt Tesla will give up on their U.S. factory, unless the company ever enters dire financial trouble. There have been (and still are) major auto makers with factories in the U.S. It is to their advantage to operate more than one factory if ever there are labor issues, governmental issues, or even natural disasters that could stop production.

<comment><USER27> I suspect US will be reserved for high end S/X models, with the model 3 likely majorily in China.</comment></comment></comment>


[pdf] Haskell sucks - <AUTHOR> https://dl.dropboxusercontent.com/u/40457956/haskell_sucks.pdf <comment><USER2> Fyi, the cutesy title doesn't make it obvious but the bulk of the slidedeck is about explaining 2 concepts: Monads and Lazy Evaluation.</comment>


Who wants a RIM job? BlackBerry maker is Canada's 'Most Attractive Employer' - <AUTHOR> http://www.techvibes.com/blog/rim-is-canadas-most-attractive-employer-2011-09-30

<comment><USER2> They may be the most attractive company as noted in the report, but what about the job security there?

They recently fired 10% of their global workforce: [http://betanews.com/2011/07/25/rim-begins-round- of-2-000-emp...](http://betanews.com/2011/07/25/rim-begins-round- of-2-000-employee-layoffs-in-america-this-week/)

</comment><comment><USER3> Wow, thanks for the NSFW title...</comment>


Portrait of the CEO as Salesman - <AUTHOR> http://www.inc.com/magazine/19880301/5901.html

<comment><AUTHOR> This is my first submission to HN.

In startups, I think we by-pass a lot of the traditional schools of thought and jump directly into hacks/objects/apps/fixes which we consider "startups."

As a startup myself, I've lost sight of the most important part of building a business: sales. Tech, product, marketing, "sales" (free users) are great, but at the end of the day, to move a company from a startup to a business is hard work and can only be done with sales.

And if there's one article that sums up exactly what I should be doing, it's this.

Thought I would pass this along and hopefully change the attitude of others in our community.

<comment><AUTHOR> TL;DR:

"So what the hell are you doing buying a computer?" he demanded. "You know, Jim, I've seen a lot more businesses go broke because they didn't have enough sales than I've seen go under from lack of computers. Why don't you work on first things first?"

Selling is a devalued skill. It's considered beneath anyone with an M.B.A.'s training. Marketing, on the other hand, is somehow "clean," something professional businesspeople aspire to. If you go to a cocktail party and you're asked what you do for a living, and you reply, "I'm a salesman," people look at you like you've got crumbs on your shirt. Tell them you're a marketing director, however, and they say "How interesting." In my view, this is one of the worst hoaxes ever pulled on American business. Manufacturers perceive marketing as a magic solution that takes away their responsibility for making good products. Their idea is, we'll make a product that's just as good as anything else out there--not better, mind you, but just as good--and marketing it well will make us rich. And that's a lot of crap.

Marketing is all about creating, in the customer's mind, a value that does not exist: a way of differentiating a basically undifferentiated product and charging the consumer more money for it. Selling is fundamental.

Consumers are not idiots. They want detergents that get their clothes cleaner, not detergents with slicker advertising campaigns.

Because, sad to say, it's a lot easier to differentiate your product through the quality of the marketing than through the quality of the product. To go back to the automobile industry, it's easier to change your advertising campaign than it is to build a better car--as General Motors well knows.</comment></comment>


How Android's "won't fix" problem is the result of poor standardization - <AUTHOR> http://gbl08ma.com/how-androids-wont-fix-problem-is-the-result-of-poor-standardization/ <comment><USER2> By contrast, Chrome OS (which intentionally avoided this whole problem by taking OEMs and hardware vendors out of the update process) doesn't have this problem.

That said, it's not obvious that Android would have been able to spread as widely as it did if it had cut out the handset vendors and carriers sooner. An Android that solved that problem might not have become the Android on the majority of phones and tablets everywhere.

<comment><AUTHOR> That's true, however, Chrome OS still suffers from the upgradability issue I described, but of course that is more of a personal rant about today's state of things and the fact that due to users' inability to easily tinker, everyone is left with devices that "just work" but will never "work" much beyond what they "worked" when they were bought (as things evolve, they will actually become less capable).

I wonder if the low market share of Windows Phone (the only OS really comparable to Android in this case, as iOS is Apple-only and all others are insignificant) has to do with OEMs not having as much control over the platform as they would like. For example, and just about looks, Android allows for things like TouchWiz and Sense, whereas as far as I know, Windows Phone does not. I have always felt that brands with both Android and WP phones to sell, don't advertise WP ones nearly as much as they could, which certainly influences the market share. In fact, with WP having a lower market share, I think it would make sense to favor advertising models with it, instead of Android ones? With the exception of Nokia of course, but that is a "special" case.</comment></comment>


Ask HN: What's a good business model for a product like Keybase - <AUTHOR> What are some ways a company providing services like Keybase can sustain itself and have a healthy business model. <comment><USER2> Open-core, or fully open-source with paid offerings (e.g. Zulip -- see tabbott's comment below [0]).

Let the DIYers host their own instances, but offer support and/or on-premise deployments for a fee. It seems to be what Mattermost, Zulip, and others are doing with some success.

Mattermost also includes use of their mobile notification relay servers in their paid offerings, which is compelling, because otherwise you have to build _and distribute_ your own mobile apps.

[0] edited to include reference to important comment

<comment><USER3> Just to be clear, Zulip is not Open Core. We are 100% open source software, in contrast with Mattermost, GitLab, and many (most?) other VC-funded applications marketed as "open source".

I think this is a really important distinction; the VC-funded open core business model has a fundamental incentive structure that pushes the company to makes its open source project an intentionally crippled demo product so that they don't miss any revenue they might have had as a proprietary product.

<comment><USER2> Thanks for clarifying -- I've edited my comment to make that more clear. And thanks for your work on Zulip!

</comment></comment></comment><comment><USER4> Free for personal and small team use to gain brand and product awareness, then charge for support, additional features, higher usage limits, etc.

Basically the same as Slack, Trello, etc.

Be careful with per-user billing though, as this puts a lot of big enterprises off.</comment>


The future of jobs: The onrushing wave - <AUTHOR> http://www.economist.com/news/briefing/21594264-previous-technological-innovation-has-always-delivered-more-long-run-employment-not-less <comment><USER2> They estimate in their chart that Athletic trainers have a 0.007 chance of being automated, the third lowest chance after therapists and dentists.

it's hard to know exactly what they class as "Athletic trainers". For Olympic athletes, there will always be staff. For the rest of us, what would that "unlikely" automation of the coach look like? Perhaps it would start with a movement sensor on the wrist? A smartphone app to track and recommend exercise?

That's not looking unlikely to me, it's looking like it's already here in plain sight:

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

[http://www.microsoft.com/microsoft-band/en- us](http://www.microsoft.com/microsoft-band/en-us)

[https://play.google.com/store/apps/category/HEALTH_AND_FITNE...](https://play.google.com/store/apps/category/HEALTH_AND_FITNESS)

<comment><USER3> Yeah, the same chart lists a 17% chance that "firefighters" will be automated... I'm equally curious what then definition of "firefighter" is. If they are talking about woodland (or "forest") firefighting, then _maybe_ (I could see drones accomplish at least some of the tasks involved). But for structural firefighting? No way... Not in 20 years.

<comment><USER4> Why not? Is it the chaotic environment? The temperature extremes? The unpredictability of each situation?

All those are strong reasons TO automate firefighting. Machines can function better in heat/smoke/violent structural collapse situations. They can make objective analysis when their own mortality is not an issue.

Nobody made money betting against advances in computing.

<comment><USER5> But to replace a fire fighter would require order of magnitude discoveries in several fields you would effectively need true AI and a self powered robot with as good strength and endurance as a human.

<comment><USER2> Don't assume that the robotic solution will look anything like the human solution. A fitbit does not look like a "robotic personal trainer" and a roomba does not look like a person with a broom.

I would speculate that the obvious next wins for fire-fighting are drones to visualise the scene from multiple angles, remote control or self-aiming hoses and extinguishers. And various hardened eyes and arms to reach into the fire. All with human oversight, but a reduction in the number of humans involved or in harm's way.

This reduction in manpower is the pattern - e.g. supermarket self-checkouts still have some human staff, but to troubleshoot and supervise.

<comment><USER3> I'm actually most of the way done with a prototype of a quadcopter that can be deployed on a scene that just orbits and streams video to a monitor in the chiefs vehicle. It's mostly off the shelf components, with a little bit of 'wrapper' that makes is easier to deploy.

The biggest issue I haven't sorted out yet is the batteries... LiPo batteries are great in terms of capacity/weight, but if you keep them fully charged all the time, you kill them pretty quickly...

<comment><USER5> Ok can this go into a burning building find trapped people and carry them out?

<comment><USER3> No? That's well outside the scope of its design... what's your point?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> There's a great 15 minute video by CGP Grey introducing the same set of concepts that technology will contribute to unemployment: [https://www.youtube.com/watch?v=7Pq-S557XQU](https://www.youtube.com/watch?v=7Pq-S557XQU)

Its a bit pop-sciency, but its very approachable and well explained.

<comment><USER7> It sounds like the technology forecasts in the 50ies and 60ies but with a pessimistic instead of an optimistic undertone.

<comment><USER8> In all fairness, most desk jobs that existed in the 50's and 60's are now heavily consolidated (it now takes one journalist and Google what it used to take 10 to do). And most factory work is either also heavily consolidated or moved overseas.

Would the words "service economy" even make sense back then?

<comment><USER9> Some simpler financial news articles are now written by _zero_ journalists. A program just extracts numbers from data feeds and plugs them into a template.

<comment><USER10> Sports as well. You can't have journalists cover all lower league games, but an aide has to write a log about plays, which you can use to generate some metrics and generate something that fits roughly the right tone. (example that does advertise it: [http://statsheet.com/](http://statsheet.com/) does this for basketball)

</comment></comment></comment></comment></comment><comment><USER11> I am always stunned with statements like this:

"For those not in the elite, argues David Graeber, an anthropologist at the London School of Economics, much of modern labour consists of stultifying "bullshit jobs"—low- and mid-level screen-sitting that serves simply to occupy workers for whom the economy no longer has much use. Keeping them employed, Mr Graeber argues, is not an economic choice; it is something the ruling class does to keep control over the lives of others."

Yes, I, as an employer, keep my staff doing "bullshit jobs" because I want to "keep control over the lives of others." WTF?!?! Why would I do that? Why not fire the bullshit job person and use that money to take my family on vacation 4x a year?

It amazes me that some people think there is some ruling cabal in a dark castle somewhere, deciding how to keep the masses in line. Maybe the answer is less evil - I have the person doing the work because I can't afford to automate it yet, or it is not currently possible.

What does the author think of the maker movement? This "Capital Equipment" is now priced at a weeks wage for many US workers. Marx would love it - it puts the means of production in the hands of the common man. I sold capital equipment for years, and what I used to sell for $50,000 you can now do with a $5000 machine. Prices keep coming down, and the machines I sold are no longer made. My job was eaten by progress :)

People will keep re-inventing themselves. It's what humans do.

<comment><USER12> Bullshit jobs arise in two ways. One is through the crazy inefficiencies of huge companies and governments. This is likely not you. Second is as an emergent property of red queens races in the economy, escalating complexity or overhead that does not actually increase overall macro productivity. The latter requires at least a casual familiarity with evolutionary game theory, but once comprehend cannot be un-comprehended. Most global military competition also falls into this category, and that's double digits of the economy in some countries.

I feel like these kinds of emergent pathologies are a species scale IQ test that so far we have utterly failed.

<comment><USER13> _Utter_ failure would have been nuclear self-annihilation.

<comment><USER12> True. Guess we passed the first pop quiz.

<comment> bro-kaizen But unfortunately pop quizzes take place literally every day :(

</comment></comment></comment></comment></comment><comment><USER14> Very interesting analysis. But they don't consider at all one very relevant change that happened during the last 30 years in most wealthy economies, especially the USA: That the taxation of the rich and the highest-earners in general was massively lowered. This contributed a lot to the concentration of wealth and capital in fewer hands.

<comment><USER15> Taxation for the purpose of running a government and providing basic services seems to be long gone. Most of the discussions these days are more about what the 'right' and 'fair' level of redistribution should be.

But, the rates of taxation are so arbitrary. Legislators get together to determine fixed rates and tiers of taxation.

Aside from the complexities of accounting (which should be simpler with computers), couldn't it make more sense to tie tax rates to real mean wages? Then, the very rich would have incentive to increase jobs and increase mean wages.

<comment><USER16> As much as I like this idea, there's an equally strong incentive, for those who can afford to do so, to engage in "tax optimization".

</comment></comment></comment><comment><USER17> The chart claims that economists have a 43% chance of being replaced by automation.

If they're wrong, then they'll be replaced by algorithms that are better at predicting economic trends than they are.

If they're right, then...

<comment><USER18> I've pointed this out elsewhere in this thread: That's not what the chart is saying. The description reads "Probability that computerisation will lead to job losses in the next two decades", not "probability that computerisation will completely replace this job".

For example, in economics, there might be a need for fewer economists because computers are able to do some of the work that previously had to be done by humans. But they're not suggesting that there's a 43% chance that there will be no human economists in 20 years, or that there will be such a thing as a computerised economist - it'll be aspects of the work that are automated (at least initially), not the whole job.

</comment></comment><comment><USER19> If unemployment ever becomes a problem we can simply outlaw the wheat combine, which will open up hundreds of thousands of jobs harvesting grain manually.

<comment><USER20> I hope you were being sarcastic... but in case you weren't, why would we ever create meaningless work instead of just giving people money for pursuing whatever makes them happy? A basic income guarantee seems like a much more reasonable solution than "put everyone to work digging holes and filling them in again".

<comment><USER21> >>just giving people money for pursuing whatever makes them happy? A basic income guarantee seems like a much more reasonable solution

Because recent history suggests, when offered money/stuff/income gurantee for free:

a. In the eyes of the individual receiving money, the value, importance and the perceived hard work that had to be done to earn it, as time passes, tends to zero.

b. A vast majority of people tend just take the money and chill doing nothing, while wanting others to work and make more free stuff/money for them.

c. Because a few people tend to do nothing and keep the status quo going, other people who like to break the norm and make value/money are immediately perceived as heretics who break the 'equal misery for all' norm and are perceived as evil.

d. Brilliant, hard working and creative people like to work with people of their own kind and generally go and live at places where they can find them. And such places always exist.

e. 'Right to free stuff' generally becomes the norm after a while and people who the real work are expected to make over the skies sacrifices and offer bulk of what they do 'for greater good of society'.

f. Equality for all in general tends toward, equal misery for all. Over big periods of time.

<comment><USER20> Aside from being generally inaccurate, your points completely ignore the fact that we are talking about the future, not the present. Specifically, we are talking about a future in which there is simply no _useful_ "work" for most people to do.

You can read more about the idea here: [https://en.wikipedia.org/wiki/Basic_income](https://en.wikipedia.org/wiki/Basic_income)

There is also:

[http://isa-global-dialogue.net/indias-great-experiment-the-t...](http://isa- global-dialogue.net/indias-great-experiment-the-transformative-potential-of- basic-income-grants/)

and

[https://en.wikipedia.org/wiki/Mincome](https://en.wikipedia.org/wiki/Mincome)

</comment></comment></comment></comment><comment><USER22> The interesting thing is that a wave of redundancy due to automation or unprecedented efficiency contains problems that those made redundant might be able to work on.

Eg. Joe can't afford X due to lack of employment, and Bob can't afford Y for the same reason. Assuming Bob can supply X and Joe can supply Y (or some more complicated network of bartering), it seems like should be possible for an economy to arise.

<comment><USER23> While commerce and trade are important, the basis of our existence is physical. We are physical beings with physical needs. Physical resources (energy, land, lumber, food, water, etc.) all have owners in the real economy. Joe and Bob are unemployed, thus have no resources, thus have nothing to trade. The best they can do in your scenario is called dumpster diving, assuming recycling tech is not making garbage valuable to the real economy as well. Mass dumpster diving, that's your dystopia right there.

<comment> guard-of-terra Specifically, Bob and Joe need oil (energy) to produce anything and it's expensive. If they create less value than oil they spent, they're a net loss for society.

</comment></comment></comment><comment><USER24> "However, society may find itself sorely tested if, as seems possible, growth and innovation deliver handsome gains to the skilled, while the rest cling to dwindling employment opportunities at stagnant wages."

As insurmountable as it may seem, people living in and affected by these innovative societies just need to adapt accordingly. It is in our innate nature to do so rather than remain stagnant and perpetuate mediocre jobs that were created as a result of the industrial revolution. People can acquire new skills and leverage themselves to appropriate some of the "handsome gains". Also, globalization would only exacerbate the issue of "dwindling employment opportunities". Nowadays, more and more corporations seek to outsource jobs to other countries due to cheap labor costs. For most people, it'll be a paradigmatic shift in thinking and seeking ways to contribute to society. Machine learning and artificial intelligence will only serve those who can transcend the repressive jobs which are inherently repetitive and meant for a machine to accomplish as they are the jobs most susceptible to computerization.

</comment><comment><USER25> Of course, the other side of the coin says that there are too many people.

<comment><USER26> I think that this is a very important piece of the discussion. Improving the efficiency of a lot of workers and increasing automation does not marry up well with a constantly increasing world population.

<comment><USER27> The growth rate is falling though.

</comment></comment></comment><comment><USER28> This makes me think : what are good ways to try and protect myself against this? How can I, as a software developer and entrepreneur leverage this to my advantage? What does this tell me about where the big opportunities will be in 3,5 and 10 years so I can begin positioning myself there?

</comment><comment><USER29> I see the dateline of this interesting submission (which looked familiar) is "Jan 18th 2014 | From the print edition." There seems to be a whole spate of year-old submissions to Hacker News this weekend. Are we trying to do a year in review, to see which predictions of 2014 turned out in reality?

As for the substance of this interesting submitted article, the historical facts are reviewed in a key paragraph before the article goes off into speculation about the future: "For much of the 20th century, those arguing that technology brought ever more jobs and prosperity looked to have the better of the debate. Real incomes in Britain scarcely doubled between the beginning of the common era and 1570. They then tripled from 1570 to 1875. And they more than tripled from 1875 to 1975. Industrialisation did not end up eliminating the need for human workers. On the contrary, it created employment opportunities sufficient to soak up the 20th century's exploding population. Keynes's vision of everyone in the 2030s being a lot richer is largely achieved. His belief they would work just 15 hours or so a week has not come to pass." The nub of the article's argument is that new forms of technological change might not leave us with any new forms of gainful employment.

After its interesting text discussion and chart predicting what kinds of employment are least likely to be automated out of existence, the article points out one difference between the world of the past and the world of today: "Another way in which previous adaptation is not necessarily a good guide to future employment is the existence of welfare. The alternative to joining the 19th-century industrial proletariat was malnourished deprivation. Today, because of measures introduced in response to, and to some extent on the proceeds of, industrialisation, people in the developed world are provided with unemployment benefits, disability allowances and other forms of welfare. They are also much more likely than a bygone peasant to have savings. This means that the 'reservation wage'—the wage below which a worker will not accept a job—is now high in historical terms. If governments refuse to allow jobless workers to fall too far below the average standard of living, then this reservation wage will rise steadily, and ever more workers may find work unattractive. And the higher it rises, the greater the incentive to invest in capital that replaces labour." Indeed, it may be that the funding of governmental benefits will become secure enough through rising productivity that many current workers will have children who do not need a job at all.

</comment><comment><USER30> Decent sci-fi reading list in the sub-headings.

<comment><USER31> Good catch, thanks for pointing it out.

</comment></comment><comment><USER32> The article refers to a 2013 paper by David Autor of MIT... [http://economics.mit.edu/files/9014](http://economics.mit.edu/files/9014)

The Nissan anecdote starts on page 3.

</comment><comment><USER33> A table in the article says Technical Writers have an 89% chance of losing their jobs. But it's only 6% for editors.

Why? Will technical instructions be automatically generated? How?

</comment><comment><USER34> Science is by definition the creation of causal chains. If I do X in this system, Y will result. Hence the importance of falsifiability and reproducibility.

This is yet another in a series of economic articles that sound much more like a typical op-ed column than an observation, hypothesis, or proof.

</comment><comment><USER12> If it does turn out to be different this time, it will be because Turing complete automation is qualitatively different from single purpose machine automation.

</comment><comment><USER35> I'd recommend reading Economics in One Lesson [http://mises.org/library/economics-one- lesson](http://mises.org/library/economics-one-lesson)

</comment><comment><USER36> the domain of computer science that seems to have a bright future is machine learning.

</comment><comment><USER37> I don't blame _technology_ for the stagnation of the American middle class. I blame poor leadership, but I think there's something else going on that isn't getting a lot of press: _latency skew_.

Instead of waiting two to three days for a piece of postal mail, we're annoyed if that email takes two _minutes_. I'm not going to moralize about "instant gratification" as if it were wrong, because it's mostly not conscious and it's not a moral issue; we're just being neurologically retrained to resist delays. From a website, 10 seconds means "never": it's down, or in an unusable state. We're also (some of us, at least) at a ridiculous level of comfort; we have people who program their garages to heat up 30 minutes before they leave for work, because they can't stand the thought of 45 seconds' exposure to winter cold.

What's _not_ becoming instant is human learning. If something can be learned quickly and will become rote, we can now program a computer to do it. So the things that we need humans for tend to be those that require subtlety or experience. That hasn't gotten faster. It still takes 6+ months before someone is good at his job. That's not a new problem. It's just less tolerated because people are more primed to expect instant results. So we're seeing an aversion to training people up into the better, more complex jobs that technology creates.

</comment><comment><USER38> Ftee trade destroys wages, of this there is no secret.

De-regulation subverts democracy.

Time to revisit the relationship between capital and well-being. Ricardian theories of comparative advantage drive wealth into the hands of those who control capital, not into the calloused hands of the poor suckers who sweat.

<comment><USER39> Automation destroys far more jobs than free trade. If anything we should ban automation.

<comment><USER38> It wasn't automation that destroyed US manufacturing

<comment><USER39> Manufacturing only became the major source of employment after all the farm laborers had become unemployed due to automation. As another comment mentioned, just banning wheat harvesters alone would create thousands of jobs. If creating jobs was our only goal.

<comment><USER38> Farm labourers became unemployed as a result of govt. policy to undermine farm worker political power.

More labour intensive farming would be a good thing. At the moment the US uses 10cals of energy to produce 1cal of food. Pre "get big or get out" it was 1 in 2 out.

Back to manufacturing, it is free trade that has gutted US manufacturing capability. Just look at the trade deficit, the rest of the world benefits greatly, capitalists get great returns on their free movement of money. The US loses taxes, jobs, and wealth and is eroding its long term economy while the short term policy makers make hay.

<comment><USER39> >Farm labourers became unemployed as a result of govt. policy to undermine farm worker political power.

No, in the last 2 centuries we have simple automated the vast majority of farm labor.

>More labour intensive farming would be a good thing. At the moment the US uses 10cals of energy to produce 1cal of food. Pre "get big or get out" it was 1 in 2 out.

This is an entirely meaningless metric.

>Back to manufacturing, it is free trade that has gutted US manufacturing capability.

Yes but my point was that banning automation would be more effective at creating jobs than banning trade. They are economically equivalent. A port is essentially a machine that produces stuff with less (local) labor.</comment></comment></comment></comment></comment></comment>


LibGyro – Low-Level Multimedia API - <AUTHOR> https://github.com/libgyro/libGyro <comment><USER2> I have browsed the source code and the project's commit messages, but frankly it didn't leave a good impression on me with so much cursing and swearing in the logs. It would help to have an actual README file in place too - the one on Github is empty. Which architectures besides the DreamCast (mentioned in some of the commit logs) are targeted by this implementation?

<comment><USER3> Almost like... this was a private repository that was literally just stolen. A DCMA complaint has been filed. This man literally stole my own work of several years, which wasn't even ready to go open source, and decided to take credit for it.

</comment></comment><comment><USER3> This is my work that I've been working on the last several years. I was not ready to release it open source, and this idiot just proceeded to steal it from an internal repository and POST IT UNDER HIS OWN NAME WITH ALL OF HIS PERSONAL INFORMATION.

</comment><comment><USER4> There's no information, not even a link to the documentation, so I don't see how this compares with SDL or anything in the same space. I don't know how to map this on to existing knowledge, sorry.

<comment><USER5> I started here: [http://elysianshadows.com/updates/libgyro- library/](http://elysianshadows.com/updates/libgyro-library/)

It is a low-level library to allow the porting of their game to many platforms.

<comment><USER4> That would probably be a better link to post to Hacker News then?

<comment><USER3> This is an internal library for the kickstarted game Elysian Shadows that was not yet ready to go open source. He's plagiarized it... and used his real account with all of his contact information... oooopsies!</comment></comment></comment></comment>


Disgruntled online shopper texts entire works of Shakespeare as revenge - <AUTHOR> http://www.independent.co.uk/life-style/gadgets-and-tech/disgruntled-online-shopper-texts-entire-works-of-shakespeare-as-revenge-9201564.html <comment><USER2> Who says revenge and culture can't go hand in hand?</comment>


Free Software Foundation: Tim Berners-Lee is wrong to think he's powerless - <AUTHOR> https://defectivebydesign.org/blog/response_tim_bernerslees_defeatist_post_about_drm_web_standards <comment><USER2> Their argument is persuasive. Prominent figures should take care before taking pragmatic steps that likely to further entrench the powerful.

Of course they risk becoming a standards body whom no one follows.</comment>


Logistic Regression from Bayes' Theorem - <AUTHOR> https://www.countbayesie.com/blog/2019/6/12/logistic-regression-from-bayes-theorem <comment><USER2> If you fit a linear model for the coffee making problem and one of the parameters is temperature and the coefficient for the temperature in the linear model is positive, does that mean if you keep increasing the temperature without limit, the probability of making a good cup of coffee increases as well without limit?

In reality the temperature is required to be a certain exact value within a range.

<comment><USER3> Yes, you are correct. In other words, the relationship between temperature and quality is not linear, so directly using the temperature in a linear model gives wrong results. (To be pedantic, the probability will approach 1 as the temperature goes to infinity)

<comment><USER2> The example problem seems to be completely inappropriate then for the article/model.

<comment><USER4> I think it's a little more complicated then that. A variable might not be linear in general but may be approximately linear within a certain range of values. You might fit the model on values only within that linear range and thus get a good fit. The model may be very useful inside the range of fitted values but garbage at extrapolation. As long as you understand the limitations it can still be a useful model.

<comment><USER5> While you're right, the original post is meant to be pedagogical. Someone who doesn't understand the fundamentals of model selection might learn the wrong lesson(s).

You kinda have to expect a student to use the examples you give.

There's really no upside to using that example.

<comment><USER6> If I were the author, I would drop things like temperature unless I am willing to discuss nonlinear transformations thereof.

Instead, why not simplify it down to D=Freshness of Coffee Beans ?

</comment></comment></comment></comment></comment></comment><comment><USER7> It would be nice to hear about the optimization method with convergence guarantees etc. Introducing the model is nice, but you need to show quality and easiness of fit. You can maybe do this before since you rely on the idea of learning the parameters somehow to motivate the model.

You can relate to NNs for free since it is a linear layer with sigmoid activation.

You can stress it is linear in that your decision boundary is linear.

I don't like how capitalized letters are not random variables but are observations.

You can give some examples of what conditional PDFs P(H=1 | D ) look like and what you can model. In your case if the ideal temp for coffee is 190F and +/\- 10 or more and the coffee is bad then you hope that (temp - 190)^2 is a feature input.

Congrats on the book deal!

</comment><comment><USER8> Very nice! How about this, for more than 2 classes:

Let p_k be the probability of being in class k. We assume log p_k = f_k(x) + C(x) where x is the feature vector and C(x) is normalisation to make the probabilities sum to 1.

Equivalently, p_k is proportional to exp(f_k(x)), so p_k = exp(f_k(x)) / sum_j exp(f_j(x)).

Because of the normalisation we may assume without loss of generality that f_0(x) = 0. Then if we have 2 classes and f_1(x) is linear, we get logistic regression.

<comment><USER9> It's called multinomial logistic regression if there are more than 2 classes. It works exactly how you described.

</comment></comment><comment><USER10> This was a really neat exposition! I have a few questions:

1\. Is D a binary random variable? If so, what exactly does it mean to say beta*D + beta_0 is an approximation for log odds? Doesn't this formula only take on 2 possible values?

2\. Could you provide intuition for why a linear function of D would be a good approximation for the log odds mentioned?

<comment><USER6> D can be binary, in which case the model predicts two alternative outcomes for the log-odds. The linear part is shifted by beta, whenever D=1.

As for your second point, there is no prior reason in this case why a linear function of D would be a good approximation. Indeed in the current case, we would probably prefer to at least write beta1 _D+beta2_ D^2+beta0 which is still linear in a transformation of D.

That being said, however, there is a notion on why a linear function may be a good approach. If you are interested in the direction of change around the averages values of the variables involved, then a linear function gives you such a "linear approximation" of the slope. This of course quickly breaks down if the function is not really linear, and in particular, it breaks down if you are interested in predicting an observation that is not "average". But often, one may be interested in such very qualitative statements as: on average, the coffee is improved by fresher beans - yes or no? In that case, such a linear model may give an answer.

Note that the above is absolutely not formally correct.

Finally, logistic regression can also be motivated differently.

\- It arises from minimizing certain entropy losses in Machine Learning

\- One may assume that the binary variable we observe is really just based on a "latent" variable (here something like coffee quality), which is determined by such a linear model

\- finally, in economics and reinforcement learning, we assume agents make one decision (here whether the coffee is good or bad) by judging the inputs plus some random "error" or "taste" parameter which is has extrem value distribution. Since only the differences between these utilities matter (cf. odd ratios), and the actual values are meaningless, the logistic regression also arises.

</comment></comment><comment><USER3> NB: this post uses D for the input x and H for the output y. This confused me quite a bit since usually in ML we use D for the data (pairs of x and y) and H for the model (in most cases the parameters, the betas in this example).

</comment><comment><USER11> I'm a little confused, how much technical this approach is? I can't understand the meaning of P(D) for example. Does it make sense in strict mathematics?

<comment><USER12> P(D) is just the probability of D. This is common when talking about probabilities.

<comment><USER11> How can we talk about the probability of the data (D)?

<comment><USER12> D in this case refers to a specific set of variables that goes into brewing coffee. P(D) then refers to the probability of a given set of values for that vector of variables given all the possible values.

Don't take it too literally - P(..) here is not some well defined function, it's effectively just part of the name, as a convention for naming probabilities. I find it confusing too.

As the article points out, that set is for all intents and purposes infinite in this case, but this doesn't matter, as you can sidestep it by comparing to complementary hypotheses (which makes P(D) cancel out). This is all covered in the article.

The only maths worth reading up on to understand this article is a basic introduction to Bayes theorem - the wikipedia page is quite decent.

</comment></comment></comment></comment><comment><USER13> I realise this is pedantry but it's definitely "Bayes' theorem" not "Baye's theorem" dammit.

Sorry about that.

<comment><USER14> Well, if you want to be a pedant, it should arguably be Bayes's theorem: [https://www.bartleby.com/141/strunk.html](https://www.bartleby.com/141/strunk.html).

That "Drop the trailing s to form possessives" exception needs to die.

<comment><USER15> Why does it need to die? What is the rationale behind that?

<comment><USER16> What's the rationale for keeping it? English should try to be at least a little bit easier parse for a newbie.

<comment><USER17> One man trying to dictate the direction of a language used by a billion people... that's just not going to happen.

Not that I don't sympathize. I think that "it's" should be the possessive form of 'it', not a contraction of 'it is'. Maybe if we band together we can force- feed both our changes at once to the rest of the world?

<comment><USER18> Languages by definition are fluid. If a certain way of spelling a word or grammatical structure spreads to become popular (possibly, yes, from one person), then it becomes the new normal.

<comment><USER17> English is fluid like the tides are fluid. The chance that somebody can dictate the direction of that tide is very slim.</comment></comment></comment></comment></comment></comment></comment>


Without Churchill, India's Famine Would Have Been Worse - <AUTHOR> https://winstonchurchill.org/resources/in-the-media/churchill-in-the-news/indias-famine-would-have-been-worse/ <comment><USER2> International Churchill society disputing that Churchill did not commit genocide. Color me surprised.

<comment><USER3> Feel free to argue your point.</comment></comment>


Apple recalls 15in MacBook Pro laptops over battery fire risk - <AUTHOR> https://www.theguardian.com/technology/2019/jun/21/apple-recalls-15-inch-macbook-pro-laptops-battery-fire-risk <comment><USER2> Does it relates to [https://www.reddit.com/r/apple/comments/bulbhv/my_macbook_pr...](https://www.reddit.com/r/apple/comments/bulbhv/my_macbook_pro_exploded_and_burst_into_flames/) that's posted before? Interesting</comment>


Perchance to Scheme (2016) - <AUTHOR> https://hardmath123.github.io/perchance-to-scheme.html <comment><USER4> Racket is not academic to me. Racket equals programming fun and really is a joy to use. Academic seems to not convey the feeling one gets when using Racket. To me Racket is really the future of what languages will look like, a language to create your own DSL.

The greatest strength of Racket is its documentation. Secondly the way Racket actually teaches you how to be a better programmer. I personally grew the most due to "How to Design Programs" [https://htdp.org/2018-01-06/Book/](https://htdp.org/2018-01-06/Book/) Third the executables for cross platform is its reason why I use Racket at work. I can make it and create an executable with raco.

I feel like Racket is the most general purpose language I have ever used. I grew up on C64 Assembly, Pascal and Forth. When I learned Python I felt like I could do anything. That was until I wanted my Python code to be used on a computer that wasn't my own computer.

Python was my go to language for everything at work but I ended up moving to R about 6 years ago. I felt my R was rough around the edges and picked up Racket to learn about R's Scheme roots. It was a night and day difference. I have several pet programs that saves me hours every week.

My Racket programs are much more readible than my Python Scripts. The libraries are certainly not all there but it is actually easy and fun to create your own implementations in Racket and a library for your own use.

<comment><USER5> > Racket equals programming fun and really is a joy to use. Academic seems to > not convey the feeling one gets when using Racket.

As an academic, it makes me very sad to hear these qualities, that I feel describe my work, used as the _opposite_ of 'academic'.

<comment><USER4> I was faculty at a University and I still find the word Academic to be negative connotation and was an inaccurate statement on Racket

Define - <USER2>

1\. c: very learned but inexperienced in practical matters 1\. d: based on formal study especially at an institution of higher learning 3\. a: theoretical, speculative 3\. b: having no practical or useful significance

[https://www.merriam-webster.com/dictionary/academic](https://www.merriam- webster.com/dictionary/academic)

Couldn't find a positive way to spin Academic as used by the article.

<comment><USER6> Academic as in, there are many places where the person[s] working on the code or feature abruptly stopped. As if they graduated and were no longer working on it.

<comment><USER4> That certainly isn't the case with Racket either :)

</comment></comment></comment></comment></comment><comment><USER7> Alternatively - you can choose to program in Common Lisp - an industrial strength language that has been demonstrated in large projects like the QPX flight search engine (Google Flights).

For anyone who doesn't know - a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing.

Another big difference between Scheme and Common Lisp is that the Common Lisp specification is _much_ larger and it comes with a much larger collection of standard built-in functions and macros and a standard object-oriented programming facility, among many other things.

I know this because I've spent the last six years implementing Clasp (github.com/clasp-developers/clasp) - a Common Lisp that interoperates with C++ and uses LLVM as the backend. There are several excellent implementations of Common Lisp - Steel Bank Common Lisp is a great place to start.

<comment><USER8> > a big difference that Common Lisp brings to the table is that it has > separate namespaces for variables and functions. This may not sound like > much but it makes it much easier to write macros (code that writes code) and > facilitates compile-time computing.

A little more detail here: it has a lot more namespaces than that. Indeed, you can attach arbitrary different namespaces of things to symbols if you want to.

It turns out that when you're writing macros in Lisp, the majority of what you use from outside the macro are functions and the majority of symbols that you bind and use within the macro are variables, so if you put them in different namespaces, you get rid of the majority of cases where symbols don't do what you were expecting in a macro.

Now, it's not quite all of the cases, and when it does happen, it's a pain to track down. Which is why the Scheme folks spent the effort and complexity on hygienic macros (where the system rewrites all symbols internally to make variable capture impossible). At the time of Common Lisp's creation, multiple namespaces and unhygienic macros were the obvious choice for production code, since there weren't hygienic systems available. Today you can go either way. In terms of research, hygienic is the route to go, as the work over the last couple of years on strongly typed, hygienic systems has shown.

<comment><USER9> > A little more detail here: it has a lot more namespaces than that.

And I don't think the function/value split is even the most important namespacing it does with regards to macro hygiene ("functions are less likely to be shadowed" always struck me as a kind of weak argument). Symbols being namespaced under packages is a much more robust solution:

        CL-USER> (defmacro m (x) `(car ,x))
        M
        CL-USER> (defpackage :p)
        #<PACKAGE "P">
        CL-USER> (in-package :p)
        #<COMMON-LISP:PACKAGE "P">
        P> (cl:macroexpand '(cl-user::m x))
        (COMMON-LISP:CAR X)

CL:CAR isn't accessible in P, so (car x) by itself would signal UNDEFINED- FUNCTION, but the macro works correctly. Defining a P::CAR function wouldn't change anything.

That isn't just for functions, either, eg if you do:

        (defmacro awhen (pred &body body)
          `(let ((it ,pred))
             (when it ,@body)))

(where you _want_ to leak IT), and then import AWHEN but not IT, you'll get an error that YOUR-PACKAGE::IT isn't bound to anything when you try to use it; it doesn't matter that AWHEN-PACKAGE:IT is bound.

I don't disagree with anything you said, I just think it made CL macros look flimsier than they are.

<comment><USER10> The problem is that it is quite common for _cl:car_ to be accessible in packages, because of the practice of use-ing the cl package everywhere.

Even if I'm in my own package, I can't do this:

      (flet ((car (x) ...)))
        (m arg))

because in order to have a hassle-free Lisp coding experience in my package, I brought in all the public symbols from the common-lisp package. So my _flet_ is in fact shadowing _cl:car_.

Even if I just import the specific common-lisp things I need, and _car_ is not one of them, that could change. Today, that _car_ above is _mypkg:car_. Tomorrow, someone edits the _defpackage_ to import _car_ (because they needed it in a function they added), and now when that file is re-read, _car_ is _cl:car_.

Packages have a theoretical solution to the hygiene problem that will not be air-tight in practice due to use/importation.

Another problem is that programmers aren't going to define a large number of packages to protects parts of their program from each other. A common practice is just to make one package for an entire project.

You need fine-grained package use to achieve near perfect hygiene. Ideally, each module that provides macros should have its own package, and use only symbols from that package in the macro expansion. If module A uses a macro from package B, and that macro generates a local function F, that will be B::F, not interfering with the A::F function. If the modules are in the same master project package, the clash is not averted, obviously.

</comment></comment></comment></comment><comment><USER11> > Clojurescript.... Personally, I don't like it on a matter of principle: I > don't like things that compile to JavaScript. It doesn't seem like anything > you really need to write better code.

Maybe I don't understand what the alternative is when you want to write client side code for the browser - js?? I use Clojurescript and find clear benefits.

By way of example I often found the general setTimeout functionality to be a nightmare for scheduling delays. Most of the time it works, but periodically I find it blocks or fails (via a dependancy chain) and then have to spend time arranging code abnormally to mitigate. In clojurescipt I use core async.

      (defn timeout [ms]
        (let [c (async/chan)]
          (js/setTimeout (fn [] (async/close! c)) ms)
         c))

Never looked back. Never had a delay problem - Ever.

cljs core.async and many other features have made it so much more enjoyable to write client side code. Don't even get me started on callbacks.

> Oh, and one last thing. I feel it's obligatory at this point for me to say, > please don't spend too much time researching Scheme dialects. Just pick > Racket and start coding

I've had the opposite experience so thanks, but no thanks.

<comment><USER12> What was your experience with Racket?

<comment><USER11> This dates back about 5 years ago, but I found Racket's libraries were rough. Often they amounted to prototype work that never got fleshed out, they were ill maintained, low in quality, and many just wouldn't load. And these were general purpose libraries; like even just basic database stuff.

I moved on to Clojure.

</comment></comment></comment><comment><USER13> I am guilty of writing my own Scheme (R5RS) interpreter as well, and a key takeaway from the experience was that many things calling themselves Scheme interpreters are missing core parts of Scheme.

Implementing a language that resembles Scheme is quite easy. Implementing call-with-current-continuation and hygienic macros AND getting the tricky little details correct is not.[0] An analogy might be someone offering "ability to write SQL" for their fly-by-night database without stating up front that joins are not supported.

[0] Old test suite run against old Schemes: [http://sisc- scheme.org/r5rs_pitfall.php](http://sisc-scheme.org/r5rs_pitfall.php)

<comment><USER14> "Implementing a language that resembles Scheme is quite easy. Implementing call-with-current-continuation and hygienic macros AND getting the tricky little details correct is not."

(tangential) and this is where most "build your own compiler" style books fall down.

They teach you to implement ultra simple languages, but don't tackle memory management/garbage collection, concurrency, production grade typecheckers, and for lisplikes, macro systems, etc.

<comment> nils-m-holm > (tangential) and this is where most "build your own compiler" style books > fall down.

Have a look at [http://t3x.org/s9book](http://t3x.org/s9book) \- it covers a Scheme implementation including GC, call/cc, low-level macros, type checking, tail call elimination, etc.

</comment></comment></comment><comment><USER15> A minor update: Now Chez Scheme is open source (Apache license) [https://github.com/cisco/chezscheme](https://github.com/cisco/chezscheme)

<comment><USER16> Racket is now integrating the best parts of Chez Scheme, for a future release.

<comment><USER17> Racket-on-Chez will be considerably slower than vanilla Chez - <USER3> semantics incur some overhead. Here are some rough benchmarks from a year ago:

[http://blog.racket-lang.org/2018/01/racket-on-chez- status.ht...](http://blog.racket-lang.org/2018/01/racket-on-chez- status.html#%28part._benchmarks%29)

</comment></comment></comment><comment><USER18> Other schemes that may be of use:

1) Gambit. Compiles to C. Interesting tools built on top are Termite (Erlang- like concurrency framework) and Lambdanative

2) TinyScheme - super minimalist embeddable scheme.

3) Kawa Scheme - on JVM. Much smaller and faster than Clojure when I used it last.

4) Bigloo - can compile to C & Java bytecode.

Note ChezScheme is now open source and has very good documentation.

<comment><USER19> To add to the list, PicoBit Scheme for microcontrollers, currently PIC18 and ARM, [https://github.com/stamourv/picobit](https://github.com/stamourv/picobit)

There was a port of one of PicoBit predecessors, Bit Scheme, to the XMOS architecture, with realtime GC and support for the native XMOS features [http://soft.vub.ac.be/~cderoove/publications/master_thesis_r...](http://soft.vub.ac.be/~cderoove/publications/master_thesis_ruben_vandamme.pdf)

</comment></comment><comment><USER20> As a guile user myself, I feel I must say that guile works just fine also when you are not embedding it. It is a very capable scheme, and even though it is not as fast as chez or racket, things have gotten a lot better (the upcoming JIT in the 3.0 release means at least a 2x speedup).

<comment><USER20> Oh,and thanks to pthreads and guile fibers the concurrency situation is probably the best of any scheme.

</comment></comment><comment><USER21> Does the sheer amount of cool stuff out there feel overwhelming to anyone else? I want to learn this and this and this and that and this and that thing and this other thing over there.

<comment><USER22> Because of this I can't focus on anything because learning anything feels like it has infinite opportunity cost, spirals into anxiety. My irrational response is to watch Netflix because if I were instead learning X, I would be concerned that I'm not learning Y0, ..., YN for a very large N.

</comment></comment><comment> phoe-krk > ClojureScript is a compiler from Clojure to JavaScript (Clojure originally > targeted Java). It is not a Scheme dialect, not does it feel like one. It's > a LISP dialect.

Hell no. The linked website, [http://wiki.c2.com/?LispSchemeDifferences](http://wiki.c2.com/?LispSchemeDifferences) lists differences between _Common_ Lisp and Scheme. Clojure is not a Common Lisp implementation.

<comment><USER23> Clojure(Script) is neither a Scheme nor an implementation of Common Lisp but is a LISP dialect. LISP dialect languages are simply a group of lisp-like language not just implementations of Common Lisp. [https://en.m.wikipedia.org/wiki/List_of_Lisp- family_programm...](https://en.m.wikipedia.org/wiki/List_of_Lisp- family_programming_languages)

<comment><USER24> Scheme is generally also a LISP Dialect, more so like Clojure, since it inherits many of the LISP features directly.

Generally Clojure has very little in common with LISP dialects, besides some concepts. It has no linked lists, almost no functions are the same, almost no macros are the same, no special forms are the same, similar named operators often do something different, ... Think ATOM, CONS, CAR, CDR, APPEND, SETQ, NULL, DOLIST, DOTIMES, ... basically the original core of LISP is not present in Clojure. Literally no Clojure code runs in LISP dialects and no LISP code runs in Clojure dialects -> without completely rewriting it. Some Scheme ran in LISP - with more or less effort to do so. Nowadays that's not very common.

Clojure may in abstract terms be a LISP dialect, but the expectation that anything from LISP can be applied directly to Clojure is not the case. You can't take any LISP book and execute the examples in Clojure , nor would it make much sense.

</comment></comment></comment><comment><USER25> There's this new implementation called "gerbil"[1] which runs on top of gambit, is still very young but looks very promising.

It's opinionated in a good way (IMHO).

[1]. [https://cons.io/](https://cons.io/)

<comment><USER26> Looking at it, I'd call it a new language, not a Scheme implementation. Its semantics are much different from Scheme's.

<comment><USER6> Umm superficially you could say it is anything. The reality is it IS Scheme. (define (foo bar) (format "hi ~a" bar)) works just fine. As will any of the Scheme code, as it's merely syntactic sugar, (import :std/sugar) that you are confusing with a whole new language.

<comment><USER26> Look at things like:

        (define lst '(4 5 6))
        (set! (car lst) 3)
        (display (car lst))

        ;; 3

That's a pretty serious semantic departure. It's at least as different from RnRS as Racket, which insists it is not Scheme.

<comment><USER9> There's an SRFI for generalised set! that lots of implementations (Racket, Guile, Chicken, etc) support: [https://srfi.schemers.org/srfi-17/srfi-17.html](https://srfi.schemers.org/srfi-17/srfi-17.html)

<comment><USER26> Neat. Learn something new every day.

<comment><USER27> It's not in widespread use though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Emacs Lisp is most certainly _not_ a Scheme.

<comment><USER29> The plan is to replace Emacs Lisp with Guile, which _is_ a Scheme:

[https://www.emacswiki.org/emacs/GuileEmacs](https://www.emacswiki.org/emacs/GuileEmacs)

<comment><USER24> No, that's not the plan. The plan is to replace the Emacs Lisp runtime with a Guile-based runtime.

See here: 'is a branch of GNU Emacs that replaces Emacs's own EmacsLisp engine with the Elisp compiler of Guile.'

The word is 'ENGINE'. That's the underlying language runtime.

It's neither GNU Emacs right now, nor will Emacs Lisp be replaced.

<comment><USER30> I thought that project is perennially under development, and at this point in time more like good thing to look at than having a real chance of getting merged with master?

<comment><USER24> Probably. ;-)

</comment></comment></comment></comment></comment><comment><USER31> _Scheme, on the other hand, is very loosely specified. This is a good thing: the core language is so small that the entire standard fits on about 50 pages...It's not nebulous, it's simply minimalist. This is why Scheme is more of an idea than a language._

Smalltalk wound up being quite loosely specified. This, combined with the small "core," enabling single developers rolling their own, resulted in a high degree of fragmentation of the overall language community.

<comment><USER27> I noticed that quote as well.

Odd thing to call RnRS Scheme loosely specified. The RnRS spec is extremely well-written - and it even includes a semantics.

Now "Scheme" used to mean "a Scheme like language" is of course loosely specified - but that's another story.

</comment></comment><comment><USER32> One important thing the author failed to mention (probably due to the publication date) is that Guile also has compiler front ends for ECMAScript and Emacs lisp (and there's a lua front end in the works). So far, Guile is my go-to scheme.

[https://www.gnu.org/software/guile/](https://www.gnu.org/software/guile/)

<comment><USER6> And Gambit has backends for JS, Java, Ruby, Php, C and no doubt some others.

</comment></comment><comment><USER33> I know this is a big controversial can of worms, but as a filthy casual who just happens to like Lisp, the idea of R6RS is pretty appealing to me. This post seems very much R5RS-oriented.

Are there any R6RS-conformant Schemes that are recommended?

<comment><USER34> Not a R6RS fan myself, so no definitive answer. But AFAIK Chez (now open source as someone else posted) is R6RS-compliant and one of the fastest implementations. Also, R7RS-small is final I think. Not sure about R7RS-large. Here's an old discsussion: [https://news.ycombinator.com/item?id=11700167](https://news.ycombinator.com/item?id=11700167).

<comment><USER35> I think Chicken Scheme recently became r7rs in their new version 5

<comment><USER36> Chicken R7RS is still a work in progress AFAIK

</comment></comment></comment></comment><comment><USER37> The author concludes with:

> Oh, and one last thing. I feel it's obligatory at this point for me to say, > please don't spend too much time researching Scheme dialects. Just pick > Racket and start coding.

<comment><USER38> I prefer Chicken Scheme, which recently just had a new release (version 5).

It actually compiles to C and then to binaries for your specific platform.

Check it out: [https://www.call-cc.org/](https://www.call-cc.org/)

<comment><USER33> The fact that Chicken actually has a package manager and central repository is a big plus for me.

<comment><USER16> Racket also has a package manager and central repository.

<comment><USER6> Gerbil has a package manager too.

</comment></comment></comment></comment></comment><comment><USER6> These days Gambit/Gerbil are a much more pragmatic Scheme.

</comment><comment><USER39> What about PicoLisp?!

</comment><comment><USER40> what about mit/gnu scheme?</comment>