You shouldn't put too much in performance numbers, scalability, query language, procedure language, or administration tools (they aren't even close in some of these). Neither MySQL nor PostgreSQL are anywhere near the top. You need to make an argument based on price (and even then, most companies would rather drop $50,000 or more on a better database).
I am assuming you want pure reporting speed and that there will be a couple of batch additions and updates a day. Is this a correct assuption of the usage pattern, or am I off?
In that case there is a whole class of databases -- are better than traditional sytle -- of column oriented databases that will smoke Oracle or PostgreSQL. Fastest amoung them is probably KDB. It doesn't seem like there is that much information in the database, so maybe even a memory resident database would perform better.
I still don't understand, why PostreSQL? It is a cost issue? It certainly isn't a decision based on performance.
The entire age based system is completely arbitrary anyway. If I'm 17, I'm immature and shouldn't be allowed to play violent video games, but the day I turn 18 the maturity fairy visits me and I can realize I shouldn't actually go out and slaughter people?
There are two massive strawmen in this. First, nobody claims that at some age you gain magical understanding. We would really like to make laws based on maturity of action, conceptual ideas, and ethics. However, that isn't possible and the only factor that we can test is age, so an age is determined by then this behavior should have set in. Also, there is idea of aiding parental supervision and that legally stops at 18, so that seemed like a reasonable age.
Second, nobody is claiming that viewing violent media will turn you into a killer. The claim is that violent media relaxes attitudes towards violence and detaches them from making a negative value judgement of it. This may in some trigger violence urges, however, that isn't the important claim.
More credit should be given, by the time they're teenagers most kids aren't ignorant lumps of clay for the media to shape.
That just isn't true, though. A multi-billion dollar advertising industry knows that images you feel people affect them. The often claim is that mass-media had induced shitty culture in people. That belief isn't harmonious with this one.
It is a strawman that people think that playing a violent game will make you go out and kill people. The claim is that the excessive exposure to violence desensitizes people to it. In some this may lead to increased violence. In others it changes their attitudes of how they feel about violence.
Although K really isn't a scripting langauge (neither is C), results were done for it, too (being faster and having less code). There is also a shallow introduction to K on Kuro5hin.org.
If you want to deal with vectorized data, then use a vector language. Language, such as K are made for that and are much better than Perl at vector operations. It really doesn't make sense to use Perl for it. K is a smaller language, it is simplier, and if you are used to mathematical notation it is probably easier to learn.
I even use K as my favorite general purpose language, I like it so much. There is even a simple introduction written about it at Kuro5hin.
Can the editors please define acronyms in submissions. Most of us don't know what the hell you are talking about. The/. editorial staff is a joke sometimes.
My background is in various AI fields, and I would love to work at a game company. I don't really play too many games, though. The name (along with names such as the "Progammers' Guide" for a software developers' union) really turn me off. I am not into fanatasy and really don't get why it has to be pushed so hard by people in my choosen field.
(the ascii-line-noise example also illustrates this - because all those symbols are already overloaded with lots of meanings)
The overloaded nature of the symbols in K has been discussed on the list, actually. The next version of K that has been "imminent" for at least 6 months now, as I am understand it, will remove that. No more overloaded operators. Another major change will be that the syntax processing will be lifted into the language and mutliple overlays will be possible. Two of the provided ones will be the current symbolic nature and another that uses english words.
Maybe it was made for people who simply aren't exactly like you. People are different. Some people may even like the fact that APL-like languages make it easy to use vectorised operations. They may come from VB and realise how much error-prone make-work all those loops were, and PREFER K.
I started off as a big Lisp/Scheme fan. When I first saw K (my roommate showed it to me) I laughed and couldn't understand wanting to use it, so I can understand other people's reluctance. After digging into the language for about 2 weeks, though, I was hooked. I now use K for 80% of my work and C for most of the rest (thankfully, there is a simple K-C interface).
I don't think anybody would argue that precedence rules would be bad if you only had to deal with the four major arithmetic operations. However, as soon as more operators are introduced the complexity quickly becomes not worth it. As proof look at what people do with C: they are encouraged to not even learn what the precedence levels (and associativity of each level) are and just use parenthesis.
The creator of K once posted a list of "you know you are getting better at K when..." to the mailing list. One of them was "You know you are getting better at K... when zip expands."
I really don't know the nature of celestial simulations. I used the think the same about many string processing routines, too, and that just proved that I didn't know how to vectorize the problem. So my history of knowing that is vectorizable isn't the best.
By "plenty" you mean APL, J, matlab, SAS, and a couple others? Well, I think that K has them beat in most categories. For simplicity trying to compare K against any of them is silly. J is a monstrously difficult and complex language to me. SAS has these huge tomes for manuals. In all fairness, it has a very large library, and that is most of the documentation. However, SAS (and matlab) are far more limited in aplicability. K is a general pupose language and is used in many different fields. You would not see a database written in matlab, because it is the wrong tol. However K is the right tool for that, and K is also the right tool for stock market analysis, and data mining, and even something like parsing is very simple in K. After having to learn SAS and other small specialty languages, I would rather just learn K once.
If you try to compare on performance considerations, it is also hard to beat K. I don't know clockins on matlab, but K for complex problems will run as fast (and often faster) than C. Beside just making array processing easy, it gives you excellend memory management and manipulation.
As with any language, there is a classes of problems that are not appropriate, but for K that seems to be a very small class. Celestial simulations might just be a problem that isn't easily vectorizable. Or maybe matlab might run it faster (I doubt it, though). The only way you really learn about the costs and benefits of a particular language is by using it, though.
I think I just understood what you meant concerning updates. Yes, in KDB batching updates together in bulk is much more efficient than doing singular updates.
In K you always want to deal with large chuncks of like data: bulk good, scalar bad. However, there seems to be a very small class of problems where you can't write an array version of them. And this array programming methodology happens to lead to very fast code, too.
Yes, at some level this was an attention seeking post. I try to pump up the language whenever I get a chance to because I am amazed by it. This should be one direction the future of computer languages (and databases) takes. I still have a hard time grasping the simplicity and power in the language.
If there are any other K "trolls" (probably better called Kx shills... I'll admit to that one) here I would be surprised. I thought I was the only one.
I wasn't seriously expressing disbelief at him not including every language (especially unknown ones like K). I understand that the work it takes to do these things (and the tedium). However, maybe somebody will see this and next time they need to do something that fits K, they would think about it for a second... or maybe somebody will see this, become interested, and go learn K and use it in the future. That is how I became hooked. I used to use c, java, anc scheme (especially scheme and lisp) for everything. Now I use C when necessary and K for most other things.
Actually, I have never bothered to look at that code before (from the readme, I think), but I can tell very quickly what it does.
K is directly translatable to English (and there is a program that does it). It does this because each symbol is given a short English name (sometimes two). All K is parsed form right to left, so there is no baroque precedence rules (3*2+1 is 9 not 7).
Taking from the code sample:
v*(2*!:'x+1)-x:1_!#p
This is read as:
v times quantity 2 times enumerate each x plus one end, minus x, where x gets 1 drop enumerate count p
Break down the right side, what x is, a list from 1 to one less the length of the list p (i.e., if p was 5 elements long, x would be a list form 1 to 4). Now the part in the parenthesis is a list, where each list element is another list, but of numbers from 0 to 2*(x[i]+1) by 2s. So the first element of this list is a list with just 2 in it. The next list element is a list of 2,4, etc... Well, then you multiple all these values by v.
This follows in Dr. Iverson's tradition of executable notation (see the J website for more information). What you are writing is a formula to manipulate data. It only took me a couple weeks to get used to the notation. After that my roommate and I were to speak across the room to each other in K.
It really is all just a matter of getting used to things.
In KDB, unlike many other databases systems, normailization will increase speed. Other multidimensional dbs will try to denormalize data to run faster, but KDB isn't like that.
KDB really has two query language (and a stored procedure language): SQL92 and KSQL. SQL92 is translated ti KSQL, a more featureful and simplier version of SQL. In KSQL joins are implemented as pointer chasing and very cheap: "Parent.Child.datum" will join tables Partent and Child on the key and return the datum field of table Child. No more complicated join syntax.
I was only trying to impress the point of operating of bulk data and how it related to the test this person performed with C, Java, etc...
Concerning what you have to say about OLTP processing, you might want to read Dennis Sasha's High Volume Transaction Processing paper. You are right on, as far as the architecture is concerned. There is a entire different set of concerns with KDB, but there are always tradeoff. This is too far offtopic to really go into any detail, though.
It is interesting to see somebody else with as KDB experience. Not a common system (but we can hope it grows in the future).
KDB performs as well as it does because of this. It inverts the tables and store them by columns instead of rows. The K language goes along with that principle and has special meta-operators and operators for dealing with large amounts of data of the same type.
K is a high-performance array language. It is based on APL and Lisp. It really shines when crunching obscene amounts of data. This seems like something that would be perfect for the language.
The proof of K's speed lies in KDB, a database written entirely in K. On TPC benchmarks is spanks Oracle and other leading databases (including some amazing scaling across processors: simple table scans with 2.5 billion rows take 1 second and multi-dimensional aggregations take 10-20 seconds).
There is a quick and dirty intro to K over at Kuro5hin.
Slashdot Mirror
You shouldn't put too much in performance numbers, scalability, query language, procedure language, or administration tools (they aren't even close in some of these). Neither MySQL nor PostgreSQL are anywhere near the top. You need to make an argument based on price (and even then, most companies would rather drop $50,000 or more on a better database).
I am assuming you want pure reporting speed and that there will be a couple of batch additions and updates a day. Is this a correct assuption of the usage pattern, or am I off?
In that case there is a whole class of databases -- are better than traditional sytle -- of column oriented databases that will smoke Oracle or PostgreSQL. Fastest amoung them is probably KDB. It doesn't seem like there is that much information in the database, so maybe even a memory resident database would perform better.
I still don't understand, why PostreSQL? It is a cost issue? It certainly isn't a decision based on performance.
Second, nobody is claiming that viewing violent media will turn you into a killer. The claim is that violent media relaxes attitudes towards violence and detaches them from making a negative value judgement of it. This may in some trigger violence urges, however, that isn't the important claim.
That just isn't true, though. A multi-billion dollar advertising industry knows that images you feel people affect them. The often claim is that mass-media had induced shitty culture in people. That belief isn't harmonious with this one.
It is a strawman that people think that playing a violent game will make you go out and kill people. The claim is that the excessive exposure to violence desensitizes people to it. In some this may lead to increased violence. In others it changes their attitudes of how they feel about violence.
No, the most modern language is K. Seriously. If you are writing a language it should be required knowing about. It's amazing.
Although K really isn't a scripting langauge (neither is C), results were done for it, too (being faster and having less code). There is also a shallow introduction to K on Kuro5hin.org.
I even use K as my favorite general purpose language, I like it so much. There is even a simple introduction written about it at Kuro5hin.
Can the editors please define acronyms in submissions. Most of us don't know what the hell you are talking about. The /. editorial staff is a joke sometimes.
"Cat got your tongue? (something important seems to be missing from your comment ... like the body or the subject!)"
Stupid slashdot.
Just look at how bad Notre Dame is viewed.
My background is in various AI fields, and I would love to work at a game company. I don't really play too many games, though. The name (along with names such as the "Progammers' Guide" for a software developers' union) really turn me off. I am not into fanatasy and really don't get why it has to be pushed so hard by people in my choosen field.
Name you organization after something in a fantasy novel. Great idea.
I don't think anybody would argue that precedence rules would be bad if you only had to deal with the four major arithmetic operations. However, as soon as more operators are introduced the complexity quickly becomes not worth it. As proof look at what people do with C: they are encouraged to not even learn what the precedence levels (and associativity of each level) are and just use parenthesis.
The creator of K once posted a list of "you know you are getting better at K when..." to the mailing list. One of them was "You know you are getting better at K... when zip expands."
I really don't know the nature of celestial simulations. I used the think the same about many string processing routines, too, and that just proved that I didn't know how to vectorize the problem. So my history of knowing that is vectorizable isn't the best.
By "plenty" you mean APL, J, matlab, SAS, and a couple others? Well, I think that K has them beat in most categories. For simplicity trying to compare K against any of them is silly. J is a monstrously difficult and complex language to me. SAS has these huge tomes for manuals. In all fairness, it has a very large library, and that is most of the documentation. However, SAS (and matlab) are far more limited in aplicability. K is a general pupose language and is used in many different fields. You would not see a database written in matlab, because it is the wrong tol. However K is the right tool for that, and K is also the right tool for stock market analysis, and data mining, and even something like parsing is very simple in K. After having to learn SAS and other small specialty languages, I would rather just learn K once.
If you try to compare on performance considerations, it is also hard to beat K. I don't know clockins on matlab, but K for complex problems will run as fast (and often faster) than C. Beside just making array processing easy, it gives you excellend memory management and manipulation.
As with any language, there is a classes of problems that are not appropriate, but for K that seems to be a very small class. Celestial simulations might just be a problem that isn't easily vectorizable. Or maybe matlab might run it faster (I doubt it, though). The only way you really learn about the costs and benefits of a particular language is by using it, though.
I think I just understood what you meant concerning updates. Yes, in KDB batching updates together in bulk is much more efficient than doing singular updates.
In K you always want to deal with large chuncks of like data: bulk good, scalar bad. However, there seems to be a very small class of problems where you can't write an array version of them. And this array programming methodology happens to lead to very fast code, too.
Yes, at some level this was an attention seeking post. I try to pump up the language whenever I get a chance to because I am amazed by it. This should be one direction the future of computer languages (and databases) takes. I still have a hard time grasping the simplicity and power in the language.
If there are any other K "trolls" (probably better called Kx shills... I'll admit to that one) here I would be surprised. I thought I was the only one.
I wasn't seriously expressing disbelief at him not including every language (especially unknown ones like K). I understand that the work it takes to do these things (and the tedium). However, maybe somebody will see this and next time they need to do something that fits K, they would think about it for a second... or maybe somebody will see this, become interested, and go learn K and use it in the future. That is how I became hooked. I used to use c, java, anc scheme (especially scheme and lisp) for everything. Now I use C when necessary and K for most other things.
K is directly translatable to English (and there is a program that does it). It does this because each symbol is given a short English name (sometimes two). All K is parsed form right to left, so there is no baroque precedence rules (3*2+1 is 9 not 7).
Taking from the code sample:
This is read as: Break down the right side, what x is, a list from 1 to one less the length of the list p (i.e., if p was 5 elements long, x would be a list form 1 to 4). Now the part in the parenthesis is a list, where each list element is another list, but of numbers from 0 to 2*(x[i]+1) by 2s. So the first element of this list is a list with just 2 in it. The next list element is a list of 2,4, etc... Well, then you multiple all these values by v.This follows in Dr. Iverson's tradition of executable notation (see the J website for more information). What you are writing is a formula to manipulate data. It only took me a couple weeks to get used to the notation. After that my roommate and I were to speak across the room to each other in K.
It really is all just a matter of getting used to things.
In KDB, unlike many other databases systems, normailization will increase speed. Other multidimensional dbs will try to denormalize data to run faster, but KDB isn't like that.
KDB really has two query language (and a stored procedure language): SQL92 and KSQL. SQL92 is translated ti KSQL, a more featureful and simplier version of SQL. In KSQL joins are implemented as pointer chasing and very cheap: "Parent.Child.datum" will join tables Partent and Child on the key and return the datum field of table Child. No more complicated join syntax.
K is written by the same person that orignially developer A+, Arthur Whitney. I have never used A+, but Arthur says that K is much faster than A+.
Concerning what you have to say about OLTP processing, you might want to read Dennis Sasha's High Volume Transaction Processing paper. You are right on, as far as the architecture is concerned. There is a entire different set of concerns with KDB, but there are always tradeoff. This is too far offtopic to really go into any detail, though.
It is interesting to see somebody else with as KDB experience. Not a common system (but we can hope it grows in the future).
KDB performs as well as it does because of this. It inverts the tables and store them by columns instead of rows. The K language goes along with that principle and has special meta-operators and operators for dealing with large amounts of data of the same type.
The language is interpreted, too.
There is a quick and dirty intro to K over at Kuro5hin.
Some more links for more inforation:
Kernigan's benchmark test
more examples
Kx: the people who make K and KDB