The Hard Part of Learning a Language - <AUTHOR> https://www.hillelwayne.com/post/learning-a-language/ <comment><USER3> Languages often have a bunch of implicit assumptions which are not stated outright in the material.

As a example, the Foo-lang [1] books starts (obviously) with how to write and compile a hello world program. Bar-lang books typically postpone this to the end of the book since IO and deployable programs are advanced concepts. I once talked to some Bar-fans about this and they simply did not understand why this could be an issue. Surely you could just echo "Hello world" in the repl as the first exercise?

The underlying unstated assumption is that Bar-lang programs are primarily something you write for yourself and interact with in a repl, while Foo- programmers assume programs are written to be deployed and executed.

Such unstated assumptions are not written on first page in the manual because they are invisible when you are immersed in the culture.

Another example is a discussion I saw where a Baz-user claimed that everything was simpler in Baz than in Bong. The Bong-fan then asked how you loaded data from a relational database. The Baz-fan replied that only an incompetent moron would use a relational database, real men use text files which have less overhead. Now this could be dismissed as cognitive dissonance because Baz didn't have a nice RDBMS interface, but I think it is indicative of a deeper cultural assumption that the application _can_ decide which format to persist data in, where Bong comes from an assumption that the data is already there in a given system and a workable program _will_ need to be able to interact with it whether the developer like it or nor.

Again, such underlying assumptions are typically not written in the tutorial, but have deep implications for the language design and ecosystem.

[1] I changed the language names so as to not start a discussion about the particular languages. Although I'm sure there are actual languages called Foo, Bar etc.

<comment><USER4> Foo = procedural (c)

Bar = functional (haskell)

Baz = bash ?

Bong = hard to say because bash has a perfectly good interface to sql so im just super confused now.

<comment><USER5> > Baz = bash ?

Lisp (the anecdote is famous)

Bong may be C#, but "good" is pushing it. The only language I know with a good interface with a database is SQL, but I/O is quite bad.

<comment><USER3> I'm curious, what anecdote are you referring to?

<comment><USER5> There's an essay from PG where he explains how viaweb used only text files and how people react to the absence of a database.

<comment><USER3> Nice. I was actually paraphrasing a discussion I saw recently about K versus Python.

<comment><USER5> Cool. I expect it to happen with all kinds of languages, it's interesting to see it happening.

Just a decade ago, databases weren't the go to solution to all kinds of software. Now we have sqlite everywhere, so those arguments will probably get less common with time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> For me the worse part of every new language is deal with ecosystem. Holy fuck. It is so annoying. Scattered info, standards, many solutions for the same thing and none is good, style guide, plugins and editors, debugging, packaging, testing, libraries, environment quirks, deployment compatibility, vendoring/semantic-versioning etc.

Ironically, learning the language itself in general is the easy part, that other stuff that are just pain.

I just love learning new languages, but I hate to deal with new ecosystems and all their bullshit. It is just terrible, always seems totally wrong for a outsider (ex.: JS with npm, .Net with versioning hell, Scala with sbt bugs, Haskell with Cabal Hell, Mobile dev with all complex setup)

Fun thing: to make anything useful, dominate the ecosystem is essential.

F _uc_ K.

<comment><USER7> To be realistic about it I stopped calling things I don't understand "bullshit" and "terrible". What I use instead is "I don't know why it is that way", "I don't understand" and finally realization "OK, I don't want to spend my time on understanding this because I have better things to do".

I would love to spread this approach in developer community. Be honest that you don't understand stuff and you don't have time to learn it because you have better things to do.

Though if someone is paying me to do something in a language I will put my time into learning it. If it is just a hobby who cares that it is not easily grasped, I don't have to spend time on it.

<comment><USER8> You're entitled to your opinion, but most of it is 100% bullshit in my eyes.

I'll use Haskell as example. The ecosystem is a mess. `stack` is admirable effort to make development palatable, but it's ultimately a technical solution papering over a cultural issue: The community [including the language designers!] have 0 respect for backwards compatibility.

The node ecosystem is seems to be the worst at this. Not only is there no real respect for backwards compatibility, but it seems that the real purpose for a lot of the stuff is created is to 1) bolster the creator's resume and status or 2) to get funding from a VC. Certainly all ecosystems have that to some degree, but node just feels like the worst, by far.

I've written all the major languages with this problem professionally [except node]. It's not that I don't understand. It's that I _did_ spend my time on understanding this and it was such a complete waste of time in retrospect. The solution isn't to spend more time learning the tooling. It's to only work in ecosystems that don't waste your time.

edit: Any ecosystem that has some notion of a "langauge version manager" is a big clue to me that I'm about to spend a lot of time learning a bunch of non- portable information.

<comment><USER9> Which ecosystems don't waste your time, according to you?

Just curious.

<comment><USER8> Java is pretty good. Go. C because of the nature of how libraries are shipped. Just as an example:

"0 - libcurl 7.1, August 2000

1 - libcurl 7.5 December 2000

2 - libcurl 7.7 March 2001

3 - libcurl 7.12.0 June 2004

4 - libcurl 7.16.0 October 2006"

"During the first seven years of libcurl releases, there have only been four ABI breakages.

We are determined to bump the SONAME as rarely as possible. Ideally, we never do it again."

This is the attitude of what I want out of my dependencies.

<comment><USER10> Have you had an experience with Cargo, the Rust package manager? It is an absolute joy to work with, clean repeatable builds, and fast for what you are getting (speed of C++ with the correctness of Haskell).

<comment><USER8> Not really. I've played with Rust but haven't used it in anger. One thing I've noticed about my programming style is that I LOVE to learn about new languages and language features. Using a language like Go or Java forces to me concentrate on the problem at hand [which almost always something where GC is fine for what I'm working on]. That said, the Rust ecosystem seems pretty solid [except the edition stuff, that makes me very leery...]

<comment><USER11> Editions exist to guarantee forward compatibility, it's actually a really good solution to a hard problem.

</comment></comment></comment></comment></comment></comment></comment></comment><comment> daniel-levin I've just introduced a new engineer to a project in a language he hasn't used before. All of these points ring true! I want to suggest C# on .NET Core as a pleasant, fast language and ecosystem to learn.

I used to avoid anything Microsoft like the plague. A friend of mine used to call me "the Unix beth din" [1]. By necessity I needed to use C#/.NET for a project. It changed my view, mostly because almost all of Mr Wayne's questions could be answered quite easily. The package management, build system, IDE, installers, test framework, debugger, and documentation are all from Microsoft, come well-documented, and on all platforms of consequence. It's a breath of fresh air compared to the clusterfuck of competing tools (e.g. gulp, webpack, yarn and friends for JS) with overlapping features and bad docs that some other languages are plagued with. In C# on .NET Core, MSBuild + NuGet handles this for you. Compiler selection, package installation, building, test running, custom build steps, code generation, etc etc. Plus, NuGet's website and interface in the canonical IDE (Visual Studio) shows you the "'canonical' packages the community has consensus on".

[1] [https://en.wikipedia.org/wiki/Beth_din](https://en.wikipedia.org/wiki/Beth_din) (the autority for what is and is not kosher)

<comment><USER12> There should probably be a website that answers these questions for every language.

Just a giant table with language names on one side and standardized tooling names on the other.

<comment><USER13> This should be the top comment. Maybe we could collaborate on it via a github repo?

<comment><USER12> Sure, I made a stub: [https://github.com/Kinrany/awesome- ecosystems](https://github.com/Kinrany/awesome-ecosystems)

</comment></comment></comment></comment><comment><USER14> The fact is that most of the things on the list are just trivial, but a nuisance to do because it is the boring, not glamorous part of the programming job.

For me, the really difficult part of the language is understanding the core concepts, like what is a monad? or a functor? or a lambda, or a map, or an S-expression, a pointer, automatic reference counting,ip stack, neural network and so many more.

Each of those concepts isolated can take more than a week to deeply understand.

What this man calls "The hard part of learning a language" is quite simple and easy to do with the right method.

The method I use is:

\- Take a notebook and write down a checklist with all the things you need to do.

-Set an alarm clock to alert you after an hour of work.

-Start following the steps on the checklist, mark them when finished and write notes of what you did.

-When the alarm alerts you, stop working.

Now rinse and repeat every day as a routine, doing other (fun) things so you don't emotionally link learning a new language as something terrible or bad.

Instead of trying to do all the boring stuff one single day(and burning myself out) I split it.

Learning different approaches to programming will pay off over time. It compounds and makes solving problems so easy in the middle and long term. But you are not entitled to improving.

The fact is that nobody cares if you stop learning. They will just pick someone better solving problems and not making mistakes than you(because they continue improving).

<comment><USER15> > ... most of the things on the list are just trivial ...

That's just it. That those things that cost you so much time and nerves are so trivial makes them all the more annoying.

<comment><USER16> Yeah, I think that was pretty much the author's point.

</comment></comment></comment><comment><USER17> Though those are good points, there are a few things to mention: once you know a few programming languages, jumping into a new one becomes relatively easy. That said, there are a few traps here and there(something I've also noticed when studying a foreign languages after knowing 2 others): "Oh that's the same as in {{X}}". And you pay no real attention to it as a result. A few days later you end up going to check what "{{X}}" was.

My methodology as far as programming languages go, is the following:

1\. Learn the nature of the language by understanding it's internals - is it dynamically typed, statically typed, functional, object oriented, single threaded, multi threaded etc.

2\. If it's a compiled language, learn the hello-world and then spend some time to figure out how the compiler works.

3\. Ecosystem - packaging, distribution, community, etc.

4\. No IDE's, plain and simple vim. Getting off the line becomes a lot harder but it teaches you the fundamentals from the start without relying on anything fancy: Get your hands dirty.

5\. While you are studying it, think of a small project to work on along the way in that language and try to push your current knowledge over the edge of what you've learned. After you learn a new concept, go over the entire project and see where it can be applied and what would be the benefits/drawbacks. Even if that means re-writing 90% of the project.

<comment><USER18> I actually think #5 is the most important and shouldn't be discounted. I like three month projects - something moderate hard that might or might not get shipped. A summer of evenings sort of thing is usually enough to get a good grasp for me.

<comment><USER16> While this approach seems to work for a lot of people, personally I'm in the crowd that has a really hard time with that.

I'm just not a creative person. I consider myself a good developer when it comes to diving into an existing code base and figuring it out, fixing things and adding new features. But I simple _cannot_ come up with stuff on my own. I've been trying ever since I was a kid and started programming, and now it's been 20+ years of drawing blanks when I try to "think of a project."

Hopefully I'm not alone in this :P

<comment><USER17> There's no need to be creative about it. I never try to (re-)invent the wheel myself. Once I'm done with #1 on the list I posted, I evaluate the strengths and weaknesses of the language and pick something that probably already exists. Say for the case of Rust when I was learning it ~3 years ago, that was a private dropbox-like service which syncs files I listed in a config file to a GCP filestore bucket. Nothing fancy or complicated but still - <USER2> checksums, syncing, error reporting, all the usual stuff. Eventually further extended it to encrypt personal documents before pushing them and so on. Doesn't have to be big or complicated or something that no one has done before. Matter of fact, doing something that already exists is the better option cause you can transfer concepts.

</comment></comment></comment></comment><comment><USER19> Parts that are harder (for me) than anything on the list:

\- buying into a paradigm specific to the language at the beginning. Sure, everyone tells me that multiple dispatch is great in Julia, but that doesn't click until you write a decent amount of code.

\- frustration of dealing with exceptions, special cases and unexpected behaviour (R is full of these, for example)

\- teaching materials that pile all language features too early on which makes it realy hard to understand why you're doing things in a certain way (the Rust book stands out as an example of this)

\- the mental block of comparing the ease of use of the new language to one you already know ("this can be done easier in Python" can be applied to _a lot_ of cases when you're a beginner)

\- more limited reasources than what you're used to. If you're used to a hugely popular language like JavaScript or Python, it's really noticeable when your new language doesn't have a StackOverflow answer for every question that you can possibly have.

</comment><comment><USER20> When first I read the title I thought it meant human language and so figured "oh yeah, be in a relationship with a native speaker"

I'm not going to break up with my gf but we met specifically (at first) as we are both lisp programmers. Hmm, but actually it's probably not a bad form of pair programming: "oh, you'd donut that way? Wouldn't it be easier to express it _this_ way?"

</comment><comment><USER21> The last year or so I really gotten into learning/exploring new languages and frameworks(don't flame me). I used to do it the old fashion way of just reading the docs or doing some tutorial.. BUT what I found out this last year, learning a new coding languages (and all it's eco-system) the best way is to watch a good YOUTUBE video !

It's sooo underrated I think ! You get to see all the steps (I hate it when the web-based-examples have code-snippets but the omit the filenames !) Try doing that in a new language or framework that uses a LOT of files (java, angular etc), plus you can speed up the video, I watch most "learning videos" at 1.25x

<comment><USER22> I watch all YT videos at 2x speed and it's still a slower way of absorbing information than just reading.

<comment><USER5> Oh, I try never to have a video at all. It's slow, hard to search, hard to go back, hard to jump useless stuff, hard to comprehend, and hard to interrupt.

Yet, the GP's point stand. If you see the video of a person starting a python project, it won't be missing the `virtualenv` parameters that he would omit in the text tutorial.

Video also beats anything else (except physical presence) on discovering what somebody did to cause a bug.

</comment></comment></comment><comment><USER23> So, a Python fanboy. Well, I remember when I learned Python 5 years ago, I did all of these. Before that I did them all with C# 14 years ago, and before that I did the same with Java, VB, PHP, C/C++, ASP, HTML etc etc(you insert any fad in past 20 years, I've done it) all the way back to 90's when I started with Pascal and Assembler.

The general answer to all of them is "you grind and RTFM". I too am awaiting the time when all I need to be expert in a new technology is to just go buy the plugin I'll insert into my brain (hopefully we'll become cyborgs, that's my optimism) but until then is grind & RTFM.

<comment><USER24> >grind & RTFM

Nothing is more true, as I start to relearn C after 20 years, that there is no substitute for the above. Literally, there is no good C tutorial or way to learn other than just writing some goddamn code and trying to make it compile.

<comment><USER15> There is some helpful literature, though. You might possibly appreciate "Modern C": [http://modernc.gforge.inria.fr/](http://modernc.gforge.inria.fr/)

<comment><USER24> It's just what I needed, thanks again.

</comment></comment></comment></comment><comment><USER25> I can relate a lot to this. Maybe a part of this is also due to the language we are already familiar with. I'm not sure if the difficulty of your language would affect this, but I feel like learning a new programming language is difficult because we are very comfortable with the one which we already know.

I mostly use JavaScript for various purposes. While moving to other languages, we expect certain things to be present naturally and be as easy as they were in your previous language.

Several strong reasons, as you mentioned too, occasionally encourage me to learn a new language, but after a few days of frustration, I end up coming to JS. Maybe this is how JS/Python has spoilt me with the flexibility they provide, or maybe I am utterly lazy.

One solution to this which I can think of is building a mini project related to something the new language you are learning was originally made for. For example, if you are planning to learn Rust, try a small CLI, or some low-level project instead of directly building a web server. I'm not sure if I'm correct though.

</comment><comment><USER26> I kind of think the author is coming up with excuses, because he is afraid to learn a new language. Like, just start a new project, learn as you go. In a couple days, you should know enough to figure anything else you need to know on your own. In those first couple days, post on reddit or whatever.

Also, why would you use Windows as a dev environment unless you absolutely had to?

The author is creating artificial obstacles in order to justify not learning.

<comment><USER27> Well obviously if you're willing to spend the time you can do it.

The issue is that they're not willing to spend the time, given that there are so many unknowns and decisions that have to be made. That's a very legitimate point, given that the default attitude in most programming communities is to pretend that learning new languages is almost zero cost and pure benefit.

</comment></comment><comment><USER28> Most of these would make a pretty good checklist (if phrased more positively).

</comment><comment><USER29> Not included: where's numpy? Where's networkx? Where's either scikit-learn or scipy.sparse.linalg?

I'm not a C.S. undergrad. I can be coaxed into rewriting random forest regression or whatever but there are even more pressing underlying matters. What's the pipeline for reading CSV files or querying sql databases and laying results out on a dataframe-like for transformations?

</comment><comment><USER30> At this point the hardest part of learning a language is unlearning the other languages. Is it "if-else if-else" or "if-elif-else"? Is it "def blah()" or "fn blah()" or just "blah()"? Is it "len(string)" or "string.len()" or "string.length()" or "string.size()"? Do I need a semicolon? Is it "lambda x: x+1" or "x => x+1" or ...?

After that, I find the nano-culture of the place I'm using a language the hardest to figure out. "How dare you use {} instead of end", "Everything must be split into fine grained functions because long functions are death!", all the shit that really doesn't matter that much, but is just the fashion of the group I find myself in.

It's like learning regional accents and terms with human languages.

</comment><comment><USER31> All languages have an ideological component to them. Here is a list of languages with "everything is a $THING" in it. [https://argumate.tumblr.com/post/118013166244/python-what- if...](https://argumate.tumblr.com/post/118013166244/python-what-if- everything-was-a-dict-java-what) As a pythonista language-naut like the author I think the fun part is trying on the language du jour's ideology and figuring out if you can get productive with it.

</comment><comment><USER32> This is why e.g. JavaScript on the backend, web frontend and mobile can be compelling. Figuring out IDEs, code standards, test frameworks, build tools etc. for two languages can be a lot of work.

</comment><comment><USER33> I feel those are more the tedious parts, then they are the hard parts. Maybe I just have a nack for that stuff, but it rarely takes me more than a day or two to have all that figured out.

Once you get to mastering the paradigms, syntax and semantics is when the hard part begins.

</comment><comment><USER34> OT: is there a reason why my submissions are often attributed to other people right after I posted them when they posted before me and submissions of other people aren't attributed to me even tho I posted before them?

<comment><USER35> Not sure exactly what you mean, but this has been submitted multiple times before:

[https://news.ycombinator.com/from?site=hillelwayne.com](https://news.ycombinator.com/from?site=hillelwayne.com)

<comment><USER34> I see, thanks.

<comment><USER35> It's interesting that some things (even the same thing) reach the front page and some things don't though.

It may depend on time of day, the interests of who's reading or checking "new", what other submissions are competing with it and perhaps who submitted it and/or who upvoted it.

This has 111 upvotes now but even that raw number doesn't seem to matter; submissions can and do reach the front page with just a handful of upvotes.

</comment></comment></comment></comment><comment><USER36> What I can say from a personal standpoint is that learning Elixir has been a really pleasant experience.

Many of the points mentioned in there are well managed by the friendly community, and the superb inline help system.

</comment><comment><USER37> Database connectivity and OO are the point at which every new language becomes useful for me. I try to get there as fast as I can without skipping any fundamentals.

</comment><comment><USER38> This list almost perfectly matches my frustrations when learning a new language, and to be honest it's why I don't bother anymore.

I started off in Python and have looked at Ruby, Pony, Rust, JavaScript, etc so I'm aware there are other ecosystems out there but I feel none of them really approach the ease of C# .NET, especially with .NET Core.

On a new system I can install the dotnet core sdk, call `dotnet new mvc` then `dotnet add package npgsql`. I've got everything I need to write a web app that connects to a Postgres database. I can launch up Visual Studio for free and have almost unparalleled intellisense, etc. Or on a non Windows system Visual Studio for Mac or Visual Studio code. The project template gives me everything set-up and it 'just works'. If I'm not sure how to use a library I don't have to leave the IDE to browse through variable quality documentation, I can autocomplete to victory or use the REPL or just debug and write the code in the debugger with edit-and-continue.

Once it's time to move to production `dotnet publish -r linux-x64 -c release` and I have my production ready deployable application.

Now when I go back to Python or these other languages at least one or more parts of that process is missing. I know I'm biased but it feels like for other ecosystems the 'pain is the point'. It should be as simple as that and it needs tooling, especially an IDE to match.

Almost certainly people feel this way about other languages they use, but I think there's an enraging habit for software development as a field to throw away the old tool we were used to and that was comfortable and worked, for some new thing that doesn't get the job done and is a godawful pain to work with (goodbye XML hello YAML). This really contributes to my burnout and disillusion with the field in general, though I'm on the road to recovery.

Edit: This rant clarified what I'm actually frustrated with. There's no way .NET would have reached the (excellent) point it is now without competition from other ecosystems, the whole dotnet CLI owes a lot to other ecosystems and evolution does improve things.

But I'm just sick, in this field, of feeling like a failure, or a fossil because people are constantly hyped about some hot newness and if it gets introduced, I'm going to have to learn it because that's the job. I'm not excited to learn flavour of the month cloud tool, or database replacement, or configuration language (I hate YAML so much) or language or framework. Other people are, and that's fine and good, but if those people introduce the thing at work then I now have to learn it and 9 times out of 10 we'll be having discussions 5 years down the road about why micro-services, or NoSQL or whatever it might be, was overhyped and we've found the right approach (which was almost identical to the approach before we started this). People should be free to have fun with those new tools, but I feel there's explicit or implicit judgement of people who just want to use the tools they know, that have known best practices and failure modes and whatever else. TLDR: you'll take my RDBMS from my cold dead hands.

</comment><comment><USER15> I hope this goes into a time capsule. I will shed some light on how life as a software dev was like in the early 21st century.

</comment><comment><USER39> > And people keep telling me that $AUTHOR is a serial killer?

What is this a reference to? It's a hard google.

<comment><USER40> Yes, I was wondering. I know of one prominent open source programmer who was a murderer, but he invented no programming languages and committed only a single murder.

<comment><USER41> Who

</comment></comment></comment><comment><USER42> Yup. You don't so much learn languages as ecosystems.

</comment><comment><USER43> story of my life

</comment><comment><USER44> TL;DR

The Hard Part of Learning a Language

...is all the learning. Screw [all] this [learning], I'm going back to Python.

<comment><USER16> The author's point seems to be that it's hard to figure out _where_ and _what_ to learn. They're not complaining they have to learn new things.

<comment><USER44> The list of 'what' to learn is the list itself, with the exception of the unknown unknowns which will become known unknowns when encountered. This to me _IS_ learning. Still reads like a rant after being faced with more learning than hoped.

      - How do I install it?
      - Which editor? IDE? Vim plugin?
      - How do I.. read a file? parse JSON? environment variables?

How do I do any of the things that aren't part of the core syntax/semantics but are super common problems people face every day? I'm going to have to memorize another 100 functions and their parameters, aren't I?

      - What are the language quirks that will cost me an hour to discover?
      - How is the help organized?
      - I hit problem X.
      - How do I debug?
      - Testing.
      - How do I build? package? manage environment?
      - Package management.
      - So… the language community.

Is it worth it? For most languages the answer will be "No", for others unless you've already really gotten into several very different ones you won't know.

</comment></comment></comment><comment><USER45> Brave

</comment><comment><USER46> He should honesty consider using a different operating system one thing.

<comment><USER47> You must not work on anything remotely related to desktop gaming.

<comment><USER48> well neither does the author; they're writing python

<comment><USER49> Several well-known desktop games use Python.

</comment></comment></comment></comment><comment><USER50> I skimmed this post and I agree with it. But I wouldn't want to actually read it.</comment>


LUCID, an Open-Source Chrome Developer Tool - <AUTHOR> https://reactlucid.io/ <comment><AUTHOR> Our engineering team is excited to announce the beta release of LUCID, an open-source Chrome Developer Tool.

LUCID lets you: • visualize your React component hierarchy, and state/prop changes • log GraphQL schema, queries, and mutations in real-time

[https://reactlucid.io/](https://reactlucid.io/) [https://chrome.google.com/webstore/detail/lucid/pnaoeldlekbf...](https://chrome.google.com/webstore/detail/lucid/pnaoeldlekbfpnalhabggkcddleelamc)

We welcome all feedback and contributions, including flagging issues, and/or requesting features for future releases.

And don't be shy about giving us some github stars! And Chrome WebStore stars too!

Have a wonderful New Year, and hope to see you in 2019!</comment>


The "Housing Affordability Crisis" - <AUTHOR> http://blog.kwelia.com/2014/03/27/the-housing-affordability-crisis-affordable-low-income-rentals-without-federal-assistance/

<comment><USER3> This is a defining problem of our current urban generation.

It's fascinating to read about the Next City study that "concludes that poor housing affordability in Philadelphia is a symptom of low income rather than of insufficient rental supply."

Having studied this in depth, specifically in regards to China's Ghost Town problems where they increased housing supply by many folds - Here's the current VICE documentary on it.

[http://www.youtube.com/watch?v=trs_udhjWqc](http://www.youtube.com/watch?v=trs_udhjWqc)

The problem is not one of supply divorced from affordability. There needs to be both sufficient supply (ie. Not SF / LA) and there needs to be sufficient affordability (ie. Not China). Yet with these two constraints people seem to sit around wringing their hands unable to do anything. It's almost as if, politically, people are incapacitated by this problem. To which I always respond - look at Ford. The Pre-Ford cars had the same problem, lack of supply and lack of affordability. And Ford changed the equation with the Model T, by making an affordable, readily available car - thereby jump-starting the car economy worldwide.

We CAN do the same thing with housing. By eliminating the speculative incentives on housing (as is done in Germany) through capital gains taxation, and through multiple non-residence ownership taxation, we can address some of the market structures that diminish affordability. And on the other side we can create growth opportunities, through zoning primarily - such as a reduction in the required number of parking spaces per residence unit - <USER2> through a reduction in average square footage (which has been growing in America over the last 30 years) --

[http://www.census.gov/const/C25Ann/sftotalmedavgsqft.pdf](http://www.census.gov/const/C25Ann/sftotalmedavgsqft.pdf)

And while this is just a start. This can be done. We don't even need the 'political will' to do it. We just need to do it. With just a few slight changes in the way we manage our housing inventory, both financially, and with regards to zoning and planning, we could radically alter the availability of affordable (NOT low income! or qualified housing) Over night.

<comment><USER4> >>through multiple non-residence ownership taxation

Can you clarify what you mean by this? It sounds like basically a "landlord tax."

>>reduction in the required number of parking spaces per residence unit

Certainly that would reduce costs in some cases, though it could be problematic in others. eg, many neighborhoods near me already have a shortage of parking (street parking is constantly full), and the zoning only calls for 1 spot per unit. Reducing that would just lead to more problems, and probably parking tickets for residents.

>>reduction in average square footage

That would certainly help, particularly in areas where the land is expensive.

<comment><USER5> I interpreted the "multiple non-residence ownership taxation" as more of a non-landlord tax.

I met a fellow back around 2002 who owned twenty houses out in Arizona. He had never actually seen any of them - he just owned them as an investment. Also, since being a landlord was too much hassle and legal liability, he wasn't renting them out. The houses just sat vacant and he intended to make his money on housing prices outpacing inflation.

The theory behind the tax is that having large numbers of houses sitting around empty is a poor use of resources. By increasing the property tax on unoccupied houses, the owner is encouraged to rent out the units, increasing the overall housing supply and thereby decreasing rents.

<comment><USER4> Ah, so a "housing speculator tax" or an "unused residence tax." That makes a lot more sense than a landlord tax.

edit: Occurs to me that this would help deal with bank-owned properties that can sometimes sit vacant for quite a while. OTOH, that very thing might make it harder to get a mortgage - lenders would be scared they'd end up owning some unsaleable property in downtown Detroit, and paying elevated taxes on it to boot.

<comment><USER3> Correct. Vacancies that accrue speculative value, or vacancies that are covered by rental insurance destroy the housing supply chain. Rentals on the other hand are amazing. They are a great way for people to start on their way to home ownership, and they are great for labor mobility. Robust rental markets should be supported by the type of residences allowed by planning - granny units, alley units, secondary units, etc. Plus smaller rental units as well.

</comment></comment></comment></comment></comment><comment><USER6> This seems like very circular logic. There are not many single-family units available to rent to ELI (Extremely Low Income) renters for <= 30% of their income. Right, if there were then you wouldn't call it _ELI_.

To look at it another way... Plot the price of every rental, sorted by price, X axis is percentile, Y axis is price. ELI is defined as the Xth percentile price times 3.

You want more cheap housing? State it another way, you want to encourage investment in cheap housing. Land is scarce, housing has lots of fixed costs, renting is a massive risk to the landlord.

One interesting catch-22 is the stronger the renter protection laws, the more risk to investors who would build and rent these units.

There are a lot of ways to make this area less risky for investment. Better legal frameworks to deal with problem renters. Better tools to select reliable ELI renters. Better legal framework for using these tools to screen renters. Better tax incentives for renting to ELI tenants (subsidies).

</comment><comment><USER7> In many older parts of California you can rent an apartment over a garage. Great system. Revenue for the home owner, good environment for the renter, distributed rentals. Of course that was then, right? When people talk about rentals versus homes now they have a mental image shaped by very strong zoning. That is the apartment strip, this is the single home suburb.

Compare to Japan, Tokyo in particular, with tiny homes and tiny apartments pushed into every nook and cranny.

Why do our costs keep rising? Because we have structured it that way, for the apartment owner and for uniform suburban living.

</comment><comment><USER8> Rents higher than 30% of income seem pretty normal to me (living in Germany). Makes me wonder: aren't rents prone to rise to the level that people can bear? If people can bear 30%, rents will rise to that level in attractive locations.

That's part of what makes the game rigged against common people.

<comment><USER9> > Makes me wonder: aren't rents prone to rise to the level that people can > bear? If people can bear 30%, rents will rise to that level in attractive > locations.

In econ this reasoning is related to the diamond-water paradox: [http://en.wikipedia.org/wiki/Paradox_of_value](http://en.wikipedia.org/wiki/Paradox_of_value)

The gist of it is that it's only accurate to assume so when supply is very low. But like water, despite being crucial if housing supply is high enough it should decrease in price until it approaches the marginal cost of production. In this case, it's almost always laws and regulation that prevent he supply from increasing; this in part because (a) most voters (in the US) are home owners who have a vested interest in increasing home value, and (b) people are resistant to change and don't want new housing developments in their towns.</comment></comment>


Logan's Run depicted as a giant LEGO diorama - <AUTHOR> http://io9.com/5648293/logans-run-depicted-as-a-giant-lego-diorama <comment><USER2> God that was a terrible movie...

So bad that I actually watched the whole thing to see if it could possibly get any worse.</comment>


The Last Browser Tab You'll Ever Open - <AUTHOR> http://www.droplix.com Droplix makes it easy for you to manage your social media profiles, email accounts and favorite shared media from one location. Never open another tab to connect with friends, family and colleagues again. <comment><AUTHOR> Here's the quick pitch: Droplix makes it easy for you to manage your social media profiles, email accounts and favorite shared media from one location. Never open another tab to connect with friends, family and colleagues again.</comment>


Good Lord, the World Is Using Almost 500B Plastic Water Bottles a Year - <AUTHOR> https://www.fastcompany.com/40436286/good-lord-the-world-is-using-almost-500-billion-plastic-water-bottles-a-year <comment><USER2> Bottled water is an important prophylactic is countries where municipal and surface water are unhealthy to drink. As usual, however, governments fail to hold corporations and consumers responsible for the environmental cost of not recycling the plastic containers.</comment>


PHP Is an Industry - <AUTHOR> https://txt.fyi/+/37eb5136/ <comment><USER2> I've been writing PHP professionally in some form for over 15 years. I don't think I've been out of work for more than a week and I currently make a very good living (well into the 6-figures in the Midwest).

While PHP has it's issues as a language, it works very well for many companies...and if you are good, you can get paid very well.

True story.

<comment><USER3> I also spent some time in the lucrative "I'll fix your PHP project" space. It was a good paycheck, but it could be downright miserable. I'm sure static analysis is better than it used to be though.

I think if you like fixing bugs (kind of like solving puzzles) and easing the pain of stressed out small businesses, it's a great niche. I actually had a teacher who still gets paid enormous sums to fix COBOL code for industry, so perhaps PHP5 will be similar one day.

<comment><USER2> "I think if you like fixing bugs (kind of like solving puzzles) and easing the pain of stressed out small businesses, it's a great niche"

Fixing bugs is only a small part of what I do (like most developers). This is less about the language and more about the previous developers that the small business hired.

PHP runs almost everything for a client of mine (hundred-million dollar+ company) (I'm a consultant). I'm regularly involved in new features and new code. New features and changes in PHP7 has made PHP into a much better language.

I feel like Rails is the COBOL of our time. I remember when all of the cool kids were using it around 2007 and the blind zealotry that ensued when anyone tried to discuss its shortcomings.

Those same people now have since jumped ship and now are mostly involved in various Javascript Frameworks.

</comment></comment></comment><comment><USER4> This has got to be one of the most terribly misguided, typo-ridden, and judgmental posts I've ever seen about a programming language.

1\. "Crappy language for crappy developers" Seriously? Because Facebook among other very large companies still use PHP

2\. An "industry"? Stuck? I've seen so many people easily transition out of a job using PHP because people don't CARE about what language you're using, they care if you're a good engineer. I can promise you, referring back to point 1, that there are "crappy developers" for every programming language. Companies worth working for care about your skill set as an engineer overall, not which language you might have worked with.

3\. No actual arguments on why PHP is bad from a technical standpoint? The ecosystem and language has only been getting better and better. You can't just say "PHP BAD!" and act like you have some coherent argument.

Not worth my time spent. It's clear you favor Ruby, but I'm not sure who you're trying to convince with this narrative. The "lol PHP sucks" meme has been dead for a while now.

</comment><comment><USER5> I would say that its smarty templates that need to go in the bin.

Its a terrible, horrible POS that should have died a long time ago.

And all the frameworks.. So many, there is no need. Just pull in what you need using composer.

PHP has came a long way, its just that most people haven't noticed the language has improved and now has a great package manager.</comment>


A free, complete guide to Technical Analysis - <AUTHOR> http://zerodha.com/varsity/module/technical-analysis/ <comment><USER2> Anyone thinking about doing doing some technical analysis may well become less enthusiastic about the idea if they first played around with generating some random time-series with statistics similar to the real thing and then dwelling on the fact that they look pretty close to the real thing. GARCH(1,1) isn't a bad place to start (although it's not perfect). I just put up some R code on github for this here: [https://github.com/mhowlett/garch11](https://github.com/mhowlett/garch11) which I was experimenting with in the past. I can't remember the state of it exactly, but I think it works.

<comment><USER3> Looking pretty close to the real random and being actually random are two different things, which is why RNG analysis is so difficult.

</comment></comment><comment><USER4> Technical analysis is far from useless. As an active trader, it's the best tool I have come across. I'm sorry, but to say that it is useless is to admit pure ignorance, or to admit your failure to grasp the concepts and understand how to apply them visually and correctly.

People do apply techniques incorrectly, yes. They can get confirmation bias from it, yes. However, that does not invalidate successful traders who trade primarily on technicals. Keep in mind that a "tool" is just that - but not used the same way by everyone - and "this means that" isn't a blanket rule that always works as described. Everything is part of a larger structural puzzle. Also, HFT algos will eat your lunch if your hold period is too short. I don't hold a position for more than a week, MAYBE two, but never less than 45 minutes - and as a retail trader, that makes a huge difference in P/L ratios over time.

Through my trading experience I have continuously used less fundamentals and more wonky technical techniques I have come up with. It has given me a massive edge over whoever is on the other side of the trade, and has pulled me quite a long way out of debt and into making a nice living doing it on the side. The side of the story that you don't see in the endless "get rich quick" trading schemes that promise to teach you all of those super awesome secrets is that anyone who knows what they're doing isn't spending any time teaching it to the masses.

But, to get back on topic: Well done with this site! It's a great beginner guide to understand what a lot of the basics actually mean. Babypips falls very short.

<comment><USER5> But what is the empirical basis to things like Fibbonacci retracement levels ?

<comment><USER6> They are self fulfilling to an extent - because all the TA day traders are using the same signals

<comment><USER2> If that is the case, it would create a market inefficiency which some other market participant could come along and exploit (anticipate the TAs moves and act preemptively). Your statement is basically saying there is no one out there smart enough to do this.

<comment><USER7> Not necessarily! Suppose a bunch of noise traders are piling into a stock because all seven green lights are on in the software they bought for 29.95 from an infomercial. Let's take as an assumption that this algorithm has no idea what it's doing. The smart money thing to do would be to _buy_ now (since investors are going to keep buying as they notice their text alerts or sound alarms or whatever tells them to buy the stock) then sell again knowing full well you are driving the price further from fundamentals in the short term. The best response to past irrationality is to trade against it. The best response to future irrationality is to trade with it. That irrational behavior might be forecast-able should not be a huge surprise.

Momentum is a well established empirical regularity in stock prices. Knowing this, you trade with the momentum at then trade against it later. This does not help momentum go away.

</comment></comment></comment></comment></comment><comment><USER8> Technical analysis doesn't have any science backing it up. However, as most pop books are some form of swing, candlestick, Bollinger bands, mean reversion, it creates a self-fulfilling prophecy.

If you're going to play the markets, it's quantitative analysis or go broke. And that is a literal go broke!

</comment><comment><USER9> Funny, I read this is as a free and complete guide to the effects of confirmation bias.

A free and complete guide to bullshit is just bullshit.

Technical analysis is a farce.

<comment><USER10> Its free to support their main business. Zerodha looks to be a brokerage.

<comment><USER11> So, baiting more suckers, I mean, "day traders".

</comment></comment></comment><comment><USER12> Technical analysis is the homeopathy of finance.

<comment><USER13> Can you provide any useful information other than a cool sound bite? Is there a better way to analyze equities? There is a lot of computer trading. Must be some analysis happening. I'm sure a lot of us here would like to be pointed in the right direction.

<comment><USER14> They are better analyzed against each other. A starting point is modern portfolio theory.

<comment><USER15> Oh, you mean the portfolio theory that "risk managed" so many financial institutions safely through the latest financial crisis without a scratch?

</comment></comment></comment></comment><comment><USER16> The only guys that get rich with technical analysis are the ones that sell books about it.

<comment><USER17> That's true in most industries, don't dig for gold, sell shovels.

</comment></comment><comment><USER18> The only important indicator on a chart is price, and volume in some cases to confirm price. But all decisions need to be based on price action. Chart analysis is just a tool to read the emotions of other traders, that's it.

Think about it, you see a 3 day rally with wide range bars and on day 4 you get a narrow range bar where the open and close are the same (or very close). What does that tell you? Momentum has stopped and people are undecided. There's nothing subjective about that. After this the stock can move either way, but you are getting an indicator that something's going to happen and you have to monitor closely. You can tighten the stops or exit completely. The decision is up to you. But you are using the chart to make an educated decision.

Another example, after a 3 day pullback on day 4 you see a narrow range bar with a very long tail. This is called a Hammer [[http://en.wikipedia.org/wiki/Hammer_(candlestick_pattern)](http://en.wikipedia.org/wiki/Hammer_\(candlestick_pattern\))]. This tells you that at some point during the day the sellers were in control but something happened and buyers took control and raised the price. This was a war and the buyers won. This usually changes momentum and leads to a rally. An explanation for this could be that at some point during the day many stop loss orders from long term investors were triggered and short-term buyers see it as an opportunity to buy and raise the price.

I just gave you two examples where Technical Analysis can be effective. Does it work all the time? Of course not. But you have a better picture of what's happening, therefore your odds are higher and you can use this information to lower your risk.

Finally, you have to remember that for every buyer there's also a seller and vice versa. When you buy a stock (long) you have to ask yourself. Is the person selling me the stock profiting or taking a loss? Is the other person a beginner, professional trader or institution? You have to find scenarios where you buy the stock from the beginners taking a loss (even if it sounds cruel). Given enough time and hard work you can develop experience necessary to spot where all these people buy and sell and use this information to your advantage.

Does it work all the time? NO

Will you have losses? YES

Can you still make money? YES

</comment><comment><USER15> Backtesting[1] is really critical when deciding on whether to use a given technical indicator.

I've read too many books and articles, and heard too many anecdotes that make some technical indicator sound fantastic. But until you backtest it (and then forward test it) against a large amount of data, and make sure you're not curve-fitting, I don't think you can have much confidence in it actually working in the real world in the long run (though you may get lucky and have it work for a brief period of time).

For backtesting, the best tool I've found is AmiBroker[2]. It's orders of magnitude faster than any other backtesting tool that I've found, and lets me backtest mountains of data against any indicator I can dream up within seconds or minutes, and then go on to the next one. It's pretty awesome (though kind of quirky in that its programming language is array-based). Anyway, highly recommended.

[1] - [https://en.wikipedia.org/wiki/Backtesting](https://en.wikipedia.org/wiki/Backtesting)

[2] - [http://www.amibroker.com/](http://www.amibroker.com/)

<comment><USER19> Alternatively, you can save your money and use one of the myriad of backtesting tools built into existing trading platforms using a demo account.

<comment><USER15> Yeah, you can, but they usually suck... especially compared to AmiBroker, in my opinion.

</comment></comment></comment><comment><USER20> Technical Analysis can be useful, because it enables a systematic approach to trading - eliminating subjectivity when making trading decisions. _Consistently_ exploiting some edge with a well defined set of rules and conservative risk management is key.

</comment><comment><USER21> Just put a tools ruler on a chart and you can see the future. Easy as that. And wrong.

</comment><comment><USER22> The guide opens with an analogy suggesting that picking the best stocks to invest in is equivalent to picking the best restaurant to eat at, and that technical analysis is equivalent to looking for the stall with the most people at it.

If technical analysis is equivalent to looking for the restaurant with the most people at it, then the restaurant that you're trying to find is the one that, over the period that you intend to eat there, will gain the most new customers, relative to the number of customers it had when you walked in, not the one that's best to eat at.

The flawed analogy exactly explains the problem with technical analysis.

<comment><USER23> > "If technical analysis is equivalent to looking for the restaurant with the > most people at it, then the restaurant that you're trying to find is the one > that, over the period that you intend to eat there, will gain the most new > customers,"

Which pretty much is what you want to achieve in certain markets.

For instance, if you are trading with CFDs and want to close your positions in the short term, you want to predict the right direction in an instrument with high volatility, which tends to be correlated with the amount of people trading in the same instrument (restaurant with the most people for a given period of time)

</comment></comment><comment><USER5> How would you account for the effect of other people using Technical analysis on stock prices

</comment><comment><USER24> It's not complete bullshit, just unusable for trading nowdays: these algorithms that found trends worked until better algorithms were used:

[http://en.wikipedia.org/wiki/Technical_analysis#Scientific_T...](http://en.wikipedia.org/wiki/Technical_analysis#Scientific_Technical_Analysis) The results were positive with an overwhelming statistical confidence for each of the patterns using the data set of all S&P 500 stocks daily for the five year period 1992-1996.

<comment><USER10> > The results were positive with an overwhelming statistical confidence for > each of the patterns using the data set of all S&P 500 stocks daily for the > five year period 1992-1996.

Looks a bit like cherry picking</comment></comment>


Oscar Wilde's new play opens in Manchester (1892) - the-enemy https://www.theguardian.com/culture/2017/aug/23/oscar-wilde-lady-windermere-fan-review-manchester-1892 <comment><AUTHOR> Out of curiosity I did a little benchmark of this rather convoluted but well written 1892 review against a limited sample of 2017 theater reviews. All from The Guardian.

Some of my findings:

\- Recent reviews are < 2000 chars long, versus 5856 chars in the posted article. \- Recent reviews are 22 words per sentence long on average, versus 28 words/sentence avg in the article. \- Recent reviews have 62% unique words, against 39% uniqueness in the posted article.

If we compared news articles instead of reviews, I bet the difference would probably be more remarkable.

To do this I've used this online tool:

[http://countwordsworth.com/wordspersentence](http://countwordsworth.com/wordspersentence)</comment>