Mostly dynamic typing yes. I've been working in java for the last few years and js for maybe a year, and we've had quite a few run time errors due to dynamic typing, which would have been caught instantly in with static types. I'm starting to think that we need to create unit tests for every variable to check for type errors, but that seems like a lot of boilerplate work that you don't have to do if you simply use static types.

And our junior js devs completely miss the point of certain patterns that we try to implement, and just pepper their code every which way. In java you have stuff like interfaces that clearly define what methods you need to implement and encourage you to modularize in a proper way. It feels more "guided", although I do acknowledge that OO is maybe not the best paradigm and is definitely misused.

no, yes and yes.

Cool - yea I love static types. In the scientific world, everything is MATLAB and python. Pretty optimal for playing around with algorithms and doing research, but occasionally we delve into the sphere of building large scale tools, and it kinda sucks with both languages.

Yup. Making new modules in js is a joy. Especially when you embrace the functional aspect and have learned to avoid all common pitfalls of the language.

But maintaining large systems, or creating frameworks that dozens of devs are then supposed to implement and extend... not so much with the joying.

Maybe I'm an idiot, but I don't understand why people are so passionate about static types.

Is it actually really common for people to try and use the wrong type? Why are they doing this, surely if people feel this way there must be some common pitfalls, what are they?

Junior devs using the wrong type and not realizing it and the code erroring after compilation doesn't seem compelling to me. Maybe in rare cases the code will appear to work but fail for many/most or edge cases, but testing should pick that up?

Fortunately my boy mpj at funfunfunction shares the opinion or i would feel like the only person who doesn't get the obsession with type checking.

In my experience - the joy of static types is auto-complete and IDE code navigation.

I can't remember ever having a major run-time bug in node or the browser that would have been caught by static types at compile time. But it could be just because I don't ever think about static typing with JS.

I do remember however having to go through contortions to get around a static type in a method signatured I didn't control (angular http.get()).

This is it. Maybe you guys can tell me how to get around this:

This is for angular universal, to pass the cookie headers from the original (page load) request on to the server-side child ajax requests (where in our case node calls itself to make ajax calls).

I would like to just do this:

But webpack complains that the headers object is not the right type. So I have to overwrite the original request headers object (which is the right type) then feed that to the http.get method. Which makes very little sense because I'm overwriting req.headers with a plain object that I just created.

Below is a good link that examines both sides:

https://pchiusano.github.io/2016-09-...s-dynamic.html

Anymore I am not surprised at all by people taking sides on any subject....

Sent from my SM-G900R4 using Tapatalk

Any way to hang oneself will be done to its fullest extent, and static typing prevents at least one way... sort of.

The problem really happens when someone decides to bake their own typing system on a dynamic language. Turns out that typing is a very complex CS subject, and not something that can be done as an add-on when building out an app.

I suppose an over-simplistic answer is, have you ever:

That's just one less thing you have to work into your code (and once again, something you are possibly doing wrong, so more errors).

It's fairly common. Mistyped property names and subtly changes in types not being communicated properly. One big problem is that a lot of JS developers use objects with slightly different types interchangeably without rigorously defining what's expected.

For instance, we recently had a case where a shared component outside of our code base subtly changed the type signature for a rarely used callback. Another common situation is one person writing code to handle multiple possible types (say an object and a number) but another person later modifying the code, not fully realizing this and failing to handle all possible cases.

If the library you're using subtly changes the types and you don't realize this and change your mocks, your code will still pass unit tests since your mocks are still based on the old interface. And the vast majority of code bases don't have anywhere near the level of test coverage to ensure that these types of errors are caught in tests anyway. Whereas a compiler catches these types of errors with 100% reliability.

Yeah - I mean consider redux - a huge amount of it is just a type system built on top of JS in a fragile way. Or for that matter react and propTypes - it's a really poor man's type system that is both more cumbersome and less reliable.

One thing that is important to realize is that any time you change code to use a property that wasn't being used before, you're changing the implicit type signature of the function. Maybe the property was there all along and maybe it wasn't - but you're creating potential downstream impact. This is really maddening when you're in a huge code base or have lots of dependencies or have lots of other code depend on your code.

This seems pretty fair. Though I think it misses by far the biggest advantage of dynamic typing - the design and implementation of the language are far simpler, which allows the language to evolve rapidly to meet developer needs. The initial versions of Ruby, Python, JS, PHP, Perl were basically created in a few days, give or take. This also means many more dynamically typed languages can be created and have been created, which means the popular ones are the ones that survived this fierce evolutionary competition. On the other hand, it takes years and far more expertise to design and implement a reasonable modern statically typed language, whether Java, C#, Go, Swift, Scala, F# or Haskell. This implies more robustness and thinking behind the design but also less adaptation to the current developer use case.

https://www.jwz.org/doc/worse-is-better.html

This is sort of what I'm getting at - though ironically, this was first written with C (a statically typed language) being the "worse is better" or NJ approach archetype and Common Lisp (a dynamically typed language) being the "better is worse" MIT approach archetype. But in today's world where all modern languages more or less descend from some combination of Lisp and ML, modern dynamically typed languages are closer to the NJ approach and modern statically typed languages are closer to the MIT approach.

Good article.
In the end, it feels like to me that the java half of my company ends up with higher quality production code. Maybe it takes longer to get to production, it's hard to say cause the domains are different. And I have no comparison metrics on either the quality or the speed of our java/node dev, just my subjective feeling having worked in both domains now.

For the record, I am not a fan of java or OO. The more I learn about fp the more I like it.

I am not an expert by any means but my reading has led me to believe that OO and FP are not mutually exclusive. You can still use OO techniques and minimize state full changes in your system.

Sent from my SM-G900R4 using Tapatalk

My interpretation of fp is probably not very accurate, but what I'm referring to when I contrast OO and FP is:

OO:
Data and methods are tied together. Functions are methods on state that mutates (car.drive()).

FP:
Data is just data. You work with data using functions, preferably with no side effects and in a non-mutative way (car = drive(car)).

I'm also conflating composition over inheritance with FP, that might be wrong.

I had a moment this week where functions and functional programming just totally clicked for me and now it seems incredibly simple and also really awesome.

I was intimidated before and it was sometimes hard to manage how closures, callbacks, higher order functions, etc. were working, but I feel like they are all really not complicated at all once you practice it a lot.

It would be great if redux gave better error messages.

Also, it's interesting that it seems to never fatally error.

That difference between OO and FP is correct, but perhaps doesn't get at the heart of the matter.

What you get in FP that you don't get in OO -- the cash value that really matters -- is immutability and composability. So fully contained side-effects aren't an optional benefit, but are one of key reasons for adopting the style.

I'd also argue that if you don't have data in the last argument, curried by default functions, you haven't experienced the true magic of FP. With the caveat that the benefits aren't all or nothing -- even using map over a for loop is a start on the right path. But you're not going to really feel what's so great about it until you're writing the majority of your logic in the point free style, building up larger functions from smaller ones without naming your data.

Composition over inheritance, within the OO framework, is a nod to the benefits of this style -- but doesn't, by itself, take the principle to its logical conclusion.

EDIT: Also worth pointing out that the calling style:

OO: car.drive(distance)
FP: drive(distance, car)

should be considered a trivial syntactical difference, and if you strongly "like" one over the other you should view that as the result of habit, just like learning a SOV language is "hard" for a native speaker of a SVO language. Except that in the case OO v FP, the habit can be changed much, much more easily than in the case of natural language.

That point clicked home for me when someone pointed out the similarity between fp and the linux shell experience where you pipe together simple yet power tools that do one thing and do it well to produce really complex results.

Working in windows is on the opposite end of the spectrum, where every tool tries to be everything plus the kitchen sink. Case in point: agent ransack vs grep/find/sort. Or any IDE. I love intellij for java because it has really powerful features that are hard to get elsewhere (refactoring, debugging, interactive unit testing) but man, when I saw that they had a widget sql database editor I just went:

Thank you Wolfram and gaming_mouse for your insights on the distinction between the paradigms. Definitely more studying for me to do.

Sent from my SM-G900R4 using Tapatalk

I've been using intellij for the last 6 months or so and can't stand it, coming from a Visual Studio background. Thinking of trying out Visual Studio Code with the Java plugins.

That's OK I can't stand Visual Studio. And I've been using it off and on since about 1999.

has anyone worked w/ recommender systems for say, 10m+ users with a catalog of 10k's of items? or maybe know of good resources...i can't seem to find anything indepth

Probably ignore me since I'm just a grump on this stuff but imo almost no one seems to do anything aside from global popularity any more.

Even the much-vaunted personalized so-intrusive deep learning algorithms of facebook, amazon and google just seem to advertise stuff to me that I literally just bought

Oh I see you just bought a blender. Let me show you other blenders you could buy!

amazon's "other people who bough that also bought this..." works well for me, especially with books. but in general you're right that systems make laughable errors given their sophistication.

I think most of that (I mean what Rusty is describing) is ad retargeting which has been around for a lot longer than machine learning has been trendy.