I am an experienced software deveoper that is fairly competant in what I do. I am presently living in Southern California, but i am willing to relocate to most places (especially moving back to the San Francisco Bay Area). A full resume can be found at http://xcf.berkeley.edu/~nordwick/resume.pdf or you can just go the homepage to find other formats.
Yes! I am using my +1 bonus, because I need a job badly.
Connect 4 was not solved by any deep searching. It is mathematically solvable. You can look at a position and almost instantly tell what side will win. There is a small, finite set of rules that tell you who will win the game. I wrote this for the my second computer science class and absolutely destroyed the entire class, winning every single match with O(1) complexity for a move choice.
Yes, chess is solvable. It doesn't matter what the opponent does (however, it could be the case that the person who makes the first move always looses). If you think that the opponent being able to move changes this, then think about tic-tac-toe. That is another game that has perfect information where the opponent also has a choice to disrupt your plan, yet perfect play has already been demonstrated. Or you can think of connect-4, in this game the first person to move always wins.
K is a high-performance data processing language. It is a high-level language with very fast performance (it even beats out well written C code). Many people after switching to K have noticed 100x decrease in code side (yes, 2 orders of magnitude) and sometimes even more. It has very high-performance I/O facilities and was explicitly made for muching data. It is cross-platform and runs on NT, Solaris, Linux, FreeBSD, and AIX (you can probably get a build for other systems, too, since the guy who write it is very nice about that).
Some of theK programming maxims are that memmap is better than read/write (the native file I/O is memmap), operating over bulk data is better than scalar data (the language is built around bulk operators), and terse code is good.
There is a warning, though. K is very elite and may be too elite for you (it was for me at first), but it is very eay to learn.
I have seen customizable button bars that can have any function added to it, but I have never seen the same for context menus. Why not? Everybody would want different functions available on their context menus (I personally like keeping them lean, with only what I use often).
Re:Differences between Squid and Octopus?
on
Giant Octopus
·
· Score: 1
http://www.aqua.org/animals/species/procto.html
I thought the largest was 32ft?
on
Giant Octopus
·
· Score: 3, Interesting
The largest octopus reported in scientific literature was 32 feet from arm tip to arm tip and weighed 300 lbs. It was an unusual looking octopus. The biggest one that I've ever seen was found in the waters around Vancouver Island, and was 22.5 ft. from arm tip to arm tip and weighed 156 lbs. (Jim Cosgrove, RBCM)
taken from http://7thfloormedia.com/projects/safari/newslette r/questions/qocto.html
On Kuro5hin, someone had the awesome idea to buy text ads for the words scientology and xenu. More people had decided to buy ads, too. So now when you search on Google for Scientology you are shown ads such as "Why is the CoS censoring this site" and "scientology is evil". This guy deserves an award for best abuse of the system.
Why do we care about some random unimportant Microsoft bug? Worthless stories like this crowding out other news are what make people think that/. has turned into a purely anti-Microsoft forum.
Since there have been games written mostly in Lisp already, doesn't this empirical proof extend to Java or other higher-level languages? I have seen comments such as "nobody wants to be first" and that there is "cultural baggage," but wouldn't Lisp's trail blazing really have been these new firsts and unloaded some of the cultural baggage?
As you point out, there are many parents who do not own up to their responsibilities. What do you do about these kids then, "Oh, well, your parents sucked too bad your going to grow up a cracked out, murderous prostitute." Or do you create a safety net for these children and try to provide some artificial parenting as a safe-guard.
Second, these laws are there to assist parents. Since a parent cannot supervise a child constantly you create laws that help the parent when they cannot be there, such as setting smoking and drinking age limits.
You seem to be under the delusion that a parent can always be there and just by speaking to your children they will do what they say; you are in for a shock when your kids hit 13. You can argue aabout the casual relationship elsewhere, but don't flip out at laws that are meant to assist parents.
There are four occurances of the word (or derivations) of incapacitate. Three of those occurances occur in the schedule guidelines and are the phrase "incapacitating toxicity." The other occurence is "incapacitation," and it is further restricted by the modifying phrase "chemical action on life process." The slime is clearly not toxic nor does it effect a life process.
Also look to Article II.9.d where it clearly states that "[a purpose] not prohibited under this convention" is "law enforcement including domestic riot control."
This has been discussed heavily on the K mailing list. Somebody has done a done a K-ish version of Ackermann's function that works very well. The way you program in K is different from the way you program in C. In K you choose to operate over bulk data and you slive object arrays length-wise, i.e. if you have an object of three fields x, y, and z, you would operator over all the x's, then all the y's, then all the z's.
I agree that most language are the same C derived POS. C was different and inventive when it was created. Lisp, APL, Prolog, and Smalltalk were all different when they were created. It seems like as time went on we started narrowing our field of vision and implementing the same languages: C to C++ to Java, what kind of intereting steps are those? At least Smalltalk to Self was a very interesting pushing of the boundries. Today, almost nobody pushes anything, except how similar their langauge is to C and why that it good. Even Python and Perl don't attempt to explore any new concepts, they are happy being a Frankenstein of older languages that people seemed to have forgetten about; name three new features of either language, just try to name one!
My sole exception to this is a language called K. Yes, it has its roots in APL and has added to the APL model from languages such as Lisp and Scheme, but it has some very interesting new features of its own.
K is very very very fast to write and the run. It blazes in both categories. There is a full relational database that is written in K, called KDB. It crushed Oracle on the TPC-B and TPC-D benchmarks in both speed and storage size, requiring only a few percent above the dataset size in overhead. It has native clustering and replication that allowed it to run on a 50 cpu Linux cluster loaded with 2.5 billion stock trades and quotes and have simple table scans (such as, select max price from trade) take under a second and multi-dimensional aggregations (such as, 100 first desc select sum size*price by sym from trade) take only 10 seconds. Starting the database cluster took a tenth of a second. It is SQL92 compliant, has an extended ultra-powerful query language called KSQL that makes writing queries very simple, and the stored procedure languages are K and C.
In bwk's language benchmarks, even though this is not the K strong point, the sum of the execution times were: K at 32 seconds, Perl at 95, Java at 300, and TCL above 1400. The lines of code to implement were: K at 9 lines, awk at 95, Perl at 96, TCL at 105, Scheme at 170, VB at 200, and Java at 350.
Yes, K can look like line noise, but unlike Perl, you get alot from this. First you get extreme code density and see the entire problem on the screen at once. I came from a Scheme background and Perl hurt my eyes, so I was very skeptical, but after my roommate persuaded me to look at K harder, I realized that this high code density made it very easy debug and write code. It is rumored that KDB is written in 26 files of code, each file consisting of a single screen of code, labeled a to z. Try doing that in any other language. The language is exceptionally regular. It is so logical and consistent that it takes a little getting used to. You never have to remember any baroque language rules. Anything that makes sense, you can do. Also, even though it looks difficult, it is extremely easy to learn because K is directly translatable to English, in fact there is a K program that will do this automatically. For example to split a line by tabs you could write:
cut:{1_'(&x=*x)_ x:"\t",x}
And this is read:
cut gets function, 1 drop each, where x equals first x quantity, cut x. When X gets tab join x.
It may take a little getting used to, but with a month of K, my roommate and I were able to converse this way when describing K and you could see the picture developing in your head. It was amazing.
A unique feature of K is what is called the K tree. Unification is a very strong idea in K, so it unifies the idea of object, variables, attributes, namespaces, and dictionaries. A dictionary is a native K type. Each variable lives in a dictionary (somwhat like Python). These dictionaries are joined hierarchically and can be removed and added dynamically. All variables are on the K tree, too, so a new namespace is really just a dictionary on the K tree! This means that you can rearrange the K tree and change what functions get called. This is the most reflective language that I have ever seen (Python, Scheme, and CLisp come in a very close behind). All variables have attributes. All attributes are is a special dictionary attached to the variables (the language is so regular that this is really a namespace with a blank name so to refer to the attributes of a variable you say ns.var..attrib). And, of course, each attribute is just a variable so each of those can have attributes, too.
This interesting K tree leads to a very elegant GUI. Each variable can have an attribute named c (for class), and this can have certain values like `table, `check, `radio, `button, and others (the backtick ` is how you make a symbol). Lets take radio for an example. Then you would have another attribute o (for option) with possible values:
These four lines would create a radio box with five choices, zero through four, and everytime you evaluated r whatever the radio was set to, r would evaluate to. Basically, each variable has a direct on-screen representation (they default to `data) and is directly manipulable.
K also has the ideas of dependencies and triggers in the language, so if a..d:"1+b" then refering to a will dynamically calculate 1+b, but only when necessary (if you refer to a multiple times but b does not change between those references, a will only be calculated once and stored; K figures out the dependency graph for you). There are also triggers. If b..t:"a:b-1" then whenever b is assigned or modified then a will get the appropriate value. This trigger can be anything, such as a network operation or a gui command.
The language has some other unique features like an interesting callback oriented interprocess communication system and an on-the-fly optimizing vm.
Of course since it inherits some background from APL it has bulk operators, called adverbs, that modify functions in every conceivable way (much more powerful than APL or Perl). One of the signs of a good K programmer is one who knows how to do this and doesn't use any loops (KDB, the relational database, is written without any loops).
From functional languages K inherits higher-level functions and projections. Both which are very standard practices especially when combined with the bulk operators. b f[a;;c;]'d takes the four argument function f, fixes the first and third arguments projecting a function of two arguments, then applies it to each down the list of argument in b and d.
When you use K you truly are standing on the shoulders of giants. The person who wrote it, Arthur Whitney, has this amazing ability to identify the important pieces of a problem and simplify away the rest. The performance in K and KDB is incredibly; the simplicity and power of the language and the database is incredibly.
K runs on various flavors of Unix and NT, so people should take an open mind (I didn't have one at first and was very skeptical) and really try the language and try a new style of programming. Your code and thoughts on developing will never be the same.
The reason I don't buy e-books is more than just what titles are available. I read alot of research PDFs, but I still print them out (at least 2-sided printing, though). Better screens need to come down in price, this includes the LCD e-book viewers.
First, they hurt my eyes to look at for entended periods of time. I hear that it is the refreshing on standard monitors and that LCDs are better since they do not refresh, but even LCDs give me eye strain.
Second, on LCD screens, they tend to be too small vertically, especially e-book handhelds. In dead tree format it seems like I get more vertical lines, but less width. Maybe it is just that I am used to that, but I find reading on a screen with the extra width more difficult than reading thinner columns. I think it is the retrace to the beginning of the line that my eye does and on longer lines it tends to be difficult (and I get lost frequently). I even wish that more web pages would be double columned.
Third, I think that there might also be a problem with the light eminating from the screen, too. I just notice that I am sensitive to how much light there is when reading and the direction of it. While a back-lit screen does provide light it is like a light bulb shining on your face when you are trying to read.
My fourth problem is glare in the screens. It is very easy to read a book with a light behind you, but you get nasty glare off the screens. Even with what would be ideal lighting for reading paper, screens still suffer glare.
The final thing keeping me form buying e-books is that you cannot mark on them. In literary book I tend to underline certain passages and make little pictures/doodles. In reserach docs, I make notes to understand it better as well as diagrams. As far as I know this is not possible with an e-book. Typed notes are okay, but not the same as a pencil.
I don't think that quality is a problem and I don't think that I need print quality to read comfortable, but I could be wrong on this too, all well as any of my other comments.
Sounds like a bad design. I would pass the deck of cards to an instance of a shuffler interface. If this is the dealer object or not is unimportant.
This breaks the paradigm of a data and its operation going together, one of the basic tenants of OO design. Then you would have a non related class, the shuffler class, picking at the data of the deck class. This is clearly covered by Martin Fowler in Refactoring as a bad smell.
There's no reason to choose functional vs. OO programming, they work fine together. Closures and OO works perfectly together in Smalltalk. The power of OO is data encapsulation and correct use of interfaces. These are things that are not easily modelled in a pure functional language.
You say it yourself. Lexical closures are the perfect medium for encapsulation and inteface exposure. The lexical bindings allow for data to be completely hidden from the users eyes. The function that creates the closure and returns it is a factory in design pattern lingo. It creates a function with a clearly defined interface. I think both of these OO paradigms are more than adequately covered in functional programming.
My biggest question in evolution is how the number of chromosomes changes in a species and that species can still mate and produce viable offspring. Is there something that explains this?
People committed to idea that is so intrically tied to them traditionally and emotionally are impossible to talk to objectively.
Sounds like a description of a fanatical atheist. They can be just as emotionally tied to evolution as a Christian for they want to know how they were created just as much as any Christian.
Any angry athiest out there, dont waste your time talkiing reason with some one who by doctrine requires faith as the only means of substantiating their beliefs, it is fruitless and frustrating.
And where did the universe come from? Did it just spring itself existance without cause; then how did cause and effect come to be? And don't you just believe that by faith? Do you believe in leptons and is that just by faith or have you felt them?
how can free will exist if god knows everything including the future.
What is wrong with knowing what decisions you will make, just as a wife knows what her husband will do when he comes home or his reaction to certain news? The Lord just knows use infinitely well. I see no problem with that. I like the fact that somebody with my best in mind knows me that well.
Why are preachers rich and congregations poor?
Even us Christians wonder that sometimes. However, some of the best pastors that I know are just as poor as their congragations; they always have people living with them; they are always feeding people at their house; and they always assist their congragation financially. There are some very good pastors out there, but there are also some greedy ones out there. Even the greedy ones are just human and have flaws, though, and some of them are still good people (who wouldn't want to live a little more confortable life, it is a difficult thing to pass up).
"Jesus Christ is the only thing that matters, because he brings new life to mine which was once meaningless, stale and stagnant."
Isn't that sort of like patriotism? "MY country is better than YOUR country, because I was born in THIS country!"
These are not even close. Nationalism is driven by an us-versus-them dichotomy creating a feeling of supremacy. The idea of if you are born in the US then you are against a non-US nation is a competition.
The idea of being reborn in Jesus Christ is that everyone can be born there. Christians know that they are horrible sinners and none should feel superior to anybody. There is no competition only cooperation, we are there to bring the gospel to everybody and have everybody saved unto the Lord. It is a miraculous feeling when you trust in the Lord, nothing can ever go wrong.
Not to beat a dead horse, this is my last post on the topic.
This is wrong. Any objects you define do correlate to the "real-world" (your model). If they dont your program will not make sense. You have taken a wrong turn somewhere.
I am not the only to advocate this position. Jeff Alger is a great proponent of objects not as real-world entities but of programming idioms, as is Martin Fowler. The reason is that to distribute work, many times is makes more sense to have object be active: it fits the "data with their operations" paradigm. The point of the cards example is that in real life you don't really have self shuffling decks of cards, but it is a natural division of work in programming (it is an operation of the deck dealing with its data).
Each instance of an object in a program is a model. You think about what it is conceptually that you are modeling and derive classes for those concepts. In practice these objects usually have hierarchial and recursive relationships.
Indeed I don't beleive 9 out of 10 developers using an OO language are actually writing OO code. It's modular at best. To use it effectively is non-trivial.
First, but what is the purpose of making modeling easier? Isn't the goal of almost all new language to make programming easier in some respect.
Second, I am not one one of the "objects as real-world entities" people. I believe strongly that to effectively partition work -- to make programming more tractable -- many times you will create work partitions and create objects that have no correlation to the real-world. A contrived example would be a deck of cards. Imagine that you make each card an object, then you have a deck object, and a dealer object. In the real-world the dealer would shuffle a deck, but in our code this responsibility would fall on the deck, but the dealing mechanics would probably rest with the dealer.
I am the kind of programmer that believes in active objects. I am the kind of person that makes everything an object. I make all my constants objects (for type checking and I cannot stand it when people use integers for this) and slowly through most development I have done, these once data-only objects gain methods and no longer become just place-holding constants.
I think that to effectively use the OO paradigm, you need to really abuse it. I use dynamic dispatch for almost all my flow control; try finding even an 'if' statement in my code. I even have the_empty_tree_node objects that don't do anything except return so my tree recursions don't need a base case. This abuse is non-trivial; you are correct. I have spent alot of time abusing C++ and Java for it to come more naturally to me.
However, I don't think it will ever come as naturally to me as functional programming. I am not saying that I do not use OO techniques in my functional code. You can see a sort of dynamic dispatch mimicked by function passing and you can see pseudo-object in functions that return different functions, each operating on the same lexically captured bindings. I am just saying that OO is over-hyped and I feel that the functional paradigm effectively captures OO benefits.
APL's style of data oriented processing has also shown to be much faster and require far less code. Why develop a library when it only takes a single line implement the functionality? Also when you language supports dynamically evaluating a string code reuse in terms of modifying a string then evaluating is phenominal (plus the on-the-fly compiler gets to optimize the hell out of it).
Slashdot Mirror
I am an experienced software deveoper that is fairly competant in what I do. I am presently living in Southern California, but i am willing to relocate to most places (especially moving back to the San Francisco Bay Area). A full resume can be found at http://xcf.berkeley.edu/~nordwick/resume.pdf or you can just go the homepage to find other formats.
Yes! I am using my +1 bonus, because I need a job badly.
Connect 4 was not solved by any deep searching. It is mathematically solvable. You can look at a position and almost instantly tell what side will win. There is a small, finite set of rules that tell you who will win the game. I wrote this for the my second computer science class and absolutely destroyed the entire class, winning every single match with O(1) complexity for a move choice.
Yes, chess is solvable. It doesn't matter what the opponent does (however, it could be the case that the person who makes the first move always looses). If you think that the opponent being able to move changes this, then think about tic-tac-toe. That is another game that has perfect information where the opponent also has a choice to disrupt your plan, yet perfect play has already been demonstrated. Or you can think of connect-4, in this game the first person to move always wins.
Some of theK programming maxims are that memmap is better than read/write (the native file I/O is memmap), operating over bulk data is better than scalar data (the language is built around bulk operators), and terse code is good.
There is a warning, though. K is very elite and may be too elite for you (it was for me at first), but it is very eay to learn.
I have seen customizable button bars that can have any function added to it, but I have never seen the same for context menus. Why not? Everybody would want different functions available on their context menus (I personally like keeping them lean, with only what I use often).
http://www.aqua.org/animals/species/procto.html
The largest octopus reported in scientific literature was 32 feet from arm tip to arm tip and weighed 300 lbs. It was an unusual looking octopus. The biggest one that I've ever seen was found in the waters around Vancouver Island, and was 22.5 ft. from arm tip to arm tip and weighed 156 lbs. (Jim Cosgrove, RBCM)
e r/questions/qocto.html
taken from http://7thfloormedia.com/projects/safari/newslett
On Kuro5hin, someone had the awesome idea to buy text ads for the words scientology and xenu. More people had decided to buy ads, too. So now when you search on Google for Scientology you are shown ads such as "Why is the CoS censoring this site" and "scientology is evil". This guy deserves an award for best abuse of the system.
Why do we care about some random unimportant Microsoft bug? Worthless stories like this crowding out other news are what make people think that /. has turned into a purely anti-Microsoft forum.
Since there have been games written mostly in Lisp already, doesn't this empirical proof extend to Java or other higher-level languages? I have seen comments such as "nobody wants to be first" and that there is "cultural baggage," but wouldn't Lisp's trail blazing really have been these new firsts and unloaded some of the cultural baggage?
As you point out, there are many parents who do not own up to their responsibilities. What do you do about these kids then, "Oh, well, your parents sucked too bad your going to grow up a cracked out, murderous prostitute." Or do you create a safety net for these children and try to provide some artificial parenting as a safe-guard.
Second, these laws are there to assist parents. Since a parent cannot supervise a child constantly you create laws that help the parent when they cannot be there, such as setting smoking and drinking age limits.
You seem to be under the delusion that a parent can always be there and just by speaking to your children they will do what they say; you are in for a shock when your kids hit 13. You can argue aabout the casual relationship elsewhere, but don't flip out at laws that are meant to assist parents.
There are four occurances of the word (or derivations) of incapacitate. Three of those occurances occur in the schedule guidelines and are the phrase "incapacitating toxicity." The other occurence is "incapacitation," and it is further restricted by the modifying phrase "chemical action on life process." The slime is clearly not toxic nor does it effect a life process.
Also look to Article II.9.d where it clearly states that "[a purpose] not prohibited under this convention" is "law enforcement including domestic riot control."
This has been discussed heavily on the K mailing list. Somebody has done a done a K-ish version of Ackermann's function that works very well. The way you program in K is different from the way you program in C. In K you choose to operate over bulk data and you slive object arrays length-wise, i.e. if you have an object of three fields x, y, and z, you would operator over all the x's, then all the y's, then all the z's.
My sole exception to this is a language called K. Yes, it has its roots in APL and has added to the APL model from languages such as Lisp and Scheme, but it has some very interesting new features of its own.
K is very very very fast to write and the run. It blazes in both categories. There is a full relational database that is written in K, called KDB. It crushed Oracle on the TPC-B and TPC-D benchmarks in both speed and storage size, requiring only a few percent above the dataset size in overhead. It has native clustering and replication that allowed it to run on a 50 cpu Linux cluster loaded with 2.5 billion stock trades and quotes and have simple table scans (such as, select max price from trade) take under a second and multi-dimensional aggregations (such as, 100 first desc select sum size*price by sym from trade) take only 10 seconds. Starting the database cluster took a tenth of a second. It is SQL92 compliant, has an extended ultra-powerful query language called KSQL that makes writing queries very simple, and the stored procedure languages are K and C.
In bwk's language benchmarks, even though this is not the K strong point, the sum of the execution times were: K at 32 seconds, Perl at 95, Java at 300, and TCL above 1400. The lines of code to implement were: K at 9 lines, awk at 95, Perl at 96, TCL at 105, Scheme at 170, VB at 200, and Java at 350.
Yes, K can look like line noise, but unlike Perl, you get alot from this. First you get extreme code density and see the entire problem on the screen at once. I came from a Scheme background and Perl hurt my eyes, so I was very skeptical, but after my roommate persuaded me to look at K harder, I realized that this high code density made it very easy debug and write code. It is rumored that KDB is written in 26 files of code, each file consisting of a single screen of code, labeled a to z. Try doing that in any other language. The language is exceptionally regular. It is so logical and consistent that it takes a little getting used to. You never have to remember any baroque language rules. Anything that makes sense, you can do. Also, even though it looks difficult, it is extremely easy to learn because K is directly translatable to English, in fact there is a K program that will do this automatically. For example to split a line by tabs you could write: And this is read: It may take a little getting used to, but with a month of K, my roommate and I were able to converse this way when describing K and you could see the picture developing in your head. It was amazing.
A unique feature of K is what is called the K tree. Unification is a very strong idea in K, so it unifies the idea of object, variables, attributes, namespaces, and dictionaries. A dictionary is a native K type. Each variable lives in a dictionary (somwhat like Python). These dictionaries are joined hierarchically and can be removed and added dynamically. All variables are on the K tree, too, so a new namespace is really just a dictionary on the K tree! This means that you can rearrange the K tree and change what functions get called. This is the most reflective language that I have ever seen (Python, Scheme, and CLisp come in a very close behind). All variables have attributes. All attributes are is a special dictionary attached to the variables (the language is so regular that this is really a namespace with a blank name so to refer to the attributes of a variable you say ns.var..attrib). And, of course, each attribute is just a variable so each of those can have attributes, too.
This interesting K tree leads to a very elegant GUI. Each variable can have an attribute named c (for class), and this can have certain values like `table, `check, `radio, `button, and others (the backtick ` is how you make a symbol). Lets take radio for an example. Then you would have another attribute o (for option) with possible values: These four lines would create a radio box with five choices, zero through four, and everytime you evaluated r whatever the radio was set to, r would evaluate to. Basically, each variable has a direct on-screen representation (they default to `data) and is directly manipulable.
K also has the ideas of dependencies and triggers in the language, so if a..d:"1+b" then refering to a will dynamically calculate 1+b, but only when necessary (if you refer to a multiple times but b does not change between those references, a will only be calculated once and stored; K figures out the dependency graph for you). There are also triggers. If b..t:"a:b-1" then whenever b is assigned or modified then a will get the appropriate value. This trigger can be anything, such as a network operation or a gui command.
The language has some other unique features like an interesting callback oriented interprocess communication system and an on-the-fly optimizing vm.
Of course since it inherits some background from APL it has bulk operators, called adverbs, that modify functions in every conceivable way (much more powerful than APL or Perl). One of the signs of a good K programmer is one who knows how to do this and doesn't use any loops (KDB, the relational database, is written without any loops).
From functional languages K inherits higher-level functions and projections. Both which are very standard practices especially when combined with the bulk operators. b f[a;;c;]'d takes the four argument function f, fixes the first and third arguments projecting a function of two arguments, then applies it to each down the list of argument in b and d.
When you use K you truly are standing on the shoulders of giants. The person who wrote it, Arthur Whitney, has this amazing ability to identify the important pieces of a problem and simplify away the rest. The performance in K and KDB is incredibly; the simplicity and power of the language and the database is incredibly.
K runs on various flavors of Unix and NT, so people should take an open mind (I didn't have one at first and was very skeptical) and really try the language and try a new style of programming. Your code and thoughts on developing will never be the same.
-j
how many asses do they have?
Why is this not under the developers section?
The reason I don't buy e-books is more than just what titles are available. I read alot of research PDFs, but I still print them out (at least 2-sided printing, though). Better screens need to come down in price, this includes the LCD e-book viewers.
First, they hurt my eyes to look at for entended periods of time. I hear that it is the refreshing on standard monitors and that LCDs are better since they do not refresh, but even LCDs give me eye strain.
Second, on LCD screens, they tend to be too small vertically, especially e-book handhelds. In dead tree format it seems like I get more vertical lines, but less width. Maybe it is just that I am used to that, but I find reading on a screen with the extra width more difficult than reading thinner columns. I think it is the retrace to the beginning of the line that my eye does and on longer lines it tends to be difficult (and I get lost frequently). I even wish that more web pages would be double columned.
Third, I think that there might also be a problem with the light eminating from the screen, too. I just notice that I am sensitive to how much light there is when reading and the direction of it. While a back-lit screen does provide light it is like a light bulb shining on your face when you are trying to read.
My fourth problem is glare in the screens. It is very easy to read a book with a light behind you, but you get nasty glare off the screens. Even with what would be ideal lighting for reading paper, screens still suffer glare.
The final thing keeping me form buying e-books is that you cannot mark on them. In literary book I tend to underline certain passages and make little pictures/doodles. In reserach docs, I make notes to understand it better as well as diagrams. As far as I know this is not possible with an e-book. Typed notes are okay, but not the same as a pencil.
I don't think that quality is a problem and I don't think that I need print quality to read comfortable, but I could be wrong on this too, all well as any of my other comments.
Sounds like a bad design. I would pass the deck of cards to an instance of a shuffler interface. If this is the dealer object or not is unimportant.
This breaks the paradigm of a data and its operation going together, one of the basic tenants of OO design. Then you would have a non related class, the shuffler class, picking at the data of the deck class. This is clearly covered by Martin Fowler in Refactoring as a bad smell.
There's no reason to choose functional vs. OO programming, they work fine together. Closures and OO works perfectly together in Smalltalk. The power of OO is data encapsulation and correct use of interfaces. These are things that are not easily modelled in a pure functional language.
You say it yourself. Lexical closures are the perfect medium for encapsulation and inteface exposure. The lexical bindings allow for data to be completely hidden from the users eyes. The function that creates the closure and returns it is a factory in design pattern lingo. It creates a function with a clearly defined interface. I think both of these OO paradigms are more than adequately covered in functional programming.
My biggest question in evolution is how the number of chromosomes changes in a species and that species can still mate and produce viable offspring. Is there something that explains this?
thanks
And where did the universe come from? Did it just spring itself existance without cause; then how did cause and effect come to be? And don't you just believe that by faith? Do you believe in leptons and is that just by faith or have you felt them?
What is wrong with knowing what decisions you will make, just as a wife knows what her husband will do when he comes home or his reaction to certain news? The Lord just knows use infinitely well. I see no problem with that. I like the fact that somebody with my best in mind knows me that well. Even us Christians wonder that sometimes. However, some of the best pastors that I know are just as poor as their congragations; they always have people living with them; they are always feeding people at their house; and they always assist their congragation financially. There are some very good pastors out there, but there are also some greedy ones out there. Even the greedy ones are just human and have flaws, though, and some of them are still good people (who wouldn't want to live a little more confortable life, it is a difficult thing to pass up).
The idea of being reborn in Jesus Christ is that everyone can be born there. Christians know that they are horrible sinners and none should feel superior to anybody. There is no competition only cooperation, we are there to bring the gospel to everybody and have everybody saved unto the Lord. It is a miraculous feeling when you trust in the Lord, nothing can ever go wrong.
For the first time that I can remember somebody acrtually god the meaning of the acronym correct: Berkeley Software Distribution. Who told the secret?
Second, I am not one one of the "objects as real-world entities" people. I believe strongly that to effectively partition work -- to make programming more tractable -- many times you will create work partitions and create objects that have no correlation to the real-world. A contrived example would be a deck of cards. Imagine that you make each card an object, then you have a deck object, and a dealer object. In the real-world the dealer would shuffle a deck, but in our code this responsibility would fall on the deck, but the dealing mechanics would probably rest with the dealer.
I am the kind of programmer that believes in active objects. I am the kind of person that makes everything an object. I make all my constants objects (for type checking and I cannot stand it when people use integers for this) and slowly through most development I have done, these once data-only objects gain methods and no longer become just place-holding constants.
I think that to effectively use the OO paradigm, you need to really abuse it. I use dynamic dispatch for almost all my flow control; try finding even an 'if' statement in my code. I even have the_empty_tree_node objects that don't do anything except return so my tree recursions don't need a base case. This abuse is non-trivial; you are correct. I have spent alot of time abusing C++ and Java for it to come more naturally to me.
However, I don't think it will ever come as naturally to me as functional programming. I am not saying that I do not use OO techniques in my functional code. You can see a sort of dynamic dispatch mimicked by function passing and you can see pseudo-object in functions that return different functions, each operating on the same lexically captured bindings. I am just saying that OO is over-hyped and I feel that the functional paradigm effectively captures OO benefits.
APL's style of data oriented processing has also shown to be much faster and require far less code. Why develop a library when it only takes a single line implement the functionality? Also when you language supports dynamically evaluating a string code reuse in terms of modifying a string then evaluating is phenominal (plus the on-the-fly compiler gets to optimize the hell out of it).