Bullshit. PHP doesn't load everything into its core: it has a well-developed system for managing optional extensions (PEAR).
"Core" extensions are the ones that come with PHP.. This is pretty standard terminology. You just can't be bothered to look it up. Then why reply at all?
As they say: free software is only free if you don't value your time. So free software that saves me from having to spend time on things I'm not interested in spending time on is of huge value.
For logged-in users, put a 'hide' button next to every mention of a story. When clicked, no more links to the story will be shown.
The quality of the stories appears to have improved sharply. If this continues, I will return to reading Slashdot on a regular basis.
The problem is that organizing stuff and keeping it organized requires a tremendous continuous investment of time on the part of the users no matter how much support you get from software. There is no magic bullet.
Something flat and amorphous at least stands a chance of being used at all. Wikipedia has a couple of post-hoc information structuring projects; I think it's a better approach than overdoing organization before the content is entered.
So if you won't need to merge much, and development is going to be pretty much linear, SVN is OK.
If not, use Git or another distributed VCS.
There is no excuse for using CVS for new projects these days. SVN improves on it in every possible way.
*nod*
I once tried Debian, intending to switch to it, but I never got beyond the initial installation attempt. The abrasiveness on #debian was my primary reason for giving up and never looking back. (Hint: pick a Debian derivative.)
This doesn't answer the question at all.
The intent of the question is: why won't a language extension or library do?
This answer suggests they never even considered the option.
"I stopped playing freeciv once they stopped being turn based."
That should read: "I stopped playing Freeciv before I understood how it works." Freeciv never "stopped being turn-based".
In Freeciv, all human players move concurrently, during the same turn.
It was always this way; trying to make this work was the reason for creating it.
AI players were added later. Human and AI players do take turns: AI players never do anything during a turn, they only act at the start and end of a turn.
They are a lot easier to implement that way. But the difference has been confusing novice players ever since AI players existed.
You could have looked this up in the manual.
My guess is that instead you played a few games on your own, against AI players, then got your big cold shower in the first game where a fellow human player approached you in battle. I'm not sure what you were expecting; you must have been aware that human players were moving concurrently, so why did you expect things to somehow be different in battle? But I think I was just as confused as you about the game mechanics after my first Freeciv games against other humans. It was a pretty rough experience. (And it still is. I never got good at it.)
So your experience isn't exactly unique. And you're not exactly unique in wanting human players to take turns, either. What is unique is your conclusion that Freeciv changed between the games you played against AI and the games you played against humans and dropped being turn-based. It did no such thing. As a matter of fact, it did exactly the opposite: in 2.2, and option was finally added that requires human players to take turns. You could have found that in the manual, too: phasemode.
The problem is that Wikipedia editors require "published" references, which typically means "published on paper" - which is a crazy criterion for software.
Never attribute to malice what is adequately explained by ignorance.
Paradoxically, the ignorance in this case is a result of the opposite: too much knowledge!
Programmers tend to think in code. Many have never had the need to think about the problem they're creating code to solve in any other way than in terms of code. To inexperienced programmers, code may be the *only* way they have encountered to think about software. Consequently, they may have a lot of trouble envisaging other ways to talk about what the software does, how it does it, or why it does it; let alone imagining how such other ways could be useful.
That is tunnel vision, but not necessarily anal retentiveness - it may simply be a result of lack of exposure to situations in which the level of detail that code provides is more of a hindrance than an advantage, such as teaching other people how to use the software.
Interesting, but you are discussing a different issue. The article is about worse kinds of threats than "go fuck yourself" and it is not about workplace behavior.
Circuits and GUIs are graphical by themselves. To specify them graphically is to specify them in their own terms. Such graphical representations are natural and compact. They are not really abstractions. (For circuits, their behavior can be added to the graphics using a minimal set of graphical conventions. For GUIs, this is not possible; hence, the behavior of GUIS isn't usually specified in a graphical way.)
Most things in programming are not graphical. C functions aren't. Algorithms aren't. Data structures aren't. Databases aren't. Contracts on what a function may or may not do aren't. Communication protocols aren't. Etc.
Graphical languages can be used as an aid in explaining or specifying these things, but the results will be symbolic representations, just like textual representations are. This is a fundamentally different way of using graphics.
Such symbolic graphical languages certainly have their use (UML diagrams, database model diagrams, state machines, etc.) but they take up a lot more space than equivalent textual representations. Take natural numbers, for instance. It's perfectly OK to replace them with a graphical representation (dots and circles on a screen) when introducing them, but only a textual representation such as the decimal representation will scale to larger sizes. This holds for pretty much all aspects of programming. For instance, when specifying program flow logic, a flowchart is a very space-inefficient way to do so when compared to textual code. It also takes much more time to create. There is no way to specify the equivalent of 10 million lines of code in less than 1 million pages of flowcharts, and they would cover only the control flow, not all other things that the code specifies. Therefore, graphics will only be used for those aspects of a program that are easy to visualize, and usually, only as a secondary representation, next to a textual one. Text is a lot more compact and usable.
There is no such thing as 'on your own time' when you're doing work for a company: they are responsible for the results and the working conditions (proper payment, working environment, insurance, supervision, etc.) Not living up to those responsibilities is illegal. The company can ask you whether you're willing to put in more hours at the same salary, and if you agree, that arrangement may be legal. They cannot ask you to do work 'on your own time'.
Slashdot Mirror
I do this, too. I do it on sites that support multiple answers to the same question. The idea is to have a range of different answers to pick from.
Bullshit. PHP doesn't load everything into its core: it has a well-developed system for managing optional extensions (PEAR). "Core" extensions are the ones that come with PHP.. This is pretty standard terminology. You just can't be bothered to look it up. Then why reply at all?
Please note that the article claims nothing of the kind.
is "Bash Unix"?
"Bash Unix" is lingo IT for "interpreter line command".
See? It wasn't that hard to figure out.
As they say: free software is only free if you don't value your time. So free software that saves me from having to spend time on things I'm not interested in spending time on is of huge value.
For logged-in users, put a 'hide' button next to every mention of a story. When clicked, no more links to the story will be shown. The quality of the stories appears to have improved sharply. If this continues, I will return to reading Slashdot on a regular basis.
The same thing happened on Wikipedia. It seems rather inevitable.
Still, I don't think it required more than a short email exchange.
I think you can have nation-specific technology trees with custom rulesets. That would allow you to do this.
The problem is that organizing stuff and keeping it organized requires a tremendous continuous investment of time on the part of the users no matter how much support you get from software. There is no magic bullet. Something flat and amorphous at least stands a chance of being used at all. Wikipedia has a couple of post-hoc information structuring projects; I think it's a better approach than overdoing organization before the content is entered.
So if you won't need to merge much, and development is going to be pretty much linear, SVN is OK. If not, use Git or another distributed VCS. There is no excuse for using CVS for new projects these days. SVN improves on it in every possible way.
I fell on my knee and cleaned and bandaged the wound all by myself. Anyone can do it with some googling.
I'm so glad you don't work in education.
I have a name for people with your attitude. Do you?
*nod* I once tried Debian, intending to switch to it, but I never got beyond the initial installation attempt. The abrasiveness on #debian was my primary reason for giving up and never looking back. (Hint: pick a Debian derivative.)
In Britain, 'Europe' is often used to mean the continent, excluding Britain.
This doesn't answer the question at all. The intent of the question is: why won't a language extension or library do? This answer suggests they never even considered the option.
The sqldf package helps me out with this.
In Freeciv, all human players move concurrently, during the same turn. It was always this way; trying to make this work was the reason for creating it.
AI players were added later. Human and AI players do take turns: AI players never do anything during a turn, they only act at the start and end of a turn. They are a lot easier to implement that way. But the difference has been confusing novice players ever since AI players existed.
You could have looked this up in the manual. My guess is that instead you played a few games on your own, against AI players, then got your big cold shower in the first game where a fellow human player approached you in battle. I'm not sure what you were expecting; you must have been aware that human players were moving concurrently, so why did you expect things to somehow be different in battle? But I think I was just as confused as you about the game mechanics after my first Freeciv games against other humans. It was a pretty rough experience. (And it still is. I never got good at it.)
So your experience isn't exactly unique. And you're not exactly unique in wanting human players to take turns, either. What is unique is your conclusion that Freeciv changed between the games you played against AI and the games you played against humans and dropped being turn-based. It did no such thing. As a matter of fact, it did exactly the opposite: in 2.2, and option was finally added that requires human players to take turns. You could have found that in the manual, too: phasemode.
The problem is that Wikipedia editors require "published" references, which typically means "published on paper" - which is a crazy criterion for software.
Never attribute to malice what is adequately explained by ignorance.
Paradoxically, the ignorance in this case is a result of the opposite: too much knowledge!
Programmers tend to think in code. Many have never had the need to think about the problem they're creating code to solve in any other way than in terms of code. To inexperienced programmers, code may be the *only* way they have encountered to think about software. Consequently, they may have a lot of trouble envisaging other ways to talk about what the software does, how it does it, or why it does it; let alone imagining how such other ways could be useful.
That is tunnel vision, but not necessarily anal retentiveness - it may simply be a result of lack of exposure to situations in which the level of detail that code provides is more of a hindrance than an advantage, such as teaching other people how to use the software.
Interesting, but you are discussing a different issue. The article is about worse kinds of threats than "go fuck yourself" and it is not about workplace behavior.
Don't you own a cell phone?
I think there is an important distinction here.
Circuits and GUIs are graphical by themselves. To specify them graphically is to specify them in their own terms. Such graphical representations are natural and compact. They are not really abstractions. (For circuits, their behavior can be added to the graphics using a minimal set of graphical conventions. For GUIs, this is not possible; hence, the behavior of GUIS isn't usually specified in a graphical way.)
Most things in programming are not graphical. C functions aren't. Algorithms aren't. Data structures aren't. Databases aren't. Contracts on what a function may or may not do aren't. Communication protocols aren't. Etc.
Graphical languages can be used as an aid in explaining or specifying these things, but the results will be symbolic representations, just like textual representations are. This is a fundamentally different way of using graphics.
Such symbolic graphical languages certainly have their use (UML diagrams, database model diagrams, state machines, etc.) but they take up a lot more space than equivalent textual representations. Take natural numbers, for instance. It's perfectly OK to replace them with a graphical representation (dots and circles on a screen) when introducing them, but only a textual representation such as the decimal representation will scale to larger sizes. This holds for pretty much all aspects of programming. For instance, when specifying program flow logic, a flowchart is a very space-inefficient way to do so when compared to textual code. It also takes much more time to create. There is no way to specify the equivalent of 10 million lines of code in less than 1 million pages of flowcharts, and they would cover only the control flow, not all other things that the code specifies. Therefore, graphics will only be used for those aspects of a program that are easy to visualize, and usually, only as a secondary representation, next to a textual one. Text is a lot more compact and usable.
There is no such thing as 'on your own time' when you're doing work for a company: they are responsible for the results and the working conditions (proper payment, working environment, insurance, supervision, etc.) Not living up to those responsibilities is illegal. The company can ask you whether you're willing to put in more hours at the same salary, and if you agree, that arrangement may be legal. They cannot ask you to do work 'on your own time'.