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

91–100 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#91

Post by woranl »

AgentME wrote: post #15
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…

The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private…

Your browser can auto-update, your OS can have backdoor, drone and satellite can fly over our heads and observe our every moves. The safest way is to hide in a cave and put on tin foil hat. If one does not trust the service provider, then don't use their service. Similarly, if one cannot trust their ISP, then stay offline. Trust is critical in many things in life. If we cannot trust anyone anymore, then we have to build everything ourselves. Shit, is the cup of water in front of me safe to drink?

Re: Lisk: Blockchain development in JavaScript

#92

Post by chrisco255 »

seanwilson wrote: post #67
chrisco255 wrote: post #48

Earlier quoted context omitted.

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 find that convincing at all and most studies like this are full of issues because coder productivity is notoriously hard to measure. The graph of bugs per language is just a simple count of how many GitHub issues were labelled "bug" which isn't meaningful. I don't even know why you need a study for this anyway. Working in a language where it's impossible to mix up strings and numbers, impossible to call a fu…

Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program.

Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function.

I think JS code tends to be simpler than equivalent Java code and in my opinion, the simplicity of JS offsets its lack of explicit types.

"Simplicity is prerequisite for reliability." -Dijkstra

Re: Lisk: Blockchain development in JavaScript

#93

Post by Matachines »

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...

Eric Elliott is a joke even in the JS community.

Re: Lisk: Blockchain development in JavaScript

#94

Post by chrisco255 »

Matachines wrote: post #93
chrisco255 wrote: post #48

Earlier quoted context omitted.

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...

Eric Elliott is a joke even in the JS community.

Dude, don't know what the ad hominem is all about, but if you have rational arguments to dispute the studies by UC Davis or the methodology behind Lebrero's bug count analysis, I'd love to hear them.

Re: Lisk: Blockchain development in JavaScript

#95

Post by qaq »

purerandomness wrote: post #86
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.

None of those companies handles actual monetary transactions in JavaScript. That would be insane.

Define handling transactions, they have Node services which are touching cardholder data and are subject to PCI DSS compliance. The web layer is Node.

Re: Lisk: Blockchain development in JavaScript

#96

Post by seanwilson »

danek wrote: post #81
13years wrote: post #80

Earlier quoted context omitted.

Studies are important simply because reality is often counter intuitive to theory.

This is true but a study is useless if it can't measure the thing you want. Things in programming are notoriously difficult to quantify, compared to say, stuff in physics. Perhaps it's why there are so many holy wars.

> This is true but a study is useless if it can't measure the thing you want.

This is my point really. A misleading study is worse than no study as people use it to back up their points with a false air of legitimacy.

Re: Lisk: Blockchain development in JavaScript

#98

Post by seanwilson »

chrisco255 wrote: post #92
seanwilson wrote: post #67

Earlier quoted context omitted.

I didn't find that convincing at all and most studies like this are full of issues because coder productivity is notoriously hard to measure. The graph of bugs per language is just a simple count of how many GitHub issues were labelled "bug" which isn't meaningful. I don't even know why you need a study for this anyway. Working in a language where it's impossible to mix up strings and numbers, impossible to call a fu…

Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type err…

> Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program.

> Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function.

I wouldn't agree with that. Issues with string/number conversions, strings being treated like arrays and unexpected undefined/null (these are particularly bad) are common in my experience in JavaScript. Even if they're not particularly common, you really think having to define a few interfaces takes so much time it nullifies the benefit of automatic error checking? Writing an interface is way less effort than writing a test as well, plus you get automatic refactoring tools, autocomplete and automatic error checking in return.

I really can't see why you'd want to give all that up to save a few keystrokes. I've done years of JavaScript after moving from typed languages like OCaml, C++, Java and Coq, and it's horrible trying to write large apps in plain JavaScript without types.

Re: Lisk: Blockchain development in JavaScript

#99

Post by chrisco255 »

seanwilson wrote: post #98
chrisco255 wrote: post #92

Earlier quoted context omitted.

Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type err…

> Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. > Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type…

Unexpected nulls are common in typed languages like Java and C# as well. I know some static functional languages go much further and offer superior protection and reliability. I'm willing to believe that.

However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Also, because there's mutable state everywhere buried in Java classes, you get many more logic errors.

At the end of the day, I think simplicity is the best hedge against errors. However, I tend to agree that statically typed, functional languages are probably the best for preventing errors.

Re: Lisk: Blockchain development in JavaScript

#100

Post by seanwilson »

chrisco255 wrote: post #99
seanwilson wrote: post #98

Earlier quoted context omitted.

> Having worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. > Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type…

Unexpected nulls are common in typed languages like Java and C# as well. I know some static functional languages go much further and offer superior protection and reliability. I'm willing to believe that. However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Also, because there's mutable state everywhere buried in Java classes, you get many more logic errors. At the end of th…

> However, I think that in a strongly typed languages like Java, it's more than a few keystrokes.

Type inference solves the extra typing issue and Java isn't a great example of a strongly typed language. For JavaScript, you can use TypeScript which has type inference and non-null checking. There's also BuckleScript or Reason if you want to code in OCaml so there's practical ways to get this safety in JavaScript.

> At the end of the day, I think simplicity is the best hedge against errors.

You can have static types + simplicity though which is better than just simplicity. Types and immutability constrain the behaviour of your program to make it simpler to reason about.

Post reply on HN