The amount of overtaxation in the US economy is drastic. _Any_ taxcuts are beneficial to the economy because the government is taking way too much out as a percentage of the GDP to be healthy.
Taxcuts to taxpayers. It is not the governments job to dictate the economy. It is up to them to simply provide an environment for the economy to flourish.
I have _never_ seen goto used except in rare cases by someone with a clue, so the odds of seeing it used poorly are a bit difficult, simply because when it is used so many people take notice. However, as I've tried to point out, I'm not accusing people with a clue of _intentionally_ using goto in a bad way, but _everyone_ makes mistakes, and eliminating goto for better constructs (like continuations) eliminates an entire class of mistakes. I would say that the "anti-goto" crowd has been successful in improving the structure of modern code, simply because anyone who uses gotos these days do so only when all other options have been eliminated.
There's nothing wrong with it being a library, or a dynamically linked one at that. However, it should be considered as part of the compiler and not separate. That's a small distinction, but important. C and C++ developers should make a habit of automatic GC when possible. With a common, defined way of attaching garbage collection to C code, this will enable it to be a part of the language rather than an add-on library, and hopefully encourage more people to use it.
That is the problem. Even if the programmer has a clue, there are so many ways that it can be accidentally misused that it's not even funny. EVERY language feature of any Turing-complete language A can be mapped into a Turing-complete language B. However, that does not mean language A is equivalent in usability to language B, or easily susceptible to the same class of errors. If I were to write the equivalent of s!\$\{(.*)\}!lookup($1)!eg; in a language without regular expressions, I can still do it, but a) it takes a lot longer, b) it would be _MUCH_ less clear to future programmers what I was trying to do, and c) it would be much more error-prone. Likewise is the problem with C as a language compared to more functional approaches - the lack continuations, closures, and lazy evaluation makes writing complex programs painful, and the necessity for continual variable assignment makes it begging for errors. It's not that you can't simulate closures and continuations with C, it's just that it is a very error-prone method. When you make it a language feature, you lose an entire class of errors!
Memory management _is_ tough. I think GCC should have a switch like -usegc to enable garbage collection (i.e. - statically link in Boehm). Memory management is _really_ a tough issue to do manually for any complicated program.
1) Nonlocal exits is not the same as GOTO. The paper you refer to does not advocate use of goto, it advocates the use of escape procedures. Functional Programming people are fine with this - in fact Scheme goes even further with it's call-with-current-continuation function - allowing continuations with unlimited extent - unlike your example, which has only lexical extent. The problem with Goto is that it has no structure whatsoever, and therefore is susceptible to many, many abuses.
2) Lisp is not the same as functional programming. Although it encourages a functional style, it has numerous procedural elements. Variable assignment is NOT functional programming, and Lisp is not the ultimate FP language.
"their governments continued to cut taxes" - I'm not sure what you are implying with this, but government tax revenues have gone _UP_ every time a significant tax cut has been issued, because of how much it stimulated the economy.
It's simple. I get to decide what I provide for free. If you want control over what I do, you have to pay me.
On my projects, I always try to be clear - so that people don't _have_ to ask questions. However, since it's my time, if I don't have enough time or patience to answer your question, that's my decision. If you want to pay me, I'll answer even when I don't feel like it.
Most software (including NetSaint) is easily understandable, and comes with good documentation. However, if for whatever reason, you don't understand the documentation, you can ask a question, but to get an answer for sure you pay for the time someone spends answering you.
Sometimes you can find companies who can work with you on this cycle - sure you have to do some maintenance in the downtime, but if you have 3 or 4 projects in the pipe, taking time off from 1 of them isn't always a problem.
I think the answer is to change the law on suing people. Using the corporate shield _is_ just a way to avoid moral responsibility. It also avoids stupid lawsuits, but maybe the solution is to find a way to keep those stupid lawsuits from happening, instead of finding a way to keep people from ever being sued.
What requires you to accept the EULA? There isn't really any legal requirement that I'm aware of to accept an EULA, since the transaction is already complete.
Let's pretend you bought a house with a pool. Upon entering the house, you find the pool covered with plastic saying that you didn't have a right to use it unless you agree to additional terms. What would you do? I'd rip off the plastic and use it anyway, because I bought the stupid house.
I love Python, and have recently started using it a bit. Here are my thoughts:
weaknesses:
*third-party libraries not as mature as, say, Perl's (I LOVE CPAN!)
*regular expressions not a language feature, but a library. Also, regexps differ dramatically from Python version to Python version
*scoping rules a bit awkward at first
strengths:
*Supports objects directly
*late-bound, and therefore do not need to specifically define interface classes (although they are still useful for documentation)
*supports lexical closures (how does anyone in the world code sensibly without them?) - very useful for GUI callbacks. This takes away a huge chunk of work
*Very simple
*XML libraries are very nice indeed
*excellent COM integration on Microsoft platforms (you can manipulate COM objects interactively in a Python session - very useful!)
*on Microsoft platforms, py2exe will build whole application and runtime environment into an executable and a few DLLs.
*Supports the "Generator" concept (new in Python 2.1)
*Supports bound methods (this can be done on any language supporting closures, it's just easier with direct bound-method support)
Basically, Python takes many of the excellent ideas in several languages - Lisp, Smalltalk, and Perl, and combines them into a simple, easy-to-remember language. The only difficulty I've had with python are remember it's scoping rules and dealing with regex compatibility between versions.
Actually, Visual Basic's GUI builder isn't near as nice as Borland's. The choice of language also has nothing to do with whether or not a GUI-builder comes with it. personally, I will use a GUI builder only under the following circumstances:
* I can load the GUI with whatever language it is I'm using on the rest of the project
* The GUI builder DOES NOT WRITE CODE. I will use GLADE only in libglade mode - writing property files is good, writing code is bad.
* The GUI builder actually is faster than writing it by hand
Actually CGI.pm is excellent to prevent Cross-site scripting. There's some functions that are obviously not very useful, but to be able to pass arbitrary parameters into select boxes, input fields, text, and whatever else is very, very nice.
Perl and Python are my two favorite languages. Them are fightin words....
Perl is amazing, because you can get so much done in so little time. People say it's hard to read, but it really only takes one or two readings of the camel book to be able to understand all but the toughest perl.
It has support for all stages of development, and is really useful as your project grows from procedural, to object-oriented, and even if it needs some functional aspects. A scripting language as easy-to-use as perl with lexical closures is simply amazing to build with.
In addition, it has it's own documentation system that goes beyond what Javadoc does, and allows you to really document the what's and why's of your interfaces.
COM is excellent. However, the glue framework (i.e. - the OS) completely sucks. Try printing from a service sometime, and see how dependent Windows is on having a logged-in user.
However, COM is not as good as actually having the data in a text-readable format. With COM, you can do everything the application can. With open data formats, you can do more.
I hate VS. It seems to go against all that is good in programming - i.e. - the ability to just crank out code.
Even when programming win32-only, I like just just stick with Python and wxWindows. It is so much easy just to be able to type and double-click, and not having to mess with launching bloated applications that try to do things for me, even when I want them done differently.
I think the tech market is very good right now. However, you have to look at it from the right perspective.
I'm in a tech company that has been growing over the last 3 years. The problem is knowing how to find business.
Every business wants to automate what they do. Every business wants to operate better and faster. The problem is, most tech companies know very little about how to actually do this, especially how to treat and care for customers.
Get to know the people and companies around town. Find out what their problems *actually are*. Find a way to fix them, possibly using technology. Present your solution and your price.
There are always people with problems that are willing to pay for them. What happened in the tech industry are:
a) it grew so fast, "developers" were in such demand that completely unqualified incompetents were being hired. In addition, HR had no way of distinguishing between competent and incompetent people. This is probably the biggest problem.
b) Even fewer people cared about actually serving consumer needs. Upgrading to Windows 2000 became more important than making my processes more efficient.
c) Management finally wised up and stopped doing useless things with technology. However, there is still a demand for useful technology, you just have to be able to justify it to a much smarter crowd.
d) Management refuses to go along with technology people who can't communicate.
Tech people are used to being able to just make sales based on the fact that they knew more about technology than anyone else. Now they have to be able to actually help solve problems. I see this as a good thing.
By the way, solving problems is something that can't be outsourced to third-world countries. It requires personal communication. It requires being able to see technology from the point-of-view of the business owner, and being able to speak intelligently and understandably about them and their problems, and only speak about technology when it's absolutely relevant.
I like object-oriented programming, but I think that the underlying technology of OOP should be considered at least as important if not more so - lexical closures. What drives me nuts are those OO languages without them.
Object-Oriented programming is really just a spin-off of functional programming, with some features removed and syntactic sugar for the common cases.
So, people go with what they know, even if 100 codemonkeys are hired as opposed to 50 talented people, even though the 50 talented people may save you 25% of your budget.
***
Actually, often 3 great developers can do the work of 30 codemonkeys. It really is that much of a distinction.
The problem with the advances in computing tools is that people have become dependent on the tools, and have no understanding of the underlying technology. Then, when they get stuck, they can spend weeks or months trying to figure it out, while it only took the good programmer about 30 minutes on Google, because he knew what to look for.
Slashdot Mirror
The amount of overtaxation in the US economy is drastic. _Any_ taxcuts are beneficial to the economy because the government is taking way too much out as a percentage of the GDP to be healthy.
Taxcuts to taxpayers. It is not the governments job to dictate the economy. It is up to them to simply provide an environment for the economy to flourish.
I have _never_ seen goto used except in rare cases by someone with a clue, so the odds of seeing it used poorly are a bit difficult, simply because when it is used so many people take notice. However, as I've tried to point out, I'm not accusing people with a clue of _intentionally_ using goto in a bad way, but _everyone_ makes mistakes, and eliminating goto for better constructs (like continuations) eliminates an entire class of mistakes. I would say that the "anti-goto" crowd has been successful in improving the structure of modern code, simply because anyone who uses gotos these days do so only when all other options have been eliminated.
There's nothing wrong with it being a library, or a dynamically linked one at that. However, it should be considered as part of the compiler and not separate. That's a small distinction, but important. C and C++ developers should make a habit of automatic GC when possible. With a common, defined way of attaching garbage collection to C code, this will enable it to be a part of the language rather than an add-on library, and hopefully encourage more people to use it.
" Sure it has no inherent structure"
That is the problem. Even if the programmer has a clue, there are so many ways that it can be accidentally misused that it's not even funny. EVERY language feature of any Turing-complete language A can be mapped into a Turing-complete language B. However, that does not mean language A is equivalent in usability to language B, or easily susceptible to the same class of errors. If I were to write the equivalent of s!\$\{(.*)\}!lookup($1)!eg; in a language without regular expressions, I can still do it, but a) it takes a lot longer, b) it would be _MUCH_ less clear to future programmers what I was trying to do, and c) it would be much more error-prone. Likewise is the problem with C as a language compared to more functional approaches - the lack continuations, closures, and lazy evaluation makes writing complex programs painful, and the necessity for continual variable assignment makes it begging for errors. It's not that you can't simulate closures and continuations with C, it's just that it is a very error-prone method. When you make it a language feature, you lose an entire class of errors!
Memory management _is_ tough. I think GCC should have a switch like -usegc to enable garbage collection (i.e. - statically link in Boehm). Memory management is _really_ a tough issue to do manually for any complicated program.
1) Nonlocal exits is not the same as GOTO. The paper you refer to does not advocate use of goto, it advocates the use of escape procedures. Functional Programming people are fine with this - in fact Scheme goes even further with it's call-with-current-continuation function - allowing continuations with unlimited extent - unlike your example, which has only lexical extent. The problem with Goto is that it has no structure whatsoever, and therefore is susceptible to many, many abuses.
2) Lisp is not the same as functional programming. Although it encourages a functional style, it has numerous procedural elements. Variable assignment is NOT functional programming, and Lisp is not the ultimate FP language.
Or just use a garbage collector like Boehm with it.
"their governments continued to cut taxes" - I'm not sure what you are implying with this, but government tax revenues have gone _UP_ every time a significant tax cut has been issued, because of how much it stimulated the economy.
You should check out the book I'm writing - Programming from the Ground Up - http://savannah.nongnu.org/projects/pgubook/
Good gosh, I hate Unicenter. I used it at EDS and it was absolutely terrible. I wish they would have had the sense to use NetSaint.
It's simple. I get to decide what I provide for free. If you want control over what I do, you have to pay me.
On my projects, I always try to be clear - so that people don't _have_ to ask questions. However, since it's my time, if I don't have enough time or patience to answer your question, that's my decision. If you want to pay me, I'll answer even when I don't feel like it.
Most software (including NetSaint) is easily understandable, and comes with good documentation. However, if for whatever reason, you don't understand the documentation, you can ask a question, but to get an answer for sure you pay for the time someone spends answering you.
I don't see how this is anything but reasonable.
Sometimes you can find companies who can work with you on this cycle - sure you have to do some maintenance in the downtime, but if you have 3 or 4 projects in the pipe, taking time off from 1 of them isn't always a problem.
According to AOL, what constitutes SPAM?
I think the answer is to change the law on suing people. Using the corporate shield _is_ just a way to avoid moral responsibility. It also avoids stupid lawsuits, but maybe the solution is to find a way to keep those stupid lawsuits from happening, instead of finding a way to keep people from ever being sued.
What requires you to accept the EULA? There isn't really any legal requirement that I'm aware of to accept an EULA, since the transaction is already complete.
Let's pretend you bought a house with a pool. Upon entering the house, you find the pool covered with plastic saying that you didn't have a right to use it unless you agree to additional terms. What would you do? I'd rip off the plastic and use it anyway, because I bought the stupid house.
I love Python, and have recently started using it a bit. Here are my thoughts:
weaknesses:
*third-party libraries not as mature as, say, Perl's (I LOVE CPAN!)
*regular expressions not a language feature, but a library. Also, regexps differ dramatically from Python version to Python version
*scoping rules a bit awkward at first
strengths:
*Supports objects directly
*late-bound, and therefore do not need to specifically define interface classes (although they are still useful for documentation)
*supports lexical closures (how does anyone in the world code sensibly without them?) - very useful for GUI callbacks. This takes away a huge chunk of work
*Very simple
*XML libraries are very nice indeed
*excellent COM integration on Microsoft platforms (you can manipulate COM objects interactively in a Python session - very useful!)
*on Microsoft platforms, py2exe will build whole application and runtime environment into an executable and a few DLLs.
*Supports the "Generator" concept (new in Python 2.1)
*Supports bound methods (this can be done on any language supporting closures, it's just easier with direct bound-method support)
Basically, Python takes many of the excellent ideas in several languages - Lisp, Smalltalk, and Perl, and combines them into a simple, easy-to-remember language. The only difficulty I've had with python are remember it's scoping rules and dealing with regex compatibility between versions.
Actually, Visual Basic's GUI builder isn't near as nice as Borland's. The choice of language also has nothing to do with whether or not a GUI-builder comes with it. personally, I will use a GUI builder only under the following circumstances:
* I can load the GUI with whatever language it is I'm using on the rest of the project
* The GUI builder DOES NOT WRITE CODE. I will use GLADE only in libglade mode - writing property files is good, writing code is bad.
* The GUI builder actually is faster than writing it by hand
Actually CGI.pm is excellent to prevent Cross-site scripting. There's some functions that are obviously not very useful, but to be able to pass arbitrary parameters into select boxes, input fields, text, and whatever else is very, very nice.
Perl and Python are my two favorite languages. Them are fightin words....
Perl is amazing, because you can get so much done in so little time. People say it's hard to read, but it really only takes one or two readings of the camel book to be able to understand all but the toughest perl.
It has support for all stages of development, and is really useful as your project grows from procedural, to object-oriented, and even if it needs some functional aspects. A scripting language as easy-to-use as perl with lexical closures is simply amazing to build with.
In addition, it has it's own documentation system that goes beyond what Javadoc does, and allows you to really document the what's and why's of your interfaces.
COM is excellent. However, the glue framework (i.e. - the OS) completely sucks. Try printing from a service sometime, and see how dependent Windows is on having a logged-in user.
However, COM is not as good as actually having the data in a text-readable format. With COM, you can do everything the application can. With open data formats, you can do more.
I hate VS. It seems to go against all that is good in programming - i.e. - the ability to just crank out code.
Even when programming win32-only, I like just just stick with Python and wxWindows. It is so much easy just to be able to type and double-click, and not having to mess with launching bloated applications that try to do things for me, even when I want them done differently.
I think the tech market is very good right now. However, you have to look at it from the right perspective.
I'm in a tech company that has been growing over the last 3 years. The problem is knowing how to find business.
Every business wants to automate what they do. Every business wants to operate better and faster. The problem is, most tech companies know very little about how to actually do this, especially how to treat and care for customers.
Get to know the people and companies around town. Find out what their problems *actually are*. Find a way to fix them, possibly using technology. Present your solution and your price.
There are always people with problems that are willing to pay for them. What happened in the tech industry are:
a) it grew so fast, "developers" were in such demand that completely unqualified incompetents were being hired. In addition, HR had no way of distinguishing between competent and incompetent people. This is probably the biggest problem.
b) Even fewer people cared about actually serving consumer needs. Upgrading to Windows 2000 became more important than making my processes more efficient.
c) Management finally wised up and stopped doing useless things with technology. However, there is still a demand for useful technology, you just have to be able to justify it to a much smarter crowd.
d) Management refuses to go along with technology people who can't communicate.
Tech people are used to being able to just make sales based on the fact that they knew more about technology than anyone else. Now they have to be able to actually help solve problems. I see this as a good thing.
By the way, solving problems is something that can't be outsourced to third-world countries. It requires personal communication. It requires being able to see technology from the point-of-view of the business owner, and being able to speak intelligently and understandably about them and their problems, and only speak about technology when it's absolutely relevant.
We didn't have cron permissions.
But to answer your question, no I wasn't very UNIX smart at the time.
I like object-oriented programming, but I think that the underlying technology of OOP should be considered at least as important if not more so - lexical closures. What drives me nuts are those OO languages without them.
Object-Oriented programming is really just a spin-off of functional programming, with some features removed and syntactic sugar for the common cases.
So, people go with what they know, even if 100 codemonkeys are hired as opposed to 50 talented people, even though the 50 talented people may save you 25% of your budget.
***
Actually, often 3 great developers can do the work of 30 codemonkeys. It really is that much of a distinction.
The problem with the advances in computing tools is that people have become dependent on the tools, and have no understanding of the underlying technology. Then, when they get stuck, they can spend weeks or months trying to figure it out, while it only took the good programmer about 30 minutes on Google, because he knew what to look for.