[flagged]
I wonder if we were in our early 20s during Nazi Germany if either of us would have the wherewithal to reject being a Nazi. I suspect we're all shitheads depending on the context.
> I'm dis-recommnending bash.
Yeah, I got that. I just thought it was absurd for you to only aim for a few orders of magnitude speed improvement when you could've easily gotten several more by arguing for something faster than Python.
> You admit floating point math in bash would be a good idea, and you seem to think [...]
You're doing that thing again where you try to represent my argument for me. This time instead of telling me what I might say, you're telling me what I think. You're wrong again, and it's still a poor argument strategy.
I'm not defending or advocating bash. I'm certainly not recommending any improvements to it - I only said they were possible. I am however calling you out for recommending Python in any case where performance matters.
Once again: If performance matters, then use PyPy or V8 or SpiderMonkey or ChakraCore or JavaScriptCore or Carakan or Nashorn of course.
It doesn't invalidate my argument that I used the name of the language Python instead of listing out every possible interpreter or VM that runs Python scripts, or every JavaScript VM, or every C++ compiler.
I've already said several times that Python is just an example. Did you not understand that part?
The hundreds of instructions difference between multiplying with CPython and PyPy still pales in comparison to the millions of instructions required to fork "bc".
And with bash you're still stuck with that terrible mish-mash syntax and converting back and forth between text and binary floating point numbers.
Thank you for the link. I'll give it a look.
> While you're farting bubbles in the bathtub about integrating "bc" into bash, and haven't even proposed how you'll integrate the canvas api yet.
I tend to fart in the shower, and I don't give a crap about bc or bash. As for the canvas api, you must've missed the part where I said you can call gnuplot from bash (or any language which supports fork, dup, and exec, or popen). I'd guess that bash calling gnuplot as a subprocess is on par with Python calling the Tkinter canvas through their hackish hidden-Tcl abomination. You're probably a matplotlib guy though...
Incidentally, I have built command line plotters before, but I can't share the code, so you don't have any reason to believe me on that.
(No I'm not a matplot guy, but I've built command line plotters too and even terminal emulators that accepted escape codes with PostScript commands. ;) And I've done a lot of work with TCL/Tk and canvas both directly and through Tkinter, and also with PyGTK using pycairo, and I've integrated lots of code into Python with SWIG, including Python C extension integrated with PyCairo. Can you integrate C extensions into bash with SWIG, or any other way short or recompiling?)
Here are some open source reasons to believe me:
(search for "termulate-ps-string"):
https://www.donhopkins.com/home/code/term.ps.txt
https://github.com/SimHacker/micropolis/blob/master/micropol...
https://github.com/SimHacker/micropolis/blob/master/micropol...
https://github.com/SimHacker/micropolis/tree/master/Micropol...
https://github.com/SimHacker/micropolis/tree/master/Micropol...
You keep going back to this mistaken belief that forking off separate processes is incredibly cheap. Or even convenient. You really should rid yourself of that misconception.
Sure, there is some cost to all the glue code required by something like TCL or SWIG or COM or P/Invoke or any foreign function interface. But that's not even in the ballpark of how long it takes to fork off a Unix process.
It's ironic that the strongest argument bash apologists have is that it's convenient, but once you are faced with all that mish-mashed haphazard syntax and kludgy tricks (like testing for an empty string like "x$foo" == "x"), it's actually one of the most inconvenient languages there is!
Python's Tkinter converts all calls into strings which are parsed and executed by the hidden Tcl interpreter in there. It's really pretty hackish. I didn't say it ran in a separate process, I said it was probably on par performance-wise as bash calling gnuplot through a separate process.
> Can you integrate C extensions into bash with SWIG, or any other way short or recompiling?
Yuck. Why would I want to do that? I don't like SWIG or bash. SWIG generates an awful mess. When needed, I prefer to write Python extensions by hand.
However, I suspect the only reason bash doesn't support plugins/extensions has more to do with some GPL ideology.
> You keep going back to this mistaken belief that forking off separate processes is incredibly cheap. Or even convenient. You really should rid yourself of that misconception.
You should really stick to things I've actually written. I'm starting to think you're having an argument with some imaginary bash and fork advocate in your head and pretending I'm him.
And then on top of that, you still have to convert just as many numbers and strings back and forth -- if not more! It's not just the calling and conversion overhead of gnuplot: bash also has to fork off many more "bc" processes that themselves convert text numbers to binary, evaluate expression, then convert binary numbers back to text (and there could be hundreds or thousands of expressions).
While Python with pycairo can draw a pie chart without once converting numbers between text and binary, reading and writing text to a pipe, context switching, or forking off thousands of processes.
The only thing I was imagining about you was that you were listening to what I was saying, but I keep finding I need to repeat myself.
Communicating with people is hard, especially when you only really want to repeat yourself and not try to understand what anyone else is saying. I get your point - fork is slow. Now what do you think my point was? Please don't bother repeating yourself again.
Yes[1], although I don't recommend doing that. See my longer comment[2] re: bash is a simple scripting/glue language, not a general-purpose programming tool.