Gosling's inability to sell his own version of a proprietary Emacs built on MockLisp back in 1981 says very little about whether it's a useful tool today.
There is an official Windows build which is usually found in the "windows" subdirectory on the official mirrors. There's also an unofficial Mac OS X build (though the site is currently down).
A more common issue is that Emacs just isn't installed by default on as many servers. So it's a good idea to know how to use vi to go to a line, perform a search, insert some text and save the file at the very least.
Not necessarily. Sometimes the act of explaining how stuff works to a documenter can not only make for better documentation, but enlighten the original developer as well. The development of the "Inside Macintosh" documentation is one such example.
Re:it could have been worse
on
GitHub Hacked
·
· Score: 2
Which would be noticed the next time anyone does a push to the repository. There'd be an unexpected non-fast-forward push, and git would force developers to deal with it by default.
In 5 years, self-driving cars will be another 5 years away from being available to consumers. In 10 years, self-driving cars will still be another 5 years away from being available to consumers. And so on.
Not better than human drivers. They're still significantly slower, or running on closed courses, or on pre-mapped city streets with a human behind the wheel.
The technology to make computers navigate the real world and its hazards as well (and as fast) as humans is still years off - and may remain that way.
Given enough time to adapt- the whole country could be computer-driver only.
Only if computer drivers get intelligent enough to understand what to do when a deer crosses the highway in the middle of the night. Or when a child's ball comes bouncing into the street. Or when there's a giant pothole in the traffic lane.
Computers are excellent in controlled situations when it knows all the variables. But real life is a messy place full of surprises and unknowns that computers have long been ill-equipped to handle. So like the mythical flying car, I don't expect to see computer driven cars in my lifetime simply because human brains adapt better at handling the unexpected.
The trouble is that uploading gigs of data can take hours, depending on one's connection speed. So once Google gets bored with this service and kills it, one will have to spend that time re-uploading it to a less flighty service provider.
You still seem to fail to understand my point that you should not need a special editor to help you correctly understand what the code is doing.
The code is doing exactly what the source code tells it to do. If you're having trouble reading what's in your source code - especially source code from someone else - there's plenty of tools available to make that job easier. If your editor made periods and commas look the same, it'd be hard to write C code and it'd be smart to switch. If your editor makes tabs and spaces look the same, it's hard to write Python code and you'd be smart to switch.
It doesn't require a "super-duper IDE". But by sticking to something sub-optimal, you're making it harder than it needs to be.
Python doesn't care whether you're using tabs or spaces, so long as you use a consistent amount of it to denote blocks. The problem is that some editors don't show you the difference. Nobody complains about semicolon requirements in C code because an editor shows you where all the semicolons are in a given piece of code. I feel whitespace should be just as easy to follow. If someone's indented a block wrong or mixed in some tabs, that should be just as easy to spot - even if you're using a language without any whitespace restrictions at all.
My solution is to use ethan-wspace which automatically highlights tabs in source code (along with lots of other little whitespace problems) and lets me clean them up trivially with the touch of a button and without breaking the file. It not only keeps my Python code functioning, but does wonders for keeping junk whitespaces changes out of source control.
will tell you all the line numbers where someone's mixed tabs and spaces. Or use M-x whitespace-mode (or your editor's equivalent) and clean them up yourself in whatever consistent style you'd prefer.
Python's design has plenty of annoyances, but its whitespace-based syntax is the among least of them.
Six months from now, long after I've moved on to something completely different, am I going to remember a function's return values? The inner workings of a particularly complex algorithm? Or the reasoning while a special case has to be handled differently?
If it's not going to be obvious to myself later on, it's worth adding a concise comment to explain.
The idea is that the end user is still going to keep all his devices behind a firewall so everybody on the internet can't probe them. But since your toaster has its own actual address, it can connect directly to the Online Toasting Database server without having to kludge all that traffic through a NAT.
FLAC's maximum compression tends to outperform ALAC by a few percentage points. Internally, the two are quite similar. ALAC uses LPC-style frames with adaptive coefficients and an adaptive residual, which works well enough for 16bps input. But for 24bps, ALAC stores the lower 8 bits of each sample uncompressed, and FLAC blows it away.
Slashdot Mirror
Don't forget Zork, Enchanter and other Z-machine games.
Firefox uses SQLite, which implements a database management system in a single file. It's not something anyone can connect to remotely.
Gosling's inability to sell his own version of a proprietary Emacs built on MockLisp back in 1981 says very little about whether it's a useful tool today.
By simply remembering the site name and a strong master password, one can generate a unique password for each site.
There is an official Windows build which is usually found in the "windows" subdirectory on the official mirrors. There's also an unofficial Mac OS X build (though the site is currently down).
A more common issue is that Emacs just isn't installed by default on as many servers. So it's a good idea to know how to use vi to go to a line, perform a search, insert some text and save the file at the very least.
It's been done.
If you like the undo stack, Undo Tree will blow your mind.
while anything that needs a counter I take care of with repeat-insert
Not necessarily. Sometimes the act of explaining how stuff works to a documenter can not only make for better documentation, but enlighten the original developer as well. The development of the "Inside Macintosh" documentation is one such example.
Which would be noticed the next time anyone does a push to the repository. There'd be an unexpected non-fast-forward push, and git would force developers to deal with it by default.
In 2012 there are 261 weekdays. In 2011, there were 260. But in 2010 and 2009 there were also 261 weekdays. So not really.
In 5 years, self-driving cars will be another 5 years away from being available to consumers. In 10 years, self-driving cars will still be another 5 years away from being available to consumers. And so on.
Not better than human drivers. They're still significantly slower, or running on closed courses, or on pre-mapped city streets with a human behind the wheel.
The technology to make computers navigate the real world and its hazards as well (and as fast) as humans is still years off - and may remain that way.
Only if computer drivers get intelligent enough to understand what to do when a deer crosses the highway in the middle of the night. Or when a child's ball comes bouncing into the street. Or when there's a giant pothole in the traffic lane.
Computers are excellent in controlled situations when it knows all the variables. But real life is a messy place full of surprises and unknowns that computers have long been ill-equipped to handle. So like the mythical flying car, I don't expect to see computer driven cars in my lifetime simply because human brains adapt better at handling the unexpected.
The Twin Cities light rail system is entirely above ground.
The trouble is that uploading gigs of data can take hours, depending on one's connection speed. So once Google gets bored with this service and kills it, one will have to spend that time re-uploading it to a less flighty service provider.
The code is doing exactly what the source code tells it to do. If you're having trouble reading what's in your source code - especially source code from someone else - there's plenty of tools available to make that job easier. If your editor made periods and commas look the same, it'd be hard to write C code and it'd be smart to switch. If your editor makes tabs and spaces look the same, it's hard to write Python code and you'd be smart to switch.
It doesn't require a "super-duper IDE". But by sticking to something sub-optimal, you're making it harder than it needs to be.
Python doesn't care whether you're using tabs or spaces, so long as you use a consistent amount of it to denote blocks. The problem is that some editors don't show you the difference. Nobody complains about semicolon requirements in C code because an editor shows you where all the semicolons are in a given piece of code. I feel whitespace should be just as easy to follow. If someone's indented a block wrong or mixed in some tabs, that should be just as easy to spot - even if you're using a language without any whitespace restrictions at all.
My solution is to use ethan-wspace which automatically highlights tabs in source code (along with lots of other little whitespace problems) and lets me clean them up trivially with the touch of a button and without breaking the file. It not only keeps my Python code functioning, but does wonders for keeping junk whitespaces changes out of source control.
will tell you all the line numbers where someone's mixed tabs and spaces. Or use M-x whitespace-mode (or your editor's equivalent) and clean them up yourself in whatever consistent style you'd prefer.
Python's design has plenty of annoyances, but its whitespace-based syntax is the among least of them.
Six months from now, long after I've moved on to something completely different, am I going to remember a function's return values? The inner workings of a particularly complex algorithm? Or the reasoning while a special case has to be handled differently?
If it's not going to be obvious to myself later on, it's worth adding a concise comment to explain.
Or, they could just look at the Saturn V on display in NASA's visitor center.
The idea is that the end user is still going to keep all his devices behind a firewall so everybody on the internet can't probe them. But since your toaster has its own actual address, it can connect directly to the Online Toasting Database server without having to kludge all that traffic through a NAT.
FLAC's maximum compression tends to outperform ALAC by a few percentage points. Internally, the two are quite similar. ALAC uses LPC-style frames with adaptive coefficients and an adaptive residual, which works well enough for 16bps input. But for 24bps, ALAC stores the lower 8 bits of each sample uncompressed, and FLAC blows it away.