As someone who programs in Pick/D3 still every day (a skill I picked up working for a company with a legacy product), as well as having had worked in pretty much every SQL product that exists, I am both startled and amazed to see it mentioned on Slashdot. I think this is the first time I've ever seen anyone mention it!!!

And I am in agreement - Pick was something truly different which could have been as big as SQL - multi-value, "NoSQL"-ish which still had a query engine, fast, little to no maintenance, loosely structured among other things. Unfortunately, due to the marketing practices of the company that made the product (now Tigerlogic), the former leader (Dick Pick... what a guy..) and various other corporate cultural issues, it has languished as an artifact of history.... but it still has important lessons to learn and teach, and it still runs a lot of systems!

For that matter, while some today don't realize it, many NoSQL databases today bear a startling resemblance to systems like Pick, MUMPS, Cache, Universe, etc.

Ok, fine, you don't want us to have unlimited plans anymore.

If a customer has an unlimited plan (grandfathered in), and Verizon ceases offering it, what will they offer in return?

It sure would be nice if common practice was, when they take something away, they give you something in return.

What is the exchange? Lower rates/costs? Better network performance? Higher throughput?

Don't have anything to give after you take away "unlimited", Verizon? Then give the customer the reason you MUST do it. Prove to the customer that this is necessary, at the very least.

Show the customer a convincing, legitimate reason to stay, or they're going to wonder why you're simply "taking away from them".

Don't just take and take and take and take - that's what the customer doesn't like.

The customer is not stupid, but can easily be misinformed, and perception is everything.

I was interested in the sub's specs - the glass cockpit "dome" is apparently made of quartz. The only other subs with these kinds of domes that I've seen that can get to these depths without being crushed by the enormous pressures use some type of borosilicate glass. My understanding is the only difference between the two types of glass is the amount of silica (SiO2) in them.

Looks like a race to the bottom - I think the other company was Triton submarines that used the borosilicate glass domes. Whatever it is - it is fascinating to see the use of these materials which actually get stronger under pressure!

To take CREATE VIEW one step further, I was dreaming about something like this - given guaranteed always on network connectivity with plentiful bandwidth (I know, unrealistic, but just follow me for a moment), imagine that the view actually existed in the software layer separated by the network from the database. That the view could exist on the client, but the data on the server at all times. This is what I mean by disconnected - not so much that the data has to live on the client, but that the view is not database-resident.

Imagine running a CREATE VIEW statement that actually created an access method to the database that LOOKED like an object model. Heck, should be no problem, after all this is kind of what ORMs are trying to do - create an updateable "view" of the database for the client to use to update the server. Heck, here's a crazy idea - why can't the server update the "view" in the client, if we always had an open connection (see long polling?). Well, at least if the impedence mismatch of needing SQL to get from the code to the database was not there (rather an "object interface"), things are a little nicer.

Also, imagine a dynamic object, for example - one in which you can just set the value of a property, but in the programming environment, you can intercept that operation and see oh, look, this is Person # 123 and the property Last Name is being set, why, I'll go update the database while I update the object. Imagine all changes to data in objects going straight through to the database instead of going through a complex ORM layer (yes, of course, too much traffic to the database with millions of little writes?). This is what happens when the database, and the code, are directly connected. And no, the object doesn't have to LOOK like the database, although it can. Just like a view doesn't need to look like the tables it represents, although it can. Also note, updateable views are possible when a SQL engine can determine how to decompose an update and update related tables (although almost no database can do it when there are joins involved). So updateable objects that work like views seem totally doable. Ironically, already kind of done if you consider MUMPS for example, which had persistent storage by simply going: SET ^Person("123","LastName")="Bob", right in the language itself - just didn't look like a strongly typed object.

Ironically, I am actually a strong relational supporter, and have personally built at least one major relational database that scaled up to several terabytes in the area of large scale fraud detection. So, I am familiar with, and have a deep respect for Boyce, Codd, Chris Date, the relvar, relational algebra and set logic, Inmon, Kimball, data warehousing, OLTP vs OLAP, to name a few.

I am not a "node.js" front-end web cowboy with no understanding of database technology..... and boy, did I have my fill of database replication, in SQL Server, specifically. It worked, but it could be a bear at times. I urge you - if you haven't looked into what the latest distributed relational databases can do (or even go back to Teradata which is expensive but has a long history of distributed scaling) - ACID is totally possibly, performance can be increased, and it's nowhere near as difficult as replication - it DOES work. It turns out that relational operations work really well at being decomposed and distributed in a similar fashion to map/reduce algorithms (see the work of the late Dr Jim Gray, a former top database researcher from Microsoft).

Furthermore, I am currently working a job using a legacy MULTIVALUE database - for fun, if you haven't read up on Pick/D3 or OpenQM, check them out. Most people don't even know what a MV database is, but to understand where I'm coming from, you'd need to know more about the history of what well could have been if a few technology choices had been different in the past. Not to say I'm unhappy with how things did turn out - I think every technology is unique and interesting, but I have a fairly reasonably different viewpoint because of working with older technologies, and newer ones both.

I also agree that, I personally feel that the acronym NoSQL (which we have been told really means "Not Only SQL") was actually really something different, a bit of an underhanded jab - I think they should have called in NoRelational - because that to me seems to be a deeper crux of what is really going on here. After all, SQL is a query language - who cares what database it runs against (although it clearly was designed with relations in mind), but that doesn't mean it necessarily had to run against a relational database. Ultimately, NoSQL is another technology for the toolbag, and a new direction for people to research.

I am interested in what could be (as evidenced by my "dreaming"). I see, based on our short memory of past history, our long recent successes with relational databases, and the new developments in NoSQL databases, a new possibility - some sort of hybrid which is a mix of technologies, and something that truly can achieve a lot of aims that we all have (distributed systems, connectivity, less mismatch, data integrity, etc). And I see this possibility manifested in the kind of thought that happened in this Opa project. New thought should be encouraged, not discouraged, and hopefully, these new thoughts root themselves in solid solutions and learn from the past as much as they look to the future.

We're not talking about views that live in the database. You don't "create view" in C++, but in the end, aren't objects just structured data + behavior? Objects can act as a bridge to data which gives it meaning through structure, and function. Map data structure (in my programming language) direct to data storage (in my database), with little in between, even if my data structure is on one physical machine, and my storage is on another.

It depends on how you define ACID. You can have an ACID transaction happen in a database on your phone, which then syncs to a database on your server with an ACID transaction. Other than a time delay in the transaction, what is the difference? I mean disconnected more in the sense like, in this case, a data structure is really just a direct map/representation of a model in a database. In that kind of scenario, when the connection between database and application is severed, yes, you don't get ANY transactions, but maybe you could work with disconnected data and sync up later. Furthermore, ACID and DISTRIBUTED data works - see any massively parallel relational database implementation like Teradata, SQL Server Parallel Datawarehouse, MySQL Cluster, etc.

Well, of course they are not the SVOT (single version of the truth) if there are two copies of one piece of data. However, if the data I need is in my disconnected database, and it synchronizes with an online database as soon as one is available, it's hard but not dellusional. Plenty of apps try to use offline storage as a cache when disconnected from the main data store, for example.

Yup, so now give me lots of implementations and make them easy to use.

That's probably true in some cases, but I wouldn't want to throw the baby out with the bathwater - if you have control of the REST stack, you can expose anything you want from your application code or your database, as long as you follow REST principles.

That's not necessarily true if your code is the interface to your database and if your code enforces the necessary constraints so that your database can play dumb. But generally, yeah, if you don't structure and define rules for your data (schema), then sure you will have problems

Hmm, I don't know about you, but the singularity happening is cool by me. I mean, I'm not saying it will or it is... but it would be cool.

That's why it's a dream... but all progress depends on the unreasonable man!

It's important that we don't forget the past, but also that we open our minds to new possibilities in the future. I agree with your sentiment- I don't like "the next shiny widget which really just reinvents the wheel" kind of thinking either, and I certainly won't defend it.

That said, I think things like Opa represent a nice take on abstraction in that the mismatch between the technologies that are being interfaced is conceptually much lower (data structures <-> data storage with less in the way), so the necessary abstraction is less complex. It's nice to see it working for them. Sure there are some glaring oddities, like why call it ORM if there are no objects - but I think it's the inspiration, not the implementation that matters.

If I spent all day writing C or assembly operating in my own little world on my own timetable, I could build anything I want, interface it however I wanted to, abstract it however I felt like. I could do that even in higher-level languages. But "application developers", operating at high levels of abstraction, would be quite pleased with any improvements in the underlying abstractions that makes their code/systems faster, less complex, and/or conceptually easier to understand. That is probably even true of low-level programmers.

This kind of reduction in complexity seems to be happening a lot lately - look at Windows 8 - Microsoft is doing more work in C++ and lower levels and seems to be moving more abstract concepts to a lower level in the stack, and also encouraging use of more concrete programming concepts. From the outside it looks like the moves they are making are adding a lot more abstractions and complexity, but I think that's partially because they are trying to maintain previous ways of doing things, while advancing the core.

In my opinion, the more we can reduce abstraction over the long run, the better.

...interesting things happen. I have always felt that the object-relational impedance mismatch was a mental block holding back the redevelopment of something we actually used to have (integrated programming tool/database platforms - look at things like D3, Cache/MUMPS for example).

Now, we know we can separate the representation of data in a database from the data itself, but the two can look identical, with a middleware as the go-between between the programming tools and the database. Or they can co-habit.

It doesn't matter what you call it, but I like it.

My dream environment = perfect representation of data in flexible/dynamic objects in a programming language, disconnected or connected to databases with nearly identical, flexible and dynamic data model representation, with a powerful query language (SQL-like), the scalability of the new generation of shared-nothing architectures, simple connectivity options (simple sockets all the way up to REST) and the reliability of a relational database's ACID properties.

It feels so close!

Maybe somebody needs to connect the people who discovered this with the folks at the Taub Institute and Harvard as mentioned in this previous Slashdot article - "Alzheimer's Transmission Pathway Discovered". My grandfather (RIP), one of the smartest people I knew and loved dearly, suffered at the hands of Alzheimer's/dementia. I am not a scientist with enough knowledge to make a difference here, but I sure wish I could do something other than donate $$ to the researchers to help us win this battle. I'm just hoping with fingers crossed that the right people are connecting - there have been a lot of interesting discoveries - and that if the solution is found, it is made accessible and available.

Thank you for inspiring millions and helping make some really cool dreams into realities.

Does the world still need "classic" Star Trek, the story that not only entertained us, but fueled the imaginations of many?

For that matter, the proprietary mobile "app" world sometimes makes me feel like I'm sadly regressing to the Internet as seen the way some application wants me to see it (not in it's native format of HTML), an uncomfortable feeling that reminds me of what it was like to browse the web with the AOL client years back- just a lot bit more modular. The "free native" Internet allowed for a lot of openness (view source, open protocols, for example) and experimentation - something that before was hindered by a single "UI" design and single infrastructure before.

That said, it's not like the new "app" world is all bad - there are some standards there like those set by the Apple App Store and supporting iOS framework that have allowed a ton of cool apps that are simple and effective to flourish. I just dislike the claustrophobic feeling of getting stuck in any one person's way or view I am getting so much these days.

Presumably a balloon would not even need to be detonated - it could be made to explode from the pressure changes in the atmosphere as it ascends - although it may not release its particles at a desirable altitude in that model. Then there is the release of whatever gas was used (helium) in the balloon, although I don't know what effect that would have on the atmosphere.

Did anybody else read this and think of the singularity? I sure did.

http://en.wikipedia.org/wiki/Technological_singularity

SixD

I like this direction of thinking, personally.

Some of our best and brightest minds in space exploration today have already pointed out that the International Space Station represents a test-bed for sustainability in many ways, and an ecosystem controlled and defined by human activity. Sustainability is one of the greatest goals for humanity, if not the greatest!

Also, to think that all the major advancements in space exploration have happened in, what, the last 40-50 years? What could we do if we really put our minds to it? It's hard to know what benefits could be had, and I think that's always been a challenge - showing the present value of something whose benefit is reasonably unpredictable. We need entrepreneurs and risk-takers to take stabs at these challenges because it is these groups of people who help us quantify, discover and explore what the actual benefits are. Lastly, it's not about failing - it's about what we will not learn by not trying!

This is why things like "Google Labs" exist, in my opinion. Just imagine if every company had a formal "Labs" entity within IS/IT. The only problem is that being able to have a free-flowing anything goes R&D-type department (which is separate from your ordinary every-day "structured" or process-based type department) usually requires corporate support, a company of a certain size, enough people, or enough discipline to separate R&D time from planned/organized/structured time.

I believe the core purpose behind Agile methods was originally to support what comes naturally to most developers, which is light-process and getting things done incrementally (which as I recall, is even a practice used in total quality management/TQM). So, really, many of us do "agile" intrinsically in some form, unless you work in a monolithic situation, a large company, one that makes complex or very expensive products that require lots of up-front planning/documentation, or one that requires traditional SDLC/waterfall/project-planning type processes.

If you built an aircraft carrier using agile methods, vs traditional project planning, I wonder, what would the difference be?

SixD