5 ms·
I'll talk about the setup and configuration part. I mean this has been talked about to death but people still don't get it. And lately I'm starting to fear that
by kaitnieks 17y ago
I'll talk about the setup and configuration part. I mean this has been talked about to death but people still don't get it. And lately I'm starting to fear that maybe some people like it.
This is especially visible when trying out various new programming languages. I have written exactly one .NET application in my life and I absolutely loved it that I could just downl... I mean buy the Visual Studio, install it and start coding, debugging and deploying the application. The same story with Delphi.
A very different story is about Python, Haskell and all things Java related. You need to download compilator, then you need to find and download IDE separately, then you need to figure out how to make it work with the debugger, if you're lucky enough to get it working at all. It takes time and effort that doesn't benefit me. It's all reading instructions, changing paths in configuration files and setting environment variables.
And the reason why this is done so is because as I mentioned some people absolutely love the idea that they can use any tools in any configuration that somehow after some effort work together. And people who like to tinker are the people who write open source. So there.
Also making good product = fun, making good setup = boring.
- mullr 17y agoBut there's a catch, isn't there? There's always a catch. At work (Big Company TM), we call it the "MS Happy Path." If you're on it, you're golden and life is good. The overall development experience is great. If you're not, well, sucks to be you. With the other choices you probably have a way out. Even if there's no scaffolding for you, you can at least implement something yourself. Granted it takes more time up front, but it pays off when your priorities vary from those of your tool vendor's. We've made lots of choices explicitly for the purpose of staying on the MS Happy Path, since we knew it would make our life easier. Not because they were the best solution to the problem.
- joe_the_user 17y agoWow, This is the first time I've heard anyone else describe the happy-path phenomena, yet I previously talked about it any time anyone ever asked about the goodness of MS software. I'd also mention that the Happy Path is also a verbose path. I recently looked at a C# application and a C++ application that each did about the same thing. I was amazed to find the C# app had least ten times the source code. Moreover, the C# app seemed to be coded in the proper C# way and worked generally well. The main thing is that the problems that it did have (memory leaks) were utterly, irrevocably, totally, completely unsolvable... So there are trade-offs in all these things that are very "unobvious"...
- kiba 17y agoI never have to messed with that. I just sudo pacman -S your-intrepreter-package here. I never have to download a dedicated IDE for the language. I just grabbed emacs and go along with that. I never have to change configuration files and setting environment for each language. I never use a debugger, just old fashion println. Yet, I lived in the world of open source.
- deleted 17y ago[deleted]
- silentbicycle 17y agoYou missed the part about deployment, though. Most users aren't going to install Python (or whatever) for you, and that complicates things.
- kiba 17y agoYou can make a window executable with py2exe. http://py2exe.org http://py2exe.org Really, everything is going to be pain on window in comparsion to Linux. Since linux was orginally made for programmers by programmers, life is going to be a piece of cake.
- silentbicycle 17y agoAh, yes, sunshine and lollipops. Like configuring sendmail. :) I use (and really like) OpenBSD, actually, but the point that the article is trying to make is that while open-source users usually tolerate a fair amount of configuration, spotty documentation, etc., those problems can sit ignored in plain view, and people trying out open source stuff may get the first impression that it's incredibly rickety. (And in some cases, they're probably right.) Tedious detail-work such as setting up a smooth installer is very important, particularly for people who aren't themselves programmers.
- kiba 17y agoI am not sure what is your point. The fact that tedious work is left around is in fact due to the lack of incentives for open source developers, not any instristic structure of open source itself. Lot of them are non-profit, so of course they don't even try that hard. What do you expect, hard core ass kicking software? Sometime, you will find hard core ass kicking software. I still remember fanastic open source games like battle for wesnoth that are easy to install on window, and even more so on linux with pacman or apt-get. It look like it can compete with any reasonable indie game.
- rbanffy 17y agoOh... The simple life of those who choose to have no choice... You just download the official tool set and program in the official languages against the official APIs. As for the Java-related stuff, installing NetBeans is pretty much a no-brainer. It even comes with its own Java runtimes, if you want it to. And it can work with Java, PHP and Ruby. From phone apps to server apps running on those 1000-core Azul beasts. That's a range Windows can't touch. Eclipse is a little harder to download (there is a bewildering amount of options) but it's one impressive tool stack and rightfully deserves that compliment people traditionally reserve to Emacs: it's a great operating system, lacking only a decent IDE. To put it in other way, do you really want to hire a programmer who can't understand/install/adapt/make his own tools? It takes me about 15 minutes to be functional with any *nix box, given a decent network connection. With Windows, I need a little more time, but Cygwin is my friend.
- jfarmer 17y agoMy experience was the opposite. I started programming with C and Perl. How are you supposed to do that on Windows? Setting up the system to be able to run compiler commands from the command line is very hard on Windows. On Mac/Linux/UNIX you get that all for free, out of the box, and every tutorial on the web makes sense. With MS it's always some crazy proprietary thing that is hard to find good documentation for (at least it was ~10 years ago, when I was starting to program). I never got serious about programming until I switched to Linux (I use a Mac, now) because it was just too hard to get started on Windows.
- joe_the_user 17y agoI've done lots of windows command line programming, mostly in Ruby but some Perl . That was in the last 2-4 years, so it has gotten better but I also did Python programming seven years ago and it wasn't hard at all. Scite is free and more or less the same on all platforms. Windows C++ command line programming is a bit of a pain but it's just the same setting-your-configuration-pain-in-the-neck that everyone is complaining about Linux having. I can navigate files with vi but has always been the least intuitive system I could imagine, like brainfuck but not a joke.
- jfarmer 17y agoSure, but were you learning how to program? At the time I didn't know what a compiler was, let alone the nuts and bolts of installing one and getting it running. I was a self-taught 15-year-old and the only one in my hometown interested in this stuff. Making that happen on Windows was very difficult, IMO. I remember using something called LCC-Win32? Moving to *ix made a world of difference for me from a programming and sysadmin perspective. Everything works "out of the box" and the space is less fragmented because everyone uses gcc/g++. There are a million tutorials explaining step-by-step how to write a C/C++ program and compile it. Installing a printer on the other hand... :)
- joe_the_user 17y agoFor command-line workability, I suppose there have been many levels of problems in the nix and the PC world. Going way back to when I was learning to program, I couldn't get Unix working at all. The folks at the college who understood it loved to make that understanding a mark of their superior condition rather than helping in any way. This was well before Linux. Unix terminal configuration is pretty much the most screwed-up, evil thing in the world. At the college where I was learning to program, most of the terminals were irrevocably mis-configured at the server level (or at least some level we had no control over) but the admins pretended it was the student's fault. And the present screwed-up configuration of the various flavors of desktop Linux can be traced to their support of the various archaic terminal flavors as a default. And it really shouldn't be assumed that Unix was step forward from UI's that existed in the really old systems. I learned my hatred of vi from a truly old school programmer who went back to far before Unix existed and could verify that there was no excuse for it's pathological absurdity - it wasn't a "step forward" from the editors that existed before - rather, it's popularity has to do with accidents of markets and college sysadmin culture. Here DOS (not Windows) was great. I just got a simple compiler and did a did of command-line stuff. The Borland c++ ide was great back in that day...