Forgot your password?
typodupeerror

Comment: Re:No mention of seaside? (Score 1) 244

by Grapedrink (#26918807) Attached to: Web-based IDEs Edge Closer To the Mainstream

I think the parent is absolutely correct, seaside has been doing this for years with halos, code browsers, inspectors, search browsers, etc. You can also easily build your own because of how Smalltalk works (the dev UI uses Smalltalk and it is fully meta-driven by the language itself).

Maybe I am missing something, but I am not sure what you are talking about regarding seaside refreshing. If you had bothered to download, install, use seaside, or even read the documentation, you would know that seaside almost never does a full page refresh.

The whole point of the seaside framework is that it is stateful like a desktop application. There is no need to refresh the page. If you look carefully or take a peek at the code, it refreshes just the UI component you are working with, for example a code browser or halo.

You can change the actual URL via your components to create the illusion of switching pages, or even do a redirect, but the design used is to swap components in the UI as needed, not refresh the page. The page can maintain your state or even persist most parts of it long after your gone, so vs. almost every other popular web framework, there is next to no risk of losing your work unless you coded it as such. I don't think you understand seaside and how it uses sessions in conjunction with state management, script, and the web context.

FYI, seaside does use a lot of these "DHTML technologies." It also uses a ton of AJAX if you want, and does indeed support the back button (old seaside versions used backtracing for instance) quite well (better than almost any other AJAX framework, plus you can customize this behavior easily).

The one thing you are even close to being correct about is this technology has been around for nearly a decade. Actually, longer. Seaside is a continuations based web framework, and others have been around to some degree for awhile. Seaside took its inspiration from web objects for example.

Comment: Superman (Score 1) 224

by Grapedrink (#26914983) Attached to: Hubble Repair Mission At Risk

The real scape goat here is superman. If only superman would stop putting all those missiles in the way, we would not have this problem. And don't get me started about all those chunks of his tacky colored planet. Always blaming general zod, some sort of cosmic event, or something and never taking real responsibility. Don't litter.

Anyway, I think it's time we ask him to clean his room so to speak. If he can't do it, I guess plan b is some sort of friggin gundam laser.

Comment: Re:SQL is the problem, not RDBMSs (Score 2, Insightful) 344

by Grapedrink (#26851627) Attached to: Is the Relational Database Doomed?

Microsoft has CLR code running on top of MS SQL but it sucks performance wise. Oracle has Java. That's about as close as we have gotten, but both are just crutches.

Unfortunately, you are right that SQL is terrible and not going away. The status quo, industry, and marketing will make sure we suffer for years to come.

Comment: Re:Ummm what regular graph/object databases (Score 1) 344

by Grapedrink (#26851605) Attached to: Is the Relational Database Doomed?

You are misunderstanding me, but perhaps I was not clear. Architecture with the right hardware makes a difference of course. My point was it was no longer technically impractical to run certain types of databases. Certainly every database loves more hardware.

There are plenty of tuple and graph stores that support distributed transactions. There are also plenty that have not been updated, but just as many in the relational world. It is in the nature of graph and tuple stores to scale out in this way. Most of the major implementations already do this quite well and much more elegantly than any replication based solution in the relational world.

I am not sure what you are getting at here other than straying a bit off topic from what I was commenting about. Regardless, yes, I agree with you.

Comment: Re:Ridiculous (Score 2, Insightful) 344

by Grapedrink (#26851201) Attached to: Is the Relational Database Doomed?

I agree with you on a lot of points, particularly people coming up with stupid solutions and creating new problems, but how is the rest of this insightful? Sure, relational is a good general fit databases, but it sounds like you are saying the fact that you can query and modify it using something like SQL in most implementations makes it great?

Exactly how is that easier than some other ways, such as building an object database? Can't you just write a few lines of code that are far more expressive than any SQL ever could be in a language like Common Lisp, Smalltalk, Python, Ruby, etc? Isn't that more accomodating than a relational model which limits your options due to performance vs. flexibility vs. integrity vs. extensibility vs. scalability? How does SQL give you more ways to manipulate things than a map, collect, slice, reduce, anonymous function/lambda, etc?

I use both relational and object databases (preference to object dbs in all honesty). For an object database, my process both in use and development is to write and modify like it sounds, objects. Instances of objects in those classes are automatically stored for me and even in most implementations, class level data as well. I simply write my code and trudge along and do not worry about some ridiculous ORM. If I need transactions, I have them at the object level which I would want anyway even with a relational DB.

If I need a query, it is done in a well-known language that I used to write the application. I can of course see if there was no application, it might annoying to do this and relational can make some of that easier, but that is rarely the case. Further, I don't hit as many bumps where I need to denormalize my data to do reporting or data warehousing. I simply once again write code as normal to get what I want.

A great example is try storing an organizational hierarchy in a database. Query it for basic info such as a list of a manager and all subordinates and superiors. Now try to ask it for the full path between employees. Keep asking it questions about the hierarchy. In just about every relational db it is a fail. Oracle for instance even realized things like this and added "Connect By." Storing the data itself is a nightmare and you end up needing something like nested sets, self joining queries, cursors (never), handing it off to an application (aka relational failure), or materialized path.

You run into other similar problems where you see hackish solutions in the realtional world like table inheritance. Why have it if a relational database is so good? It is there because relational completely fails here, just like object databases fail elsewhere. There is no ideal solution, and for general cases both work great in my experience, even giving an edge for web applications to object dbs.

There are so many areas where either the relational model itself, or SQL fails. If you have not hit them, then you have not used relational databases as much more than a glorified spreadsheet. The amount of time I spend tuning my queries in a relational db is ridiculous, even for relatively simple data. Hints, denormalization, columns as rows, cursors, triggers, user defined functions, and other such devices are all crutches for relational dbs. Of course some of those are also caused by bad devs of course, but it need not be that hard in the first place.

Anyway, I am not trying to slam the relational model. Rather, I think you are wrong to say it's the best and most flexible. Like all things, it depends what you are doing, and in my own experience object databases have been far easier to work with and maintain. I must save months of work every time I use one, but general ignorance often forces me to use either object or relational. If people better understood the strengths of each and paid more attention to each specific task rather than marketing, we would all be happier. It's sad that complaints about tools for example are even valid points. If you market the hell out of something and it just becomes the standard for whatever reason, then of course it is going to win in areas like that. You would think with all the anti-Microsoft rhetoric around here, people would get it.

For now, I'll continue to use both and enjoy them for different reasons.

Comment: Ummm what regular graph/object databases (Score 1) 344

by Grapedrink (#26850947) Attached to: Is the Relational Database Doomed?

It seems like every time I read one of these articles, it is written by someone with no knowledge of what is actually out there. I suppose that is normally because anyone with enough time to mouth off on the internet in article or blog form is not actually doing real work. The rest of us are too busy, you know, working?

Anyway, as someone that has been programming, particularly against just about every major database platform out there, I can tell you that there has always been a battle between relational vs. other types of databases, most notably graph databases. Full disclosure: I am partial to graph databases, but that is because I find a lot of utility in working in pure code and I also apply graph theory to a lot of my work.

There is no silver bullet and each kind of database is better at certain tasks. Long ago, hardware made much more of a difference than it does today and was one reason relational databases "won" out. Other reasons include marketing, the development of SQL and other standards, and the ease of applying relational mathematics which are easy to understand. I spent most of my life working with relational databases as they were simply in my comfort zone, until I realized I needed to get off my ass and learn more than just new languages and programming techniques (and realized relational dbs were such a huge fail at tasks like traversing graphs, storing dynamic columns ala a CRM, etc).

Particularly when you look at older languages like LISP, relational was a great fit vs. graph. Since then, many factors have caught up and many more languages, solutions, and designs are out there. In the meantime, graph databases never went away. It seems suddenly since the outbreak of "web 2.0" frameworks and ORMs, a lot of people who don't have a clue about SQL, and especially databases in general of all types find it a great idea to go out and make their own or put some huge hack on top of a relational db, or perhaps worse, try to come up with something entirely new that is not based on fact or need.

I've played around with some of the databases mentioned above, and just like MySQL, they are mainly reinventing the wheel badly. The google implementation is the only one I have seen that is not completely shoddy, but color me somewhat unimpressed as well. FYI, just because xyz company such as google or IBM uses some product does not make it good. On the contrary, it's often a warning sign as big companies are often what keeps sites like thedailywtf going.

Regarding graph databases, I'm currently using Gemstone with Smalltalk for instance, and I have used it with Java as well. I can tell you it is great, but it is no panacea. It's been around forever like many of its competitors which are also noteworthy, but a side-by-side comparison is best left outside the scope of this comment. Gemstone lets me avoid any ORM overhead and I can write and maintain queries, transactions, reports, etc in one place; my code where they belong for my projects. It's fast as hell and I have collections with millions of objects and there is no slow down. In fact, I migrated many of my databases from other systems including Oracle, DB2, MS SQL, and Postgres, and it smokes them all, but I am confident that if I can think of a huge laundry list of tasks where the opposite will be true.

For instance, I can do reporting using Gemstone as I mentioned, but it is left up to me writing my own code or using a library, where in something like MS SQL, I can just use reporting services to do more complicated cubes, or one of the 100 enterprise reporting tools of various size for Oracle. It also sucks in some ways if you need to share a lot of data between applications because you have to make decisions about what do you want to split out and how to manage the memory and load.

Even Gemstone itself is not so bold as to presume there is no use for relational databases. You can build a SQL layer on top of it and it has many tools to move data back and forth between any relational db, for instance.

The authors of the article would do well to take a look at real graph dbs instead of crap like Harry Potter DB and Couch surfer DB. Just reading over the philosophy behind Couch DB makes it clear to anyone who has spent time working on serious databases that the devs don't have a damn clue. Go back and take some math, learn about b-trees and calculus, and stop writing stupid articles.

I am going to tear my eyes out if I see "yet another tuple store or graph db." Welcome to the last century, please try again. In Smalltalk and Common Lisp alone, we have tons of graph DBs, ranging from Magma to Elephant. Please stop making more cheesy ones that suck little snowflake, and doubly so stop writing ill informed articles. /rant.

Comment: Re:Java was a good idea (Score 1) 766

by Grapedrink (#23952035) Attached to: Does an Open Java Really Matter?

Java was a good idea, but there are lots of other languages that came before that had all the characteristics you describe. I would argue that most of those already did a better job than Java but were marketed or supported poorly at various stages.

I use .NET every day as well as Java and I agree MS did a better job. MSIL is a great concept, but unfortunately too much of the framework has deep hooks in windows to work in whole cross platform. Mono of course tries to solve this issue, but I wish MS would be a little more careful about how much they bake windows into everything.

I think the answer is to use the best language for the job and that means Java is long from being irrelevant given the wealth of functionality available to us today.

"The trouble with doing something right the first time is that nobody appreciates how difficult it was." -- Walt West

Working...