I don't think BSD vs GPL license is the relevant factor for the slower flow of patches in *BSD compared to Linux.
I believe the relevant factors here are "code base size", "CVS", "GNATS", and many developers, and the culture that flows from them.
The BSDs had (and to a degree has) a hard time with getting patches into the system, because nobody/too few has this as their primary responsibility/priority. The reason for this, again, is that it is less mental gruel with writing code from scratch than it is with trying to get somebody elses code in shape and commit it.
In Linux, there's a single person (Linus) that has primary authority to change the tree, and he can botch it and will be forgiven for it (especially in the start of the Linux project). In *BSD, the dynamics are different - botches are actually somewhat tolerated, but it doesn't *feel* that way.
Eivind (FreeBSD developer)
In my opinion, XML is a lousy design for human text editing. Way too unvieldy. Look at e.g. YAML (http://www.yaml.org/) for an example of how to do this more human-friendly (and with less waste for the machines involved.)
Alas, XML became a standard and Apple use it all through OSX, so it's reasonable that they use it here, too.
This assumes the Copenhagen/Conscious Observer interpretation of quantum physics. I tend to dislike these, and I especially dislike that people discuss things as if these are quantum mechanics. Quantum mechanics are the maths.
> You can't have bits and pieces of code GPLed and some not.
Eh? You definately can, as long as there is an interface separating them. This is both the actual intention of the GPL, and if it hadn't been, there are the legal precedents that licenses don't cross interface boundaries. And the way the BSD projects generally do this is by having different *programs* under different licenses.
> Other licences are more flexible, but are less precise.
I am unsure of what you mean by this. The GPL is textually a brilliant piece of propaganda, but fairly icky when it comes to being easy to read precisely.
> I'll still be using the GPL for most of the code
> I write, because I want as many people as
> possible to use it, and be fully secure in doing
> so.
This statement makes no sense to me. Could you please explain?
I've studied license impact and what beliefs people have around it for years. One of the primary ones are that the GPL necessarily will make for more free code due to commercial companies releasing their code changes (which is only true under the assumption that commercial companies do the same work no matter if they can sell it or not, and/or will keep all changes they can no matter what.)
But I've not seen "be secure" before, and would like to hear the reasoning behind it. I'm always looking for data can make me understand these issues deeper than before.
Please state five SPECIFIC things you think should be covered by software patents. Five patents you think are good and just. The very best you can think of.
Then we'll analyse how development around the ideas would have been without software patents, based on general development.
Patents are intended to increase invention. I'm asking for five simple examples. Heck, even one would be a start.
Generalized hand-waving is easy, and for mental children. Now come over and play the adult form of debate.
Disclaimer: I'm a FreeBSD developer, with the bias that brings.
I think it is a good choice for the OpenBSD cases. It allows development to be done at better development speed and with cleaner code than something trying to be completely portable. This makes it easier to track security and work with the code.
I'll also note that most software that is "portable" today is written using GNU autotools, which makes it, on average, less portable than software was before autoconf. Either it works at once (this happens reasonable often), or there is a significant amount of pain to make it work. Ten to fifteen years ago, there was usually some work involved, but the average was less, and it was spread out.
Separating the porting part from the initial clean codebase means that it is possible to debug them separately, and when autotools fails, it is easier to go around them.
Our experience, after doing this for 10 years (I personally have been a developer for 7.5 years) is that we get serious problems whenever we try to go feature based, because we get wrong priorities, and it end up with releases taking too long and there being less feature development overall.
This is why we want to switch back to a time based release cycle. We have had long discussions about this (there have been hundreds of messages debating various issues around it), and the overall result is that we believe things get better in close to every way with time based releases, based on what happens in practice.
As we introduce fairly major features reasonably often, there will be major features introduced to releases. We just stop promising major features that are not yet implemented in a particular release. If there were nothing major new, we wouldn't bother with the work of cutting a new -stable branch.
Eivind.
Re:NetBSD faster than FreeBSD???
on
FreeBSD 5.3 Released
·
· Score: 3, Insightful
I'm a FreeBSD developer.
The issue the grandparent is alluding to is that we've had some performance hits in early 5.x versions compared to our own 4.x branch. This is due to introducing a wider SMP model, and the necessity for locks for this. However, this is infrastructure for a overall speedup, and we are continually moving more of the code over to the higher performance model.
As far as I know (from what numbers I have seen), we're still faster than NetBSD overall in 5.x, but not in all subcases.
Apart from that, the folklore is a simplification. FreeBSD has several platforms, and we have generally had good performance, but it isn't a really specific focus. It's just something we are good at (compared to the other BSDs, and in many cases compared to Linux). We're also good at general support of software (there are over 11,000 packages for FreeBSD), documentation, etc.
FreeBSD, NetBSD, and DragonflyBSD has taken a number of different routes for optimization lately. It is not clear which of these will lead to be the best performance over time; it may be that FreeBSD will keep a lead, or it may be that one of the others will overtake us. Speed is a game everybody plays.
I've made patches to mergemaster that does this a long time ago.
These patches are available from my homepage at http://people.freebsd.org/~eivind/. They have not been integrated into mergemaster due to lack of time to review them on the part of the mergemaster maintainer.
However, this is just a more specific case of doing a 3-way merge. I was planning to add this to mergemaster, but due to the issues of maintainer timeout (over a two-year period), I've instead written a new tool: See/usr/ports/sysutils/etcmerge.
This does a full 3-way merge, which means that you usually need no manual interaction (as opposed to all you need to do with mergemaster.)
I'm presently preparing this tool for possible import into FreeBSD, so there will be some enhanchements in the next couple of days.
Mostly, I'm doing this in Ruby because I personally want to use it with Ruby - and if nobody else use it, having it available for my own use is enough motivation to develop it. If I were to develop it in Java, it just wouldn't happen - because Ruby is so much more pleasant to program in.
Also, I don't see replacing SQL per se as my goal. My goals are (haphazardly arranged):
To make a tool that is useful to myself. I like programming in Ruby more than I like programming in Java.
To make a tool that is useful to my friends. And my friends mostly program in Ruby, Perl and C/C++.
To learn more about how implementations of the full relational model work inside programs. For me, this requires implementations in Ruby or Perl, because those are the languages I've done much professional programming in lately (moving towards Ruby as much as I can)
To inject knowledge about how the relational world built on non-SQL queries can be to the overall programming community. I believe I can do this more efficiently in Ruby than in Java, because I know many of the central Ruby players, the Ruby community is small enough that a technology fairly easily can go through the entire community, and many of the central development method people (Martin Fowler, Alistair Cockburn, Ron Jeffries) are using Ruby. Some of them are also using Java, but Java is slower in technology spreading and has more 'competiton'.
Learn about the interaction between the relational model and unit tests; I know the negative interactions between SQL and unit tests, but I know that some aspects of those problems are pure SQL problems - and I want to see how much of them are.
None of the things I hope to achieve are likely to happen through a Java implementation. Even if a Java implementation should replace SQL, that would not make my world significantly better. For me, having to use a language with "training wheels" (required type annotations) and the resulting limitations would be even more of a problem as having to deal with the limitations of the SQL model. Groovy looks like it might rememedy this, but it ain't there yet - and Ruby is available today:-)
NULL looks like something to complain about for a week after you learn databases. Then it doesn't look like something to complain about for the next five or ten years where you work with databases. Then you start to get interested in modelling and database optimization and query API designs, and NULL becomes something to complain about again.
All these comments about "NULL is not a problem, you lack understanding of SQL" or "SQL is a not a problem, you just don't understand it" are quite insulting.
Most of us that criticize SQL know it quite well. We know its history (did you know that SQL was selected as standard because there were two warring factions with their own agendas, and SQL was brought forth as a third alternative that everybody agreed was worse than both, but which was politically possible to accept?), we know the idosyncracies of NULL (how it blocks us from doing the easy transforms of the query trees, because there suddenly isn't available a sensible NOT operation - NOT A > B is different from A
And we think we may know how to fix some of the problems, so we're trying to do some work in that direction, to see if we're right.
Unless you think SQL is perfect, you should be cheering.
Why oh why can't I moderate "Wrong", so people see that and stop up-moderating.
Originally criticized quote:
"but the syntax is often inconsistent and unless you use one of the many vendor-specific supersets of SQL it can be tricky to express complex series of operations in a concise manner."
Notice the parts that are bold here.
There are a bunch of cases that are tricky to express well in SQL, and where a consice representation requires vendor-specific SQL. The two examples that come to mind for me are hirarchies and string matching; hierarchies are quite icky to do without vendor extensions (there are a number of tricks that makes this sort of work, but it is still not possible to do consisely and clearly), and case insensitve string matching (not to talk of complex string matching.)
And that's not even considering varying performance profiles for queries - even assuming the SQL is interpreted the same for different database engines (a false assumption for many cases), the performance profiles vary a lot, and this has to be tuned at the query level - while it should have been tunable by meta-operations on the queries.
As for the talk in the parent criticizing the quoted article's understanding of NULL: There is nothing in either the quoted article or the critique indicating a misunderstanding of NULL. However, it is quite clear that the parent misunderstand the quoted article and then attacks his misunderstanding.
The quoted article discuss the logical inconsistencies in the SQL NULL demonstrated by the two statements "NOT field = 47" and "field 47" resulting in a different result set in the precense of NULL.
As for "SQL is neither clunky nor obsolete", I request that the poster actually spend a month or two trying to find out how SQL is clunky, and what damage this clunkiness does in practice. I've so far attempted to analyse the problem for a little over a year, and I'm still
People that have not attempted to program in different variants of the relational model than SQL should IMO have enough pride to refuse to have an opinion.
You're losing one major benefit of having a lighter weight language than Java: Ad-hoc queries.
Having to write and compile code to do ad-hoc queries instead of running it in a standard line-based CLI with command history.
So, I see the value in playing with a full new language.
However, I personally prefer having the relational model available as an API integrated with my main language - so I'm actually working on an implementation of a "D" as a library for Ruby, my favourite language. There, the objection I had above mostly fall away - because Ruby is available in a command line form, and is light weight enough / has enough support for sort of creating domain specific languages that you get little benefit from creating an entirely new language like Tutorial D (I can do my ad-hoc queries in the interactive Ruby shell irb.)
Think of the different small OSen as experiments in culture and development technology. At some point, one of them may hit a sweet spot and grow. "Work together" is in my opinion not the answer - it is the question. And people are experimenting to try to find the answer.
In a free marketplace, supply and demand rule the market. A human life is worth as much or as little as the market says. So, go out with 2 million dollars and try to pay someone to get killed. Good luck.
You're comparing apples and oranges. Free marketplaces are specifically only relevant for some form of commodities. Lives of people in general are a commodity to society; they can be traded back and forth, and in a situation of scarce resources, they have to be.
Your individual life is, however, not a commodity to you. It is the ultimate non-commodity - you have one of it, and can't trade it back if you've traded it away.
Also, the figure you quote is for a SOLDIER's life.
That's right. It is roughly in the middle of the range of values I've seen, and is one that is simple to remember, so I've chosen to remember that one for this kind of discussion. There are other values used by e.g. insurance companies.
assuming you can put a dollar value on a human life, which I personally think is impossible
It isn't just possible - it is routinely done.
I personally find refusing to accept that one can and should set dollar values on human life to be disrespectful of human life. I see it as refusing to accept and use one of the most powerful tools we have for optimizing human lives because it "feels bad" and requires hard thinking and hard choices.
It makes absolutely no sense to value a thing above a person.
This statement is a false axiom; it leads to contradictions. Let me give you the correct axioms: A thing only has value as a means to do something - it is always relative. Let's for instance say that I'm in a triage situation after a major car accident - 30 cars hit each other on the autobahn, lots of wounded, and I have a roll of tape, which can be used to stabilize the position of the heads of people so they can breathe. There's roughly fifty wounded, and I've only got enough tape to bind up 25 of these. In this case, I may let a person die to save the piece of tape necessary to bind them up. Here, I value their life below a piece of tape - and it is a correct decision, because that piece of tape can be used to save another life.
The judgement scales up to more abstract situations. We do not have infinite resources pushed into health care - another case of putting a higher value on "things" (money) than lives. Every skyscraper built has some construction workers die - it's "part of doing business", We as a society has limited resources, and some people will actually die as a result of this. It is brutal, and it is an inevitable result of living in a real world.
As for the value of Mona Lisa vs human life: I've actually got a figure for the value of human life, from military operations. That's $2 million plus training costs for the individual. As far as I know, this is in rough (give or take a factor of 3) agreement with the values assigned in other contexts where we actually have to calculate with human lives due to limited resources.
I don't know the value of the Mona Lisa - but I know that The Scream was valued (apart from "priceless";) at about $80 million. We as a society run by demand and supply has ended up with a market value (the relative value in the free situation) of at least ten people for that one painting (and Mona Lisa is definately more expensive).
A person is what creates things.
Can't argue with that, except when it's a monkey that makes the art and an abstract painter that sells it;-)
I'm not sure I agree with you. We need a good way to interface with the relational model, but I am uncertain if we need a special language for this.
I'm finding that the logic of my systems goes up into the domain space where I want OO a lot, *and* that they go down into the database where I want the relational model a lot.
I agree with you that embedding SQL or query interfaces strongly based on SQL does not cut it; however, I'm uncertain if a special language will cut it, either.
I'm presently working on an implementation of the relational algebra directly in Ruby. I do this by generating SQL, but having objects representing relations - full relations, not tables - in Ruby. I hope this will help me by giving full flexibility for relational manipulation both for production code and for the unit tests, while keeping the full OO model available for the cases where this is more appropriate.
I beg to disagree with Ruby doing nothing better than Smalltalk.
Ruby and Smalltalk both think of everything as an object and have a "bullet list" of main language features that are similar, true.
However, they have a quite different environment integration, a quite different syntactic style, a different programming culture, leading to them being different in practice, with different strengths and weaknesses.
To be more specific:
Environment:
Ruby programs run from standard files, where they go from line 1 in the script being started to finish. Smalltalk generally work as an image where the programmer edit "everything", and then select an arbitrary place to execute from when the user use it as a program. Using something as a program generally involves a so called "image extraction", where the programmer point at a place to start, and then the compiler extract everything necessary to run from there (and probably a bit extra).
Ruby works quite easily with external libraries, having a standard fashion to create bindings (easy, since Ruby only has one real implementation). Smalltalk doesn't - there's variaton from implementation to implementation.
Ruby works easily with external commands, having several standard ways to execute operating system commands. Smalltalk has no standard way, requireing different ways depending on which implementation you use.
Ruby has standard libraries for network programming. Smalltalk doesn't.
Syntactic style:
Smalltalk has a very, very simple syntax and set of control structures. It was implemented because Alan Kay felt that Lisp ended up with too many "special forms" (similar to for, if, while, switch, etc in C). Basically, Smalltalk has one operation: Send a message to an object. If is implemented by having methods for true and false on an "if object".
Ruby, on the other hand, has a rich set of control structures and syntax, in the spirit of most contemporary languages (C, Java, Python, Perl, etc). It has even added string interpolation and regular expressions to the syntax, making it very easy to deal with these constructs. (Regular expressions is, BTW, another thing that Smalltalk has no standard support for. See e.g. http://www.smalltalk.org/articles/article_20040917 _a1.html for a discussion around this.)
The Programming Culture:
The Ruby programming culture is fairly heavy on metaprogramming and library use. People use standard tools for editing files, version control, searching through the code, etc. Documentation is generally stored as standard comments in the code. If you want to make them browsable or make it possible to do easy lookups in them, you run separate tools to extract them (rdoc to extract to HTML and ri, ri to look up).
The Smalltalk community use special code browser for going through the code. This works on parse trees and the heavily normalized form of Smalltalk. If you want to add comments, this has to be done separately, and is stored separately from the code. You cannot use a standard text editor to edit the code and comments. On the other hand, the normal form of Smalltalk makes it very easy to write tools that work on the code, and this is standard practice. On result of this is the "Refactoring browser", making it possible to do refactorings directly, instead of having to do the manual edits necessary. However, there is very little use of metaprogramming, as that gets in the way of the paradigm. Version control is also handled internally in the Smalltalk image.
End result:
Ruby lets the programmer leverage the habits and tools he or she is used to, while Smalltalk only lets the programmer leverage abstract programming knowledge and the tools that are built into Smalltalk.
The tools that are built into Smalltalk are generally very, very good, but this requirement form a barrier to the wide adoption of Smalltalk. If the entire world was in Smalltalk, it might be a better place, but as it is, the world is not in Smalltalk. The end result is one more thing that Ruby is better at that Smalltalk: Getting programmer adoption. There are presently about 300,000 pages found by a search for "smalltalk language" - against 1.1 million for "ruby language".
As a developer with the FreeBSD project, I can say with certainity that there do come benefits from proprietary derivates of BSD-
Specific examples:
The entire SCSI subsystem of FreeBSD (CAM) comes from a proprietary derivate
The entire netgraph subsystem (network transformation system) comes from a proprietary derivate
Many of our core developers are employed by companies making proprietary derivates
The mpd multilink PPP daemon came from a company that made a proprietary derivate
We've also got a ton of other submissions, but bugfixes and feature enhancements.
Now, we can have an economics debate about which license results in the most contributions - but claiming that "if a company uses your source in a closed product you dont get any future benefit" is plain misinformation.
VB is NOT an easy language. VB is a very, very hard language.
It is a language that it is simple to get started with, sure, but it is, for a professional programmer, a language full of tedium and details that need to be remembered.
I did read the freakin' article; it was irrelevant to my point. Go read the freakin' reply which tell you WHY. And your Java code wasn't most of the issue; your judgmental comments were.
And I still claim: Only judge between things you know. But this is Slashdot - maybe expecting thought is too much to ask.
I copy and pasted that code out of the article - I didn't make it up.
So?
You were criticizing the language, not the article. That code was awful Ruby. Your code was good Java.
I've seen awful Java a lot of times - but I don't rewrite that to good Ruby and then criticize Java based on the single awful piece.
I read both Java and Ruby more or less daily (neither is my primary pay-the-bills language at the moment, though I've paid bills with both before, and expect to do so again). My personal, subjective experience is that Ruby is usually (but not always) more readable, because Ruby contains only close to the exact stuff the programmer wants to happen, while Java contains a lot of extra stuff to satisfy the language (primarily various forms of type annotations, variable declarations, casts, etc).
As for minimizing line counts: You mentioned Perl. My experience with translations from Perl to Ruby is that the non-comment lines of code end up at fairly precisely half the number in Ruby compared to Perl. This is with a close to raw translation (the only Ruby idiom I've utilized for that kind of translation has been the counting iterators from the standard library.)
I'm not sure what you mean by "But looking at the redundant entropy in the bytes (I won't huff it for you) I can tell that this code looks more complicated.".
If it is that Ruby has more signal per byte of source code: Definately! Ruby has had as an explict goal that it should succint, letting the programmer specify his intentions in short and clear terms.
If it is that the Ruby program you wrote a parallell to was more complicated than the Java program: Sure. It contained more complications; first, it did cross-language interfacing (using libraries that were not written for Ruby), and second, it had a ton of unnecessary complications that had nothing to do with the task at hand, but were just left from bad programming.
Slashdot Mirror
I don't think BSD vs GPL license is the relevant factor for the slower flow of patches in *BSD compared to Linux. I believe the relevant factors here are "code base size", "CVS", "GNATS", and many developers, and the culture that flows from them. The BSDs had (and to a degree has) a hard time with getting patches into the system, because nobody/too few has this as their primary responsibility/priority. The reason for this, again, is that it is less mental gruel with writing code from scratch than it is with trying to get somebody elses code in shape and commit it. In Linux, there's a single person (Linus) that has primary authority to change the tree, and he can botch it and will be forgiven for it (especially in the start of the Linux project). In *BSD, the dynamics are different - botches are actually somewhat tolerated, but it doesn't *feel* that way. Eivind (FreeBSD developer)
In my opinion, XML is a lousy design for human text editing. Way too unvieldy. Look at e.g. YAML (http://www.yaml.org/) for an example of how to do this more human-friendly (and with less waste for the machines involved.)
Alas, XML became a standard and Apple use it all through OSX, so it's reasonable that they use it here, too.
Eivind.
I like John G Cramer's or Feynman's Path Integrals.
There is an overview of various interpretations in Wikipedia.
Eivind.
Eh? You definately can, as long as there is an interface separating them. This is both the actual intention of the GPL, and if it hadn't been, there are the legal precedents that licenses don't cross interface boundaries. And the way the BSD projects generally do this is by having different *programs* under different licenses.
> Other licences are more flexible, but are less precise.
I am unsure of what you mean by this. The GPL is textually a brilliant piece of propaganda, but fairly icky when it comes to being easy to read precisely.
> I'll still be using the GPL for most of the code > I write, because I want as many people as > possible to use it, and be fully secure in doing > so.
This statement makes no sense to me. Could you please explain?
I've studied license impact and what beliefs people have around it for years. One of the primary ones are that the GPL necessarily will make for more free code due to commercial companies releasing their code changes (which is only true under the assumption that commercial companies do the same work no matter if they can sell it or not, and/or will keep all changes they can no matter what.)
But I've not seen "be secure" before, and would like to hear the reasoning behind it. I'm always looking for data can make me understand these issues deeper than before.
Eivind.
Then we'll analyse how development around the ideas would have been without software patents, based on general development.
Patents are intended to increase invention. I'm asking for five simple examples. Heck, even one would be a start.
Generalized hand-waving is easy, and for mental children. Now come over and play the adult form of debate.
Eivind.
PHK has a very direct and fairly brutal communication form that I personally find effective and some people find offensive.
DES has an unfortunate communication style and is occasionally prone to temper.
But that's it.
Eivind.
I think it is a good choice for the OpenBSD cases. It allows development to be done at better development speed and with cleaner code than something trying to be completely portable. This makes it easier to track security and work with the code.
I'll also note that most software that is "portable" today is written using GNU autotools, which makes it, on average, less portable than software was before autoconf. Either it works at once (this happens reasonable often), or there is a significant amount of pain to make it work. Ten to fifteen years ago, there was usually some work involved, but the average was less, and it was spread out.
Separating the porting part from the initial clean codebase means that it is possible to debug them separately, and when autotools fails, it is easier to go around them.
Eivind.
Our experience, after doing this for 10 years (I personally have been a developer for 7.5 years) is that we get serious problems whenever we try to go feature based, because we get wrong priorities, and it end up with releases taking too long and there being less feature development overall.
This is why we want to switch back to a time based release cycle. We have had long discussions about this (there have been hundreds of messages debating various issues around it), and the overall result is that we believe things get better in close to every way with time based releases, based on what happens in practice.
As we introduce fairly major features reasonably often, there will be major features introduced to releases. We just stop promising major features that are not yet implemented in a particular release. If there were nothing major new, we wouldn't bother with the work of cutting a new -stable branch.
Eivind.
The issue the grandparent is alluding to is that we've had some performance hits in early 5.x versions compared to our own 4.x branch. This is due to introducing a wider SMP model, and the necessity for locks for this. However, this is infrastructure for a overall speedup, and we are continually moving more of the code over to the higher performance model.
As far as I know (from what numbers I have seen), we're still faster than NetBSD overall in 5.x, but not in all subcases.
Apart from that, the folklore is a simplification. FreeBSD has several platforms, and we have generally had good performance, but it isn't a really specific focus. It's just something we are good at (compared to the other BSDs, and in many cases compared to Linux). We're also good at general support of software (there are over 11,000 packages for FreeBSD), documentation, etc.
FreeBSD, NetBSD, and DragonflyBSD has taken a number of different routes for optimization lately. It is not clear which of these will lead to be the best performance over time; it may be that FreeBSD will keep a lead, or it may be that one of the others will overtake us. Speed is a game everybody plays.
Eivind.
However, this is just a more specific case of doing a 3-way merge. I was planning to add this to mergemaster, but due to the issues of maintainer timeout (over a two-year period), I've instead written a new tool: See /usr/ports/sysutils/etcmerge.
This does a full 3-way merge, which means that you usually need no manual interaction (as opposed to all you need to do with mergemaster.)
I'm presently preparing this tool for possible import into FreeBSD, so there will be some enhanchements in the next couple of days.
Eivind.
Also, I don't see replacing SQL per se as my goal. My goals are (haphazardly arranged):
None of the things I hope to achieve are likely to happen through a Java implementation. Even if a Java implementation should replace SQL, that would not make my world significantly better. For me, having to use a language with "training wheels" (required type annotations) and the resulting limitations would be even more of a problem as having to deal with the limitations of the SQL model. Groovy looks like it might rememedy this, but it ain't there yet - and Ruby is available today :-)
Eivind.
All these comments about "NULL is not a problem, you lack understanding of SQL" or "SQL is a not a problem, you just don't understand it" are quite insulting.
Most of us that criticize SQL know it quite well. We know its history (did you know that SQL was selected as standard because there were two warring factions with their own agendas, and SQL was brought forth as a third alternative that everybody agreed was worse than both, but which was politically possible to accept?), we know the idosyncracies of NULL (how it blocks us from doing the easy transforms of the query trees, because there suddenly isn't available a sensible NOT operation - NOT A > B is different from A And we think we may know how to fix some of the problems, so we're trying to do some work in that direction, to see if we're right.
Unless you think SQL is perfect, you should be cheering.
Eivind.
Originally criticized quote: "but the syntax is often inconsistent and unless you use one of the many vendor-specific supersets of SQL it can be tricky to express complex series of operations in a concise manner."
Notice the parts that are bold here.
There are a bunch of cases that are tricky to express well in SQL, and where a consice representation requires vendor-specific SQL. The two examples that come to mind for me are hirarchies and string matching; hierarchies are quite icky to do without vendor extensions (there are a number of tricks that makes this sort of work, but it is still not possible to do consisely and clearly), and case insensitve string matching (not to talk of complex string matching.)
And that's not even considering varying performance profiles for queries - even assuming the SQL is interpreted the same for different database engines (a false assumption for many cases), the performance profiles vary a lot, and this has to be tuned at the query level - while it should have been tunable by meta-operations on the queries.
As for the talk in the parent criticizing the quoted article's understanding of NULL: There is nothing in either the quoted article or the critique indicating a misunderstanding of NULL. However, it is quite clear that the parent misunderstand the quoted article and then attacks his misunderstanding.
The quoted article discuss the logical inconsistencies in the SQL NULL demonstrated by the two statements "NOT field = 47" and "field 47" resulting in a different result set in the precense of NULL.
As for "SQL is neither clunky nor obsolete", I request that the poster actually spend a month or two trying to find out how SQL is clunky, and what damage this clunkiness does in practice. I've so far attempted to analyse the problem for a little over a year, and I'm still People that have not attempted to program in different variants of the relational model than SQL should IMO have enough pride to refuse to have an opinion.
Eivind.
Having to write and compile code to do ad-hoc queries instead of running it in a standard line-based CLI with command history.
So, I see the value in playing with a full new language.
However, I personally prefer having the relational model available as an API integrated with my main language - so I'm actually working on an implementation of a "D" as a library for Ruby, my favourite language. There, the objection I had above mostly fall away - because Ruby is available in a command line form, and is light weight enough / has enough support for sort of creating domain specific languages that you get little benefit from creating an entirely new language like Tutorial D (I can do my ad-hoc queries in the interactive Ruby shell irb.)
Eivind.
Eivind.
You're comparing apples and oranges. Free marketplaces are specifically only relevant for some form of commodities. Lives of people in general are a commodity to society; they can be traded back and forth, and in a situation of scarce resources, they have to be.
Your individual life is, however, not a commodity to you. It is the ultimate non-commodity - you have one of it, and can't trade it back if you've traded it away.
Also, the figure you quote is for a SOLDIER's life.
That's right. It is roughly in the middle of the range of values I've seen, and is one that is simple to remember, so I've chosen to remember that one for this kind of discussion. There are other values used by e.g. insurance companies.
assuming you can put a dollar value on a human life, which I personally think is impossible
It isn't just possible - it is routinely done.
I personally find refusing to accept that one can and should set dollar values on human life to be disrespectful of human life. I see it as refusing to accept and use one of the most powerful tools we have for optimizing human lives because it "feels bad" and requires hard thinking and hard choices.
Eivind.
This statement is a false axiom; it leads to contradictions. Let me give you the correct axioms: A thing only has value as a means to do something - it is always relative. Let's for instance say that I'm in a triage situation after a major car accident - 30 cars hit each other on the autobahn, lots of wounded, and I have a roll of tape, which can be used to stabilize the position of the heads of people so they can breathe. There's roughly fifty wounded, and I've only got enough tape to bind up 25 of these. In this case, I may let a person die to save the piece of tape necessary to bind them up. Here, I value their life below a piece of tape - and it is a correct decision, because that piece of tape can be used to save another life.
The judgement scales up to more abstract situations. We do not have infinite resources pushed into health care - another case of putting a higher value on "things" (money) than lives. Every skyscraper built has some construction workers die - it's "part of doing business", We as a society has limited resources, and some people will actually die as a result of this. It is brutal, and it is an inevitable result of living in a real world.
As for the value of Mona Lisa vs human life: I've actually got a figure for the value of human life, from military operations. That's $2 million plus training costs for the individual. As far as I know, this is in rough (give or take a factor of 3) agreement with the values assigned in other contexts where we actually have to calculate with human lives due to limited resources.
I don't know the value of the Mona Lisa - but I know that The Scream was valued (apart from "priceless" ;) at about $80 million. We as a society run by demand and supply has ended up with a market value (the relative value in the free situation) of at least ten people for that one painting (and Mona Lisa is definately more expensive).
A person is what creates things.
Can't argue with that, except when it's a monkey that makes the art and an abstract painter that sells it ;-)
Eivind.
And I don't know of any particular advantage of UVM in practice; as far as I've understood, the performance in practice is not as good with FreeBSD.
If you've got information to the contrary, please share!
Eivind.
I'm finding that the logic of my systems goes up into the domain space where I want OO a lot, *and* that they go down into the database where I want the relational model a lot.
I agree with you that embedding SQL or query interfaces strongly based on SQL does not cut it; however, I'm uncertain if a special language will cut it, either.
I'm presently working on an implementation of the relational algebra directly in Ruby. I do this by generating SQL, but having objects representing relations - full relations, not tables - in Ruby. I hope this will help me by giving full flexibility for relational manipulation both for production code and for the unit tests, while keeping the full OO model available for the cases where this is more appropriate.
Eivind.
Ruby and Smalltalk both think of everything as an object and have a "bullet list" of main language features that are similar, true.
However, they have a quite different environment integration, a quite different syntactic style, a different programming culture, leading to them being different in practice, with different strengths and weaknesses.
To be more specific:
Environment:
Syntactic style:
Smalltalk has a very, very simple syntax and set of control structures. It was implemented because Alan Kay felt that Lisp ended up with too many "special forms" (similar to for, if, while, switch, etc in C). Basically, Smalltalk has one operation: Send a message to an object. If is implemented by having methods for true and false on an "if object".
Ruby, on the other hand, has a rich set of control structures and syntax, in the spirit of most contemporary languages (C, Java, Python, Perl, etc). It has even added string interpolation and regular expressions to the syntax, making it very easy to deal with these constructs. (Regular expressions is, BTW, another thing that Smalltalk has no standard support for. See e.g. http://www.smalltalk.org/articles/article_20040917 _a1.html for a discussion around this.)
The Programming Culture:
The Ruby programming culture is fairly heavy on metaprogramming and library use. People use standard tools for editing files, version control, searching through the code, etc. Documentation is generally stored as standard comments in the code. If you want to make them browsable or make it possible to do easy lookups in them, you run separate tools to extract them (rdoc to extract to HTML and ri, ri to look up).
The Smalltalk community use special code browser for going through the code. This works on parse trees and the heavily normalized form of Smalltalk. If you want to add comments, this has to be done separately, and is stored separately from the code. You cannot use a standard text editor to edit the code and comments. On the other hand, the normal form of Smalltalk makes it very easy to write tools that work on the code, and this is standard practice. On result of this is the "Refactoring browser", making it possible to do refactorings directly, instead of having to do the manual edits necessary. However, there is very little use of metaprogramming, as that gets in the way of the paradigm. Version control is also handled internally in the Smalltalk image.
End result:
Ruby lets the programmer leverage the habits and tools he or she is used to, while Smalltalk only lets the programmer leverage abstract programming knowledge and the tools that are built into Smalltalk.
The tools that are built into Smalltalk are generally very, very good, but this requirement form a barrier to the wide adoption of Smalltalk. If the entire world was in Smalltalk, it might be a better place, but as it is, the world is not in Smalltalk. The end result is one more thing that Ruby is better at that Smalltalk: Getting programmer adoption. There are presently about 300,000 pages found by a search for "smalltalk language" - against 1.1 million for "ruby language".
Eivind.
This makes it possible to handle all of your cases beautifully, even if blocks[1] had been the only core feature.
Eivind.
[1] Technically, passing the callback in the block slot of the method in question. Blocks is a syntactic structure.
As a developer with the FreeBSD project, I can say with certainity that there do come benefits from proprietary derivates of BSD-
Specific examples:
- The entire SCSI subsystem of FreeBSD (CAM) comes from a proprietary derivate
- The entire netgraph subsystem (network transformation system) comes from a proprietary derivate
- Many of our core developers are employed by companies making proprietary derivates
- The mpd multilink PPP daemon came from a company that made a proprietary derivate
We've also got a ton of other submissions, but bugfixes and feature enhancements.Now, we can have an economics debate about which license results in the most contributions - but claiming that "if a company uses your source in a closed product you dont get any future benefit" is plain misinformation.
Eivind.
It is a language that it is simple to get started with, sure, but it is, for a professional programmer, a language full of tedium and details that need to be remembered.
EIvind.
And I still claim: Only judge between things you know. But this is Slashdot - maybe expecting thought is too much to ask.
Eivind.
So?
You were criticizing the language, not the article. That code was awful Ruby. Your code was good Java.
I've seen awful Java a lot of times - but I don't rewrite that to good Ruby and then criticize Java based on the single awful piece.
I read both Java and Ruby more or less daily (neither is my primary pay-the-bills language at the moment, though I've paid bills with both before, and expect to do so again). My personal, subjective experience is that Ruby is usually (but not always) more readable, because Ruby contains only close to the exact stuff the programmer wants to happen, while Java contains a lot of extra stuff to satisfy the language (primarily various forms of type annotations, variable declarations, casts, etc).
As for minimizing line counts: You mentioned Perl. My experience with translations from Perl to Ruby is that the non-comment lines of code end up at fairly precisely half the number in Ruby compared to Perl. This is with a close to raw translation (the only Ruby idiom I've utilized for that kind of translation has been the counting iterators from the standard library.)
I'm not sure what you mean by "But looking at the redundant entropy in the bytes (I won't huff it for you) I can tell that this code looks more complicated.".
If it is that Ruby has more signal per byte of source code: Definately! Ruby has had as an explict goal that it should succint, letting the programmer specify his intentions in short and clear terms.
If it is that the Ruby program you wrote a parallell to was more complicated than the Java program: Sure. It contained more complications; first, it did cross-language interfacing (using libraries that were not written for Ruby), and second, it had a ton of unnecessary complications that had nothing to do with the task at hand, but were just left from bad programming.
Eivind.