Fear, trust and JavaScript: When types and functional programming fail • Hacker News Board

Re: Fear, trust and JavaScript: When types and functional programming fail

#201

Post by dang » Mon, Oct 29, 2018, 4:47 AM UTC

ItsMe000001 wrote: post #194

eropple wrote: post #110

Earlier quoted context omitted.

I don't feel defensive, but I do find your comments interesting and your experience almost diametrically opposed to mine--which is what I said. JavaScript is quite complex and quite dynamic, but the reason TypeScript got me back into doing web stuff was, by and large, because it removes that except for in clearly delineated places (at least, once you turn on strict mode). You're reading in some stuff that isn't inten…

> You're reading in some stuff that isn't intended. What a coincidence, same thing I said to you! Why do you make a stupid reply when you know it's stupid?

We've banned this account for violating the site guidelines and ignoring our request to stop.

https://news.ycombinator.com/newsguidelines.html

Re: Fear, trust and JavaScript: When types and functional programming fail

#202

Post by remify » Mon, Oct 29, 2018, 9:58 AM UTC

ritchiey wrote: post #70

cetra3 wrote: post #12

I love TypeScript and use it in any new project I create. The author is right though, you need to have team discipline to avoid using the `any` type when it can be avoided, and immutability is not in scope. TypeScript is probably the closest we'll get to my personal ideal of static typing in JS, while understanding that you sometimes need an escape hatch to deal with dynamic typing as JS is a dynamic language. I thin…

You don’t need to wait for web-assembly to solve these problems. TA mentions 3 languages (Elm, Reason & Purescript) that combine sound type-checking and immutability right now. None of these bring the cognitive overhead of Rust’s borrow checker and, in the case of Reason at least, compile at lightning speed to readable (though optimised) JS.

Don't forget F# with Fable :)

Re: Fear, trust and JavaScript: When types and functional programming fail

#203

Post by kbd » Mon, Oct 29, 2018, 4:13 PM UTC

crimsonalucard wrote: post #172

incadenza wrote: post #138

Earlier quoted context omitted.

This all sounds great but I cringe a bit at yet another layer of abstraction in an already insane JS tooling ecosystem. It seems like half of the time you’re just using the escape hatch to plain JS to stitch all of this stuff together, no?

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

This is the opposite of my experience with Elm. Tried it for a while. Getting the time or a random number takes a tutorial to learn how to do because those things aren't purely functional.

Then I wanted a fast lookup table, turns out all dictionary lookups in Elm are nlogn because it's backed by an immutable tree structure.

So, I disagree with you and went back to JavaScript.

Re: Fear, trust and JavaScript: When types and functional programming fail

#204

Post by jeremychone » Mon, Oct 29, 2018, 4:58 PM UTC

First, no language is perfect, and building a real system with growing team(s) is always about making purity vs pragmatism tradeoffs with the main goal of keeping the complexity down as the system scale. The truth is that a system is much more than just the languages it is composed of, and regardless of the purity, exactitude, elegance of a language, sloppy work will always lead to a messy result.

In other words, languages should not be used as a substitute for discipline, good patterns, or scalable best practices, but rather as an enabler of such conducts.

TypeScript favored pragmatism over purity, but it is a very well thought-out, robust, and expressive typing layer on top of JavaScript.

Sure, for the sake of language purity, developers can "bytecode your way" to JavaScript Dart, Java with GWT, ReasonML, Elm, but there is a reason why all of those options, how elegant they might be, have limited traction and relatively short lifespan (at least compared to JS), and that is because they add too much friction points (often unexpected ones) for the sake of language purity, which at the end is a never-ending quest anyway.

TypeScript is a structural typing system which has its differences with commonly known nominal typing systems (which often confused with soundness), and while there are some unsoundness is some specific cases, overall, TypeScript is a very robust and expressive typing system on top of the most pervasive language, JavaScript. Not perfect, but very robust nevertheless and a huge step up from traditional JS. TypeScript combined Modern JS (module, let/const, async/await/promise, arrow function with related scoping, deconstruction, ...) does create a very robust environment to scale code and developers.

We used to all our backend in Java for 20 years (personally comes from Oracle) and we now see nodejs / typescript ecosystem and runtime environment has competitive for big app system. For one of our client, we actually just ported the last of our multi-service system from java to TypeScript, and it got 40% less code and it is better typed than Java. Java's high typing friction and Class-For-Everything purist approach makes good code design more of a contortionism exercise than an intellectual one, and while nowadays most agree that this OO-Obsessed approach was the wrong one, it was considered very pure and "robust" at a time.

Anyway, the short version is what makes a big code base scale is not the purity of any given part (e.g., language) but how the whole can minimize present and future friction points. The less friction, the more velocity. Discipline, best practices, tools, environments, and ecosystem are all part of a whole and one needs to make sure to not over optimize one part on the detriment of the others.

Re: Fear, trust and JavaScript: When types and functional programming fail

#205

Post by crimsonalucard » Mon, Oct 29, 2018, 8:10 PM UTC

kbd wrote: post #203

crimsonalucard wrote: post #172

Earlier quoted context omitted.

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

This is the opposite of my experience with Elm. Tried it for a while. Getting the time or a random number takes a tutorial to learn how to do because those things aren't purely functional. Then I wanted a fast lookup table, turns out all dictionary lookups in Elm are nlogn because it's backed by an immutable tree structure. So, I disagree with you and went back to JavaScript.

Although I disagree with you, I never stated one was better then the other. All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. There is a practical logic around why it was done that way, but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm and compare it to the same type of app written in javascript.

Re: Fear, trust and JavaScript: When types and functional programming fail

#206

Post by kbd » Mon, Oct 29, 2018, 9:21 PM UTC

crimsonalucard wrote: post #205

kbd wrote: post #203

Earlier quoted context omitted.

This is the opposite of my experience with Elm. Tried it for a while. Getting the time or a random number takes a tutorial to learn how to do because those things aren't purely functional. Then I wanted a fast lookup table, turns out all dictionary lookups in Elm are nlogn because it's backed by an immutable tree structure. So, I disagree with you and went back to JavaScript.

Although I disagree with you, I never stated one was better then the other. All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. There is a practical logic around why it was done that way, but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm and compare it to the same type of app written in javascript.

> All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point.

Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

> but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm

It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

Re: Fear, trust and JavaScript: When types and functional programming fail

#207

Post by crimsonalucard » Mon, Oct 29, 2018, 9:34 PM UTC

kbd wrote: post #206

crimsonalucard wrote: post #205

Earlier quoted context omitted.

Although I disagree with you, I never stated one was better then the other. All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. There is a practical logic around why it was done that way, but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm and compare it to the same type of app written in javascript.

> All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.? > but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm It soun…

>Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

Your reply doesn't even address my point. That's all I'm saying. All I said is that I disagree with you.

>It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

>Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

>Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

Don't ever call what I say absurd or BS that's plain offensive and against the principles here on HN. If you want me to continue replying to you, I'll need an apology otherwise I will ignore you.

Re: Fear, trust and JavaScript: When types and functional programming fail

#208

Post by spiralx » Tue, Oct 30, 2018, 6:06 PM UTC

Quekid5 wrote: post #30

austincheney wrote: post #19

Earlier quoted context omitted.

This completely ignores my comment in its entirety. Do people make mistakes: yes. Does software ever have defects: yes. Typically, people making mistakes in software is called a software defect. It is absolutely critical in a discussion like this to understand that defects in software are not necessarily defects in data. This conversation is about data, and checks for processing data are already present in various fo…

> For example when was the last time you complained about weak type systems when working with JSON, XML, or SQL tables? Well, I don't know about the person you're replying to, but I certainly complain about these all the time. Interestingly and counter to your point, I think, XML grew a "type system" of sorts with XML Schema (which is widely used IME, esp. where interfacing with external services as in SOA), and SQL…

> ... XML grew a "type system" of sorts with XML Schema (which is widely used IME, esp. where interfacing with external services as in SOA) ...

The type system came from both XML Schema and XPath and was codified with XSLT 2, then expanded when XQuery was defined. It's not been a type system "of sorts" since XSLT 2, which filled in a lot of gaps and undefined behaviours.

Re: Fear, trust and JavaScript: When types and functional programming fail

#209

Post by SZJX » Sat, Nov 03, 2018, 4:52 PM UTC

erikpukinskis wrote: post #117

Companies and coders will always push themselves to the absolute brink, where they no longer trust the code and the system is nearly unmaintainable. Because every step towards that line has not just cash value, but exponential cash value if it’s a startup. And by constantly pushing themselves into unfamiliar territory coders develop the most impressive possible resumes. They either have relevant experience or have ex…

I don't think exact technologies per se are that important for "resume padding". Many companies do use relatively "old" technologies and don't care as long as the job gets done. Slack even uses PHP. Not to mention the big companies which might pay more attention to algorithm problems instead of the particular language you solve those problems in. Do the recruiters really think you are the one if your resume has all the newest hottest things written all over it?

Personally I learn new technologies if they are fun to learn and make my life as a dev easier. I'm not sure if anybody jumps on wagons just for the sake of it. For example I tried out Rust, Julia and Elixir, hated the first but liked the later two. I also tried Vue a bit but with Phoenix framework a lot of things can just be done with server-side rendering so I just dropped Vue in the project and felt totally fine with it.

Re: Fear, trust and JavaScript: When types and functional programming fail

#210

Post by SZJX » Sat, Nov 03, 2018, 4:53 PM UTC

jorblumesea wrote: post #167

erikpukinskis wrote: post #139

Earlier quoted context omitted.

Sure. I worked on the system which is now the customer admin for Square’s ecommerce platform they bought in Weebly. We were all learning Vuex, while also trying to ship code. Across a half dozen pages we had a half dozen slightly different ways of addressing Vuex data. It wasn’t so much complexity that a professional coder couldn’t keep it straight in their head. But it was a trivial amount of complexity to fix. Two…

That sounds like no one actually designed or architect-ed the system, and everyone just went off and built things without an overarching plan. This is sadly somewhat common in software projects. This could be due to a variety of factors but to chalk every software project up to "resume padding" seems like a simplistic take. Using your example but applied to other companies, I've seen the below, or some combination of…

I don't even think "jumping on the next new thing" is a particularly valid "career strategy". Many companies do use relatively "old" technologies and don't care as long as the job gets done. Slack even uses PHP. Not to mention the big companies which might pay more attention to algorithm problems instead of the particular language you solve those problems in. Do the recruiters really think you are the one if your resume has all the newest hottest things written all over it?

Personally I learn new technologies if they are fun to learn and make my life as a dev easier. That's it. I'm not sure if anybody jumps on wagons just for the sake of it. For example I tried out Rust, Julia and Elixir, hated the first but liked the later two. I also tried Vue a bit but with Phoenix framework a lot of things can just be done with server-side rendering so I just dropped Vue in the project and felt totally fine with it.