Seriously C is a great language for systems work, but writing accounting packages in C is just not the way to go.
Exactly. Implementing non-performance-critical desktop software such as this in C or C++ today is asinine--it's practically begging for failure.
Experienced developers end up chasing memory handling bugs instead of implementing features or writing documentation, and many potential developers turn away intimidated at the sight of C. Additionally, compile-time dependency hell discourages potential users.
Sadly, this project is on a course of willful time wastage; the choice of C to implement an accounting application will consign it to the dustbin of history. I've seen the same thing happen to similar open source projects, but those who design and start open source projects (as opposed to those who stick with them and finish them) persist in their irrational devotion to C/C++ for application-level programming because it's "elite".
The book starts with a chapter on building larger programs that covers @INC, eval, do and require before discussing packages and scope. It then has several chapters on references that explains in well understandable fashion and increasing complexity all the ins and outs of references including dereferencing, nested references, references to subroutines and references to anonymous data before a final chapter on references that gives you some incredibly useful tricks such as sorting and recursively defining complex data.
In other words, Perl needs a book devoted to topics that are totally straightforward in a well-designed language.
The bottom line is that if we work to simply play follow-up, we'll ALWAYS be behind, and BK will ALWAYS be seen as the superior choice.
The same claim is often make with regard to desktop Linux, but of what use is a comforting truism without the follow-through of genuine innovation and actual implementation?
If, on the other hand, we design a system that is intended to super-set BK from the word "go", then BK is the one playing follow-up...
One functional implementation is worth a thousand grandiose "designs" that are "intended to" do this or that.
I'm not attempting to refute your statement (I wouldn't try, because it's a truism), just to nudge you from heedless optimism back toward reality.
Guess you could say Red Hat is turning into a traditional Unix company.
Yeah, the filthy traditionalists have actually created a Linux-based company that's making a profit and appears likely to survive. The horror!
Re:Java is bad for our industry
on
Head First Java
·
· Score: 1
So what if that's the only language you know? If you're a good Java programmer, what's the problem?
The problem is that if you learn only one language (or one operating system, or one religion,...), you are blind to its flaws.
You warp your behavior to fit the tool, rather than choosing the most appropriate from a diverse set of tools.
Just look at the huge majority of web surfers that use Internet Explorer. Instead of exploring alternative web browsers and settling on one that prevents pop-ups from arising, they become whack-a-mole experts. This is directly analagous to programmers who only know one language, or only languages from a single family.
[[[Humans will find inventive ways to kill each other as long as the species exists. In view of that fact, why not kill precisely rather than imprecisely?]]]
[Clearly, you aren't interested in iving up to your full potential as a human being. Start pulling your weight.]
How do you know what *I* am interested in? I was making a generalized observation about human nature, not excusing myself of moral responsibility.
If my statement was paranoid, yours is incredibly naive. Can you find *any* evidence in human history to counter my pessimism, or are you just philosophically masturbating? Do you *really* believe that one day, in the words of the OP, humans will "just start being nice to each other"?
Instead of a squadron of big, lumbering, gas guzzling bombers, you need one little black jet to hit a target.
So you'd rather see several city blocks heavily damaged to destroy a target (as in WWII) than two or three bombs taking out a single building? Yeah, the good old days.
Kill more, spend less.
In the example you cited (though certainly not in all weapon-oriented technologies), kill more, spend less is a blatant misrepresentation of motive. It's actually about killing less, spending less.
What will ever happen to human progress if we start all being nice to each other?
It's not going to happen. Humans will find inventive ways to kill each other as long as the species exists. In view of that fact, why not kill precisely rather than imprecisely?
>> The re module does have a sub() function, but >> that's fairly well documented. > > Yeah, but the bit of docs I quoted are from the > re.sub() documentation! Like I said, really > annoying when it references you to something > that doesn't appear to exist.
No, you quoted the docs for the sub() *method* of compiled *regular expression objects* (which are implemented in the underlying C module _sre; returned from the re.compile function).
Look at the docs for the sub() *function* of the re *module*, and you'll find what you want. You can access it online right here: http://www.python.org/doc/current/lib/node9 9.html#l2h-732
<<<At this early stage, about the only thing I'm finding a little confusing is how variables are handled. This is neither good or bad at this point, just that there's enough concepts I hadn't really dealt with before that there's a learning curve I haven't yet gotten through. From what I can tell, there's an odd mix of C++ style variables that act more like pointers than the scalars that I'm used to working with in PHP.>>>
Python doesn't have variables in the traditional sense, only references to objects. x = 1 causes x to refer to the immutable integer object 1, while x += 2 would then create an immutable integer object with value 3 and cause x to refer the new object. This is unlike C-style languages in that in C, x would be an integer-sized slot into which we're pushing different values; in Python, x is just a name that is subsequently used as a label for various integer objects.
However, because the objects in the example above are immutable, it's easy to mistake x for a C-style "value slot" rather than a "reference". In Python, the code x = 1 y = x x += 2 will not change y to 3, because y initially refers to the immutable integer object 1, as does x.
x += 2 does not change the object that y refers to (which is 1) into 3, it just causes x to refer to a different object (the immutable integer object 3).
Contrast the discussion of immutable objects above with the following code, which works with a mutable object: x = [1,2] y = x x.append(3)
In this case, the first statement creates a list (a *mutable* sequence) containing 1 and 2, then labels the new object with the name 'x'. The second line applies another label ('y') to the same mutable sequence object.
Since lists are *mutable*, they can be changed. The third statement changes the single mutable sequence object that both x and y refer to, so both references reflect the change. However, if the third statement had been x = [10,11] , then it would not have changed the object that y refers to; instead, it would have created a new object and applied the label 'x' to it.
Think of it this way: If I have a domestic building that I refer to as 'my house' and you live in *the same building* with me, but you refer to it as 'mi casa', then 'my house' is affected if you burn the building that you call 'mi casa', because we're just applying different labels to the same object.
If you build a new house for yourself and begin to refer to the new house as 'mi casa', then 'my house' (the house in which we previously lived together) would not be affected if you burned 'mi casa'.
[Visual Basic] can be programmed as a "functional language"...
Whatever else Visual Basic may be, it is most certainly not a functional language. The difference between functional and procedural is vast, and worth learning.
I used to do quite a bit of (commercial) Visual Basic programming, and while I agree that the IDE is almost incomparably easy to use, I came to hate the language with a passion when I tried to write medium-sized programs (10,000 lines and up) in it.
Personally, I think this is one of the things holding back development by businesses on Linux (esp on the desktop) - the lack of such a tool.
I think you're right on the money with this statement.
The closest I have seen has been Python with some windowing toolkit (to interface with X) tacked on, plus a gui designer to create the fancy forms - but none of this is as integrated as VB's IDE is, and while Python is a nice looking language (I can't really tell how good it is at things - I have never used it - currently playing and learning about Perl and PHP), it isn't BASIC.
Python eventually beat out Visual Basic, C, Java, Perl, Ruby, Erlang, and Lisp (all of which I tried) to become my primary development language. I'm quite satisfied; for me, Python delivers unparalleled productivity. But I'm no zealot. If I find something better, I'll switch, but none of the listed languages was more productive, in my experience. Most weren't even close (only Lisp and Ruby).
However, I'm doing primarily server-side development of various sorts, rather than GUI programming. When it comes to building GUIs, the Python IDEs I've tried pale in comparison to Visual Basic's IDE. C, Perl, Ruby, and to a lesser extent Java also suffer from poor GUI-building-IDEs, though (and virtually no one tries to write GUIs in Erlang or Lisp).
I have never understood why there is such derision regarding BASIC - because that is the problem, it seems.
Try writing some large programs in it and see how it holds up. In my experience, very poorly.
I eventually chose the tcl/tk option, because of the following reasons:
* 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
But this applies as much to Tcl as to Python, right?
FWIW, Python has both bare bones and CGI-capable HTTP servers right in the standard library (the BaseHTTPServer, SimpleHTTPServer, and CGIHTTPServer modules). I find these easy to use.
* 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
wxPython itself lacks extensive documentation, but the documentation for the C++ API is great. The Python API matches the C++ API so closely that I don't have any trouble applying the C++ docs to Python. After all, both C++ and Python are quite suitable for manipulating object-oriented toolkits.
The included example programs are quite extensive. If you accept my assertion that the documentation for wxPython is not lacking where it counts, the ready availability of demo programs won't hurt anything, eh?
* 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.
Python is also well-tested, and the documentation is (IMO) excellent. Python is somewhat less portable than Tcl. While its Windows, Unix, and Mac support is fine, ports to mainframe operating systems and such are not available (or are no longer maintained).
Except for the portability aspect, I don't find your logic convincing. But hey, use what you like. Viva la open source.
I can guess you come from the Sybase world. Come over to Oracle, my friend. Writers do not block readers, readers do not block writers, locks never escalate and deadlocks are automatically detected and resolved.
While that's sound advice, it's not necessarily viable because of Oracle's high price. Note that the open source databases PostgreSQL and Firebird also implement multi-version concurrency control. Of course, Oracle easily outstrips them for overall feature set, but the point is: MVCC is available in much cheaper (free) RDMBSes than Oracle.
I guess you haven't heard today's anouncement from greenspan... economy is recovering. Job markets are expected to reopen soon.
I heard these same announcements in early 2002. Guess what? Greenspan has a vested interest in leading people to believe that the economy is doing better than it really is.
BTW, 10 million unemployed is still much better than the double-digit percentage of unemployment plaguing various European countries these days.
Except that the European unemployed actually have access to medical care, counseling, etc. That's a big, big difference.
Re:So let me get this straight...
on
SCO SCO SCO!
·
· Score: 1
Is the secret code surrounded by super-double-secret code ?
Yes, in fact, it is. You just have to know the language!
SAP no doubt wants a piece of the enterprise DB pie...
They've been at pains to claim otherwise. According to material on the SAPDB web site, they *are not* interested in selling a relational database system. Rather, they want an enterprise-class, royalty-free database they can use as the basis for their core apps.
SAPDB is trying to popularize its main applications (ERP, CRM) in smaller businesses than those in which they have traditionally been popular. Microsoft is just now entering this same space; SAP will never be able to compete with Microsoft in the small(ish) business market if the price of SAP's software must include an expensive relational database license.
A significant motivation for the Open Source initiative is the price structure for database
licenses. This affects not only SAP, but every provider of database-based solutions that must
procure database licenses in order to sell them on as part of their own solution, therefore
imposing costs on the end licensee. SAP AG hopes to enliven the market through the Open
Source initiative and to encourage users to critically examine the high-price policies of the
market-leading database providers.
Slashdot Mirror
Seriously C is a great language for systems work, but writing accounting packages in C is just not the way to go.
Exactly. Implementing non-performance-critical desktop software such as this in C or C++ today is asinine--it's practically begging for failure.
Experienced developers end up chasing memory handling bugs instead of implementing features or writing documentation, and many potential developers turn away intimidated at the sight of C. Additionally, compile-time dependency hell discourages potential users.
Sadly, this project is on a course of willful time wastage; the choice of C to implement an accounting application will consign it to the dustbin of history. I've seen the same thing happen to similar open source projects, but those who design and start open source projects (as opposed to those who stick with them and finish them) persist in their irrational devotion to C/C++ for application-level programming because it's "elite".
The book starts with a chapter on building larger programs that covers @INC, eval, do and require before discussing packages and scope. It then has several chapters on references that explains in well understandable fashion and increasing complexity all the ins and outs of references including dereferencing, nested references, references to subroutines and references to anonymous data before a final chapter on references that gives you some incredibly useful tricks such as sorting and recursively defining complex data.
In other words, Perl needs a book devoted to topics that are totally straightforward in a well-designed language.
I don't know, it's working splendidly for 3D Realms.
The bottom line is that if we work to simply play follow-up, we'll ALWAYS be behind, and BK will ALWAYS be seen as the superior choice.
The same claim is often make with regard to desktop Linux, but of what use is a comforting truism without the follow-through of genuine innovation and actual implementation?
If, on the other hand, we design a system that is intended to super-set BK from the word "go", then BK is the one playing follow-up...
One functional implementation is worth a thousand grandiose "designs" that are "intended to" do this or that.
I'm not attempting to refute your statement (I wouldn't try, because it's a truism), just to nudge you from heedless optimism back toward reality.
Guess you could say Red Hat is turning into a traditional Unix company.
Yeah, the filthy traditionalists have actually created a Linux-based company that's making a profit and appears likely to survive. The horror!
So what if that's the only language you know? If you're a good Java programmer, what's the problem?
The problem is that if you learn only one language (or one operating system, or one religion, ...), you are blind to its flaws.
You warp your behavior to fit the tool, rather than choosing the most appropriate from a diverse set of tools.
Just look at the huge majority of web surfers that use Internet Explorer. Instead of exploring alternative web browsers and settling on one that prevents pop-ups from arising, they become whack-a-mole experts. This is directly analagous to programmers who only know one language, or only languages from a single family.
[[[Humans will find inventive ways to kill each other as long as the species exists. In view of that fact, why not kill precisely rather than imprecisely?]]]
[Clearly, you aren't interested in iving up to your full potential as a human being. Start pulling your weight.]
How do you know what *I* am interested in? I was making a generalized observation about human nature, not excusing myself of moral responsibility.
If my statement was paranoid, yours is incredibly naive. Can you find *any* evidence in human history to counter my pessimism, or are you just philosophically masturbating? Do you *really* believe that one day, in the words of the OP, humans will "just start being nice to each other"?
Jan 7, 2009: CowboyNeal inauguration ceremony.
Instead of a squadron of big, lumbering, gas guzzling bombers, you need one little black jet to hit a target.
So you'd rather see several city blocks heavily damaged to destroy a target (as in WWII) than two or three bombs taking out a single building? Yeah, the good old days.
Kill more, spend less.
In the example you cited (though certainly not in all weapon-oriented technologies), kill more, spend less is a blatant misrepresentation of motive. It's actually about killing less, spending less.
What will ever happen to human progress if we start all being nice to each other?
It's not going to happen. Humans will find inventive ways to kill each other as long as the species exists. In view of that fact, why not kill precisely rather than imprecisely?
>> The re module does have a sub() function, but
9 9.html#l2h-732
>> that's fairly well documented.
>
> Yeah, but the bit of docs I quoted are from the
> re.sub() documentation! Like I said, really
> annoying when it references you to something
> that doesn't appear to exist.
No, you quoted the docs for the sub() *method* of compiled *regular expression objects* (which are implemented in the underlying C module _sre; returned from the re.compile function).
Look at the docs for the sub() *function* of the re *module*, and you'll find what you want. You can access it online right here:
http://www.python.org/doc/current/lib/node
/* I rypped this koad of from SCOA: */
...
Also, Zope is not licensed under the GPL, but rather, a GPL-compatible license called the Zope Public License.
<<<At this early stage, about the only thing I'm finding a little confusing is how variables are handled. This is neither good or bad at this point, just that there's enough concepts I hadn't really dealt with before that there's a learning curve I haven't yet gotten through. From what I can tell, there's an odd mix of C++ style variables that act more like pointers than the scalars that I'm used to working with in PHP.>>>
Python doesn't have variables in the traditional sense, only references to objects.
x = 1
causes x to refer to the immutable integer object 1, while
x += 2
would then create an immutable integer object with value 3 and cause x to refer the new object. This is unlike C-style languages in that in C, x would be an integer-sized slot into which we're pushing different values; in Python, x is just a name that is subsequently used as a label for various integer objects.
However, because the objects in the example above are immutable, it's easy to mistake x for a C-style "value slot" rather than a "reference". In Python, the code
x = 1
y = x
x += 2
will not change y to 3, because y initially refers to the immutable integer object 1, as does x.
x += 2 does not change the object that y refers to (which is 1) into 3, it just causes x to refer to a different object (the immutable integer object 3).
Contrast the discussion of immutable objects above with the following code, which works with a mutable object:
x = [1,2]
y = x
x.append(3)
In this case, the first statement creates a list (a *mutable* sequence) containing 1 and 2, then labels the new object with the name 'x'. The second line applies another label ('y') to the same mutable sequence object.
Since lists are *mutable*, they can be changed. The third statement changes the single mutable sequence object that both x and y refer to, so both references reflect the change. However, if the third statement had been
x = [10,11]
, then it would not have changed the object that y refers to; instead, it would have created a new object and applied the label 'x' to it.
Think of it this way: If I have a domestic building that I refer to as 'my house' and you live in *the same building* with me, but you refer to it as 'mi casa', then 'my house' is affected if you burn the building that you call 'mi casa', because we're just applying different labels to the same object.
If you build a new house for yourself and begin to refer to the new house as 'mi casa', then 'my house' (the house in which we previously lived together) would not be affected if you burned 'mi casa'.
[Visual Basic] can be programmed as a "functional language"...
Whatever else Visual Basic may be, it is most certainly not a functional language. The difference between functional and procedural is vast, and worth learning.
I used to do quite a bit of (commercial) Visual Basic programming, and while I agree that the IDE is almost incomparably easy to use, I came to hate the language with a passion when I tried to write medium-sized programs (10,000 lines and up) in it.
Personally, I think this is one of the things holding back development by businesses on Linux (esp on the desktop) - the lack of such a tool.
I think you're right on the money with this statement.
The closest I have seen has been Python with some windowing toolkit (to interface with X) tacked on, plus a gui designer to create the fancy forms - but none of this is as integrated as VB's IDE is, and while Python is a nice looking language (I can't really tell how good it is at things - I have never used it - currently playing and learning about Perl and PHP), it isn't BASIC.
Python eventually beat out Visual Basic, C, Java, Perl, Ruby, Erlang, and Lisp (all of which I tried) to become my primary development language. I'm quite satisfied; for me, Python delivers unparalleled productivity. But I'm no zealot. If I find something better, I'll switch, but none of the listed languages was more productive, in my experience. Most weren't even close (only Lisp and Ruby).
However, I'm doing primarily server-side development of various sorts, rather than GUI programming. When it comes to building GUIs, the Python IDEs I've tried pale in comparison to Visual Basic's IDE. C, Perl, Ruby, and to a lesser extent Java also suffer from poor GUI-building-IDEs, though (and virtually no one tries to write GUIs in Erlang or Lisp).
I have never understood why there is such derision regarding BASIC - because that is the problem, it seems.
Try writing some large programs in it and see how it holds up. In my experience, very poorly.
I eventually chose the tcl/tk option, because of the following reasons:
* 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
But this applies as much to Tcl as to Python, right?
FWIW, Python has both bare bones and CGI-capable HTTP servers right in the standard library (the BaseHTTPServer, SimpleHTTPServer, and CGIHTTPServer modules). I find these easy to use.
* 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
wxPython itself lacks extensive documentation, but the documentation for the C++ API is great. The Python API matches the C++ API so closely that I don't have any trouble applying the C++ docs to Python. After all, both C++ and Python are quite suitable for manipulating object-oriented toolkits.
The included example programs are quite extensive. If you accept my assertion that the documentation for wxPython is not lacking where it counts, the ready availability of demo programs won't hurt anything, eh?
* 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.
Python is also well-tested, and the documentation is (IMO) excellent. Python is somewhat less portable than Tcl. While its Windows, Unix, and Mac support is fine, ports to mainframe operating systems and such are not available (or are no longer maintained).
Except for the portability aspect, I don't find your logic convincing. But hey, use what you like. Viva la open source.
By God when I was kid they hadn't discovered colors yet--our monitors were nothing but dynamic braille plates with a 1e-010 refresh rate.
I can guess you come from the Sybase world. Come over to Oracle, my friend. Writers do not block readers, readers do not block writers, locks never escalate and deadlocks are automatically detected and resolved.
While that's sound advice, it's not necessarily viable because of Oracle's high price. Note that the open source databases PostgreSQL and Firebird also implement multi-version concurrency control. Of course, Oracle easily outstrips them for overall feature set, but the point is: MVCC is available in much cheaper (free) RDMBSes than Oracle.
What about the CPU cost per hit of a high traffic (1Mhit/day or more) CGI-based applicatoin?
Who the fuck bases a 1Mhit/day site on CGI?
A linux for school distro was just relaesed here in Québec... it's based on mandrake 9.1 and add some better local french support...
You mean French-speaking people attend school? All this time, I thought they sprang fully educated from the womb.
I guess you haven't heard today's anouncement from greenspan... economy is recovering. Job markets are expected to reopen soon.
I heard these same announcements in early 2002. Guess what? Greenspan has a vested interest in leading people to believe that the economy is doing better than it really is.
BTW, 10 million unemployed is still much better than the double-digit percentage of unemployment plaguing various European countries these days.
Except that the European unemployed actually have access to medical care, counseling, etc. That's a big, big difference.
Is the secret code surrounded by super-double-secret code ?
Yes, in fact, it is. You just have to know the language!
At the dysfunctional corp where I worked in 2000, the lead developer was running a Pentium 166.
Yes, let me repeat: lead developer->Pentium 166->year 2000.
Imagine the lost productivity! This was a large corporation, too, not some hole in the wall. Now it's a large, bankrupt corporation.
more of the same lip service from our friends at Redmond. is this the 3rd, or 4th 'security' initiative?
Oh, but this one's different--they're hiring 3D Realms to implement it.
SAP no doubt wants a piece of the enterprise DB pie...
They've been at pains to claim otherwise. According to material on the SAPDB web site, they *are not* interested in selling a relational database system. Rather, they want an enterprise-class, royalty-free database they can use as the basis for their core apps.
SAPDB is trying to popularize its main applications (ERP, CRM) in smaller businesses than those in which they have traditionally been popular. Microsoft is just now entering this same space; SAP will never be able to compete with Microsoft in the small(ish) business market if the price of SAP's software must include an expensive relational database license.
Here's a quote from the whitepaper.
msSQL [sic] could gain quite a bit of big-time features from SAP's DB (real tansactions, ACID compliance, etc.)
This is a severe oversimplification. Have you ever written a large program?
SAPDB's code base is a mixture of C++ and Pascal, started circa 1980 and quite crufty.
So how is MySQL just going to "gain" these features? Internally, their architectures are quite different; merging the two is anything but a sure bet.