Your comment is well-put. Sadly, the languages popular with IT shops now are strongly/manifestly typed -- meaning no common Sequence implementation exists.
That IS a good question. In Unix, creating a new process and using IPC is so simple, you almost don't need threads. In fact, before POSIX threads, Linux threads WERE processes. The advantage you got over threads was cleaner separation of memory and variables -- always worth a lot when programming in three-star C. The disadvantage, of course, was that same separation meant that everything you wanted to share had to go through IPC.
Definitely true. They are ready to drop everything and head out the door at 5pm Friday (provided there are no "production issues") and not think about computers again until 9am Monday. The idea of software development as a profession that requires continuous learning is foreign to them.
I've never actually written any COBOL myself, but here's what I've learned from trying to teach Java to former mainframe developers.
COBOL is actually remarkably like wordy assembly language
The typical mainframe programmer, being steeped in COBOL, will think of everything in "records".
Mainframes are case-preserving but case-insentive. Like DOS, a token can be any mixture of case an it will work. Thus, a mainframer might wonder why 'PRINTF' doesn't work for 'printf'.
On the same topic, a mainframer will assume that something like the Java type 'Account' and the variable 'account' actually don't distinguish anything, and will be confused when the compiler refuses to assign to a type.
MOVE CORRESPONDING is COBOL's big hammer. It will take all the values of the elements of one record and copy them to the "corresponding" fields of another record. There is nothing like type-checking for this. This will cause mainframers to be confused about why you can't assign a linked list to an array and have it "just work".
Not that mainframers will grasp "linked list" or "array". Actually, they won't really get any of what we call the standard data structures and algorithms learned in the first year of any CS program.
COBOL programs have no scoping rules. EVERYTHING is global. Thus, a mainframe programmer won't understand why an assignment way over in some little function in another library to a variable called "date" won't affect the "date" value in the code everywhere.
The author is recommending the death penalty based on monetary damages -- so does he agree CEOs like Ken Lay and Dennis Kozlowski should be at the head of the line for the chair?
FTP Software, a little company in N. Andover, MA, is correct. One of the founders was John Romkey who wrote the RFC for SLIP. They later got bought by Chameleon makers NetManage.
The guts of their products in and around the TCP/IP stack were well-engineered, for an era when TSRs were standard and memory below 640K being precious.
There was a little company called FTP Software (later bought by Chameleon) that made a much better TCP/IP stack, originally for DOS, then as a VxD for Windows 3.1 to 95. It was faster, more compliant, and smaller, and it worked with more drivers (remember crynwyr?).
When MS started shipping their own TCP/IP stack, which was a crappy port of BSD's code that had all kinds of issues, my employer and I gather most other customers dropped FTP Software's product practically overnight. The built-in MS stack was "free" as in beer, so the need to pay for TCP/IP, regardless of technical quality, couldn't easily be justified.
It seems that by adopting existing code they didn't need to pay for (although I guess they did) and didn't need to share, MS was able to make Windows workable on TCP/IP without the need to share or work with anyone else. The fact that it resulted in competing products disappearing from the world was probably just a bonus.
Sure, but demanding that estimates be fudged to fit a pre-determined schedule is clearly management incompetence. The argument I'm making -- based on real experience -- is that when a developer consistently makes optimistic and unrealistic estimates it's still management's fault. One, for believing the estimates and continuing to believe them when demonstratably wrong, two, for hiring and keeping an incompetent.
This isn't hard. You don't need a complicated tool. In fact, all you need is a bag of Gummy Bears. Take the features you have left to do, and divide them up into small tasks -- 3 days each, say, of uninterrupted time. Make each task equal to 1 gummy bear. Count out gummy bears totalling the number of tasks left to do. Put them all in a bowl. When a developer finishes a task, remove a gummy bear. Enjoy. Any time you want to know how much time is left, count out the remaining gummy bears and multiply by 3, or however long your standard task length is, and that's how many (uninterrupted) workdays until you are done. After a couple of weeks of checking the numbers daily, you will be able to get a trend. A simple Excel spreadsheet will be able to determine, based on the ratio of tasks completed to actual days, how many gummy bears/week your team is completing, and how many more weeks/days, based on that trend, until final delivery.
If the only time estimation is done is at the beginning of a project, that's a problem, too. Experience and research shows the estimate will be off by at least 2x. That is, a project estimated at 1 year could take 2 years, or could go 6 months.
What kind of insane person looks at a 1-year project after 3 months, sees it's failed to achieve what it had planned for those 3 months, and then just expects to make up the loss without pain? I don't know if that is more, or less, insane than doing a schedule once and then never looking at it again for a year.
Again, when developers make estimates and fail to meet them, management must adjust, and not by having everyone work double overtime.
Right. I left out an important point. Estimating is hard. Estimating something you haven't done before is nearly impossible. Estimating something neither you nor anyone else has done is completely impossible.
When management asks for that kind of an estimate, the only reasonable, professional, response is, "I don't know, how long can you give me to research the problem to determine the scope?". Management needs to accept that, and be prepared to respond if the estimate comes back "too long".
In games development, (and plenty of other fields) management doesn't accept that answer. The deadline is set at next Thanksgiving. It's impossible for them grasp the concept that some things can't be estimated.
Management's "solution"-- just push as hard as possible to get what they want, and punish the failures. Reality intrudes regardless, games get delayed or features dropped. Sane people would plan and prioritize features. If task X can't get done in time T, either that feature gets dropped or another, lower priority, feature is dropped to give time to finish task X. There is no "work twice as many hours so you can get both done".
Similarly for unanticipated stuff that comes. Change happens. A perfectly reasonable estimate that can be agreed on by multiple programmers can turn out to be wrong when something else comes up. It's no use railing against fickle customers or glitchy hardware and libraries. But that's another essay.
Quite true. And one of the mistakes management makes is hiring people who can't or won't estimate correctly. On prefectly reasonably well-run projects I've been on, things don't get done because some hot-shot lone coder tells management he (and it's always been guys in my experience) can do in half a day what will actually take 3 days from start to completion of integration and testing. Sometimes they just plain don't actually know how long things take. Often, the only portion of the task they think of as taking time is typing time. These wishful thinkers typically type in the change they think is right and check it in and call it done.
If this sounds more like the coder's fault, let me assure you it's not. Miss an estimate once or twice, OK. Nobody is perfect, you learn and move on. Consistently fail to estimate correctly and management needs to take notice. Either pull that person out of the critical path (so missed deadlines don't hurt so bad) or have someone else who has shown better estimating ability size the task and use that number.
If, after 12-18 months of work, management is still letting someone who makes committments he can't keep blow the project's schedule, that's pretty much professional malpractice in any real profession.
Yes, if you design as you go, you get something like a beehive, a termite nest, or an anthill. And we know how how badly those meet the needs of their builders. Oh wait...
A good, secure password does not automatically equate to hard-to-remember. It takes some effort, but it's possible to come up with memorable good passwords. Given the choice I'd rather put thought into coming up with one good strong memorable password that I don't have to keep changing, and use it to protect all my hard-to-remember passwords that I'm required to change all the time.
Defined that way by the language standard and will always be that way on any platform past, present, and future. That's why it's platform-neutral, because you don't have to deal with ridiculous low-level issues like the size of standard datatypes. All primitive types are fixed by the language standard. These sizes do not change from one machine architecture to another (as do in most other languages). This is one of the key features of the language that makes Java so portable.
Need more than 2,147,483,647? Try long -- 9,223,372,036,854,775,807. Still not big enough? java.math.BigInteger is arbitrary precision.
Although programming in Java has lost some of its charm for me, I never ever again want to have to program in a language where I don't know from one platform to the next whether or not a particular bit of arithmetic will overflow.
That's just about the only thing that comes to mind the JBuilder base edition would bring to Eclipse that it doesn't already have, and do better. In any case, having used JBuilder for a long while before switching to Eclipse (and having a brief fling with IntelliJ IDEA), I really don't see myself switching back to the Borland/Inprise "experience". If the Register got the story right, which some are questioning.
It wouldn't surprise me if there already were a plugin for Brief keybindings.
Slashdot Mirror
Your comment is well-put. Sadly, the languages popular with IT shops now are strongly/manifestly typed -- meaning no common Sequence implementation exists.
That IS a good question. In Unix, creating a new process and using IPC is so simple, you almost don't need threads. In fact, before POSIX threads, Linux threads WERE processes. The advantage you got over threads was cleaner separation of memory and variables -- always worth a lot when programming in three-star C. The disadvantage, of course, was that same separation meant that everything you wanted to share had to go through IPC.
Only if you know where all the lineprinter porn resides!
Definitely true. They are ready to drop everything and head out the door at 5pm Friday (provided there are no "production issues") and not think about computers again until 9am Monday. The idea of software development as a profession that requires continuous learning is foreign to them.
The author is recommending the death penalty based on monetary damages -- so does he agree CEOs like Ken Lay and Dennis Kozlowski should be at the head of the line for the chair?
FTP Software, a little company in N. Andover, MA, is correct. One of the founders was John Romkey who wrote the RFC for SLIP. They later got bought by Chameleon makers NetManage. The guts of their products in and around the TCP/IP stack were well-engineered, for an era when TSRs were standard and memory below 640K being precious.
You mean, like GNUstep and Project Center?
There was a little company called FTP Software (later bought by Chameleon) that made a much better TCP/IP stack, originally for DOS, then as a VxD for Windows 3.1 to 95. It was faster, more compliant, and smaller, and it worked with more drivers (remember crynwyr?).
When MS started shipping their own TCP/IP stack, which was a crappy port of BSD's code that had all kinds of issues, my employer and I gather most other customers dropped FTP Software's product practically overnight. The built-in MS stack was "free" as in beer, so the need to pay for TCP/IP, regardless of technical quality, couldn't easily be justified.
It seems that by adopting existing code they didn't need to pay for (although I guess they did) and didn't need to share, MS was able to make Windows workable on TCP/IP without the need to share or work with anyone else. The fact that it resulted in competing products disappearing from the world was probably just a bonus.
Gosh, I could google it faster than slashdot will let me finish a post: http://catb.org/~esr/jargon/html/P/pumpking.html
Q: What is the contour integral of Western Europe?
A: 0, because all the Poles are in Eastern Europe.
More like, if somone gives me a brand new mansion, but keeps the key (and all the doors and windows are locked), well gee. Thanks for nothing.
Sure, but demanding that estimates be fudged to fit a pre-determined schedule is clearly management incompetence. The argument I'm making -- based on real experience -- is that when a developer consistently makes optimistic and unrealistic estimates it's still management's fault. One, for believing the estimates and continuing to believe them when demonstratably wrong, two, for hiring and keeping an incompetent.
This isn't hard. You don't need a complicated tool. In fact, all you need is a bag of Gummy Bears. Take the features you have left to do, and divide them up into small tasks -- 3 days each, say, of uninterrupted time. Make each task equal to 1 gummy bear. Count out gummy bears totalling the number of tasks left to do. Put them all in a bowl. When a developer finishes a task, remove a gummy bear. Enjoy. Any time you want to know how much time is left, count out the remaining gummy bears and multiply by 3, or however long your standard task length is, and that's how many (uninterrupted) workdays until you are done. After a couple of weeks of checking the numbers daily, you will be able to get a trend. A simple Excel spreadsheet will be able to determine, based on the ratio of tasks completed to actual days, how many gummy bears/week your team is completing, and how many more weeks/days, based on that trend, until final delivery.
If the only time estimation is done is at the beginning of a project, that's a problem, too. Experience and research shows the estimate will be off by at least 2x. That is, a project estimated at 1 year could take 2 years, or could go 6 months.
What kind of insane person looks at a 1-year project after 3 months, sees it's failed to achieve what it had planned for those 3 months, and then just expects to make up the loss without pain? I don't know if that is more, or less, insane than doing a schedule once and then never looking at it again for a year.
Again, when developers make estimates and fail to meet them, management must adjust, and not by having everyone work double overtime.
Right. I left out an important point. Estimating is hard. Estimating something you haven't done before is nearly impossible. Estimating something neither you nor anyone else has done is completely impossible.
When management asks for that kind of an estimate, the only reasonable, professional, response is, "I don't know, how long can you give me to research the problem to determine the scope?". Management needs to accept that, and be prepared to respond if the estimate comes back "too long".
In games development, (and plenty of other fields) management doesn't accept that answer. The deadline is set at next Thanksgiving. It's impossible for them grasp the concept that some things can't be estimated.
Management's "solution"-- just push as hard as possible to get what they want, and punish the failures. Reality intrudes regardless, games get delayed or features dropped. Sane people would plan and prioritize features. If task X can't get done in time T, either that feature gets dropped or another, lower priority, feature is dropped to give time to finish task X. There is no "work twice as many hours so you can get both done".
Similarly for unanticipated stuff that comes. Change happens. A perfectly reasonable estimate that can be agreed on by multiple programmers can turn out to be wrong when something else comes up. It's no use railing against fickle customers or glitchy hardware and libraries. But that's another essay.
Quite true. And one of the mistakes management makes is hiring people who can't or won't estimate correctly. On prefectly reasonably well-run projects I've been on, things don't get done because some hot-shot lone coder tells management he (and it's always been guys in my experience) can do in half a day what will actually take 3 days from start to completion of integration and testing. Sometimes they just plain don't actually know how long things take. Often, the only portion of the task they think of as taking time is typing time. These wishful thinkers typically type in the change they think is right and check it in and call it done.
If this sounds more like the coder's fault, let me assure you it's not. Miss an estimate once or twice, OK. Nobody is perfect, you learn and move on. Consistently fail to estimate correctly and management needs to take notice. Either pull that person out of the critical path (so missed deadlines don't hurt so bad) or have someone else who has shown better estimating ability size the task and use that number.
If, after 12-18 months of work, management is still letting someone who makes committments he can't keep blow the project's schedule, that's pretty much professional malpractice in any real profession.
Yes, if you design as you go, you get something like a beehive, a termite nest, or an anthill. And we know how how badly those meet the needs of their builders. Oh wait...
A good, secure password does not automatically equate to hard-to-remember. It takes some effort, but it's possible to come up with memorable good passwords. Given the choice I'd rather put thought into coming up with one good strong memorable password that I don't have to keep changing, and use it to protect all my hard-to-remember passwords that I'm required to change all the time.
Agree. Ben Goodger comes off as an arrogant ass in this one.
> the int is still 32 bits
Defined that way by the language standard and will always be that way on any platform past, present, and future. That's why it's platform-neutral, because you don't have to deal with ridiculous low-level issues like the size of standard datatypes. All primitive types are fixed by the language standard. These sizes do not change from one machine architecture to another (as do in most other languages). This is one of the key features of the language that makes Java so portable.
Need more than 2,147,483,647? Try long -- 9,223,372,036,854,775,807. Still not big enough? java.math.BigInteger is arbitrary precision.
Although programming in Java has lost some of its charm for me, I never ever again want to have to program in a language where I don't know from one platform to the next whether or not a particular bit of arithmetic will overflow.
That's just about the only thing that comes to mind the JBuilder base edition would bring to Eclipse that it doesn't already have, and do better. In any case, having used JBuilder for a long while before switching to Eclipse (and having a brief fling with IntelliJ IDEA), I really don't see myself switching back to the Borland/Inprise "experience". If the Register got the story right, which some are questioning. It wouldn't surprise me if there already were a plugin for Brief keybindings.
The fine structure constant might not be constant either. That should really cook your noodle.
The only "natural" standards I know of are things like C, e, pi, alpha (the fine structure constant), and the charge of an electron.
Pretty good links. I found the tips and tricks on the CocoaDev Wiki invaluable in my work on the Objective-C port of FIT.