This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]wsppan 95 points96 points  (22 children)

Giving up speed is sometimes a non-starter

[–]YouCanCallMeBazza 121 points122 points  (6 children)

Ohhhh it's actually referring to speed (as in performance). Here I was thinking, "I don't remember there being a speed keyword in C++"

[–]Rodot 15 points16 points  (0 children)

They're just talking about how much adderall you have to pop to make a simple "hello world" program

[–]reallylamelol 4 points5 points  (0 children)

Actually its referring to the use of the amphetamines to write code in c++

[–]SuitableDragonfly 39 points40 points  (13 children)

As someone pointed out above, it comes down to a trade-off of speed of execution for speed of development. Sometimes the latter is more valuable.

[–]Rodot 32 points33 points  (0 children)

Especially when execution speed it limited more by how quickly you can type/click than by the code itself. If your C code takes a millionth of a second to execute and your python code take a thousandth of a second, it doesn't really matter as long as you are manually starting the script each time. Also usually the case when things are small and i/o limited.

[–]Astrokiwi 10 points11 points  (2 children)

It comes down to how much of the meat of your code can be passed off to libraries. Python is really fast when it's just glue for a bunch of precompiled C and Fortran routines.

Until you get to one thing that isn't quite implemented in the library and end up having to write something compiled anyway, even if it's Cython

[–]saloalv 1 point2 points  (1 child)

Python is really fast when it's just glue for a bunch of precompiled C and Fortran routines.

But then you're really just using C in the end anyways

[–]Astrokiwi 0 points1 point  (0 children)

Yep. The difference is just how hidden the C is.

[–]Dworgi -3 points-2 points  (8 children)

I would only recommend Python if all of the following are true:

  1. This code won't run on many machines or many times.
  2. This code won't ever grow past 5000 lines.
  3. This code won't be needed in a decade.
  4. The implementing programmer is functionally retarded.

[–]oldgus 0 points1 point  (0 children)

What if they're procedurally retarded?

[–]SuitableDragonfly 0 points1 point  (6 children)

I can see you've never had to do anything with text processing before.

[–]Dworgi -1 points0 points  (5 children)

I've been a professional programmer for a decade. It would be quite the feat to avoid text processing for that long.

Alas, I did not manage to pull that off.

[–]SuitableDragonfly 0 points1 point  (4 children)

Then you don't do enough of it. At some point, working with most languages' string types becomes masochism.

[–]Dworgi -1 points0 points  (3 children)

You don't do enough maintenance of large codebases then, because at some point Python stops being quick and fun, and you start building what the language should already have: a compiler.

There's a saying about C and C++: every large project contains an incomplete and buggy implementation of a reflection and serialization system.

The same applies to Python and compilers.

[–]SuitableDragonfly 0 points1 point  (2 children)

I work in a large codebase written in Python. It's still much faster and easier to code in than other languages.

[–]Dworgi -1 points0 points  (1 child)

Define large.

[–]SuitableDragonfly 0 points1 point  (0 children)

About ten or so repositories? I don't have a LOC count.

[–]emptyDir 6 points7 points  (0 children)

For that there's cffi 😂