Slashdot Mirror

Then how do you call something that is spread by neither advertising agencies nor ordinary people, but by f*cking corporate media, which are making up shallow boulevard news so they don't need to tell the real news?

It's not viral marketing, it's bloody PR: http://www.paulgraham.com/submarine.html

Yes, lightyears ahead of code which is talked about, but still not publicly available : Arc.

If you use computers, I know that you have run into software that totally sucks. In fact, not only did it totally suck, but every piece of software that came close to doing that thing sucks. Or you have run into wanting to do something that simply no software out there does.

There are still LOADS of gaps like this anywhere from tiny utility software up to enterprise level stuff. Pick one. Whatever one bugs you the most. Write some really good software. Open source it and sell support. Or don't.. whatever. Just write good software.

So you need some deadlines to keep you going? Not uncommon. Have someone do it for you (isn't that what you would do by contracting?). Either get yourself a partner (preferably someone who is keen on handling all the _other_ parts of creating and running a company in exchange for the possible rewards) who is also a good deadline-setter and will not let you slack. Or hire yourself a business coach if you do want to try your hand at the other aspects of running a company and just want someone to egg you on.

Read Paul Graham's essays for encouragement and why starting your own software company is (still) a good idea. http://www.paulgraham.com/

Oh yeah - ALSO find yourself another engaging hobby or two. They must involve at least the following:

Social interaction. Yes you need this. You cannot work in front of a computer at work and do programming all day and then come home and do it all night. Your boss made that rule for a _reason_ . In order for your creative programming side to flow the rest of your mind must be fed. If you just program all day every day for primary job and then your side job your productivity will drop like a rock. This should ideally involve more than one person - a significant other will severely cut into the time you can spend on the stuff you need (socializing with more than 1 person and getting outdoors (see below)). It is a trade off.

Get out. Out of the house. Out of buildings. Gardening maybe. Or hiking. Bicycling. Whatever appeals really. This is important for all the same reasons that social interaction is. It will tend to give your mind a break from thinking too heavily and the opportunity for creative thoughts to bubble up. It will also keep your body healthier. Not Olympic gymnast healthier. Heck - gardening will leave you a fat slob (if you are, and want to remain so), but it will bring your health up a slight notch nevertheless. If you want to be time-efficient, find a hobby that combines social activity plus getting out - this would possibly allow the space to date. But I do feel that doing something relatively mindless (BUT NOT IN FRONT OF A SCREEN - no video games and no TV. They are not mindless enough) is also fairly important even if it is only for a short amount of time..but regularly. At least once per week. Heck - just sit outside in a lawn chair in the sun and make chain mail. No thought involved, but you get fresh air and sun.

Remember, the hobby must be engaging enough that you will continue to do it in spite of the pull to spend all of your time in front of the computer. Try out a few and see which one sticks with you for a while. Plop a reminder in your calendar a few months down the line to start the programming part (ie: don't get so sucked into the hobby that it cuts off your original plans). Plop a reminder in your calendar a few months down the line to re-examine your hobby(ies).

Yes, this will severely cut back on the total amount of time that you spend in front of the computer programming. In fact, you might get only a tiny bit of code done per week (best done in extended-concentration burst I know - maybe one weeknight and 6-8 straight hours on one weekend day). But it will be much higher quality and you will get a LOT more done during that time.

If you are concerned about the time issues and you happen to watch TV cut it out. Watching TV fulfills neither of the requirements for a healthy body and mind needed for programming. If

I sort of regret writing what I did, it was at the end of the work day in haste.

My apologies too, if my writing caused any offense. It wasn't intended.

Almost any problem you could create have had libraries written to solve them in almost every language, just utilize them and be done.

I've come across many, many problems where this simply isn't true. Whilst almost every language has libraries that handle regular expressions, graphics, network access and so forth, once you get into specifics, the difference between the libraries for languages becomes far more apparent. Java, for instance, has some very mature XMPP libraries, whilst in Python, all the equivalent libraries are in a much earlier stage of development. And as I've mentioned before, C++ doesn't have an equivalent to the Turbogears framework.

However, let's put the library issue to one side, and concentrate on whether the syntax of a language has any significant benefits for the programmer.

That said, the custom back-end business code to that webpage could be in almost any language and it would take nearly the same amount of development time. VB, C, anything.

I disagree with this as well, but for reasons that are less easily explained. I'll let a quote from Paul Graham's Beating the Averages essay start my argument:

But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be.

Lisp macros are a good example of high level syntax that C++ does not possess. In Lisp, macros are used to manipulate code in the same way functions are used to manipulate data, or, to put it another way, Lisp macros enable you to make local changes to the syntax of the language. They are very different from the macros found in C or C++.

Given that the programmers in the startup Graham was involved in were writing so many macros, one has to wonder why. If programming in Lisp has no significant advantages over C++, why use a language construct like macros that has no direct analogy in C++?

There are two conclusions you can draw: either Lisp has no significant advantage over C++, and the programmers were using macros pointlessly. Or, that macros did serve a purpose, and thus Lisp does indeed offer advantages over C++. Given the success of the company, they must have been doing something right.

Indeed, one can see this same theme with many other libraries. Turbogears uses high level functions and metaclasses throughout its systems. Again, these are language constructs that C++ lacks, but are used often enough that one has to wonder about the benefits of these features, even if one knows nothing about them first hand. If Python offers no significant advantage over C++, why are these constructs put to use so commonly?

Since C/Fortran, languages such as Java/Python have been moving steadily toward the lisp model:

http://www.paulgraham.com/diff.html

And lisp code can be made as fas/almost as fast as C code. I don't know if you were trolling with that old myth, but advances in compiling lisp have let it catch up with C. The only problem is that it's much easier to write slower code in lisp than in C if you don't know what you are doing (in either language).

But I'm sure you knew that.

Hi Killjoe,

Here is an essay you should read to answer: "I mean if zope is so great...." why don't more people use it?

http://www.paulgraham.com/iflisp.html

It's about lisp, but it may apply to zope as well. And lisp is experiencing a revival since 2000, when Paul Graham started advocating it. Coming from the C family of languages, hanging myself on c++/java back in the 90's - I've come to love lisp and recognize how much the languages like python/java were attempting to move from c to lisp/otherlanguages in terms of features.

Anyway, I just wanted to say you shouldn't always look at what those around you are using if you already have a tool (language) that works well. You should use what makes sense, and if zope works, there's no reason you can't stay with it, if you're deciding to move just for popularity reasons.

While there are some libraries that blur the line, I'd have to sincerely disagree.

Take Python for example, and compare it with C++. You can do the same things in both languages. But what C++ cross-platform library or framework gives me runtime object mutation and reflection? First-class functions? Namespaces (importable at any point in the runtime)? Type safety and introspection? Universal serialization (or "object save and load," or "pickling", or whatever one's favorite buzzword is for having a default strategy to contain any data in a static long-term storage form)? A built-in debugger? An interpreter that can allow me to pause execution and modify the runtime environment while a program is executing (including modifying the source code, re-compiling it, and re-inserting it into the environment without restarting the process)?

And more importantly... if I have those features in library A, how do I get them in library B?

While one can obtain some features in a low-level language through proper choice of libraries, a high-level language demands those features exist in all code, and that they be accessible through an agreed-upon syntax. As Paul Graham notes in this Lisp-related essay, that's one of the reasons one would bother to learn a new language---because languages are different at a level deeper than the libraries available to them. Remember, C++ started as a simple extension to C---eventually, a point was reached where it became its own language, and there are in fact valid C programs that are not valid C++ programs.

On the flip side of the Python/C++ coin, by the way: how does Python give me pointers and explicit memory management?

1. Lisp is interactive.

This is about the only statement you got 100% right. Lisp is interactive and it is a plus, IMO. It's nice that a drops back to a REPL when condition (execptions in Java/C++) is signaled. I can query the environment state, inspect variables, or provide restarts. But, it does not have to be.

2. Therefore, Lisp is interpreted.

Not necessarily. Most Common Lisp implementations can either interpret their code or have their code compiled.

3. Therefore, Lisp uses non-native code.

Most Common Lisp implementations can be compiled into native fast-loading files (FAS) or byte code. Some implementation can even create stand-alone executables.

4. Therefore, Lisp runs in a virtual machine.

Not really. Common Lisp run in an environment and executes either native code or byte code, depending on the implementation. CLISP is the only major Common Lisp implementation that I know of that does not compile to native code. Hey, it was good enough for Paul Graham when developing Viaweb. I was even shocked by that.

5. Therefore, Lisp is incapable of direct memory addressing or interrupt handling.

Not sure. There are some people creating Lisp operating system, it might be possible, right?

6. Therefore, Lisp can't be used to create an operating system!

Hmmm. I guess creating a Lisp machine in hardware is not enough, huh?

If the economy is so great, why are so many former programmers and sysadmin types working at my wife's place of employment (a call center) for $12-15/hour?

Cuz they sucked? Cuz they didn't add enough value over an Indian IIT grad even counting the costs of networking and cultural differences?

To legitimately keep a job, you have to have productivity per invested dollar better than someone else. Lots of factors play into that: your salary, your education, your reliability and effectiveness, but also externalities that you have little control over (such as the tax, legal and infrastructure systems of your locality, state and nation).

I think Paul Graham's articles on starting 'silicon valleys' is pretty spot-on but I think he leaves out the critical issue of taxes..

If the economy is so great, why are so many former programmers and sysadmin types working at my wife's place of employment (a call center) for $12-15/hour?

Cuz they sucked? Cuz they didn't add enough value over an Indian IIT grad even counting the costs of networking and cultural differences?

To legitimately keep a job, you have to have productivity per invested dollar better than someone else. Lots of factors play into that: your salary, your education, your reliability and effectiveness, but also externalities that you have little control over (such as the tax, legal and infrastructure systems of your locality, state and nation).

I think Paul Graham's articles on starting 'silicon valleys' is pretty spot-on but I think he leaves out the critical issue of taxes..

Good suggestion! I would supplement it with the following as well:
1. Episodic Learner Model/An online Lisp tutorial
2. Common Lisp: A Gentle Introduction to Symbolic Computation
3. How to Design Programs
4. Practical Common Lisp
5a. The book - Structure and Interpretation of Computer Programs
5b. The movies - Structure and Interpretation of Computer Programs
6. Loving Lisp - the Savvy Programmer's Secret Weapon
7. Common Lisp the Language, 2nd Edition
8. On Lisp
9. common lisp: a web application tutorial for beginners
10. JavaScript: The World's Most Misunderstood Programming Language
11. Free JavaScript Learning Center
12. JavaScript for Scared People
13. JavaScript Closures
14. Why's (Poignant) Guide to Ruby

= 9J =

My parents told me it would all get better, but it was cold comfort at the time. I wish Why Nerds are Unpopular had been around at the time; it would have made it all so much more bearable if I had know why it was bad then, and why it wouldn't be that way forever. Wouldn't have been so damned hopeless at the time.

Meant to add this aswell:

http://www.paulgraham.com/nerds.html

The fact that BlueSecurity caused spammers such a headache that they either complied or attacked is proof that the idea of DoSing the advertisers is absolutely valid. This really hit spammers where it hurt which is why it provoked such a massive response. The failure of the model is that BlueSecurity represented a single point of failure -- they could be singled out for attack. IMHO, I think Paul Graham's idea outlined in his excellent article "Filters That Fight Back" will be the next step in this idea. If all mail servers were sending unsubscribe requests to spamvertisers, the assault on the advertisers would be distributed... DDoS. While spammers could take down BlueSecurity, they couldn't take down all the world's mailservers.

If you're an investor in Creative get out now.

A company that sues competitors for patent infringement is like a defender who has been beaten so thoroughly that he turns to plead with the referee. You don't do that if you can still reach the ball, even if you genuinely believe you've been fouled. So a company threatening patent suits is a company in trouble. Paul Graham

Nice straw man.

But, ultimately, an assertion with just as much logical weight as yours. He offered his opinion on how the case was covered, you offered yours.

They covered, but they went with the Dem party spin for the most part, that Ken Starr was persecuting Clinton for a private affair that should be left between a man and his wife.

Not in the papers I read, or on the news programs I watched. The perjury and obstruction of justice charges figured significantly in most of them. Sure, the newspapers were full of opinion columns on both sides of the issues, and some of those columns presented the argument you're speaking of. But confusing that with some kind of unified general spin from the media is ludicrous.

Interesting anecdote from Schwarzenneger's run: you may recall that it appeared he had a history of harrasment that might have made Clinton blush. Of course this was brought up during his campaign. His campaign's response? No comment about whether or not the charges were true. Simply a statement: "These attacks were politically motivated." And that was enough for many people to simply drop the matter. It didn't matter whether or not they were true, verification wasn't an issue. Because the matter could have been used by his political opposition, it was considered tainted information and irrelevant.

This is essentially the strategy of those who would paint "the media" with a broad brush as "liberal" -- and therefore, possesed of a unified agenda against their political causes. Get people to distrust it, and they'll simply disbelieve when it says something they don't like.

Of course the media isn't perfectly trustworthy. With the exception of a rare, few pieces of real investigative journalism, most news stories are mere starting places for understanding an issue. Misconceptions are regularly propogated. Stories are pushed by all kinds of hidden interests. And especially in the land of punditry, political bias exists (though it is not, by any means, limited to a liberal slant). The solution is not to pronounce the media as a whole untrustworthy, nor is the solution to retreat to an outlet or community that caters to your personal worldview, as is rather easy to do. The solution is to verify. Read other versions of the story. Yes, even check an outlet that you feel is a haven for those with a skewed and opposing political perspective.

That's handling media consumption responsibly. Simply calling "the media" liberal -- or conservative, for that matter -- is just burying your head in the sand.

An expressive, succinct, high-level language is still the better bet than a verbose language for producing quality code.

The compiler's job is to turn any syntactically valid source code into executable code. It might warn you about syntactically dubious constructions. But compilers aren't designed to catch logic errors. While the presence of syntax errors tells you that the code is definitely wrong, the absence of syntax errors does not indicate that the code is correct.

An expressive, succinct, high-level language is still the better bet than a verbose language for producing quality code. All the verbose language does is make you type more, and probably increase the total number of typos. Working in Pascal just creates more syntax errors, which doesn't necessarily reduce the number of logic errors. If you insist on being verbose, your effort would be better spent on adding more assertions and comments to your code.

Unfortunately, if the goal is to produce quality code, C is succinct in all the wrong places, with shortcuts like if (a = b), and verbose in all the wrong places, such requiring you to do your own memory management.

what CS problem that I might encounter in an upper-division CS course requires the use of Diff. Eq., Linear Algebra or Physics?

To pick just one example, the Kalman Filter, which is used for everything from radar tracking to helicopter stabilization, relies on linear algebra. And physics gives an excellent background in learning to apply mathematical modeling techniques to real-world phenomena. One of the best (or at least most interesting) distributed version control systems out there, Darcs, was written by a physicist, in the Haskell programming language (the latter of course being based on the lambda calculus, another seemingly esoteric subject which is so fundamental that it really ought to be taught in high school). Darcs is based on a physically-inspired theory of patches.

There's a problem here which was described by Paul Graham as "The Blub Paradox" (in Beating the Averages). Graham writes "But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up." It's not easy to correctly assess that which you do not (yet) understand.

The other side of the story is that you're totally right about coding being different from CS. The problem is that most HR/Business types don't know the difference.

I agree, this is a big part of the problem. This comes from the fact that everything about computers, and particularly software, is so relatively new. As alluded to elsewhere in the thread, you don't get HR people trying to hire mathematicians or even economists for accounting positions - they know better than that. They just don't know better than that, yet, when it comes to programming, particularly in "IT". And this confusion affects academic curricula, too - universities want to satisfy the commercial demand with subjects they already teach, and academic computer scientists don't want to turn themselves into a Java instructors any more than they absolutely have to.

It seems the best course of action is to expand software engineering programs to fill the void and make sure those are focused on turning out pratical, level-headed engineers who can solve a variety of problems but do not care to learn any more about math or physics than it takes to get an equation from a mathematician or physicist and implement it.

I think that'd be a start. However, I also think we'll eventually find that the tentacles of software are so diverse that "software engineering" is too broad a subject, and we'll end up with a "software school" analog to "medical school" or "law school", where a wide variety of subjects are taught, including theory, engineering, and other topics. I notice CMU has a "School of Computer Science already, and Northeastern has a College of Computer and Information Science, but most other institutions still treat CS and related disciplines as a "department".

-I won't even mention the USPTO and american fair justice system ("the one with the more money always win") that would make us european laugth if it wasn't hype for our politicians to copy your mistakes.

This IMHO the largest threat, actually. This may irrepairably damage our tech industry. It is becoming increasingly risky for a company with money to produce new systems, because of the sheer number of infringements this involves and how much someone would like to sue that company. I've seen this from both the open source developer side and the huge company side, and what is going on is appalling -- mass siphoning of resources from developers and engineers to lawyers and "patent entrepreneurs".

I can think of a number of reasons why the US does well.

* Europe generally has heavily protectionist labor laws. In the US, if a programmer sucks, he's generally fireable at-will. If a company sucks, a programmer can walk out tomorrow. In Europe, you tend to be looking at mandated long warning periods on each side, mandated severance pay, and so forth. The benefit of the European approach is more stable employment. This doesn't come for free though -- it's harder to establish a meritocracy and connect with the best workers. The recent protests over French employment law were incomprehensible to me, as an American (where laws guaranteeing that employees could not be fired without "just cause" for a a certain number of years after they started working were possibly going to be rolled back). If you're worthwhile, your employer isn't going to fire you, and your employee isn't going to leave you. Forcing the employer to do otherwise is not economically free.

I work with some Germans -- they take their eight-hour workday *very* seriously. My understanding is that a German manager that requires an employee to work beyond a certain amount of time becomes personally liable if, say, that employee gets into a car crash on the way home because he is tired. This may be great if you want stable employment; it's not so great if you're trying to get a company going, especially in a market where time-to-market is crucial.

* Venture capital. I remember reading an analysis that dated back before the dot-com boom, and remember reading that it is much easier to get startup funding in the United States than it is in many European countries.

* A large market is easily accessable. The US is well-to-do, and just about everyone speaks English (though Spanish is upcoming). It's easy to write a software product and sell it to everyone in the US. I was debating this subject with a gentleman who runs a German software development firm the other day -- he commented that a US software developer doesn't need to be able to sell to Europe, but that a European software developer generally does need to be able to sell to the US.

* Good education. Expensive, granted. I still see lots of grad students studying in the US from overseas.

* Savings are more liquid. In the US, you tend to have more money going to the employee and staying with him, due to lower tax rates. That means that after a few years, it's easier for someone to take his savings and make a (possibly risky) gamble and start a company. Of course, he might wind up fairly poor in his old age as a result of this; Europe would tend to subsidize that old age more heavily.

* Paul Graham has his own take on this, which seems to be some sort of fuzzy claim that Europeans culturally focus on long-term planning and polishing products, and Americans culturally focus on quick-and-dirty and a rapidly changing market. His arguments seem to be mostly anecdotal, but they are at least fun to read.

* You mentioned deficit financing as a drawback. Deficit financing is bad only *in the future*. It's great in the short term. The faster the national debt grows, the faster resources flow to the US in the short term.

* My understanding (though I'm not aware of the specific

• Installed apps only run on the machines where they're installed. Web-based apps run from just about any Internet-connected machine, which is much more flexible. I mean, if my desktop machine is having problems, I can go to the local library, or a friend's house, and I can hit GMail from there. Access to my data is much more flexible.
   
• How hard is it to push software updates/upgrades to multiple machines? Granted some of the newer management tools are making it easier if you're managing a network of MS Win machines, and most Unix gurus can update a roomful of Unix boxes in short order. But, if you're dealing with a web-based app, you have the potential to roll out multiple updates and upgrades in a single day, especially bug fixes. I've seen this in my own career. I was developing a number of web-based apps for our company Intranet. Someone in HR complained that they were inputting the same data quite often (address of the office where someone was employed), and I was able to throw together something which accelerated the process. There was less than 30 minutes between her whining about an issue and her using the updated system. Let's see you do that with an installed app.
   
• Web-based apps are usually running in data centers, which tend to have better data backup and disaster recovery features than most users. How many users run backups as religiously as a data center? I don't know any. Consequently, if I have a system problem, the data is on their server. If they have a system problem, they are more likely to be able to restore my data than I would be.
   

from my blog
I broadly agree with Paul Graham's essay on Software Patents, but I do think he underestimates the damage from patent trolls, and from what he calls the mafia-like behaviour of some patent holders.
Paul has been lucky in the field he has worked in, but in the Audio and Video area there are many patent thickets. Perhaps it is the history of Farnsworth's victory over RCA that makes video engineers patent hungry.
My first startup, The MultiMedia Corporation, was a spin-out from the BBC in 1990. One of our products was a program called MediaMaker that combined video from tape or videodisc, CD Audio, Pictures, digitised audio and Director animations into picture icons on a timeline for making presentations. It was demoed on stage at Macworld by the CEO of Apple, and we got Macromind to publish it.
Then the patent troll showed up. A company called Montage had made a video editing system that included several video monitors showing edit points from tape. The company had gone out of business but a lawyer had bought up the patents, including one on using a still image to represent a video sequence. The troll was working his way round the video companies, and he caused enough trouble to stop work on the product while we worked on a legal defence instead.
Later, while I was at Apple on QuickTime, there was a steady stream of patent trolls claiming that Apple should pay them royalties; enough to keep several lawyers busy, and a lot of engineers spending time working on prior art evidence demonstrations.
Several potential features were excluded from QuickTime due to patent thickets. The obvious one was the Unisys LZW patent that encumbered GIF, but there were other more subtle pressures that meant adopting open source codecs was discouraged. Working on the patent license agreements for MPEG meant that technology ready to ship was deferred pending legal agreement on more than one occasion.
So I'm much lass sanguine than Paul about this. I think software patents should not be granted, and the European Union's banning of them is the right decision. I hope the Gowers Review in the UK makes this UK law as well.

Graham has engineers disease: he believes that being an accomplished engineer makes him qualified to speak authoritatively on art, law, science, film... He probably caught it from ESR.

Anyway, I heartily recommend you read this fine demolition [idlewords.com] of Graham's opinions on painting [paulgraham.com] before giving this dilletante blowhard any of your copious free time.

I heartily recommend you read Paul Grahams bio:

"He has an AB from Cornell and a PhD in Computer Science from Harvard, and studied painting at RISD and the Accademia di Belle Arti in Florence."
http://www.paulgraham.com/bio.html

He has published many semi-interesting essays in Hackers and Painters: Big Ideas from the Computer Age. I am not sure I fully agree with his ideas on patents. Most of his stuff is fairly pendantic and if you want a sampling, just go read his articles online.

Graham has engineers disease: he believes that being an accomplished engineer makes him qualified to speak authoritatively on art, law, science, film... He probably caught it from ESR.

Anyway, I heartily recommend you read this fine demolition of Graham's opinions on painting before giving this dilletante blowhard any of your copious free time.

http://www.paulgraham.com/submarine.html

What is the technical difference between a line-by-line compile-on-the-fly and interpretation?

I actually have done some of this even in Visual Basic

Then Slashdot is becoming more like a "real" news source every day. It's no secret that news sources get sent articles by PR firms all the time. Lazy reporters will write a story about it. The best article I've seen about "submarine PR" is here.

If by 'beginner' you mean someone who just needs to learn a language to do simple projects for their homework or something, and who has no aspirations of becomming a software engineer or computer scientist, then yes it's probably a decent 'beginner's' language. Lots of free stuff from MS, including their free (for one year) Visual Studio Express IDE's and free (indefinitely) SQL Server 2005 Express edition.

However, if by 'beginner' you mean an aspiring computer scientist or software engineer, then by all means no, it's a terrible beginner's language. In that case, start them out with Assembly, as someone suggested in an earlier thread. Or, if you want them to learn the two fundamental language paradigms, start them with C and LISP (preferably the Scheme dialect for starters). C teaches pointers, LISP/Scheme teaches recursion.

Who knows, indeed? ;)

The article says Oracle compares its US$15G/yr revenue to MySQL's US$30M/yr. But as Paul Graham says, it is OK to shrink a US$30G/yr industry to US$30M/yr, if your absolute share of the new US$30M is bigger than the one on US$30G was. Or in other words, MySQL will laugh to the bank on growing from US$30M, while Oracle will strive to keep their US$15G.

Also, IBM, Oracle and Intel did not make Linux. Richard Stallman created GNU, Linus used GNU and complemented it with Linux, and now IBM, Oracle and Intel help Linus with Linux and RMS with GNU.

I wonder how long will IBM and Oracle continue think they can sell proprietary servers on free platforms, without facing significant competition from free servers too. And how long Intel think they can sell proprietary machines to run free software without facing competition from free (think 'open') hardware? Now they are winning, IBM and Oracle using GNU/Linux to face competition from Microsoft, and Intel to crush proprietary RISC (think they ignoring OpenFirmware); but how long before we are running PostgreSQL (or better yet, Rel) on some OpenCores system booting with OpenFirmware or something the like? Not on the short term, for sure, but eventually maybe it is inevitable, unless DRM forces us into a police state.

The article is obvoius an M$ (or M$ like) funded.

F/OSS is a great oportunity in both higher education and lower education, and Microsoft is beging to seeing a threat from linux especially in poor countries where M$ is starting to no longer be the one and only way.

No matter what they say, but advanced programming can be learned better on an operating system of which sources you have access to.
Otherwise everybody will learn to program using only APIs.

The most important thing in a good education is not having a pointy-haired teacher (and even more important not having a pointy-haired principal).

http://www.paulgraham.com/opensource.html

The focus is different though.

The market for development tools is not what it once was, but I think you've chosen a wise licensing strategy. I doubt I'd know about MySql and Qt if they weren't dual-licensed GPL products. Use the GPL side of things to build product awareness and get contributions, and use the proprietary licensing side to fund your company.

I think you should take a dual approach to marketing, too. Market it as a GPLed open source project: use the internet as a medium to to convice people that your tool is worth their time to investigate and use. Spread the word over the normal channels (mailing lists, newsgroups, blogs, forums, etc). If your tool attracts enough users, you'll get your own community going. Be sure to encourage that--having actual users will spread awareness of your tool and will help you tune it into an even better product.

Since this is also a commercial product, you'll probably need to work the more conventional marketing channels. I don't know what the best way to do that is. Paul Graham, founder of a successful internet startup, speaks highly of PR firms. That might worth looking in to when you reach that point.

Good luck!

Obviously insufficient on the face of it. It's not enough to like what you do. Here is an excellent article on how to do what you love, to save some breath. Paul Graham's "How to Do What You Love". Here's the first paragraph to whet your appetite.

To do something well you have to like it. That idea is not exactly novel. We've got it down to four words: "Do what you love." But it's not enough just to tell people that. Doing what you love is complicated.

Read Paul Graham's Why Nerds are Unpopular for thoughts on the dichotomy between purposefulness and popularity contests. MySpace is set up for popularity contests. Other blogging sites aren't like that.

People with interesting stories to tell often don't have much spare time. The current technology caters to people who want to tweak colors. To attract more writers like Paul Graham ("In a real essay you're writing for yourself. You're thinking out loud."), we need something efficient.

Exactly why I resisted the pressure to abandon Linux for MacOS X on the desktop. It's not Linux with a better UI, it's a proprietary system with candy coating.

And its true colors finally come out.

Will the cool hackers still dig it?

...I have a sneaking suspicion that this story is in some way a submarine. For who in specific, I'm not entirely sure, but a number of organisations are currently keen to start segregating online traffic, including those whose revenues are threatened by VoIP and those who currently sell bandwidth.

Getting people used to such an idea would be the first step. Either way, the talk of segregation has more to do with profiteering than "traffic jams" for consumers. Video content providers won't deliberately outpace the growth of networks that can accommodate them, and most ISPs already offer tiered broadband, so I'd lean towards this particular story being more the anti-VoIP crowd.

And, of course, not forgetting the plug for Itiva at the top of the story, who want to sell people their supposedly new and improved video compression tech.

How much? Beats me. But it does seem that, to find out, you have to kick some dirt, go out there and ask people what they are doing (though even then they may not be particuarly forthcoming). I don't think it is safe to draw any sort of conclusions from sales figures.

But I would say that there's no culture without "riping off".

Indeed--that's what copyright is meant for: creating incitement (in the form on restrictions imposed on publishers) to be creative, such that the humanity (or at least the `USAnity') at large can benefit from the work, being through reading it, performing it publicly, or, in your words, ripping off.

What would be bad for the culture in general would be if Joe Doe can make a living from stealing Bob Kane's or Joss Whedon's ideas without any kind of repercussion, because then there would be no incentive to create something original. The "culture" would die.

Nice way to prove that you don't understand how (at least some) artists think.

Let me give an example: one of my friends has written approximately three seasons of a TV show (aimed at 50 min / ep.). He's probably never going to see a dime for doing it, and it was probably never a motivational factor. Why did he do it? Because he found it entertaing.

Why do I write programs? Because I find it entertaining.

From RMS's bio (stallman.org): My hobbies include [...] puns, science fiction fandom, and programming; I magically get paid for doing the last one.

That's the artist/hacker spirit: we do whatever we do for the fun of it, and consider ourselves lucky to get paid for it. You might want to read http://www.paulgraham.com/gh.html -- esp. the section `More than Money'

Mod me -1 Flamebait if you will; I'm just trying to explain the world the way I see it.

Disclaimer: I have had a real job doing one of the things I like. It was in some sense great, and in some sense not-so-great: it sucked out a lot of my capacity for doing the same thing as a hobby in my spare time, and the job wasn't exciting enough to fulfill my needs. As a consequence of my lukewarm attitude towards the job, I probably didn't do the best job I could have.

http://www.paulgraham.com/submarine.html

Hey slashdot, read it and apply it to this article. In fact, apply it to every other article on /.

Thanks.

http://www.paulgraham.com/submarine.html

Are we really still this naieve?

Windows Vista--so secure that the government requested we install a back door!

Captain, we've got something on sonar. Looks like a submarine.

They say you aren't a real VC until you have lost at least 20 million dollars of your own money.

Except that most VCs don't actually lose their own money, and they get paid even when their investments are not successful. It's quite a racket. Although people tend to write bad things about you.

Programming languages are lot harder to learn than screwdrivers are, so that analogy is not particularly apt. If you're a well-healed business that can afford to hire for the bulk of your tech team CS graduates or the equivalent who are versed in theory and therefore equipped with the intellectual tools to quickly pick up any language, then you should have no problem supporting a diversity of languages and platforms, and could even leverage their various strengths to get something better than a single platform or language might provide. If you can't hire such a tech team, you're probably better off standardizing on something common like .NET or Java.

That might be true, if Vonage was doomed to offer exactly the same service they do today, for the entire life of the company.

Fortunately, Vonage also has a bunch of employees, and (hopefully) are working on other projects.

Joel Spolsky says "the goal is not to solve some specific problem, but to be able to convert money to code through programmers". Paul Graham says "What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people." One of the Zope people described the decision to open-source Zope by saying "This is not the last innovation we'll make".

If you're judging a company by its initial product, you're not judging the company, you're judging the product. Look at the first products of many of today's companies. Few are in business with their first product, or even an updated version of it. (Would you have invested in Ole Kirk's wooden toys?)

If VOIP does take off, there's plenty more than just those two services that they can provide. As a really simple example, suppose you're president of BigCo, and decide that switching to a VOIP phone on 120,000 desks will save you money. Where are you going to find a decent-sized group of engineers with VOIP expertise to pull it off? I can think of a place...

But that's simply a direct application of their skills. Google took a great search engine, and built webmail, a chat system, and great 3d mapping tool. Who'd have guessed?

If you knew their people, you might have. All it takes is people. Their existing technology is just a red herring.

Some people define their life by their job. I have friends like that. They would much rather make less money andwork a lot of hours in order to have interesting work. On the other hand, are people like myself. I see my job as nothing more than a means to an end. While I am fortunate to do something I enjoy (I'm a *nix sysad), I don't particularly care if my work is mentally stimulating. I place a premium on flex time, a 40 hour work week, vacation and being able to leave my work at work. I get my mental stimulation by volunteering as a search and rescue dog handler for the state in which I live. While it's and expensive and time-consuming hobby, it has great rewards. I get to be in the woods with one of my dogs every weekend, I have a highly trained and skilled dog and I'm fascinated by why my dog does what it does and how to train it to have the necessary skills. Plus, I've been able to take my dog training skills and start training my dog's cat (yes, it's my german shepherd's cat). As an added bonus, I get to help people. Additionally, I have time to spend with my friends and family, do work around my house and DJ once a month at local bar. If I made less and/or worked more hours, I wouldn't be able to do a lot of those things.

My point is that there are a myriad of ways to find fulfillment in life that don't revolve around your job. In fact, you're probably better off if you get your fulfillment outside of your job. To most employers, you are nothing but a number, to be laid off when they need to cut head count or you are no longer needed. If you get your fulfillment from something other than work, it is much harder for it to be taken away from you. It sounds like you have a great job aside from it not being interesting. Having been through a number of layoffs due to companies closing offices or going under, I place a high value on job stability. I would suggest staying at your job and saving/investing a good portion of your salary. Since you are young and don't have debt, you're in a great position to let your money work for you. It will pay tremendous benefits down the road: you may be able to retire early and/or you will have the financial freedom to do other things. Staying in your current job because the money and benefits are good is most definitely not selling out. You are simply looking out for your best interests if you stay. Paul Graham's January essay (previously linked to on /.) would be a good read if you haven't already read it. Jobs with benefits/pay like yours are very rare. Don't make the decision lightly.