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

Lisk: Blockchain development in JavaScript

blog.lisk.io

Post reply on HN
Print view View original

51–60 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#51

Post by cgmg »

chrisco255 wrote: post #48
cgmg wrote: post #22

Earlier quoted context omitted.

I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.

Please read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-abou...

I didn't didn't mean to imply JS was more or less buggy than C++ or Java.

Regarding the article you linked to, I recommend reading the discussion in the comments section (https://medium.com/@oxymor0n/eric-9f4869bb0ecb).

The UC Davis paper, for example, concludes:

"...language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing.

"This is strong evidence that functional static languages are less error prone than functional dynamic languages … In order to strengthen this assertion we recode the model as above using treatment coding and observe that the Functional-Static-Strong-Managed language class is significantly less defect prone than the Functional-Dynamic-Strong-Managed language class with p = 0.034."

Re: Lisk: Blockchain development in JavaScript

#52

Post by [deleted] »

danmaz74 wrote: post #47
chrisco255 wrote: post #46

Earlier quoted context omitted.

Maybe it's one of the best ones because it is one of the most accessible programming languages on the planet.

* Most accessible language in the planet -> any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood * dapps manage real money in real time * end users aren't able to evaluate the quality of the dapps they entrust their money to * what could possibly go wrong?

[deleted]

Re: Lisk: Blockchain development in JavaScript

#53

Post by jsnathan »

relyio wrote: post #30
jsnathan wrote: post #26

Earlier quoted context omitted.

I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…

>I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. >I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Not sure what…

> Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts.

Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs.

But I'm more excited about things like property testing than I am about things like strong type systems. And I'm wondering specifically what is the value they bring.

No offense, but all of the answers I've gotten so far are very vague, and don't really address my question. I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites.

Let me give you an example, say we have a hypothetical language with a strict type system, and we declare a variable to be of type List[Foo]. Then later we use that variable as if it was really of type Foo. That's not gonna work, and a type-checker would catch that at compile-time. But a test suite (that covers the variable access) is going to catch that as well, because the code won't behave as it should.

At which point is a strong type system going to surface a bug that a good test suite would not have? Like, can you give an example?

> Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?).

The line is as variable as the strictness of the type system we would compare it to.

I guess one could argue that a type system will force the programmer to satisfy it, while a test suite can be written very sloppily. So maybe there is some kind of signalling value in using these types of languages.

Re: Lisk: Blockchain development in JavaScript

#54

Post by hasenj »

keypusher wrote: post #2

> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

The whole "Misunderstandings" section reads like a flat-earther denying that they're anti-science.

Re: Lisk: Blockchain development in JavaScript

#55

Post by tmp12456 »

KirinDave wrote: post #35
flunhat wrote: post #13

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.

Maybe the people saying that js is insecure were refering to the state of crypto on js. Like random number generation etc.

Re: Lisk: Blockchain development in JavaScript

#56

Post by jsnathan »

syndev wrote: post #33
jsnathan wrote: post #26

Earlier quoted context omitted.

I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…

Sure, that could totally work. Part of the benefit a type system provides is that those checks are provided for you automatically, every time.

Are we talking about automatic type inference then?

Otherwise you'll still have to work out each type before it becomes "automatic". Which is not entirely dissimilar from working out a test suite.

Re: Lisk: Blockchain development in JavaScript

#57

Post by progx »

keypusher wrote: post #2

> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

You are right, but who uses Cobol today?

Re: Lisk: Blockchain development in JavaScript

#58

Post by TheAceOfHearts »

danmaz74 wrote: post #9
keypusher wrote: post #2

> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

Not just that. One thing that worries me a lot about JS in this context is numbers: JS was designed to make it easy to use numbers and convert to/from strings without caring about the precision and exact internal representation. Which is perfectly fine for UI code and the like, but a terrible idea when you're transacting money.

I have good news for you! There's a BigInt proposal [0], and it's already in stage 3 of the process. Now they're asking for feedback and waiting for implementations.

[0] https://github.com/tc39/proposal-bigint

Re: Lisk: Blockchain development in JavaScript

#59

Post by yorwba »

qaq wrote: post #45
qaq wrote: post #40

Earlier quoted context omitted.

Paypal, Walmart are doing just fine handling huge amounts of transactions in JS. Majority of security breaches are via targeted emails with attachments and have very little to do with language services are written in.

Not sure what is making everyone upset Paypal is doing 1.7 billion transaction per quarter (100 billion + in volume). 80%+ of breaches at companies are via email as a vector.

Are Paypal and Walmart actually handling their transactions in JS or is that just the front end? In either case, when they transfer money, they hopefully use a sane database transaction mechanism. AFAIK, that would have prevented the DAO hack.

Re: Lisk: Blockchain development in JavaScript

#60

Post by lomnakkus »

jsnathan wrote: post #53
relyio wrote: post #30

Earlier quoted context omitted.

>I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. >I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Not sure what…

> Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs. But I'm more excited about things like property testing than I am about things like strong type systems. And I'…

> I am wondering how their capabilities in catching bugs differ from test suites.

Well, for one they can prove the absence of certain classes of bugs. Buffer overflows, for example. No amount of testing can do that.

Obviously most languages have "escape hatches" to do inherently 'unsafe' things like calling into C, but then at least you know exactly which bits to audit especially rigorously.

> But a test suite (that covers the variable access) is going to catch that as well, because the code won't behave as it should.

How many different List[X], where X != Foo do you need to test with to have the assurance you need? Are those tests that will actually get written? (IME it's pretty rare to see such "negative" tests, but then I mostly work in typed languages where such tests are usually unnecessary...)

There's also the really huge advantage to types that they actually document a machine-checked contract in a way that integrates seamlessly with the language. There's no such consistency in e.g. JS-land. Now, those contracts may be pretty vague (in e.g. Java or C#), but in Haskell for example they include such things as "does this function have any side effects?". That's extremely powerful, but it's hard to appreciate just how powerful until you have experience in those type systems.

EDIT: Also, don't forget that tests also have costs -- they have to be maintained just like the rest of the program, and static types can drastically cut down on the amount of tests you need to write+maintain.

Post reply on HN