Why object oriented? OO is only one attempted solution to the larger problem of making programming easier on the programmer. It does this by trying to compartmentalize functionality and seperate implementation from usage. To see how OO has eschewed its own features just look at how delegation is favored over inheritance. This is a functional way of programming.
Functional language actually provide even cleaner semantics of encapsulation by first-class method passing; compare the interface semantics of this versus encapsulation and notice how simplier the documentation is. Even OO style is better done in a functional way than objects: calling a function to return a lexically scoped function that can then be passed around does far more to promote security and encapsulation than any OO language could hope to do (look at the ugly attempt of C++ to provide member function pointers). Even the arguably most OO language, smalltalk, does what it needs to do in a very functional way.
Besides functional there is the APL, now J and K, way of doing things. Array languages have shown for years that the most effecient way of operating on data is to slice the data column-wise as opposed to across object: doing an operations on the all first fields of your objects as opposed to doing an all operations on your first object. This even hides the amount of data from you. Perl is just now seeing this with hyper operators.
Instead of desiring OO, peple should look to see what the desired outcome is, then think rationally instead of going with the buzz-word compliant non-technical people.
He probably just drank too much. They should check the surrounding areas for empty kegs, togas, and the tar pit he was trying to get it in, but barely missed.
I am an ex-Ask Jeeves employee that was able to pull in a small 6 month contract in New York after months of looking everywhere. Now, I have spent almost 4 months looking for another job. The San Francisco Bay Area industry is very painful. I used to receive 10-20 calls per week from recruiters, now I never receive them and I am the one making all the phone calls. I am not one of the paper techies and have abundant skills in many area -- computational linguistics, information extraction and retreival, 7 years of Java experiences, databases, FreeBSD kernel development, and I could go on -- but nobody is hiring.
From what I've heard in few off the record conversations with hiring managers, companies are mostly in a looking phase; they are trying to feel out the market and see what kind of talent they can grab in their price range. I used to make over $100,000 a year, but now I am being asked how I feel about large salary cuts. I wish that I could say that things are looking up, but I still here of all this pseudo-interviewing going on. I sometimes call recruiters back a month or two later, and often the positions are still open. Either the companies are becoming exceptionally careful of their candidate choices of they are still not really hiring and feeling out the waters.
Mod this up. This is a great idea for a book. The problems would need to expose the working of Java and not be some random problem. There are great problems posted on comp.lang.lisp often, but these are probably better siuted to Lisp and often involved some novel Lisp feature that makes the problem absurdly simple. Something like that for Java (or any other language) would be great. Any there any out there for other languages already?
Can anybody answer a simple Perl6 question for me please?
What will be the difference between map and foreach in Perl6? And why are these going to be necessary when hyper-operators are going into the language? Can't these 3 be rolled into a single language feature; they seem to be the same to me.
This is why I hate bandaids. A bandaid, in the long term, only adds to the instability of a system. The correct solution is to make the code do what it is supposed to do and assert (panic the system) if it does something it isn't supposed to do. You might get a few panics in the short term, but in the long term you solve the problem. Permanently. Bandaids have the effect of causing problems to return and haunt you, sometimes for years. The dirty-cache-page bug was in the system for at least 3 years because of a bandaid.
This makes Matt my hero. I wish everybody (including me) believed and followed this more.
Re:OT: question about hyper operators.
on
Parrot Updates
·
· Score: 1
Yes, I see your point about wanting to stop evaluation periodically; laziness is a very important concept to allow. POE also sound very cool.
I do not use nearly as much Perl as I should, so I cannot comment as to specific Perl usages. However, you should never run out of memory with hyper operators, since it is too easy for the language to play swap games itself. This is my opinion, at least.
I too use very large data sets at work tied to databases. I do massive text processing tasks working as a core developer at one of the largest search engines on the web. For this taks we use a database called KDB.
Re:OT: question about hyper operators.
on
Parrot Updates
·
· Score: 1
Why would you opt for this explicit iterator syntax? Yes, this should be possible, but the language should really be much smarter than this.
This construct is so prevalent, that it should be more concise and optimizable. The example is of a mostly effect free statement. There is a single assignment necessary, back to the iter_a. That is probably not sematically needed and just used for "efficiency". But the iterator code requires 4 additional assignments, the two original iterator creation assignments, then the implicit state changes in the next function. This destroys the ability for optimization, complicates the code and increases source bloat both increasing the probability of bugs.
@a+@b
or if you like
@a.+(@b)
describes the same process and seems far superior to the 5 line alternative.
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 1
I wasn't calling the design of the interpreter dumb. I see how it could be taken that way. When I said dumb, I meant as in "dumb terminal" (somwthing without knowledge). The interpreter just seemed to look at an operation and do exactly what asked of it, not optimizing on the fly. A language called K from http://kx.com is a smart interpreter in the sense that it does semantically what it is asked, but not necessarily how you ask it to be done and it will blow C code out of the water many times. It is based on APL coolness and tricks, like not actually calculating the entire matrix being operated on, but only the section that is examined at the end.
sorry for the confusion.
Re:OT: question about hyper operators.
on
Parrot Updates
·
· Score: 1
Thanks for the answer. I think it is great that some other languages are finally learning about bulk data operators and adverbs.
The map examples show that Perl didn't quite go as far as I would have liked to see it go in that direction. These bulk operators are one of the features that make K a far faster language that C many times.
Is there a reason these hyper meta-operators only scratched the surface to the concept? Not trying to pick on Perl, but it just seems that other people have these examples as great ammunition to the argument that Perl is just a kitchen sink approach to a language: tossing the surface level of everything imaginable intoa language without trying to think of the underlying concepts and unite them, for example shouldn't map and hyperness be the same thing?
Re:FAQ leaves me concerned.
on
Parrot Updates
·
· Score: 1
And register based systems have advantages over stack based systems. An awful lot of stack thrash is avoided in a register system--with more temp values handy you don't have the extraneous dups, stack rotates, and name lookups.
And just because we have registers doesn't mean we don't have a stack. We do. (Several, actually) But registers let us toss a lot of the useless shuffling.
This is a weak answer. The obvious and correct response is that just because the program says rotate stack, you don't really have to do it, just remember that all data accesses after this point have to be shifted one index. Think of how efficient APL is at knowing just what sections of an array need to be computed and how they are: the flip operation never really results in the array being flipped, just noted that data access now begins at the other end of the array.
I am a very big fan of stack machines and I think that an intelligent implementation can be built that would blow the doors off any finite register machine: think of the cache hits you can have operating on such local data instead of the random access model. Two stacks can also be used, one for short lived data and one for long lived data. There has also been a ton of research on variable lifetime and scoping analysis to know where to keep data.
Why does everybody always want to make dumb interpreters and not something more intelligent?
OT: question about hyper operators.
on
Parrot Updates
·
· Score: 2, Interesting
First, let me admit a bias: I am madly in love with an APL like language called K. It has destroyed some unreasonable language biases I had in the past by being simply an amazing language. I have become used to the hyper operator concept, even though in K functions are called verbs and the hyper decorations are called adverbs.
My question is about how hyperness is applied to hyperness and how you make hyperness apply to only one side of the operator. Here are how you do things like this in K; are these possible in the new Perl? If not, these would be monumental omissions.
' is read each \: is read each left /: is read each right
Given the lists x:1 2 3 and y:10 20 30 and value z:100
x+'y is 11 22 33 x+\:z is 101 102 103 z+/:y is 110 120 130
but these can all be done implicitly, so you really do not need the decorations: x+y, x+z, and z+y are fine. This allows you walk down only a single list, while aggregating results.
Then you can also walk down the left then right sides of list by \:/:(left each right each).
You can walk down a list unarily:/ is read over and +/x is 6, or ': is read each pair and +': is 3 5.
There are other adverbs and they can be combined to modify each other arbitrarily. This winds up being an incredibly powerway to write programs. It removes the programer from the burden of flow control and compacts code enormously. Think of removing all the loops from your code and replacing them with a couple charcters, instead.
My point was missed, I think. If you can express the code concisely -- I can view the entire algorithm in one page -- then it is easier to see the big picture while walking through the details. You do not need to keep scrolling around the source. It is possible to site back and just immerse yourself in it.
I used to be the first one in line to help develop
coding standards. Now, I can't imagine wasting my time with them. I attribute it to being young and not having enough experience -- thinking that I had seen everything worth seeing. I have now seen some of the most beautiful code written in a
style that most people balk at. It expresses its beauty through its amazing ideas, exquisit symetry, and ingenious compactness. Looking at an entire interpreter written as a page of APL while actually writing in C.
I used to be a syntax bigot, but I have now seen the light (no, Perl is still ugly and unreadable with no redeaming quality, unlike the almost prefectly regular syntax and symantics of K). No coding standard can make good code, but good code could be prevented by coding standards.
Remember, only you can help prevent segmentation faults.
What difference does changing languages to most of you mean? 99% of everybody I see write a program in any language, writes C. I have seen hundreds of self-proclaimed "real Scheme hackers" use a dozen local variables in function; complex state is their definition of incredible code. I have seen even more "Perl gurus" write C with line noise, not understanding the unique features of perl that make it almost a concatenative language at times. I cannot count the number of C++ or Java twirps that have never seen the simple "TheEmptyTreeNode" as control-flow (or even worse, the ones that think it is poor style) -- these are usually the people that have never thought of the idea of removing explicit control flow from their code. Has everybody forgotten about the idea of constant data and as little state as possible, keeping with the Knuth maxim of code being as simple as possible (but no simplier). Has C wedged everybody's mind into thinking that every segment of code must be littered with control statements. Here is a challenge next time you code: write the code with as few control statements as possible, using every idiom you know and trick you can think of to remove all the if, switch, for, while, do, and related from your code and try to treat everything generically.
As much as I have a love-hate relationship with a certain APL derivative, they have the best programmers I have ever seen. They don't worry about performance, except when needed (and they have some extreme views of what is truly fast). They use a few big generic data structures and operate on them uniformly; they do not litter the landscape with a thousand different structures (that are all mostly similar and should be handled the same anyways). They write very terse code, where one screen of text can tell you the entire picture; nobody has to page through 30 pages of code to understand even the most complex operations. Why cannot more programmers be like this?
You are just using the wrong database, then. There is a 50cpu linux cluster (not Beowolf, but the native clustering to the database) that was loaded with 2.5 billion stock transactions. It performed very well using KDB (taken from kx.com):
on thursday jan 4, 2001 steve miano, ed bierly, keith mason and i
loaded 2.5 billion trades and quotes on a 50cpu linux cluster.
simple table scans on one billion trades, e.g.
select distinct sym from trade
select max price from trade
take 1 second
multi-dimensional aggregations, e.g.
/ 100 top traded stocks
100 first desc select sum size*price by sym from trade
/ daily high and close
select high:max price, close:last price by sym, date from trade
take 10 to 20 seconds
translating the data from TAQ to kdb took about 5 hours.
(steve had loaded the 200 TAQ cd's onto several disk drives.)
distributing the 100gigabytes over the 100Mbit ethernet took 3 hours.
(this cluster should probably have Gbit ethernet)
loading the database (k db taq.m -P 2080), starting 50 slaves,
connecting, mapping shared indicative tables over nfs, building
parallel partitions, etc. took.1 second.
This is from kx.com using kdb, what I and others consider to be the most advanced database and development environment in existence today. It has amazing performance and unmatched efficiency. It absolutely crushes Oracle, SQL Server, Informix, and MySQL (shown by their tpc benchmarks). Here is a cluster they put together.
on thursday jan 4, 2001 steve miano, ed bierly, keith mason and i
loaded 2.5 billion trades and quotes on a 50cpu linux cluster.
simple table scans on one billion trades, e.g.
select distinct sym from trade
select max price from trade
take 1 second
multi-dimensional aggregations, e.g.
/ 100 top traded stocks
100 first desc select sum size*price by sym from trade
/ daily high and close
select high:max price, close:last price by sym, date from trade
take 10 to 20 seconds
translating the data from TAQ to kdb took about 5 hours.
(steve had loaded the 200 TAQ cd's onto several disk drives.)
distributing the 100gigabytes over the 100Mbit ethernet took 3 hours.
(this cluster should probably have Gbit ethernet)
loading the database (k db taq.m -P 2080), starting 50 slaves,
connecting, mapping shared indicative tables over nfs, building
parallel partitions, etc. took.1 second.
Let's say you maintain this lexicon and related sematic network. You are responsible for ensuring that the network remains relatively balanced with respect to your users' input. Your lexicon is about 3 millions phrases. Now how do view correlation and the sizes of groups of similar questions more efficiently without a pretty colored graph drawing it on the screen for you. How to efficiently present this information to the operator (even a very skilled operator)?
It seems more intuitivc that data with a huge number of points would be too much for a human, but a computer would thrive on it. Human can do the easy, small sets usually just by looking at the plots.
It supports private and broadcast messages along with an command handler similar to IRC ("/nick" and such). This should handle over 10k messages a second easily. Here is the entire server source code (but me for the slightly longer client code if you care):
I think he means that Jesus lived a sinless, lawful life and was still condemned to die. He lived the perfect life according to God's high standards, even though he was tempted just as much as any of us. His faith so strong and without any doubt that he could perform miraculous actions.
After having lived such a noble life, He was caught by the authorities, accused of crimes He did not commit, then crucified to the death. He accepted this, knowing that this was his role in God's plan. If you were asked to be tortured and killed to help people the same people that were killing you, would you concent?
He gave his his sinless life so that we could be absolved of our sins. Why did he need to die for everybody else's sins; he didn't have any and eveybody else gets to continue living? Does this seem fair to you?
"When we were utterly helpless, Christ came at just the right time and died for us sinners. Now, no one is likely to die for a good person, though someone might be willing to die for a person who is especially good. But God showed his great love for us by sending Christ to die for us while we were still sinners. And since we have been made right in God's sight by the blood of Christ, he will certainly save us from God's judgment. For since we were restored to friendship with God by the death of his Son while we were still his enemies, we will certainly be delivered from eternal punishment by his life. So now we can rejoice in our wonderful new relationship with God - all because of what our Lord Jesus Christ has done for us in making us friends of God." -- Romans 5:6-11
Oh, maybe you meant "division my zero"... hmmm I don't know about that one.
When I posted, I was thinking of a particular time I needed to add an attribute to an element in the middle of a for-each. I remember it because it almost doubled the file size. One, of the many, relevant segments follows. Please, tell me how I am sucking. I am sure there is a better way of doing this (excure the t namespace, I use is because I am lazy):
Just as I inserted the "<a>" element, I was something as simple for the attributes. Since you treat a single tree and a forest the same when iterating over them, then why not for assignment, too?
Can I do this, hopefully, and have it constructe a forest of "a" elements?
<a href="//store/*/designer/url/text()">
<t:value-of name="//store/*/designer/name"/>
</a>
That seems to make sense, I hope: make "a" elements with "href" attributes, assigning "href" the text value of each "//store/*/designer/url" element. Take the value of all the "name" elements, placing them on the tree is the "a" element.
It would be the same thing that many other languages do with array assignment:
a[4 6 8 9 10]:= 2 3 2 3 5
meaning, do a scatter/gather assignment, giving the first 5 composite numbers the value of their largest prime factor.
(or imagine from c:
int a[0 3][0 3] = b[1 2][1 2];
assigning the corners of the 4x4 matrix to be the middle of another matrix)
How is transforming "" to "" different from transforming "o" to "X"? The biggest problem I had in XML on my first real project was spending an hour trying to output "There is 1 email message unread. Would you like to read it?" and "There are 12 email messages unread. Would you like to read them?" in some templatized way. You know, being dense: "There W X email messageY unread. Would you like to read Z?" Then I just hardcoded all the necessary strings (about half a dozen of them) and wrote the read/unread message totals in a scorebox. Screw english. Similar to the typical i18n hack people use for error messages.
Data transformation, isn't that all the game of is it? I want to munge well structured text. I wanted to transform this document:
+-----+
|ooXXo|
|XooXX|
|XoooX|
|XXXoo|
|ooXXo|
+-----+
into this document:
Replace the 'X's and 'o's with your favorite words.
They are both very regularly structured blocks of text with a few small precise rules. Why shouldn't a document conversion language be able to do this. Does you think that that mess of vague rules we can English would be any easier?
-j
< move along people. there's nothing to see here >
< something to placate the postercomment compression filter >
< these quotes stolen from Slashdot homepage >
< This page was generated by a Group of Trained Robots >
< This page was generated by a Team of Trained Geese >
It isn't Lisp. It is bad C. If you could find a full spec of the syntax and semantics of LOOP, I bet it is larger than the R5RS of Scheme. It is as if an evil C zealot snuck into the committee and forced his twisted philosophy on everybody: a terrorist plot against everything that is Lisp. The LOOP clauses are out of place in the beautiful forest of s-expressions.
Seriously, I have just never a use of LOOP where DO/MAP/REDUCE were not cleaner. The interactions between clauses is unbearably difficult to understand at times. If you are looking for peculiar interactions between the variables in the clauses, then use DO*.
The this what really annoys me with DO/MAP/REDUCE is that even though CLisp has a large standard library of functions, it is missing small very useful list generating functions: like generating a list of the integers from 0 to x. Then the need for defining some incrementation construct and iterating though it would be eliminated (not in the Lisp spirit, I feel); you could then just MAP across the list (a much more Lisp-ish style).
Besides all that, LOOP is just too complex, very poorly defined, and not extensible at all: very un-Lisp like.
-j
I'm glad you found it simple, nobody else does.
on
W3C Recommends XSL
·
· Score: 1
It took me a whole weekend to write Conway's game of life for my first learning project. My first real application was a simple xml logical to HTML converter. It took about 12 hours. The real catch was when I needed to ouput to be dependant on two different far away element bodies.
XSLT is not based on rewriting the XML tree, but the correct way to view the process is on creating an output tree from an input tree. Rewriting would imply that elements that were not specifically analyzed (how ever you define it) would still be in the output tree. Also, you cannot reference the structure of the newly constructed output tree, only the input tree.
Using XML was supposed to free you of the burden of doing much of the parsing, i.e., have a consistent format for the data. However in XSLT you still have a very large parsing responsibility. They choose XML to represent the top-level transformation structures, but almost every element and attribute that has content has its own mini-language format. XML is too syntax heavy for a pure XML-only syntax, probably.
Slashdot Mirror
Why object oriented? OO is only one attempted solution to the larger problem of making programming easier on the programmer. It does this by trying to compartmentalize functionality and seperate implementation from usage. To see how OO has eschewed its own features just look at how delegation is favored over inheritance. This is a functional way of programming.
Functional language actually provide even cleaner semantics of encapsulation by first-class method passing; compare the interface semantics of this versus encapsulation and notice how simplier the documentation is. Even OO style is better done in a functional way than objects: calling a function to return a lexically scoped function that can then be passed around does far more to promote security and encapsulation than any OO language could hope to do (look at the ugly attempt of C++ to provide member function pointers). Even the arguably most OO language, smalltalk, does what it needs to do in a very functional way.
Besides functional there is the APL, now J and K, way of doing things. Array languages have shown for years that the most effecient way of operating on data is to slice the data column-wise as opposed to across object: doing an operations on the all first fields of your objects as opposed to doing an all operations on your first object. This even hides the amount of data from you. Perl is just now seeing this with hyper operators.
Instead of desiring OO, peple should look to see what the desired outcome is, then think rationally instead of going with the buzz-word compliant non-technical people.
He probably just drank too much. They should check the surrounding areas for empty kegs, togas, and the tar pit he was trying to get it in, but barely missed.
I am an ex-Ask Jeeves employee that was able to pull in a small 6 month contract in New York after months of looking everywhere. Now, I have spent almost 4 months looking for another job. The San Francisco Bay Area industry is very painful. I used to receive 10-20 calls per week from recruiters, now I never receive them and I am the one making all the phone calls. I am not one of the paper techies and have abundant skills in many area -- computational linguistics, information extraction and retreival, 7 years of Java experiences, databases, FreeBSD kernel development, and I could go on -- but nobody is hiring.
From what I've heard in few off the record conversations with hiring managers, companies are mostly in a looking phase; they are trying to feel out the market and see what kind of talent they can grab in their price range. I used to make over $100,000 a year, but now I am being asked how I feel about large salary cuts. I wish that I could say that things are looking up, but I still here of all this pseudo-interviewing going on. I sometimes call recruiters back a month or two later, and often the positions are still open. Either the companies are becoming exceptionally careful of their candidate choices of they are still not really hiring and feeling out the waters.
Mod this up. This is a great idea for a book. The problems would need to expose the working of Java and not be some random problem. There are great problems posted on comp.lang.lisp often, but these are probably better siuted to Lisp and often involved some novel Lisp feature that makes the problem absurdly simple. Something like that for Java (or any other language) would be great. Any there any out there for other languages already?
-j
Can anybody answer a simple Perl6 question for me please?
What will be the difference between map and foreach in Perl6? And why are these going to be necessary when hyper-operators are going into the language? Can't these 3 be rolled into a single language feature; they seem to be the same to me.
-j
Yes, I see your point about wanting to stop evaluation periodically; laziness is a very important concept to allow. POE also sound very cool.
I do not use nearly as much Perl as I should, so I cannot comment as to specific Perl usages. However, you should never run out of memory with hyper operators, since it is too easy for the language to play swap games itself. This is my opinion, at least.
I too use very large data sets at work tied to databases. I do massive text processing tasks working as a core developer at one of the largest search engines on the web. For this taks we use a database called KDB.
<PLUG>
KDB is entirely based around bulk data operations. This database is written in K. It is the fastest database I know of, doing 50,000 transactions a second on a 100 million records.
</PLUG>
This construct is so prevalent, that it should be more concise and optimizable. The example is of a mostly effect free statement. There is a single assignment necessary, back to the iter_a. That is probably not sematically needed and just used for "efficiency". But the iterator code requires 4 additional assignments, the two original iterator creation assignments, then the implicit state changes in the next function. This destroys the ability for optimization, complicates the code and increases source bloat both increasing the probability of bugs.
or if you like describes the same process and seems far superior to the 5 line alternative.
I wasn't calling the design of the interpreter dumb. I see how it could be taken that way. When I said dumb, I meant as in "dumb terminal" (somwthing without knowledge). The interpreter just seemed to look at an operation and do exactly what asked of it, not optimizing on the fly. A language called K from http://kx.com is a smart interpreter in the sense that it does semantically what it is asked, but not necessarily how you ask it to be done and it will blow C code out of the water many times. It is based on APL coolness and tricks, like not actually calculating the entire matrix being operated on, but only the section that is examined at the end.
sorry for the confusion.
Thanks for the answer. I think it is great that some other languages are finally learning about bulk data operators and adverbs.
The map examples show that Perl didn't quite go as far as I would have liked to see it go in that direction. These bulk operators are one of the features that make K a far faster language that C many times.
Is there a reason these hyper meta-operators only scratched the surface to the concept? Not trying to pick on Perl, but it just seems that other people have these examples as great ammunition to the argument that Perl is just a kitchen sink approach to a language: tossing the surface level of everything imaginable intoa language without trying to think of the underlying concepts and unite them, for example shouldn't map and hyperness be the same thing?
I am a very big fan of stack machines and I think that an intelligent implementation can be built that would blow the doors off any finite register machine: think of the cache hits you can have operating on such local data instead of the random access model. Two stacks can also be used, one for short lived data and one for long lived data. There has also been a ton of research on variable lifetime and scoping analysis to know where to keep data.
Why does everybody always want to make dumb interpreters and not something more intelligent?
First, let me admit a bias: I am madly in love with an APL like language called K. It has destroyed some unreasonable language biases I had in the past by being simply an amazing language. I have become used to the hyper operator concept, even though in K functions are called verbs and the hyper decorations are called adverbs.
/: is read each right
/ is read over and +/x is 6, or ': is read each pair and +': is 3 5.
My question is about how hyperness is applied to hyperness and how you make hyperness apply to only one side of the operator. Here are how you do things like this in K; are these possible in the new Perl? If not, these would be monumental omissions.
' is read each
\: is read each left
Given the lists x:1 2 3 and y:10 20 30 and value z:100
x+'y is 11 22 33
x+\:z is 101 102 103
z+/:y is 110 120 130
but these can all be done implicitly, so you really do not need the decorations: x+y, x+z, and z+y are fine. This allows you walk down only a single list, while aggregating results.
x+\:y is (11 21 31; 12 22 32; 13; 23 33)
x+/:y is (11 12 13; 21 22 23; 31 32 33)
Then you can also walk down the left then right sides of list by \:/:(left each right each).
You can walk down a list unarily:
There are other adverbs and they can be combined to modify each other arbitrarily. This winds up being an incredibly powerway to write programs. It removes the programer from the burden of flow control and compacts code enormously. Think of removing all the loops from your code and replacing them with a couple charcters, instead.
My point was missed, I think. If you can express the code concisely -- I can view the entire algorithm in one page -- then it is easier to see the big picture while walking through the details. You do not need to keep scrolling around the source. It is possible to site back and just immerse yourself in it.
I used to be the first one in line to help develop coding standards. Now, I can't imagine wasting my time with them. I attribute it to being young and not having enough experience -- thinking that I had seen everything worth seeing. I have now seen some of the most beautiful code written in a style that most people balk at. It expresses its beauty through its amazing ideas, exquisit symetry, and ingenious compactness. Looking at an entire interpreter written as a page of APL while actually writing in C.
I used to be a syntax bigot, but I have now seen the light (no, Perl is still ugly and unreadable with no redeaming quality, unlike the almost prefectly regular syntax and symantics of K). No coding standard can make good code, but good code could be prevented by coding standards.
Remember, only you can help prevent segmentation faults.
-j
What difference does changing languages to most of you mean? 99% of everybody I see write a program in any language, writes C. I have seen hundreds of self-proclaimed "real Scheme hackers" use a dozen local variables in function; complex state is their definition of incredible code. I have seen even more "Perl gurus" write C with line noise, not understanding the unique features of perl that make it almost a concatenative language at times. I cannot count the number of C++ or Java twirps that have never seen the simple "TheEmptyTreeNode" as control-flow (or even worse, the ones that think it is poor style) -- these are usually the people that have never thought of the idea of removing explicit control flow from their code. Has everybody forgotten about the idea of constant data and as little state as possible, keeping with the Knuth maxim of code being as simple as possible (but no simplier). Has C wedged everybody's mind into thinking that every segment of code must be littered with control statements. Here is a challenge next time you code: write the code with as few control statements as possible, using every idiom you know and trick you can think of to remove all the if, switch, for, while, do, and related from your code and try to treat everything generically.
As much as I have a love-hate relationship with a certain APL derivative, they have the best programmers I have ever seen. They don't worry about performance, except when needed (and they have some extreme views of what is truly fast). They use a few big generic data structures and operate on them uniformly; they do not litter the landscape with a thousand different structures (that are all mostly similar and should be handled the same anyways). They write very terse code, where one screen of text can tell you the entire picture; nobody has to page through 30 pages of code to understand even the most complex operations. Why cannot more programmers be like this?
You are just using the wrong database, then. There is a 50cpu linux cluster (not Beowolf, but the native clustering to the database) that was loaded with 2.5 billion stock transactions. It performed very well using KDB (taken from kx.com):
.1 second.
on thursday jan 4, 2001 steve miano, ed bierly, keith mason and i
loaded 2.5 billion trades and quotes on a 50cpu linux cluster.
simple table scans on one billion trades, e.g.
select distinct sym from trade
select max price from trade
take 1 second
multi-dimensional aggregations, e.g.
/ 100 top traded stocks
100 first desc select sum size*price by sym from trade
/ daily high and close
select high:max price, close:last price by sym, date from trade
take 10 to 20 seconds
translating the data from TAQ to kdb took about 5 hours.
(steve had loaded the 200 TAQ cd's onto several disk drives.)
distributing the 100gigabytes over the 100Mbit ethernet took 3 hours.
(this cluster should probably have Gbit ethernet)
loading the database (k db taq.m -P 2080), starting 50 slaves,
connecting, mapping shared indicative tables over nfs, building
parallel partitions, etc. took
This is from kx.com using kdb, what I and others consider to be the most advanced database and development environment in existence today. It has amazing performance and unmatched efficiency. It absolutely crushes Oracle, SQL Server, Informix, and MySQL (shown by their tpc benchmarks). Here is a cluster they put together.
.1 second.
on thursday jan 4, 2001 steve miano, ed bierly, keith mason and i
loaded 2.5 billion trades and quotes on a 50cpu linux cluster.
simple table scans on one billion trades, e.g.
select distinct sym from trade
select max price from trade
take 1 second
multi-dimensional aggregations, e.g.
/ 100 top traded stocks
100 first desc select sum size*price by sym from trade
/ daily high and close
select high:max price, close:last price by sym, date from trade
take 10 to 20 seconds
translating the data from TAQ to kdb took about 5 hours.
(steve had loaded the 200 TAQ cd's onto several disk drives.)
distributing the 100gigabytes over the 100Mbit ethernet took 3 hours.
(this cluster should probably have Gbit ethernet)
loading the database (k db taq.m -P 2080), starting 50 slaves,
connecting, mapping shared indicative tables over nfs, building
parallel partitions, etc. took
Let's say you maintain this lexicon and related sematic network. You are responsible for ensuring that the network remains relatively balanced with respect to your users' input. Your lexicon is about 3 millions phrases. Now how do view correlation and the sizes of groups of similar questions more efficiently without a pretty colored graph drawing it on the screen for you. How to efficiently present this information to the operator (even a very skilled operator)?
It seems more intuitivc that data with a huge number of points would be too much for a human, but a computer would thrive on it. Human can do the easy, small sets usually just by looking at the plots.
It supports private and broadcast messages along with an command handler similar to IRC ("/nick" and such). This should handle over 10k messages a second easily. Here is the entire server source code (but me for the slightly longer client code if you care):
[ time x]"enter";Who,:_w;nicks[];(x;Nicks;Msgs)}
/k server -i port {oper}
if[~_p;."\\m i 1234"]
Oper::[0<#_i;*_i;""]
Who:!0
Nicks:()
Msgs:()
.m.c:"if[_w _in Who;bye Who?_w]"
.m.s:{:[(_w _in Who)&x[0]_in`msg`obj;. x;'`access]}
.m.g:{:[(~_w _in Who)&`hi~*x;. x;'`access]}
hi:{if[x _in Nicks;:_f""];if[0=#x;x:"guest",$_w];Nicks,:,x;sys
bye:{Who::Who _di x;n:Nicks x;Nicks::Nicks _di x;sys[time n]"exit";nicks[]}
nicks:{Who 3:\:(`Nicks;();:;Nicks);}
sys:{send[1;Who](`msg;(y," ",x;`blue;`gray;""))}
time:{x," (",({(1_,/"/",'x)," ",1_,/":",'y}.$+0 100 100_vs _gtime _t),")"}
msg:{[x;y;z;n]:["/"~*x;cmd 1_ x;txt[x;y;z]n]}
txt:{[x;y;z;n]send[0=#n;:[0=#n;Who;_w,Who Nicks?n]](`msg;(x;y;z;Nicks[Who?_w],">",n))}
send:{if[x;Msgs,:,z];(?y)3:\:z;}
cmd:{Cmd[`$i#x]{|((x=" ")?0)_ d:|x}(1+i:x?" ")_ x}
Cmd.nick:{if[(0<#x)&~x _in Nicks;n:Nicks i:Who?_w;Nicks[i]:x;_w 3:(`Nick;();:;x);sys["is now ",x]n;nicks[]]}
Cmd.me:{sys[x,")"]"(",Nicks Who?_w;}
Cmd.boot:{if[Oper~Nicks Who?_w;3:Who Nicks?x]}
I think he means that Jesus lived a sinless, lawful life and was still condemned to die. He lived the perfect life according to God's high standards, even though he was tempted just as much as any of us. His faith so strong and without any doubt that he could perform miraculous actions.
After having lived such a noble life, He was caught by the authorities, accused of crimes He did not commit, then crucified to the death. He accepted this, knowing that this was his role in God's plan. If you were asked to be tortured and killed to help people the same people that were killing you, would you concent?
He gave his his sinless life so that we could be absolved of our sins. Why did he need to die for everybody else's sins; he didn't have any and eveybody else gets to continue living? Does this seem fair to you?
"When we were utterly helpless, Christ came at just the right time and died for us sinners. Now, no one is likely to die for a good person, though someone might be willing to die for a person who is especially good. But God showed his great love for us by sending Christ to die for us while we were still sinners. And since we have been made right in God's sight by the blood of Christ, he will certainly save us from God's judgment. For since we were restored to friendship with God by the death of his Son while we were still his enemies, we will certainly be delivered from eternal punishment by his life. So now we can rejoice in our wonderful new relationship with God - all because of what our Lord Jesus Christ has done for us in making us friends of God." -- Romans 5:6-11
Oh, maybe you meant "division my zero"... hmmm I don't know about that one.
-j
Hey, I didn't know that. Nice.
:= 2 3 2 3 5
When I posted, I was thinking of a particular time I needed to add an attribute to an element in the middle of a for-each. I remember it because it almost doubled the file size. One, of the many, relevant segments follows. Please, tell me how I am sucking. I am sure there is a better way of doing this (excure the t namespace, I use is because I am lazy):
<t:for-each select="//store/*/designer">
<a><t:attribute name="href">
<t:value-of select="url"/></t:attribute>
<t:value-of select="name"/></a></t:for-each>
Just as I inserted the "<a>" element, I was something as simple for the attributes. Since you treat a single tree and a forest the same when iterating over them, then why not for assignment, too?
Can I do this, hopefully, and have it constructe a forest of "a" elements?
<a href="//store/*/designer/url/text()">
<t:value-of name="//store/*/designer/name"/>
</a>
That seems to make sense, I hope: make "a" elements with "href" attributes, assigning "href" the text value of each "//store/*/designer/url" element. Take the value of all the "name" elements, placing them on the tree is the "a" element.
It would be the same thing that many other languages do with array assignment:
a[4 6 8 9 10]
meaning, do a scatter/gather assignment, giving the first 5 composite numbers the value of their largest prime factor.
(or imagine from c:
int a[0 3][0 3] = b[1 2][1 2];
assigning the corners of the 4x4 matrix to be the middle of another matrix)
-j
How is transforming "" to "" different from transforming "o" to "X"? The biggest problem I had in XML on my first real project was spending an hour trying to output "There is 1 email message unread. Would you like to read it?" and "There are 12 email messages unread. Would you like to read them?" in some templatized way. You know, being dense: "There W X email messageY unread. Would you like to read Z?" Then I just hardcoded all the necessary strings (about half a dozen of them) and wrote the read/unread message totals in a scorebox. Screw english. Similar to the typical i18n hack people use for error messages.
-j
Data transformation, isn't that all the game of is it? I want to munge well structured text. I wanted to transform this document:
+-----+
|ooXXo|
|XooXX|
|XoooX|
|XXXoo|
|ooXXo|
+-----+
into this document:
+-----+
|ooXXo|
|oXooX|
|XoXoX|
|XoXoo|
|ooXXo|
+-----+
Replace the 'X's and 'o's with your favorite words.
They are both very regularly structured blocks of text with a few small precise rules. Why shouldn't a document conversion language be able to do this. Does you think that that mess of vague rules we can English would be any easier?
-j
< move along people. there's nothing to see here >
< something to placate the postercomment compression filter >
< these quotes stolen from Slashdot homepage >
< This page was generated by a Group of Trained Robots >
< This page was generated by a Team of Trained Geese >
It isn't Lisp. It is bad C. If you could find a full spec of the syntax and semantics of LOOP, I bet it is larger than the R5RS of Scheme. It is as if an evil C zealot snuck into the committee and forced his twisted philosophy on everybody: a terrorist plot against everything that is Lisp. The LOOP clauses are out of place in the beautiful forest of s-expressions.
Seriously, I have just never a use of LOOP where DO/MAP/REDUCE were not cleaner. The interactions between clauses is unbearably difficult to understand at times. If you are looking for peculiar interactions between the variables in the clauses, then use DO*.
The this what really annoys me with DO/MAP/REDUCE is that even though CLisp has a large standard library of functions, it is missing small very useful list generating functions: like generating a list of the integers from 0 to x. Then the need for defining some incrementation construct and iterating though it would be eliminated (not in the Lisp spirit, I feel); you could then just MAP across the list (a much more Lisp-ish style).
Besides all that, LOOP is just too complex, very poorly defined, and not extensible at all: very un-Lisp like.
-j
It took me a whole weekend to write Conway's game of life for my first learning project. My first real application was a simple xml logical to HTML converter. It took about 12 hours. The real catch was when I needed to ouput to be dependant on two different far away element bodies.
XSLT is not based on rewriting the XML tree, but the correct way to view the process is on creating an output tree from an input tree. Rewriting would imply that elements that were not specifically analyzed (how ever you define it) would still be in the output tree. Also, you cannot reference the structure of the newly constructed output tree, only the input tree.
Using XML was supposed to free you of the burden of doing much of the parsing, i.e., have a consistent format for the data. However in XSLT you still have a very large parsing responsibility. They choose XML to represent the top-level transformation structures, but almost every element and attribute that has content has its own mini-language format. XML is too syntax heavy for a pure XML-only syntax, probably.
-j