con: GUI programming will suck unless .net adds "visual python"
I don't have statistics but I imagine people would prefer sticking to VB for ease of adding buttons, etc.
201–210 of 280 posts
con: GUI programming will suck unless .net adds "visual python"
I don't have statistics but I imagine people would prefer sticking to VB for ease of adding buttons, etc.
Earlier quoted context omitted.
> strong, static typing is an essential feature for large scale projects This is empirically false. There are (of course!) good reasons to consider static typing. But, in my experience, use of static typing has never been a first-order predictor of business or technology success. It's quite possible to build considerable value with, for example, a large Python 2.x code base. A fun, and tangentially related, talk: htt…
That reminds me of Kapital [1] - a valuation and risk analysis system written in Smalltalk at JPMorgan, begun in the early '90s and as far as i know still going; 14,000 classes, 400,000 methods, hojillions of dollars of profit, twenty years in service, zero types: http://www.esug.org/data/ESUG2004/ValueOfSmalltalk.pdf
In my view, classes are types. (Well, maybe I'm just spoiled by C++.)
Earlier quoted context omitted.
I disagree. Python is great for scripting and for small projects, but I believe strong, static typing is an essential feature for large scale projects. I wouldn't want to use Python for anything that's predicted to end up with more than a couple thousand lines of code.
Given that there are literally thousands of huge projects using Python at massive scale and hundreds of kLOC, it's clearly not essential .
Earlier quoted context omitted.
Unfortunately, there are several companies and hundreds of divisions of companies run entirely out of excel spreadsheets.
Next up, get rid of Access
I understand, though: you hate VBA. And by extension, Access. But Excel, with or without Python, doesn't mean it can suddenly be used as a relational database. But you knew that.
So, what should replace Access?
Earlier quoted context omitted.
I disagree. Python is great for scripting and for small projects, but I believe strong, static typing is an essential feature for large scale projects. I wouldn't want to use Python for anything that's predicted to end up with more than a couple thousand lines of code.
People will tell you that instagram uses python or yelp or other big name projects use python. Certainly, type checking is not Essential to a large project the same way utensils are not essential when you eat. You can just use your hands to shove all the food into your mouth.
No love for C#? Imagine the power of LINQ in Excel.
I think python is a bad choice for Excel, Ruby would probably be easier to people who are not developers and javascript might work just because if its reach (while still being simple).
It would be great for a scripting language, but for field functions I would have preferred something that's more akin to FRP-oriented language (e.g. Scheme).
Excel itself is functional and reactive already, wouldn't adding an FRP language on top of that be a bit superfluous? Check out Felienne Hermans' work if you haven't already: https://www.youtube.com/watch?v=0yKf8TrLUOw http://www.felienne.com/publications