Why CoffeeScript Isn't the Answer - <AUTHOR> http://www.walkercoderanger.com/blog/2014/03/coffeescript-isnt-the-answer/ <comment><USER2> I used CoffeeScript full-time for a year, both client-side and server-side (node.js). I completely agree with everything here -- it's a _great_ summary, and it describes exactly while I never, ever want to use it again.

In CoffeeScript, ambiguous code is the rule, not the exception. On top of that, things like variable capture and everything-returns-a-value introduce new kinds of bugs. The author says "realistically, the issues I have raised with CoffeeScript don't come up every day," but in my experience they pretty much did.

But the real kicker on top of it all is that none of the stuff is documented. When you're trying to guess if you should use parentheses or a comma or an indent or a newline or a backslash or _what_ , there are no reference documents to help you. The CoffeeScript home page just has a bunch of tutorial examples which give you an overall idea, but there's nothing rigorous, and the devil is in the details when you start combining aspects of the syntax.

In the end, I'm much more productive programming in JavaScript because I know _exactly_ how the language works, no surprises. JavaScript has its fair share of warts, but you take a day or two to learn them, and then you never need to worry about them again. CoffeeScript, on the other hand, is just endless surprises. And I still felt that way after a whole _year_ of using it at work. It's basically unlearnable -- no matter how much experience you have, you constantly find yourself pasting different versions of a line into the "try" tab of [http://coffeescript.org/](http://coffeescript.org/) until you get one which, through trial and error, turns into the JavaScript code you want.

<comment><USER3> You completely agree with everything he wrote, after a year full-time? Really?

So you would use curly braces and commas to specify an object, and then be confused when CoffeeScript doesn't get it?

After a year you didn't figure out that its a best practice to leave off the parenthesis in just the outermost function call, but to include them in the other calls on a line to make things clear?

After a year, you didn't realize that with the CoffeeScript scoping rules, you couldn't just throw in a global at the last second without looking carefully to see if it was used somewhere else?

After a year, you still hadn't learned about function binding with fat arrow?

After a year, you still hadn't learned that the existential operator (?) means you don't have to use typeof nearly as much?

<comment><USER2> Ha! Not necessarily those specific examples, but the overall reaction to it. Here are a couple of other articles which explain the same things:

Section "full of surprises": [http://ruoyusun.com/2013/03/17/my-take-on- coffeescript.html](http://ruoyusun.com/2013/03/17/my-take-on- coffeescript.html)

[http://ceronman.com/2012/09/17/coffeescript-less-typing- bad-...](http://ceronman.com/2012/09/17/coffeescript-less-typing-bad- readability/)

And here's an old HN comment of my own which described a few representative difficulties: [https://news.ycombinator.com/item?id=4518892](https://news.ycombinator.com/item?id=4518892)

Also, there's no such thing as a global in CoffeeScript (unless you explicitly specify window.xyz), since everything is scoped to the file. And that's the point -- it's ridiculous to have to "look carefully" at all your code to see if functions further down share a variable name _inside of them_. In JavaScript, you don't need to worry about that because you know "var" scopes each variable to its function, regardless of whether a higher function or global variable uses the same name. In CoffeeScript, you suddenly _do_ have to worry about that, which is fairly insidious and bug-prone behavior.

<comment><USER3> Hm.. well you may want to use more precise language in the future, because you said you "completely agree" and that it describes "exactly".

So you are saying that none of those particular issues are problems you are having today with CoffeeScript or were problems for most of the year?

In which case, what problems did you have?

Edit: it looks like in another thread you are pointing out some random and unmaintainable code examples that are ambiguous and saying that its hard to know how they will be interpreted by the compiler. Its hard to know how those examples would be interpreted by anyone, or why you would write code like that and create that problem for yourself.

</comment></comment></comment></comment><comment><USER4> This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is:

        # BROKEN
        func 5, {
           event: (e) ->
             if e.something
               36
             else
               45,
           val: 10}

Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler:

        # far better
        func 5,
           event: (e) ->
             if e.something
               36
             else
               45
           val: 10

Note how just dropping the excessive notation makes the intention clearer while also making the code cleaner.

His example on variable capture neatly illustrates a few of the opinions of CoffeeScript that actually make it far easier to reason about code: don't use global variables, and if a variable has the same name, it should refer to the same thing. It's far more confusing to allow rampant variable shadowing. Code that relies on variable shadowing is simply broken.

His last example shows a fundamental misunderstanding of not just CoffeeScript, but JavaScript generally. Granted `this` binding can be sometimes confusing, which is why CoffeeScript has a fat arrow (`=>`) to automatically capture `this`.

<comment><USER3> "More than a day's experience" is not really fair.

It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day.

The rest of what you wrote I agree with.

But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally.

I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but thats another issue) whereas initially I thought that CoffeeScript was a joke.

Then I had to learn CoffeeScript because it was used in a library that I needed to understand.

It was only _after_ I had invested the time in learning CoffeeScript that I could see the advantages. In fact, up until that point that I had learned it, CoffeeScript _was not_ an advantage for me -- it was a liability, because I didn't know how to use it. When you aren't familiar with a language then whatever advantages it may have are more than offset by the fact that you don't know what you are doing.

I think this is a problem that pretty much every new paradigm shares to some degree. It is very difficult for the average person to emotionally get behind the effort to learn a new way of doing things, and psychologically we just aren't wired to make an accurate judgement about whether that will pay off.

Judgments and decisions are actually emotional/subconscious and the rationalization comes afterward.

<comment><USER5> the minutia of most efficiently optimizing your syntactic sugar to communicate DEEEEP meanings is the most annoying part of the open-source/language community & one of the biggest factors in why i've actually come to like corporate java.

i've been on so many RoR interviews where i am dismissed essentially for not knowing enough of cutesy syntax tricks and yet in the Java + plain ol' javascript projects i've worked on I've been exposed to a muuuuuch wider variety of programming design patterns than i ever was in Ruby-land, to the point where i could care less about the tiny semantics these hipsters spout on about

one of the few new languages i'm interested in working with now is Clojure simply because they cleanly define libs & then don't have all of this obsessive "syntactic sugar" nitpicking. to make a language / code library usable it shouldn't depend on developers going down a rabbit hole of brackets etc. I understand this is difficult to avoid in the "compile to js"/language pre-processor community but it's why I prefer Dart as a solution. It is an attempt at a clean, robust, simple language rather than a repeat of the annoying language evolution process where devs in the know just talk down to those who don't care to commune with punctuation all day

</comment></comment></comment><comment><USER6> It's a tool, that is all.

 _Ambiguous code_ is a poorly thought out contrived example with a simple solution.

To me, this:

        eat food for food in foods when food isnt 'chocolate'

Is kind of beautiful and much more readable than:

        for (var i = 0, var len = foods.length; i < len; i++) {
          var food = foods[i];
          if (food !== 'chocolate') {
            eat(food);
          }
        }

How is this even an argument?: _" One wouldn't realize it was conditional until reading the end."_ How do you expect to understand any code without reading it? How do you understand people when they talk without listening? And the whole paragraph is moot with syntax highlighting.

Variable clobbering is javascript's problem not coffescript's.

ECMAScript 6 introduces a syntactic sugar for classes as well as like every single JS framework.

Knowing plain old JS is important, especially for understanding CS. CS is just a tool that some people find useful, I don't really understand the passion or frustration.

<comment><USER7> Your Javascript example is a bit contrived too. How about:

      foods.filter(function (e) { return e !== 'chocolate'; }).forEach(eat);

Regardless, I disagree that the Coffeescript example is more readable. My brain is much faster at parsing symbols (`(`, `{`, etc.) than english words.

With your JS example, without having to read the words, I know there's a loop, a conditional and a function invocation. I also know that I can safely add statements after this piece of code without worrying it might break some other function (in Coffeescript, I'd have no way to tell if the implied return really mattered or not assuming it was the last line of a function).

With your CS example, I have no way to tell what's going on until I've read the full sentence. I have to read every word and see if it matches one of the many reserved keywords in order to determine if it has a special meaning or if it's just a regular variable.

In Javascript, you have a few reserved words but the list is relatively short and those words are almost always preceded by a line break or a symbol.

Maybe our brains work differently...

<comment><USER8> I'm obliged to agree. Even the "contrived" example is easier for me to parse given that I have years of seeing "{}[]()" as delimiters.

Not to mention that filter/each functions will get even easier to parse once es6 standards reach the browser (stabby procs, woo).

<comment><USER6> I don't understand. Because you have been doing something one way for years, a different way is harder and thus worse?

I'm not trying to be inflammatory at all just wondering as this is a reply to my comment.

</comment></comment></comment></comment><comment><USER9> Ok, so if CoffeeScript is just JavaScript, add the parenthesis. If you need brackets to make a section of code readable or compile to "certain" JavaScript, then add them. Even the programs I work on we add parenthesis, brackets, etc for readability. Use CoffeeScript to increase productivity. Nowhere does CoffeeScript say you must use white space instead of brackets and such. Keep it simple and easy, classes are also nice; I'll be reading those are articles soon as well to gain less of a bias.

<comment><USER10> There are still two sides in programming, it seems. And interestingly enough it's not necessarily static vs. dynamic or procedural vs functional.

One the one hand you have pragmatic, loosey goosey languages like perl, javascript, ruby, even scala and C#. An important defining characteristic being perl's maxim "there's more than one way to do it".

On the other hand you have what I'd call the "bondage and discipline" languages like python and java. The defining characteristic being "there should only ever be one right way to do a thing".

In my experience people coming from the 2nd world have a harder time living in the 1st than vice versa.

<comment><USER11> It's not that simple if you go beyond surface impressions and common usage. There are in fact many ways to do the same thing in Java and Python, some better than others. Both languages have escape hatches that can be used to extend the language; it just requires more effort.

Reflection and annotation processors in Java are very powerful tools; see Guice, Dagger, and AutoValue. Creating something like JQuery is awkward in Java, but it can be done; see GQuery. Java 8 will make functional and callback-heavy DSL's a whole lot easier to build.

Python may look like a strict language but it's not. You can redefine just about anything except the core syntax. If you want to make your head spin look into metaclass programming.

Haskell is a weird one; statically typed, but extremely expressive. It's very easy for Haskell programmers to define their own obscure notations and like when reading mathematics, you must understand the definition of every symbol or you're lost.

One interesting dimension is the attitude towards modifying other people's libraries. In Java, it's easy to build something that nobody else can change unless they fork the library and modify the source or mess with the bytecode. But if you build your own, you can do what you want. In more dynamic languages, you can load someone else's library and muck with it at runtime.

</comment></comment></comment><comment><USER12> _> > Why CoffeeScript Isn't the Answer_

What _is_ the question for which CoffeeScript is a compelling answer?

 _" I needed to speak to Germans, so I learned French and spoke through a French-German interpreter. Things were occasionally lost in translation and somteimes I couldn't get my point across, but French is prettier. Can I recreate this experience in code?"_

 _" My team can't learn to write `var` or `===`. Can we just learn a new language instead?"_

 _" Indentation speaks to my aesthetic sensibilities, but braces do NOT! What fits my needs?"_

 _" I don't want to use JavaScript. Fortunately, since I never make coding errors, I'll never need to debug transpiled JavaScript. What's the right language for me?"_

Seriously, though, what is the problem that CoffeeScript solves?

<comment><USER3> [http://en.wikipedia.org/wiki/Status_quo_bias](http://en.wikipedia.org/wiki/Status_quo_bias)

CoffeeScript obviously solves problems. Its not compelling to you because of status quo bias, and because you don't want to invest the effort to learn it.

The issue with equality is a real issue. CoffeeScript solves that issue.

Braces and parenthesis _do_ become awkward in JavaScript with callbacks. CoffeeScript solves that problem.

You have been able to debug CoffeeScript as CoffeeScript for some time now with source maps. However, debugging the generated JavaScript is not hard for someone who knows JavaScript.

<comment><USER13> Its cute you link to status quo bias, then immediately state, like a fact from god that "braces and parenthesis _do_ become awkward (...) Coffeescript solves that problem."

It's your opinion that coffeescript solves the callback and parentheses issue. I'd also call your argument a bit of red herring.

... FWIW? I think futures do a mighty fine job of solving callback issues; no coffeescript needed. Design around them, don't make a whole new "dialect" for it..

<comment><USER3> For callbacks I have found ToffeeScript to be an even bigger improvement than CoffeeScript. You can write code like this:

        e, personJson = fs.readFile! "person.json"
        person = JSON.parse personJson
        matchesLastname = myDB.query! "lastname", person.name
        id = msgQueue.push! { JSON.stringify(matchesLastname) }
        log.info "Message sent to queue: #{id}"

instead of this:

        fs.readFile("person.json", function(e, personJson) {
          var person = JSON.parse(personJson);
          myDB.query("lastname", person.name, function(matched) {
            msgQueue.push(JSON.stringify(matchesLastname), function(id) {
              log.info("Message sent to queue: " + id);
            });
          });
        });

Why do you believe that it is better to design around serious issues rather than creating a new paradigm?

I have found that the best solutions always involve a new/different fundamental model that incorporates solutions to recurring problems.

<comment><USER13> I guess I just don't think it's a serious issue. I've found that often when I have an "issue" it's more so my design lacking not the tool (javascript) itself.

<comment><USER3> What would the code look like for my example using futures in JavaScript?

<comment><USER14>
        fs.readFile("person.json")
        .then(function(e, personJson) {
            var person = JSON.parse(personJson);
            return myDB.query("lastname", person.name);
        })
        .then(function(matched) {
            return msgQueue.push(JSON.stringify(matchesLastname));
        })
        .then(function(id) {
            log.info("Message sent to queue: " + id);
        });

<comment><USER3> That's part of it. What about creating the promises?

<comment><USER14> that's in there, with the assumption that you're using the promises based node.js api, but if you aren't, and you're using Q, that part looks like this

        var readFile = Q.denodeify(FS.readFile);

which doesn't create the promise. it just wraps the readFile method so that it returns a promise when you call it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I agree with some the things he writes, but others seem blatant absurdities:

> "the + operator is still both numeric addition and string concatenation. > That is frequently listed as one of the bad parts of JavaScript. Why no > provide separate operators for the two?"

The problem isn't operator overloading: the problem is implicit type coercion.

Having to use 2 separate operators/functions for separate types when writing code, is useful only if types are actually checked at compile time, and the compiler can do inference on them (see the + and +. operators in F#)

If you have a dinamically typed language, you can have sane semantics if you make it so that type conversions are explicit (e.g. Python, Ruby...)

See also: [http://james-iry.blogspot.it/2009/03/operator-overloading- ad...](http://james-iry.blogspot.it/2009/03/operator-overloading-ad- absurdum.html)

<comment><USER16> The problem is the combination of the two. You can have operator overloading if conversion is explicit. You can have a converting operator if the action is explicit. But you can't have loose overloading and automatic conversion at the same time without silly defects.

Edit: And you didn't just disagree but call it a 'blatant absurdity' to blame the half of the problem that you happen to like better? Jeez.

<comment><USER15> I agree, "blatant absurdity" is quite a strong wording. I should've wrote "quite dubious" or the like.

In my defense, I didn't even think of having a language with type coercion and 0 operator overloading (even on builtin types). I never saw such a language, and I'm skeptical that it could work. But it's an interesting take on the problem.

I cannot say why I think that the no-coercion+overloading is the better solution... maybe that's because operators are dyadic, and thus type coercion can be executed on both sides of the operator, and multiple times. While function application is (can be?) sort of monadic (in the APL sense) since coercion/overloading for an argument doesn't depend on the type of the other arguments supplied to the function

(But while writing this, I'm not so sure anymore... at the very least, it could depend on the order in which arguments are evaluated...)

<comment><USER16> What I think of here is Lua, where builtin types have no overloading and there is a single type of coercion, between numbers and strings. This coercion is only triggered by arithmetic operators and concatenation. Unambiguous and pretty harmless.

(Technically objects can overload binary operators (with no coercion) but it's not very common)

</comment></comment></comment></comment><comment><USER17> This article only proves that when doing it wrong, CoffeeScript causes problems.

No parenthesis make nested calls unreadable? Simple add parenthesis for the inner calls. Like in any other language with optional parenthesis (Ruby) too.

Too long statements are unreadable? Don't write them. Maintaining an 80 or 100 character line limit is good coding practice anyways.

<comment><USER18> That's kind of the point of the article: If it's easy to get it wrong in CoffeeScript, i.e. CoffeeScript has its own bad parts, then you're better off just learning to deal with the bad parts in JavaScript directly.

</comment></comment><comment><USER19> This is not the first article talking about CoffeeScript's ambiguity and readability issues.

It's interesting how CoffeeScript fans almost always decide to blame the programmers for these problems. They said good developers should use common sense and use best practices to make code readable, for example by always using parentheses when calling functions. I hear exactly the same argument in the Perl community.

But reality is that if a language allows you to write bad code easily, people will write bad code, and you will have to read bad code. This is very easy to verify: most CS project on GitHub, starting with the CS code itself ([http://github.com/jashkenas/coffee- script](http://github.com/jashkenas/coffee-script)) contain a lot of bad ambuigous uses of the language. A very similar thing happens with Perl code.

Programming language design is not only about making it easy to write good code, but also about making it hard to write bad one.

<comment><USER20> It is hard to argue, however, that Javascript (the thing Cofeescript purports to improve) doesn't "allow you to write bad code easily" or "makes it hard to write bad code". I have avoided Coffeescript and probably will continue to do so, but it seems to at least try to make it a bit harder to write bad code, albeit not getting all the way there apparently.

</comment></comment><comment><USER21> I do have some frustrations with CoffeeScript as outlined here - I find the unless keyword infuriating because it forces me to read backwards:

        a = 123 unless b == 2

"OK, so a is set to 123. Oh, unless b is 2. That's annoying"

That said, my answer is to just not use the unless keyword. If you don't like CoffeeScript classes, you don't have to use them. IMO you could write CoffeeScript using only the kind of functionality availabie in vanilla JS and it would _still_ be a preferable experience.

<comment><USER22> I really like that syntax, I think it reads well.

Of course, I've known Perl for 20 years, so that might have something to do with it. :-)

</comment></comment><comment><USER23> Am I the only one astounded that we're still having this conversation? The fact that it's still around shows me it has indeed been "the answer" for some. The fact that it hasn't become ubiquitous is plenty of proof that it also is not a one size fit all solution, as if any solution is.

</comment><comment><USER24> I wonder what the author thinks of GorillaScript [1].

[1]: [http://ckknight.github.io/gorillascript/](http://ckknight.github.io/gorillascript/)

<comment><USER25> Very interesting! I was nodding along through the first dozen syntax features or so, which seemed much more obvious and well-chosen than CoffeeScript's, and then they just kept piling on... Promises? Macros? Generics??

I won't prejudge GorillaScript, but if someone ever makes a language like this that exhibits both good taste and a little more restraint, it could get wide adoption.

</comment></comment><comment><USER26> "CoffeeScript isn't the answer because I don't understand how it works."

</comment><comment><USER27> This seems to share many of the same things of CoffeeScript I've had. I prefer plain old JS. More readable, unless you're looking at twitter bootstrap code... No semicolons? Such messy code IMO.

</comment><comment><USER28> I find CoffeeScript very readable, and I highly value readability. The extra verbosity of JavaScript doesn't really help me when I am reading code. I read CoffeeScript code faster than I can read JavaScript because CoffeeScript removes so much of the repetitive boiler plate code and lets you focus on the intent of the code.

I don't really understand the ambiguity argument. From the code examples in the article, I get the impression that the author doesn't really understand CoffeeScript.

I definitely prefer CoffeeScript to good old JavaScript.

</comment><comment><USER29> I had a lot of niggles with CoffeeScript as well, which is why my compiles-to- JS language of choice is LiveScript[1]. It fixes basically all the annoyances and adds a lot of nice things on top of that. For exmaple, you can write more paren-free code with it and there are more kinds of useful function declarations (hushed functions, curried functions, backcalls).

[1] [http://livescript.net/](http://livescript.net/)

</comment><comment><USER30> Mm, most of the issues the article discusses are part of the learning curve of Coffeescript IMO. The real problem I've had (and I still love it for some reason) is dealing w/ JS frameworks. Like, try using Coffeescript w/ Angular or something. It's quite difficult.

</comment><comment><USER31> Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules.

With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping.

I'm done, this isn't suitable for prime-time, time to go somewhere else.

I spent too many years in the 80s working with xBase. I've been shafted too many times by calling a (coworker's) routine that forgot to declare its variables "private", which stomped over one of my variables. (private in xBase is similar to local in Perl 4) To have a language which doesn't let you declare the intended scope of a variable - ugh.

<comment><USER32> I've used coffeescript extensively for years, and I have never had that be an issue. Not sure if it's because I rarely write a file longer than ~200 lines, or I'm careful about variable names and global scope.

More generally I've found that coffeescript mixes much better with a functional style than with an imperitive one.

<comment><USER33> This, to me, sounds just like Douglas Crockford when he dismisses all the evils of Javascript as "things that never happen to him". Which is interesting, given that they occur to me and my work mates on a fairly regular basis.

<comment><USER32> I don't think the gist is that there aren't problems with these languages, but that with a little carefully placed construction tape, you can avoid falling into the large holes.

<comment><USER33> Yeah, people say the same thing about C++. It's great when you have your own carefully curated subset of the language.... and then you have to deal with other programmers & libraries

<comment><USER32> The difference being, you can't avoid javascript (if you want to target the browser); you can either write it directly, or use it as a compile target. Each has it's strengths and drawbacks.

</comment></comment></comment></comment></comment></comment><comment><USER34> Phew. I was beginning to worry that a whole month would go by without a blog post about CoffeeScript's deficiencies. I hate it when I write unidiomatic code in a language and then get punished by said language.

Now that I got my sarcasm out of the way, whenever somebody bashes CoffeeScripts variable shadowing they openly show the world that they don't understand how variable scoping _should_ work. CoffeeScript covers up JavaScript's warts. One of those warts is JavaScript's broken implementation of closures. CoffeeScript is trying to help you, don't let your lack of understanding of lexical scope get in its way.

</comment><comment><USER35> > The declaration of what food is occurs in the middle of the line and doesn't > even look like a variable declaration.

And that's what makes the whole line unreadable. And 'unless' would make it even less readable.

I can understand why people insist on discussing such personal, subjective matters as "readability" or "expressiveness" \- I like that too. What I don't get is why do they confuse their impressions with facts and why do they try to generalise based on them. Is it that hard to admit that what's readable to you may be completely unintelligible to someone else?

Comparison of programming languages, outside of some really technical metrics, will always be subjective and preference-based. Discussing metrics as vague as "readability" without even agreeing on what it means is absolutely pointless. Yet so many man-hours go into debates and blog posts, sometimes even books, which cover such issues. It's stupid, straw-man discussion every single time it appears.

I really wish people would stop writing lengthy posts with a sole purpose of informing the world about their preferences. It's not that I'm against people having preferences, I'd just like them stated as preferences, not facts, and preferably only when they are not repeated a millionth time this month.

Edit: also, this: [http://joelgrus.com/2013/12/24/why-programming-language-x- is...](http://joelgrus.com/2013/12/24/why-programming-language-x-is- unambiguously-better-than-programming-language-y/)

</comment><comment><USER36> > eat food for food in foods when food isn't 'chocolate'

> from the CoffeeScript tutorial...Furthermore, ___until you finish reading > the line it isn't clear which foods will be eaten_ __.

The thing with typing the filter at the end is, that format has its basis in mathematical notation, particularly in set theory. Using an even terser mathematical syntax/notation, you could write the same expression this way:

        { eat(food) : ∀ food ∈ { foods } ^ food ≠ "chocolate" }

You read that as "the set of eat(food) where for all food in the set of foods, the food isn't chocolate". The notation will be quite familiar to mathematicians, and thus if you have a strong mathematical background, especially in set theory, discrete math, and combinatorics, the CoffeeScript array comprehension feels natural.

See the Wikipedia article on Set-nuilder Notation/Set comprehension, [http://en.wikipedia.org/wiki/Set_comprehension](http://en.wikipedia.org/wiki/Set_comprehension).

Here's another example from the Wikipedia article:

        { x | x ∈ R ^ x = x^2 }

This reads as "the set of all x, where x is a real number and x = x^2", which evaluates to the set { 0, 1 }.

</comment><comment><USER37> I believe there will be a day when converting CoffeeScript to just native JavaScript won't be very difficult, but until that time, it's useful as a way to have neat syntax features without having to wait for browsers to support it. Indeed, many of the features CoffeeScript introduced into the JS developer's mindset are or will be present in the upcoming ECMAScript specifications. We can only assume this trend will continue.

</comment><comment><USER38>
        delayed: () ->
          -> this.model  # isn't the class

Well, that isn't really fair now, is it? You could have used the fat arrow (`=>`) for binding `this` to the class.

With that in mind, I agree with the author in that CoffeeScript isn't the answer, at least not exactly. With syntax this incredibly similar, how far are we from compiling python (with generators, with statements, imports, ...) to JavaScript?

<comment><USER39> >how far are we from compiling python

I frankly find CoffeeScript nicer than Python. There are advantages and disadvantages, obviously, but whenever I'm writing Python, it makes me long for CoffeeScript.

<comment><USER40> Going from CoffeeScript to Python (bundled together with going from Node.js to Python) is painful. So many things that CoffeeScript has learned over Python - of all of them, "everything is an expression" rule.

</comment></comment></comment><comment><USER41> This is a bit overly critical. The implicit parentheses are optional, so if it's confusing or ambiguous you should just use parentheses.

        func 5, {
           event: -> 45,
           val: 10}

Is reasonable but

        func 5, {
           event: (e) ->
             if e.something
               36
             else
               45,
           val: 10}

Really ought to be split up for readability no matter what programming language you use. And besides, the only issue is the extra comma causes it not to compile.

To be fair, the `->` vs `=>` (which `this` is `this`?) for class members is confusing. I'd almost prefer class members didn't give you the option and defaulted to `=>`.

The "variable capture" section is overblown, though. You're a lot less likely to run into this issue than the classic JavaScript "I forgot `var` and now my variable is global.

My biggest complaint is actually the implicit returns. Sometimes I forget a return statement but it works anyway because of this feature. Then I come back later and modify the function slightly only to spend a bunch of time figuring out why it's returning `undefined`.

<comment><USER42> If you write JavaScript in strict mode the probability of incidentally declaring something as global is pretty much zero. Those mistakes can also be properly linted and warned against - which is not possible for CoffeeScript's implicit declarations. And at least I had real-life situations where CoffeeScript's scoping broke code in very subtly ways.

</comment></comment><comment><USER43> Then, for sure, Clojurescript is the answer.

<comment><USER44> Clojure is really hard for me to use, coming from a lisp background. The various special forms seem to sometimes want a list and sometimes want a vector and sometimes don't care. I've yet to find a way to keep track of that.

Anyone have a link to something from Rich mentioning why vectors are used in basic syntactic constructs? It's the one departure from its lisp roots that I couldn't figure out any motivation for.

<comment><USER45> I've never seen any explanation from Rich on the subject, but semantically speaking, vectors used in syntactic constructs are almost universally meant to denote binding forms. Let-bindings, loop-bindings, function parameters and the like all use vectors in the context of binding symbols to values.

I find that, having gotten used to the mental shortcut "square brackets == binding", the distinction makes it easier to read the "shape" of code from a very high level and get a general understanding of its meaning at a glance. YMMV.

</comment></comment></comment><comment><USER46> The example in "Ambiguous Code" is ridiculous - if you write CoffeeScript like that then you have much bigger problems. Also, the part in "Classes Are an Illusion" totally fails to mention the fat arrow `=>`, which solves the main issue the author raises.

However, this part I completely agree with:

> Realistically, the issues I have raised with CoffeeScript don't come up > every day. Ultimately though, they are enough to say we need something > better. I hope to share some thoughts soon on what such a solution might > look like.

CoffeeScript isn't perfect and we should always be looking for better solutions. So I'm glad that the author wants to add to the discussion. While CoffeeScript isn't _the_ answer, it's probably the best answer we have so far,

</comment><comment><USER47> Coffee-script is awesome but suffers from it's roots as a preprocessed layer on top .. and that essentially leads to poor overall tool chain support .. I actually enjoyed writing code in it .. debugging not so much .. Would love some of the constructs to make into JS

</comment><comment><USER48> I have a rule of thumb that coffeescript is never appropriate for code that has to be require()'d by any code written by somebody else than me.

I'll happily use coffeescript, and enjoy doing so, when that condition is met. It doesn't happen very often though.

</comment><comment><USER49> While it might not be the answer, it has been a very good answer for me. Recently I worked on an Angular project that had a pretty complex data model, and converting the model to CS made the code much more readable. The rest of the app was still in JS, minus a ./models directory which was CS. The other devs found the code very readable also.

I am biased towards Python and Ruby. I think that they are nice looking languages.

Different tools for different jobs. Next time I am on a JS project and I want to model data, I will probably use CS again.

</comment><comment><USER50> Answer to what? What's wrong with Javascript in the first place?

<comment><USER51> For me, coffeescript was the answer to the question "How can I write javascript with python-esque whitespace block formating?" I suspect the author was asking something like "what can replace javascript?"

<comment><USER52> Coffeescript seems to be more like Perl, where parenthesis are often optional, and meaning is implied by the context a lot of the time.

I like Perl, but I tended to be fairly pedantic with parenthesis and things when writing it. I prefer explicit over implicit. (Though sometimes implicit can save you a ton of time).

</comment></comment></comment><comment><USER53> The only gripe I share is scoping, and that's fixed in LiveScript. I've started writing LiveScript in a fairly explicit style - for example I use parentheses where they improve readability and I always use curly braces for object literals. Qualitatively I think it's increased the readability of my code way beyond JavaScript. It's nice to have curly braces carry specific meaning instead of being littered all over the place.

</comment><comment><USER54> CoffeeScript is putting lipstick on a pig. It's pretty damn good lipstick, but still being applied to a pig.

</comment><comment><USER55> My problem with CoffeeScript has always been the syntax vs. semantics issue. CoffeeScript saw a big opportunity to improve JavaScript semantics and help programmers more easily avoid the JavaScript minefield ("var" and "===" for example), but in doing so decided "while we're at it, let's overhaul the general syntax too".

Gratuitously changing "function" to "->" for no reason other than removing characters seems to introduce more brand new idiosyncrasies than it's worth. If the goal were to improve JavaScript as a language by smoothing over a few of the gotchas, which of course would require a few syntax updates, then I think it would be immensely valuable. (Think SCSS instead of the original "Sass".) But it seems as if the authors were more troubled that JavaScript didn't write like Ruby, so they made a new language that happens to compile to JavaScript. And now I have two languages to choose from, each with pros and cons and their own gotchas, adding more complexity to my decisions when I was hoping for simplification.

<comment><USER56> I totally disagree regarding 'function'. Good javascript tends to be more functional than imperative. That means using 'function' a lot. Most functional languages use either fun, fn, or lambda, all relatively short words for this because it's used ALL THE TIME.

Shortening it to two chars made sense IMHO. The long form of the word function directly impacts code quality and readability.

</comment></comment><comment> mck- These pitfalls can be easily avoided by following a styleguide [1]

[1] [https://github.com/polarmobile/coffeescript-style- guide](https://github.com/polarmobile/coffeescript-style-guide)

</comment><comment><USER57> There is still not "answer", and the world is not gonna end tomorrow, in the future maybe will be one but until that day comes i will stick with whatever i find appealing to me at present. For now is CS.

</comment><comment><USER58> CLOJURESCRIPT IS THE ANSWER! no question about it

<comment><USER59> The problem I have with clojurescript is i couldnt find any closurescript tutorial that did not involve java.

Let's say i want to start using closurescript,like coffeescript.

i want to do npm install -g closurescript then

closurescript compile myscript or closurescript myscript.

How do I do that?

If closurescript folks want their language to be popular with javascripters i need to be able to do that.

Right now,searching on google,on npm, i did not find any tutorial that did not involve maven or java.You cant expect a nodejs developper to learn maven or install the JVM for the sake of using clojurescript.

coffeescript is popular because it's easy to get started with.You dont even need to install anything,just add the coffeescript compiler to a HTML page.

<comment><USER58> npm depends on a javascript compiler such as g8 so how is that different than clojurescript depending on the JVM ?! It's no different at all you're just complaining that you don't like to have to install software before using it which is ridiculous if you want to use powerful software.

<comment><USER59> what is ridiculous is a compile to javascript language that is not written in javascript itself.

</comment></comment></comment></comment><comment><USER60> Sometimes I think that most CoffeeScript, ClojureScript, etc. programmers are people who were advanced in other languages before they learned JavaScript. There are quite a few programmers who have no issues with these "bad parts" or "really bad parts" because they cut their teeth on them, and these numbers are growing: Most people now learn JavaScript as their first language. JavaScript already won, and things like CoffeeScript are the last gasp of the old regime.

<comment><USER61> As someone from the old regime (cut my teeth on spectrum basic in the 80's, get of my lawn etc etc) I sorta agree.

For years I avoided using javascript beyond wiring little bits of jQuery together because I hated the language but eventually I ran into a project where I could no longer do that and resolved to _learn_ javascript properly.

Many wtf's where had but now looking back I realise that Javascript is a warty language (but then show me a widely used (top 10) language that _isn 't_).

I still don't like it but I don't hate it and I just accept it for what it is.

<comment><USER60> To an extent it is a Devil you know/Devil you don't thing. The moment one of the JS-first people get bitten by the CoffeeScript compiler (having to indent/dedent something, move a comma, suddenly your code is working ... I think everybody runs into the sort of issues the author described) they are going to go back to JS. JS is such a high-level language already, and the browser vendors and SSJS projects seem focused on advancing it. I just don't see much room in the future for languages like CS.

<comment><USER61> I agree the other issue with someone like me using CoffeeScript is that first I'd want to _really understand_ Javascript otherwise I'd never be able to trust that I could fix any bugs I ran across, it's another layer of abstraction I essentially don't need.

</comment></comment></comment></comment><comment><USER62> Livescript or Gorilla are what I would want from a .js precompiler. Coffeescript just removes brackets and readability.

</comment><comment><USER63> >I ... couldn't figure out how to write the CoffeeScript for the JavaScript I wanted.

</comment><comment><USER64> What is the question?

</comment><comment><USER57> Who said it was?

</comment><comment><USER65> CoffeeScript seems to be an efficient alternative to plain Javascript. The fact is you can't avoid seeing Javascript completely. Just try debugging in Chrome or any other browsers built-in debugger and you'll know what I mean.</comment>


Practical IT Audit Experience - <AUTHOR> I would like to get some hands-on about IT Audit. Could anyone guide me into something like open-source or volunteer activity which, I could associate with to learn? <comment><USER2> What area of IT? There's tons of resources as Audits are regulatory framework based.

IT: COBIT is a good start

Security: ISO 27001 (popular in EU) GDPR (EU) PCI (Credit Card) HIPAA (Health Sector) SOX/GLBA (Public Companies) ...

List goes on

<comment><AUTHOR> I am new, but Security would be one of my interests. If so, would you know any options?

</comment></comment><comment> astropod-match which country are you trying to be based at?

<comment><AUTHOR> US</comment></comment>


When does intelligence become a curse? - <AUTHOR> https://www.quora.com/When-does-intelligence-become-a-curse?share=1 <comment><USER2> Yes. Yes. Yes. Some sections hit like a stone, most things match my experience (even the comments).

Im already at a level where i relearned the "just do"/"just feel" thing. Also have some kind of a Sally/Bill-Situation. Instincts are odd. I envy ignorant people abit.

Great Article.

</comment><comment><USER3> well, shit. this explains a lot.</comment>


Ask HN: Start-up 1 – Success, Start-up 2 – Asking for too much? - <AUTHOR> A couple years ago I met a small group of experienced entrepreneurs (1 success each, key industry knowledge/connections).
They were struggling to get traction with a start-up. Their outsourced webapp was buggy and messy. They had <20 users at this point.
I came in and developed the MVP they needed. To build trust and learn the industry, I accepted a medium cash low equity deal.
Fast forward a couple years, I led the system to 50M+ valuation with thousands of paid users and 5 employees under my wing. I let someone else take my position and I moved on.
A month ago, the entrepreneurs called me for another start-up. I agreed to take a look and clean things up for a low goodwill fee. They have a trademarked business name, promotional website, and pilot program interest from major businesses. They also own a running system that provides JSON APIs to interface some key external service providers for this start-up.
They need a technical co-founder to lead, build, and run the product. Specifically now, they need a clean, commercially viable MVP off the ground within 4-8 weeks.
Trusting them, I already developed 30% of the application. If I work 60-80hr weeks, I can deliver the MVP they need within 4 weeks with confidence. But the current agreement expires soon and the tentative long-term deal on the table is <5% equity vested over 2 years with 40+/hr pay like last time.
My proposal is 7%+ equity with 20/hr or no pay for X months. I prefer equity over cash this time. I value this pre-MVP start-up at 2M, max. I know I'm worth 50/hr absolute minimum.
Problem. Of the entrepreneurs, half really value me and half think I'm easily replaced by someone cheaper or a 15K$ contract with a 30-person tech team for the MVP. They can't get consensus to offer me even ~6% vested over 3 years.
Am I asking for too much?
Tech offers conditional certainty, but negotiations have always been tough for me due to the subjectivity of "fair". <comment><USER2> Negotiations are not about what's fair but about BATNA ([https://simplicable.com/new/batna](https://simplicable.com/new/batna)) i.e. Best Alternative To A Negotiated Agreement.

Can you get a better offer elsewhere? If yes, then you have no reason to accept anything less than that offer. Even if those entrepreneurs won't agree to at least match your best other offer, you're not losing anything.

If you don't have a better offer elsewhere then your best option is to accept whatever they offer.

If you want that job then the question is: what is their BATNA? If they can find someone cheaper that can do the job, they have no reason to offer that job to you.

Note: it doesn't matter if they really can do that, only if they think they can.

Other points:

> I agreed to take a look and clean things up for a low goodwill fee.

A mistake. They apparently were in a bind. They needed a job done quickly and you were a proven person for the job. You had leverage. You should have asked for a high fee.

People are strange. It's possible that now they value you less because you did something for them for less than it was worth.

> I prefer equity over cash this time

I'm surprised you're so keen on equity.

Equity is worth $0 until a business has an exit event i.e. does IPO or gets sold to some other company.

If neither happens, the business can be very profitable for 20 years, the owners can pay themselves whatever salary they want from profits but your equity will be worth $0.

Exit events are extremely rare. Or to put it differently, you have a higher chance of multiplying your money by getting max salary, 0% equity and then going to casino and betting on black.

Betting on equity is no different than betting on black but people usually don't think of it that way. Equity in a company that doesn't yet exist is extremely risky.</comment>


Git-annex assistant: Like DropBox, but with your own cloud - <AUTHOR> http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own <comment><USER2> "Then I will build a web app that can be used to control and configure things. Watch files as they upload and download, set priorities, etc. No command line needed. I plan to use Haskell's amazing Yesod web framework."

Is it possible to get Yesod running on shared hosting? I was excited about SparkleShare-Dashboard until I saw it was built on node.js. It would be nice if there was a self-hosted dropbox alternative that I could recommend to people who have the skill level to do something like install WordPress but not the skill to administer their own server.

<http://sparkleshare.org/> <https://github.com/hbons/SparkleShare-Dashboard>

<comment><AUTHOR> git-annex and this friendly interface to it will run without a central server at all, so you won't have to worry about the hosting environment. The Yesod- powered web server will typically run on each local machine on which you run git-annex. And the ability to push to S3, rsync.net, and other storage providers will take care of the most common case of machines on which you can't run git-annex.

</comment></comment><comment><USER3> This space is getting crowded. How many Dropbox clones are there now? I just saw that ownCloud released a new version recently.</comment>


Harvard Biz Review: Steve Jobs's Disastrous iPhone 4 Press Conference - <AUTHOR> http://blogs.hbr.org/cs/2010/07/steve_jobss_disastrous_iphone.html

<comment><USER2> "Today, he was deep in his own personal maelstrom of defensiveness and hostility. His head was frequently down; in fact his whole posture betrayed his unhappiness. He frequently hid his hands behind his back — a classic defensive posture — when he wasn't clasping them in front of his stomach (another defensive posture)."

It was a defensive press conference, by nature. It's not like he's announcing a new product or something. Do you expect, or even want Steve to summon fake enthusiasm on command?

Say what you want about the "reality distortion field", but Steve is a profoundly honest guy, in the sense that he won't convey any impression other than that which he really feels. I bet he couldn't give a Stevenote about a toaster no matter how hard he tried.

<comment><USER3> The closest he came was when he introduced and demoed the Motorola ROKR. And even then he was visibly displeased when it failed on him on stage.

</comment></comment><comment><USER4> "Apple is now a dominant player in the consumer technology market and it can't afford this kind of ham-fisted performance. Jobs should remove himself from the lineup and let someone else take over. Or he should get over himself and cheer up. But Friday's press conference was not good corporate PR."

This is exactly the type of ivy league business exec extrodinaire that could lead to Apple's demise in the post-Jobs era. Yeah, let's be all unicorns and butterflies on stage when our crown jewel, the best cell phone ever made, is being torn apart unfairly by the media. If you're not angry on stage, either your product is defective or you're not being sincere.

</comment><comment><USER5> Strange, might have been the reality distortion field, but as I watched the press conference I though to myself at several occasions "yeah, this will shut the nay-sayers up."

I thought they made a pretty strong case with the data they presented. I myself have never had a dropped call with the iPhone because of the reception issue -- believe me, I have tried. However, the not-so-sensitive proximity sensor has, on several occasions, caused me to inadvertently press the "End call" button with my cheek.

</comment><comment><USER6> Agree with the article's observations, but disagree with its conclusions. Although the article correctly described Jobs' body language, tone, anger, defensiveness, etc., the effect of all that was positive for Apple because it was totally honest and matched the situation perfectly. People who watch the video understand the Jobs has every right to have acted the way he did in the press conference, and that understanding builds empathy for the company and works in Apple's favor.

</comment><comment><USER7> The media is making a mountain out of a mole hill here. Unfortunately for Apple, right or wrong, people listen to the media.

</comment><comment><USER8> So this article goes from using the analogy "Yeah, well, Jimmy stole cookies from the cookie jar, too!" to using beefy words like petulant and contrite. I'm lead to believe that readers of the Harvard Business Review are linguistic ninjas who are simultaneously somehow unable to analyze the simplest abstract description. Or am I reading too much into this?

<comment><USER9> His analogy is majorly flawed, unless everybody is stealing cookies from the cookie jar.

He seems to be more analysing Job's body language and speech, rather than what was said and what was shown.

If the media get another story to follow, they will leave it alone. If not, then they may pursue it for a while longer.

</comment></comment><comment><USER10> Hacker News AKA anti-apple-circle-jerk. Seriously. Stop beating the long dead anti-apple horse, it's starting to smell like reddit.

<comment><USER11> Relax man, don't get so worked up over it. There's plenty of anti and pro apple people here, and the objective is to discuss opinions and present facts.

Besides, reddit's programming, apple etc subreddits are rather sane. Definitely more than their main ones.

Pretty sure there are a bunch of redditors here too. I'm also certain that they LIKE reddit. This place just requires a different mindset when you enter. And your comment, dear sir, is definitely the bad-reddit type.

<comment><USER12> Yeah no doubt. The main reason I don't go to reddit anymore is not due to a lack of good discussion. It's just because I don't want to scroll through a 50-comment long pun chain to get to it.</comment></comment></comment>


Disassembling the Sony FE 135mm F/1.8 GM - <AUTHOR> https://www.lensrentals.com/blog/2019/06/disassembling-the-sony-fe-135mm-f1-8-gm/ <comment><USER2> > _There's also a bit of glue, or possibly just sealant, around the second > group, too. Since the element fell right out once the screws were removed > we'll go with sealant, since that sounds better than ineffective glue._

"The element fell right out" is one of the reasons I've never considered trying to peek inside a lens.

I had a Canon EF 17-35/2.8L (on which I got a really good deal used, because the model is known to be a bit soft, and IIRC parts were no longer available). I banged it at an event (a July 4th exhibition of the ship USS Constitution), the hood didn't soften the impact enough, I held my breath and didn't look at any exposed entrails. I sent it to Canon, with an explanation to the effect of "the front fell off", along with monetary tribute. The lens came back not only repaired perfectly, but calibrated to what might've been better than new. In my living room is a poster-sized print of a crowd photo taken with this lens, and all the great happy facial expressions reacting to something happening are clear and sharp.

<comment><USER3> I love people/street photography, would you mind sharing the poster?

<comment><USER2> I was actually personally very averse to doing street photography, but there seemed to be a fuzzy overlap with photojournalism. In my rules for myself, the difference was when newsworthiness trumps privacy/imposition.

This particular image was when I was learning photojournalism, had just left practicing fluffy stuff at a street fair (e.g., visually appealing image of vendor making candied popcorn), and the crowd I was in suddenly parted, to something newsworthy, and muscle memory kicked in.

I didn't try to publish it, because it turned out to involve a celebrity (who I didn't recognize until a real photojournalist told me), and I had a rule against shooting that, but it was a happy enough image that I had a print made for myself.

</comment></comment></comment><comment><USER4> As an FYI for anybody getting ready to take apart their own lens to repair it, be aware that Japanese made lenses frequently use JIS screws [0], not Philips. If they aren't super tight, you can get away with using Philips, but you wouldn't want to make a regular thing of it.

I've had a no-name 28mm lens apart a couple of times to clear oil off of the aperture blades. The old manual everything lenses are relatively straightforward to get apart. Be aware of the minuscule ball bearing that engages the detents in the aperture ring. It's spring-loaded, which might be obvious to you, but wasn't to me the first time I took the lens apart.

[0] [https://en.wikipedia.org/wiki/List_of_screw_drives#JIS_B_101...](https://en.wikipedia.org/wiki/List_of_screw_drives#JIS_B_1012)

<comment><USER5> > It's spring-loaded, which might be obvious to you

In my experience it's never "obvious" until it flies across the room :D

<comment><USER6> I assume everyone who ever took a manual lens apart has at least one lens with a cine-style aperture ring... that is, without detents.

</comment></comment></comment><comment><USER7> If you enjoyed this, you'll probably also really enjoy the video teardown of the Sony OSS 16-50mm kit lens. It's cool for two reasons — one is that it's a zoom lens, but the really awesome part is that it has an optical stabilization element. There's also a bit more focus on the electronics and motors.

[https://petapixel.com/2016/02/09/this-teardown-of-a-sony- e-m...](https://petapixel.com/2016/02/09/this-teardown-of-a-sony-e-mount-lens- shows-optical-steadyshot-in-action/) (blog bait summary — but with a bit more text)

[https://www.youtube.com/watch?v=g9umAQ1-an4](https://www.youtube.com/watch?v=g9umAQ1-an4) (the actual video)

</comment><comment><USER8> Regardless of weather sealing lenses will get dusty if they breathe. If any outside lenses move the internal volume of air must change and that means air is being exchanged with the outside.

<comment><USER9> Couldn't you make a lens with a vacuum inside?

<comment><USER8> If the lens does not breathe there would be no advantage (it can just be airtight without being vacuum) and if the lens breathes (ie changes internal volume) it means the motor would have to work against atmospheric pressure which would be extremely difficult in a lens to do reliably.

<comment><USER5> Counter question: Why not fill lenses with Nitrogen? I know outdoor cameras CCTV cameras do this (more so to prevent condensation from internal moisture).

<comment><USER10> You'd still have to compress the nitrogen going one way to zoom, and pull the nitrogen against air pressure going the other way. Focus motors powerful enough to do that, plus including movable airtight seals to keep the nitrogen inside, would make the lens a serious chunk bigger, heavier and more expensive.

The dust that gets inside from breathing while zooming rarely affects image quality to any meaningful degree. Excessive humidity can lead to fungus growing on the glass though, which really can ruin your contrast. It's normally good enough to keep your lenses in a box with some silica desiccant during summer to prevent that.

</comment></comment></comment></comment></comment><comment><USER11> That was a fun read. I enjoy reading tear-downs like this, even if the fault was something they weren't able to fix.

<comment><USER12> I also like it that Sony was cool with them doing this.

Despite Sony's insistence on DRM they make some very repairable hardware. For instance, it is dead easy to replace the controller switches, battery, and other parts on the Playstation Vita where the flex cables are very well routed.

<comment><USER13> In general I've found electronics from the major Japanese companies easy to open, well labeled, and designed in a logical manner.

</comment></comment></comment><comment><USER14> Nice writing, and very educational for someone who never had reason to take a lens apart. Explains part of why they're so expensive! :)

I think it's a bit more glue than I like, but still reasonably serviceable for something with small parts in a restricted space. About on par with a Toshiba laptop, not as good as a Thinkpad (based on my experience with now outdated hardware repairs).

</comment><comment><USER15> I love the Lensrentals teardowns! I _just_ finished reading this teardown of a then-flagship Sony camera that was exposed to saltwater.

[https://www.lensrentals.com/blog/2017/10/about-getting- your-...](https://www.lensrentals.com/blog/2017/10/about-getting-your-camera- wet-teardown-of-a-salty-sony-a7sii/)

Or if you're a Nikon fan, here's their teardown of a Nikon flagship a year later. Note that this camera wasn't suspected of exposure or abuse, so not really a comparison but I'm fascinated by how modern pro cameras are built, their weaknesses, and how they may or may not be serviceable.

[https://www.lensrentals.com/blog/2018/10/teardown-of-the- nik...](https://www.lensrentals.com/blog/2018/10/teardown-of-the- nikon-z7-mirrorless-camera/)

<comment><USER6> wrt. casing at least Nikon's pro offerings were always top notch in terms of body ruggedness etc., although up to 2008 or so they did have occasional issues with the rubber coming off at the edges. Some problems with chemical resistance as well. Newer models use a different, notably stronger adhesive. Fewer problems wrt. chemicals it seems, too.

</comment></comment><comment><USER16> I once had to open an old 24mm Pentax lens that my parents handed down to me when I started photography. The aperture was stuck due to some old grease, and with that the lens barely unusable. The fix was pretty easy, and the whole process of understanding all the tiny mechanics of a lens were a lot of fun, but at the same time it was incredibly stressful to have those optical elements so exposed.

I couldn't image doing the same thing with a current lens that also has all those electronics in there.

</comment><comment><USER17> I just disassembled (and didn't bother putting back together) a Sony 16-50mm f/3.5-5.6, the build quality here seems to be better. That was a lot of plastic and parts didn't really "click" in place so much as "mashed in there." I've had to replace this lens twice already (and it's only a very, very part- time camera for me); I am significantly less careful with my Nikkor equipment and never had any issues there.

</comment><comment><USER18> The Sony camera stuff is _really_ built like tanks and can pack a load of abuse. Thanks for the submission, that explains the "why" :)

</comment><comment><USER19> I found this disassembly very interesting. Thanks for posting.

I've taken _a lot_ of stuff apart in my days, but never an expensive camera lens. I've owned, just off the top of my head, a 70-200 f/2.8, 50 f/1.8, 85 f/1.8, and a 105 f/2.8 macro lens back in the day when digital was just starting to catch on.

There are times where I miss photography...I always assume I'll get back into it at some point.

</comment><comment><USER20> Great read - I'm excited for the Sony 35mm 1.8 teardown.</comment>


Firefox for iOS Now Available for Preview in New Zealand - <AUTHOR> https://blog.mozilla.org/futurereleases/2015/09/03/firefox-for-ios-now-available-for-preview/ <comment><USER2> The separation of "Firefox" (brand, UI, browser history, password sync, extensions, etc) from "Gecko" (an implementation of a rendering engine) seems like a good idea to me, even if it was forced by Apple.

Gecko stands for nothing; it's just code. Whereas the Mozilla / Firefox brand stands for things like privacy, security, etc. ([https://www.mozilla.org/en- US/about/manifesto/](https://www.mozilla.org/en-US/about/manifesto/))

The Firefox/Mozilla brand shouldn't be tied to Gecko or any other specific piece of code.

<comment><USER3> I agree, but they still need to deliver the other things that go with the brand: End-user control, privacy, and openness and freedom (as in speech).

I don't know much about Firefox for iOS: Does it live up to those expectations?

<comment><USER4> _End-user control, privacy, and openness and freedom (as in speech)._

If they really wanted to support that it seems like a great opportunity to make a Gecko version of Firefox only available for jailbroken devices, and let their userbase do the rest.

But given the direction they have been heading in the past few years, it seems all their talk about "end-user control" is just clever doublespeak for _Mozilla_ doing the controlling.

<comment><USER5> We have iOS platform support (in progress) in the main (gecko) tree now actually. If anyone is interested in putting a WKWebView compatible API on top of that, please fork the project and submit a patch. Open source! Hack. Mix. Burn! :-)

<comment><USER6> Here is the meta bug for Gecko on iOS: [https://bugzil.la/1163827](https://bugzil.la/1163827)

</comment></comment></comment></comment></comment><comment><USER7> Here is a link to the repository, for those interested :

[https://github.com/mozilla/firefox-ios](https://github.com/mozilla/firefox- ios)

It is programmed using Swift.

<comment><USER8> Thanks!

Let's see if I get it compiled and can test it right now without waiting for the offical release. :> Wohooo~ Open-Source!

<comment><USER5> As a developer, you can absolutely grab the code and run the app on your own own devices. However, there are a few manual steps that you need to take before this works.

If you want to build the v1.0 app with Xcode 6, then use these instructions: [https://github.com/mozilla/firefox- ios/blob/v1.0/BUILDING.md](https://github.com/mozilla/firefox- ios/blob/v1.0/BUILDING.md)

If you want to build the (upcoming) v1.1 app with Xcode 7 beta, then use these instructions: [https://github.com/mozilla/firefox- ios/blob/master/BUILDING....](https://github.com/mozilla/firefox- ios/blob/master/BUILDING.md)

Happy to help here or in a new thread if you get stuck in the process. We have tried to make it as simple as possible but due to some code signing complexity it can't be a 'download & run on device' kind of thing unfortunately.

</comment></comment></comment><comment><USER9> I'm assuming this is essentially a wrapper around WKWebView, as per Apple's rules?

<comment><USER10> and in being so, what exactly is the point?

<comment><USER11> I don't use iOS, but if I did, I'd use it just for multiple search engines, awesomebar history search, and history/bookmark/tab sync.

<comment><USER12> but... you get all of that with Mobile Safari..?

<comment><USER13> What he meant is that if you are a Firefox user in other platforms, you can now keep everything synced including iOS devices. It is mainly for Firefox and ex-users who left Firefox because of lack of iOS option.

</comment></comment></comment></comment></comment><comment><USER14> It's not clear to me why there's no link on the blog post (at least, I couldn't find one); but here's the product page, grabbed from one of the screen shots: [https://www.mozilla.org/en- US/firefox/ios](https://www.mozilla.org/en-US/firefox/ios) .

<comment> o0-0o That link is to signup to be notified... and to subscribe to a newsletter... and to give Moz your data. Just FYI.

Anyone have a DDL?

<comment><USER14> I had the impression that they are intentionally rolling it out by region (the title and link mention that they're starting in New Zealand—unless that's a version name for Firefox?), so I assumed that the link went to a download page if you were in the correct region. If I haven't completely misunderstood, then maybe a New Zealander can comment.

<comment><USER15> They've limited downloads to NZ App Store accounts to prevent everyone from downloading it at once. This lets them do a wider beta test, and fix bugs so when they release it globally everyone else's first experience will be positive. It's common on iOS for games to do this too.

</comment></comment></comment></comment><comment><USER16> Does this allow for installation of add-ons?

<comment><USER17> I imagine that would be in violation of Apple's rules around apps executing 'arbitrary' code from 3rd party sources.

<comment><USER18> Hmm, well firefox could vet them so that they're not 3rd party and the user could permit to inject 'add ons' into every web page loaded. You are allowed to upload html/javascript dynamically (just not shared objects, jvm byte code, etc)

</comment></comment></comment><comment><USER19> I'm not very familiar with how web browsers are built, but would it be possible to write a HTML / CSS renderer on iOS that utilised JavaScriptCore for code execution?

This would abide by Apple's policies given that arbitrary code is still executed through their JavaScript engine, but would give much more flexibility on the rendering side.

It would be more bespoke than simply wrapping a WKWebView.

Is this a feasible path for a browser like Firefox on iOS?

</comment><comment><USER20> does it at least come with its own video player for vp8/vp9 videos?

</comment><comment><USER21> What's the setup for 'default browser' like on iOS now? I guess you can add Firefox as a target for 'Send to' sheets but presumably normal links in other apps will still open Safari?

</comment><comment><USER22> If you guys want to download it you just need an account with an address in New Zealand.</comment>


Show HN: A data science fellowship to solve the world's toughest problems - <AUTHOR> http://www.bayesimpact.org/fellowship

<comment><USER2> I appreciate what you guys are trying to do but I can't seen many mathematicians or statisticians applying for this unless you provide a little more information about what these "hard" problems are.

Honestly it reads like your offering basic in training in a a random selection of tools and then hoping some non profits present a problem with nice clean data that can be solved through application of a few methods from scikit.learn.

If you wan't to attract math people my suggestion would be to identify a few intriguing and hard problems a head of time and taking applications specifically for them...you can always suggest a change if you think an applicant would be better suited to a different one. Providing intriguing problems that might match up with peoples pre existing research interests is key...there is lots of room for cross pollination and growth but a bayesian statistician is going to be much more intrigued by something that might benefit from a hierarchical model then something that needs ODE's or online convex optimization.

Worse 4-6 months might not even be enough time to formulate a problem that needs a solution and get the required data in place. Non profits are generally extremely overworked and take a long time to do things. They will not have their data in anything resembling a database or standardized format...think short hand notes in word files if you're lucky. Identifying people and data you can work with on this end a head of time is key.

For the record I work for a non profit analyzing complex diseases and my background is in math. I've also sat on the board of and been involved in a few other non profits.

<comment><AUTHOR> Paul from Bayes Impact here. I appreciate the sentiment, though in all respect it does seem like most of your concerns are addressed on the website, either on the fellowship page or in the others.

> unless you provide a little more information about what these "hard" > problems are

The second paragraph does go briefly over the problems we are currently working on (granted, not in much detail for the sake of brevity, but enough to give an idea of what type of challenges they are). There is a little bit more information on the front page, but granted since we started Bayes Impact two months ago we haven't been able to put as much work into the website content as we'd like to.

> Honestly it reads like your offering basic in training in a a random > selection of tools

This is simply not the case -- while their level of experience varies, our current fellows actually comprise some well-established data scientists in their own right. It is precisely because the problems worth solving are _tough_ to solve that we need to round up talented individuals who are able to commit to working on social impact projects full-time and pair them up with industry and domain experts who have the domain knowledge but may not have the time.

They each bring their own set of skills -- for example, someone who built Lyft's grid optimization system might be uniquely suited to help save lives by improving ambulance and fire truck dispatch and reducing average emergency response times.

> and then hoping some non profits present a problem with nice clean data that > can be solved through application of a few methods from scikit.learn

This is precisely the point of Bayes Impact and why a longer engagement model such as fellowships is needed in the space (most current data science for social good organizations work on a volunteer basis model), so we have the time to build these longer relationships with nonprofits to leverage data science even in cases where data is messy or sensitive. We go a little bit more in-depth about it on our article here: [http://blog.bayesimpact.org/blog/the-bayes-impact- mission/](http://blog.bayesimpact.org/blog/the-bayes-impact-mission/)

> Worse 4-6 months might not even be enough time to formulate a problem that > needs a solution

This is why they're not 4-6 months, but typically 6-12. We do have a pilot 3 month program in the summer for problems that are comparatively easier to work on.

> and then hoping some non profits present a problem with nice clean data that > can be solved through application of a few methods from scikit.learn

This is why we have a fellowship application page and not a project application page -- we actually tend to identify and scope projects ourselves.

On that note though, I want to point out there is no need to be so overly dismissive of the work nonprofit and civic organizations have been doing in collecting and storing clean data. For example, most fire departments we talked to had surprisingly good data, and some such as the Fire Department of New York had even started initiatives of their own to use data science to improve their processes. For example, by integrating building permit data with their own systems, they've been able to direct inspectors where fire were predicted to be more likely to occur.

One direction we've been headed towards is seeking these data-educated organizations to create pilot projects, then use the results of these as a basis to export these solutions in similar institutions whose data practices may not be as good. In that end, we are helped by some data engineers from companies like Splunk or Cloudera so we do believe in working with these organizations in the long run to bring them up to speed. This is precisely the problem we're trying to solve with our model!

> For the record I work for a non profit analyzing complex diseases

Then you might be interested in the project we are doing on Parkinson's with the Michael J. Fox Foundation! Feel free to email me for more details.

<comment><USER2> I'm trying to offer constructive, if harsh, criticism based on my own experience which includes recruiting for similar positions and working with large and small 501(c)(3)'s.

I don't mean to come off as dismissive but to suggest that your write up is vague to the point of being easily dismissed and provide feedback on how someone from outside your local peer group might read this.

And there are organizations out there with great IT and clean data but I and most people in this field have lost months writing hideous combinations of NLP and regular expression to pull data out of old medical records and things and hand validate it or correct for batch effect in supposedly clean data.

I think that fleshing out the projects and areas of investigation you guys already have lined up would go a long ways towards addressing my concerns and making the program more appealing to the typical analytical folks i've worked with. I'd also suggest focusing the intensive course on analytical methods not the tools, this is what will intrigue people with expertise. At the moment it reads like it is focused at people new the the field with no programing experience.

What data sets/types are you using for the Parkinson's thing? My main focus is on analysis methods that resist the noise, imbalance, heterogeneity and other issues typical in extremely wide/multivariate genetic+clinical+proteomic studies...a few sentences about the study in the write up would have told me a lot about if my skills could be useful. (I'm not looking to relocate but I am always open to collaborations and correspondence with people working on similar things.)

<comment><AUTHOR> As I said earlier -- I definitely appreciate the sentiment, and constructive criticism is always welcome when actually substantiated. I also took your post as an opportunity to elaborate a bit more on our model so my post got longer as a result.

> And there are organizations out there with great IT and clean data but (...)

This argument also works the other way round -- there are organizations out there with terrible data (and this is especially common with medical data), but there are also many high impact projects for which the data _does_ exist in a workable form that are begging to be solved (and that we are actually working on solving). We are focusing on these in the short term, while laying the groundwork for the others in the medium-long term (both through the research arm we are building, and our data engineers). There is no reason not to get the low-hanging fruit first.

> I think that fleshing out the projects and areas of investigation you guys > already have lined up (...)

Agreed. Since we created Bayes Impact two months ago our main focus has been on building the program from scratch and working on the projects as well, so the website has unfortunately taken a backseat. Another problem is that government organizations are very sensitive about communication and we can only communicate about our projects on their timeline. This results in us not having a website as fleshed out as we'd like, but this is par for the course for a new organization.

> I'd also suggest focusing the intensive course on analytical methods not the > tools

Ah, I just saw the paragraph you're referring to. I get how the language may be a bit confusing and will make the appropriate changes -- our goal is actually to do the opposite: we bring on individuals who already have the analytical methods but some may not have had exposure to best industry practices. Because we focus on building _production_ systems and not just write case studies, it's important to bring them up to speed in that minor respect. This is why we can spend only a week teaching tools -- teaching analytical methods to people without the required background would likely take much longer, which is not our target audience.

At a broad level we simply provide an avenue for data scientists to work on social impact problems in collaboration with domain experts, with us taking care of the overhead of scoping projects and doing the dirty work of acquiring and preparing the data as well as defining the implementation strategy. We also smooth out the edges in our Fellows' backgrounds if any but this is really not the core of the program.

Fortunately the pool of applicants as well as our current fellows does not seem to echo your fears but I'll review and see which changes to the fellowship page could help remove ambiguities in the future.

Hope it helps clarify. Regarding the Parkinson's project, feel free to reach out to me by email -- unfortunately we need to wait for the press release from the MJFF and the other partner before I can actually communicate about the details publicly.

<comment><USER3> Seems like you've got big data problems to solve and data scientists up the wazoo.

I would think the missing element would include avant problem-solvers, regardless of (advanced) degrees or not who are as outstanding in that specialty as the data scientists are in theirs.

</comment></comment></comment></comment></comment><comment><USER4> To get more exposure, consider posting the fellowship to these subreddits:

[http://www.reddit.com/r/datascience](http://www.reddit.com/r/datascience)

[http://www.reddit.com/r/datasets/](http://www.reddit.com/r/datasets/)

[http://www.reddit.com/r/statistics](http://www.reddit.com/r/statistics)

[http://www.reddit.com/r/machinelearning/](http://www.reddit.com/r/machinelearning/)

If you have not already, I would recommend reaching out to these companies to sponsor: Cloudera, Palantir, New Relic, Tableau, Domo.

<comment><USER5> Awesome - thanks for the feedback. We're indeed going to post to those subreddits and reach out to those companies to potentially sponsor us. If you know a good contact, we'd love to be introduced!

<comment><USER6> You will also probably find people interested in this on: [http://lesswrong.com/](http://lesswrong.com/)

<comment><USER5> We just tried to, but couldn't b/c of the karma requirement :(

</comment></comment></comment></comment><comment><USER7> I love the last item in the FAQ,

> I am a frequentist. Can I still join Bayes Impact?

</comment><comment><USER8> This is an awesome initiative. It's good to see an organization using and promoting data science for something other than "optimizing click ads." Kick some ass guys!

</comment><comment><USER9> Always glad to see these skills put to uses besides selling products and eyeballs!

Here's another fellowship using data science towards non-commercial goals (global health research): [http://www.healthdata.org/get- involved/fellowships](http://www.healthdata.org/get-involved/fellowships)

Full disclosure: I participated in the fellowship in 2008.

<comment><USER5> Hi kfor, the fellowship program sounds really interesting. Do you mind chatting with our team and telling us about your experience?

</comment></comment><comment><USER10> I have a vehicle routing solution (minimal routes via multiple destinations, with time windows, capacity constraints, weekly scheduling; it's a website service on top of Google Maps) that I would be happy to provide for free to social impact projects. Email is in my profile if you're interested.

</comment><comment><USER11> This site does not work properly on Firefox, because of cross-origin requests of fonts.

      downloadable font: download failed (font-family: "sinkin_sans600_semibold" style:normal weight:normal stretch:normal src index:1):
      bad URI or cross-site access not allowed
      source: http://d1arcc3qu8ndpn.cloudfront.net/fonts/SinkinSans-600SemiBold-webfont.woff

<comment><USER5> Thanks gulbrandr! We're fixing right now

</comment></comment><comment><USER12> For those who think this is an awesome idea, but that don't want to relocate and/or work full-time, I recommend you check out the similarly minded [http://www.datakind.org/](http://www.datakind.org/)

<comment><USER13> Thanks for the link man, this really look wonderfull.

</comment></comment><comment><USER14> Can you elaborate on what a "Fully funded fellowship" means? I'm guess it's vague because you haven't figured out how much support you'll be able to provide yet?

<comment><USER5> Hi Shoyer, one of the founders here! For our fall fellowship, support will likely be in the range of $4,000-6,000 per month based on experience. We also provide a fellowship house in San Francisco for our fellows to live in.

<comment><USER15> Hi ajiang, This is a great initiative. Glad to see Data Science knowledge put to use for noble causes. I am a mentor in a Data science/analytics program based in Bay Area where we help professionals looking for a career change to data science. We are always hunting for interesting projects for them to work on. Would love to have them work on real projects with noble goals. Love to connect to discuss this possibility. If interested, please ping me. You can find my email in my profile. Thanks.

<comment><USER5> Hi hsshah, that sounds interesting. Shoot us a note at firstname.lastname@example.com - we'd love to talk!

</comment></comment></comment></comment><comment><USER16> This sounds amazing.</comment>


An open letter to the mathematical community - <AUTHOR> https://www.mcsweeneys.net/articles/an-open-letter-to-the-mathematical-community <comment><USER2> So I got about two paragraphs in before saying "why did this weirdo write this" and turning it off</comment>


The iPod of 2004 - <AUTHOR> http://techblog.willshouse.com/2011/03/02/the-ipod-of-2004/

<comment><USER2> Ah, the 3G iPod.

It marked the time I finally stopped using a bunch of perl scripts to manage my music and started using iTunes; my first MP3 player; my first Apple product since the mid 80s, and it quickly led to my first iBook, and so, so much more.

Only the iPod touch, another killer device, could get me to eventually give it up.

I still sync that old iPod with iTunes, still use it in my car for long trips; in a number of ways the click wheel is still the superior interface for an MP3 player. What an epic little machine.

Edit: Yes, I meant 4G iPod. If I'm going to wax poetic about a device I should at least get its name right.

<comment><USER3> Actually, it's the 4G monochrome (<http://guides.macrumors.com/iPod_%284G_Monochrome%29>) iPod.

The 3G (<http://guides.macrumors.com/iPod_%283G%29>) didn't have the clickwheel. I've still got a trusty 3G 40 GB in my car tethered to my stereo and tucked away in my console.

<comment><USER4> I still think the 3G had the most futuristic interface (other than a touchscreen) of any iPod. With its non-mechanical buttons in an all-white, translucent face, and the red backlighting that only triggered when you touched it, it's still a pretty amazing bit of design.

</comment></comment></comment><comment><USER5> I _loved_ this design. Easy to hold in your hand. Rounded, cute and cuddly. And, the wheel was such a clever interface choice. By comparison, today's iPod feels like a waify supermodel to me.

<comment><USER6> I still rely on my iPod Classic as my music player of choice, though I'd probably want an iPod Touch if I didn't have an iPhone (for the apps).

I agree: this is one phenomenal design.

<comment><USER7> _I still rely on my iPod Classic as my music player of choice, though I'd probably want an iPod Touch if I didn't have an iPhone (for the apps)._

Somewhat off topic, but I find it odd that I can't get a high capacity phone to also act as my MP3/media player. It would be nice to only have to carry one device with all my stuff, but since I have more than 32GB of media, that's impossible.

</comment></comment></comment><comment><USER8> 3 years later (2007) and we get the first iPhone, which still looks relatively OK to modern eyes.

I'm thinking older iPods will age about the same as 1970's mall designs, with the extravagant plastic and overblown wall art.

<comment><USER9> I love Apple's design. It's absolutely beautiful. But when I look back, their designs tend to age with the same quality that you mentioned. I take a look at the Colourful iMacs, PowerBooks and iPods of the past and now they all have the same "dated" quality to them. I suppose it's like looking at the Jetsons or other future-predictions from the past, but this "phenomena" is very interesting

<comment><USER10> There's definitely something psychological about design that I don't understand. Cars are another example - new cars today somehow _look_ new, and putting them beside an older model makes the older model look old as well.

I wonder if it's because we're exposed to these designs, and that's why they look old? (We're familiar with them, we know they're old, therefore they feel old). It'd be interesting to see two models of something that you're not very familiar with, and see if the same phenomenon occurs.

</comment></comment></comment><comment><USER11> Makes you wonder how ridiculous handheld tech will be just 5 years from now.

<comment><USER12> Maybe it won't be handheld, even, but embedded :)

<comment><USER13> I think we're likely to have wearable computing before embedded ones. I won't complain about being wrong though!

<comment><USER14> The iPod touch _is_ wearable computing, at least as defined by futurists predicting such things 15 years ago.

</comment></comment></comment></comment><comment><USER15> I never thought about it at the time, but the 3rd gen iPod was one of the last vestiges of the Classic Mac OS interface.

It's the last device Apple shipped with Monaco as it's default system font.

If I remember correctly, the later iPods used Myriad and then Helvetica.

<comment><USER16> Actually, Chicago is the font on the original iPods: <http://en.wikipedia.org/wiki/Chicago_(typeface)>

<comment><USER15> Ah, my mistake. I did know that. Honest.

</comment></comment></comment><comment><USER17> Now I feel old, and I'm only 23.

<comment><USER18> Imagine how all the Atari 400 / Vic 20 owners are feeling about now. In most aspects of life, we are still ok aged, but oh how tech has changed.

// although it looks like the Thunderbolt connector will bring back new version of the Atari 850

</comment></comment><comment><USER19> For what it's worth, older iPods with Firewire have a particular value to motorcycle tourers. Firewire has a very wide voltage spec, so you can hardwire your iPod straight to the bike.

</comment><comment><USER20> Does anyone know of a reason why the headphone jack moved from the center to the left side ?

EDIT: On second thought, the new iPods (iPhones) have the ear piece for the phone in the middle.

<comment><USER21> There are three possible reasons I can think of.

1) Probably the most likely, is related to the electronics. Stuff got shuffled around. This was probably more true in the mini and nano designs, where space was even more precious. Bigger iPods might have simply been made to match. 2) Having the headphone jack in the middle might have made it difficult to determine orientation when the iPod was in a holster. 3) Cynical, but the location of the jack also made it easy to tell at a glance if the iPod was the 5G video version or not, as a point of visual differentiation.</comment></comment>


Browsing the ancient Web with an ancient browser - <AUTHOR> https://library.stanford.edu/blogs/digital-library-blog/2015/12/browsing-ancient-web-ancient-browser <comment><USER2> The linked [http://oldweb.today/](http://oldweb.today/) is a nice piece of hackage.</comment>


Black Box Driven Development in JavaScript - <AUTHOR> https://hacks.mozilla.org/2014/08/black-box-driven-development-in-javascript/ <comment><USER2> I know this is just demonstrating an example, but the example includes a dangerous XSS vulnerability:

             for(var i=0; i<products.length; i++) {
                  content += products[i].name + '<br />';
             }
             $('.content').html(content);

Use a template library, do not concatenate strings and then just set HTML. Most template libraries will have safeguards in place to prevent XSS vulnerabilities. Even if the product name is always trusted to be non- malicious, it's still a dangerous anti-pattern.

XSS will eat your lunch. It breaks every safeguard there is, it even defeats 2 factor auth and lets the attacker adopt the identity and privileges of whoever has been exposed to the attack. It's prudent to be extra careful and never have code that looks like this.

<comment><USER3> If you had included just one more line of code it would have shown that this isn't a XSS issue at all:

         var products = window.localStorage.getItem('products') || [], content = '';

If an attacker can set a localStorage value then they can already run JS making this entire attack vector completely superfluous. In order for your claimed attack to work someone has to have already conducted a XSS.

It is like talking about the risks of XSS within locally set cookies. It might technically be true but how do you set the cookie in order to later run the JS taken back out of it? Same issue here. How do you set the localstorage to give you back the JS to commit XSS, more XSS?

<comment><USER4> This is going to be very app specific but 'products' might be a list of products in a shopping cart and the products can be submitted to the store by third parties with arbitrary names. Then all an attacker has to do is to trick you into adding his evil product to your cart. Alternatively, products might be some kind of client side cache of products from the server and the attacker might not even have to trick you into adding something to your cart.

Of course it could be possible that the 'name' value is HTML and not TEXT and has already been pre-escaped. :)

Regardless of whether this is exploitable XSS or not this is probably a correctness issue. Stuff shouldn't start breaking when people start inputting '<' somewhere.

</comment></comment></comment><comment><USER5> Why use that horrible expression when there is already a word for that,which by the way is one of the pillars of OOP : ENCAPSULATION .

You bring the word twice in your article ,so no need for that "BBDD" expression.

<comment> krasimir-tsonev Yep, BBDD is just a buzzword and I agree with you. ENCAPSULATION is a term that fits in the concept as well, but it is a little bit _general_ for me.

</comment></comment><comment><USER6> Assigning a variable as a pointer to an anonymous function:

        var Box = function(a, b) {};

as opposed to the simpler:

        function Box(a, b) {}

makes no sense. It is more verbose for zero benefit and makes all functions anonymous so you will never see that it is the Box function being called in your debuggers and profilers. If you want to enforce functions being declared before they are called, use JSLint (which you should be doing anyway.)

<comment><USER7> A lot of people use notation #1 to do namespacing by using objects, eg

      var MyProject = {};
      MyProject.func = function() {}

If you ever want to assign a function to an object, you might as well do it with global-scope functions. Most debuggers/profilers I am aware of can handle this notation well. If they don't, there is still the possibility of doing

      var Box = function Box (a, b) {}

The function does not have to be anonymous!

<comment><USER8> +1 for the named function expression. I really don't like pure function statements because of hoisting. You often end up seeing functions being used before they're defined which can lead to confusing bugs and hurts readability. I also like that `var Box = function Box (a, b) {}` directly shows people who are new to JS that function declarations are nothing else than just assigning a function to a variable.

</comment></comment></comment><comment><USER9> Isn't this just unit testing? Each module should have public methods exposed that can be tested as a black box, i.e. their inputs and outputs...

<comment> krasimir-tsonev That's right. The thing that I call "black box driven development" helps a lot if you want to do unit testing.

</comment></comment><comment><USER10> There is similar content in [http://addyosmani.com/resources/essentialjsdesignpatterns/bo...](http://addyosmani.com/resources/essentialjsdesignpatterns/book/)

It would be great if you mentioned what works with browserify, webpack, gulp etc..

I'm not sure what percentage of front-end developers still just link a bunch on JS files in the HTML.

<comment> krasimir-tsonev Hi, I referenced [http://addyosmani.com/resources/essentialjsdesignpatterns/bo...](http://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript) The revealing pattern is the backbone of the article.

</comment></comment><comment><USER11> "Use composition over inheritance" doesn't make a strong case. Can someone explain this more in depth?

<comment><USER12> Here you can read about this principle:

[http://en.wikipedia.org/wiki/Composition_over_inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance)

The take away part in the article is this: "... so there is no way to produce collisions."

</comment></comment><comment><USER13> Ouch! All those HTML entities in the code samples make this article difficult to read.

<comment><AUTHOR> That was my bad. I've fixed them and the article should look all ok now.

<comment><USER14>
        $(document).ready(application.init());

I think you meant to say:

        $(document).ready(application.init);</comment></comment></comment>


OnePlus 7 Pro review: an absolute beast in every way - <AUTHOR> https://www.theguardian.com/technology/2019/may/31/oneplus-7-pro-review-an-absolute-beast-in-every-way <comment><USER2> I know it's been talked about before, but it is still the headphone jack that will decide my choices. I'm forced to play the dongle game with my macbook, at least I should be able to listen to music with quality headphones (wired) still with a simple solution. I'll stick with my OnePlus 6 for a while.

<comment><USER3> I hardly ever use headphones with my phone (I have a separate MP3 player), but I'm the same. You can pry my headphone jack from my cold, dead fingers.

</comment></comment><comment><USER4> My experience with One Plus Two is that the final update before the system being declared EOL caused the phone to tremendously heat up and empty the battery in a span of 2-3 hours.

None of the advice posted online helped fixed the issue, only after installing Lineage OS was able to use my phone again.

</comment><comment><USER5> I don't like acronyms in specs: QHD+</comment>


10 scariest hacks from Black Hat and Defcon - <AUTHOR> http://www.cso.com.au/slideshow/397747/10_scariest_hacks_from_black_hat_defcon_/?image=1

<comment><USER2> skip the slideshow, readable link:

<http://www.readability.com/articles/ldiywdsz></comment>