On Sun, May 26, 2019 at 7:11 PM Barry Scott email@example.com wrote:
You said this: "Well, depends on how we define narrow ... you are writing probably this email on a HDL designed machine ... and the entire world is powered by HDL designed silicons. that is not small for me at all."
Which I take to mean that because there are billions of chips in the world there are billions of python users. And the change you want is justified by the billions of python users.
No offense but it is a bit too optimistic too think there are billions of python users (who actually write python code). And it is a bit too pessimistic to think there are billions of chips in the world ... the chips I personally worked on most likely exceeded the billion mark. So put this in perspective there are hundreds of billions of chips being produced, this is the problem space of secondary impact. the primary impact could be a few million (my estimation) HDL developers, and a dozen million HDL verification engineers. It is definitely smaller than the entire python developer community because probably all of the hardware/silicon engineers write a few lines of python. I just want to say this is NOT a small problem at all.
SiFive can now develop RISC-V CPUs which is faster and more efficient than the respective ARM versions is probably the best testimony that a better HDL matters.
There is a reason that there are 1,000s of computer languages in the world. Not all computer languages are able to solve all problems.
If Chisel or Scala is closer to what you want why are you not using them for your HDL tools?
Yes of course ... and python keeps solving more of them with PEPs ... and the whole motivation for me to discuss here is I think Python is so close to solve the HDL problem too (give me a way to override assignment and do not mess up the existing operators which I do love and want to mix with the overloaded assignment operators). Chisel does not solve all the problems (yet), and I have never been a scala developer, so I do want to give a push in Python before I decide to switch to scala/chisel.
What has that got to do with justifying a change to the python language?
I think every language has to has a vision, and I thought Python's vision is to use less chars to present bigger ideas, and logically I thought assignment overloading but not messing up existing operators could have been resonating in python community.
And it seems that you have hit a major problem with the HDL syntax not mapping to python. Maybe python is not the right choice?
This is actually the only problem I hit ... python seems to be the right choice in all the rest 99% cases I have ever met.
For any non-trivia hardware I'm finding it hard to believe that python will run fast enough to be useful. What is it that I'm missing?
We are all Python users and we start to worry about running fast? really? ;-) I thought we all understood development time matters (if not even more ...)
Packages like numpy are not written in python for a reason. A pure python numpy would be very slow. So yes we worry about run time speed.
numpy is not Python! numpy is C! Python does not have numpy! I am a bit surprised that we python community is even denying python is slow? You bench mark it in all possible ways python is still slow, if not the slowest. That's a known fact and we always do python prototyping and optimize the critical path/parts into C. Python is not build for speed. (don't bring in pypy for now please ... ) What we love about python is its development speed. The same applies to the world of hardware design and verification.