[Forge]

01001101 01101001 01100011 01101011 01111001 00100000 01000011 00100000 01101111 01110111 01101110 01110011 00100000 01100001 00100000 01100111 01110101 01101110

[Micky C]

Using Python with Scipy I was able to reduce 400 lines of code in 3 subroutines in fortran into one function of 40 lines, that is also a more general case of the original. I don't care if it's 1000x slower, it's also 1000x easier to read, understand and maintain

[icecoldduke]

Micky C, on 07 April 2017 - 10:14 PM, said:

Using Python with Scipy I was able to reduce 400 lines of code in 3 subroutines in fortran into one function of 40 lines, that is also a more general case of the original. I don't care if it's 1000x slower, it's also 1000x easier to read, understand and maintain

If you were able to cut down that many lines of code, I would blame your original implementation and not so much the language . I would say use whatever works for you, but if your making software in a professional environment, people need to consider someone else will have to come in and maintain your code later down the line. Which is why I would argue people should use languages that most engineers don't cringe at.

[Micky C]

The majority of the code taken out was replaced by a function built into a popular module that was essentially a one-line call. I had no reason to keep my version of the algorithm around. Having so much functionality built into the standard libraries and otherwise mainstream popular third party libraries is one of the big reasons for me to move to python. Sure, some of the larger stuff may be available in fortran, but there's a lot of small benefits to python that add up to a big advantage.

You'll have to be more specific when you refer to engineers. My background is civil engineering. I can tell you right now that C is pretty much the last language a civil engineer is likely to learn. Fortran, R and Matlab are actively taught in the course at my university. Between them they're very well suited to the kind of work civil engineers do; math, math and more math. No graphical user interfaces needed, just a command line, an input text file and another text file at the end that contains the answers. Sure, now that I'm at the PhD level a more general purpose language is starting to look tempting, and python serves that purpose well while 1. Having a very short development time, 2. Having code that is easily understood by other civil engineers.

[High Treason]

Courtesy of a Python-based MIDI SysEx tool. The older 16-Bit tool I commonly use is written in C++ and doesn't drag the machine to its knees just to puke a few KB up and down the MIDI cables.

* Screenshot for illustrative purposes only as I couldn't be bothered to reinstall the tool and take my own picture, though it is still accurate. The Java one isn't much better either. I also acknowledge that HAL doesn't help matters very much, but this is still needless.

[Sledgehammer]

Forge, on 07 April 2017 - 06:53 PM, said:

01001101 01101001 01100011 01101011 01111001 00100000 01000011 00100000 01101111 01110111 01101110 01110011 00100000 01100001 00100000 01100111 01110101 01101110

01000011 01100001 01101110 00100000 01101000 01100101 00100000 01100101 01110110 01100101 01101110 00100000 01101111 01110111 01100101 00100000 01101111 01101110 01100101 00111111

[High Treason]

54 68 69 73 20 69 73 20 72 65 61 6C 6C 79 20 64 75 6D 62 2E

[Micky C]

High Treason, on 08 April 2017 - 05:27 AM, said:

Courtesy of a Python-based MIDI SysEx tool. The older 16-Bit tool I commonly use is written in C++ and doesn't drag the machine to its knees just to puke a few KB up and down the MIDI cables.

* Screenshot for illustrative purposes only as I couldn't be bothered to reinstall the tool and take my own picture, though it is still accurate. The Java one isn't much better either. I also acknowledge that HAL doesn't help matters very much, but this is still needless.

Yeah Python's not well designed for multiple threads as a result of the global interpreter lock.

It should be noted that besides some things like not forcing declaration of variables, there's not a lot about python that's inherently slow as a language. While python is currently predominantly interpreted, this doesn't have to be the case, and there are several teams working from different angles to bring significant speed boosts. There are a few JIT compilers in the works such as Numba and Pypy with various levels of required tweaks and compatibility, as well as Cython which converts python code into C and statically compiles it to give you C-level speed. Work on these features is on-going.

[Big Bene]

Lots of Basic back in 64 times, plus quite some assembler code.
Same with Acorn Archimedes.
Some QBasic when I gave computer lessons for children.
VBasic for programmed Word macros.
Nowadays mostly webbased in Javascript and PHP.