> In the olden days, Excel had a very awkward programming language without a name. “Excel Macros,” we called it. It was a severely dysfunctional programming language without variables (you had to store values in cells on a worksheet), without locals, without subroutine calls: in short it was almost completely unmaintainable. It had advanced features like “Goto” but the labels were actually physically invisible. [...] I was supposed to come up with a solution to this problem. The implication was that the solution would have something to do with the Basic programming language. Basic? Yech!
Take a look at this 4-minute video: Excel Magic. This engineer demonstrated the implementation of many sophisticated simulations, entirely in Excel, including flight simulators, orbital mechanics, digital signal processing, ray-tracing, heat transfer, chemical reaction dynamics, and more.
I don't know what to say... On one hand, I clearly understand that, due to the programmability with macros and VBA, the express power of Excel is as powerful as any "real" programming language, and in fact, a lot of real-world engineering calculations are indeed performed in Excel, the prevalence of Excel in engineering is almost terrifying. Imagine solving differential equations numerically using 10,000 cells in Excel, yes, it has been done! I respect their skills and achievements.
On the other hand, it just looks painful to me, and feels like constructing a skyscraper using a toothpick.
Excel macros were/are bad as a programming environment, for the reasons Joel says. The thing is, that's because it grew out of the deficiencies of formulae. If you can't do a thing with formulae, the next logical step was a macro. Since Excel was such widely distributed software back then, and it took actual effort to get decent tools for programming, macros were a lot of folks' first exposure to programming.
In turn, that means there are people who can perform what I'd consider pure wizardry with them. My hat is off to those people, though I still am happier that I got my hands on Turbo Pascal at the right age.
Many times "it" started as one worker in the office who needed to get something done. And they figured out that Excel (or Access) could do "that thing". So they used Excel to automate it. Then "that thing" ended up doing more, and getting more complicated, until one day people realize that the company depends on this (now) business critical process.
Excel was more likely because it came in almost every version of Microsoft Office. Access tended to come in only the more expensive suites.
That's why I call Excel & Access "gateway drugs" - they're the tool that got a lot of people into programming. They didn't wake up one morning and say "hey, I want to be a programmer!". Instead they figured out how to do their work with the tools they had, and then one day woke up and realized "OMG! I've become a programmer without noticing."
Oh hey, another turbo pascal starter. If you don't mind, can you elaborate on why you feel that way about it?
In retrospective, I am happy about starting with it, and remember it fondly. But I cannot really make any good point for why, and I definitely remember cursing it out very hard at the time.
1. It was better than the other stuff I had access to at the time. This is due more to the poor quality of the other stuff I had access to at the time than any benefit of Turbo Pascal, but it still mattered.
2. There are pointers in it, but you aren't forced to use them for simple programs. Having encountered pointers early is a huge leg up when it comes time to work with something like C or assembler. Being forced to use them (as in C) makes the learning curve really steep. Something like Pascal, where you have pointers but you aren't forced to use them for the sorts of program a beginner will tend to write, seems to give both benefits.
as someone who started out with turbo pascal I totally agree with this
but I have to add an extra point that turbo pascal is an IDE you press F9 (I think?) and it runs your freaking code, press F8 (I think?) and you have a line-stepping debugger
I started learning programming in 2003 in turbo pascal, already very outdated at the time. But it is still probably the most pragmatic choice for teaching pointer-based programming (it should be a crime to teach data structures in a language that doesn't have manual memory management)
> Imagine solving differential equations numerically using 10,000 cells in Excel, yes, it has been done!
There's a nice treatment of how to do this for simple heat transfer problems in Tony Kordyban's Hot Air Rises and Heat Sinks. You will amaze and frustrate your co-workers.
Excel is 100% the poor man's simulation package. I like Matlab and Simulink a lot better, and if I were 25 again I'd be a fool for Julia, but nothing beats it for sharing a simulation or other analysis with someone that doesn't have the same software you do on his or her computer.
It was a fun book, I don't remember the Excel modeling part though... I do remember seeing something similar on Microwaves101.com by The Unknown Editor...
> The spreadsheet has 96 distance steps and 2000 time steps, or almost 100,000 cells. In the old days it would bring a computer to its knees when you changed a variable. Now it's almost instantaneous, however, it still measures 10MB. We will offer a zipped version of it in the download area, soon.
Chapter 25, "Even A Watched Pot Boils Eventually". If you want a whole lot of that, appendix D of Holman's Heat Transfer, which is referenced in Kordyban's book.
Take a look at this 4-minute video: Excel Magic. This engineer demonstrated the implementation of many sophisticated simulations, entirely in Excel, including flight simulators, orbital mechanics, digital signal processing, ray-tracing, heat transfer, chemical reaction dynamics, and more.
https://www.youtube.com/watch?v=r9PLmtQZwmY
I don't know what to say... On one hand, I clearly understand that, due to the programmability with macros and VBA, the express power of Excel is as powerful as any "real" programming language, and in fact, a lot of real-world engineering calculations are indeed performed in Excel, the prevalence of Excel in engineering is almost terrifying. Imagine solving differential equations numerically using 10,000 cells in Excel, yes, it has been done! I respect their skills and achievements.
On the other hand, it just looks painful to me, and feels like constructing a skyscraper using a toothpick.