I'm not as familiar with FF but the issue isn't that I don't want future people to see what I'm currently doing. I want current people to not see what I was previously doing (without permanently erasing that stuff every time).

I think incognito mode only shows url autocomplete if you've typed it out at least once in non-incognito mode. I'm really surprised there's no setting to 100% disable/hide autocomplete? I never dug around.

Heh, one time I was getting a new cable modem setup and the tech had to login to their internal system and Opera is my primary browser. For some reason he couldn't login to the system but it threw an auth error.

We concluded it could be a browser issue so he loaded it up with Chrome. He had the reigns on my computer and somehow hit the keyboard shortcut in Opera to bring up the "Save as" dialog box when trying to close the browser.

The problem is, the last thing I saved was porn so the dialog box was filled with thumb nail folder previews of my porn directory. He spazzed out and tried to instantly close it then we both pretended nothing happened. It was pretty funny and awkward.

Did he ask to wash his hands before he left?

FWIW, I'm now researching some stuff on this because I'm still sussing this language out and I discovered today that I can do something I previously thought I couldn't, but I do feel the need to address this one point: I'm not complaining about the dot being unusual or confusing coming from other languages; I'm complaining about how it's different from regular method calls in Ruby and the implications for things that (try to) operate on arbitrary functions. I'm not as annoyed as I was yesterday but I still had to delete a few hundred words from this post.

(FWIW I don't hate the language or anything, but I now think it's been overhyped in some ways)

It's clunky but suits our purposes. Better than the wiki+email system we had for collaborating before.

Doesn't work when you have 20 tabs open and want to toggle between two of them.

It's not different, though. It's consistent. Here is a detailed explanation of why.

Following smalltalk, in ruby everything is an object (well, nearly - more on that in a minute), including lambdas and procs, and the only thing you can do with objects is send them messages (ie, call methods on them).

You can't "invoke" a proc/lambda the way you would a method, ie, by slapping some parens on the end -- you can only send a proc the call() message. So you want to be able to do:

my_proc()

but that would actually be *inconsistent* because that is the syntax for method invocation, but my_proc is not a method (what object would it even be a method on??), it is an object, and the way you send objects messages is by using dot notation (i'll discuss a sort of exception to this below).

So, two of your options are:

my_proc.call()
my_proc.()

Both of these are the same, and in both cases we are sending the call() message to my_proc. The second form is simply built in syntactic sugar. Think of it like a built in alias or a C macro -- anywhere in your code you ".()" it gets replaced with ".call()". Now you can see why you can't write "my_proc()" instead of "my_proc.()" -- because the parser obviously can't replace every instance of "()" with ".call()" in your code -- because parens at the end of a name are special. They mean "send this message to the object".

This brings us back to the exception I mentioned to everything being an object: methods are not objects. Of course, Ruby allows you to *get* a Method object that *represents* any given method, but the method itself is not an object. And this makes sense: if your fundamental abstraction is the object, along with that you need the basic idea of message sending (ie, methods), so your two primitive ideas, your axioms as it were, are objects and methods/messages. And your basic syntax is just "<object>.<method>()"

Now what about this little exception to the dot notation I mentioned above:

my_proc[<optional params>]

Well this isn't really an exception either, as "[]" is just a special method name. And indeed, if you wanted to make that clear and be consistent, you can write "my_proc.[]" and it will work just fine. It's just that in this case ruby allows you to omit the dot as another built in bit of syntactic sugar: anywhere you write "object[]" in your code, ruby interprets that as "object.[]".

So viewed in this light, "my_proc.()" makes perfect sense. You could certainly argue that it's an unnecessary bit of syntactic sugar, and it would be clearer and better if everyone just always had to write ".call()". That's a perfectly valid position, and would be more in keeping with the python spirit -- just one way to do everything. But Ruby has a more hackerish vimlike philosophy, where it's all about giving you multiple shortcutty ways to do everything. And you are of course free to ignore them, and just always use ".call" everywhere, and in many situations that's probably the best route.

g_m: Argh. It's still not coming across.

-I'm not complaining about having to type or read the `.()` or `.call()`. And I'm really not complaining that there are two ways to spell it. I'm complaining about the implications for code that wants to operate on arbitrary code, e.g. higher-order functions.

- It sounds like my initial statement:

is at worst a slight exaggeration, iyo?

-Re `.call` not being an inconsistency, my use of "different" and not "inconsistent" was intentional. Reading over your post, it's more or less how I thought it worked. My sentiment here is, "If Ruby really had first-class functions, methods (or possibly blocks) would be objects."* By way of comparison, in Python or JavaScript a method is effectively just a function that happens to be in an object's hash (Python even lets you define a `__call__` method on arbitrary objects, allowing them to mimic functions if that's what some interface is expecting).

As to why this even bothers me, it's really impossible to say without an essay, which I'm probably going to end up writing at this point. The bad news for my argument** (but good news for anyone writing Ruby code) is that even though you don't have first-class functions, you have shortcuts that let you fake it for most practical purposes. This is why Rubyists get away with what I now think is false advertising; Rubyists can talk about Ruby's higher-order functions and first-class functions and even literally call the language a LISP, and they get away with it because it's easy to believe them in small examples. I mean, these things sure look like they're living up to the hype:

...that is, until you try to do something even slightly more complicated and have to understand what's actually going on. And then the more complicated stuff can be written in a slightly different way that will still be at worst "not bad," so I'll have to keep piling up requirements to make my point. And then I just know that if I reach that threshold of "obviously a serious problem," there's probably going to be some way to metaprogram your way around it, so I'll have to keep going until I've rewritten Numpy or something.


* Please note that this is not the same as saying, "Ruby should have first-class functions." But since everyone seems to insist it does, I've been implicitly holding it to that standard.

** I mean, I'm not even that annoyed; at this point I'm more annoyed at how difficult it is to explain my annoyance!

EDIT: Humorously enough, I just discovered the `&` syntax for turning a proc/lambda into an inline block, which actually means at least some things are easier than I thought they were. And this is exactly the difficulty I'm running into here; we don't have first-class functions, but we can wrap blocks in procs and cast our block procs back to blocks so trivial examples make it look like we do!

Let' get our definitions straight, first. From wikipedia:

But this definition, ruby has first class functions. They are instances of the Proc class (that includes lambdas and blocks, they're all just procs, that is, blocks of code represented as an object).

Blocks *are* objects. Methods are not, for the reasons I described in my previous post. However, you can still get Method objects anytime you want. So what you are asking for, ruby has.

With respect, it sounds like it's impossible to say because you don't really have an argument based on facts. I will agree with you that the subtle distictions between blocks, procs, and lambdas are complicated and annoying to learn. Again, going back to my point before, what they end up offering you are options that will allow you to write succinct and pretty code for each situation, if you know which one to use and why. Ruby works best in the hands of power users. The way things work in javascript, eg, *is* much simpler, and preferring that is fine. I often prefer that myself.

As for the article you linked, he ends by saying: "If you're going to use a functional programming style in Ruby, use lambdas and invoke them with .call()." Then it will work how you want, just like javascript. The rest of the article is essentially a complaint coming from someone first learning the pitfalls and distictions among blocks, procs, and lambdas. I have no problem with that. It's a valid complaint. But it does not prove that ruby doesn't support "real" functional programming or first class functions. It just proves ruby offers a lot of options, not all of which behave as you would expect if you're trying to shoehorn them into your understanding of how things work based on other languages.

If you still think I'm missing your point, instead of continuing an abstract argument you should give an example of something you can do in javascript that you think can't be done (or can't be done easily, or well) in ruby.

Gaming Mouse:

When I said that "I don't think that Ruby was meant to have functional constructs," I didn't mean that as a slight to the language or mean to say that it didn't have functional stuff.

What I meant is that, knowing what I know of the language and the idea that it is "more OO than Python" and strongly influenced by SmallTalk, that the language is likely more suited to staying the course of OO concepts, thus the dot-call makes perfect sense. Just because you can use functional stuff in Ruby doesn't mean that you should look toward those ideas before using what is more elegant in the framework of the language, which, if my understanding is correct, is generally not functional, but 80% to 90% of the time, closer to OO and procedural concepts and ideas.

dave,

yeah, if you are true functional devotee, you'll probably be happier with haskell or closure, that's true. any yeah, ruby shines when doing OO programming.

Lets not get too political here. It brings out my trolling side and I've tried to control myself in this forum (aside from obvious programmer trolling).

yes can we please not discuss bitcoin[1] and especially not discuss general economics, fiat currency, or the financial merits of precious metals?

[1] discussion of bitcoin's technology or tactical items (how do i write a bitcoin payment processor? how do i write a wallet app?) would be on-topic

Infinitely divisible my ass, think of the bits!

something something quantum mechanics tho

Is anyone super sold on Angular? It seems kinda.. clunky. Random ng-xxx slapped into markup is really the opposite of "clean seperation of code" etc, seems really bad to have JS logic thrown into your HTML in non-validating snippets like this. And jesus christ is the documentation terrible.

Fair enough and pretty wise imo (because I would def. rage away otherwise )

Yep, agreed - the existing BFI thread better location for bitcoin talk.

i spent a good amount of time learning it, was impressed at first and slowly came to the conclusion that it was too complex for my taste. i've researched many alternatives, and imo this is the best: http://www.ractivejs.org/. Documentation is great, and you can thoroughly learn the entire thing in a day. ofc, spa frameworks inspire religious debate, and you will find lots of smart people who swear by each of them, including angular.

Ractive.js looks good. I might investigate a bit

just to clarify, there are a dizzying number of js libraries named with some varation of the word "react", including react from facebook, reactive extensions from microsoft, and https://reactjs.com, not all of which are even solving similar problems.

The one under discussion here is "ractive" -- no e -- and, to use a loose analogy, is like a sinatra for spa apps.

Yep noticed it...looks cool indeed, finished the first couple of tutorials. I'm building the toolset for converting some codebase to better(?!) HTML+CSS+JS. I think I might use this.

So currently in the stuff I'll use bag: ractive.js, bootstrap

I think it's a shame we can't discuss BTC here, we're all tech people and I'm really interested in what people have to say on it, ideas people have about its uses and what you're all thinking about it.

what about confining all the discussion to a single thread and keeping it out of the LC thread?

another fine idea majority of bitcoin posts moved to this new thread: http://forumserver.twoplustwo.com/19...hread-1387971/