Those numbers "about half of all software engineers have a degree" [wikipedia]. "Nearly half of the software developers in the United States do not have a college degree. Many never even graduated from high school" I haven't been able to find a single study that confirms those statements, and it isn't corroborated by my own experience. Even if they were real, what would they even mean?
If all people who write programs of all type are included, the number may have some validity, but in my team which builds software that runs an advertising network 6 of the 8 software enigneers have a degree. The two outliers are a developer with twenty years experience building software, and a senior graphic designer who is holding an internship level software engineering position because the company wanted to support his desire to change careers. Across the engineering department, a hand full of engineers have degrees which aren't computer science, but very few of them have no degree at all.
Building software is a lot like other skills, skill sets vary. You don't hire a detailer who you pay $20/hr to wash cars to paint a car if you want car-show quality results; you hire an auto-body expert and pay him $100/hr. Similarly, you might hire any old contractor to build a garage, but you don't hire any old contractor to build you a thirty story building — you hire a real architect, and a real engineer. On the same note, you can't hire someone who just "can program" to build a system that runs a business of much scale.
The device was virtually unusuable due to the sheer volume of bugs in the touch-screen interface. I've had one, for almost a year, and it's now quite reasonable (a dozen firmware updates later) but at first, I had such problems as not being able to select an email or phone number if it was not on the first page-full of a list, because when I did, I would get the item that used to be at those coordinates when I was on the first page full.
And developers using file access APIs in Windows can get case sensitive behavior. It's just a single FILE_FLAG_POSIX_SEMANTICS flag to CreateFile and friends. It's actually easier to do that in Windows because it doesn't require a reformat and reinstall.
Only on slashdot would anyone take this kind of time, to talk in this level of detail about the windows API regarding case sensitive file names in a thread of commentary which had nothing at all to do with what you are talking about. The shame in/. is to tap into the wealth of knowledge that's is it's reader base, you apparently have to float around and make baseless trollish remarks and you will get in response a wealth of information, no matter how tangential.
VIM renders text-area as a grid. This is compatible with column-area selection, and other features it supports which frankly I use nearly daily. While I've honestly considered using proportional fonts — I've tried living without VIM, switching to Eclipse or IDEA for several months at a time to give the IDE experience a full opportunity. Doesn't work for me, so neither will proportional fonts.
Besides there seem to be more reasons not to use proportional fonts than to use them:
Lot's of people align assignments, this will look terrible.
Several formatting techniques (newline before curly bracket) depend on the width of whitespace.
Occasionally code contains tabular data which is easily formatted for digestibility using fixed-width fonts.
Occasionally, although rarely, comments may contain diagrams or ascii-art figures which would be rendered useless with proportional font.
Reasons to use them:
You might be able to read the contents of your code up to 14% faster, if you don't run into the issues above...
Are you guys crazy? Microsoft has "troubles"? Microsoft is laying off 5000 people...out of 91,000. That's 5.5%, relatively light for this economy. Sony is laying off 16,000 of 185,800 people leaving it's slashes at 8.6% (incase your arithmetic isn't up to it, that's 63% more people relative to the size of the company). The company I work for (I won't mention the name) last year cut a total of 139 of 800 people including three senior executives, registering at 17.3%. Now that's a troubled company. Microsoft is running very strong. Their profit margins remain in the 20s despite the hardening economic times they continue to run without an annual net operating loss and maintain an enormous cash position. Microsoft is in no way "troubled". They're being very conservative about even being prudent, given the state of the economy. They could probably afford to -- and might benefit their shareholders if they did -- live without double the number of people they are cutting.
OOP is not one tool too many, it's just a tool that's used inappropriately all too often.
Object Oriented Programming *can* lead to incredibly elegant application designs, high separation of concerns, easy feature-scalability and very flexible and agile code.
The problem typically is, that programmers focus on the wrong things when building an object oriented application. They worry about things like how to use inheritance, which is probably the most over-valued feature of OOP. They create objects which are large, upside-down in structure (utility base classes!?) and couple data and functionality arbitrarily (making data objects have functionality that is not intrinsically exclusive to that data, is a common error in OOP).
Java programs can be elegant. But usually, they aren't. The fault is not the language, or OOP. The error is the operator.
The single greatest attribute to good software is that the group or individual responsible for it both really wanted to write the software, and really wanted it to work well. This is typically attributed, not to much of a surprise, by the ego of the individual or collective ego of the group responsible.
The things that makes software good, in my opinion, is having created a program that performs a collection of tasks which solve the problem for which the program was intended, and doing it without unexpected errors and within the parameters of it's environment. This means web software that scales to load, desktop software which doesn't -- but scales to features, and software that in general...works. No stack traces (except in a log, maybe) and no null pointer exceptions, and naturally no segfaults.
One thing java programmers should learn is to treat NPEs like they are segfaults -- because, if this wasn't java, they would be.
All of the best programs, never mind how horrendously ugly their code might be, must be tested thoroughly...this typically requires support from developers to accomplish effectively. That being said, the best programs that most programmers will ever write, are the programs that they themselves will *use every day*. They thoroughly use it, and use it regularly. This tends to lead to a lot of really good QA. Unless they are lazy.
There was some item above I was replying to when I decided to make a larger post...here's the item I was responding it:
It should read only : map(lambda x: int(x.strip), input.split(","))
But this is easier than you think in java, or perl, or any other language that has regular expressions.
List results = new ArrayList (); Matcher matcher = Pattern.compile("([^,]+)").matcher(args[0]); while (matcher.find()) results.add(Integer.parseInt(matcher.group(1).trim()));
Granted, the java version is 3 times the amount of code than the most expressive python version. But it's still not a lot of code, in fact, it's quite concise. And it's a lot more optimizable -- and more strict.
But both of these examples suck, really. Because if you're looking for numbers -- your regular expression should match numbers, and not just try to blindly parse the data as an integer.
And here's the part that really matters
Anyway, I think ruby, python and friends are growing in popularity not because they increase productivity, but because people suck. After all, those ruby folks who hate java also hate XML, and XML is nothing more than a collection of super fantastic technologies built ontop of a common document format where a single parser and parsing framework can be used to represent a myriad of types of data -- how cool is that?
And like any tool, it's only as good as it's user, which precludes that the user using the tool must be using the right tool for the right job, which all too often is not the case regardless of the language. I think the entire world of software engineering would benefit from forgetting about the related philosophical wars related to programming languages, tools, and frameworks and just learn how to use as many of them as possible. Learn as much about them all as possible. And start trying to chose your language, framework, and libraries based on how they solve the particular problem each and every application faces -- which is always specific to the application and it's purpose.
If we chose tools using this pragmatic approach, rather than buying into any given framework, language or library regardless of the problem we would actually have a better cognative ability as an over-all community to be more productive in developing tools, languages and frameworks that meet the needs of specific problems and do that well, and would thus increase our over-all effectiveness as an entire industry.
I appreciate your effort(s) to improve the quality of code in general. It's a noble goal I've spent my entire career trying do, including mentoring co-workers and junior level engineers as well as writing papers, and a lot of preaching and ranting...
But part of the problem I saw when I read your article is that your suggestions really aren't that good. Take for instance your example of "good" comments:
// This procedure moves the bullet upwards. It's called //NUM_BULLET_MOVES_PER_SECOND times per second. It returns TRUE if the //bullet is to be erased (because it hit a target or the top of the screen) and FALSE //otherwise.
That comment is actually documentation, and if you are going to document in comments (not *entirely* a bad idea) then you should be actually using a type of comment designed to be picked up by some documentation system, such as autodoc.
Describing what your code does is the job of documentation, describing why your code does what it does the WAY it does is the job of comments.
Boolean player_bullet::move_it()/* <- move_it is kind of a crummy name */ {
Boolean is_destroyed = FALSE;
// Calculate the bullet's new position.
An example of just saying what you're doing instead of why you're doing what you're doing.
[Small chunk of code.]
// See if an enemy is in the new position. If so, call enemy destruction call and // set is_destroyed to TRUE
[small chunk of code]
// See if bullet hits top of screen. If so, set is_destroyed to TRUE
[Small chunk of code.]
// Change bullet's position.
Why do we need to say that this changes the bullets position? Shouldn't the code probably look like, bullet.setX(x); bullet.setY(y); or some variation thereof and a redraw? Wouldn't that indicate that the code is moving the bullet? Do we really need a comment to say this?
[Small chunk of code.]
Return is_destroyed; }
In retrospect, a good time to use a comment is when you deviate from anything a future onlooker would be expecting from your method, function or subroutine. For instance, where you would do something specifically because of another bug that or behavior that is out of your control.
/* We cannot add the events immediately or they simply will
* fail to work. Event's on un-rendered nodes are
* optimized away. But these nodes will be rendered when
* this operation is finished, so a single cycle delay will
* make sure we let this thing render before attaching
* events.
*/ window.setTimeout( function () {
self.populate(child) }, 0 )
A smart person doesn't need to remind himself what code X does, unless it's not obvious.
this.y = y this.x = x
...That's pretty obvious
In the section where you suggest using define a lot, I honestly consider that a particularly bad idea. Using global constants is just in general a bad practice. A good practice, on the other hand, is having all arbitrary static data be a matter of configuration. That is, instead of defining NUM_ALIENS_TO_KILL_TO_END_WAVE as a compile time constant, or any other form of literal, define it in a configuration file so it can easily be modified without a code change.
Enabling behavioral changes without code changes is critical to software success. Every time you change code, you rebuild and redeploy things. And this provides the potential for other
I switched because of my interest as a developer. Even in the MSDOS world most of the code I played with in my early days was in the public domain. When a found a plethora of powerful development tools and a free way to follow the unix way of things, the choice was obvious.
The reason I never switched back is more important, I think. I've found windows interface to be cumbersome, and I find features common to X11 desktop environments to be things I can't live with out...Features, such as multiple work spaces, window shadowing, window grouping, and auto-configuration (pekwm !) and placement of windows I struggle with not having access to in Windows. As well as that fancy global copy on select clipboard.
In addition to my actual use of the environment itself, which is almost emulatable in windows these days (but not really to my satisfaction) I have found programming in windows (as well as more often than not just with priorietary software that never gets good code review) to be increadibly painful. The API's are nonsensical, cumbersome, and downright ugly even for the most basic of operations. The.CreateTextFile method still haunts me to this day.
These are just the surface reasons, for a developer such as myself, to not only make the switch but buy in whole heartedly. I'm not even going to get into the fact that when they made me start running Windows 2003 Server on my dev workstation at work I started spending a lot of time dealing with issues such as my desktop crashing, my second display failing to function at random, and so outlook siezing up at random.
This is very becoming of microsoft software. Their page, although having an identical layout, and an extra feature (column control) is clunkier, non-standard compliant (? xmlns:msn...a namespace without a URI?), and simply doesn't really work as well as google's nice streamlined page, although I have to admit...google's page isn't to standard friendly either ( is not approved by the W3C, and element's require a type attribute!).
The point is, I pick google's, because when I click on something and drag it, I get smooth behavior, rather thank chocking, choppy wierdness.
But it wont surprise me if 90% of people don't agree with me or don't find googles page and find microsofts first, since that is typically what happens.
It's complete malarkey that testing is only a priority on a closed source application. In fact, the beauty of open source is that many of the lower level products of open source (libraries) are fundemental elements of much larger commercial products. Regression testing at the library level is a very common practice, and some development communities (I'm sure you all dislike perl, it's not my favorite language but this is my favorite example) like CPAN even force atleast some tests to be in place before a library can be distributed through that system.
In many of the large sucessful projects I see test cases are a huge part of the development. Look at mozilla's tinderbox system, it automates lots of tests before patches are even accepted into the development branch. This is after a patch has been either created by or reviewed by one of the core developers.
Open source is not some wild west land where anyone can go around adding any code to any project they want...well I mean they can, but it won't effect the distribution. Distributions are still controlled by the author of the project, and anyone else the author decides to delegate the responsibilities (aka privileges) to.
When I'm building a proprietary application, I often end up building it out of a number of generalized solutions which I abstractify into libraries with carefully thought out APIs in order to promote reuse and flexibility. I do this so that not only I can use them with other applications, but so with some careful evangelizing with my customer(s) I can convince them it is in their best interest to allow these generic elements of the application to be distributed in the public domain.
One thing people keep missing about open source is that it's a developer's method of doing things. It doesn't mean we can't create great user desktop software, but it does mean that open source isn't an approach to replacing vendors who develop and support software. It can be a model for sharing all generic parts of an application to give it good code review, increase its stability, and for developers to collaboriate indirectly on a very large scale.
I think OS-X is a great example of this at work, Cocoa being *just* as proprietary as windows, but the actual underlying system is just as open source as linux. Obviously Apple's developers know how to build a great user interface and have the infrastructure necessary for enterprise quality support, where the open source community has the ability to build flexible, powerful, innovative solutions that could not take shape without having thousands of prying eyes on the source code. The result is a solution that's easier to use, harder to break, more flexible and more powerful than anything that could ever come out of Redmond.
Now if only we could get Apple to quit being selfish and make the daring move to becoming an OS Vendor as well as a computer manufacturer, maybe there could be a viable desktop software solution for the average person who thinks of a computer as an appliance. From what I've seen, Microsoft's software is far to easy to break for these kind of people, and the literally computer illiterate stuggle with it horribly. And speaking from experience, developers used to more sophisticated ways of doing things (such as by following standards and whatnot) find MS software hard to work with.
If the mozilla project's standard compliant SVG rendering is deployed into the market first, the "next" IE (Whenever that is - how many years has it been since an IE release?) will undoubtably need to support SVG markup standards and thus won't be an issue.
From what I've been gathering, it really seems Microsoft's project of making IE the #1 browser is greatly slipping. I've heard rumours of a GRE Compatible XUL markup being supported, as well as rumors of aliasing all of the ActiveX component API's with XPCOM compatible APIs giving access to all of the ActiveX controls we need through the nsI interfaces. [ e.g. new ActiveXObject("MSXML2.XMLHTTP") becomes new XMLHttpRequest(), and so on ]
All of this makes me think that MS's attempts at slightly breaking all standards and trying to push forth as the lead-dog in the "world wide web", are mostly dead.
At the same time, I'm mostly praying they are because I'm really tired of dealing with it:-)
Oh great, so you mean PHP5 finally borrowed the method resolution behavior of Perl 5?
Fancy that!
There are a number of other languages which allow you to dereference return values and call member functions on them. One of them is (surprise surprise) ECMA, Also known as Java Script. Another one I fancy is Pike.
PHP5 Still hosts a large number of the PHP4 Flaws. And additionally, bench marks show that it is still very damn slow. Not to mention the scope behavior of PHP5 is hardly more advanced than that of awk. C'mon now.
Gnumeric, is a nice quality GTK spreadsheet application, and it does write and read Microsoft Excel 95 formats. Which albiet isn't an office XP format but surely the office XP suite is backward compatable. Thats always been one of MS's biggest issues, I mean, yeah;)
We've all seen how MS's buisness and development plans work, and we dont need them pinching into the *nix market. After all MS Office is not even very good (In ways of eficiency atleast) and the only reason its popular is because its become an industry standard out of sheer marketing. What we do need though, in my opinion, is for more of our local speedy, quality applications to support MS office formats. (Abiword writing ms.docs would be a good deal, and KOffice would be good too). I think we could do more with opensource applications that we build to cover these formats. I know the.doc format is not very good, I'm sure abiword's document format as well as many others are superior for thier own reasons. But this doesn't help us at all when it comes to penitrating the office market.
In my mind and experiances the opensource community's goal as of late has been to build a quality stable and fast workstation enviroment. After all we already have, have had and will continue to have the best of the server market. Apache, thttpd, php, mysql, all by far outperform IIS, Asp and Access for a server application in resource handling, efficency and stability, and I would even venture as far as to say that opensource applications have become the industry standard for the server side market. But we need to be able to communicate with buisness colleages cleanly, in order to do anything with an office suite. This means MS document formats as they have been the rule of thumb as to what to use for the past decade.
I dont know how many of you will get down here but a specific programmer comes to mind who I'm sure would appriciate the donation. I dont think he has a paypal link but I bet if you e-mail him (I think I will just have to do so myself) he'd tell you where you could send your donation.
Muhri! www.muhri.net, I am not he but he is the author of several open source projects of which are very widely used. gkrellm, skipstone, pronto...any of those ring a bell? And IMHO He's done a very good job, keeping all of his code very modulated, lightweight and extreamly becoming of unix tools for as far as X11 applications go.
I wish everybody else would think dozens of small tools rather than one very large tool, but for some reason GUI Userlands are slowly but surely killing that kind of development off even in the opensource world.
If I remember correctly I spotted a post several weeks ago entitled something like "XP Pipe speed Slower than Win2k?" Instead of pointing to examples using direct MS Software titles, it pointed to actual tests of piping, and even gave you the code used for the benchmark. And last I checked, much of multitasking often relies on piping, especially in a software package that trades information between binaries, as would Office XP.
But ofcourse you cant expect MS to write any type of data exchange that is fast, I mean after all, they wrote DDE:)
-If your not the lead dog, the view never changes-
Re:And of course there is always Galeon
on
Netscape 6.2
·
· Score: 1
And of course there is always skipstone, which even less bloated than Galeon. In my experiances so far skipstone has put MSIE to shame, right along with everything else. It does have one little problem though, so far skipstone hasn't been compatable with every version of gecko...the first version I used it didn't generate a scroll bar, the second worked perfectly, the third didn't submit forms, now its back to working. I suppose it needs some help, but being an opensource project the only help it'll get is for people to use it, find the problems and fix it.
Aside from an occasional glitch that can usually be countered by hunkering down until the next version - skipstone is the ideal display of how quick gecko really can be:)
Slashdot Mirror
Those numbers "about half of all software engineers have a degree" [wikipedia]. "Nearly half of the software developers in the United States do not have a college degree. Many never even graduated from high school" I haven't been able to find a single study that confirms those statements, and it isn't corroborated by my own experience. Even if they were real, what would they even mean?
If all people who write programs of all type are included, the number may have some validity, but in my team which builds software that runs an advertising network 6 of the 8 software enigneers have a degree. The two outliers are a developer with twenty years experience building software, and a senior graphic designer who is holding an internship level software engineering position because the company wanted to support his desire to change careers. Across the engineering department, a hand full of engineers have degrees which aren't computer science, but very few of them have no degree at all.
Building software is a lot like other skills, skill sets vary. You don't hire a detailer who you pay $20/hr to wash cars to paint a car if you want car-show quality results; you hire an auto-body expert and pay him $100/hr. Similarly, you might hire any old contractor to build a garage, but you don't hire any old contractor to build you a thirty story building — you hire a real architect, and a real engineer. On the same note, you can't hire someone who just "can program" to build a system that runs a business of much scale.
The device was virtually unusuable due to the sheer volume of bugs in the touch-screen interface. I've had one, for almost a year, and it's now quite reasonable (a dozen firmware updates later) but at first, I had such problems as not being able to select an email or phone number if it was not on the first page-full of a list, because when I did, I would get the item that used to be at those coordinates when I was on the first page full.
And developers using file access APIs in Windows can get case sensitive behavior. It's just a single FILE_FLAG_POSIX_SEMANTICS flag to CreateFile and friends. It's actually easier to do that in Windows because it doesn't require a reformat and reinstall.
Only on slashdot would anyone take this kind of time, to talk in this level of detail about the windows API regarding case sensitive file names in a thread of commentary which had nothing at all to do with what you are talking about. The shame in /. is to tap into the wealth of knowledge that's is it's reader base, you apparently have to float around and make baseless trollish remarks and you will get in response a wealth of information, no matter how tangential.
Kill Oracle....hahahah.
VIM renders text-area as a grid. This is compatible with column-area selection, and other features it supports which frankly I use nearly daily. While I've honestly considered using proportional fonts — I've tried living without VIM, switching to Eclipse or IDEA for several months at a time to give the IDE experience a full opportunity. Doesn't work for me, so neither will proportional fonts.
Besides there seem to be more reasons not to use proportional fonts than to use them:
Reasons to use them:
Are you guys crazy? Microsoft has "troubles"? Microsoft is laying off 5000 people...out of 91,000. That's 5.5%, relatively light for this economy. Sony is laying off 16,000 of 185,800 people leaving it's slashes at 8.6% (incase your arithmetic isn't up to it, that's 63% more people relative to the size of the company). The company I work for (I won't mention the name) last year cut a total of 139 of 800 people including three senior executives, registering at 17.3%. Now that's a troubled company. Microsoft is running very strong. Their profit margins remain in the 20s despite the hardening economic times they continue to run without an annual net operating loss and maintain an enormous cash position. Microsoft is in no way "troubled". They're being very conservative about even being prudent, given the state of the economy. They could probably afford to -- and might benefit their shareholders if they did -- live without double the number of people they are cutting.
OOP is not one tool too many, it's just a tool that's used inappropriately all too often.
Object Oriented Programming *can* lead to incredibly elegant application designs, high separation of concerns, easy feature-scalability and very flexible and agile code.
The problem typically is, that programmers focus on the wrong things when building an object oriented application. They worry about things like how to use inheritance, which is probably the most over-valued feature of OOP. They create objects which are large, upside-down in structure (utility base classes!?) and couple data and functionality arbitrarily (making data objects have functionality that is not intrinsically exclusive to that data, is a common error in OOP).
Java programs can be elegant. But usually, they aren't. The fault is not the language, or OOP. The error is the operator.
The single greatest attribute to good software is that the group or individual responsible for it both really wanted to write the software, and really wanted it to work well. This is typically attributed, not to much of a surprise, by the ego of the individual or collective ego of the group responsible.
The things that makes software good, in my opinion, is having created a program that performs a collection of tasks which solve the problem for which the program was intended, and doing it without unexpected errors and within the parameters of it's environment. This means web software that scales to load, desktop software which doesn't -- but scales to features, and software that in general...works. No stack traces (except in a log, maybe) and no null pointer exceptions, and naturally no segfaults.
One thing java programmers should learn is to treat NPEs like they are segfaults -- because, if this wasn't java, they would be.
All of the best programs, never mind how horrendously ugly their code might be, must be tested thoroughly...this typically requires support from developers to accomplish effectively. That being said, the best programs that most programmers will ever write, are the programs that they themselves will *use every day*. They thoroughly use it, and use it regularly. This tends to lead to a lot of really good QA. Unless they are lazy.
There was some item above I was replying to when I decided to make a larger post...here's the item I was responding it:
It should read only :
map(lambda x: int(x.strip), input.split(","))
But this is easier than you think in java, or perl, or any other language that has regular expressions.
List results = new ArrayList ();
Matcher matcher = Pattern.compile("([^,]+)").matcher(args[0]);
while (matcher.find()) results.add(Integer.parseInt(matcher.group(1).trim()));
Granted, the java version is 3 times the amount of code than the most expressive python version. But it's still not a lot of code, in fact, it's quite concise. And it's a lot more optimizable -- and more strict.
But both of these examples suck, really. Because if you're looking for numbers -- your regular expression should match numbers, and not just try to blindly parse the data as an integer.
And here's the part that really matters
Anyway, I think ruby, python and friends are growing in popularity not because they increase productivity, but because people suck. After all, those ruby folks who hate java also hate XML, and XML is nothing more than a collection of super fantastic technologies built ontop of a common document format where a single parser and parsing framework can be used to represent a myriad of types of data -- how cool is that?
And like any tool, it's only as good as it's user, which precludes that the user using the tool must be using the right tool for the right job, which all too often is not the case regardless of the language. I think the entire world of software engineering would benefit from forgetting about the related philosophical wars related to programming languages, tools, and frameworks and just learn how to use as many of them as possible. Learn as much about them all as possible. And start trying to chose your language, framework, and libraries based on how they solve the particular problem each and every application faces -- which is always specific to the application and it's purpose.
If we chose tools using this pragmatic approach, rather than buying into any given framework, language or library regardless of the problem we would actually have a better cognative ability as an over-all community to be more productive in developing tools, languages and frameworks that meet the needs of specific problems and do that well, and would thus increase our over-all effectiveness as an entire industry.
Of course, that's probably not going to happen.
But part of the problem I saw when I read your article is that your suggestions really aren't that good. Take for instance your example of "good" comments:
That comment is actually documentation, and if you are going to document in comments (not *entirely* a bad idea) then you should be actually using a type of comment designed to be picked up by some documentation system, such as autodoc.
Describing what your code does is the job of documentation, describing why your code does what it does the WAY it does is the job of comments.
An example of just saying what you're doing instead of why you're doing what you're doing.
Why do we need to say that this changes the bullets position?
Shouldn't the code probably look like, bullet.setX(x); bullet.setY(y); or some variation thereof and a redraw? Wouldn't that indicate that the code is moving the bullet? Do we really need a comment to say this?
In retrospect, a good time to use a comment is when you deviate from anything a future onlooker would be expecting from your method, function or subroutine. For instance, where you would do something specifically because of another bug that or behavior that is out of your control.
A smart person doesn't need to remind himself what code X does, unless it's not obvious.
In the section where you suggest using define a lot, I honestly consider that a particularly bad idea. Using global constants is just in general a bad practice. A good practice, on the other hand, is having all arbitrary static data be a matter of configuration. That is, instead of defining NUM_ALIENS_TO_KILL_TO_END_WAVE as a compile time constant, or any other form of literal, define it in a configuration file so it can easily be modified without a code change.
Enabling behavioral changes without code changes is critical to software success. Every time you change code, you rebuild and redeploy things. And this provides the potential for other
I switched because of my interest as a developer. Even in the MSDOS world most of the code I played with in my early days was in the public domain. When a found a plethora of powerful development tools and a free way to follow the unix way of things, the choice was obvious.
.CreateTextFile method still haunts me to this day.
The reason I never switched back is more important, I think. I've found windows interface to be cumbersome, and I find features common to X11 desktop environments to be things I can't live with out...Features, such as multiple work spaces, window shadowing, window grouping, and auto-configuration (pekwm !) and placement of windows I struggle with not having access to in Windows. As well as that fancy global copy on select clipboard.
In addition to my actual use of the environment itself, which is almost emulatable in windows these days (but not really to my satisfaction) I have found programming in windows (as well as more often than not just with priorietary software that never gets good code review) to be increadibly painful. The API's are nonsensical, cumbersome, and downright ugly even for the most basic of operations. The
These are just the surface reasons, for a developer such as myself, to not only make the switch but buy in whole heartedly. I'm not even going to get into the fact that when they made me start running Windows 2003 Server on my dev workstation at work I started spending a lot of time dealing with issues such as my desktop crashing, my second display failing to function at random, and so outlook siezing up at random.
This is very becoming of microsoft software. Their page, although having an identical layout, and an extra feature (column control) is clunkier, non-standard compliant (? xmlns:msn ...a namespace without a URI?), and simply doesn't really work as well as google's nice streamlined page, although I have to admit...google's page isn't to standard friendly either ( is not approved by the W3C, and element's require a type attribute!).
The point is, I pick google's, because when I click on something and drag it, I get smooth behavior, rather thank chocking, choppy wierdness.
But it wont surprise me if 90% of people don't agree with me or don't find googles page and find microsofts first, since that is typically what happens.
It's complete malarkey that testing is only a priority on a closed source application. In fact, the beauty of open source is that many of the lower level products of open source (libraries) are fundemental elements of much larger commercial products. Regression testing at the library level is a very common practice, and some development communities (I'm sure you all dislike perl, it's not my favorite language but this is my favorite example) like CPAN even force atleast some tests to be in place before a library can be distributed through that system.
In many of the large sucessful projects I see test cases are a huge part of the development. Look at mozilla's tinderbox system, it automates lots of tests before patches are even accepted into the development branch. This is after a patch has been either created by or reviewed by one of the core developers.
Open source is not some wild west land where anyone can go around adding any code to any project they want...well I mean they can, but it won't effect the distribution. Distributions are still controlled by the author of the project, and anyone else the author decides to delegate the responsibilities (aka privileges) to.
When I'm building a proprietary application, I often end up building it out of a number of generalized solutions which I abstractify into libraries with carefully thought out APIs in order to promote reuse and flexibility. I do this so that not only I can use them with other applications, but so with some careful evangelizing with my customer(s) I can convince them it is in their best interest to allow these generic elements of the application to be distributed in the public domain.
One thing people keep missing about open source is that it's a developer's method of doing things. It doesn't mean we can't create great user desktop software, but it does mean that open source isn't an approach to replacing vendors who develop and support software. It can be a model for sharing all generic parts of an application to give it good code review, increase its stability, and for developers to collaboriate indirectly on a very large scale.
I think OS-X is a great example of this at work, Cocoa being *just* as proprietary as windows, but the actual underlying system is just as open source as linux. Obviously Apple's developers know how to build a great user interface and have the infrastructure necessary for enterprise quality support, where the open source community has the ability to build flexible, powerful, innovative solutions that could not take shape without having thousands of prying eyes on the source code. The result is a solution that's easier to use, harder to break, more flexible and more powerful than anything that could ever come out of Redmond.
Now if only we could get Apple to quit being selfish and make the daring move to becoming an OS Vendor as well as a computer manufacturer, maybe there could be a viable desktop software solution for the average person who thinks of a computer as an appliance. From what I've seen, Microsoft's software is far to easy to break for these kind of people, and the literally computer illiterate stuggle with it horribly. And speaking from experience, developers used to more sophisticated ways of doing things (such as by following standards and whatnot) find MS software hard to work with.
If the mozilla project's standard compliant SVG rendering is deployed into the market first, the "next" IE (Whenever that is - how many years has it been since an IE release?) will undoubtably need to support SVG markup standards and thus won't be an issue.
:-)
From what I've been gathering, it really seems Microsoft's project of making IE the #1 browser is greatly slipping. I've heard rumours of a GRE Compatible XUL markup being supported, as well as rumors of aliasing all of the ActiveX component API's with XPCOM compatible APIs giving access to all of the ActiveX controls we need through the nsI interfaces. [ e.g. new ActiveXObject("MSXML2.XMLHTTP") becomes new XMLHttpRequest(), and so on ]
All of this makes me think that MS's attempts at slightly breaking all standards and trying to push forth as the lead-dog in the "world wide web", are mostly dead.
At the same time, I'm mostly praying they are because I'm really tired of dealing with it
Oh great, so you mean PHP5 finally borrowed the method resolution behavior of Perl 5?
Fancy that!
There are a number of other languages which allow you to dereference return values and call member functions on them. One of them is (surprise surprise) ECMA, Also known as Java Script. Another one I fancy is Pike.
PHP5 Still hosts a large number of the PHP4 Flaws. And additionally, bench marks show that it is still very damn slow. Not to mention the scope behavior of PHP5 is hardly more advanced than that of awk. C'mon now.
Gnumeric, is a nice quality GTK spreadsheet application, and it does write and read Microsoft Excel 95 formats. Which albiet isn't an office XP format but surely the office XP suite is backward compatable. Thats always been one of MS's biggest issues, I mean, yeah ;)
We've all seen how MS's buisness and development plans work, and we dont need them pinching into the *nix market. After all MS Office is not even very good (In ways of eficiency atleast) and the only reason its popular is because its become an industry standard out of sheer marketing. What we do need though, in my opinion, is for more of our local speedy, quality applications to support MS office formats. (Abiword writing ms .docs would be a good deal, and KOffice would be good too). I think we could do more with opensource applications that we build to cover these formats. I know the .doc format is not very good, I'm sure abiword's document format as well as many others are superior for thier own reasons. But this doesn't help us at all when it comes to penitrating the office market.
In my mind and experiances the opensource community's goal as of late has been to build a quality stable and fast workstation enviroment. After all we already have, have had and will continue to have the best of the server market. Apache, thttpd, php, mysql, all by far outperform IIS, Asp and Access for a server application in resource handling, efficency and stability, and I would even venture as far as to say that opensource applications have become the industry standard for the server side market. But we need to be able to communicate with buisness colleages cleanly, in order to do anything with an office suite. This means MS document formats as they have been the rule of thumb as to what to use for the past decade.
I dont know how many of you will get down here but a specific programmer comes to mind who I'm sure would appriciate the donation. I dont think he has a paypal link but I bet if you e-mail him (I think I will just have to do so myself) he'd tell you where you could send your donation.
Muhri! www.muhri.net, I am not he but he is the author of several open source projects of which are very widely used. gkrellm, skipstone, pronto...any of those ring a bell? And IMHO He's done a very good job, keeping all of his code very modulated, lightweight and extreamly becoming of unix tools for as far as X11 applications go.
I wish everybody else would think dozens of small tools rather than one very large tool, but for some reason GUI Userlands are slowly but surely killing that kind of development off even in the opensource world.
Amen!
My Typewriter is electric so it only slows me down about 5-10wmp at that.
If I remember correctly I spotted a post several weeks ago entitled something like "XP Pipe speed Slower than Win2k?" Instead of pointing to examples using direct MS Software titles, it pointed to actual tests of piping, and even gave you the code used for the benchmark. And last I checked, much of multitasking often relies on piping, especially in a software package that trades information between binaries, as would Office XP.
:)
But ofcourse you cant expect MS to write any type of data exchange that is fast, I mean after all, they wrote DDE
-If your not the lead dog, the view never changes-
And of course there is always skipstone, which even less bloated than Galeon. In my experiances so far skipstone has put MSIE to shame, right along with everything else. It does have one little problem though, so far skipstone hasn't been compatable with every version of gecko...the first version I used it didn't generate a scroll bar, the second worked perfectly, the third didn't submit forms, now its back to working. I suppose it needs some help, but being an opensource project the only help it'll get is for people to use it, find the problems and fix it.
:)
Aside from an occasional glitch that can usually be countered by hunkering down until the next version - skipstone is the ideal display of how quick gecko really can be