Imagine if you bought the LOTR books. You read them and enjoy them but then you find out that Tolkien didn't actually write those books but it was someone else writing in the same style with all the same names and places.
In informal usage by laymen, "bug" might mean most anything. But any insect biologist, (and certainly any professional organization thereof) will tell you that "bug" properly refers only to those insects in the order Hemiptera (cicadas, aphids, planthoppers, etc.) Wait a second... so the Moth was not the first bug found in a computer?
Considering the number of people who deny (orquestion) that Jesus was an historical figure (sorry, best references I could find in a bit of searching), you might want to use a more accurate term than `real' to avoid appearing to question his historical existence.
I like this --- you'd rather impose what you *think* are someone's beliefs on him, than let him make his own decisions. Freedom begins with the right to be a hypocrite.
It's sometimes easier in case-insensitive languages. When I was 16, I'd name my VB functions in Camel Case, and then type in the calls all lower-case. If they were still all-lower-case after I hit Enter, I knew I'd mis-spelled them.
The program I'm looking at now was written in perl. The one two windows behind that was written mostly in Lisp. The program in the terminal at lower right is perl invoking Haskell (cheating, I wrote both). I've got NeoOffice (Java IIRC) running somewhere. And, this being a crappy NeXT clone I'm running, I'm sure there's Objective C around somewhere.
I understand where you're coming from --- when I think about the proprietary library (thankfully only one!) we use. You might want to look into open source libraries (or languages, such as Python), instead. Saves time without/any/ of the disadvantages you name.
Nice way to jump horses in mid-stream. We no longer care about the user at all; now, we just care about management.
I'm sorry; I don't care about management, or its fetishistic belief that it's always and everywhere better to hire a crappy programmer you can replace easily than a good programmer you might have to work harder to replace, or the twin belief that it's always and everywhere better to use crappy methodology (e.g. new/delete) that everyone understands than good methodology (e.g. GC) that management is irrationally afraid of. As a software house, your programmers and your methodology are your capital as much as your code, and you have to be willing to invest in them. That is why your management consultants call your programmers âoehuman capitalâ, not to demean them.
Ideas like those you spout are believed by management not because they've been proven in practice, but because they are repeated by worthless trade magazines. Which makes believing them (let alone acting on them) more stupid, not less.
If you follow the advice of âoeget the job done the best possible wayâ, you'll also know the answer. Good programming advice is user-centric, because that's what supplied the selective pressure to allow it to evolve. But the only time I've every seen âcare about the userâ(TM) actually applied, it's a priori advice that contradicts sound development tradition. I trust the development tradition more.
Caring about the users is fine, but last I checked, they were paying me by the day. The faster I get the job done, the faster they get their app. I can code it up in C in a year, or in Haskell in two months; which serves the user better?
Where I work, the software changes fast enough, I can already show my manager the results of design improvements I put in only a few months ago. That's one way to do this: stay in communication, incrementally improve things, and make sue the next layer up knows every time an improvement made your life easier or got a feature added or bug squashed sooner.
I also make a point of reminding them, every time we see a bug caused by a system issue I want to fix. That helps them see the ROI, too.
Slashdot Mirror
So we agree the purpose of a patent is to create a monopoly. But yet you claim this kind of monopoly doesn't put your competitors out of business...
Explain to me again --- how do you think patents work?
Imagine if you bought the LOTR books. You read them and enjoy them but then you find out that Tolkien didn't actually write those books but it was someone else writing in the same style with all the same names and places.
Oh, you mean like the Silmarillion?
Poison pill.
Sexist.
Considering the number of people who deny (or question) that Jesus was an historical figure (sorry, best references I could find in a bit of searching), you might want to use a more accurate term than `real' to avoid appearing to question his historical existence.
Interesting. You find a (nearly) infinite number of universes easier to believe in than God?
I like this --- you'd rather impose what you *think* are someone's beliefs on him, than let him make his own decisions. Freedom begins with the right to be a hypocrite.
Ooh, I know this one! The strongest feature possessed by every language is Turing-completeness.
It's sometimes easier in case-insensitive languages. When I was 16, I'd name my VB functions in Camel Case, and then type in the calls all lower-case. If they were still all-lower-case after I hit Enter, I knew I'd mis-spelled them.
The program I'm looking at now was written in perl. The one two windows behind that was written mostly in Lisp. The program in the terminal at lower right is perl invoking Haskell (cheating, I wrote both). I've got NeoOffice (Java IIRC) running somewhere. And, this being a crappy NeXT clone I'm running, I'm sure there's Objective C around somewhere.
lambda will be in a library? How does that work?
I understand where you're coming from --- when I think about the proprietary library (thankfully only one!) we use. You might want to look into open source libraries (or languages, such as Python), instead. Saves time without /any/ of the disadvantages you name.
If they're meant to be computationally convenient, why do they have so few prime factors?
Put them together hard enough, and you don't have 4 apples any more.
Or, ask me how to prove that 4 -1 = 5 sometime.
On the scale of programmability, emacs > ed > vi.
On the scale of number of modes, vi > ed > emacs.
I don't see the issue, here...
Pi is defined as twice the least positive number at which cos is 0...
Also as the least positive number at which cos is -1.
Also as the least positive number at which sin is 0.
Also as 1/2 the period of cos and sin.
Also as 1/2i the period of e^x.
Also as the least positive solution to the equation e^{xi} = -1. (This is redundant with definitions 2 and 3, in conjunction).
I may have forgotten a few...
Nice way to jump horses in mid-stream. We no longer care about the user at all; now, we just care about management.
I'm sorry; I don't care about management, or its fetishistic belief that it's always and everywhere better to hire a crappy programmer you can replace easily than a good programmer you might have to work harder to replace, or the twin belief that it's always and everywhere better to use crappy methodology (e.g. new/delete) that everyone understands than good methodology (e.g. GC) that management is irrationally afraid of. As a software house, your programmers and your methodology are your capital as much as your code, and you have to be willing to invest in them. That is why your management consultants call your programmers âoehuman capitalâ, not to demean them.
Ideas like those you spout are believed by management not because they've been proven in practice, but because they are repeated by worthless trade magazines. Which makes believing them (let alone acting on them) more stupid, not less.
If you follow the advice of âoeget the job done the best possible wayâ, you'll also know the answer. Good programming advice is user-centric, because that's what supplied the selective pressure to allow it to evolve. But the only time I've every seen âcare about the userâ(TM) actually applied, it's a priori advice that contradicts sound development tradition. I trust the development tradition more.
Caring about the users is fine, but last I checked, they were paying me by the day. The faster I get the job done, the faster they get their app. I can code it up in C in a year, or in Haskell in two months; which serves the user better?
Where I work, the software changes fast enough, I can already show my manager the results of design improvements I put in only a few months ago. That's one way to do this: stay in communication, incrementally improve things, and make sue the next layer up knows every time an improvement made your life easier or got a feature added or bug squashed sooner.
I also make a point of reminding them, every time we see a bug caused by a system issue I want to fix. That helps them see the ROI, too.
No, no, no. All Linux apps start with g!
How dare you imply Wikipedia might be biased!
Does X work when you ssh remotely? I suspect you forgot the -X flag.