h335ian
Joined 3 years ago
Joined 3 years ago
The article is purely a marketing piece. As we know with all tech, it’s how you hold it. Yes, you can certainly graph all the entities, activities & relationships - but there is the human tendency towards laziness, least path of resistance and the desire to show “look what I can do” that inevitably leads towards using using weak/garbage data without verification - often in the form of purchases/collected metadata.
Concrete example with a less scary outcome; I was involved in a project for real-estate marketing that used “quality” metadata to infer potential buyers/sellers/properties to target for a given marketing campaign and/or what marketing techniques/campaigns might influence a targeted entity. It was cool. For sure. But, due to the lack of integrity in the data, even with well known & trusted data (direct from the MLS) the result was a graph that made many very weak/inaccurate connections and resulted in a great deal of wasted marketing efforts/cost, targeting the wrong message to the wrong entity at the wrong time. Because it was still a major improvement over other tools in the space, it became the preferred path even with inaccuracies galore.
Now, imagine if the cost of inaccuracies is human freedom - vs wasted cents. Scary stuff.
I guess I’m tainted/jaded by the early proponents and initial rationale that was absolutely tied to - “ewwww dynamic types!?! Gross, where are my strong/static types!?”. I’ve just fought that too many times - and that was a very strong argument at the inception of TS. There certainly are value props that go beyond and more to be discovered I’m sure.
I feel like MANY if not most of the devs I work with today simply use TS cause “that’s what you do these days” - but they have no clue what the “why” is and are baffled by native JS typing - and still consider JS “garbage” as a result. Bummer. In the Scala community I hear so much hate for NodeJS because it enables JS for server-side, “where it doesn’t belong” for many of these same old reasonings about typing (even with TS!?).
So yah, there’s value there, but you don’t NEED it to write large, good software. I’m clearly just jaded by the religious debates that have gone on and on - so despite their utility, I can come across very anti to the “solutions” to IMHO shitty arguments.
I’d strongly encourage doing a deeper dive here. Functions in JS are objects and can have their own methods/props + scope. They’re a first class citizen.
JS was certainly never a “garbage” language but the elegance is unappealing/unappreciated by entire classes of developers. I totally get the perspective, but it’s all based on a worldview that just doesn’t get functional programming
Yes, ES6 brings the OOPiness
I’ll double down on the urge to drop TypeScript. That pile of nonsense came from the classic OOP folks - “But where are my TYPEs!? How do I know what type that variable is!?” (first the Java/C++ folks then the .NET folks “solved” the brain fuzz around functional programming and dynamic types by giving you TypeScript)
Having been out of the m$ ecosystem for some time, I’m kinda surprised HTAs are still around, I’m guessing to avoid breaking things. Once .NET started taking off - I always assumed that would replace the VBScript side of things and let you build proper, elegant system interfaces for your JavaScript app. I really imagined the goal was to drop Windows forms/object controls - but I always imagined BATTLES at m$ over being able to create Windows “apps” that didn’t conform to native UI controls, couldn’t be controlled through Windows theming engines, etc. kinduva brand control battle. I always imagined some team going “NOOO, just build a web app, you’re breaking all the UI rules!!!”
Nifty project, but IMHO the world is better off using native JavaScript without all the BS that comes with TypeScript, etc. JavaScript is so powerful and amazing, it’s a bummer to hamstring your app by using TypeScript and classic OO inheritance models that preclude the beauty and dynamics of JavaScript as a functional, prototypal language.