And don't forget the end-to-end project[1], which is the javascript crypto library by google.
The significance of these types of project extend beyond browser privacy. As crypto-currency become more prominent, we NEED better, carefully auditted javascript crypto-libraries.
While, I think they are all doing a fine job. It is not settling to think that these mission critical, crypto-code is not vetted by cryptographers.
In fact, a few months ago, there was a bug where the nonce for each signature was not set properly that basically meant you were able to work out the private key for 2 different signatures. Some users lost funds due to the bug.
These open initiatives will lay an important foundation.
I don't think that JS or any other interpreted/JIT-compiled crypto code will ever be vetted by cryptographers. Simply the fact that you can't control the memory, CPU cache and instruction scheduling means that your code is vulnerable to at least side-channel exploits.
> We believe that SJCL provides the best security which is practically available in Javascript. (Unforunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.)
Browser extensions are cryptographically signed and verified, while web application javascript is not.
The problem isn't with javascript, it is with delivering javascript in a web-based application (amongst other concerns).
Most of the other concerns about web delivered javascript also don't apply to extension security. Example: a web application can't interfere with the execution of extension code since extensions reside within their own context and cross-origin rules apply (there are special API's accessibly only from the extension to call into the web javascript).
End-to-end from Google is a browser extension, and it is signed by the developers and then verified on install. It is more secure than a traditional desktop software installation.
They also pretty commonly use in-browser JS SHA256 to derive private keys from human-generated passphrases: https://brainwallet.github.io/ There have been reports of pretty obscure, but still guessable, keys being cracked this way.
Bitcoin is fascinating just because it makes these sorts of things worth untraceable money, sometimes a lot of money, and puts it in the hands of people who have never had that sort of responsibility. Whatever else cryptocurrency does, maybe it will teach laypeople about these things, devise new ways to teach them and new technological measures to increase their safety.
While I want everything to be open and interoperable, I personally work in a startup that aims to make profit. So I also understand the commercial reasons of proprietary technologies.
So, I am torn, what should be proprietary and what should be open?
Formats should never be proprietary. That's just holding user data hostage.
Really, nothing should be proprietary, or at least not proprietary forever.Take note of Id Software's approach of open-sourcing their engines X years after release of the accompanying game.
If we keep releasing proprietary systems, nothing will be archived or usable in the future, if the source is never released. Hundreds of video games are going to be inaccessible in the future due to DRM servers, or proprietary backends.
I mean, I can ramble on forever, but it's pretty clear that non-free[1] software is bad for the future of people and society. Snowden proved RMS right.
[1]: Free as in freedom: http://www.gnu.org/philosophy/free-sw.html (You can still charge money for free software or related services. Not everyone can run their own Google, even if they open sourced it all. But that's a whole 'nother set or arguments.)
I always have a mixed feeling about ruby. The "magic-ism" of ruby is something that I just cannot deal with.
"require" gives you methods that appear out of nowhere (unlike other language where they are name spaced), method call without perens (so what is an attribute, what is a method call)
All of these look nice at first but kills maintainability later
Disregarding the UAP thing you mentioned, I believe you might be dismissing the complaints of "magic" in Ruby too quickly if you think all it is meant by it is what you said.
In the contexts I usually see, the complaints of magic are regarding Ruby's fondness of Spooky Action at a Distance. I would then argue that Ruby or its frameworks do seem to rely too much on this "magic" that otherwise is condemned by recent literature (and Code Complete).
I think the discussion is really about Rails, not Ruby. Ruby itself is fairly minimalist and easy to follow. Probably the biggest legitimate complaint about the language design itself is that it mixes functional, procedural, and object-oriented paradigms in a way that makes it hard to fully capture the benefits of any of them unless you really know what you're doing.
Now Rails on the other hand relies on a good deal more magic than say Django, but it's recognized in the community as a tradeoff and it is done carefully. Some of the things that rubyists accept in Rails they would never put in an application or library because it is deemed okay only by massively adopted convention at the framework level, but not generally a good practice.
Then you have libraries like rspec which started out being full of magic but which gradually got refined and cleaned up so that in rspec 3.0 you have zero monkey patches; it's just pure ruby, providing a totally modular set of DSLs that work together nicely and allow for amazingly readable test output.
Its all method calls. Specifically, its all calls to #send, most of which get relayed to another method (either based on the message name or, if no such method exists, #method_missing.)
And the object responds to the "foo" message by calling a method.
The difference is whether we're discussing the invocation or the response. OP's usage of method isn't incorrect in this case if it's discussing the response. It is true that all message responses (including accessors) are implemented using methods.
Yeah right. Good luck getting me back onto their platform.
Last year, our startup was heavily relying on their yahoo local API.
One day, we started having a lot of errors. We inspected the errors and it said "NO RESPONSE".
We started googling why and realized that yahoo basically just decided to shutdown the servers with ZERO notice.
Of course, There were tons of complaints about it on the forum. There were no response from yahoo. For us, The API was an important part of the product, and suddenly, our product was taken away from us.
No notice, no deprecation warning. Just one big middle finger.
There is NO WAY I am ever using yahoo with that kind of attitude.
I want to use this opportunity to open a discussion and get hacker news community's thoughts on preparing code examples.
I always find many contrieved examples in coding guides such as:
class Bicycle
def initialize(size_of_wheels)
# blah
end
def run
# blah
end
end
These are fine. But as such, the examples always fit well with the principles and you try to implement the principles, reality is a always far more messier.
Are there a better way to write coding examples? does it ever make sense, to grab snippets from a real code base and so that it is in touch with reality
There are better ways as given in Robert C Martin's excellent book, Clean Code. He constantly refers to code taken from the Fitnesse repo and shows how the code looked before and after refactoring and testing.
I do agree with the sentiment that real world code examples are more useful. When I was learning design patterns during my degree, we were actively discouraged from using Head First as THE reference even though it did simplify things. Our lecturer was later challenged on this view. He then took the students on a counter challenge to refactor and redesign code from real world examples (taken from students' projects). Reality hit quite hard for a lot of us as we struggled to see the patterns in less obvious situations.
An interesting point to note however, was that after gaining an understanding of the design patterns at a practical level, I could then reference simple examples as given in Head First and immediately formulate how I would use it to solve a practical scenario that I might have been stuck with. Funny how it worked one way but not the other.
I am not a functional programmer and I always find that when I read clojure it just looks like layers and layers of nested code. Personally, I find it visually hard to parse.
Can someone enlighten me why clojure seems to be the trending language?
I can't speak for everyone but I can speak for myself: because it makes me happy to program in. I love programming in Clojure. It makes my work a joy and that lets me produce higher quality software over the long term.
More concretely, Clojure's mechanisms for abstraction are both simple and extensible. You can create interfaces (called protocols) for writing polymorphic and efficient code against both your own and existing library classes. Transducers, the topic of the article, are an incredible abstraction that allows you to write powerful transforming functions on sequences of data that are not tied to any concrete representation. This means the same transducers you write will work on lazy sequences, non-lazy collections, and even values asynchronously put on core.async channels (a library for asynchronous programming in Clojure).
I think most languages look weird when you first see them and are unfamiliar with their syntax. But if you give it a chance, the nesting that seems confusing at first might actually come to be something you appreciate.
Maybe it helps to simply notice that Clojure code is stored in a data format. Or it may help for you try to write a simple macro.
(Macros give you extra power in extending the language, in ways which a language designer couldn't foresee. Because they're not omniscient; for your domain, you can be the expert, not them. Macros let people add paradigms-as-libraries. You may never write a macro, but you can benefit from those who do.)
Now that I'm proficient, I see those parens as cute little code units. With my code editor, I operate on these code units, not just characters. In contrast, other languages seem to have lots of punctuation in all sorts of weird places. Messy.
Not sure what you mean by nested code, but im just gone assjme something.
One the problems is that you probebly only see the more outthere post about clonure on HN, its selection bias. Most things in clojure are lije in any other FP language.
The reason many people like it is because it brings all the niceness of lisp and FP to a modern production ready VM (JVM).
Other then that the design philosphy of focusing in data and smaller composable languges seams hit a cord with many people. Also I at this point have to mention that the community is quite friendly and the maintainers do a good job at pushing the language foreward.
Also, and this is the reason it pops up on HN, the community does a good job on addopting relativly 'weird' stuff and make it practical like logic programmi g (core.match), reducers, transducers and CPS.
One reason is that it actually isjust layers and layers of nested code. While that sounds troubling as written it's a relatively simple substrate for writing code in.
I'm not certain that it is the trending language, however. Many "advanced" functional languages are trending nowadays. These languages tend to include some subset of fast functions, good modules, strong typing, pattern matching, good support for concurrency, generics, higher-kinded types, ubiquitous HOFs, easy lambda syntax, abstract data types, immutability, lack of exceptions, encapsulation of effect, minimization of state, so on and on and on.
Clojure is one of these remarkable for its (a) lisp syntax (b) dynamic typing (c) well-spoken leader, and (d) austerity.
As far as functional languages go, it's a nice compromise between the absolute purity of something like Haskell and the day-to-day practicalities necessitated by building practical, scalable things quickly (core.async, nice Java integration, runs on the JVM).
As far as looking like a parenthesis layer cake, that's part of the Lisp "tradition", really. One can look at is as the price you pay for true homoiconicity and powerful macros.
Working with Haskell for a while, "absolute" there starts to seem weird - there is room in "programming language space" for "more pure than Haskell", and some attempts at it. I've not drawn any conclusions yet as to whether anything in that space is practical, but it's certainly interesting.
So many coding lessons are so irrelevant to business / law people. No, business people don't need to really learn how to code. They want to learn how to parse / clean messy spreadsheet data.
REGEX + basic loops and conditional in VBA will do wonders to the productivity of business people.
On a separate note, I am surprized that there is still no good graphical way to build regexes
The significance of these types of project extend beyond browser privacy. As crypto-currency become more prominent, we NEED better, carefully auditted javascript crypto-libraries.
Right now, all the crypto-code are home baked. e.g.: https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/e...
While, I think they are all doing a fine job. It is not settling to think that these mission critical, crypto-code is not vetted by cryptographers.
In fact, a few months ago, there was a bug where the nonce for each signature was not set properly that basically meant you were able to work out the private key for 2 different signatures. Some users lost funds due to the bug.
These open initiatives will lay an important foundation.
[1]https://code.google.com/p/end-to-end/