colin_jack

Yeah I agree, but to my mind its good advice delivered in a very condescending style.

The quote he was commenting on had a very condescending tone too:

" Do not complain about something you think is missing, wrong, or stupid. You are ignorant and new to the language, no matter how much of an expert you are on programming in general."

That is actually mentioned in the article.

Woah, did not expect a picture of an animal being bled out.

Pity the title refers to an interesting discussion point that isn't discussed till quite late in the article, and then only fleetingly.

As someone who doesn't often use taxis but often finds them the most pushy/unsafe drivers on the road I'll be interested to see if these other services improve that side of things.

Its particularly important for me when I'm a pedestrian because taxis/cyclists/delivery vans running red lights or taking corners too quickly are a relatively regular hazard that I'd be glad to be rid of.

I wanted to love that course but found that despite his entertaining style the lecturer could be quite hard to understand in places. What I mean is he'd be giving a description of a problem and I actually wouldn't understand what he was saying. No biggie if you were in a real lecture as you'd just put your hand up but on Coursera you're left with looking at the transcript (which didn't help) or asking in forums (which in case of this course were a ghost town).

Pity as it seemed like an excellent course.

> As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions from the bottom up

Yeah I think this is a reasonable approach, especially as if you do end up completing this, and get to a design you are happy with, it will probably be very different (and hopefully infinitely superior) to your original high level design.

You've probably already heard of it but the mikado method can also be useful in some of these situations.

Its a good book but from my memory it doesn't really address solutions to whats being discussed in the post, and I'm presuming the author is familiar with the book because he discusses characterization tests.

Totally agree about the dissonance with TDD and it always surprised me it wasn't discussed more when TDD was going through the hard sell stage.

I guess my core problem is TDD only drives your design if you write quite granular tests but they then become barriers to further refactoring/redesign. However my current preferred approach (for anything non-trivial) is different to the authors. As he does I start out with outer-level acceptance-y tests, however those integration tests are then combined with extensive refactoring to drive the design, so I don't do the dreaming up of collaborators he does in step 4.

My reason for not thinking of collaborators early is although I think that approach has legs I found it didn't necessarily always the simplest/most elegant design you could come up with. I ended up encoding my first understanding of how to solve the problem into the interactions, even though I knew that my understanding of the problem at that point was much less than it would be once I dug a bit deeper.

Anyway with my current approach if I extract additional classes/whatever I might then test them directly, or use further tests to drive their design further (incl test doubles as appropriate). So I'll have one or a few tests of the extracted behavior at the outer level, and maybe more thorough testing at the lower level because quite often testing all the combinations and edge cases is easier at this level.

Yup agreed but the prototype approach is scarier as it affects every user of the prototype, where as with namespaces you opt-in to bringing in extension methods at the file level by importing the associated namespace.

Not sure on the whole this as argument, I prefer it to the current approach of this being decided at framework/library level because I get bored of having to bind each function to get lexical scoping back. That Nim code is indeed beautiful though, maybe need to give ti a look ta.

You're obviously right but could this sort of case not be handled by future versions of JS allow clients to opt in to the prototype being modified, something equivalent to extension methods in .NET where if a client wants to use them they import the associated namespace?

You have a point but you mention C#, it's worth thinking of how you'd handle one of the examples in C#:

items .filter(isOk) .map(toOtherType) ::flatten()

In C# that sort of case is primarily handled by extension methods. They have their issues not least in terms of collisions, but to me they are a beautiful solution. The equivalent in JS would seem to be the always unpopular choice of adding these methods to the prototype, and as with extension methods you'd want the user to opt-in to their addition (possibly at object level here?).

Not sure though, maybe I've missed something.

>Essentially any event where the user would expect feedback means you need write the conditional structure in the output. So if the user types a character in an input box then you need to write the value of the input box to be the characters the user has typed so far

Anyone able to provide a quick description of what this means?

They'll sort that our for you.

At least in Guardian comments they make no sense, are intensely rude, and tend not to reply to comments. As you say it makes them very easy to spot.

Some disabled people rely on access to these spaces, meaning if the spaces are full they can't do their shopping and have to go home.

I think the quote does miss the point, its almost a call for more wall street banker style behavior. As mentioned abovce though thats not really in keeping with his books, and the quote is misleading as it omits the last part.

That quote didn't seem like him at all, in fact it seemed to be showing a mindset completely at odds with his books, quick google indicates you maybe missed a key part:

"And at the other end of the bar the world is full of the other type of person, who has a broken glass, or a glass that has been carelessly knocked over (usually by one of the people calling for a larger glass) or who had no glass at all, because he was at the back of the crowd and had failed to catch the barman's eye"

I somewhat agree and consider moving to TypeScript a bit risky as it seems like it'll end up a niche but I do think sensibly added typing code improve JavaScript. I want better tooling support, refactoring support, intellisense...and languages like Dart/TS seem to me to have shown its possible to do this without throwing out the dynamic aspects.

Couldn't agree more, its also one of the best written tech books I've ever read.

Ta yeah, I probably should but its usually just I don't find the approach the UI takes intuitive in a lot of cases. Even just things like doing a search, viewing results, compared to Chrome I find it all a little painful...not sure that's the sort of thing I can meaningfully report though.

Its been my recent experience too, I keep a lot of tabs open and began to notice Chrome was filling up my memory.

Very strange that Google let the situation get so bad. Mind you I find the Chrome developer tools far more powerful and intuitive than those in Firefox which stops me moving entirely.

Yeah I plan to ta, to be honest I like what I've seen/used of TypeScript too. However I'm thinking the big win will be in the longer term when JS picks up some of the ideas.

On the multiple ways, I was sure I read a post that documented them all and had me nodding along but can't find it, this one seems good though [1].

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

Possibly, but you can argue the opposite. I've seen a bit of commercial TypeScript and it's been horrific and to me just matched the anything but Web/JS approach I was expecting.

I'd also worry that the TS community itself would risk marginalization, end up as a small niche ghetto, with most of the interesting stuff going on in ES7+.

Hard to be sure but I wouldn't write off JS just yet, people have been doing it for years as new/better (flash/silverlight/compile to JS) technologies have promised to make it seem soooo 90s.

I actually don't think its so much about code safety either. To me the real top advantage of static typing is that it leaves the code self-documenting, easier to navigate around, easier to refactor as you say...etc.

Having said that the flexibility JS gives you is huge, I've played with Scala and its at the opposite end of the scale. I don't mind that but I am more interested in things like gradual typing being added JS, even if that just ended up being checked at run-time, because it gives you some of the big advantages of static typing without sacrificing all the of the dynamic goodness.

"it doesn't make JS a pleasure to work with yet (which seems to be the argument?)"

My interpretation of what Retozi is saying is that CS just means that in addition to understanding JS, including ES6, you need to be familiar with all the different ways things can be done in CS.

I tend to agree, especially as JS is becoming an improving with each release.

What I'd like to see going forward is JS continuing to add selective sugar as is in CS, but also add functionality that makes going into a new fresh JS codebase and making sense of it easier. That side of things is less about CS, and more about the sorts of ideas you see in Dart and TypeScript.

Sorry yeah wasn't meaning to infer you couldn't write beautiful Web embracing code in TS. However most of the code I've seen using TS, and admittedly its a small sample, was of the other sort so I wasn't sure if that's the way the TS community is pulling.

Yeah the stuff I've seen looks to me like poorly written C# consciously written in a Web-ignorant style, thoroughly at odds with whats going on in the Web/JS community generally.

Anyway totally agree on the typing angle, navigation/refactoring/discover-ability aspects are useful and I loved the implicit interface approach in Dart. However I wonder whether some of those features won't be added to JS over time (where possible in such a dynamic language). Ta for link to flow, will give it a look thanks.