4 ms·
I remember when I was first learning Java, whacking my head repeatedly against all these sorts of problems - WTF is a JRE vs. a JDK, why is it asking to install
by ewjordan 9y ago
I remember when I was first learning Java, whacking my head repeatedly against all these sorts of problems - WTF is a JRE vs. a JDK, why is it asking to install a browser toolbar, WTF is Eclipse and why doesn't it just let me run the file that I'm working on without going through half an hour of researching "Run configurations" and classpath BS first, etc. It was doable, but as a new person to the whole ecosystem, it was seriously painful to even get to the point where "Hello, world!" would run. Then I tried to get OpenGL working (I wanted to do games), and I probably blew an entire week futzing with configuration just to draw a rectangle on the screen. TBH it was harder than getting the same thing done in C++.
And compiling it all into a Real Executable that would run on Windows like a normal program? Forget about it...not even to get into Web Start, applets, Maven and JavaFX (remember that disaster?), oh my!
Then I discovered Processing, which bundled everything (Java runtimes, libraries, etc.) together in a nice tidy package, and its own IDE where you could just open up the thing, type in some code, and hit the big obvious "Run" button. Want a library? Download it from the nicely curated set that are guaranteed to work! Wanted to create an executable, click "Export", and it just works! All the nastiness of linking native dependencies, bundling the JRE, handling classpaths and linker flags, it was handled once by the devs working on that project, and end users could just focus on code.
Things are getting better with other technologies these days, but it's still rare that I see an environment as zero-config as Processing, apart from web-based Javascript playgrounds. All it takes is a pure focus on usability, which I think is something that as devs we often overlook because once we've gotten over the installation problems that we're familiar with ("well of course brew is better than MacPorts, and you'll need to install nvm and pick the right version before this library will work, except for this one dependency that's only available through RubyGems, and this other one that") we forget that they can be confusing and really off-putting to newbies.
Python environments are particularly bad, IMO because of screwy webs of dependencies that more often than not fail to install cleanly and the Python 2 vs 3 split.
- icebraining 9y agoOn the other hand, Python's "batteries included" means you can go a long way without installing anything. Sometimes I think people forget to look in the stdlib: https://docs.python.org/3/library/index.html https://docs.python.org/3/library/index.html
- wrinkl3 9y ago> Python environments are particularly bad, IMO because of screwy webs of dependencies that more often than not fail to install cleanly and the Python 2 vs 3 split. Which is why Python virtual environments are a thing, and I feel like more people should be taught to use them routinely.
- veddox 9y agoLearning to program just takes a huge amount of frustration-tolerance. Fullstop. It's inherent in the craft and doesn't really ever go away - it's just the problems you face that change. So in that sense, complex setups are perhaps not our biggest problem. Of course, that's no excuse for terrible interfaces. But I dare say there have been easy-to-use and not-so-easy-to-use programming setups in every era...