Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excel team considering Python as scripting language: asking for feedback

news.ycombinator.com

Post reply on HN
Print view View original

251–260 of 280 posts

Re: Excel team considering Python as scripting language: asking for feedback

#251

Post by vanderZwan »

askvictor wrote: post #18
_e wrote: post #5

Dear Excel team, Take a look at the top three results for "excel python" on bing.com for some great ideas on how to incorporate python into excel. --- 1.) https://www.python-excel.org 2.) https://www.pyxll.com/ 3.) https://www.xlwings.org/

There is also pyspread as a full spreadsheet implementation using and for Python: https://manns.github.io/pyspread/

> Pyspread expects Python expressions in its grid cells, which makes a spreadsheet specific language obsolete. Each cell returns a Python object that can be accessed from other cells. These objects can represent anything including lists or matrices.

Huh, on the one hand sounds like a such a simple way to deal with it that I can have trouble imagining a more elegant approach.

On the other hand, does it still respect the ways that Excel updates cells? Sicne that kind of requires immutability I think.

Re: Excel team considering Python as scripting language: asking for feedback

#252

Post by twic »

Koshkin wrote: post #202
twic wrote: post #95

Earlier quoted context omitted.

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

> 14,000 classes..., zero types In my view, classes are types. (Well, maybe I'm just spoiled by C++.)

In C++, classes do indeed define types. Templated classes define whole families of types. But in Smalltalk, classes do not define types.

I understand the word "type" to mean a property of a variable which restricts the range of values it can hold, and the set of methods which can be invoked on it. Smalltalk doesn't have any way to do either of those things, so it has no types.

Re: Excel team considering Python as scripting language: asking for feedback

#255

Post by intrasight »

zoom6628 wrote: post #178

Much as i would love for the power of Python in Excel it is important that whatever is done is consistent across the office experience. Some of us old enough to remember the multiple versions of VB-whatever across Excel, Word, Access and that in itself was a blow to productivity. Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs pleas…

C# Scripting is a thing now. I've used it on projects. C# makes an excellent scripting language, and in the MSFT space there's probably more of an established practice in that language. I can't imagine why they would use any other language - except perhaps F# or PowerShell.

Re: Excel team considering Python as scripting language: asking for feedback

#256

Post by rmbeard »

PlugTunin wrote: post #204
bluedino wrote: post #177

Earlier quoted context omitted.

Next up, get rid of Access

No one is proposing that we get rid of spreadsheets. 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?

Actually, a number of people are proposing this for certain applications. It is also reasonably likely to happen, at very least the spreadsheet is being challenged which will put pressure on spreadsheet vendors and most definitely cut into their marketshare. Adding Python support to Excel seems to be an attempt to resist this.

Re: Excel team considering Python as scripting language: asking for feedback

#257

Post by lazyman75 »

zoom6628 wrote: post #178

Much as i would love for the power of Python in Excel it is important that whatever is done is consistent across the office experience. Some of us old enough to remember the multiple versions of VB-whatever across Excel, Word, Access and that in itself was a blow to productivity. Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs pleas…

Python?!?! "Significant whitespace" is an abomination from deepest layers of hell.

Re: Excel team considering Python as scripting language: asking for feedback

#258

Post by joshuamorton »

Koshkin wrote: post #203
Daishiman wrote: post #25

Earlier quoted context omitted.

Given that there are literally thousands of huge projects using Python at massive scale and hundreds of kLOC, it's clearly not essential .

Code written in a statically typed language requires less testing. How is that not essential?

Code written in dynamically typed language requires less code, which often means less surface area for failure, and less tests.

Re: Excel team considering Python as scripting language: asking for feedback

#259

Post by Koshkin »

twic wrote: post #252
Koshkin wrote: post #202

Earlier quoted context omitted.

> 14,000 classes..., zero types In my view, classes are types. (Well, maybe I'm just spoiled by C++.)

In C++, classes do indeed define types. Templated classes define whole families of types. But in Smalltalk, classes do not define types. I understand the word "type" to mean a property of a variable which restricts the range of values it can hold, and the set of methods which can be invoked on it. Smalltalk doesn't have any way to do either of those things, so it has no types.

But don't objects that belong to a class also effectively have similar restrictions imposed on them? (Otherwise, why have classes at all?)

Re: Excel team considering Python as scripting language: asking for feedback

#260

Post by Koshkin »

joshuamorton wrote: post #258
Koshkin wrote: post #203

Earlier quoted context omitted.

Code written in a statically typed language requires less testing. How is that not essential?

Code written in dynamically typed language requires less code, which often means less surface area for failure, and less tests.

> often means

No it does not, neither in theory nor in practice. Also, "less code" depends primarily on the language structure and not on whether the language is dynamically typed or not. (Haskell, for example, is more terse than Python.)

Post reply on HN