The future of programming

[Anonymous]

kk, I'm glad FB is GPL, you're right, I'm sure no one would want to steal that (lmfao).

Some corporation did a good work to convince people GPL is a bad idea ;]

[Agamemnus]

In essence, people can't live on free. If everything is free, it'd be communism. People would lose the incentive to do anything.

So Necros is saying that even if you use other people's code AND your own code, the GPL on that other piece would force you to make ALL code free? Bwuh?

[Deleter]

Personally I don't think open source is really the future. I think its more of a catalyst. Most of the time, small time companies cannot compete with the big software devs, so they are forced out of business. Open source is a way of countering it, as people don't have to stake their livelihood on a program, yet you can still have a huge team working on a project. Some open source products really rock, others suck. But the strength of open source is also its weakness. While it allows virtual "no body's" to take on people like microsoft, it does not really force them to. In other words, while that small time developer has to get his ass into shape to survive, an open source project can just become vaporware with no one the wiser. Also, if an open source project sucks, there is no way to get it better short of doing it yourself, because the people making it don't really have any solid reason to make it better. So while open source can be a good thing, its far from being the total future of programming. Its more of a way of saying to the "pros" that "you better get better or else your out." I think it comes from the fact that the computer industry is still very new. There is not as wide of a gap between pros and hobbyists as in most other fields, and there is not as wide of a gap as far as what they can afford.

[LooseCaboose]

And for the record...don't bother arguing the point, as it's pointless to try. I won't respond, and you'd be simply kicking a very dead, festering horse one more time.

I like that, "Heres my opinion, Im right and you can't argue with me" ;-). Oh well, heres my counterpoints:

The GPL has a bad way of suffocating the small independant firm who wants to compete with the larger firms. High-end libraries cost lots of money, so that option is simply not available to the small firm. Countless man-hours must be spent to develop something in comparison (at the same time, allowing too much time to pass, and losing the competitive edge). Or, the small firm could go with a GPL'd solution, and sacrifice any form of trade secret or market advantage.

Many libraries are released under the Library/Lesser GNU Public License (LGPL) which allows the code using the library to be closed. For example a company can use GCC and the GNU C library to develop a piece of software and then release that software as closed source even though it contains code from the C library. In this case the GPL is helping small businesses.

A large amount of GPL code is developed by hobbyists who do not get payed, why should they just give their code away to small independant companies under a less restrictive license? The alternative is something like the BSD license, which allowed Mircosoft to copy the entire TCP/IP stack into Windows and never pay the original developers a cent.

The GPL is really a delusion of grandeur thrown together by some OSS dreamer that says "bad big company, you no steal my code lolrofl!"

No, it was designed to promote sharing of code. By requiring projects based on the GPL to provide the full source for their modifications it gives back to the community. If you can't abide by the restrictions of the license, then don't use GPL source, but don't complain because your want your source code for free and you want it to be on your terms.

Well, I got news for you, dreamers...the big corporations don't WANT your crap, so there's zero reason to worry about it

Which is why big companies like Apple, Google, Redhat and IBM are paying developers to work on GPL software now ;-).

[Anonymous]

It seems to me that the GPL just strives to give credit where credit is due, which is an ideal solution, imo. And like LC said, LGPL allows you to use it in closed source.

Example: FB is GPL, you can't change the compiler, close the source, and sell it. You could still sell it, You could still change it, but you have to make the src open. (As well as the original src) On the other hand, FB's runtime lib (the ocmmands your prog uses like PRINT, CLS, etc) are under the LGPL. Which means you can write progs which have those tools embedded in them, AND make your app closed src, and profit from it.

If I got anything incorrect, someone here will let me know about it quick. =)

See, that was an allusion to open source's benefits as well. The more eyes that see it, the more likely that errors get flushed out, like Wallace said in his first post.

FB would not be as stable as it is today if there wasn't tons of people writing code and finding the bugs. And there are lots of people and schools and even businesses using FB right now, don't kid yourself.

[DrV]

The actual language used in the LGPL is a little confusing - IANAL, but the common interpretation seems to say that if you statically (rather than dynamically) link to a library under the LGPL, you must release your sources...

Hence this exception used in the FB rtlib:

* As a special exception, the copyright holders of this library give
* you permission to link this library with independent modules to
* produce an executable, regardless of the license terms of these
* independent modules, and to copy and distribute the resulting
* executable under terms of your choice, provided that you also meet,
* for each linked independent module, the terms and conditions of the
* license of that module. An independent module is a module which is
* not derived from or based on this library. If you modify this library,
* you may extend this exception to your version of the library, but
* you are not obligated to do so. If you do not wish to do so, delete
* this exception statement from your version.

[LooseCaboose]

The actual language used in the LGPL is a little confusing - IANAL, but the common interpretation seems to say that if you statically (rather than dynamically) link to a library under the LGPL, you must release
your sources...

Having to dynamically link and then provide access to code for the just the library seems like a pretty small price to pay in order to get an entire library worth of free code.

[Anonymous]

The actual language used in the LGPL is a little confusing - IANAL, but the common interpretation seems to say that if you statically (rather than dynamically) link to a library under the LGPL, you must release
your sources...

Having to dynamically link and then provide access to code for the just the library seems like a pretty small price to pay in order to get an entire library worth of free code.

Yeah, especially if you make a nice, tight interface to the library, like anyone really should =P

@drv, thats good to know, thanksfor clarifying that.

[Moneo]

The title of this thread is "The future of programming."
However all the posts only talk about programming languages, languages that can generate code, the good/bad about Firefox, open source this and open source that, GPL, and other such stuff.

I see the field of programming split into two distinct categories:

Category #1: Programming of commercial and scientific applications, and system software to support these.

Category #2: Programming of software focused primarily on single end-users, such as operating systems like Windows, including a huge variety of tools and utilities.

Before 1981, when the IBM PC came out, all programming efforts were devoted to category #1 above. With the advent of the PC and then Windows, there was a tremendous shift in the computer industry to jump on the bandwagon and provide software for the hundreds of millions of PC end-users. The business of software shifted away from application software. Not that application software is not still being developed, but the percentage is extremely small compared to the software being developed for the PC users.

My observation of what goes on today in many corporations, is that every single employee in the company has a PC, and they're banging away at it all day long. Prefessional software development is done by a very small department, and very ofter entirely farmed out on an outsourcing basis.

The last company I was with had 63 people in the IT department, and none of them knew how to program (except me). Their software development was done by 6-8 outsourced programmers.

The worst part was that most of these 63 people were responsible for various business processes and files, which most of them "programmed" in Excel. I was an internal IT auditor at the time, and reviewed their work and Excel files. You can't imaging the garbage that I found, especially on the files. I had to write special QB programs to validate, sequence check, and reformat the files. These people were processing the company's data with no training whatsoever on data handling priinciples.

In a previous job with a global publishing company, although I wasn't an auditor, I encountered the same chaotic Excel and Access files when they wanted to import these data files to be integrated into the main IT system.

So, let me get back to the subject of the future of programming. For category #1 programming, specifically application programming, I think that there should be an emphasis in the future to teach and train programmers on the applications that they are expected to develop. These programmers are devoting entirely too much time to the new development languages themselves, the intricacies of object oriented, the database and webpage considerations, and less on the requirements of the applications. Hey, if you're developing a Supply Chain Management system on a web-based system, you need to thoroughly understand all the concepts of Supply Chain, not just all the language, database, and web goodies.

Category #2 is a tough assignment for the future. Most software development for this category is done by Microsoft, computer manufacturers, and independent software companies. In the future, they will continue to develop software that sells.

Let me move on to the majority of end-users of these products. If company members are going to be responsible for processes and their corresponding files, they need to be given some formal training on the processes, on the tools (Excel, Access, etc.), and on the concepts of creating and maintaining data files, including data verification, code validation and formatting, date handling, duplicate entry detection, sequencing, etc. When company members perform these tasks, they can be considered as "programming" the processes to produce the required data files. Therefore, just like programmers in category #1, they need to be trained, and their processes and files need to undergo some formal acceptance testing, and documentation needs to be written and reviewed. None or very few of these category #1 type functions are done today for category #2 "programming" activities. Each user basically does his own thing.

In summary, I think that programming in the future should require more training on the applications being developed, and increased controls and adherence to standards, like SDLC. Let's face it, you can have use the newest language, like Java, the best database, like DB2, the best webpage language and browser, but if the application doesn't perform correctly, your system is a failure.

*****

[Anonymous]

Interesting point, moneo. I know from experience that when "end-users" are allowed to "program" in sort of pseudo-languages that the applications offer, things can get messy. =P

Preventing this catastrophe is exactly as you said, merely education.

These programmers are devoting entirely too much time to the new development languages themselves, the intricacies of object oriented, the database and webpage considerations, and less on the requirements of the applications.

I guess the problem is that there are only so many people who can code large systems, and as a result, those people are forced to be more flexible, sometimes creating apps that they don't even understand.

Maybe it's a consequence of breaking things down into very small steps; every programmer on the team doesn't have to understand the full system, but at the same time, maybe it would be advantageous for them to...

In summary, I think that programming in the future should require more training on the applications being developed, and increased controls and adherence to standards

I agree, and it irks me very much when people dismiss adherence to good coding practices as "elitism" ...