Python is the best at quite a few things these days, particularly if you need to accommodate projects (or developers) that require top-caliber tools for getting work done in several different problem areas.

The whole 2 vs. 3 is, if anything, an embarrassing interlude in getting to the fact that it's currently both amazing for beginners and one of the most versatile professional languages. Where it's not the best, it's often fighting "mainly good for this one problem area" tools and languages to a draw...while still being great for dozens of other problem areas.

Cracks about "really easy to use orbital death cannons being handed out to anyone who asks" aside - your best comparison is probably a trench knife. Simple, elegant, gets the job done whatever that job happens to be.

You need to build in some hyperbole. Python is a scripting language, and even amongst scripting languages, not a particularly fast one. So ...

Python, as a weapon, is like a government grant on which you have written "shoot a gun". You just tell it what to do and it somehow happens ...

using 500x the resources any sane human being would have used. If you examine what it did to launch a bullet found it built and operated an international airport including 5 passenger terminals and then used a very elaborate looking runway to fire the bullet. The amount of empty space between the buildings looks very impressive and significant.

The only reason Python should ever be problematically slow is if you're writing bad Python. (Well, almost ever.)

What you have to understand is that pythonic Python is largely a matter of invoking C libraries, and that Python only really runs at "interpreted" speed the first time you invoke the code.

It's no more slow than a shell script which serves to invoke grep and sed would be, because you're relying on the underlying optimized tools to execute the bits that would actually benefit from optimization. The microseconds it takes to switch from one to the other are almost never going to be a meaningful slice of the total execution time.

Instead of picking over the mostly insignificant delays that are left, Python has said "hey, let's optimize for readability & developer sanity instead — things that actually affect project outcomes." And then you go knock off 10 different issues you wouldn't have had time for, and you don't stab yourself in the eye with a fork while trying to make sense of the old code.

> What you have to understand is that pythonic Python is largely a matter of invoking C libraries, and that Python only really runs at "interpreted" speed the first time you invoke the code.

I do a bit of machine learning for work every now and then. I don't agree. Python is both really popular for machine learning and way too slow to let production stuff run in it.

I routinely do machine learning and computer vision, and have used a number of languages for them.

The main issue, irrespective of language, is that the implementation of your final model is often a distinct step from the last output of your experimental tools. If you just take what it gives you and try to deploy that, it will often provide extremely suboptimal performance.

The methods for implementing your final model could involve raw Python, NumPy, the Python wrapper for an external library, writing and consuming custom C libs...it depends on the complexity of the hyperplanes.

But e.g. scikit-learn already wraps libsvm and liblinear. If your SVM (etc.) is slow, it's very unlikely to be because you used Python.

If you're e.g. trying to do Facebook-level heavy lifting, your experiences may vary. But again, that would be a challenge for any tools. The solution is to use sampling, parallelism, etc. - and to implement and optimize your final model as a separate step from designing it.

"Why an “Unlimited” Plan is Toxic for Your SaaS" -- Josh Pigford, Baremetrics

https://baremetrics.io/blog/never-offer-unlimited

That's a good article but it glosses over this comment: https://baremetrics.io/blog/never-offer-unlimited#comment-13...

Never ever listen to people who use the words never and ever.

"Okay, how do you determine what portion of revenues are profit?" (crickets)

Seriously, I've heard this one waaaay too many times. It's right up there with "you'll work for equity right, and maybe we can throw in a bit of cash if you put in enough hours?"

Not implicitly, although people are free to use that as a negotiation tactic.

If people try to negotiate you down, you negotiate them right back.

You are probably drastically underestimating the marketability of "can write production-ready JavaScript given sufficient time browsing docs & without copying it directly from StackOverflow."

And I only say "probably" because it sounds like you're looking for a local W-2 gig, and there are some places (e.g. rural Idaho) where there's likely to be a shortage of potential employers.

Elsewhere, consider "any company with senior programmers to report to" as a location which is probably hiring, or at least entertaining applicants - regardless of what any public listings may say about what openings exist, or how much experience or what madcap assortment of skills any job postings say that they'd like (yes, like).

Thank you for the perspective. I take the requirements on job listings very literally and definitely underestimate what I have to offer. I will broaden my search. I am not in a tech hot spot, but also not in the middle of nowhere.

People with networks of fake accounts routinely set them up in advance & run simulated activity.

This is normally used for e.g. selling fake likes. It's taken as a given that you will have regular churn as accounts are detected, occasionally high spikes of turnover as fraud detection and safeguards change, that kind of stuff. Often the action of converting network behavior into currency activity is what burns accounts.

Given an alternative way of rapidly converting part of that network into a compelling quantity of USD, and the fact that you're routinely rotating accounts anyway...offering to pay money or money-equivalents for Facebook connections in an automated fashion is pretty much screaming for fraudsters to call in the biggest airstrike they can before you come to your senses.

Yeah, I'm well aware of that. I was answering the 'what's required' part.

Let's just say, it's a fairly trivial exercise if you have access to a botnet.

Set up a lightweight web interface using Flask. When people log in and submit a job, it gets added to an RQ task queue for asynchronous execution. If they need anything back at the end, job status, results, whatever - that goes in a database. Congratulations, you've just made a simple web app.

If people are actually getting use out of it, go back and pretty it up a bit with a Bootstrap template or whatever, it doesn't take much here to have meaningful effects on user perception. It mostly just has to be nice enough that it looks reasonably professional when people show it off in meetings, which is NOT a cutting-edge design problem.

Add more pages for more scripts as needed, and tag users with permissions so you know which scripts should be exposed to which users.

If merited, go back and add fancy features like generating PDF reports and emailing them to the head of department every week.

This is interesting. What if users have to put in their own inputs for the scripts? For instance, specify start-date and end-date for a sql query, or upload a spreadsheet to do the python analysis on?

You'd use Flask-WTF for forms.

https://flask-wtf.readthedocs.org/en/latest/

It can also handle file uploads.

https://flask-wtf.readthedocs.org/en/latest/form.html

You'd need to define a model which describes the form fields, handle it in your view, and add it to your page template.

forms.py

    from flask_wtf import Form
    from wtforms import TextField, PasswordField
    from wtforms.validators import DataRequired
    
    class LoginForm(Form):
        email = TextField('Email', validators=[DataRequired()])
        password = PasswordField('Password', validators=[DataRequired()])

views.py

    from forms import LoginForm
    
    @app.route('/login', methods=('GET', 'POST'))
    def login():
        form = LoginForm()
        if form.validate_on_submit():
            email = form.data.get('email', None)
            password = form.data.get('password', None)
            do_login_stuff(email, password)
        else:
            return render_template('login_page.html', form=form)

login_page.html

    {% extends "base.html" %}

    {% block content %}
    <h3>Log in:</h3>
    <form method="POST" action="{{ url_for('login') }}">
      {{ form.hidden_tag() }}
      {{ form.email.label }} {{ form.email }}
      {{ form.password.label }} {{ form.password }}
      <input type="submit" value="Log in">
    </form>
    {% endblock %}

Yeah that's the tough part. I think I'd have to set up a model for each script I add to flask.

Here's an option for organizing a "bunch of scripts" app that might be less intimidating to maintain.

foo_script.py

    from flask import render_template
    from flask_wtf import Form
    from wtforms import TextField
    from wtforms.validators import DataRequired
    
    class ScriptForm(Form):
        param1 = TextField('Param1', validators=[DataRequired()])
        param2 = TextField('Param2', validators=[DataRequired()])
        param3 = TextField('Param3', validators=[DataRequired()])

    @app.route('/foo-script', methods=('GET', 'POST'))
    def foo_script():
        form = ScriptForm()
        if form.validate_on_submit():
            do_stuff(form.data)
        else:
            return render_template('foo_script.html', form=form)
    
    def do_stuff(data):
        for key in data:
            print '%s: %s' % (key, data[key])

foo_script.html

    {% extends "base.html" %}

    {% block content %}
    <h3>Run foo script:</h3>
    <form method="POST" action="{{ url_for('foo_script') }}">
      {{ form.hidden_tag() }}
      {{ form.param1.label }} {{ form.param1 }}
      {{ form.param2.label }} {{ form.param2 }}
      {{ form.param3.label }} {{ form.param3 }}
      <input type="submit" value="Run foo script">
    </form>
    {% endblock %}

base.html

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <title>FooCorp Script Service</title>
      </head>
      <body>
        {% block content %}{% endblock %}
      </body>
    </html>

app.py

    from flask import Flask
    
    app = Flask(__name__)
    app.config.from_pyfile('config.py')
    
    import foo_script, bar_script, baz_script

config.py

    # You need this for CSRF protection & cookie signing
    SECRET_KEY = randomly_generated_secret_key

You should also look into Flask's blueprints at some point if it keeps growing. But it's not really essential, just another tool to help you keep projects organized. Flask is mostly "do whatever makes sense in your specific case" rather than imposing many global constraints on structure.

Also, I'd use gunicorn if you're deploying your own server. It's a bit less intimidating to get set up than uWSGI, and the main tradeoff is that it doesn't support quite as many thousands of users (i.e. not relevant).

Where would you actually host the webapp? Would you set up a new server on your intranet and share a link to it?

That depends on your resources & priorities.

Internal if you have the IT resources & infrastructure for that to be reasonably painless. VPS if you need to access it from multiple public locations and don't want to expose an internal server, or if "internal server" isn't a thing where you work. Heroku if you don't know how to admin Linux or don't want to spend the time worrying about it.

I constantly pushed the use of source control when I was a TA for CS juniors & seniors. Of the low-three-digit number of students I interacted with, approximately two of them listened. Many of these had already had internships at e.g. Facebook, Microsoft, Amazon...

Their funding isn't your problem.

Either they can meet your compensation requirements, or they can't and you go elsewhere, or you find a compromise if you both want it to work.

If you're a decent engineer who can get things done and out the door to some reasonable professional standard, there are a LOT of elsewheres.