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

121–130 of 280 posts

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

#121

Post by sheetjs »

blhack wrote: post #12
HumanDrivenDev wrote: post #11

An absolute no-brainer. Python is the new BASIC - very popular with people who have to program to do their work but aren't programmers. It's an excellent choice for a spreadsheet.

>aren't programmers Also extremely popular with people who are programmers and need to do things. Sorry, this is a frustration of mine lately. Python is a fantastic introductory language. It's also a fantastic general purpose language. Newbies get turned off of it because it feels too easy, and they know that "real" programming is supposed to be hard.

It's actually surprising the Excel team isn't considering TypeScript. TS is a modern language that they control, gives them an out for eventual browser compatibility, and they've already built great tooling (better than the visual studio tooling for python)

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

#125

Post by [deleted] »

gregschlom wrote: post #17
blhack wrote: post #12

Earlier quoted context omitted.

>aren't programmers Also extremely popular with people who are programmers and need to do things. Sorry, this is a frustration of mine lately. Python is a fantastic introductory language. It's also a fantastic general purpose language. Newbies get turned off of it because it feels too easy, and they know that "real" programming is supposed to be hard.

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.

[deleted]

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

#126

Post by bpicolo »

sheetjs wrote: post #121
blhack wrote: post #12

Earlier quoted context omitted.

>aren't programmers Also extremely popular with people who are programmers and need to do things. Sorry, this is a frustration of mine lately. Python is a fantastic introductory language. It's also a fantastic general purpose language. Newbies get turned off of it because it feels too easy, and they know that "real" programming is supposed to be hard.

It's actually surprising the Excel team isn't considering TypeScript. TS is a modern language that they control, gives them an out for eventual browser compatibility, and they've already built great tooling (better than the visual studio tooling for python)

> eventual browser compatibility

You'd be hardpressed to reinvent excel in a browser. Sheets is a big, advanced web app but it doesn't even come close.

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

#127

Post by jeremiep »

cm2187 wrote: post #102
jeremiep wrote: post #89

Earlier quoted context omitted.

Saying dynamic languages are for novices hints more at you being one than anything else. Not everyone likes IDEs (Emacs and VIM are still by far superior to many) and not everyone wants to deal with all the extra code and boilerplate and ad-hoc data classes that comes with static typing, to name a few. Dynamic languages have faster iteration times and from experience that can yield higher quality software. They're ea…

I am not saying dynamic languages are for novice. I am saying people who will be using office's scripting are more often than not programming novices (like they are with VBA). You may like plain text editor but for someone who doesn't know how to program, typing a variable then dot, and having a drop down of what is available from there, with an embedded documentation and direct IDE feedback on what is correct or inc…

Sorry I misread your first comment.

Its still possible for dynamic languages to have auto-completion. There's way more information available at runtime than at compile-time.

Besides, IDEs tend to have the entire world in most autocompletions, which is not useful either.

There would be no IDE here, you'll probably still write code from within Excel and advanced users will use separate source files to leverage their editor of choice.

The novices you mention will not want to leave Excel. A dynamic runtime with reflection is all you need to give a friendly experience. That doesn't prevent type hints, inference or autocompletion.

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

#129

Post by nick238 »

mixedCase wrote: post #44
Lxr wrote: post #28

Earlier quoted context omitted.

Instagram would disagree with you. Seriously, Python is an absolute pleasure for managing large web projects and the lack of static typing has never been an issue for my company (spend the time writing tests instead!)

>(spend the time writing tests instead!) Every sufficiently large test suite will contain an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a proper type system.

What's the point in testing types if the tests that check it works pass?

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

#130

Post by pmontra »

nightski wrote: post #98
pmontra wrote: post #88

Earlier quoted context omitted.

Not for free. You have to think and write types, maybe add some code to cast values between them or implement the same function twice for two different type signatures. Sometimes it still gains time, sometimes it doesn't. Anyway, I doubt that a VBA replacement would need types. The use case is small scripts.

Python is strongly typed. You still have to think about the types. Except now you have to think about them every time you work with the code, not just the first time.

I work with Python and Ruby (some Elixir.) They are strongly typed in the same way. I hardly think about types. The code just works. The only scenario in which I have to stop and think is when I get some input, for example some JSON. Is that value I have to add to this counter a string or an integer? I can cast it to integer and that's it. To be fair, sometimes an integer gets where there should be a string and boom. Still, I prefer that to having to write types again as I used to when working with C and Java. I fix the code and I don't write tests to check the types of function arguments. Maybe I could accept some type inference, but no more string, int, generics, etc.
Post reply on HN