Example: vim comes standard in our device builds. About half the time I will go through the extra effort putting nano on it, even though I only ever need to add/change a couple lines once
thatassemblyguyJanitor of Technical Debt.Registered Userregular
I admit I haven't done a good job of learning the IDE editors I use in my day to day, so I'm not sure if any of them offer the mode-editor style of vim.
I just really like the cursor travel that vim offers in a simple package. Like, reaching for the mouse to click is enough to drop me out of my train of thought sometimes (Yes, I am a dumb, but this is beside the point), so having an editor where my hands stay on the keys I'm using for multiple tasks is amazeballs.
vim is one of those tools that I'd like to learn better. I suspect much like with cli vs gui stuff, once learned I could do a lot of stuff much more quickly. Unfortunately, I can't be bothered to learn it or use it often enough for the keyboard shortcuts to be second nature. I can insert a line above or below, delete a line, start editing wherever I am in a line, save and quite, save and not quit, search, and jump to end or beginning of a file and that lets me get whatever I need to done. My knowledge of emacs is about the same... enough to get shit done without having to spend more time looking at docs than editing the file, but not enough to find it any quicker or easier to use than sublime or atom or whatever.
tmux is also something I need to learn, now that it's been mentioned. I've used screen for about a billion years and it does what I need so I have a hard time justifying the time to figure out tmux. Everyone I've talked to who has bothered to use both says tmux is better though, so I should figure it out some day.
vim is one of those tools that I'd like to learn better. I suspect much like with cli vs gui stuff, once learned I could do a lot of stuff much more quickly. Unfortunately, I can't be bothered to learn it or use it often enough for the keyboard shortcuts to be second nature. I can insert a line above or below, delete a line, start editing wherever I am in a line, save and quite, save and not quit, search, and jump to end or beginning of a file and that lets me get whatever I need to done. My knowledge of emacs is about the same... enough to get shit done without having to spend more time looking at docs than editing the file, but not enough to find it any quicker or easier to use than sublime or atom or whatever.
Yeah, I don't know half (more than half, I imagine, actually) the vim shortcuts either. I read through a few vim golf examples, but couldn't make head nor tails of some of them.
You can get really elaborate with vim navigation but you get a lot of the way there with just four commands.
^d ^u ('down', 'up') go down and up half a page. they're easy to hit, quick for navigation, and also a bit less sledgehammery than pageup/pagedown
w ('word') jumps to the next word
b ('back') jumps to the prior word
hjkl will navigate single characters (left/down/up/right in order). these are pretty functionally boring despite having better hand positions, so if you use arrow keys whatever
On environments that I plan to use more than once, I usually will also map jk to <ESC> (imap jk <ESC> tossed into your .vimrc file) so that switching between edit mode and cursor mode is an easy keystroke to remember and type ("jk i am done editing this").
My biggest problem with vim has to be all the many, many times I've found the part of the file I want to edit and started typing away, without realising I'm not in edit mode, and my typing has done something weird like moved me to a different location, deleted a line, and started recording a macro.
Hey, isn't the proof algorithm for halting problem a little wonky?
So, say you have a stop(code) function that answers the question of whether it stops or not. Then, if you have an algorithm that goes like this:
haltingProof()
{
while(stop(haltingProof())
{continue;}
halt
}
Well, my problem with it is, if you "implement" it, then stop(haltingProof()) actually becomes infinitely recursive, in this manner:
1. The while evaluates stop(haltingProof()), so it runs stop
2. Then the stop evaluates while(stop(haltingProof()), and because the stopping condition is whether stop(haltingProof()) is true or not, stop must evaluate stop(haltingProof()), so it runs stop
3. Etc. etc.
What I'm getting at is that things become weird when code-analysis functions are given themselves as arguments. Do they all loop infinitely?
No general procedure for bug checks will do.
Now, I won’t just assert that, I’ll prove it to you.
I will prove that although you might work till you drop,
you cannot tell if computation will stop.
For imagine we have a procedure called P
that for specified input permits you to see
whether specified source code, with all of its faults,
defines a routine that eventually halts.
You feed in your program, with suitable data,
and P gets to work, and a little while later
(in finite compute time) correctly infers
whether infinite looping behavior occurs.
If there will be no looping, then P prints out ‘Good.’
That means work on this input will halt, as it should.
But if it detects an unstoppable loop,
then P reports ‘Bad!’ — which means you’re in the soup.
Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.
Here’s the trick that I’ll use — and it’s simple to do.
I’ll define a procedure, which I will call Q,
that will use P’s predictions of halting success
to stir up a terrible logical mess.
For a specified program, say A, one supplies,
the first step of this program called Q I devise
is to find out from P what’s the right thing to say
of the looping behavior of A run on A.
If P’s answer is ‘Bad!’, Q will suddenly stop.
But otherwise, Q will go back to the top,
and start off again, looping endlessly back,
till the universe dies and turns frozen and black.
And this program called Q wouldn’t stay on the shelf;
I would ask it to forecast its run on itself.
When it reads its own source code, just what will it do?
What’s the looping behavior of Q run on Q?
If P warns of infinite loops, Q will quit;
yet P is supposed to speak truly of it!
And if Q’s going to quit, then P should say ‘Good.’
Which makes Q start to loop! (P denied that it would.)
No matter how P might perform, Q will scoop it:
Q uses P’s output to make P look stupid.
Whatever P says, it cannot predict Q:
P is right when it’s wrong, and is false when it’s true!
I’ve created a paradox, neat as can be —
and simply by using your putative P.
When you posited P you stepped into a snare;
Your assumption has led you right into my lair.
So where can this argument possibly go?
I don’t have to tell you; I’m sure you must know.
A reductio: There cannot possibly be
a procedure that acts like the mythical P.
You can never find general mechanical means
for predicting the acts of computing machines;
it’s something that cannot be done. So we users
must find our own bugs. Our computers are losers!
I'm starting to think that our designers and project managers have come to believe that agile means "we can add a feature or change our minds at any time and the developers have to do it while meeting the same deadline and all other features... even if the project launches tomorrow".
They also seem to have funny definitions of "use the same", "won't make any changes", and "do nothing".
I'm starting to think that our designers and project managers have come to believe that agile means "we can add a feature or change our minds at any time and the developers have to do it while meeting the same deadline and all other features... even if the project launches tomorrow".
They also seem to have funny definitions of "use the same", "won't make any changes", and "do nothing".
I feel you. I really do. I have some similar issues and fears...
Always amazes me how many people use Vim instead of emacs on this forum, while in language specific communities I always feel that emacs is on top....Probably wishful thinking.
Edit: I'm speaking specifically about development of course.....
I'm trying to make a simple browser-based multiplayer game as a learning exercise, but I'm really inexperienced when it comes to web UI stuff. To keep it simple, imagine it's a game of noughts and crosses. I want two people to be able to go to a page, the server picks one of them to be crosses, they click in the grid and both players see a cross where they clicked.
Does anyone know a good tutorial for stuff like that? I'm hoping to keep it to just javascript, no plugins or flash or anything, and I don't need animations or physics or anything. I could do a really simple version of client vs server, but I don't know where to start with making one player's choice visible to the other, at least without making the other player sit there refreshing until something happens.
Don't have any good articles to point you too but I have a good bit of experience with custom Javascript AJAX long-polling / Comet, and WebSockets, as the two main places you'd look at.
You could use Firebase as a starting point; it's free, they have examples, and it'll take care of the client-server part for you (plus it falls back from websockets to long polling/etc automatically, which saves you a bunch of browser compatibility pain). Caveat: I haven't personally used Firebase, but people around here have played with it and it seems fine for them.
Well, okay. the Church-Turing hypothesis says that there is no computing machine that is stronger than a Turing machine. Yet, we humans can recognize that P(Q) is a paradox. So how are we humans able to recognize ("be stronger than") a Turing machine? What do we have that computers don't?
I still think P(Q) loops infinitely, thereby giving no answer.
P(Q)=P(Q) ; which gives
P(Q)=P(while(P(Q))continue else halt ; which gives
P(Q)=P(while(P(while(P(Q))continue then halt)) continue else halt ; and so on
What if P checked calls from A to A and also from A to P? I think what happens here is it detects that Q is calling P(Q) and throws an exception. I'm well convinced enough that you can't determine if any program will loop infinitely, but I'm pretty sure that you can determine the halting quality of some, or perhaps most, programs.
Don't have any good articles to point you too but I have a good bit of experience with custom Javascript AJAX long-polling / Comet, and WebSockets, as the two main places you'd look at.
I don't really know where to start, and I didn't want to hop on here and say "Tell me everything!"
So, I should start learning AJAX? I'd probably prefer to stay away from websockets, I think.
0
Options
GrobianWhat's on sale?Pliers!Registered Userregular
Well, okay. the Church-Turing hypothesis says that there is no computing machine that is stronger than a Turing machine. Yet, we humans can recognize that P(Q) is a paradox. So how are we humans able to recognize ("be stronger than") a Turing machine? What do we have that computers don't?
I still think P(Q) loops infinitely, thereby giving no answer.
P(Q)=P(Q) ; which gives
P(Q)=P(while(P(Q))continue else halt ; which gives
P(Q)=P(while(P(while(P(Q))continue then halt)) continue else halt ; and so on
What if P checked calls from A to A and also from A to P? I think what happens here is it detects that Q is calling P(Q) and throws an exception. I'm well convinced enough that you can't determine if any program will loop infinitely, but I'm pretty sure that you can determine the halting quality of some, or perhaps most, programs.
That's obvious and no one is debating that. The halting problem is that you can't have an algorithm that checks halting for every algorithm.
0
Options
GrobianWhat's on sale?Pliers!Registered Userregular
You're making assumptions about how P works. That doesn't matter, you can treat it like a black box that just spits out true or false for the sake of the paradox.
0
Options
GrobianWhat's on sale?Pliers!Registered Userregular
(Sorry for the triple post, I'm on mobile)
Also simply knowing that it is a paradox doesn't make you more powerful than a Turing machine. You still can't say if the algorithm halts or not, that's the whole point.
Don't have any good articles to point you too but I have a good bit of experience with custom Javascript AJAX long-polling / Comet, and WebSockets, as the two main places you'd look at.
I don't really know where to start, and I didn't want to hop on here and say "Tell me everything!"
So, I should start learning AJAX? I'd probably prefer to stay away from websockets, I think.
I'd take a look at Node.js
It's pretty powerful and event based stuff like this is pretty easy in Node
Currently building our second provider-hosted app at work this week. We're going to end up selling it to customers and hosting it ourselves on a public server, since it doesn't store any data. Here's hoping people like it, I think one of our customers has already bought it and that's paying for our R&D work on this thing.
I still don't know if anyone else in the industry is doing this kind of thing, but it's getting us plenty of business. It looks like hybrid solutions between on-premise and the cloud is where the future is going for SharePoint. Nobody wants to go full cloud, but there seems to be a lot of interest in either "mostly cloud" or "semi cloud" for a lot of businesses.
Well, okay. the Church-Turing hypothesis says that there is no computing machine that is stronger than a Turing machine. Yet, we humans can recognize that P(Q) is a paradox. So how are we humans able to recognize ("be stronger than") a Turing machine? What do we have that computers don't?
I still think P(Q) loops infinitely, thereby giving no answer.
P(Q)=P(Q) ; which gives
P(Q)=P(while(P(Q))continue else halt ; which gives
P(Q)=P(while(P(while(P(Q))continue then halt)) continue else halt ; and so on
What if P checked calls from A to A and also from A to P? I think what happens here is it detects that Q is calling P(Q) and throws an exception. I'm well convinced enough that you can't determine if any program will loop infinitely, but I'm pretty sure that you can determine the halting quality of some, or perhaps most, programs.
When you say "humans can recognize that P(Q) is a paradox", you are no longer talking about the domain of programs but the domain of proofs. A human recognizes/verifies the diagonalization proof via the rules of some logic; similarly a computer can do the same thing. In this sense, a computer can recognize the diagonalization paradox as well.
It's important to note that the diagonalization argument actually shows how both human logic and computers are limited in the same way. We are unable to make a decision about what P(Q) returns not because of an infinite loop but because of a logical contradiction.
As an aside, note that the Church-Turing hypothesis relates an informal notion of computability ("things we can compute on pen and paper") with the formal notions of computability: general recursive functions, the λ-calculus, and turing machines. It isn't a proven theorem (because of the "informal notion of computability"), and it only comments on what computation can do versus cannot do.
Kambing on
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
Posts
Vim: the program where if you forget a command, you can't leave. Good luck getting that cursor back!
ESC, ESC, ESC, ESC, ESC, ESC, Shift+ZZ.
I just really like the cursor travel that vim offers in a simple package. Like, reaching for the mouse to click is enough to drop me out of my train of thought sometimes (Yes, I am a dumb, but this is beside the point), so having an editor where my hands stay on the keys I'm using for multiple tasks is amazeballs.
"If you're going to play tiddly winks, play it with man hole covers."
- John McCallum
I was really amazed at the whole multi-terminal concept (was it like Alt-F1/F2/... or Ctrl-Alt-F1?)
and for some reason I loaded up my first instance of vim.
But couldn't figure out what :q meant =P
So proving that a little knowledge is a dangerous thing, I went into another text terminal, ps'd and kill -9'd the vim process.
tmux is also something I need to learn, now that it's been mentioned. I've used screen for about a billion years and it does what I need so I have a hard time justifying the time to figure out tmux. Everyone I've talked to who has bothered to use both says tmux is better though, so I should figure it out some day.
Le *sigh*
Yeah, I don't know half (more than half, I imagine, actually) the vim shortcuts either. I read through a few vim golf examples, but couldn't make head nor tails of some of them.
I realize there are other options, but I never learned them and feel no desire to.
^d ^u ('down', 'up') go down and up half a page. they're easy to hit, quick for navigation, and also a bit less sledgehammery than pageup/pagedown
w ('word') jumps to the next word
b ('back') jumps to the prior word
hjkl will navigate single characters (left/down/up/right in order). these are pretty functionally boring despite having better hand positions, so if you use arrow keys whatever
On environments that I plan to use more than once, I usually will also map jk to <ESC> (imap jk <ESC> tossed into your .vimrc file) so that switching between edit mode and cursor mode is an easy keystroke to remember and type ("jk i am done editing this").
If you can use it, it's great.
So, say you have a stop(code) function that answers the question of whether it stops or not. Then, if you have an algorithm that goes like this:
haltingProof() { while(stop(haltingProof()) {continue;} halt }Well, my problem with it is, if you "implement" it, then stop(haltingProof()) actually becomes infinitely recursive, in this manner:
1. The while evaluates stop(haltingProof()), so it runs stop
2. Then the stop evaluates while(stop(haltingProof()), and because the stopping condition is whether stop(haltingProof()) is true or not, stop must evaluate stop(haltingProof()), so it runs stop
3. Etc. etc.
What I'm getting at is that things become weird when code-analysis functions are given themselves as arguments. Do they all loop infinitely?
Write a program that checks itself using your Halt algorithm. If the Halt algorithm says that you halt, then loop forever, otherwise halt.
That you can construct such a program is the proof that you can't determine the solution by code, as you can always wrap it into this contradiction.
You can skip to 3:25
Now, I won’t just assert that, I’ll prove it to you.
I will prove that although you might work till you drop,
you cannot tell if computation will stop.
For imagine we have a procedure called P
that for specified input permits you to see
whether specified source code, with all of its faults,
defines a routine that eventually halts.
You feed in your program, with suitable data,
and P gets to work, and a little while later
(in finite compute time) correctly infers
whether infinite looping behavior occurs.
If there will be no looping, then P prints out ‘Good.’
That means work on this input will halt, as it should.
But if it detects an unstoppable loop,
then P reports ‘Bad!’ — which means you’re in the soup.
Well, the truth is that P cannot possibly be,
because if you wrote it and gave it to me,
I could use it to set up a logical bind
that would shatter your reason and scramble your mind.
Here’s the trick that I’ll use — and it’s simple to do.
I’ll define a procedure, which I will call Q,
that will use P’s predictions of halting success
to stir up a terrible logical mess.
For a specified program, say A, one supplies,
the first step of this program called Q I devise
is to find out from P what’s the right thing to say
of the looping behavior of A run on A.
If P’s answer is ‘Bad!’, Q will suddenly stop.
But otherwise, Q will go back to the top,
and start off again, looping endlessly back,
till the universe dies and turns frozen and black.
And this program called Q wouldn’t stay on the shelf;
I would ask it to forecast its run on itself.
When it reads its own source code, just what will it do?
What’s the looping behavior of Q run on Q?
If P warns of infinite loops, Q will quit;
yet P is supposed to speak truly of it!
And if Q’s going to quit, then P should say ‘Good.’
Which makes Q start to loop! (P denied that it would.)
No matter how P might perform, Q will scoop it:
Q uses P’s output to make P look stupid.
Whatever P says, it cannot predict Q:
P is right when it’s wrong, and is false when it’s true!
I’ve created a paradox, neat as can be —
and simply by using your putative P.
When you posited P you stepped into a snare;
Your assumption has led you right into my lair.
So where can this argument possibly go?
I don’t have to tell you; I’m sure you must know.
A reductio: There cannot possibly be
a procedure that acts like the mythical P.
You can never find general mechanical means
for predicting the acts of computing machines;
it’s something that cannot be done. So we users
must find our own bugs. Our computers are losers!
I started learning vi because the only editor on our target hardware was BusyBox's crappy version of vi.
Then I learned vim when our development network's X server crapped out for a day or so because hey, I already knew the basics
Now I can't use anything else. The last time I used Visual Studio, I had random ":w" all over my code from when I absent-mindedly tried to save.
They also seem to have funny definitions of "use the same", "won't make any changes", and "do nothing".
I feel you. I really do. I have some similar issues and fears...
Always amazes me how many people use Vim instead of emacs on this forum, while in language specific communities I always feel that emacs is on top....Probably wishful thinking.
Edit: I'm speaking specifically about development of course.....
Does anyone know a good tutorial for stuff like that? I'm hoping to keep it to just javascript, no plugins or flash or anything, and I don't need animations or physics or anything. I could do a really simple version of client vs server, but I don't know where to start with making one player's choice visible to the other, at least without making the other player sit there refreshing until something happens.
Don't have any good articles to point you too but I have a good bit of experience with custom Javascript AJAX long-polling / Comet, and WebSockets, as the two main places you'd look at.
I still think P(Q) loops infinitely, thereby giving no answer.
P(Q)=P(while(P(Q))continue else halt ; which gives
P(Q)=P(while(P(while(P(Q))continue then halt)) continue else halt ; and so on
What if P checked calls from A to A and also from A to P? I think what happens here is it detects that Q is calling P(Q) and throws an exception. I'm well convinced enough that you can't determine if any program will loop infinitely, but I'm pretty sure that you can determine the halting quality of some, or perhaps most, programs.
I don't really know where to start, and I didn't want to hop on here and say "Tell me everything!"
So, I should start learning AJAX? I'd probably prefer to stay away from websockets, I think.
That's obvious and no one is debating that. The halting problem is that you can't have an algorithm that checks halting for every algorithm.
Also simply knowing that it is a paradox doesn't make you more powerful than a Turing machine. You still can't say if the algorithm halts or not, that's the whole point.
I'd take a look at Node.js
It's pretty powerful and event based stuff like this is pretty easy in Node
I still don't know if anyone else in the industry is doing this kind of thing, but it's getting us plenty of business. It looks like hybrid solutions between on-premise and the cloud is where the future is going for SharePoint. Nobody wants to go full cloud, but there seems to be a lot of interest in either "mostly cloud" or "semi cloud" for a lot of businesses.
When you say "humans can recognize that P(Q) is a paradox", you are no longer talking about the domain of programs but the domain of proofs. A human recognizes/verifies the diagonalization proof via the rules of some logic; similarly a computer can do the same thing. In this sense, a computer can recognize the diagonalization paradox as well.
It's important to note that the diagonalization argument actually shows how both human logic and computers are limited in the same way. We are unable to make a decision about what P(Q) returns not because of an infinite loop but because of a logical contradiction.
As an aside, note that the Church-Turing hypothesis relates an informal notion of computability ("things we can compute on pen and paper") with the formal notions of computability: general recursive functions, the λ-calculus, and turing machines. It isn't a proven theorem (because of the "informal notion of computability"), and it only comments on what computation can do versus cannot do.