flebron

My point is indeed that "you can't compare [arbitrary sized numbers] in constant time" is a statement about some model of computation, and not all of them.

Where 'large' is about 80.

The computational model will define what you can and cannot compare in constant time. It is perfectly fine to say that comparing elements of arbitrary size is a constant time operation - that's precisely what a computational model is: an enumeration of the operations that are considered basic.

Well, what you wrote is "The main reason I did it was to see what Haskell is capable of compared to other languages such as Python." The problem is that what you coded isn't what Haskell is capable of :)

The dice aren't loaded, you're just seeing a binomial distribution[1][2] :)

[1] http://en.wikipedia.org/wiki/Binomial_distribution [2] http://hyperphysics.phy-astr.gsu.edu/hbase/math/dice.html#c2

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language.

And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p

I also spent more time with CLRS, I've had my copy for close to a decade now :)

I found ADM to be much less useful. It was mostly a small bit of code per concept, with little explanation or proofs or information about why it worked. If I wanted to copy and paste code, I wouldnt've gotten a book, I'dve searched Google. I'm much more comfortable with the knowledge I obtained from CLRS, because I know not just how to code the things (since there's pseudocode for them) but why they work, and how to debug things when they break. Overall, whereas I'd class CLRS as one of the best purchases I've ever made (in terms of dollars/use of the product), I'd class ADM as one of the worst, and that's even considering it was like $5 used :)

Unfortunately, it's just a background fact that Google employs a lot of well-known computer science figures. So this was bound to happen unless they explicitly forbade them from signing this, which I also don't think is good.

Per object vtable pointer, yes.

Having any virtual member functions, unless the compiler can devirtualize it, will hurt both space usage (since you now need a per-object vtable) and cache performance (since destruction now has to go through an indirection every time, instead of being a globally visible function).

You have the `final` specifier since C++11 to state a class cannot be inherited from, but this notion of "You really shouldn't inherit from this class." has been around since classical object orientation has, C++ just couldn't express it as a language.

So if your class currently isn't being inherited from, make your public dtor nonvirtual. If and when it needs to be a base class, then the author can modify your class to have a virtual dtor, or use composition (which is often the superior alternative). If source code is not available, then composition it is. I would advise against making it virtual "just in case", that's premature pessimisation.

It's 2014. How are people still rolling their own, terrible, encryption schemes?

>Please note that O matters. Even if both algorithms belong to O(n log n) class, algorithm for which O=1 is 100 times faster then algorithm for which O=100.

Wait, what? O = 100? That's just... not how it works.

Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.

Underscores are already being used for user defined literals.

It's going to be untyped in the same sense that the following Haskell code is untyped:

    foo = [1, 2, 3]
    x = foo

We didn't give a type to x, but the compiler will infer it anyway. If foo changes, x will change too. This does not make Haskell untyped, it just means it can add type annotations by itself in most cases (see Hindley-Milner type inference).

Note that that code won't "compile no matter what", because in C++ construction using "=" is already an operation that not all types have. So if foo returns an object which does not have a copy constructor or move constructor, then that line will fail to compile. In the more general case, you'll still not be able to use operations on x that x's type does not support, and that's what type safety means.

That last "click" should be "next", clearly :)

Perhaps an easier example is to do this in GHCi:

    let x = id id id id id id id id id id id id id id id id id id id id id id id id

See how long that takes (add ids if your machine can take it). To deduce a type for x, ghci will use 2^k type variables, if you have k ids. This is easily seen by induction:

If k = 1, then the type of x is a -> a. This takes 2 = 2^1 = 2^k variables. If k > 1, it is of the form id f. Let t be the type of f. t has 2^{k - 1} variables, by induction. Thus the outermost id must take something of type t (this is 2^{k - 1} variables) and produce something of that same type t (this is another 2^{k - 1} variables), that is, it's of type t -> t. 2^{k - 1} + 2^{k - 1} = 2^k.

Note that this information is purely at compile time. Haskell isn't typed at runtime, this is all just to check types. At runtime, x is a no-op, as expected.

For anyone who's interested in type theory and programming language foundations and modern development, I've found the talks of these summer schools really interesting and useful. The videos and material are at https://www.cs.uoregon.edu/research/summerschool/summer14/cu... , and you can change "14" in the URL to earlier years to see previous material. It's really a highly valuable set of resources.

He already searched, on google. He shouldn't have to search twice for the same thing.

I'm guessing he doesn't mean branching on a result, he means just comparing two things via cmp.

Well this is embarrassing.

So how do you handle any sort of software development planning? Do you just tell the client "It'll be done eventually. I'll let you know when.", or would you accept that reply from your employees?

foo = undefined

And all its brothers :)

I may be alone in this camp, but I'd actually recommend people read the ES5 spec if they want to be confident in their JS. It's one of the most readable and understandable specifications I've read, and (compared to behemoths like C++) is fairly short. There's even an internally-hyperlinked version at http://es5.github.io .

I will do that as soon as you explain how treating female coders as if they were freaks, segregating them in their own class, decreases the problem of integration of more female coders in tech.

Perhaps the issue of "feeling alien to the community" would be improved by, you know, not alienating females from the community, with sexist behavior such as this.

Because passing around tuples and pattern matching against them becomes tiring. So you wrap that code repetition pattern around in a State. The State monad is implemented in terms of the language itself, it's not adding anything to the language in terms of computability or expressiveness. It's simply making you type less, for something you could already write in the language itself.

All of these things - Functors, Applicative, Monads, Lenses - are all design patterns in functional programming. In the same way you can use an Observer pattern in OOP, you can use a Monad pattern in functional programming. Neither adds neither computational nor expressive power to the language, but it does avoid code repetition.

It seems you think all Monads are Maybe, or List?

I really liked this talk.

PHP was my first language when I was starting out professionally, and before I went into university and learned "proper programming". Back in 2007-2008, I remember the mess it was, with the internals list being a permanent struggle to implement anything by consensus (no lambdas or JS array notation because it wasn't easy to google, for example), and it really did look like a dead end. The internal source code of PHP was often a mess of macros everywhere, and the whole PHP6 unicode fiasco really did paint a grim picture of its future.

Facebook seems to have given it a bit of fresh air, implementing some pretty interesting stuff (Hindley-Milner with subclasses, for instance), and it really seems like the "feel" of programming in PHP has changed. I'm not going to say "Screw C++ and Haskell, _this_ is a serious language!", but on the other hand I feel I can say with a straight face to someone who is starting programming, "You could check this language out", without a guilty conscience that I'll be ruining their mind.

I'm unsure of PHP's future - if it'll be tied to Facebook (and thus Facebook's future, which I am equally unsure of), for example - but as of now, it seems to be a reasonable, if idiosyncratic, language.

So yeah, good talk :)

"I design and develop websites at MasterMade or write at Newly Ancient."

From your website.

This is a similar argument to sqrt(2) being "not a number", back in the BC's, because it was not rational. And yet, you can construct it in a straightforward manner by making a right angled triangle with catheti of length 1, giving a hypotenuse of length sqrt(2). I suppose this would have made you equally uncomfortable back then.

One can definitely "work with" numbers that aren't easy to write. a + (-a) = 0, and this is valid for every real number a, not just "the ones which I can describe with a finite amount of information", or the ones I've written down at some point in my life.