It works well and I feel like I understand the basics, but pipenv, pyenv, pip etc. seem needlessly complex. Especially when I'm trying to create a serverless framework package, or upload a zip to AWS Lambda. Never know what tool to use to install packages, or how to specify the python version... or even change the python version on my Mac. Homebrew Python, system python, virtualenv?
Would love it if I could find one simple way to do all of this, but always seem to run into issues and have to use another method.
How do the professionals do it? Do you know if any good guides?
Npm let you install packages minutes after being installed, and they went right into a folder right there, and they didn't conflict with any other packages on your system.
I was like you and played with python for years but never anything larger than small scripts, and every time I went to do "real" python I'd hit a wall where you were.
npm was just so easy, so simple, so fast that it won me over. And it was years before I ever setup a virtualenv, and even then I'm still at this point not entirely sure how it works and what it's doing despite having published a pip package.
Usually, for me, I start by installing node. Ok, so I guess I need to install npm now. No problem, I guess that's like pip. Oh, I need yarn. It's better? Ok, I guess python had the same growing pains with easy_install. Oh, looks like when I installed npm I used sudo, so now I need to fix file permissions burried somewhere in my file system. Okay, I guess. At least when I get this running things will be a little better.
Oh, I need bundler? I guess that makes sense. Gotta configure a build system. Programing languages need build systems if you are creating distributable assets. Makes sense so far.
Oh, I guess I should have used webpack. Okay, lessons learned. I guess since I am using ES6 features I need something called babel too. Cute name for a transpiler, btw.
Oh no, I guess that 4 month old tutorial I followed that showed me how to set up babel with webpack used the old plug-in names. They are different now. Thats interesting. Gotta move fast, tho. I guess...
Huh, it still isn't working. The 6 different config files all look right. Oh, wow. Turns out that the behavior is different if I wrote the config files in json vs yaml vs pure js. Guess I gotta rewrite them in pure js to get at the real shit.
Okay, seems like I got all that mess sorted out. Let's add a few libraries to my packages manifest...
Huh, the docker containers are taking an awful long time to build suddenly, I wonder why that -- WHY THE FUCK IS node_modules 7.5GB and contains 82000 files, aghhhhgh?!?!
(I kid, I kid. But not really)
I guess a lot of that is just cultural differences between js and python communities, but as someone who considers themselves a reasonably competent programmer, trying to get onboard just seems like too much.
Contrast that with something like Rust, which I have also been trying to learn. Rust is positively delightful by comparison. I spent a cumulative total of 15 mins getting an environment set up. Which means I get more time to actually learn how to work with the language itself, instead of setting up tooling.
Maybe it will sort itself out a little as the node community matures and settles on what the right way to do things is, but for now, it's so much work to even get started.
And npm is always installed alongside Node.js which I suggest installing by nvm. I guess this depends a lot on the level of assistance you can get with the installation process. Using sudo is almost always a dumb idea for installing anything.
I admit frontend development with JS/TS is tricky business that I myself also abhor at times. When everything works it's fine but when it doesn't well. I'll be pulling my hair for a while, then trying to Google the issue which often works btw. The one of the biggest perks of a big ecosystem (with many beginner programmers) is that there is plenty of help for almost any problem.
Once you get past your guttural "Node.js/JS sucks because of this and this" I find it to be (with TypeScript) a productive and fairly simple ecosystem. I haven't noticed big of a problem with newbie programmers starting to learn Node.js once you give them good enough tutoring. Webpack is not something you want to introduce them to for a long time (unless necessary) and yeah, it's a pain in the ass.
I still remember my first attempt, years ago. I shopped around for front-end frameworks, and picked Ember, which was in vogue then. I proceeded to create a default "hello world" with ember-cli, only to discover the newly generated project had ~70k files in 150k folders. I bailed out immediately and went back to jQuery.
The situation in Node-land is much improved now, but I'm still uncomfortable with so many moving parts you have there, all constantly changing, which can - and do frequently - break at any moment. And just when I think I finally have things under control, my professional front-end developer friend comes out and says, "no no no, you're doing it wrong; throw out library X and use Y instead, add webpack, and while you're at it, use Yarn, and here you have this config which adds a newest linter...".
Like, I realize that these "you need so many things!!1!" narratives are popular ways to complain about JS, but if you're adding random junk to your project without a clear reason for it, that's really your responsibility and yours alone.
i, as a person that writes backend for 3-4 months and then need to do frontend hate the constant changing.
However, if you or someone else is reading this and thinking, "well, that's just what I'll have to deal with to get started in JS", heck with that crap. There is a huge portion of the community that pushes people in this direction, and you don't need to go in that direction. You should ignore them.
If you're running your code within the browser, then first take a step back and ask yourself if you even need npm or node. Remember, all Node does is give you the ability to run JS code with access to your filesystem/native processes. I hand-code sites all the time, because it's fast. You don't have a build step, you use the built in browser dev tools to debug, and you just hit F5 and see your changes instantly.
You can do TDD from a browser without installing Node. It's pretty easy actually, you don't even need a testing framework. Make a separate page that includes one script with all of your tests. The only big concern is importing headers into multiple files, but remember that you can always just fall back on the Linux commands that you already know:
rm -r ./public && mkdir ./public && cp -a ./site/. ./public
find ./public -type f -name '*.html' -exec sed -i '/<!--importheader-->/r ./templates/header.html' {} \;
Okay, so say you really want to do a build step. You're want to write SASS instead of CSS or something. First, there are command line compilers for SASS that don't require you to install Node or npm. Remember, all that Node does is it gives you the ability to run JS in your native environment. But let's say that really want to use Node for this, or let's say you're explicitly trying to build a Node application.
Install nvm[0]. This will handle setting up node and npm and all of the linking and whatever; especially on systems like Ubuntu, it's just better than using the package manager and linking everything yourself. Do not worry about yarn, it is not appreciably better unless you're working with a massive number of packages. Don't work with a massive number of packages.
If you're here because you just want to write a Node app and not because you're building a build tool, then don't install a build system. You don't need one. Most of the modern ES6 features are available in most modern versions of Node, and you can set a lower limit for what you support if you're planning on mass-distributing what you make. Remember, if this becomes a problem later, you can add Babel then. Transpilation won't require you to rewrite your entire codebase. You don't have to care about this until after it becomes a problem.
When testing or building your code, consider using a low level tool that shows you what's happening, or writing your own. It doesn't even need to be JS. I have, in the past, done bundling by literally just concatenating files together. I have also built HTML template systems in Node that were literally just a file read, a few regex expressions, and then a file write. Ask yourself, "what does this tool actually need to do?" Some of the biggest tools in JS are built on concepts that are actually not all that complicated to understand or replicate.
This seems like a very extreme perspective, but the modern JS ecosystem is based around, "We're going to build a bunch of high-level tools so that nobody has to think about the underlying mechanics of any of this." The problem with that mentality is that the high level tools change all the time, and when they do change, all of the experience you have with the old API is useless. So you end up with a bunch of opinion pieces being written about how everybody needs to switch to this tool or that tool, and new users who have no context to figure out which ones are important.
Tools are important, I like them. I use them. But I only add them when I have need. When I start a new node project, I don't install anything. At most, if I'm doing TDD, I install a very small, minimal testing framework that doesn't come with any special config files or anything. Then later on, I start looking at tools when I have a specific, well-defined problem that I need solved.
What you have to understand is that JS is very flexible, and because your build tools and IDEs and whatever are all written in JS, the temptation is always there to say, "I'm going to build some type of meta-system on top of this other meta-system because I don't like this specific thing." That's not necessarily bad, but it is very hard to avoid that mentality, and it means that large swaths of the online community think that an introduction to testing means, "here's how you install Mocha", and not, "let's learn how test runners actually work." So it's completely understandable why people feel overwhelmed, but the good news is that it's possible to ignore those people and actually just write Javascript, and in the long run doing so will make you a better developer because you'll spend less time trying to figure out what the flavor of the week tool is.
I love the JS community, but I dislike this aspect of it. I wish we spent more time questioning some of the tools we use.
In fact, I would have a lot of the same opinions about getting a python project started as has been voiced in many of the comments here regarding node. I would say "Don't worry about things like conda, virtualenvwrapper, etc. You just need to create a new venv for each project, activate it, and use pip to install any packages you need"
But I'll acknowledge that sometimes you need to do something a little outside the norm and it starts to make sense to rope in some other tools.
So when I talk about Javascript being accessible, I'm talking about this perfect world where you don't have all these people constantly telling you that you're doing it wrong, and where you're coming at it from the perspective of, "a tool should just automate something that I already roughly know how to do and don't want to repeat over and over." I'm thinking about this almost fictional world of Javascript where you can clone a Github project and the ratio of config files to source code is relatively small.
Again, it's not a criticism of anyone who feels overwhelmed or wants to acknowledge that it's a problem, because it is a problem. I just want to take every opportunity I can to point at it and say, "you don't have to do this, the insane setup is a cultural thing, not a tech thing". And that's not to put anyone down who uses those libraries or to make them feel like they're doing it wrong -- it's just to push in the opposite direction of that cultural pressure.
NPM land is the only place I really have to be wary about package versions, because otherwise, even when following 6-months old tutorials you'll end up with nothing working due to breaking changes between library versions. And there are just so many dependencies to keep track of...
Though I have to say, CPAN was much better organized and documented...
One nifty trick is using the (built-in) subprocess modules to exec some other tool, like rsync or ssh. I recently had sufficient motivation to remove a dependency on the "awscli" package from my deploy system, and implemented an aws api request signing function in about 50 lines of python3.5 using only the standard library. (For bootstrap convenience, my deploy system depends only python3.5 and some standard cli utilities.)
For some non-trivial web services, I use tornado. Running under python3, it depends on nothing else, and can take you very far. (Running under python2.7 it has 4 small dependencies.)
Never did anything huge with it though. Just small web apps hosted on pythonanywhere.
Beginners? I've been in the industry for a decade and the same applies to me. The Python environment situation is a trainwreck.
I don't see this often. Could you point out some syntax or concepts that aren't clear, in Python?
Definitely true. Getting Python to run correctly is not only one of the hardest parts of learning to code, but comes right at the beginning so before people have experienced any success. It's gotten less bad in the last year or so thanks to pipenv, but it's still not a great situation.
This is a surreal statement to read as someone who basically just writes and runs nearly pure Python in a text editor.
Go help out at meetups for Python beginners and you'll see what I mean.
>Cloud-computing is one of the most significant paradigm shifts in our industry, yet it remains commandable only by relatively few professionals. It's similar to when, prior to microcomputers, only big corporations and universities had mainframes. We want Repl.it to be the microcomputer to the cloud's mainframe.
It’s still pretty easy to run default Python prompt in MacOS (as long as you know what the terminal is). But it gets complex really fast the moment you want to use a cool library. Which is probably a few minutes into your coding tutorial.
With Repl.it we're working on what we're calling a "universal package manager", a common abstraction on top of the various language package managers. It also has a visual interface which generates a requirements.txt/package.json/etc for you.
This is one of the most frustrating parts of learning ANY language. The assumed knowledge and supposed "here's a quick start guide" actually starts on step 8.
Don't assume the beginner knows what docker is.
Don't assume the beginner knows what a shell is.
I've tried to learn 3-4 languages or frameworks over the years, and I have only a vague idea of how to move between directories in the command prompt. Nevermind where I should download or extract files.
I've found people's attitude when I tell them this is dismissive. But I sold a business for 6 figures last year that was parimarily automation scripts in PHP. Figure that one out.
This is something I've tried to tell my teams over the years... There is no direct correlation between technical complexity and business value!
Some problems require complex engineering to be solved, but value and even durability do not come from technical excellence for 99.99% of businesses... Of course as a software developer I prefer to walk pristine halls of cutting edge software with perfect tests but the businesses I've sold/run have numbed me to the idea that fancy code makes the big bucks...
It's ok that you don't know what docker is.
It's ok that you don't know what a shell is.
What exactly is the nature of the dismissive attitude from others that has held you back from learning? Perhaps these are real opinions, but consider the source. If they are smarter than they are rude, and their opinions hold value, maybe suck it up and learn something. If it's not worth it to you, ignore them and walk away. Regardless, don't let other people's feelings hold you back from learning. And don't let other people's feelings about you dictate your feelings about yourself.
On the other hand, perhaps these attitudes are partly a projection of your own feelings. Use it as motivation to learn the things that you feel like you should know.
That shit is discouraging and the annoying thing--coming from some who first wrote a Tetris clone a decade ago--is that it's recent. A decade ago you just downloaded a library and put it in the folder you were writing in. Now while that still probably works library how-tos have all either gotten complicated or assume you've already complicated that shit.
And you run software by downloading a .zip, unpacking it and executing the program in that folder.
I miss the times when both development and use was that simple. And it was what, like 10 years ago?
I was more trying to make a point that if you're writing a guide or tutorial, actually start from the beginning.
Part of learning to learn is learning to keep going through things even when you don't fully understand.
I'd be keen to learn more, can I reach out? I'm not really looking for guidance or ideas to do the same, I just genuinely enjoy reading these kinds of stories-like a weird Reader's Digest sort of thing but for entrepreneurs.
1. Install docker using Apt or Yum 1a. So for CentOS i had to download and run a script on my machine to add the repository and install. 1b. Setup autostart of the service 1c. Configure my user so i can manage docker without sudo.
Then once its installed: 2a. Lookup the correct flags to use 2b. Find the correct image to run 2c. Learn how to map a local folder for persistence 2d. Learn how to open ports for the program to be accessible.
As a system administrator with 15+ years of experience, this is easy for me. But if I where to ask someone without any system experience to do this, I can for-see a lot of frustrating moments where they would give up.
Im sure that VMs have been tested and done as well, bringing their own different issues. We could add another layer of abstraction, like some type of orchestration tool, but then that needs to be supported and there will still be issues with the system underneath.
Maybe stat with something like lambda in AWS using their cloud9 instance as an IDE? It will cost a few $ but might help with the basics. However, this would only be good for very limited learning, so maybe add a small sysadmin crash course after that?
So maybe schedule it similar to this:
Basics: 10 days of coding in lambda using dynodb etc.
Systems: 2 days of devops using python to setup and control the environment
Rest of the course ....
Wish php was better, it only outputs to the console.
No SQL. :(
No debugger.
On Windows, just install WinPython or Thonny and you are good to go.
The last thing you want new users to run into are issues where odd interrelations between your “editor” and the runtime cause problems that google can only find issue descriptions about.
> Beginners can do useful and interesting things and solve real problems after a few hours of learning.
What real problems are beginners actually solving? I literally cannot think of a single one.
Most introductory programming tutorials I've seen start off with very straightforward instructions to setting up a basic environment - and this is actually useful in the long run. vs programming in some special editor abstracted away from the real world.
That being said online repls are useful for writing quick code for e.g. testing something out.
There is but not as the first thing you do. Even I still get frustrated with setting up new dev envs for new (to me) languages. I'd much prefer to just try it out first and then figure out the plumbing later.
>What real problems are beginners actually solving? I literally cannot think of a single one.
That's a very elitist take. Firstly they are solving their own very real problem of not knowing how to code. Second they could have a very specific problem they want to solve that can only be solved by code.
>Most introductory programming tutorials I've seen start off with very straightforward instructions to setting up a basic environment - and this is actually useful in the long run.
It's true but what is also true is that there will almost always be version changes and OS specific changes that break the instructions in small but material ways. A beginner will not have the skills or knowledge on how to resolve that.
>That being said online repls are useful for writing quick code for e.g. testing something out.
Isn't that exactly the same problem they are solving for beginners?
It's not elitist, it's realistic. You haven't actually mentioned a 'real' problem they are solving through code.
> Isn't that exactly the same problem they are solving for beginners?
Not according to the comment I was responding to.
It seems there are very few real problems in the world to solve if we are going to be stringent. Also solving non-real problems can lead to solving real problems (ad industry funding bleeding edge innovation is a good example of this).
I assume it means a problem that needs solving, requires a computer to solve and is not just an exercise.
> Also solving non-real problems can lead to solving real problems
Yes, and there is nothing wrong or useless about solving problems that are not 'real', I was mostly just objecting to the usage of the term 'real problem'.
And yet the number of times I've seen beginners completely discouraged or even give up programming forever because they have conda and pip and brew and pyenv installed and can't run a basic script after 4 hours of trying because environment mess-up is ridiculous.
The value in a programming environment that literally just works and can give you a functioning web app (the modern very basic I/O) in less than a minute is a huge value add for education.
I'm a complete convert. I've worked with Amasad to write tutorials[0] showing how easy repl is to use and these have become some of my most popular tutorials.
Absolutely incredible that repl.it has done so much in such a short time and with a very small team. All the best for the future!
[0] https://www.codementor.io/garethdwyer/posts