I am east coast, yeah that's interesting.

Do you develop in typescript? Because I run into them all the time.

Also auto-complete is nice, particularly with 3rd party libs.

Nah the only time I've used typescript was with Angular 2. Now it's a mix of Ruby, Python, and JavaScript.

Auto complete is a big win for sure.

Was being hyperbolic for sure, but I really do think you get better production code with typed languages.

What sort of scenarios would you want '5' and 5 not to be considered equal?

Surely this is a joke?

Sent from my Nexus 5X using Tapatalk

This is not BBV or any of the other nonsense forums so what do you think?

Not its everything but react is downloaded 4x more than angular on npm.

I like 5 + 5 to equal 10 and not 55. That's a scenario where I care about the difference.

The most common dynamic typing error scenario I encounter is when a developer makes a bad assumption about what kind of object he's working with. I guess you could prevent that by unit testing more.

Or you can just use static types, get all that testing basically for free, and guarantee that no careless dev is skipping on that testing.

Not even sure if this is a good reason to prefer static typing but it would seem to me that the return values here could be ambiguous given integers and string representations of numerals could be interpreted as equivalent.


'5'+3

Or worse yet

'5'*3




Sent from my SM-G900R4 using Tapatalk

You always program with types, no matter what language you use.

Your only choice is between admitting that and thinking about the types implicit in what you're doing and handling them correctly, or being in denial and skirting the issue with ad-hoc and incomplete type checks done using control statements (null checks being the most common example of this).

A good type system will certainly catch errors you've missed, but even if this weren't the case you'd still want to use one.

My sense from Bay Area was that React had clearly "won" (just recently).

Oh... it is awesome.

I'm happy to inform you that you are totally ready to get a job.

I'm not sure if what I'm seeing is typical, but... you're ready. Just apply. You are fine.

my reasons for leaving angular (granted this was before 2, so some of this may have improved were in order of decreasing importance:

1. unnecessary conceptual complexity. too many concepts, and poorly named ones. the latter being a symptom of a much deeper problem, as it almost always is.
2. difficulty de-coupling from the framework. ie, making it hard to create POJOs for my domain and then just use the framework as a library for the framework stuff
3. bad docs (i'd guess this has improved a lot)
4. too big (in KB)

from what i hear some of this has gotten better, but i'd be pretty confident that it's still conceptually heavy for no good reason

The assumption that historic data is any sort of proxy for "real" data is silly. Any decent analyst would clown you on the spot. If need a proof of concept and some decent data to show how it can expand if you don't want to get some really uncomfortable questions.

But I want to be clear that this isn't a "you" issue, it is an issue that is exogenous with anything that involves guessing.

Yes. Depends on what you're doing. There are UI kludges that make this better: "calculating"

If you can't improve speed, fake that its really hard!

Are you talking about k-clusters?

if (!someVar) where some var could be false, undefined, empty string, null, or zero comes in handy though.

I could think of 100 issues that are more worrisome than type checking.

If I could pick one thing to change in javascript it would be this.

i'd like to hear just a few.

my guess that if you're espousing that view, you have never programmed in a language like haskell that gives you powerful, flexible types without the boilerplate of a Java or C#, and seen just how much better it makes life. if i'm wrong about this, i'd be honestly curious to hear your thoughts.

my suspicion is that most people form their views about "types" and "static" vs "dynamic" languages in environments with tons of confounding factors. i know i did. eg, they think they like "dynamic" languages because ruby is cooler and more fun to write than java. and they don't like "types" because java is so verbose, and so on.

it does. when you play fast and loose, you get to have some fun and sometimes write terse, clever code that's still readable and really isn't problematic.

I was travelling the Yangtzee in search of a Mongolian horsehair vest. I had got to the market after sundown, all of the clothing traders had gone, but a different sort of trader still lurked about. "Just a taste," he said. That was all it took.

It's also kind of nice sometimes to pass something around that can be a string, array or object.

I agree that I can't think of one legit case for ==, much less !=. When I see that in code it's like nails on a blackboard.

Same goes for var breaking out of block scope. What were they thinking on that one?

i think once they (or brendan) decided that functions would be the namespacing mechanism, it followed. it probably made language implementation easier, too (that may have been the real driver). if you set aside the confusion it causes to people used to block scope languages, there's actually a real simplicity to it. "what are the namespacing rules?" "any new function creates a new scope. that's it."

Sure from that POV. But from the POV of "Why would solid code ever create a variable inside a block and expect it to be available later outside the block?" - different story. I can't think of one legitimate use case. Every time I've ever seen it used was some developer who was pretty much just mashing buttons.

And then of course there's the old warning for not declaring your loop var, or also warning for re-declaring your loop var. Yeah I know - two loops on a page is code smell. But this was back when spaghetti code was cool.

For sure, I should give Haskell an honest shot. I was considering using it for my current project, but decided to use Clojure instead. I need to build a lot of XML and the lisp syntax maps nicely to that.

My largest exposure to strong types is PL/pgSQL. I know no one likes programming in that, but I personally enjoy it a lot. In some ways, I like the baked in types and find them convenient, especially since it maps so well to data and data manipulation, and those strong types do wonders for cleaning up that abomination called JSON. I don't think I'd ever want to use JSON seriously without type coercion. Of course, the cost of errors in raw data is much higher, and strong types makes a lot of sense. I'm still on the fence about general web programming, etc. I'll end this paragraph with another "you crazy," but I think C has a nice balance of types.

I suppose, what I mean is... I'm stopping myself from ranting, but strong-typing isn't some panacea for ****ty programming, and I get the sense that people honestly think this. The majority of the mistakes I'm dealing with right now are, ironically, from the utter misuse of some library that does data-typing and validation.

Worse things are namespace collisions, bad code organization, not checking if the results make any sense at all (esp. dates), over-use of meta programming, using outdated / deprecated libs, etc etc. I can figure out a bad data type in little time compared to all of the above.

I figure my perspective is probably from the languages I use, and in particular, the kinds of error messages I'm used to seeing. They tend to catch type errors when those explode. The worst errors are the ambiguous "reader error" which literally means anything, from a bad function format to well... a malformed string. Type-checking doesn't help that at all.