Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: I can't stand PHP anymore. What else can I choose?
15 points by juliend2 on April 25, 2009 | hide | past | favorite | 83 comments
All my clients use shared hosting such as iWeb.com (which does'nt have Shell access). Mainly because they don't want to pay a lot for a _reliable_ webhost.

My problem is : As a language-snob (i know, it's sad), i'm immensely bored about PHP. I want to learn another back-end language that i can use on my freelance web jobs.

I'm considering learning Perl. But Perl needs modules to extends it's possibilities, this i cannot do without Shell access. And it's also better to run it as fastcgi or mod_perl, things that shared hosting does not always support.

I know Ruby, but hosting Ruby is not cheap enough, or accessible enough for my clients.

Do you guys have any idea of a web stack or shared host that does the job?

What do you do when you can't stand PHP anymore?



Unfortunately, the reality is that PHP is dramatically easier to ship out to crappy shared hosting providers than any other language. Perl, Python, and Ruby are easy if you just use CGI...but they are increasing degrees of slow (with Perl generally being the fastest of the lot and Ruby being the slowest, when used in a pure CGI configuration). Perl is definitely the second most deploy-able language after PHP, due to its historic popularity, but it is still way behind when it comes to "untar the directory and everything just works" style deployment. And it isn't necessarily going to be fast in the types of Perl deployments many shared hosts allow.

Someone suggested Java, which is way out at the farthest end of the "hard to deploy on shared hosting" scale. In fact, I doubt you can find any way to host Java effectively for less than $25/month, and probably more if your app is at all popular. It's just a horrible choice if deployment is a big factor in your decision-making process.

FastCGI is getting easier and easier to get in shared hosting environments, and all of the major web app frameworks in all of the major languages support it (including Catalyst in Perl, Ruby on Rails in Ruby, and Django in Python). Since FastCGI is a better way to run PHP in a shared hosting environment (mod_php has serious security implications), as well, I'd recommend you start insisting on FastCGI support from your host, no matter what language you use for development.

So, I think what folks ought to be recommending is that you go with a host that provides FastCGI and shell access. And then you can decide which language(s) you want to experiment with.


"What do you do when you can't stand PHP anymore?"

Reevaluate what's really important to you.

I love to program, but it's NEVER about the language. I know many of them, and AFAIC they all have their pros and cons. I suppose that if I was a "language-snob", I'd be "immensely bored" too, no matter which language I was using.

So if it's not about the language, then what is it about? You already answered your own question with the first 3 words of your post.

It's about your clients. Always. They have needs far beyond their ability to express them. And they need you.

Stop being a "language-snob" and start being a "solutions-snob". You'll never be bored again. Promise.


He's not being a language snob. It's just plain hard to write good code in languages like Java and PHP. You spend so much time fighting the language and tools that you barely have time to think about solving your client's problems. That gets boring and tedious, so I can understand why the OP is bored.

(The fact that some people have tolerance for this stupidity is not worth arguing about. Some people enjoy digging ditches, too, but the OP is probably not one of them.)

Edit: Ah yes, let the downmods begin. "He said something bad about your favorite language!!"


If you're fighting with PHP to create a webapp, PHP's best demain, then you're doing it the wrong way. I've been writing PHP apps for a few years now, and I contribute to multiple PHP webapp projects, and I'm never fighting the language. PHP is capable of doing just about anything that any other language can do; you just have to work with PHP and stop trying to make it act like Ruby or Python.

PHP has an absolutely enormous library, which makes just about anything possible in a webapp without needing much in the way of external libraries. Templating is a core feature of the language, and with a small bit of planning and a knowledge of how to employ PHP's strengths, you can get a lot done really quickly. Perhaps the biggest stumbling block is inconsistent naming and parameter schemes for the core library, but even that is just a simple lookup in the excellent php.net documentation.

If you're fighting your tools in their strongest domains, you're not using the tools correctly...


I know that PHP brings a lot of good things to the web development arena, but I'm glad I've never had to use it for anything of significance. I've been able to use Python/Django and Python with Google App Engine, and they are delightful to work in. I know I produced a better product for my clients with Python than I could have with PHP. Someone else might have done better with PHP, and that's great for them.


If you're fighting with PHP to create a webapp, PHP's best domain, then you're doing it the wrong way.

"Best" != "Good"

Web apps are no different than any other kind of app, except they take HTTP requests as input and generate HTTP responses as output. PHP does have some features for speaking HTTP, but that's about it. For the rest of the app, you are on your own.

Let's look at the components of a web app, and see what PHP is missing.

The first thing any application needs is a data model, which is divided into a few tasks -- storing and retrieving the data, and doing something useful with that. For the first half, most people use a database, and talk to it with some library. Obviously PHP apps can talk to the database, but the core support (and Pear DB) are abysmal compared to the DB access layers in other languages (see DBI and JDBC, for example). Most apps these days like to use an ORM, as composing queries with the ORM is easier than writing SQL queries manually. I don't know of any good ORMs for PHP, at least not ones as good as DBIx::Class or Hibernate, so that's one impediment to productivity.

Now that you can get data in and out of your app, you need to do something with it. This is where the real programming happens, and you get annoyed by the fact that a == b but b != a, a !== b but a == b (and the associated "type coercions"), and so on. "Programming language features" alone don't make a language usable, but lack of a sane base makes programming quite difficult. (I could go on for hours here; inconsistent naming conventions, arrays implemented as maps, the lack of lexicals, namespaces, macros and closures, and other features that other languages have had for ages, and so on. This is all well-known, and even the newest PHP newbie knows this stuff is insane or missing.)

You'll also want to use OOP, which PHP does provide, but unfortunately, its take on OO is pathetic. It copies Java flaw-for-flaw, and so is missing key features that make writing readable code so easy, like named initargs. (Java is full of WTFs, but this is the biggest one, IMO. I have to manually initialize every class with a method that can only take positional arguments!?) Its object system has no support for features like roles, and the language doesn't give you any room to implement them yourself. So, I hope you like cutting and pasting, because that's the only way you can share code between classes, unless you think inheritance is an acceptable way to share code, that is... The flaws with the object system go on and on. There is a hack around the type system (interfaces), but there is no type system. WTF? There is no MOP. That's fine for an application developer, but it makes it difficult to write modules. (For what a good MOP can do, see the MooseX:: namespace on CPAN. There are some great time-savers in there; things I haven't seen in any other language, like MooseX::Getopt, and MooseX::AttributeHelpers. I can't live without stuff like this.)

Note to language designers: if you are going to copy a language verbatim, never pick Java. People will laugh at you.

So, uh, now you sort of cobbled together some working app code. Hopefully you didn't couple your domain classes to the database too tightly so that you can write some tests. Tests. What tools do you use for that? I see PHPUnit, but that's about it. There is no framework like Test::Builder (for writing Test modules) and Test::Harness for running those tests. That means there is no way to compose test modules or to write tools to process test output generically. At least you can write tests, though, which I suppose is better than writing your application in bourne shell.

Now you have some tested code that's the core of your application, and can worry about the web side of things. Unfortunately, PHP doesn't do that well here either. The first thing you have to deal with is handling requests. Out of the box, a request for a file on disk results in running that file. This means a nightmarish procedure of manually loading your backend classes, instantiating them, and then doing something to handle the request. Hopefully there are web frameworks that abstract this away. (I've seen web frameworks that dispatch requests, which is nice, but they are still not as good as the dispatchers in other languages' web frameworks. Take a look at Catalyst's Chained dispatch type and find that for PHP. The other issue, component loading, is made nearly impossible by PHP's object system. [No introspection and no type system == no dependency injection.] Java worked around this with annotations, but PHP hasn't come up with anything other than "do it manually" yet.)

At this point, you can run some code when a user visits a URL. Now you need to get data from the user somehow. Usually PHP provides all this data in global (erm, "super" global) variables, so you have the data everywhere in your app all at once. (No need to refactor your code to get at external data, it's all global! Great!) This approach is rather unstructured compared to just getting an instance of a class that has all the data you need in it. It is also not introspectable or composable; as an example, consider REST requests. It's like a regular HTTP request, but with some extra meta-information (for example, if it was a JSON request, you will have some "data" which resulted from parsing the JSON). In Catalyst, the usual HTTP request class has a REST role applied to it. I can introspect the instance, see the role, and know that I can call "data" to get that data. I have no idea how you would implement this in PHP. Perhaps a global variable called $HTTP_REQUEST_DATA that has the data in it. That is nice until someone accidentally overwrites it.

Hopefully there is a framework that abstracts this away, so all your app sees is an HTTP request object. I doubt anyone that uses PHP would think of that, though.

Anyway, I digress. If you manage to deal with getting the data out of the request, you still have to do something and return a result. Doing something is easy because of your well-tested backend classes. Returning the result is not that easy. As far as I know, you are own your own for speaking HTTP, with carefully-timed calls to "headers" and "print". (A framework could fix this with a proper response class, so I am not too worried about this.)

Now you just need to turn the data into HTML. This is supposedly what PHP is best at, but it's still not very good. To start with, all tags start with <?php, whereas most other languages separate the code from markup with <% or [%. (You can use <?, but since that's valid XML, you can't necessarily use it in practice.) Generally, the flaws with PHP are the same as with other templating systems -- processing the template can cause side-effects, your designers can't actually program PHP, etc. (I've used Clearsilver with PHP, which is a pretty nice solution to both problems, but you have to recompile PHP to use it. I don't think that's an option for people that use PHP because it's "easy to install".) Even ignoring that, it's still hard to do simple things with PHP's built-in templating, like filtering. As a result, most PHP programmers tend to use something better, like Smarty (which is really not all that good either, but it's better than nothing).

Anyway, as we've seen, PHP is not good for building applications. It's not good for talking to the database, it's not good for building domain objects that interact with your data, it's not good for testing, it's not good for handling web requests, and it's not good for generating HTML. Considering other languages are good for many of these things, it seems like a no-brainer to use one of those instead. You can use PHP, but you can also just wire together some transistors. The ability to do something doesn't mean you should do it.

I think the problem is that PHP is good enough for tiny web pages that need a bit of dynamic content. The low memory footprint and the ease of getting started definitely make it a favorable choice. The problem comes in considering a web application to be a set of web pages. There is a reason why nobody builds non-web applications in PHP. Unfortunately, web applications are more application than web.


I rarely read such grossly misinformed posts on HN. A shame you spent so long on it.


Then enlighten us, please. Exactly what is "grossly misinformed".


The entire thing mostly.


"For the rest of the app, you are on your own."

Did it ever occur to you that some of us prefer it that way?

I really don't mind rolling my own, especially if I'm going to use it thousands of times.

What I do mind is getting "painted into a corner" because the high level tool I'm using never accounted for something I want to do.

Everything I want to do I can do with php. It's stable, popular, and everywhere. It may not be the best, but I don't care. I'd rather spend my extra mental cycles on my customer's problems, not mine.


Facebook isn't tiny.

Delicious isn't tiny.

Digg isn't tiny.

Shit, even my little startup, massify.com isn't tiny.

I think probably the reason that people don't write non-web applications in PHP is because that's not PHP's expressed purpose.

And re: catalyst, that sure is setting the web dev world on fire. /sarcasm


What do you mean by being "solution-snob"? Looking for the appropriate tool(language) for the given task? Thanks in advance.


Just a silly word I made up to fit in with your writing style (which I really like, by the way).

I guess what I'm really trying to say in a general sort of way: as soon as you stop worrying about your problems and focus on your client's problems, you both win.


I'm guessing no, that instead he means thinking more about what you're going to write than about what you're going to write it in.


Learn python. It's an excellent all-round language, you can also create desktop stuff later. Hosts like webfaction just cost $10 a month, surely your clients can afford that.


Try Google App Engine if you want to use python.


Look for webfaction as a hosting provider. It's cheap and you have lots more options than just PHP. Plus you get shell access. You can even set up your own apache instance.

Other than that, don't worry too much about the language. Find something you like and stick to it. Just remember to always learn new things and don't get set in your ways.


++ for web faction. They're really inexpensive, straight forward to use, and you can use Rails, Django, Merb, Pylons, etc... Plus, you get shell access, and you don't have to do a lot of the server admin stuff if you don't want to.


Just remember to always learn new things and don't get set in your ways

I Totally Agree. This is the other reason why i want to change the language in which i code for my day to day jobs. Learning new things.

I read a lot about functional programming and other cool stuff on HN but in my work i'm mostly stuck with PHP... This must change.


+1 for webfaction. they are the cat's pajamas. whatever that means.


If you're comfortable with Linux, an option for you is running a Linode or Slicehost ($20/month) and hosting your clients on it. This will give you total control of the hosting environment, and a residual income. You'll have plenty of horsepower for Rails or whatever else you want to use, and as you grow, you can buy more nodes.

Beware, though: when you put on a system administration hat you're taking on a lot of new responsibilities, including backups and security. It's also a good idea to bring your friends in on it, so if something goes wrong they can look into it for your client if you're away.

So, it really depends on your level of comfort with sys admin stuff, and the kind of relationship you have with your clients. Good luck!


A basic $20/month Slicehost or Linode is probably going to be good enough for 2 "real" applications and maybe a few CGI pages, but not much more. The limiting factor is memory -- modern languages like to use a lot of it.


Remember the 80/20 rule. Most of the sites only have a couple of clicks per day. Right now we have around 15 sites and two rather heavy apps on a 512 slice. We always intended to upgrade it, but it turned out not to be the case. On a 256 slice we had all the sites confortably.

As for the few sites which get a lot of traffic... they should also generate a bit more income and an upgraded slice.


Yes, this is something i thought about also. It can be good when they dont already have their own server already set up with their email, etc. I have tried both slicehost and linode. Its nice to have such control when its possible.


You might want to have a look at haXe - a language that compiles to multiple backends including PHP, Javascript and Flash. It's not my favorite language by a long shot, but it's not PHP.


I think that it's Exactly what i was looking for! Thanks a lot. I will definitely look at it! :)


Delivering work for paying clients in a vanity language because you're bored of PHP sounds pretty close to malpractice.


It does, but using haXe based on its merits isn't. It's not hard to find good reasons to avoid PHP as an implementation language; PHP is popular mostly because it's as easy platform for deployment. If a superior language[0] allows targeting that platform, it's a win-win situation. The obvious counterargument is that it makes finding developers harder, but I don't think that's the case. The Python Paradox applies here, and there are likely dozens of developers available who would jump at the chance to get paid to use haXe.

[0] I am not, at this point arguing that haXe is a better language than PHP. I don't have enough experience with haXe to make that claim, but it's not an especially high bar to clear.


We don't have to get into a debate about PHP (I don't use it either); its virtue in this scenario is that after this guy gives up on the client, someone else can easily step in and pick up the project, because everybody knows PHP.


I think the degree to which this works depends on the sophistication of the code. If it's a simple form handler, then sure, it's an advantage to be using a language that millions of people know. If it's more sophisticated, it may actually be a disadvantage; the non-technical client has to sort through hundreds of responses to a job posting with no useful means of telling applicants apart. A language like haXe currently only attracts those who are genuinely interested in better languages. Such people tend to be decent programmers, so any of the 5 or so people who respond is likely to be a good choice.


Not really. If you don't like working with a particular tool, any work that you do with that tool will be fundamentally substandard. So if the same results could be achieved with a better tool, then your work should also be better.


First, the difference between professionals and amateurs is that professionals stand behind their work even when they don't enjoy doing it.

But that's neither here nor there. If you can't stand behind doing work in a mainstream language, don't take those jobs, and accept that you're going to earn a fraction of what your peers do.

However, when you deliver product to people in a language nobody else uses, and implicitly recommend they deploy code in that language, and you do it because you're bored with PHP, and you pick the language you move to deliberately to mask the costs of using a less popular language by compiling it down to PHP, you're coming pretty close to screwing over your clients.

Happy to be wrong about this, though. I'll stop here.


You're absolutely right. Something may be wrong with me but i still do find it interesting.


Malpractice (from http://en.wikipedia.org/wiki/Malpractice):

> In law, malpractice is a type of negligence in which the > misfeasance, malfeasance or nonfeasance of a professional, > under a duty to act, fails to follow generally accepted > professional standards, and that breach of duty is the > proximate cause of injury to a plaintiff who suffers damages.

Using another language is not failure to follow generally accepted professional standards, and I doubt using another language can result in damages to the client. Please don't use technical (legal) terms if you don't mean it.

(Also, HaXe is not a vanity language, unless you like the rest of us calling your favorite language a vanity language too: "Pshaw! It just compiles to ASM!")


Is Ruby hosting that expensive? I've seen hosters that do it under five bucks a month (like http://www.hostingrails.com/ ).


http://railsplayground.com/

Developer hosting from $5/month. Much better uptime than others in this price range. Have had some small sites with them for several years.


Thanks for the info. I did not know about hostingrails.


http://www.bluehost.com

I personally use it for PHP, but it supports Ruby/RoR, it's cheap, and I've never had any problems with it.


I don't think you should dismiss a language so fast for hosting reasons. Yes, they are a thing to consider, but "The Thing"?

We offer all our clients hosting on our slicehost server, for at least a year free (so far we haven't bothered to ask after a year either). It's clean, fast, cheap, and lets you do development and updates much faster. No system administration to speak of (long live apt-get).


Prices for hosting Ruby should fall once mod_rails sees more widespread usage.


Python + Google App Engine


After switching to this combo, I find myself reluctant to continue work on my apps still using PHP & MySQL. They feel somehow... fragile now. Before I used to check on my servers all the time, now I feel peace of mind that my app is still running, even though I haven't checked on it for a while. I feel like I might even be able to enjoy my coming vacation.


Java! I may be in the distinct minority here and particularly prejudiced since I started with Java in 98.... Java has the best IDE (eclipse), a slew of open source libraries, Groovy if you have it up for dynamic language syntax and with JIT etc. innovations it's pretty much as fast as C++. I think Java is the perfect OOP trapped inside some slightly ugly, easy to compensate for syntax. Also, easy to deploy dynamic apps with Tomcat, great user community, stable API...


perl:

You do not need shell access to install modules locally. Anything you can do from the shell, you can do from Perl with system(), backticks, or piped open(), but really... no shell access?

You want hosting that is reliable, supports shell access, rails, and 100% uptime, but your not willing to pay more than $5/month ?


i completely get your point. unfortunately i dont choose my webhosts. my clients does. but when i can, i tell them to take a linode slice.


Dreamhost is cheap and has shell, perl, ruby, and php.


Yes i tried them. That's why i mentioned "_reliable_ webhost" ;) . But yes, some websites could be hosted with them, it's just not good enough when we need something to be 100% uptime.


Plus, using things other than PHP is still pretty difficult with dreamhost.


It is? Here's a python CGI script:

http://juliusdavies.ca/svn/viewvc.cgi/not-yet-commons-ssl/

The viewvc.cgi starts with:

#!/usr/bin/env python

I just dropped the script into my ~/juliusdavies.ca/svn/ dreamhost directory. Didn't seem hard to me.


Well yeah. For a plain old CGI script it's not terribly difficult. But that just doesn't scale well nor is the script easy to write. Consider the instructions for setting up django on the other hand: http://wiki.dreamhost.com/Django

This is much more complicated than it needs to be. Especially when I can just log into my account with webfaction, click "install django application" and be done with it.


Python and Django!


seriously - this.

Django allows you to do far more with less code, and python is the finest language in which to code ( :) ).

I've advised loads of people to switch from php to django - and have had no complaints yet.


What framework are you using for your PHP work? If you aren't using a framework (because your work doesn't need one), then switching languages probably isn't going to change much, but if you are, there are several good, fun PHP frameworks out there. The best PHP framework I've used is Symfony (http://www.symfony-project.org/), which is actively developed, fun to work with, and really powerful.


I've worked in CodeIgniter, but these days I find myself using the Zend Framework (http://framework.zend.com/). They're actively developing it, and it has so much built-in functionality that I've been able to get stuff done much faster than before.


I use mainly CodeIgniter. I tried CakePHP. I heard about symfony, though. If it's fun then i will take a look. Thanks.


Why not setup your own hosting for your clients? Problems always arise when you give the client options on the server. They do not know these things. Usually they always opt to have the cheaper plan -- they are not technical people.

I have been using PHP for years now - no problems so far. Especially when Zend Framework came.


Your options are limitless, really but here are a few:

1. Pick a framework to make your PHP work less boring (CakePHP, CodeIgniter, Symfony)

2. Ruby on Rails or Python & Django

3. Slicehost ftw.

These days you can find a cheap host for just about anything except the Microsoft stack and even that you can get for a reasonable price.

If your clients are that cheap, get new clients.


I don't know whether you'd need shell access for Python (I'm only just starting to learn it myself) but that could be an idea to consider.


Using Python would have the same problems as using Perl, wouldn't it?


Not necessarily. You just need to put whatever libraries somewhere on your python path.


That's identical to Perl or pretty much any other dynamic language. Just as in Python, you can even modify your library path within the code itself, and use relative paths (so you can distribute apps in a directory and not require the end user to modify their webserver CGI shell execution environment).

e.g. something like:

    BEGIN { push(@INC, "./lib"); };


http://heroku.com isn't that expensive and it's easy to scale as needed.


Heroku is great (and free) for building and trying Ruby on Rails apps.


With such approach you will hate your next lang in no time.


Asp.net MVC


In my experience Windows hosting (I'm aware of a Linux-compatible version of ASP.net, don't know how good it is might even be for classic ASP) is a bit more expensive than Linux hosting (which is typically used for PHP - for compatibility and cost reasonings).


What is the motivation for locking yourself into the micro$oft stack? Why not use Java with a javascript (jquery/yui/ext etc) front end or even (shudder) JSPs? Spring framework? Anything but .net lock in...


Can we grow up and stop using $ when referring to Microsoft?Most of us here are in business to make money, but no one is calling this site Hacker New$.

Now in regards to lock in. How is it different from any other stack? If I build something with ASP.NET MVC (which has the source available under the MS permissive license) I can run it on Windows or any machine running Mono.


The difference is that microsoft deliberately enacted a monopoly and did dozens of highly questionable things just for the sake of profit. Just think about a company where the policy is, write code that is as inefficient as you like because hardware will catch up oh and btw we are in bed with intel...


You started a flame war over vendor lock in? What about language lock in? DBMS lock in? Or even the forbidden OS lock in?

I don't care what you use, it has lock in of some kind. Get over it. VS2008, C#/VB.NET, ASP,NET, MSSQL are great tools. That's all these things are: tools. The end product is always the same. If you build something with Ruby you can't go back and fix it with PHP. Lock in? Yep.


The point is you are locking yourself into a brand that has explicitly anti-competitive business practices, charges exorbitant rates for their licenses and not only shuns public standards but actively works to sabotage them! (ecmascript3 being the example I am thinking of the last) VS2008 is a tool, C# is a language. Locking yourself to C# (for all intents and purposes) locks you to development on a windows box using VS2008 and commits you to serious trouble deploying under linux or mac, most times. Is that the same as choosing Java or Ruby and vi vs emacs? No, no it is not.


To each their own. I just think that you should use the right tool for the job, not the most popular one. If your opinion comes into play when selecting a tool, you're doing it wrong.

Sure, there's lock in and perhaps Microsoft is engaged in anti-competitive practices. They are a business, after all. But what is wrong with the tools? Visual Studio, C#, VB.NET, IIS? Point out some real issues like the current state of ASP.NET's AJAX toolkit or linq2sql's inability to do perform joins efficiently without an associated view.

I might be playing devil's advocate here, so please don't take me the wrong way. I just want people to look at their tool box more closely and make decisions on real, measurable things.

Disclaimer: I work on everything from ColdFusion, PHP and ASP.NET to Perl, cmd and shell scripts. I have no zealotry in me except for an extreme love of Adobe Flex, Adobe AIR, Macs and the opposite sex.


That IS a real issue, vs the (relatively) open nature of Java and the absolute openness of tomcat, apache? I personally think that open source tools are inherently superior because it of the additional eyes on the code reducing screwups and deliberately bad code. One very serious issue is that their anti-competitive acts make them opposed to standards (e.g. their work on the EcmaScript3 standard and what would have been a great harmonization of AS4 and JS2!) and it's better to work with standards for obvious reasons... Being involved with open source, standards compliant tools gives you an awful lot of advantages.


The tools.

Spend a week writing C# in Visual Studio.NET with ReSharper installed, then try to go back to your old language and IDE. You'll understand.


I spent a year writing C# in Visual Studio and ReSharper, and it is nice, but I'm happier now doing Python with Emacs and the command line.


You are the exception rather than the rule. I love VS even without ReSharper. I haven't found a better IDE than VS.


I've never used those but how can it be so much better than eclipse + all the commercial plugins? Closed source can never beat open source in the end...


I spend more time than I'd like in Eclipse these days, and am consistently underwhelmed. It just can't hang with the intellisense features of VS.NET.

I spend entirely too much time in Eclipse hitting ctrl+space and getting nothing back. Often even when the thing I'm looking for is in the same file, let alone included thru an import. ReSharper will find references for things I haven't even imported. It really is that much better.

Oh, and VS.NET does have open source and commercial plugins (of which ReSharper is a good example.) It's every bit as open as Eclipse as far as extensibility is concerned.

In general, I find it's best when offering comparisons of two products to have actually used both products. That is the basis by which I consider VS.NET to be superior to Eclipse. I'd suggest you try them both before making up your mind for good.


I don't see any compelling reason to switch off of Java for the VS stack... maybe if I end up needing to do consulting, I will learn these. I'd probably have to buy a windows license first :( One point I'd like to make is that eclipse is based on an open standard (OSGi) and having worked at a company that features an eclipse plugin, having the eclipse code open source is damn useful.


i use newlisp for my web apps


Java?


Become a real solutions provider and lease a colocated server and move your clients to it by offering them competitive pricing. You might even make a profit.


CGI, then use what you like. A few of my friends are building http://werc.cat-v.org/ but it's teaching me CGI still has a lot to offer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: