It's always baffled me why more people don't seem interested in adopting design by contract, it is a ridiculously powerful tool for writing quality software.
Here's a Babel plugin which adds design by contract to JavaScript, squeezing it into existing JS syntax (the result is really similar to Eiffel) - https://github.com/codemix/babel-plugin-contracts
> It's always baffled me why more people don't seem interested in adopting design by contract
Because it's yet another layer on top of other layers, because it has performance implications ... A few languages such as Vala support some form of contracts, this kind of feature is more useful when part of the language itself, not some third party babel plugin that leads to codebase fragmentation as one just had yet another layer to the compilation pipeline. No offense, that's a nice thing you wrote, I'm just not going to use this kind of thing and add more complexity for very little gain. To me tests ARE the contracts.
I would only be willing to pay the cost of transpilation with something like Typescript which adds a signification value. Babel and co ? not worthwhile.
Your argument seems more like one against transpilers in general.
Contracts are useful during development, they're typically stripped out in production builds, so there's no performance overhead there. If you find a bug in production, turn on your contracts and you'll quickly discover the source of the error. Contracts can validate the state of the world at runtime in a way that can never be covered by unit tests, unless your tests cover all possible inputs to your program. It doesn't mean you don't need unit tests too, they are yet another layer of safety.
I use this in combination with Flow, which means I have to transpile regardless, so the overhead is very low for me. Of course I'd like them to be part of the language proper, but for that to happen there needs to be developer demand first.
If it's stripped out during production, that sounds more like an assert than a contract. What's the line over which you'd call an assert a contract...?
> It's always baffled me why more people don't seem interested in adopting design by contract, it is a ridiculously powerful tool for writing quality software.
Because it's an ugly and slow run-time hack around a proper type system, but without most of the benefits of a real type-system. The compiler cannot optimize with the given types ("contracts"), it can only add run-time checks.
Check what a typed ruby can do, and how the syntax looks much more natural there.
E.g. in my typed perl (cperl) I optimize array accesses to omit out-of-bound checks when the compiler knows that the index is within the bounds.
This is true for "shaped" arrays (typed arrays with a constant range), if the constant upper bound of a loop is within the shape, or if the loop just iterates over an array.
If the compiler knows that the given number to an unary op is only an integer, the optimized integer method can be used instead. If both arguments to a binary numeric op are integers, the optimized integer method can be used. ...
I've never seen a type system expressive enough to cover all the things that contracts can do, e.g does a type system exist which can assert the existence and size of a particular file on disk?
It's definitely most useful when combined with type annotations. They're complementary tools, annotations can ensure type safety at compile time, but type safety is only one part of program correctness, whereas contracts can validate just about any aspect of program operation because they have access to all of the runtime information. They're like unit tests that run all the time (until you strip them in production at least).
This thing can be used alongside Flow[0] and other babel plugins which use flow syntax.
You wanted to open a bank account in Germany, yet couldn't ask even the most basic questions in German? And you characterise this as a failing of the other party (the bank)? That is insane!
> And you characterise this as a failing of the other party (the bank)?
Yes. And not only that. I would go as far as saying that it is the failing of the German system in general. Heck I am being too nice here. The way everything is structured in Germany is based on one idea and one idea only. The German worker > all others. Nationalistic pride at its best.
Why would bank employees speak English when dealing with foreign business consultants? its 2016, the world should speak German by now instead!!!
It is beyond me that in 2016 English literacy in Europe's biggest economy is basically 0. In fact, I speak 4 languages and all of them were useless there. Go figure...
> its 2016, the world should speak German by now instead!!!
In which other countries have you been and lived?
Would you get a bank account easily in the UK if you speak German? Ignoring German:
Are you certain that you'd get a bank account in France, Spain, Italy? You're coming off as rather agitated and aggressive here, plus these 'German pride' and 'Everyone should speak German' references are getting dangerously close to a rather painful and sensitive subject. I'm not sure if this is intended?
> In which other countries have you been and lived?
Syrian, Sweden, Austria, Germany, USA and Turkey.
I hold dual citizenship and speak 4 languages while learning a 5th (Spanish).
> Would you get a bank account easily in the UK if you speak German?
1. You make it sound as if "all languages are born equal". What a Jeffersonian claim that is...
2. Yes much easier than it is to open one in Germany if you speak English. how do I know? I have done it 3 times so far... When I first migrated to Europe I didn't know any English yet it all worked out within days.
3. English the 2nd most spoken language in the world, only surpassed by Mandarin. Spanish is a 2nd if you only account for native speakers only and English falls in 3rd place at that point. German is 13th on a falling scale.
4. The finance world has English as the dominant language so YES, I do expect a freaking bank to speak it.
> Are you certain that you'd get a bank account in France, Spain, Italy?
Yes I do. Especially in Spain (where I currently hold one and got it literally over the phone).
> You're coming off as rather agitated
no shit... What you said prior to my reply is just flat out infuriating.
> 'German pride' and 'Everyone should speak German' references are getting dangerously close to a rather painful and sensitive subject. I'm not sure if this is intended?
It is not sensitive at all since it is the truth. That is how people act when they want to exclude you and make you feel un-welcomed. They put up bullshit barriers that should not exist in 2016 especially not in Europe's biggest economy. All of this is purely designed to piss people off who are not a part of the German culture.
If you came over to Sweden and people acted like that toward you, I would be freaking ashamed and embarrassed. I would never make a ridiculous excuse such as "well you can't ask the most basic questions in my language"... It boggles my mind how you could even justify something like that in this day and age. It is 2016 ffs, if you are a middle-class European citizen and don't speak English, that means you have purposefully evaded learning it.
It had been a while since I read it, and on rereading it, I'm not convinced the narrator was ignorant of who built the ruins he is looking at. Nevertheless, it's a pretty amazing artifact of someone looking at the ruins of collapsed culture, imagining how grand it must have been in comparison to the bleak present.
That doesn't need to be true for this to have happened. Zuck is a high profile target, probably the hackers just prioritised cracking his account and such a weak password would be found reasonably quickly even using bcrypt
Salting has zero effect on the targeted cracking of a single password. Salting protects against rainbow tables - sets of pre-calculated hashes plain-text to passwords. These are dangerous because an attacker has a large amount of time to pre-calculate hashes, but (hopefully) only a small amount of time to calculate after a dump before the password is changed. However, if you are starting from scratch and have a single password to crack, there's no difference between a salted and unsalted password.
Modern state of the art for targeted attacks is to use slow hash algorithms, such as bcrypt. They have little effect on normal operations, as most users will get the right password within a few tries, so you're adding a negligible amount of time per user. But the extra time has a huge effect when an attacker is trying to calculate millions of hashes for a single user.
You can hash something like password+email+salt. If they don't know the email or salt it makes it hard to crack and even if they do it slows things down as they have to crack each password individually rather than making a rainbow table. Also using a slower hash like bcrypt rather than sha1 helps slow things down.
> What if the salt was derived from a key the user had to supply and wasn't stored anywhere?
If I understood you that is the same as demanding the user to input two strings for password authentication, one for salt and one for password, in which case you might just as well require the user to use a longer password.
Good point. Why do we have passwords anyway? Just to authenticate at unanticipated access points? We could always just do two-factor authentication for that. A code would be sent to Google Authenticator on your phone or something like that, encrypted with your public key, and you'd just decrypt it with your private key. The phone would be secured with your password or fingerprint, which is never sent anywhere. The code would allow you to auth with the new access point. If the cellphone was connected to the internet, it could send the key directly and the site would log you in. If not connected to the net, it could use bluetooth or optical or sound to communicate with the access point (eg web browser running on a computer) to send the code. Only in the worst case would you have to type anything in yourself.
Since most people walk around with their cellphones, you could even precompute a couple keys to unlock a site, for those times when there is no internet connection. Of course, your phone should be secured with a password and you should be able to revoke the keys if anything gets lost.
Because usernames and passwords can be implemented without reliance on 3rd party infrastructure and they are culturally accepted and understood - however poorly - by everyone. We're still using 80 character lines in programming because of IBM punch card design from 1928. Similarly, I doubt the password will completely go away within our grandchildren's lifetimes. That said, our mobile devices are likely to play an increasing role in authentication for everyday activities.
We use passwords both to authenticate (assert identity) and to authorize (declare intent). The problem with automated logins is that you cannot infer intent (i.e. you have no assurance that the user actually meant to log in to your service).
The call itself is relatively expensive, but as you say it's a one off call at startup time and the methods it produces are faster than explicit promisification using `new Promise`, they are blazing fast :)
Presumably instances of `MyObject` can be accessed by functions which are running while this function is suspended, waiting for the network call. It's single threaded, as in only one thing happens at a time from JS's point of view, but other functions can be invoked (by a request coming in, or a UI event etc) while an asynchronous operation is awaiting completion.
Here's a Babel plugin which adds design by contract to JavaScript, squeezing it into existing JS syntax (the result is really similar to Eiffel) - https://github.com/codemix/babel-plugin-contracts
and here's what it looks like in a reasonably complicated program - https://github.com/codemix/malloc/blob/master/src/index.js
(disclosure: I wrote this)