Next smallest and most regular syntax for a useful language is probably smalltalk, but that's too long to post here. It's worth noting that smalltalk (particularly its first-class statement blocks) was a heavy influence on ruby. Smalltalk also gets close to hitting the 'nice' requirement, which IMO Lisp is a long way from.
Hibernate allows you to use straight jdbc calls which is what most people end up doing if they have a real world app and need to optimize the queries.
Or you can use a stored procedure or sql query accessed via a hibernate named query. Avoids the need to get your hands dirty with JDBC, but allows you complete control over the query that's executed. Best of both worlds.
If you and the client had sat down at the beginning of the project and described what the application must do, must not do, and what the client would like it to do (or not to do) would you have realized before getting "married to this object model framework" that some of the requirements would be hard or impossible to satisfy?
In my experience, that only works on the rare occasions where the client actually understands their own requirements. More often than not, I end up telling the client what they need. In something like 90% of cases there's some critical point that neither of us understood in the beginning of the project that the client only realizes when he's sitting in front of the software, trying to actually use it for real business purposes. No amount of sitting down at the beginning of the project will fix this.
You just have to realize that requirements change, and code to make the project easy to change later.
The problem is, most people/organizations desperately want to build something now, so they feel something's happening, then keep tweaking it all over the place until they're happy, totally changing the spec once it's underway.
Actually, if it's done right, that's the best thing to do. Why? You produce a first release _quickly_ without having to worry about the features that are several versions down the line. That release is adopted and the customer starts actually using it. Whatever happens, they're now actually getting the benefit of having the useful software that you have written for them.
And sure, they might decide that it's wrong in some critical respects. But at least they have _something_ to work with while you're making the changes they requested.
Most systems aren't like that. They're designed by committee who won't think through most issues until they see a working version. They essentially force prototyping on you - yet consider what you're building the final system and won't pay for you to do a final rebuild.
I've never had a client who expects to get free changes to the working software I've delivered that meets their original spec, even when they decide it's not what they wanted. Well, OK, there was one. But the court agreed with me and made them pay up. That's in over ten years of professional software development. I've had clients who ended up with bills nearly double what they originally expected, but they've paid happily because they knew I delivered their original requirements, but those requirements changed. They know I charge per feature developed, and I always make sure they know before I start work on it what each feature will cost. Generally speaking, they're all happy with that.
Yes, code re-use is something great programmers do. But only if they have great designers who really think everything through first.
Some of the best code reusers I've come across are agile developers who espouse not thinking through anything beyond the feature you're working on at the moment. Reuse doesn't require ahead-of-time design, but it does require a lot of attention to detail. In the OO world, it requires a good understanding of design patterns (which means when not to use, as much as it does when to use them). It requires the ability to understand what your code is doing in great detail, and to hold a large chunk of that information in your head at once, to enable you to spot where another piece of code is doing something similar to what you're trying to do now. It requires you to have sufficient confidence to rework that old code to better fit its new application, where necessary (which normally means you'd better have good test coverage of it). But it doesn't seem to require you to identify the opportunities for reuse in advance.
Hibernate is a pretty good product. It has nice features that allows you to abstract tables into OOP representation.
The problem with hibernate is that too many people use it when they want something with features that allow you to abstract objects into table representations. There are much simpler ways of doing that, without the complications of a library designed to work with arbitrary tables.
You should be asking, "Should I make architectural decisions before or after I collect all the requirements." But you know the answer to that one.
A more experienced engineer would have dug for requirements early, planned for some creep, and would have warned the manager that the risk of starting before the thing is properly speced is that all work might have to be thrown away.
You'll know next time.
Strongly disagree. Collecting enough of the requirements before the project begins to do this is almost impossible in most cases. There's a very high chance that the OP would never have found out about the requirements he now faces if he didn't have a working first release deployed already. Users never know what they want to do with software until they have it in front of them, that's just a fact of life, and no amount of requirement gathering can fix it.
It is also nearly always possible to build the project one requirement at a time without having to throw away more than a small fraction of what you write. Architectural decisions should be made when a requirement dictates them. If Hibernate and Spring made the OP's job easier for the first version, using them was the right choice. If he's done a halfway competent job, replacing them now shouldn't be any harder than doing the work without them in the first place would have been.
Agreed. This is definitely the approach to take in most cases.
I usually avoid Hibernate because it's overkill for most of my purposes -- I prefer beankeeper, which simplifies matters by having a *much* simpler transaction model and building its own db schema so you don't have to configure it to match your own -- but this is where Hibernate really shines. AFAICT, there isn't anything you can do with SQL but can't do with it.
The OO fad has certainly contributed mightly towards encouraging over engineering.
I don't think I would call a form of programming that has been pretty-much the dominant form for nearly 20 years now and is showing no signs of giving way to any other form a "fad".
I'm also not sure object oriented programming itself has contributed that much to *causing* over-engineering. It just makes over-engineering easier, so is particularly attractive to people who do over-engineer their code.
Perhaps it is a piece of research that will not result in a product that somebody can sell at a huge profit, but will only increase our understanding of the world a little. Or is that too silly to consider?
You don't think a drug to improve ability to remember stuff you experience while you're taking it would sell?
The real question is how cheap. Current generation lithography systems have become ridiculously expensive. Preparing a mask for a 65nm process costs in excess of $2M. This makes short-run production at not-even-cutting-edge technology levels extremely expensive, and basically discourages smaller chipmakers from considering any niche applications that might require higher density.
Even if the production process is slower, if this can cut the initial preparation costs significantly, it could make the niche IC market somewhat more viable.
Uhhh, yeah... The population of the US and the UK combined make up half a percent of the total population of the world. He *might* be some other nationality too, you know.
Well, yeah, but they do make up well over half of native English speakers, which the poster appeared to be...
Not in the UK - it has been illegal here for a few years to rent any type of mailbox without A) a valid passport, and B) proof of present address, usually accepted to be a current bank statement and a current utility in your name.
Of course, if you're a serious criminal, you can just go and rent a cheap house from a dubious private landlord using an assumed name and paying cash in advance. It'll cost a bit more than a mailbox would, but then you get a totally non-suspicious address that you can use for any fraudulent purposes you can think of without risking exposure. Which is what any serious criminal was doing anyway when they needed a temporary, untraceable address. Only a moron would use a mailbox (of which there are lists available, and many people get suspicious if they find they're dealing with someone using them).
Again, all the increased legislation does it make it harder for honest people to conduct their lives, while not even hampering the efforts of the criminals.
I don't want to have to commit a criminal act in order to have anonymous phone calls. I'm concerned that a lot of my legal but unusual activities would single me out for police harrassment if they knew what I did. I don't want them trawling through a database of my phone calls (including my location when I made/received them) and text messages with automated data mining algorithms looking for "terrorists" (which will, of course, be prone to producing false positives).
Luckily for me, I already have an anonymous phone, and the legislation being discussed sounds like it would only require registration for new customers. But it's only a single step further to require the phone companies to switch off all those old, unregistered phones. And I'm also concerned for people like me who haven't already acquired such a phone, but might need one in the future.
Real UK passports are kind-of easy to spot. They have a translucent hologram over the page with your identity info on it, which would be very hard to fake up.
If "Osama the Terrorist" is using it for 5 weeks, you lose your ability to claim ignorance and state the phone was stolen or lost.
Why would that be a reasonable thing to claim? I have about 6 or 7 phones here, some of which I haven't used for over 5 years, but I imagine they still work (they certainly did when I upgraded to a new phone and stopped using them). It might take me a year or more to notice if somebody had stolen one of them. I might never notice.
Remember we're talking about a country where the police recently distributed posters advising members of the public to inform them of people who had _more than one mobile phone_ because _terrorists tend to use multiple phones_.
Oh, and for those who haven't seen the poster, it can be downloaded here [pdf]. Its nearly-as-paranoid sibling can be found here [also pdf].
Or are you perhaps one of those pussy terrorists that is afraid of hitting people on the head and only does suicide bombings?
Well, I dunno. Remember we're talking about a country where the police recently distributed posters advising members of the public to inform them of people who had _more than one mobile phone_ because _terrorists tend to use multiple phones_.
If they really need so many, maybe they're worried about how much work constantly mugging people for them would be.
What? Those articles are locked and have been for a while (or at least they were yesterday when I posted.)
OK, so there had been a lot of editing, rather than a lot of editing still being ongoing. It's still not obvious which particular edits you were referring to.
To do this you need the TrueCrypt bootloader installed
Not really. You can create a truecrypt hidden volume in a secondary partition or in a file container if you wish. It isn't as secure (unless you disable paging and ensure your applications never write to temp while modifying data you store in the hidden partition), but it does work.
which is a dead give-away that you probably have a hidden volume.
Not really. I don't think *most* people using truecrypt are using the hidden volume function. At least not with their bootable partition. It's just too damned fiddly. Truecrypt is popular as a reasonably good, high performance, full drive encryption system. Hidden volumes, however, are more effort than they're worth, because in order to avoid overwriting the data, you have to (a) give the system two passwords rather than just one and (b) the driver can report write failures when you hit the sectors that the hidden volume is stored on, which screws all kinds of stuff up.
Seriously, you don't want to be booting off a partition with a hidden volume on it unless you really have to.
TrueCrypt plausible deniability is useful against those who cannot employ deadly force against you.
And those who have no reason to be particularly suspicious of you. And, you know what, I believe TSA comes under both categories.
I think you mean Apache. Most Java libraries I've used (other than the core Sun stuff) are from Apache and released under Apache license.
Well, the Apache license is BSD-like in that it permits redistribution under other licenses ("You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License").
But I was thinking more about stuff like Spring, Hibernate, Jetty, CGLib, JUnit, JMock, HSQLDB, AspectJ, etc.
Slashdot Mirror
the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax
So, it's Lisp then?
Seriously... in terms of small regular syntaxes you don't get smaller and more regular than Lisp:
(source).
Next smallest and most regular syntax for a useful language is probably smalltalk, but that's too long to post here. It's worth noting that smalltalk (particularly its first-class statement blocks) was a heavy influence on ruby. Smalltalk also gets close to hitting the 'nice' requirement, which IMO Lisp is a long way from.
Anyone happen to catch the election returns? I haven't been able to find anything on the internet how it ended... :p
They tied. You're going to have to go through it all again next month.
This is pretty much impossible without voter verified paper ballots.
Which is an obviously-good solution to the problem, so why isn't it being used universally?
Hibernate allows you to use straight jdbc calls which is what most people end up doing if they have a real world app and need to optimize the queries.
Or you can use a stored procedure or sql query accessed via a hibernate named query. Avoids the need to get your hands dirty with JDBC, but allows you complete control over the query that's executed. Best of both worlds.
My rule of thumb is that if it takes you longer to learn to use a tool than writing it your self you should probably just write it.
A good one. If you knew in advance how long it would take to learn the tool, that is. :)
Rewriting is inevitable, I once read (in TDWTF) that any task that is done more than there is worth abstracting out.
Sounds like a good rule to me.
If you and the client had sat down at the beginning of the project and described what the application must do, must not do, and what the client would like it to do (or not to do) would you have realized before getting "married to this object model framework" that some of the requirements would be hard or impossible to satisfy?
In my experience, that only works on the rare occasions where the client actually understands their own requirements. More often than not, I end up telling the client what they need. In something like 90% of cases there's some critical point that neither of us understood in the beginning of the project that the client only realizes when he's sitting in front of the software, trying to actually use it for real business purposes. No amount of sitting down at the beginning of the project will fix this.
You just have to realize that requirements change, and code to make the project easy to change later.
The problem is, most people/organizations desperately want to build something now, so they feel something's happening, then keep tweaking it all over the place until they're happy, totally changing the spec once it's underway.
Actually, if it's done right, that's the best thing to do. Why? You produce a first release _quickly_ without having to worry about the features that are several versions down the line. That release is adopted and the customer starts actually using it. Whatever happens, they're now actually getting the benefit of having the useful software that you have written for them.
And sure, they might decide that it's wrong in some critical respects. But at least they have _something_ to work with while you're making the changes they requested.
Most systems aren't like that. They're designed by committee who won't think through most issues until they see a working version. They essentially force prototyping on you - yet consider what you're building the final system and won't pay for you to do a final rebuild.
I've never had a client who expects to get free changes to the working software I've delivered that meets their original spec, even when they decide it's not what they wanted. Well, OK, there was one. But the court agreed with me and made them pay up. That's in over ten years of professional software development. I've had clients who ended up with bills nearly double what they originally expected, but they've paid happily because they knew I delivered their original requirements, but those requirements changed. They know I charge per feature developed, and I always make sure they know before I start work on it what each feature will cost. Generally speaking, they're all happy with that.
Yes, code re-use is something great programmers do. But only if they have great designers who really think everything through first.
Some of the best code reusers I've come across are agile developers who espouse not thinking through anything beyond the feature you're working on at the moment. Reuse doesn't require ahead-of-time design, but it does require a lot of attention to detail. In the OO world, it requires a good understanding of design patterns (which means when not to use, as much as it does when to use them). It requires the ability to understand what your code is doing in great detail, and to hold a large chunk of that information in your head at once, to enable you to spot where another piece of code is doing something similar to what you're trying to do now. It requires you to have sufficient confidence to rework that old code to better fit its new application, where necessary (which normally means you'd better have good test coverage of it). But it doesn't seem to require you to identify the opportunities for reuse in advance.
Hibernate is a pretty good product. It has nice features that allows you to abstract tables into OOP representation.
The problem with hibernate is that too many people use it when they want something with features that allow you to abstract objects into table representations. There are much simpler ways of doing that, without the complications of a library designed to work with arbitrary tables.
Unless you like being stuck with Java!
Both are available in .NET versions, if you prefer.
You should be asking, "Should I make architectural decisions before or after I collect all the requirements." But you know the answer to that one.
A more experienced engineer would have dug for requirements early, planned for some creep, and would have warned the manager that the risk of starting before the thing is properly speced is that all work might have to be thrown away.
You'll know next time.
Strongly disagree. Collecting enough of the requirements before the project begins to do this is almost impossible in most cases. There's a very high chance that the OP would never have found out about the requirements he now faces if he didn't have a working first release deployed already. Users never know what they want to do with software until they have it in front of them, that's just a fact of life, and no amount of requirement gathering can fix it.
It is also nearly always possible to build the project one requirement at a time without having to throw away more than a small fraction of what you write. Architectural decisions should be made when a requirement dictates them. If Hibernate and Spring made the OP's job easier for the first version, using them was the right choice. If he's done a halfway competent job, replacing them now shouldn't be any harder than doing the work without them in the first place would have been.
Agreed. This is definitely the approach to take in most cases.
I usually avoid Hibernate because it's overkill for most of my purposes -- I prefer beankeeper, which simplifies matters by having a *much* simpler transaction model and building its own db schema so you don't have to configure it to match your own -- but this is where Hibernate really shines. AFAICT, there isn't anything you can do with SQL but can't do with it.
The OO fad has certainly contributed mightly towards encouraging over engineering.
I don't think I would call a form of programming that has been pretty-much the dominant form for nearly 20 years now and is showing no signs of giving way to any other form a "fad".
I'm also not sure object oriented programming itself has contributed that much to *causing* over-engineering. It just makes over-engineering easier, so is particularly attractive to people who do over-engineer their code.
Perhaps it is a piece of research that will not result in a product that somebody can sell at a huge profit, but will only increase our understanding of the world a little.
Or is that too silly to consider?
You don't think a drug to improve ability to remember stuff you experience while you're taking it would sell?
This is very cheap.
The real question is how cheap. Current generation lithography systems have become ridiculously expensive. Preparing a mask for a 65nm process costs in excess of $2M. This makes short-run production at not-even-cutting-edge technology levels extremely expensive, and basically discourages smaller chipmakers from considering any niche applications that might require higher density.
Even if the production process is slower, if this can cut the initial preparation costs significantly, it could make the niche IC market somewhat more viable.
Uhhh, yeah... The population of the US and the UK combined make up half a percent of the total population of the world. He *might* be some other nationality too, you know.
Well, yeah, but they do make up well over half of native English speakers, which the poster appeared to be...
Not in the UK - it has been illegal here for a few years to rent any type of mailbox without A) a valid passport, and B) proof of present address, usually accepted to be a current bank statement and a current utility in your name.
Of course, if you're a serious criminal, you can just go and rent a cheap house from a dubious private landlord using an assumed name and paying cash in advance. It'll cost a bit more than a mailbox would, but then you get a totally non-suspicious address that you can use for any fraudulent purposes you can think of without risking exposure. Which is what any serious criminal was doing anyway when they needed a temporary, untraceable address. Only a moron would use a mailbox (of which there are lists available, and many people get suspicious if they find they're dealing with someone using them).
Again, all the increased legislation does it make it harder for honest people to conduct their lives, while not even hampering the efforts of the criminals.
Who cares?
I do.
I don't want to have to commit a criminal act in order to have anonymous phone calls. I'm concerned that a lot of my legal but unusual activities would single me out for police harrassment if they knew what I did. I don't want them trawling through a database of my phone calls (including my location when I made/received them) and text messages with automated data mining algorithms looking for "terrorists" (which will, of course, be prone to producing false positives).
Luckily for me, I already have an anonymous phone, and the legislation being discussed sounds like it would only require registration for new customers. But it's only a single step further to require the phone companies to switch off all those old, unregistered phones. And I'm also concerned for people like me who haven't already acquired such a phone, but might need one in the future.
...in recognizing fake passports?
Real UK passports are kind-of easy to spot. They have a translucent hologram over the page with your identity info on it, which would be very hard to fake up.
Of course, as soon as you top up at a cash machine, or with a credit card, it can be tied to you...
There are a number of countries with banks that will issue anonymous credit cards.
And you can still top up with cash.
If "Osama the Terrorist" is using it for 5 weeks, you lose your ability to claim ignorance and state the phone was stolen or lost.
Why would that be a reasonable thing to claim? I have about 6 or 7 phones here, some of which I haven't used for over 5 years, but I imagine they still work (they certainly did when I upgraded to a new phone and stopped using them). It might take me a year or more to notice if somebody had stolen one of them. I might never notice.
Remember we're talking about a country where the police recently distributed posters advising members of the public to inform them of people who had _more than one mobile phone_ because _terrorists tend to use multiple phones_.
Oh, and for those who haven't seen the poster, it can be downloaded here [pdf]. Its nearly-as-paranoid sibling can be found here [also pdf].
Or are you perhaps one of those pussy terrorists that is afraid of hitting people on the head and only does suicide bombings?
Well, I dunno. Remember we're talking about a country where the police recently distributed posters advising members of the public to inform them of people who had _more than one mobile phone_ because _terrorists tend to use multiple phones_.
If they really need so many, maybe they're worried about how much work constantly mugging people for them would be.
What? Those articles are locked and have been for a while (or at least they were yesterday when I posted.)
OK, so there had been a lot of editing, rather than a lot of editing still being ongoing. It's still not obvious which particular edits you were referring to.
To do this you need the TrueCrypt bootloader installed
Not really. You can create a truecrypt hidden volume in a secondary partition or in a file container if you wish. It isn't as secure (unless you disable paging and ensure your applications never write to temp while modifying data you store in the hidden partition), but it does work.
which is a dead give-away that you probably have a hidden volume.
Not really. I don't think *most* people using truecrypt are using the hidden volume function. At least not with their bootable partition. It's just too damned fiddly. Truecrypt is popular as a reasonably good, high performance, full drive encryption system. Hidden volumes, however, are more effort than they're worth, because in order to avoid overwriting the data, you have to (a) give the system two passwords rather than just one and (b) the driver can report write failures when you hit the sectors that the hidden volume is stored on, which screws all kinds of stuff up.
Seriously, you don't want to be booting off a partition with a hidden volume on it unless you really have to.
TrueCrypt plausible deniability is useful against those who cannot employ deadly force against you.
And those who have no reason to be particularly suspicious of you. And, you know what, I believe TSA comes under both categories.
I think you mean Apache. Most Java libraries I've used (other than the core Sun stuff) are from Apache and released under Apache license.
Well, the Apache license is BSD-like in that it permits redistribution under other licenses ("You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License").
But I was thinking more about stuff like Spring, Hibernate, Jetty, CGLib, JUnit, JMock, HSQLDB, AspectJ, etc.