I agree completely. I'm glad you wrote this. I wish more people would take this advice to heart.
My situation at work is identical, except with Java and regular Hibernate. My predecessors used Hibernate figuring they could ignore the database. I came in long afterwards. I've spent the last month trying to improve the situation with Hibernate, but there's only so much that can be done when your codebase assumes that all your objects are always in memory.
Without wanting to distract too much from what comes closer to total agreement than anything I've ever experienced on Slashdot, I am, personally, rather against "document" databases. While there wouldn't have been a Hibernate mapping to screw up or relational theory to misunderstand, I think my team would have ultimately just fetched everything from it and stuffed it back in like we're doing now. Perhaps that wouldn't be as big of a mistake with CouchDB. It would be hard to determine now.
Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.
The Israelis just want to live on the land they were born on, just like Americans and everyone else.
The Zionists who settled Israel actually seriously considered getting a piece of land in Africa or America instead. Most of the land they settled on was uninhabited and purchased from the previous owners.
It's an excellent point and it's well-taken, but none of those are really what the OP is talking about. Parrot is really the pertinent example, though it has arisen out of Perl (more-or-less); none of the other systems you name are really a generic managed runtime.
The answer to the question, why isn't Parrot more widely-used is to look at context. We're not comparing Parrot to (say) Python's bytecode; if we did, Parrot looks like a runaway success. We're comparing Parrot to the JVM, but that's not a fair comparison, because people write languages that target the JVM to make life easier in Javaland, not because the JVM is a technical achievement.
You found two islands of truth amid your sea of misunderstanding.
First of all, your remarks about Dice are spot on. This is not because programming languages or programmers are stupid, this is because hiring practices for programmers are stupid. Because programming requires intelligence, it's stupid to advertise for programmers as though they are single-use tools. We can learn other languages. In fact, a great deal of good companies have caught on to this and list absurd numbers of languages in the job postings, or mention that you'll have to program in language X, but that you're not required to know it coming in if you know some other languages. Language designers do not define hiring practices. That's up to the business-types: i.e., YOU. So do a better job.
Secondly, what you're describing is exactly the situation of.NET and (to some extent) the JVM. You create an artificial machine at a slightly higher level of abstraction, and then people can write whatever languages they want and they can call libraries written in other languages. It looks like a great solution to this problem, but it's hiding other problems under the surface, which is where your lack of knowledge becomes a problem.
There is a world of difference between language syntax and language semantics. True, most languages in wide use today are single-inheritance object-oriented programming languages with a strong procedural bent to them. Is there a world of difference between C# and VB.net? No, but VB.net is very different from traditional VB. They had to pile on a ton of new features which meant some syntactic changes to make VB run on.NET. After all, if you can't use each others' libraries, the exercise gains you nothing. C# is more-or-less intended to be a 1:1 mapping of.NET VM feature to language feature.
But as everyone else here is trying to point out, language semantics vary between languages. You can't run C++ (note the additional +) on.NET because.NET won't let you inherit from more than one class at a time. C++ does. And this comes hand-in-hand with a ton of other differences: operator overloading, virtual inheritance, and so forth. If you take those features away from C++, you don't have C++ anymore, you have something else rather similar to C#. If you give those features to C#, you don't have C# anymore, you have something that looks like C# but acts like C++. This is important because libraries are constrained by language features. Look at Ruby. You can't use Ruby's standard library from Java, because Java doesn't have blocks. If you make Java use classes to do it instead, your code becomes twice as big and nobody wants to do it. (See the Mango library for example). Likewise with C++, many of the standard library features assume multiple inheritance, particularly with I/O. Input and output are not fancy high-level concepts, they're ground-level fundamentals, and yet there will never be a universal I/O library that all languages prefer, because languages are different. For another example, look at Haskell. Most of my Haskell programs, I treat input as a list of strings and I am free to pretend they're just in memory the whole time because of the optimizations Haskell does. Other languages need an iterator because they can't fake it with laziness.
The situation becomes obvious when you venture outside the confines of familiar languages and consider languages which you name, like Prolog and Haskell. There is no such thing as assignment in Prolog, there is binding, but because you actually have no explicit control over binding, there's no way to rebind a variable. Indeed, functional and declarative languages (Prolog, Haskell, ML, etc.) have no such thing as assignment or iteration constructs. Until you understand what that means and how someone could possibly program without them, you should really keep your trap shut on this subject. And please don't waste our time responding with "internally they're a
In general I agree with you, but I think it's worth pointing out that: 1) existing products in a niche don't necessarily preclude a new one from coming in and taking over the niche (such as iPods) and 2) you don't have to take over the world to make a handsome profit. It would be terrifically naive for Andreesen to try and take over the browser market with this thing, but that doesn't mean he won't be able to do better than Flock, which has essentially zero users, and make several million dollars in the process.
And, what worries me more is that I can see Apple killing traditional OSX on Macs in favour of iOS as well.
Lots of people are saying this, but I really don't see evidence for it. They're certainly going to grow the two towards each other, but for the next ten years at least, I don't see any gains to be had by doing this. You can't program on an iPad, and Apple depends crucially on 3rd-party developers to fill their app stores. They can't make OS X too onerous or they'll drive developers away.
I can easily see them pushing iPad and other iOS devices for ordinary consumers, but they have always depended on being able to court the expert users with things like Logic and Final Cut and developers with their free tools and copious documentation. Expert users are not intimidated by traditional computers and would rather have powerful features than the most intuitive interface. Apple certainly intends to maximize profit, which will mean maximizing the iPad and simple tools with intuitive interfaces, but they can't undermine OS X without undermining their developers and power users, which would in turn undermine everything else they make.
I think you are on the right track, but you have cause and effect backwards. Apple strives to be a consumer company. I was confused by Apple's Xraid/Xsan and Xserve products, because they don't really fit in the same milieu. If anything, I wonder if offering Xserves and Xraids was just a way for them to kill harbored distrust of OS X inherited from OS 9. After all, OS X had some big hurdles to overcome from OS 9. Supplying even a couple universities with Xserves demonstrated that OS X and Apple in particular were making high-performance machines, a worthy continuation of their NeXT legacy, and dispelled any fears about inherited OS 9isms. So from this standpoint, the product line was a success, but it is no longer required.
From another standpoint, remember that Xserves were first brought onto the market was during the bubble, before "the cloud" was a thing. My first employer had an Xserve simply because he found the idea of managing it better than the idea of managing a hosted Linux server. Colocation was cheaper than paying for a managed server. For small business owners--particularly Mac software developers--it made more sense to them than learning how to administer Linux or paying another employee to do it. Familiarity is worth something.
Remember also the market conditions when Xserves were brought out. They weren't the only vendor selling their own weird Unix in a 1U. SGI, Sun, and HP at least were also selling their own servers running their own Unixes. The market was nowhere near as homogenized as it is now, and it was plausible at the time that OS X Server could become as important as the competition. It turns out people don't buy servers for the same reasons they buy desktops. That wasn't necessarily obvious five or ten years ago.
American democracy explained: the people want stuff for free. One side says "you get to have stuff but you have to pay for it." The other side says, "if you don't want to pay for anything, you shouldn't have to get anything." So every couple years, the voters alternate between "Waahh! I want more stuff!" or "Waahh! I don't like spending money!" It doesn't have any more to do with theoretical ideals of capitalism this time around than it did with theoretical ideals about socialism or progress last time around.
When it comes to simplicity, you have to ask, to whom? A stick shift is closer to the metal, but it takes more training to use than an automatic. It can also limit possibilities. I had a friend who staunchly refused to buy a hybrid until he could get one with a manual shift. It was quite a shock to him that the design of hybrids precludes it.
I have friends who pine for the good old days of dBase and FoxPro. Have you watched them actually write a program though? They're ugly and unintuitive, because those weren't important concerns when they began to program. They assume single user access, because computers were scarce. Yes, these programs run faster. Yes, older programmers understand the machine better. But things change, they change faster and faster, and everything continues to get more complicated. To do assembly programming on an 386 is not like doing assembly programming on an x86-64 with SSE and all that other good stuff. You have to have good understanding of vector and matrix arithmetic to use these features, you have to worry about whether stuff is in L1, L2 or L3 cache. You have to worry about cache lines. You have to worry about whether or not you're reading sequentially from the disk, or whether stuff is coming out of the disk's own cache.
I think we're stuck between two extremes. To stay married to the metal is limiting. Oftentimes, it is possible to add capabilities to the hardware that are hard to understand how to make optimal use of, but it still helps because the compiler writers understand them and can ensure they are used appropriately. Hardware manufacturers on all sides are adding complexity: the CPU, the video card, the storage, the network card. They're intended to be made use of by people who understand those aspects in great depth. If they had to be comprehensible to everyone who can program, we would still be using 2400 baud modems with our 386's and 8-color video, because that's what you can do when you have to understand everything from top to bottom. I wager almost nobody has a full and complete understanding of absolutely everything that happens between entering the URL and the page being rendered on the screen.
It's hard to give up control. But I have to ask if you're as productive as those of us who have given up control. My software tends to output HTML. It gets rendered by the browser and I don't really understand all that goes into that. I understand enough of CSS to change the way it looks. My problem is understanding SQL. I understand SQL well enough that MySQL and Access annoy me, and dBase would be a constant burden to me. My depth there is matched by the power of PostgreSQL and other true RDBMSes. I get more done this way, and my interfaces are not deplorable, and making small changes is easy and big ones are possible. It's a different way of working than application development. I worry about fewer things and get more done. Whatever technology enables that is the one that wins.
The other extreme, which I don't like either, is reinvention of the wheel and ignoring layers below that have already solved the same problems. I know you balk at that because you see it happening all over the place. I balk at it too. However, at the end of the day, you aren't the one responsible for those reinventions. If you are not the one reinventing the wheel, why get so worked up about it? Limit the effect of that kind of thing on you and you can be OK without having to curmudgeonly dawdle on ancient irrelevancies while you're programming.
Re:LISP a bad choice as a starter language.
on
Land of Lisp
·
· Score: 4, Insightful
Your information about Lisp is about 30 years out of date. It's not an acronym, Common Lisp has many looping constructs that are much more widely used than recursion, and closing parenthesis is as trivial to any modern editor or IDE as managing any other aspect of syntax. I think if you look at the cover of this book, it should be obvious to you that the target audience is not particularly interested in the marketability of their skills.
Re:computers come with accessible languages
on
Land of Lisp
·
· Score: 2, Insightful
AppleScript is much easier to understand than to write. Nearly everyone winds up using it in an autotools-like way, looking for examples online and adapting them, with a lot of superstitious behavior. It's extremely hard to write non-trivial AppleScript, and I'm speaking as a professional programmer with command of plenty of languages.
Re:"Alice" one of the best learning languages toda
on
Land of Lisp
·
· Score: 4, Informative
First, Lisp is not an acronym.
Second, Lisp has the CLOS, which is an advanced OOP system in its own right with multiple inheritance, polymorphism, encapsulation, multiple dispatch and all that other groovy nonsense. It's no setback compared to "modern" OOP.
Qt is in most every way better than Java for client-side graphical application development. However, Qt is not completely free, requires that your app be compiled for each platform it is distributed for, and does not provide access to Java libraries. The last reason there is why we use it at my work.
If they had a large number of Cocoa/Java developers and it were possible, they would have to do it. Neither of those is the case though: they're making this move in large part because cross-platform Java development and Mac development were different enough that if you were using Java it was because you wanted it to run on other platforms and therefore didn't care if it looked like a good Mac app. So in practice, almost nobody would use it. But the other problem is that their tool certainly couldn't convert a random jar into a binary, and if you used Java it's hard to imagine not using some third-party libraries. I don't think such a tool could exist without becoming essentially another JVM.
Right, but Apple does ship versions of Python and Ruby that can access their Cocoa libraries. Apple would rather all developers use Objective-C, but that's just a way of ensuring that developers use Cocoa. Using Cocoa is what they're really after, technically speaking, because their real goal is for all Mac applications to use the same toolkit, look nice and behave like other Mac applications.
I promise you Apple doesn't care if Swing applications look similar to Mac applications since they won't behave like Mac apps due to not running through Cocoa. I bet Apple would be happy if those apps just never ran on OS X. But they have in the past provided a way of using Cocoa through Java. Apparently the Mac Java developer community had enough of a clue to realize that using Cocoa is a great way to restrict your app to one platform and miss the whole point of using Java in the first place.
Apple's special JVM was really just a way of trying to sneak Java developers into Cocoa, but it never really worked, so at this point, it's probably in Apple's best interest to just provide a stock JVM so people who really want to use Java can and let Oracle worry about whether or not Swing apps look like Mac apps. In general, Swing app usability is damning enough that Apple can just leave well enough alone and their customers will want Cocoa apps or Swing apps that have been engineered to look and behave a lot like Cocoa apps anyway.
Drupal had a similar problem back when I was using it. They claimed to support PostgreSQL, but all the plugin authors wrote MySQL SQL, and it took a lot of manual effort to get any plugin to work with a PostgreSQL-based install.
What's wrong is that the OS is a general-purpose piece of software, and it is designed to guarantee relatively good performance across a wide range of use cases. However, databases are a very special case and as such they are able to make better guesses about when and where they are going to need their data. The OSes we live with are a hodgepodge of hardware abstraction and conceptual abstraction. This is one reason exokernels are so interesting to me, is because they should give you an OS built out of layers, so if you just need to treat all HDDs as the same kind of thing, you can do that, whereas if you need a filesystem for conceptual clarity, you can do that too, and these ideas don't stomp on each other's toes.
Re:Linux has the same drag as Mac in business
on
Desktop Linux Is Dead
·
· Score: 2, Interesting
What they're missing is the built-in idiot-easy form designing.
I'm speaking as a major PostgreSQL believer. One of my best friends was a beltway bandit in the 70's-90's. He calls GUI application development "the programmer's guaranteed employment act." He's definitely a fossil, and he made all his money on dBase and FoxPro. Neither of these tools are particularly amazing, but they do make it easy to write fairly simple databases with fairly simple visual forms (think ncurses).
There is a strong tendency in our profession to break systems down into a set of components and then elaborate those components. I am a web developer with a strong RDBMS background. I find that I can offload a great deal of the work to the database and it's not much effort for me. I find that, on the web, I only need a designer's input for a fraction of the time I would if I were doing a GUI application. This is because we've elaborated these components. FoxPro gives you a pretty stripped down, procedural way of dealing with the database. I haven't seen what its GUI frameworks are like but I'm willing to bet they're also fairly also stripped down and procedural. I have web developer friends who are not conversant in SQL. They are very excited about the "NoSQL" "databases." I think this largely has to do with the fact that when you misuse RDBMSes, they aren't that fast, and the kind of people NoSQL appeals to are already doing that work in their application. For them, it's not taking on a burden they don't already have. To my friend the FoxPro user, NoSQL just looks like even more work he didn't used to have to do.
The people who were brought up in simpler times find simpler tools better because they have to learn less and they can just sort of dive in and start getting shit done. But for me, I already have learned these tools and can use them deftly. To me, using FoxPro is a bunch of tedious manual labor because I can make a complicated SQL statement. Also, to make a nice application now is a lot more work than it was twenty or thirty years ago. It has to look nice and have a good metaphor as well as do its job quickly and well. My friend can certainly bang out a FoxPro application quickly, even quicker than me most of the time, but it won't be the app you want to use, because it also looks like it came out of that era.
As far as I can tell, there will always be a market for every kind of software developer. We've reached a critical mass where pretty much every technology now has an installed base of users for whom that technology is essential. My friend could certainly find work in FoxPro, though most of it seems to be on the east coast. But demand is low enough that he would have to relocate, which isn't the case for me as a web developer. It's the same thing with MUMPS. If you know it, you can get a job working for some hospital or medical company, but you are unlikely to find a company in your zip code that needs it.
To return to your point, MySQL and PostgreSQL aren't missing anything from a database perspective. From a FoxPro perspective they're simply missing simplicity. But simplicity isn't something you can just drop in.
The first problem on my mind right now though is that nearly all widely used relational databases are built with a lot of algorithmic assumptions about the disk. They spend a great deal of time ensuring that they only fetch the minimum number of blocks, and many higher end databases go to lengths to ensure that related blocks wind up near each other on disk, implement block caches and things like that. A lot of this is done to mitigate seek time.
With SSDs, seek time is basically constant and there's no need to minimize it, though you still want to minimize number of fetches. However, all SSDs on the market (AFAIK) exhibit a profound performance degradation once the disks start having to erase blocks. Most disks postpone this as long as possible with an internal copy-on-write mechanism, but it's not uncommon for write speed to dramatically decrease once every block has been written to once. So there is a serious need to eliminate unnecessary writes and minimize necessary ones, which is not something most relational databases have put much effort into.
I fully expect that in a few years most databases will have a tunable parameter for, am I dealing with SSDs or traditional HDDs, and will make appropriate optimizations for the type of disk, but I wouldn't be a bit surprised to hear that their performance improvements degrade sharply in a year or two when all of their array's blocks have been touched. At the same time, I think this area is ripe for exploitation by database vendors. I also wouldn't be surprised if the gap between SSD-backed and HDD-backed DBs were made much larger by software improvements rather than hardware improvements over the next few years. It'll be interesting to see.
The chiropractor in the small town I live in used to have pamphlets around the office explaining how depression, the flu, and acne are caused by spinal misalignment. I'm guessing they aren't printed just for him.
Slashdot Mirror
I agree completely. I'm glad you wrote this. I wish more people would take this advice to heart.
My situation at work is identical, except with Java and regular Hibernate. My predecessors used Hibernate figuring they could ignore the database. I came in long afterwards. I've spent the last month trying to improve the situation with Hibernate, but there's only so much that can be done when your codebase assumes that all your objects are always in memory.
Without wanting to distract too much from what comes closer to total agreement than anything I've ever experienced on Slashdot, I am, personally, rather against "document" databases. While there wouldn't have been a Hibernate mapping to screw up or relational theory to misunderstand, I think my team would have ultimately just fetched everything from it and stuffed it back in like we're doing now. Perhaps that wouldn't be as big of a mistake with CouchDB. It would be hard to determine now.
Another thing to consider is OODBs. I'm going to be looking at db4o pretty soon because this situation is just intolerable. I had a call with Objectivity, but they wanted in the neighborhood of $80K for a 100 client installation on a 4 processor machine with 3 developer licenses, and that's way beyond our budget. Would have probably been perfect for our situation though, due to the way they wrote the code.
The Israelis just want to live on the land they were born on, just like Americans and everyone else.
The Zionists who settled Israel actually seriously considered getting a piece of land in Africa or America instead. Most of the land they settled on was uninhabited and purchased from the previous owners.
It's an excellent point and it's well-taken, but none of those are really what the OP is talking about. Parrot is really the pertinent example, though it has arisen out of Perl (more-or-less); none of the other systems you name are really a generic managed runtime.
The answer to the question, why isn't Parrot more widely-used is to look at context. We're not comparing Parrot to (say) Python's bytecode; if we did, Parrot looks like a runaway success. We're comparing Parrot to the JVM, but that's not a fair comparison, because people write languages that target the JVM to make life easier in Javaland, not because the JVM is a technical achievement.
You found two islands of truth amid your sea of misunderstanding.
First of all, your remarks about Dice are spot on. This is not because programming languages or programmers are stupid, this is because hiring practices for programmers are stupid. Because programming requires intelligence, it's stupid to advertise for programmers as though they are single-use tools. We can learn other languages. In fact, a great deal of good companies have caught on to this and list absurd numbers of languages in the job postings, or mention that you'll have to program in language X, but that you're not required to know it coming in if you know some other languages. Language designers do not define hiring practices. That's up to the business-types: i.e., YOU. So do a better job.
Secondly, what you're describing is exactly the situation of .NET and (to some extent) the JVM. You create an artificial machine at a slightly higher level of abstraction, and then people can write whatever languages they want and they can call libraries written in other languages. It looks like a great solution to this problem, but it's hiding other problems under the surface, which is where your lack of knowledge becomes a problem.
There is a world of difference between language syntax and language semantics. True, most languages in wide use today are single-inheritance object-oriented programming languages with a strong procedural bent to them. Is there a world of difference between C# and VB.net? No, but VB.net is very different from traditional VB. They had to pile on a ton of new features which meant some syntactic changes to make VB run on .NET. After all, if you can't use each others' libraries, the exercise gains you nothing. C# is more-or-less intended to be a 1:1 mapping of .NET VM feature to language feature.
But as everyone else here is trying to point out, language semantics vary between languages. You can't run C++ (note the additional +) on .NET because .NET won't let you inherit from more than one class at a time. C++ does. And this comes hand-in-hand with a ton of other differences: operator overloading, virtual inheritance, and so forth. If you take those features away from C++, you don't have C++ anymore, you have something else rather similar to C#. If you give those features to C#, you don't have C# anymore, you have something that looks like C# but acts like C++. This is important because libraries are constrained by language features. Look at Ruby. You can't use Ruby's standard library from Java, because Java doesn't have blocks. If you make Java use classes to do it instead, your code becomes twice as big and nobody wants to do it. (See the Mango library for example). Likewise with C++, many of the standard library features assume multiple inheritance, particularly with I/O. Input and output are not fancy high-level concepts, they're ground-level fundamentals, and yet there will never be a universal I/O library that all languages prefer, because languages are different. For another example, look at Haskell. Most of my Haskell programs, I treat input as a list of strings and I am free to pretend they're just in memory the whole time because of the optimizations Haskell does. Other languages need an iterator because they can't fake it with laziness.
The situation becomes obvious when you venture outside the confines of familiar languages and consider languages which you name, like Prolog and Haskell. There is no such thing as assignment in Prolog, there is binding, but because you actually have no explicit control over binding, there's no way to rebind a variable. Indeed, functional and declarative languages (Prolog, Haskell, ML, etc.) have no such thing as assignment or iteration constructs. Until you understand what that means and how someone could possibly program without them, you should really keep your trap shut on this subject. And please don't waste our time responding with "internally they're a
I like your sinister scale. You should make a comprehensive diagram of sinisterity.
In general I agree with you, but I think it's worth pointing out that: 1) existing products in a niche don't necessarily preclude a new one from coming in and taking over the niche (such as iPods) and 2) you don't have to take over the world to make a handsome profit. It would be terrifically naive for Andreesen to try and take over the browser market with this thing, but that doesn't mean he won't be able to do better than Flock, which has essentially zero users, and make several million dollars in the process.
Lots of people are saying this, but I really don't see evidence for it. They're certainly going to grow the two towards each other, but for the next ten years at least, I don't see any gains to be had by doing this. You can't program on an iPad, and Apple depends crucially on 3rd-party developers to fill their app stores. They can't make OS X too onerous or they'll drive developers away.
I can easily see them pushing iPad and other iOS devices for ordinary consumers, but they have always depended on being able to court the expert users with things like Logic and Final Cut and developers with their free tools and copious documentation. Expert users are not intimidated by traditional computers and would rather have powerful features than the most intuitive interface. Apple certainly intends to maximize profit, which will mean maximizing the iPad and simple tools with intuitive interfaces, but they can't undermine OS X without undermining their developers and power users, which would in turn undermine everything else they make.
I think the fact you're talking about ad agencies makes my point exactly.
I think you are on the right track, but you have cause and effect backwards. Apple strives to be a consumer company. I was confused by Apple's Xraid/Xsan and Xserve products, because they don't really fit in the same milieu. If anything, I wonder if offering Xserves and Xraids was just a way for them to kill harbored distrust of OS X inherited from OS 9. After all, OS X had some big hurdles to overcome from OS 9. Supplying even a couple universities with Xserves demonstrated that OS X and Apple in particular were making high-performance machines, a worthy continuation of their NeXT legacy, and dispelled any fears about inherited OS 9isms. So from this standpoint, the product line was a success, but it is no longer required.
From another standpoint, remember that Xserves were first brought onto the market was during the bubble, before "the cloud" was a thing. My first employer had an Xserve simply because he found the idea of managing it better than the idea of managing a hosted Linux server. Colocation was cheaper than paying for a managed server. For small business owners--particularly Mac software developers--it made more sense to them than learning how to administer Linux or paying another employee to do it. Familiarity is worth something.
Remember also the market conditions when Xserves were brought out. They weren't the only vendor selling their own weird Unix in a 1U. SGI, Sun, and HP at least were also selling their own servers running their own Unixes. The market was nowhere near as homogenized as it is now, and it was plausible at the time that OS X Server could become as important as the competition. It turns out people don't buy servers for the same reasons they buy desktops. That wasn't necessarily obvious five or ten years ago.
American democracy explained: the people want stuff for free. One side says "you get to have stuff but you have to pay for it." The other side says, "if you don't want to pay for anything, you shouldn't have to get anything." So every couple years, the voters alternate between "Waahh! I want more stuff!" or "Waahh! I don't like spending money!" It doesn't have any more to do with theoretical ideals of capitalism this time around than it did with theoretical ideals about socialism or progress last time around.
When it comes to simplicity, you have to ask, to whom? A stick shift is closer to the metal, but it takes more training to use than an automatic. It can also limit possibilities. I had a friend who staunchly refused to buy a hybrid until he could get one with a manual shift. It was quite a shock to him that the design of hybrids precludes it.
I have friends who pine for the good old days of dBase and FoxPro. Have you watched them actually write a program though? They're ugly and unintuitive, because those weren't important concerns when they began to program. They assume single user access, because computers were scarce. Yes, these programs run faster. Yes, older programmers understand the machine better. But things change, they change faster and faster, and everything continues to get more complicated. To do assembly programming on an 386 is not like doing assembly programming on an x86-64 with SSE and all that other good stuff. You have to have good understanding of vector and matrix arithmetic to use these features, you have to worry about whether stuff is in L1, L2 or L3 cache. You have to worry about cache lines. You have to worry about whether or not you're reading sequentially from the disk, or whether stuff is coming out of the disk's own cache.
I think we're stuck between two extremes. To stay married to the metal is limiting. Oftentimes, it is possible to add capabilities to the hardware that are hard to understand how to make optimal use of, but it still helps because the compiler writers understand them and can ensure they are used appropriately. Hardware manufacturers on all sides are adding complexity: the CPU, the video card, the storage, the network card. They're intended to be made use of by people who understand those aspects in great depth. If they had to be comprehensible to everyone who can program, we would still be using 2400 baud modems with our 386's and 8-color video, because that's what you can do when you have to understand everything from top to bottom. I wager almost nobody has a full and complete understanding of absolutely everything that happens between entering the URL and the page being rendered on the screen.
It's hard to give up control. But I have to ask if you're as productive as those of us who have given up control. My software tends to output HTML. It gets rendered by the browser and I don't really understand all that goes into that. I understand enough of CSS to change the way it looks. My problem is understanding SQL. I understand SQL well enough that MySQL and Access annoy me, and dBase would be a constant burden to me. My depth there is matched by the power of PostgreSQL and other true RDBMSes. I get more done this way, and my interfaces are not deplorable, and making small changes is easy and big ones are possible. It's a different way of working than application development. I worry about fewer things and get more done. Whatever technology enables that is the one that wins.
The other extreme, which I don't like either, is reinvention of the wheel and ignoring layers below that have already solved the same problems. I know you balk at that because you see it happening all over the place. I balk at it too. However, at the end of the day, you aren't the one responsible for those reinventions. If you are not the one reinventing the wheel, why get so worked up about it? Limit the effect of that kind of thing on you and you can be OK without having to curmudgeonly dawdle on ancient irrelevancies while you're programming.
Your information about Lisp is about 30 years out of date. It's not an acronym, Common Lisp has many looping constructs that are much more widely used than recursion, and closing parenthesis is as trivial to any modern editor or IDE as managing any other aspect of syntax. I think if you look at the cover of this book, it should be obvious to you that the target audience is not particularly interested in the marketability of their skills.
AppleScript is much easier to understand than to write. Nearly everyone winds up using it in an autotools-like way, looking for examples online and adapting them, with a lot of superstitious behavior. It's extremely hard to write non-trivial AppleScript, and I'm speaking as a professional programmer with command of plenty of languages.
First, Lisp is not an acronym.
Second, Lisp has the CLOS, which is an advanced OOP system in its own right with multiple inheritance, polymorphism, encapsulation, multiple dispatch and all that other groovy nonsense. It's no setback compared to "modern" OOP.
Qt is in most every way better than Java for client-side graphical application development. However, Qt is not completely free, requires that your app be compiled for each platform it is distributed for, and does not provide access to Java libraries. The last reason there is why we use it at my work.
WebObjects was made completely free a few releases ago. And now I think it's even clearer why.
"Java" is not an acronym.
If they had a large number of Cocoa/Java developers and it were possible, they would have to do it. Neither of those is the case though: they're making this move in large part because cross-platform Java development and Mac development were different enough that if you were using Java it was because you wanted it to run on other platforms and therefore didn't care if it looked like a good Mac app. So in practice, almost nobody would use it. But the other problem is that their tool certainly couldn't convert a random jar into a binary, and if you used Java it's hard to imagine not using some third-party libraries. I don't think such a tool could exist without becoming essentially another JVM.
Right, but Apple does ship versions of Python and Ruby that can access their Cocoa libraries. Apple would rather all developers use Objective-C, but that's just a way of ensuring that developers use Cocoa. Using Cocoa is what they're really after, technically speaking, because their real goal is for all Mac applications to use the same toolkit, look nice and behave like other Mac applications.
I promise you Apple doesn't care if Swing applications look similar to Mac applications since they won't behave like Mac apps due to not running through Cocoa. I bet Apple would be happy if those apps just never ran on OS X. But they have in the past provided a way of using Cocoa through Java. Apparently the Mac Java developer community had enough of a clue to realize that using Cocoa is a great way to restrict your app to one platform and miss the whole point of using Java in the first place.
Apple's special JVM was really just a way of trying to sneak Java developers into Cocoa, but it never really worked, so at this point, it's probably in Apple's best interest to just provide a stock JVM so people who really want to use Java can and let Oracle worry about whether or not Swing apps look like Mac apps. In general, Swing app usability is damning enough that Apple can just leave well enough alone and their customers will want Cocoa apps or Swing apps that have been engineered to look and behave a lot like Cocoa apps anyway.
Drupal had a similar problem back when I was using it. They claimed to support PostgreSQL, but all the plugin authors wrote MySQL SQL, and it took a lot of manual effort to get any plugin to work with a PostgreSQL-based install.
What's wrong is that the OS is a general-purpose piece of software, and it is designed to guarantee relatively good performance across a wide range of use cases. However, databases are a very special case and as such they are able to make better guesses about when and where they are going to need their data. The OSes we live with are a hodgepodge of hardware abstraction and conceptual abstraction. This is one reason exokernels are so interesting to me, is because they should give you an OS built out of layers, so if you just need to treat all HDDs as the same kind of thing, you can do that, whereas if you need a filesystem for conceptual clarity, you can do that too, and these ideas don't stomp on each other's toes.
What they're missing is the built-in idiot-easy form designing.
I'm speaking as a major PostgreSQL believer. One of my best friends was a beltway bandit in the 70's-90's. He calls GUI application development "the programmer's guaranteed employment act." He's definitely a fossil, and he made all his money on dBase and FoxPro. Neither of these tools are particularly amazing, but they do make it easy to write fairly simple databases with fairly simple visual forms (think ncurses).
There is a strong tendency in our profession to break systems down into a set of components and then elaborate those components. I am a web developer with a strong RDBMS background. I find that I can offload a great deal of the work to the database and it's not much effort for me. I find that, on the web, I only need a designer's input for a fraction of the time I would if I were doing a GUI application. This is because we've elaborated these components. FoxPro gives you a pretty stripped down, procedural way of dealing with the database. I haven't seen what its GUI frameworks are like but I'm willing to bet they're also fairly also stripped down and procedural. I have web developer friends who are not conversant in SQL. They are very excited about the "NoSQL" "databases." I think this largely has to do with the fact that when you misuse RDBMSes, they aren't that fast, and the kind of people NoSQL appeals to are already doing that work in their application. For them, it's not taking on a burden they don't already have. To my friend the FoxPro user, NoSQL just looks like even more work he didn't used to have to do.
The people who were brought up in simpler times find simpler tools better because they have to learn less and they can just sort of dive in and start getting shit done. But for me, I already have learned these tools and can use them deftly. To me, using FoxPro is a bunch of tedious manual labor because I can make a complicated SQL statement. Also, to make a nice application now is a lot more work than it was twenty or thirty years ago. It has to look nice and have a good metaphor as well as do its job quickly and well. My friend can certainly bang out a FoxPro application quickly, even quicker than me most of the time, but it won't be the app you want to use, because it also looks like it came out of that era.
As far as I can tell, there will always be a market for every kind of software developer. We've reached a critical mass where pretty much every technology now has an installed base of users for whom that technology is essential. My friend could certainly find work in FoxPro, though most of it seems to be on the east coast. But demand is low enough that he would have to relocate, which isn't the case for me as a web developer. It's the same thing with MUMPS. If you know it, you can get a job working for some hospital or medical company, but you are unlikely to find a company in your zip code that needs it.
To return to your point, MySQL and PostgreSQL aren't missing anything from a database perspective. From a FoxPro perspective they're simply missing simplicity. But simplicity isn't something you can just drop in.
The first problem on my mind right now though is that nearly all widely used relational databases are built with a lot of algorithmic assumptions about the disk. They spend a great deal of time ensuring that they only fetch the minimum number of blocks, and many higher end databases go to lengths to ensure that related blocks wind up near each other on disk, implement block caches and things like that. A lot of this is done to mitigate seek time.
With SSDs, seek time is basically constant and there's no need to minimize it, though you still want to minimize number of fetches. However, all SSDs on the market (AFAIK) exhibit a profound performance degradation once the disks start having to erase blocks. Most disks postpone this as long as possible with an internal copy-on-write mechanism, but it's not uncommon for write speed to dramatically decrease once every block has been written to once. So there is a serious need to eliminate unnecessary writes and minimize necessary ones, which is not something most relational databases have put much effort into.
I fully expect that in a few years most databases will have a tunable parameter for, am I dealing with SSDs or traditional HDDs, and will make appropriate optimizations for the type of disk, but I wouldn't be a bit surprised to hear that their performance improvements degrade sharply in a year or two when all of their array's blocks have been touched. At the same time, I think this area is ripe for exploitation by database vendors. I also wouldn't be surprised if the gap between SSD-backed and HDD-backed DBs were made much larger by software improvements rather than hardware improvements over the next few years. It'll be interesting to see.
We use TWiki here and it does come with a visual editor which the non-technical types can use.
The chiropractor in the small town I live in used to have pamphlets around the office explaining how depression, the flu, and acne are caused by spinal misalignment. I'm guessing they aren't printed just for him.