It has poor backwards compatibility (Python 3 != Python 2)
This is mostly an issue if you mix Python versions. These days reasonably modern shops tend to solely use Python 3.
(It is definitely annoying though if you never got the budget to migrate your legacy project from Python 2 to Python 3 or if you do operations work on some ancient box that only includes Python 2.)
it is single-threaded like JavaScript and it's pretty slow all around unless you code all your libraries in C (and throw away all the stuff that makes it Python)
Many classic Python usage scenarios simply use Python libraries that wrap C libraries. Most important everything related to data science and machine learning. There Python is used to express business logic and C libraries do the actual computation.
Apart from that, there are plenty of scenarios where Python is "fast enough" and you don't really care if you get the result in 0.001 seconds or 0.005 seconds.
It's really about picking the right tool for the right job. And sometimes faster development time is more important than faster execution time.
then get flipped to Github and have to... get registered again - in order to get what... a manual?
You don't need to register on github. Just scroll down on the manual page and you will see the directory listing and after that the rendered manual in Markdown.
But granted, usability wise this is abysmal. Possibly they currently intend to make it accessible only for people who already have experience with github and other weird things until it has matured enough to be used by the general public.
A recent German article on a similar subject called out the current crop of AI and suggested to refer to it as "clever statistics" instead. IMHO this is spot on.
I can't quite figure out why anybody would want to use Microsoft SQL Server.
Corporate policy. It does make sense if large parts of your IT infrastructure already use MS SQL server, especially applications from external vendors. Adding another database increases costs and complexity for maintenance and support.
And it's inexpensive enough for the little money saved by using the free PostgreSQL not to make any noticeable difference. SQLite is very nice for certain applications but does not scale well (by design). MySQL still lacks support for many SQL features present even in SQLite and is bearable only through an ORM. I hear the finally thinking about adding support for common table expressions.
While my favorite would be Brazil, I found Coherence to be very effective in its minimalistic setting. From the IMDB summary: "Strange things begin to happen when a group of friends gather for a dinner party on an evening when a comet is passing overhead."
Either that or bite the bullet and start a huge replacement project that costs several magnitudes more than exorbitant hourly rates.
Cost is only part of the reason why replacement projects are avoided. Another major reason is the risk involved. Software developed in the 60s, 70s or 80s couldn't rely on many things we take for granted these days. Requirements engineering, robust libraries, development tools, testing mechanics and so on (warts and all) just were not quite there yet or did not exist at all.
So even if you have the budget to start a replacement project it's hard to predict if the new software will still work because nobody really knows what it's supposed to do. Sure, it's easy to pin down the common use cases, but it's almost impossible to be certain you also figured all the corner cases and special features that have been added over the decades.
Consequently it is very hard to find someone in upper management to bet his career on something that, at best, works as well as the existing system.
As a result, I've lost hundreds of hours in code reviews because some pedant was more interested in picking nits over whitespace than actually reviewing my algorithms.
The places where I worked used a simple guide line: the author has to clean up trivial issues before submitting an item for review. In case of code, this means ensuring style conventions.
Which in practice is trivial for reasonably popular programming languages:
First, you rarely have to invent your own style conventions. Instead, use existing standards. For instance, there are standard coding conventions for Java and Python.
If some guide lines do not make sense for your shop, simply change them to fit your needs. For example, PEP8 recommends a maximum line width of 79 characters. However, all our developers work a horizontal resolution of 1920, so we allow 132 characters. We also changed naming conventions from the loud and baroque SOME_CONSTANT to the calm SomeConstant.
Next, there are tools to check these conventions such as CheckStyle and flake8. Often you can even find tools to reformat source code consistently or automatically fix trivial issues like missing blanks, for example autopep8.
Some shops inject these tools in the commit hook of their version management and make it reject any code that does not conform. Baring that, the review moderator is required to run the style checks on the review item. If it turns out that the author still left style issues in the code, the moderator returns the item to the author and requests to clean it up.
That way, the reviewers always get tidy code and can focus on comprehensibility, maintainability and algorithms.
AFAIK you don't have to. Using the Steam key is optional (or at least was for the Trine bundle, but I doubt it changed for this one).
Once purchased, you'll receive an email that tells you where to download the DRM free archives for the game.
Alternatively, you can use the Steam key and let Steam care about the rest. I've never used mine, but I can see that it's convenient for other gamers because of automatic updates, friend lists, achievements, the "join game" function and so on. So if much of your gaming revolves around Steam, the optional key seems to be a good thing.
[I]f the underlying technologies of the web had been patented by Sir Tim (or similar) and licensed then we wouldn't be posting on Slashdot right now because nobody outside of large multinationals would even be *using* the web for anything.
Case in point: Hyper-G/Hyperwave. It was developed at about the same time as the WWW. It was technically pretty solid (renaming documents didn't break links, integrated search engine, powerful authoring tools) and even didn't use an abbreviation that took longer to pronounce the the full name.
AFAIR it soon moved out of the academia and was turned into a commercial product, so it basically did what the WIPO head suggested.
These days it doesn't even have an Wikipedia article anymore. According to its homepage, it found a niche for corporate intranets and now competes with SharePoint.
There are plenty of other early hypertext systems comparable to the WWW (going back to the 60ties). I seem to recall that Douglar Engelbart's NLS was heavily patented, though I cannot find a reference for this right now. (Though partially these systems certainly failed because of insufficient technology and lack of a target group. You can't blame everything on patents).
Once those containers get back to China and are loaded up with cargo, you now have 5 ships worth of cargo containers, but only 2 ships to transport them. Those 3 ships you left in the U.S.
Good point. Seems they need to find a way to fold ships, too.
The gist of article seems to be that for many tasks people should combine the powerful Unix standard commands like find, grep, xargs, sed, etc instead of writing dedicated programs in lower level languages such as Ruby, Python, Java etc. This idea is not new, and many of the people around here have heard it 15 or more years ago. Being a developer, I always liked the perspective of having to write lesser code.
However, the Unix command line and shell script approach never really worked for me, especially if other people in the team wrote them. The main reasons for that are:
missing error handling (no checking for "$?", broken pipes,...)
lack of consideration for special cases such as file names with blanks in them
difficult post-mortem analysis if the data causing an error got lost in a pipe instead of being available in an intermediate or temporary file
possible configuration nightmare to get non-ASCII characters working (depending on the actual platform you're on; it can be easy, too)
terse syntax with a tendency to "write only" code (which makes sense for a direct input command line but less so for code that should be maintained for years to come)
All of this could be overcome by measures such as checking $?, redirecting stderr, using temporary files, configuring encodings properly, documentation comments and so on. However, this rarely ever happens in practice.
For the past couple of years I have been using ant for many tasks formerly delegated to shell scripts. Its main advantages are:
provides many standard tasks to copy/move/delete files, search and replace in files, filter files, download files, send mails etc.
provides many ways to limit commands only to certain files depending on name, date, contents etc.
most tasks fail on encountering any error and consequently terminate the whole script (though this can be disabled for a certain task if needed be)
generic <exec> task to execute shell commands in case ant does not provide a standard task; you have to be careful with this one though and set failonerror="true" or it will continue even if it fails
pretty legible due to using english words instead of abbreviations for most things
many simple typos are already detected when ant parses your script and not only when a task gets executed.
platform independent syntax for file paths so your script can work on Unix and Windows.
takes care of all escaping and non-ASCII issues with files names.
Of course it's not perfect. For example, it uses XML and consequently contains some syntactic noise, it lacks advanced string operations, there are no pipes and sometimes seemingly trivial things result in a lot of messing around with properties. Nevertheless I rarely see a need to write shell scripts anymore except for simple launchers.
YMMV but despite ant initially being a build tool for Java developers, we use it for many sysadmin-like tasks with great success and a small amount of development time.
If you want to know what is actually going on in a company, the 3 groups of people you need access to are the admins (who can watch people's computer use), the security guards (who can watch people's physical activities), and the bookkeepers (who know where the money and therefor the power is going).
In order to gain all this information, the only group of people you need access to are the secretaries.
For instance, get a 27 inch at 2560x1440 and set the resolution to 1380x720, thus every pixel on the screen takes 2x2 pixels on the monitor. This gives you a sharp picture at resolution that is easy to handle for aging eyes.
[D]oes this offer hope that someone might finally make a good movie based on a game IP?
A good movie based on MMORPG game IP has already been made: Ben X revolves around the game Archlord and the real life of some players. Think Rainman meets WoW.
Additionally, a wired mouse is easier to find when buried somewhere in the clutter on your desk: just follow the cable back from where it is connected to your computer.
I still have an Amiga 2000 standing around from 1989 with a 8 Mhz 68000 CPU and 7 MB RAM. Funny thing about it is that it can run the relatively modern AmigaOS 3.1, for which reasonably well working graphical web browsers exist. Occasionally I fire it for fun just to demonstrate that 80's hardware can show web pages in a semi decent way. Configure it to run on a 640x400 screen with 8 shades of grey and it still shows most of the modern web sites that have some sort of accessibility fall back. It can do tables and basic CSS, so in some cases the results are almost indistinguishable from what you see on a modern browser. Of course it is awfully slow and needs several seconds to render a medium sized PNG image.
It's particular cool to show it too kids that think you need GHz's and GB's to surf the web.
According to the IMDB FAQ there seems to be some disagreement on this:
Is this film a remake?
[...] [T]here are clear similarities. Both films deal with a robbery, and feature a warehouse rendez-vous spot, a climactic Mexican stand-off, and the relationship between a veteran thief and an undercover cop, but Lung fu fong wan deals mostly with events leading to the robbery, while Reservoir Dogs is famously about the aftermath of an unseen heist gone wrong. [...] There are similar elements between the two films, but much of what makes Reservoir Dogs a classic - pacing, style, and some famous plot twists - is not present in Lung fu fong wan. Nevertheless, the debate has continued among some film fans.
Personally I can't think of any Tarantino movie I'd call "original" though some of them I find reasonably amusing.
Your eyes can only pickup 80fps anyway; you wouldn't know if it was 100 or 10,000 fps unless the fps counter didn't say.
[...]Gunny how that number keeps creeping upwards. First it was 24 FPS (because that was all the eye could see), then 30, then 60, now you're saying 80.
There are to different issues at work which are well documented in literature and backup up with experiments:
At a certain framerate, single images blur into an animation an can not be distinguished as single images anymore. This happens at about 25 FPS.
If you flash a single image for a short enough time, the eye and brain will not be able to recognize it anymore. While the brain decodes an image, it does not have to look at it all the time due to a "burn in" effect with the eye. Because of that, the time you actually see the image can be very short. Experiments with showing silhouettes of airplanes to fighter pilots yield that some of them could still distinguish certain planes even if they were flashed for only 1/200 of a second.
So 25 FPS are enough to make a game look basically fluid, but 200 FPS can be useful to process rough and basic information. For example when quickly rotating the view and scanning for the muzzle flash of enemies firing at you.
And, as others pointed out already, more FPS means less latency. As example consider a muzzle flash the game internally creates 1 milliseccond after you last screen refresh. At 25 FPS, you will be able to actually see it after 40 milliseconds, at 200 FPS it only takes 5 milliseconds. This give you 35 milliseconds more time to process the information. But you still lose 4 milliseconds compared to a system with 1000 FPS.
Granted these milliseconds might not matter much for casually playing a shooter, for instance I still enjoyed playing Doom at about 20 FPS on an upgraded Amiga 2000 back then. But for competitive gamers these milliseconds might just be the edge they need to win some price money.
Slashdot Mirror
Nothing keeps them from designing TB4 with support for up to 8K (or maybe even more).
uBlock rejects 14 data collecting nasties. Didn't have those in the mid nineties.
Nobody forces Apple, Amazon, Google, Facebook etc to offer their products and services in the EU.
It has poor backwards compatibility (Python 3 != Python 2)
This is mostly an issue if you mix Python versions. These days reasonably modern shops tend to solely use Python 3.
(It is definitely annoying though if you never got the budget to migrate your legacy project from Python 2 to Python 3 or if you do operations work on some ancient box that only includes Python 2.)
it is single-threaded like JavaScript and it's pretty slow all around unless you code all your libraries in C (and throw away all the stuff that makes it Python)
Many classic Python usage scenarios simply use Python libraries that wrap C libraries. Most important everything related to data science and machine learning. There Python is used to express business logic and C libraries do the actual computation.
Apart from that, there are plenty of scenarios where Python is "fast enough" and you don't really care if you get the result in 0.001 seconds or 0.005 seconds.
It's really about picking the right tool for the right job. And sometimes faster development time is more important than faster execution time.
I'm sure the Amiga had killer apps somewhere that was comparable to anything on the x86 platform.
Not really, especially the office applications were lacking. Sure, that was BeckerText but it was even slower and less stable then Word at this time.
What if the internet had existed back then?
Actually the Amiga had a very active shareware scene based on disks. People used snailmail or went to shareware parties to exchange these disks.
And in 1992 Aminet started and remained the largest public archive of software for any platform until 1996.
So the lack of distribution channels wasn't an issue.
Mine that data to determine what women (really) want!
RTFA, it's right there in the pornhub insights blog entry. Especially look for "Most searched terms by gender" and "Most viewed category by gender".
In summary, (pornhub viewing) women are into lesbian, japanese, threesome and gangbang.
You don't need to register on github. Just scroll down on the manual page and you will see the directory listing and after that the rendered manual in Markdown. But granted, usability wise this is abysmal. Possibly they currently intend to make it accessible only for people who already have experience with github and other weird things until it has matured enough to be used by the general public.
A recent German article on a similar subject called out the current crop of AI and suggested to refer to it as "clever statistics" instead. IMHO this is spot on.
Scratch uses an approach similar to flow charts. If you're not to picky about the notation, it might be what you are looking for.
Corporate policy. It does make sense if large parts of your IT infrastructure already use MS SQL server, especially applications from external vendors. Adding another database increases costs and complexity for maintenance and support.
And it's inexpensive enough for the little money saved by using the free PostgreSQL not to make any noticeable difference. SQLite is very nice for certain applications but does not scale well (by design). MySQL still lacks support for many SQL features present even in SQLite and is bearable only through an ORM. I hear the finally thinking about adding support for common table expressions.
While my favorite would be Brazil, I found Coherence to be very effective in its minimalistic setting. From the IMDB summary: "Strange things begin to happen when a group of friends gather for a dinner party on an evening when a comet is passing overhead."
Cost is only part of the reason why replacement projects are avoided. Another major reason is the risk involved. Software developed in the 60s, 70s or 80s couldn't rely on many things we take for granted these days. Requirements engineering, robust libraries, development tools, testing mechanics and so on (warts and all) just were not quite there yet or did not exist at all.
So even if you have the budget to start a replacement project it's hard to predict if the new software will still work because nobody really knows what it's supposed to do. Sure, it's easy to pin down the common use cases, but it's almost impossible to be certain you also figured all the corner cases and special features that have been added over the decades.
Consequently it is very hard to find someone in upper management to bet his career on something that, at best, works as well as the existing system.
The places where I worked used a simple guide line: the author has to clean up trivial issues before submitting an item for review. In case of code, this means ensuring style conventions.
Which in practice is trivial for reasonably popular programming languages:
First, you rarely have to invent your own style conventions. Instead, use existing standards. For instance, there are standard coding conventions for Java and Python.
If some guide lines do not make sense for your shop, simply change them to fit your needs. For example, PEP8 recommends a maximum line width of 79 characters. However, all our developers work a horizontal resolution of 1920, so we allow 132 characters. We also changed naming conventions from the loud and baroque SOME_CONSTANT to the calm SomeConstant.
Next, there are tools to check these conventions such as CheckStyle and flake8. Often you can even find tools to reformat source code consistently or automatically fix trivial issues like missing blanks, for example autopep8.
Some shops inject these tools in the commit hook of their version management and make it reject any code that does not conform. Baring that, the review moderator is required to run the style checks on the review item. If it turns out that the author still left style issues in the code, the moderator returns the item to the author and requests to clean it up.
That way, the reviewers always get tidy code and can focus on comprehensibility, maintainability and algorithms.
.
AFAIK you don't have to. Using the Steam key is optional (or at least was for the Trine bundle, but I doubt it changed for this one).
Once purchased, you'll receive an email that tells you where to download the DRM free archives for the game.
Alternatively, you can use the Steam key and let Steam care about the rest. I've never used mine, but I can see that it's convenient for other gamers because of automatic updates, friend lists, achievements, the "join game" function and so on. So if much of your gaming revolves around Steam, the optional key seems to be a good thing.
Case in point: Hyper-G/Hyperwave. It was developed at about the same time as the WWW. It was technically pretty solid (renaming documents didn't break links, integrated search engine, powerful authoring tools) and even didn't use an abbreviation that took longer to pronounce the the full name.
AFAIR it soon moved out of the academia and was turned into a commercial product, so it basically did what the WIPO head suggested.
These days it doesn't even have an Wikipedia article anymore. According to its homepage, it found a niche for corporate intranets and now competes with SharePoint.
There are plenty of other early hypertext systems comparable to the WWW (going back to the 60ties). I seem to recall that Douglar Engelbart's NLS was heavily patented, though I cannot find a reference for this right now. (Though partially these systems certainly failed because of insufficient technology and lack of a target group. You can't blame everything on patents).
Good point. Seems they need to find a way to fold ships, too.
Similar to bikes, planes and (to some extent) cars.
The gist of article seems to be that for many tasks people should combine the powerful Unix standard commands like find, grep, xargs, sed, etc instead of writing dedicated programs in lower level languages such as Ruby, Python, Java etc. This idea is not new, and many of the people around here have heard it 15 or more years ago. Being a developer, I always liked the perspective of having to write lesser code.
However, the Unix command line and shell script approach never really worked for me, especially if other people in the team wrote them. The main reasons for that are:
All of this could be overcome by measures such as checking $?, redirecting stderr, using temporary files, configuring encodings properly, documentation comments and so on. However, this rarely ever happens in practice.
For the past couple of years I have been using ant for many tasks formerly delegated to shell scripts. Its main advantages are:
Of course it's not perfect. For example, it uses XML and consequently contains some syntactic noise, it lacks advanced string operations, there are no pipes and sometimes seemingly trivial things result in a lot of messing around with properties. Nevertheless I rarely see a need to write shell scripts anymore except for simple launchers. YMMV but despite ant initially being a build tool for Java developers, we use it for many sysadmin-like tasks with great success and a small amount of development time.
In order to gain all this information, the only group of people you need access to are the secretaries.
This should read 1280x720 obviously.
For instance, get a 27 inch at 2560x1440 and set the resolution to 1380x720, thus every pixel on the screen takes 2x2 pixels on the monitor. This gives you a sharp picture at resolution that is easy to handle for aging eyes.
A good movie based on MMORPG game IP has already been made: Ben X revolves around the game Archlord and the real life of some players. Think Rainman meets WoW.
Additionally, a wired mouse is easier to find when buried somewhere in the clutter on your desk: just follow the cable back from where it is connected to your computer.
I still have an Amiga 2000 standing around from 1989 with a 8 Mhz 68000 CPU and 7 MB RAM. Funny thing about it is that it can run the relatively modern AmigaOS 3.1, for which reasonably well working graphical web browsers exist. Occasionally I fire it for fun just to demonstrate that 80's hardware can show web pages in a semi decent way. Configure it to run on a 640x400 screen with 8 shades of grey and it still shows most of the modern web sites that have some sort of accessibility fall back. It can do tables and basic CSS, so in some cases the results are almost indistinguishable from what you see on a modern browser. Of course it is awfully slow and needs several seconds to render a medium sized PNG image.
It's particular cool to show it too kids that think you need GHz's and GB's to surf the web.
According to the IMDB FAQ there seems to be some disagreement on this:
Personally I can't think of any Tarantino movie I'd call "original" though some of them I find reasonably amusing.
There are to different issues at work which are well documented in literature and backup up with experiments:
So 25 FPS are enough to make a game look basically fluid, but 200 FPS can be useful to process rough and basic information. For example when quickly rotating the view and scanning for the muzzle flash of enemies firing at you.
And, as others pointed out already, more FPS means less latency. As example consider a muzzle flash the game internally creates 1 milliseccond after you last screen refresh. At 25 FPS, you will be able to actually see it after 40 milliseconds, at 200 FPS it only takes 5 milliseconds. This give you 35 milliseconds more time to process the information. But you still lose 4 milliseconds compared to a system with 1000 FPS.
Granted these milliseconds might not matter much for casually playing a shooter, for instance I still enjoyed playing Doom at about 20 FPS on an upgraded Amiga 2000 back then. But for competitive gamers these milliseconds might just be the edge they need to win some price money.