Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Svelte Compiler Handbook

lihautan.com

Post reply on HN
Print view View original

91–100 of 139 posts

Re: The Svelte Compiler Handbook

#91

Post by orange8 »

nmfisher wrote: post #36
orange8 wrote: post #32

Earlier quoted context omitted.

The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new p…

> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should b…

> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities.

This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?!

good practice and discipline ≠ misplaced confidence

Re: The Svelte Compiler Handbook

#93

Post by jolux »

orange8 wrote: post #90
jolux wrote: post #71

Earlier quoted context omitted.

You're making a false dichotomy here. There's a lot of light between something being a magical silver bullet that solves all your problems and every programming language being equally bad. If that weren't the case we would probably have never progressed from unstructured programming. In general the greatest progress in software engineering practice at the level of programming languages is made when something that was…

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start p…

>I simply did not say that.

No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong.

>To me, this sounds like the belief that only one language can solve a problem which I disagree with.

I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant.

>TypeScript is not a silver bullet.

Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing.

>They are all just tools.

Sure, but some tools work better than others.

>Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.

I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.

Re: The Svelte Compiler Handbook

#94

Post by jolux »

orange8 wrote: post #91
nmfisher wrote: post #36

Earlier quoted context omitted.

> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should b…

> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in…

You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.

Re: The Svelte Compiler Handbook

#95

Post by orange8 »

IshKebab wrote: post #39
orange8 wrote: post #21

Earlier quoted context omitted.

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs I'd say it depends on your teams skill set and level of disciple. The best defence against a buggy codebase isn't a programming language or framework, its good all fashioned discipline.

Yep, just like the best defence against dying in a car crash isn't a seatbelt or airbags, it's good old fashioned being awesome at driving like me.

> the best defence against dying in a car crash isn't a seatbelt or airbags

This is the kind of madness I'm talking about. An opinionated code linter is now being compared to seatbelt and airbags.

Dont forget your bullet proof vest and gas mask too, driving is dangerous!

Re: The Svelte Compiler Handbook

#96

Post by orange8 »

jolux wrote: post #93
orange8 wrote: post #90

Earlier quoted context omitted.

> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start p…

>I simply did not say that. No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong. >To me, this sounds like the belie…

I get it. You like TypeScript, it works for you. You like and firmly believe in static types, also great. No one is asking you to stop using them, or suggesting that they are bad. They are all just tools, use the ones that work for you. Personally, I do not need TypeScript, ESlint gets me there, but then again I'm not you. Just like I'm not going to assume your code is completely perfect and bug free because you use tool X, you should not assume mine is bad and buggy because I use tool Y.

Re: The Svelte Compiler Handbook

#97

Post by orange8 »

jolux wrote: post #94
orange8 wrote: post #91

Earlier quoted context omitted.

> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in…

You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.

> You appear to assume

I like your choice of words, but no. I disagree with that assumption.

Re: The Svelte Compiler Handbook

#98

Post by jolux »

orange8 wrote: post #96
jolux wrote: post #93

Earlier quoted context omitted.

>I simply did not say that. No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong. >To me, this sounds like the belie…

I get it. You like TypeScript, it works for you. You like and firmly believe in static types, also great. No one is asking you to stop using them, or suggesting that they are bad. They are all just tools, use the ones that work for you. Personally, I do not need TypeScript, ESlint gets me there, but then again I'm not you. Just like I'm not going to assume your code is completely perfect and bug free because you use…

I’m not assuming it’s bad and buggy code. My day job is writing Elixir, albeit with full type spec coverage, and the code is fine. But that’s enabled by an extensive test suite, as well as type specs. Do we need these things, strictly speaking? No. But we don’t really need any of the tools we build and use, yet we build them because they make certain things easier and more reliable.

My code is not perfect and bug free when I write it in a strongly typed language, however it is guaranteed to be free of type errors provided the type system is sound. That level of confidence in types is just not possible in a dynamic language.

Re: The Svelte Compiler Handbook

#99

Post by jolux »

orange8 wrote: post #97
jolux wrote: post #94

Earlier quoted context omitted.

You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.

> You appear to assume I like your choice of words, but no. I disagree with that assumption.

Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.

Re: The Svelte Compiler Handbook

#100

Post by xellisx »

spankalee wrote: post #83
xellisx wrote: post #29

I'm surprised Apprun nor Solid have been mentioned yet. Are there any TypeScript reactive frameworks? I know you can use TS with the others, but finding tutorials can be a pain since it all these are JS first frameworks.

lit-html is written in TypeScript, so has great typings. There are TypeScript plugins to statically analyze the templates, like lit-analyzer and the lit-plugin VS Code extension. LitElement provides TypeScript decorators for declaring reactive properties and more.

While it is writen in typescript, it's still aimed towards JS first.
Post reply on HN