That being said, I can think of a few literary projects that worked like Open Source. The Cthulhu mythology is an example: one moderator who sets the vision and the standards (H.P. Lovecraft), a group of collaborators (A. Derleth et al) and a general public of writers bent on expanding the myth.
One could argue that software development is best done this way as well: with a very small group of developers (or even an individual) "steering" the development, and many other developers actually implementing the various bits and pieces. Software developed by committees tend to suck. Take COBOL for example. Many open source software projects, and commercial projects for that matter, have a small set of "core developers".
So maybe a more Open Source model is possible for writing; that sounds like it has a lot of potential. I know all you did was raise a potential flamebait in my post, Zagadka, but you did make me reconsider my position!
I think you're a bit too sensitive if you thought that was flamebait. It always bothers me when people don't consider software development to be creative or artistic. Software development is just as creative as architecture or classical music composition. Yes, there are strict rules that must be followed, but the truly creative learn to work within the rules rather than be constrained by them.
UGH! They better not! If they did, the show would end up like Sliders. Just kill it, and use your highly-paid creative mind to come up with something new for a change.
Yeah, I could just see it... Fox Mulder is abducted by aliens, who make him look completely different, and then release him. Scully eventually believes that it really is him, but refuses to believe the alien part of the story. She thinks he just got a new haircut...
It may not be "open source", but indeed, writers need to make money somehow from this. The equivalent of open source for written works would be to put it up on your webpage and allow people to contribute to it. It's a neat idea, but I feel there is an additional factor with an artistic product, and that is artist integrity.
Yeah, it's that "knowing what you are doing" bit that gets me.
What? Do you use the infinite monkeys with typewriters method of coding? You have to learn the language you're using.
I think he's referring to the fact that C++ tries to hide a lot of things from you with the intention of being "easy", but it often ends up doing things you hadn't intended.
In my experience C++ does not "hide" things from you, although depending on what environment you're coding in (VC++ with MFC [nudge nudge wink wink]) they you are going to find a lot of voodoo and black magic behind the scenes.
But the language itself and even the STL (if the implementation conforms to the performance requirements) does not do anything unexpected. You take a performance hit on virtual functions and sometimes on templates, mostly becuase of their extensive use of virtual functions (in my experience).
Huh? Templates and virtual functions are completely orthogonal. The performance hit with templates tends to be more related to template bloat (ie: every instantiation is yet another copy of essentially the same code). Most of the template code I've seen actually made very little use of virtual functions.
If you're taking a performance hit on temporary variable initialization you're using a bad design. Most such temp vars occur on function call boundries and can be resolved with the effective use of const references in passed class paramaters and plain references in returned classes.
I'm not sure how you're going to reduce temporary instantiation by returning plain references. I'd like to see an example of this. Do you mean passing plain references as "out" paramaters instead of having a return value? That works, but results in harder to read code in many situations, and essentially precludes the use of operator overloading.
A lot of these performance hits can be avoided. The problem is, often the clearest way of writing the code has serious performance problems that aren't even obvious to the average C++ programmer. Typical C++ programs are filled with unnecessary temporary objects. Removing them requires that you rewrite the code to be much harder to read. For example, a set of matrix and vector classes with + and * operators is only encouraging people to use a coding style that creates lots of useless temporary objects. Yes, it's bad design. Bad language design.
That said, I still use C++ for some of my own "solo" projects. I think C++, like Perl, is too nasty to use for large projects with more than one developer though. It just makes it too easy for people to create unmaintainable, or plain stupid code.
Java works well for larger projects. Yes, it isn't quite as fast as C or C++, but modern JVM's are very fast. A lot of the places where Java is marginally slower are places where it does things like array-bounds checking. I'm quite glad that it does do this though. I'd rather my software let me know when something's broke, rather than just acting weird, or opening up security holes (think buffer overflow).
Remember the Commodore 128? 128K of RAM with a 6502 derivative CPU (8510? I think.) Though 512K of RAM would have been like 20 empty universes to play with back then...
The 128 had an 8502, which was derived from the 6510, which in turn was derived from the 6502. The 6510 had bank switching as well. The Commodore 64 (which had a 6510) needed that because it had 64kB of RAM, plus some ROM. Bank switching was necessary to be able to read all of the RAM. The 8502 had more advanced bank switching apparently. And there was a 512kB expander for the 128.
The 128 was a truly weird machine. I still have mine... (with the original "q isn't a letter" ROM-bug)
It's interesting to note that the 1541 (the Commodore 64's original disk drive) had a built-in 6502 processor, and (I think) 4kb of RAM. That alone would be an upgrade from an Altair in tems of computing power, but the UI of a lone 1541 kinda sucks...:-)
It's a stupid business model that fights the very essense of information, and it means you have to create artificial scarcity (tell some people they can't have it) where there ought to be abundance.
How is it different from movies or music? Or do you think it's your right to go see any movie you want for free?
Maybe you like working in tech support, but I'd rather not. I don't want to consult. I don't want to write custom hacks. I want to write code that works properly. And why would someone pay to have a custom version done, when they can just wait to have it released for free?
I'm really beginning to think that what many Open Source advocates really care about is "free as in beer", not "free as in speech".
Big-O doesn't necessarily have to do with execution time, though that's what it's typically used for. It's also frequently used for memory usage. ie: "this algorithm uses a O(n^2) buffer"
O(log n) isn't the nicest, O(1) is. O(1) is constant time. And yes, it does happen. ie: inserting at the head of a linked list is typically O(1), as opposed to inserting at the head of an array, which is O(n).
And saying "if it's O(n^2) or worse, dump the algorithm" is going too far. For sorting algorithms this may be true, but for other algorithms, O(n^2) might be very good. There are some things where there is no known efficient algorithm, where "efficient" is defined as polynomial time. So there are cases where you even have to deal with inefficient algorithms like O(n!) or O(2^n).
Also note that O-notation refers to "growth". Quicksort is O(n log n), and Linear insertion sort is O(n^2), so Quicksort wins for large datasets. Most linear insertion sort implementations will beat most quicksort implementations for very small datasets though. (and many implementations of 'qsort' will actually do something other than quicksort for very small datasets)
Oh, and there are also cases where variables other than n will come up. For instance, in text searching, one might say n is the length of the text, and m is the length of the substring. The typical brute-force string search is O(n*m). KMP (Knuth-Morris-Pratt) is O(n+m^2) I believe. If m is small, and n is very large (as is usually the case), then KMP wins. Also, the O(m*m) part can actually be done once for the substring. Each search in each body of text is then just O(n).
And to get almost back on topic, I'm working in the US on a TN Visa (that's "Temporary NAFTA"). I'm from Canada. TN's are also tied to employers, but since TN's are significantly easier to get compared to H1's, that probably isn't as much of an issue, but it is an issue.
Circumvention is an important principle in free software. I feel OK about Red Hat selling my software becuase I can always circumvent them and sell it myself. The circumvention provision here might make developers more willing to contribute to a commercial product.
But alternatively, RedHat can circumvent you as well. If you wrote some software that you wanted to sell, but also make open source, you'd be out of luck once it starts appearing on every RedHat Linux CD. RedHat can sell it at a lower price. They have better distribution channels. People have actually heard of RedHat, not Joe Developer. RedHat can spend more money on marketing. RedHat has tech support. They also have pretty boxes. In other words, packaging, distribution, tech support and marketing are being rewarded, while technical innovation goes unrewarded. (except for the reward of creating it, but you can't eat off that)
People always point at RedHat to say "see, Open Source works!" Sure, it works for non-developers selling other people's code. Yes, RedHat does write some code, but that doesn't contribute to their revenue. Because RedHat sells to Linux users, having developers is really a form of PR for them. A company that sold open source Windows software for end-users wouldn't need developers, since end-users don't care who wrote the software.
"...since people are pushing the Pilot to do things that are really outside its simple, elegant design, that it's more of a fetish symbol than a tool..."
Using that definition, I guess there are a lot of us who have duct-tape and WD-40 fetishes...
And all of you running Linux PPC on your iMac: You've got an iMac fetish. Actually, that last bit seems pretty plausible. Running Linux on a big translucent butt-cheek...:-)
Just because most sites do it, it doesn't mean it's a good thing to do. c|net used to have fixed table widths as well. Now they don't.
Putting fixed width tables around your pages tells me one thing: you should be working with paper, not HTML. The web is too powerful for you, and you want to artificially constrain it.
I am aware that many commercial sites use fixed table widths. That doesn't stop it from being a stupid thing to do.
Using your logic, all web sites should still be grey, because most web sites were grey initially, and "Consumer's [sic] like what they know."
Using fixed-width tables around web sites destroys their usability. You can fool yourself all you want, and make up statistics like "99.9999874 users use exactly the same browsing configuration as me", but the fact remains that anyone with a different screen resolution, font, font size, browser, windowing system and/or video card is probably going to see your page differently than you do. Trying to squeeze the page into some lowest common denominator resolution just pisses users off.
When 4096 pixel wide displays do become commonplace, what are you going to do? change your tables to say 'width=3000'? What about users with 640x480?
Leave out the constraint, and things will look good on every user's display.
Why does everyone designing these so-called portal sites insist on setting all their table widths to 600 pixels?
Because it is easier to read.
I think you mean "because they think it's easier to read". My point is, of course, that this is an incorrect assumption. Do you know how big my text is? Maybe I've got a really high resolution screen.
Let's pretend I had a display that was 4096 pixels across. Because I want to be able to read text, my font is set to something that gets roughly 80 charcters per line, or an average width of 51 pixels per character. So almost 12 characters will fit in that 600 pixels. See the problem here?
Yes, you don't want more than about 70 characters per line. But restricting the number of pixels per line is not the right way to do this. You don't know how big my font is, or what the resolution of my screen is.
The right thing to do is to either use a 100% width table, or use no table at all. If I have trouble reading your lines because they're too long, I'll make my browser window narrower. Artificially restricting it to a certain number of pictures only ensures that a large portion of your users will never be able to get it to look good on their display.
If you really want 30-70 characters per row, HTML will need some way of specifying widths in em's. Unfortunately, HTML is currently too brain-dead to do sizes in anything other than percentages or pixels. Using pixel sizes is the wrong thing to do for anything other than raster images.
The thing I'd like to see in the palm is more screen space. Does the writing area really need to be static? It would be great if it was part of the display. Then for programs where you don't need text entry (or only occasionally need it) that area could be used for displaying useful info. Also, when selecting "keyboard" it could appear in that area instead of covering the entire bloody screen. And people with external keyboards or handwriting recognition software could use the whole screen.
Colour would be nice, but a clear higher resolution screen would probably be better. I'd like colour, but I don't think I'd really need it, especially not if it makes the unit a lot more expensive, or drains the batteries a lot.
It really *is* a Magic 8-ball
on
Quickie Fu
·
· Score: 2
I asked it. It said "YES, definitely". So it isn't a fake...
With open source you can't differentiate your product by making it better quality, because your competitors can legally redistribute exactly the same software you do. The way you differentiate is with marketing, price, tech support and extra bonuses (eg: commercial software, manuals, penguin dolls, pretty boxes, etc.).
The Linux software market is quite different from the "normal" software market. Linux users care about open source and are less likely to buy software from a company that they don't think contributes. The average Windows or Mac user really doesn't care.
Because Red Hat sells Linux distros, it's in their best interest to have developers because that's good PR in the Linux market. If you were selling utility or application software for Windows or the Mac you wouldn't need developers. If someone starts selling an improved version of your product, you can start selling it too. As long as you have better marketing and a prettier box, you'll make more sales.
Ironically, the one thing that could possibly force you to innovate is the existence of "proprietary" software. You can't just go and redistribute proprietary software, so they'd be real competition. If all the world was open source though, competition would be reduced to marketing and packaging. Technical innovations could just be copied off the competitor's FTP servers...
Also, consider what would happen if you developed an open source application for Linux and tried to sell it. It would be almost impossible to sell, because it would probably appear on the next Red Hat CD if it's any good. No matter how much "quality" you put into it, why would people buy it from you, when they can get it from Red Hat? They've heard of Red Hat, not you.
It's also interesting to note that for support sellers, improving the quality of the product can actually be a conflict of interests. They make money on support, and lose money on development. It would be even worse if development started doing things that would reduce the amount of money made on support. This depends on the model of payments for support of course. When talking about the "free XX days support" included with a distro, then they want to reduce the amount of support required. But when talking about $XX/hour support, they'd like to increase it...
No they're not. But if you look at the article, you'll see he uses the word volunteer an awful lot.
But since you mention Red Hat, how about trying this simple mental exercise. Imagine we created graph where the X-axis is the worth of the contributions a developer has made to Red Hat 6.0, and the Y axis is the amount of money that developer has made directly as a result of those contributions. Now take all of the developers that have contributed even the tiniest fragment of code that ended up in Red Hat 6.0 and plot them on this graph. Ideally, those developers that contributed the most will have also earned the most. In actual fact, almost all of the developers will be somewhere on the X-axis, having made $0 for their contributions.
The Red Hat developers will be in the small group of points not on the X axis. They might have made some fairly significant contributions, but much less than the sum of contributions made by unpaid developers.
Red Hat makes their money from support, printed manuals and pretty boxes. If Red Hat started doing poorly, the developers would probably be among the first to lose their jobs. After-all, they don't contribute to the bottom line. (except as an expense...)
One also has to realize that Red Hat's product is not used by "normal" people. It's used by Linux users (like myself). Linux users would get ticked off at Red Hat and probably stop buying their product if RH were to fire their developers. So Red Hat has a strong incentive to keep their developers for PR reasons. Companies selling software with more non-open-source-activist users would have far less incentive to actually pay developers if they can just rely on volunteers to do the work.
I would like to see a system where all developers, whether or not they were hired by Red Hat, could earn a profit from their contributions, proportional to the worth of those contributions. Of course, that wouldn't work too well for Red Hat, because they'd have a lot more expenses than any of the other distributors. There doesn't seem to be any way to fix this and stick with the GPL.
The most disturbing thing about this is that the article goes on and on about the software being produced by volunteers. In other words, he's talking about using open source so you can get free (as in beer) labor.
Anyone with half a brain knows you can make money with Open Source. The problem is, you don't make that money by developing open source software. You make it by selling open source software other people wrote. Well duh, of course you can make money sell the work of others. Cuts downs costs quite a bit too, not having to hire developers.
When is someone going to come up with a business model where developers can actually make money on open source software? Every model I've seen so far sucks because it relies on making money off of something other than the open-source software, ie: support (support-sellers), hardware (widget frosting) or closed-source software (loss-leader). In other words, the open-source developers are either an expense or unpaid volunteers.
I wouldn't expect source level compatibility with the original Amiga IPC mechanism. Classic Amigas have no memory protection or virtual memory. Everything is in the same address space. Message passing was so quick because you could pass a single 4-byte pointer to a structure. "Hey, look at this over here!" That doesn't work in environments like Linux that have virtual memory.
Yes, a shared memory scheme could be worked up, but that would imply one of two things: Either you'd have to explicitely create the shared space (losing source compatibility), or all Amiga processes would have to execute in one giant shared address space. They'd essentially all be threads in one big mega-process. There goes your inter-application memory protection though.
They could however run all older applications in a single shared space assuming that the processor architecture will be 68k compatible (like PPC). Newer applications would probably have to use a different IPC scheme that accounts for virtual address spaces. Then your "classic" applications could still stomp on eachother, but at least they'd leave all of the newer apps alone. This could be easily extended to have multiple "classic Amiga" address spaces. Apps that need to communicate with eachother you'd have to run in the same space, otherwise they can be separate and hence protected from one another. I suppose some sort of weird "auto-merging" mechanism could even be worked out, where if one classic-Amiga process sends a message to another, the page tables of both processes are merged. That's pretty crazy though.
What if you had 100 different callbacks, each of which did different things and which played with different lexically scoped variables from different scopes?
Then I'd kill myself for creating such a poorly designed system. But the "timeout" function I created above can also accept normal functions. As mentioned earlier, I did have a version that didn't use a separate class.
I notice you completely ignored my other points. I'll assume that means you couldn't think of any way to refute them.
I also find it amusing that you said you were going to give me the last word, but apparently couldn't resist the urge to post the above.
As for the second example, I was showing you that Python is incapable of doing correct allocation on demand.
That depends on what you consider to be correct. I could just as easily say that it shows Perl is incapable of doing correct runtime bounds-checking. You seem to think that "however Perl does it is the right way". As I mentioned earlier, there are advantages and disadvantages to each approach. Oh, that's right, Perl is "the way, the truth, and the light". Perl's way of doing things has to be better.
Explain to me exacty what the [] operator is doing when I say '$a[2][5][3] = 9' and a is completely uninitialized. An expression tree for the left side of that assignment would be nice. I'd like to know the type and value of each node in that tree.
Incidently, I don't like Python's "two namespace" thing, nor do I care for the fact that it uses reference counting, and hence has problems cleaning up cycles. I've also got a love/hate relationship with the whole indentation versus braces thing. I think that, for a language the uses braces for blocks, Perl at least does the right thing in requiring blocks for things like if's, loops, etc (rather that just a statement like in C, C++, Java, etc.)
I also think the "%" operator in Python is pretty goofy. Writing a sprintf-like function in Python would be easy. With keyword arguments it would be even better than the real sprintf.
Python's "lambda" is also severely underpowered. (lambda only works with an expression, which means no side effects unless you call another (named) function/method, which sort of defeats to purpose of lambda in many situations)
I do think that Perl's "provide a million ways to do one thing" is a weakness though. Most Perl programmers know only a small fraction of those techniques. Even if I were to learn, or perhaps especially if I were to learn Perl inside and out, it would be a problem when others came to maintain my code. And while you have me partially convinced that some of the symbols Perl uses may be of marginal use occasionally, I still think it's gone way overboard.
In all, Python's got some problems. From a practical point of view though, maintenance is the biggest problem with software, and Perl code has severe maintenance problems. So despite Python's minor weaknesses, it's still many times better than Perl for projects in the real world where more than one developer is involved.
I love the way you define as "irrelevant" the things that you just can't do.
Sorry, I just don't feel the need to write poetry in a scripting language all that often.
Where's your the C code that I can generate and you can't?
I can't parse that question. Please rephrase.
How about the way you can lose objects in Python and never call their finalizers when the program exists?
I agree that the reference counting mechanism in Python is screwy. People are working to correct that. In the meantime, it's never actually been an issue in any script I've ever seen. How about the way Perl uses dynamic scoping? That's fundamentally broken too. Are there any plans to fix it?
Anyway, below are Python conversions of the code you posted.
import sys import signal
def timeout( period, closure ):
signal.alarm(period) closure() # no need to comment, since this is obviously a function call signal.alarm(0)
class LineReader:
def __init__(self):
self.line = ''
def readLine(self):
self.line = sys.stdin.readline()
myLineReader = LineReader()
timeout( 30, myLineReader.readLine );
# now check line for proper contents print myLineReader.line
Several of the points on your list are wrong. Several others are irrelevant. What disturbs me the most is that you had to stoop to personal insults. I won't go into what that implies.
How about this: find your most readable piece of Perl code that you think can't be easily reimplemented in Python. Post it here. Nothing silly like executing chunks of Perl code allowed. It's just as hard for Perl to execute chunks of Python code.
That was an interesting rant. Too bad it was, for the most part, irrelevant.
As for the relevant parts:
You can readily tell at a glance what "part of speech" the identifier is functioning as. The $ for "this" versus the @ for "these" is a useful distinction that allows Perl programmers faster
Huh? Faster what?
These symbols permit static type-checking and logic errors in the compiler that would not otherwise be possible in so dynamic a language without severe reworking from the ground-up.
Is there a way to pass around an object that may be an array, or a string, or an associative array?
It is easy to perform string interpolation, as in "these $count cats".
It's also correspondingly difficult to determine what will happen to the contents of a quoted string.
Symbolic notation is often more convenient to work with than verbosely spelt out words that do the same thing.
True. I've said that myself many times. But what about using symbols when none should really be required? What about when the symbols actually inhibit certain things? I want to be able to pass around arrays and strings using the same variable. How does one do that in Perl?
...of which there are remarkably fewer new ones than in any other of the systems mentioned earlier in this article.
The true mark of the desperate: the need to compare apples and oranges. Cobol has far fewer "keywords" than virtually any natural language, I guess COBOL isn't so verbose after all...
Slashdot Mirror
Google caches pages. I would think that temporary caching of pages would constitute fair use. Of course, IANAL.
One could argue that software development is best done this way as well: with a very small group of developers (or even an individual) "steering" the development, and many other developers actually implementing the various bits and pieces. Software developed by committees tend to suck. Take COBOL for example. Many open source software projects, and commercial projects for that matter, have a small set of "core developers".
I think you're a bit too sensitive if you thought that was flamebait. It always bothers me when people don't consider software development to be creative or artistic. Software development is just as creative as architecture or classical music composition. Yes, there are strict rules that must be followed, but the truly creative learn to work within the rules rather than be constrained by them.
Yeah, I could just see it... Fox Mulder is abducted by aliens, who make him look completely different, and then release him. Scully eventually believes that it really is him, but refuses to believe the alien part of the story. She thinks he just got a new haircut...
Well think about it... what kind of stupid name is "USA Mulder"?
Source code isn't an artistic product?
The scariest part of that post was the 'g' flag... just how many old bodies do you have?
I think he's referring to the fact that C++ tries to hide a lot of things from you with the intention of being "easy", but it often ends up doing things you hadn't intended.
Huh? Templates and virtual functions are completely orthogonal. The performance hit with templates tends to be more related to template bloat (ie: every instantiation is yet another copy of essentially the same code). Most of the template code I've seen actually made very little use of virtual functions.
I'm not sure how you're going to reduce temporary instantiation by returning plain references. I'd like to see an example of this. Do you mean passing plain references as "out" paramaters instead of having a return value? That works, but results in harder to read code in many situations, and essentially precludes the use of operator overloading.
A lot of these performance hits can be avoided. The problem is, often the clearest way of writing the code has serious performance problems that aren't even obvious to the average C++ programmer. Typical C++ programs are filled with unnecessary temporary objects. Removing them requires that you rewrite the code to be much harder to read. For example, a set of matrix and vector classes with + and * operators is only encouraging people to use a coding style that creates lots of useless temporary objects. Yes, it's bad design. Bad language design.
That said, I still use C++ for some of my own "solo" projects. I think C++, like Perl, is too nasty to use for large projects with more than one developer though. It just makes it too easy for people to create unmaintainable, or plain stupid code.
Java works well for larger projects. Yes, it isn't quite as fast as C or C++, but modern JVM's are very fast. A lot of the places where Java is marginally slower are places where it does things like array-bounds checking. I'm quite glad that it does do this though. I'd rather my software let me know when something's broke, rather than just acting weird, or opening up security holes (think buffer overflow).
The 128 had an 8502, which was derived from the 6510, which in turn was derived from the 6502. The 6510 had bank switching as well. The Commodore 64 (which had a 6510) needed that because it had 64kB of RAM, plus some ROM. Bank switching was necessary to be able to read all of the RAM. The 8502 had more advanced bank switching apparently. And there was a 512kB expander for the 128.
The 128 was a truly weird machine. I still have mine... (with the original "q isn't a letter" ROM-bug)
It's interesting to note that the 1541 (the Commodore 64's original disk drive) had a built-in 6502 processor, and (I think) 4kb of RAM. That alone would be an upgrade from an Altair in tems of computing power, but the UI of a lone 1541 kinda sucks...
How is it different from movies or music? Or do you think it's your right to go see any movie you want for free?
Maybe you like working in tech support, but I'd rather not. I don't want to consult. I don't want to write custom hacks. I want to write code that works properly. And why would someone pay to have a custom version done, when they can just wait to have it released for free?
I'm really beginning to think that what many Open Source advocates really care about is "free as in beer", not "free as in speech".
Big-O doesn't necessarily have to do with execution time, though that's what it's typically used for. It's also frequently used for memory usage. ie: "this algorithm uses a O(n^2) buffer"
O(log n) isn't the nicest, O(1) is. O(1) is constant time. And yes, it does happen. ie: inserting at the head of a linked list is typically O(1), as opposed to inserting at the head of an array, which is O(n).
And saying "if it's O(n^2) or worse, dump the algorithm" is going too far. For sorting algorithms this may be true, but for other algorithms, O(n^2) might be very good. There are some things where there is no known efficient algorithm, where "efficient" is defined as polynomial time. So there are cases where you even have to deal with inefficient algorithms like O(n!) or O(2^n).
Also note that O-notation refers to "growth". Quicksort is O(n log n), and Linear insertion sort is O(n^2), so Quicksort wins for large datasets. Most linear insertion sort implementations will beat most quicksort implementations for very small datasets though. (and many implementations of 'qsort' will actually do something other than quicksort for very small datasets)
Oh, and there are also cases where variables other than n will come up. For instance, in text searching, one might say n is the length of the text, and m is the length of the substring. The typical brute-force string search is O(n*m). KMP (Knuth-Morris-Pratt) is O(n+m^2) I believe. If m is small, and n is very large (as is usually the case), then KMP wins. Also, the O(m*m) part can actually be done once for the substring. Each search in each body of text is then just O(n).
And to get almost back on topic, I'm working in the US on a TN Visa (that's "Temporary NAFTA"). I'm from Canada. TN's are also tied to employers, but since TN's are significantly easier to get compared to H1's, that probably isn't as much of an issue, but it is an issue.
But alternatively, RedHat can circumvent you as well. If you wrote some software that you wanted to sell, but also make open source, you'd be out of luck once it starts appearing on every RedHat Linux CD. RedHat can sell it at a lower price. They have better distribution channels. People have actually heard of RedHat, not Joe Developer. RedHat can spend more money on marketing. RedHat has tech support. They also have pretty boxes. In other words, packaging, distribution, tech support and marketing are being rewarded, while technical innovation goes unrewarded. (except for the reward of creating it, but you can't eat off that)
People always point at RedHat to say "see, Open Source works!" Sure, it works for non-developers selling other people's code. Yes, RedHat does write some code, but that doesn't contribute to their revenue. Because RedHat sells to Linux users, having developers is really a form of PR for them. A company that sold open source Windows software for end-users wouldn't need developers, since end-users don't care who wrote the software.
Using that definition, I guess there are a lot of us who have duct-tape and WD-40 fetishes...
And all of you running Linux PPC on your iMac: You've got an iMac fetish. Actually, that last bit seems pretty plausible. Running Linux on a big translucent butt-cheek...
Just because most sites do it, it doesn't mean it's a good thing to do. c|net used to have fixed table widths as well. Now they don't.
Putting fixed width tables around your pages tells me one thing: you should be working with paper, not HTML. The web is too powerful for you, and you want to artificially constrain it.
I am aware that many commercial sites use fixed table widths. That doesn't stop it from being a stupid thing to do.
Using your logic, all web sites should still be grey, because most web sites were grey initially, and "Consumer's [sic] like what they know."
Using fixed-width tables around web sites destroys their usability. You can fool yourself all you want, and make up statistics like "99.9999874 users use exactly the same browsing configuration as me", but the fact remains that anyone with a different screen resolution, font, font size, browser, windowing system and/or video card is probably going to see your page differently than you do. Trying to squeeze the page into some lowest common denominator resolution just pisses users off.
When 4096 pixel wide displays do become commonplace, what are you going to do? change your tables to say 'width=3000'? What about users with 640x480?
Leave out the constraint, and things will look good on every user's display.
I think you mean "because they think it's easier to read". My point is, of course, that this is an incorrect assumption. Do you know how big my text is? Maybe I've got a really high resolution screen.
Let's pretend I had a display that was 4096 pixels across. Because I want to be able to read text, my font is set to something that gets roughly 80 charcters per line, or an average width of 51 pixels per character. So almost 12 characters will fit in that 600 pixels. See the problem here?
Yes, you don't want more than about 70 characters per line. But restricting the number of pixels per line is not the right way to do this. You don't know how big my font is, or what the resolution of my screen is.
The right thing to do is to either use a 100% width table, or use no table at all. If I have trouble reading your lines because they're too long, I'll make my browser window narrower. Artificially restricting it to a certain number of pictures only ensures that a large portion of your users will never be able to get it to look good on their display.
If you really want 30-70 characters per row, HTML will need some way of specifying widths in em's. Unfortunately, HTML is currently too brain-dead to do sizes in anything other than percentages or pixels. Using pixel sizes is the wrong thing to do for anything other than raster images.
The thing I'd like to see in the palm is more screen space. Does the writing area really need to be static? It would be great if it was part of the display. Then for programs where you don't need text entry (or only occasionally need it) that area could be used for displaying useful info.
Also, when selecting "keyboard" it could appear in that area instead of covering the entire bloody screen. And people with external keyboards or handwriting recognition software could use the whole screen.
Colour would be nice, but a clear higher resolution screen would probably be better. I'd like colour, but I don't think I'd really need it, especially not if it makes the unit a lot more expensive, or drains the batteries a lot.
I asked it. It said "YES, definitely". So it isn't a fake...
I imagine you use Windows? And you call Linux users Lemmings? The irony...
With open source you can't differentiate your product by making it better quality, because your competitors can legally redistribute exactly the same software you do. The way you differentiate is with marketing, price, tech support and extra bonuses (eg: commercial software, manuals, penguin dolls, pretty boxes, etc.).
The Linux software market is quite different from the "normal" software market. Linux users care about open source and are less likely to buy software from a company that they don't think contributes. The average Windows or Mac user really doesn't care.
Because Red Hat sells Linux distros, it's in their best interest to have developers because that's good PR in the Linux market. If you were selling utility or application software for Windows or the Mac you wouldn't need developers. If someone starts selling an improved version of your product, you can start selling it too. As long as you have better marketing and a prettier box, you'll make more sales.
Ironically, the one thing that could possibly force you to innovate is the existence of "proprietary" software. You can't just go and redistribute proprietary software, so they'd be real competition. If all the world was open source though, competition would be reduced to marketing and packaging. Technical innovations could just be copied off the competitor's FTP servers...
Also, consider what would happen if you developed an open source application for Linux and tried to sell it. It would be almost impossible to sell, because it would probably appear on the next Red Hat CD if it's any good. No matter how much "quality" you put into it, why would people buy it from you, when they can get it from Red Hat? They've heard of Red Hat, not you.
It's also interesting to note that for support sellers, improving the quality of the product can actually be a conflict of interests. They make money on support, and lose money on development. It would be even worse if development started doing things that would reduce the amount of money made on support. This depends on the model of payments for support of course. When talking about the "free XX days support" included with a distro, then they want to reduce the amount of support required. But when talking about $XX/hour support, they'd like to increase it...
No they're not. But if you look at the article, you'll see he uses the word volunteer an awful lot.
But since you mention Red Hat, how about trying this simple mental exercise. Imagine we created graph where the X-axis is the worth of the contributions a developer has made to Red Hat 6.0, and the Y axis is the amount of money that developer has made directly as a result of those contributions. Now take all of the developers that have contributed even the tiniest fragment of code that ended up in Red Hat 6.0 and plot them on this graph. Ideally, those developers that contributed the most will have also earned the most. In actual fact, almost all of the developers will be somewhere on the X-axis, having made $0 for their contributions.
The Red Hat developers will be in the small group of points not on the X axis. They might have made some fairly significant contributions, but much less than the sum of contributions made by unpaid developers.
Red Hat makes their money from support, printed manuals and pretty boxes. If Red Hat started doing poorly, the developers would probably be among the first to lose their jobs. After-all, they don't contribute to the bottom line. (except as an expense...)
One also has to realize that Red Hat's product is not used by "normal" people. It's used by Linux users (like myself). Linux users would get ticked off at Red Hat and probably stop buying their product if RH were to fire their developers. So Red Hat has a strong incentive to keep their developers for PR reasons. Companies selling software with more non-open-source-activist users would have far less incentive to actually pay developers if they can just rely on volunteers to do the work.
I would like to see a system where all developers, whether or not they were hired by Red Hat, could earn a profit from their contributions, proportional to the worth of those contributions. Of course, that wouldn't work too well for Red Hat, because they'd have a lot more expenses than any of the other distributors. There doesn't seem to be any way to fix this and stick with the GPL.
The most disturbing thing about this is that the article goes on and on about the software being produced by volunteers. In other words, he's talking about using open source so you can get free (as in beer) labor.
Anyone with half a brain knows you can make money with Open Source. The problem is, you don't make that money by developing open source software. You make it by selling open source software other people wrote. Well duh, of course you can make money sell the work of others. Cuts downs costs quite a bit too, not having to hire developers.
When is someone going to come up with a business model where developers can actually make money on open source software? Every model I've seen so far sucks because it relies on making money off of something other than the open-source software, ie: support (support-sellers), hardware (widget frosting) or closed-source software (loss-leader). In other words, the open-source developers are either an expense or unpaid volunteers.
I wouldn't expect source level compatibility with the original Amiga IPC mechanism. Classic Amigas have no memory protection or virtual memory. Everything is in the same address space. Message passing was so quick because you could pass a single 4-byte pointer to a structure. "Hey, look at this over here!" That doesn't work in environments like Linux that have virtual memory.
Yes, a shared memory scheme could be worked up, but that would imply one of two things: Either you'd have to explicitely create the shared space (losing source compatibility), or all Amiga processes would have to execute in one giant shared address space. They'd essentially all be threads in one big mega-process. There goes your inter-application memory protection though.
They could however run all older applications in a single shared space assuming that the processor architecture will be 68k compatible (like PPC). Newer applications would probably have to use a different IPC scheme that accounts for virtual address spaces. Then your "classic" applications could still stomp on eachother, but at least they'd leave all of the newer apps alone. This could be easily extended to have multiple "classic Amiga" address spaces. Apps that need to communicate with eachother you'd have to run in the same space, otherwise they can be separate and hence protected from one another. I suppose some sort of weird "auto-merging" mechanism could even be worked out, where if one classic-Amiga process sends a message to another, the page tables of both processes are merged. That's pretty crazy though.
Then I'd kill myself for creating such a poorly designed system. But the "timeout" function I created above can also accept normal functions. As mentioned earlier, I did have a version that didn't use a separate class.
I notice you completely ignored my other points. I'll assume that means you couldn't think of any way to refute them.
I also find it amusing that you said you were going to give me the last word, but apparently couldn't resist the urge to post the above.
That depends on what you consider to be correct. I could just as easily say that it shows Perl is incapable of doing correct runtime bounds-checking. You seem to think that "however Perl does it is the right way". As I mentioned earlier, there are advantages and disadvantages to each approach. Oh, that's right, Perl is "the way, the truth, and the light". Perl's way of doing things has to be better.
Explain to me exacty what the [] operator is doing when I say '$a[2][5][3] = 9' and a is completely uninitialized. An expression tree for the left side of that assignment would be nice. I'd like to know the type and value of each node in that tree.
Incidently, I don't like Python's "two namespace" thing, nor do I care for the fact that it uses reference counting, and hence has problems cleaning up cycles. I've also got a love/hate relationship with the whole indentation versus braces thing. I think that, for a language the uses braces for blocks, Perl at least does the right thing in requiring blocks for things like if's, loops, etc (rather that just a statement like in C, C++, Java, etc.)
I also think the "%" operator in Python is pretty goofy. Writing a sprintf-like function in Python would be easy. With keyword arguments it would be even better than the real sprintf.
Python's "lambda" is also severely underpowered. (lambda only works with an expression, which means no side effects unless you call another (named) function/method, which sort of defeats to purpose of lambda in many situations)
I do think that Perl's "provide a million ways to do one thing" is a weakness though. Most Perl programmers know only a small fraction of those techniques. Even if I were to learn, or perhaps especially if I were to learn Perl inside and out, it would be a problem when others came to maintain my code. And while you have me partially convinced that some of the symbols Perl uses may be of marginal use occasionally, I still think it's gone way overboard.
In all, Python's got some problems. From a practical point of view though, maintenance is the biggest problem with software, and Perl code has severe maintenance problems. So despite Python's minor weaknesses, it's still many times better than Perl for projects in the real world where more than one developer is involved.
Sorry, I just don't feel the need to write poetry in a scripting language all that often.
I can't parse that question. Please rephrase.
I agree that the reference counting mechanism in Python is screwy. People are working to correct that. In the meantime, it's never actually been an issue in any script I've ever seen. How about the way Perl uses dynamic scoping? That's fundamentally broken too. Are there any plans to fix it?
Anyway, below are Python conversions of the code you posted.
myLineReader = LineReader()timeout( 30, myLineReader.readLine );
# now check line for proper contents
print myLineReader.line
Several of the points on your list are wrong. Several others are irrelevant. What disturbs me the most is that you had to stoop to personal insults. I won't go into what that implies.
How about this: find your most readable piece of Perl code that you think can't be easily reimplemented in Python. Post it here. Nothing silly like executing chunks of Perl code allowed. It's just as hard for Perl to execute chunks of Python code.
Remember: it has to be readable code.
As for the relevant parts:
Huh? Faster what?
Is there a way to pass around an object that may be an array, or a string, or an associative array?
It's also correspondingly difficult to determine what will happen to the contents of a quoted string.
True. I've said that myself many times. But what about using symbols when none should really be required? What about when the symbols actually inhibit certain things? I want to be able to pass around arrays and strings using the same variable. How does one do that in Perl?
The true mark of the desperate: the need to compare apples and oranges. Cobol has far fewer "keywords" than virtually any natural language, I guess COBOL isn't so verbose after all...