Maths isn't hard
As someone doing his math homework as we speak, I beg to differ 
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.html
It is, almost religously considered as such ;). I do not share this
POV for the simple reason that I am too stupid to understand it.
However, I found the "corresponding" MIT videocasts much more easy to
grasp.
e.g. http://www.youtube.com/watch?v=2Op3QLzMgSY
HTH
Robert
···
On Mon, Apr 4, 2011 at 11:28 AM, Stu <stu@rubyprogrammer.net> wrote:
I have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
On Mon, Apr 4, 2011 at 4:05 AM, Mike Stephens <rubfor@recitel.net> wrote:
This thread has been touching upon three issues - functional languages
as a way of expressing problems, Excel as a language environment, and
the programmer.Today, relational databases are widely accepted. However Ted Codd did
not invent the relational model because he thought relations were neat.
If you look at what he said at the time, his motivation was to make
corporate data more accessible to non-programmers. Forty years ago he
thought there were less programmers than there were programs to be
written. Arguably the same is true today.When I was a boy, I would see IDMS recordsets like this:
200
300
150
200
230
etcWhat this represented was
2011/Q1 Sales = £200
2011/Q2 Sales = £300
2011/Q2 Sales = £150Worse still you would have:
12
200
27
300
etcwhich meant:
2011/Q1 Sales = £200
2011/Q1 Units = 12
2011/Q2 Sales = £300
2011/Q2 Units = 27
etcTedd said you must use relations. Relations are unordered so you can't
hide information in the order of data. Also you must have a field name
for each field (and it should be on the same domain, so Sales shouldn't
be in the same 'column' as Units).You would therefore have to have:
Period Sales Units
2011/Q1 200 12
2011/Q2 300 27
etcWhilst- as we all know - that typically doesn't tell you everything you
need to know when you come across a recordset, it makes it much easier
for someone not deeply involved in the system concerned, to work out
what is going on.Put it another way, using relations makes it less likely you will make a
mistake because you didn't know the subtleties of the behaviour of the
programs generating that data.Then, relations are amenable to first order predicate calculus. This
resticts the complexity of the operations you need to carry out.When you consider the merits of functional languages, I believe you
should take into account not only the elegance with which you can
express what you want to do, or how amenable it is to eg parallel
processing. You should also consider whether it strikes a better balance
between such issues and accessibility. Does all your terseness and
'elegance' give you a justifiable advantage over something simpler which
could be more easily handled by a person of less capability?--
Posted via http://www.ruby-forum.com/\.
--
The 1,000,000th fibonacci number contains '42' 2039 times; that is
almost 30 occurrences more than expected (208988 digits).
N.B. The 42nd fibonacci number does not contain '1000000' that is
almost the expected 3.0e-06 times.
But, as I have said, I have seen some absolutely
amazing things doen with spreadsheets.
I've seen some absolutely amazing things done with befunge! Networked
programs, even. Which is more than excel can do.
However, I think it would be reasonable for people to disagree with me,
if I were to insist on a public forum that befunge is somehow
preferable to the entire imperative school of programming languages.
When people come from other programming disciplines, comparison of
modalities and techniques are usually helpful, but fanboy expressions
of "mine is bigger and/or better than yours" are not.
Since I am completely awesome*, I offered to attempt dissect a
piece of functional code for him, if he would provide one. This would
definitely involve a comparison of techniques. We may both learn
something!
* Due to the lack evidence or attention to detail in your post, I feel
confident asserting my awesomeness without any display of rigour,
evidence or logic.
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.htmlI have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
I haven't gone through it yet, but I have a PDF version I can upload if you
don't like the html format of that one. It should be understood, though,
that Ruby's functional support isn't the same as that of the purely
functional languages. That isn't to suggest you won't get insights from that
book, I know a lot of relevant people who have recommended it (ie Uncle Bob,
and Rick DeNetale).
*You have restated my point in much more pleasant language, and with
commendable precision.
Hmm, I thought he deserved to be chastised for making a post almost 90% of
which was about databases. It fits quite nicely with the hypothesis that
he's just trolling.
···
On Mon, Apr 4, 2011 at 4:28 AM, Stu <stu@rubyprogrammer.net> wrote:
On Mon, Apr 4, 2011 at 6:31 AM, Everett L Williams II <rett@classicnet.net>wrote:
On Mon, Apr 4, 2011 at 7:29 AM, Johnny Morrice <spoon@killersmurf.com>wrote:
> I've seen some absolutely amazing things done with befunge! Networked
> programs, even. Which is more than excel can do.Sorry, what with all the bullshit I forgot to provide any evidence of
this fact:
http://zem.fi/~fis/fungot.b98.txt
Amusingly, you added this on a whim, but it's more evidence than the Excel
proponents (sorry, I mean "S# programmers") have provided, despite several
explicit requests for clarification and examples.
B) Define "accessibility". Surely you aren't saying that the UI of a
program is related to which language it was written in. If you mean
issues like maintainable code, isn't a strictly logical, mathematical
structure preferable, especially if it can be analyzed (tooling is our
friend) with the help of other programs? If, indeed, the code can be
*proven* to be correct (proven in the mathematical sense)?
I believe the ability to pick up the basic syntax of the language, and
grasp the basic semantics of it with relative ease, so that one need not
be a lifelong student of the language to be able to pick up an average
program and understand it well enough to maintain it in fairly short
order, is important to the intent of Mike's preceding statement, which is
not addressed in this commentary about accessibility. More about that in
a moment.
C) Why should someone with less capability be taken care off by going
onto their levels, instead of helping them to reach new heights (we
could call such an effort "No Coder Left Behind")? Maths isn't hard,
nor is programming. So this smells like the plot of "Harrison Bergeron"
to me.
I agree this is, all else being equal, a good approach to take.
D) Wouldn't a person with less capability be aided by code that follows
simple, logical rules?
I agree that, all else being equal, this point is relevant and meaningful
here.
The thing is . . . I don't think that matters much. Mike seems to be
trying to make the argument that functional paradigm software development
techniques somehow necessarily make programming a more opaque, arcane
process than some other approach. I disagree quite strongly with that
assumption. What characteristic of functional programming techniques
could possibly render the whole exercise of programming so difficult to
fathom that we cannot present the user with a friendly syntax?
How does providing the developer with the ability to write a recursive
function that can be easily grasped by someone who bothers to learn a
bare minimum of the language's syntax -- as an alternative to forcing
developers to write do-while loops in C that require a page and a half of
code -- in any way make the language less understandable?
. . . and let's not even approach the problem of how one would create an
event loop to scale up to millions of simultaneous requests in MS Excel
minus the capability of using callbacks for asynchronous I/O.
···
On Mon, Apr 04, 2011 at 07:00:19PM +0900, Phillip Gawlowski wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Mike Stephens wrote:
>
>When you consider the merits of functional languages, I believe you
>should take into account not only the elegance with which you can
>express what you want to do, or how amenable it is to eg parallel
>processing. You should also consider whether it strikes a better
>balance between such issues and accessibility. Does all your terseness
>and 'elegance' give you a justifiable advantage over something simpler
>which could be more easily handled by a person of less capability?*You have restated my point in much more pleasant language, and with
commendable precision. The average person who wishes to program a
solution to a problem cares not one whit whether the tool they find
most accessible qualifies as a programming language by another person's
definition. They just want to get their problem solved. Personally,
though I have been arguning the side of Excel here, I hate
spreadsheets. It is arguable that almost anything that can be
accomplished with a database and implementing language such as SQL can
be accomplished with a spreadsheet. I just happen to prefer the DB way
of describing and thinking about data. But, as I have said, I have seen
some absolutely amazing things doen with spreadsheets. My particular
crutch for dealing with DB's is Alpha 5, but there are dozens of such
solutions out there.
If the best tool for the job is not a programming language, feel free to
use it to solve your problem. Please don't suggest this tool that is not
a programming language actually *is* a programming language just because
you can solve problems with it, though. A pointy stick in one's hand is
not a snare, even if it can be used to acquire a rabbit for dinner. A
handheld sickle is not a combine, even if it can be used to harvest
grains.
Denigrating another person's choice of tools will certainly not make
that person likely to seek your advice again, nor consider you helpful.
I don't think anyone is denigrating the use of spreadsheets for problems
best solved by spreadsheets. People just object to describing MS Excel
as a better programming language than Ruby -- a pretty tall order, given
it is woefully inadequate to many tasks for which programming is done,
and is not in fact a "language" by any definition short of the sort of
mental gymnastics necessary to discuss 4GLs with a straight face.
···
On Mon, Apr 04, 2011 at 08:31:08PM +0900, Everett L Williams II wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
To elaborate:
I'm a heavy user of TADS 3 these days, which stands for "Text
Adventure Development System".
It has a heavily C influenced syntax, is Turing complete, and is
compiled into bytecode, but I wouldn't dream of using it to script
regular tasks with it, or write a spreadsheet in it. It's standard
library is heavily geared towards text adventures (what a surprise),
and has next to no functions to call up files, since the IF
interpreter takes care of loading and saving game state.
It has syntax features and objects that make writing interactive
fiction a breeze, however.
For example:
aRoom: Room 'room noun' 'room name'
"This is a room. "
;
+desk: Table 'table noun' 'table name'
"A table with four legs. "
;
++paper: Readable, Thing 'readable noun' 'readable name'
"A piece of paper. "
readDesc = "You read what's written on the piece of paper. "
;
Each plus is an instance of "object nesting": The piece of paper is on
a table, in a room, and the player can react to the things in the room
by using <verb> <noun> constructs.
If I were to use Ruby for this (and I could), I'd still be writing a
text parser, instead of doing what I want to do.
TL;DR: DSLs remove a lot of yak shaving for a given task, but
introduce a lot of it when moving outside of the DSL's domain.
It's jargon vs general language: Makes communicating certain ideas
easier to those in the know, than using a general purpose language.
···
On Tue, Apr 12, 2011 at 5:56 PM, Chad Perrin <code@apotheon.net> wrote:
'Domain Specific Language' is a perjorative term.
No -- it's a descriptive term. A pejorative term would be something like
"blub language". The term "domain specific language" describes a
narrower focus, which makes it more suitable to certain tasks than a
domain nonspecific language, and less suitable to other tasks.You act as though "domain specific" is a synonym for "crippled", but
that's not the case at all.
--
Phillip Gawlowski
Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
That's not the case at all, from what I've seen. People just recognize
that, though a language is a system, not all systems are languages.
···
On Thu, Apr 14, 2011 at 05:59:54AM +0900, Kevin wrote:
Thank you for that. I personally find language construction
interesting. It's a shame that people are just plugging their ears in
this particular topic. Though I think part of the problem is this
topic is that some people seem to think that a program is not a system.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
IDK, likening your adversaries to terrorists seems a bit extreme to me.
···
On Thu, Apr 14, 2011 at 3:29 AM, Robert Klemme <shortcutter@googlemail.com>wrote:
On Thu, Apr 14, 2011 at 9:28 AM, Mike Stephens <rubfor@recitel.net> wrote:
> Longest post for at least a year.
>
> It would appear people are comfortable with discussing details but once
> you stray into challenging their worldviews, you see quite different
> behaviour patterns.
>
> A reminder of why we have to have our bags searched at the airport.Nicely put.
Are you saying that you're creating some kind of stand-alone variant of
VBA?
Unfortunately most people think the words 'Excel' and 'programming' must
equal VBA. I spent a lot on a book called Professional Excel Development
which hardly mentions Excel itself. I think however in ome circumstances
VBA functions may have to be used eg to call realistic SOAP services.
The key is to keep them as functions ie no calling and waiting. They
should look exactly like in-built functions. Also the accomplished S#
programmer only uses them as a last resort.
it's three metric tons of VM-like overhead
but seems to load faster than Ruby
I believe he means that Excel is a processor for dependent formulas
which, by virtue of update event propagation, gives you instantaneous
value updates in all relevant places.
Succinctly put
Maybe you'd like working with a database management system that offers
some kind of stored procedures or triggered functions capabilities more.
Your remark is highly relevant. Tedd Codd deliberately designed the
relational model to eliminate the requirement to describe process. SQL
is a very powerful functional programming system. Stored procedures
however are usually...procedural.
Excel is to DBMSes as those old Power Wheels toys are to actual cars,
after all.
I suspect you can do a lot of real world 'database' processing in
Excel -just like some folks use ActiveRecord (no - don't start me off on
ORMs...). On that basis, I guess a simple web site could use a lot of
functional programming functions without resorting to DBMS facilties.
As I said earlier, one of the attractions is you have to think
differently.
···
--
Posted via http://www.ruby-forum.com/\.
>
> Are you saying that you're creating some kind of stand-alone variant
> of VBA (which is what Excel uses for macros), or are you saying that
> you use a spreadsheet application to write "programs" and call it S#
> to confuse people (in which case it worked on me)? I'm frankly
> appalled at the idea of people writing "programs" in Excel; it's
> three metric tons of VM-like overhead to produce "software" that is
> necessarily far too limited to even have bothered.I believe he means that Excel is a processor for dependent formulas
which, by virtue of update event propagation, gives you instantaneous
value updates in all relevant places.
Option 2, then.
>
> If you want a simple, nominally-functional language, try Scheme.
> Just don't expect getting "real world" work done to be very easy as
> long as the community's internal differences of opinion over what
> constitutes good language design or how to define "compatible"
> continue. Scheme is in effect a great learning language, for now,
> but not very useful in the real world unless you're willing to write
> your own libraries -- but you seem interested in experimenting with
> functional programming from what you said, rather than having an
> industrial-strength, practical programming tool, so maybe that's
> okay.I'd like to throw in Scala here. Although it's not complete yet as a
language there are some interesting concepts (including functional) -
and you can use the wealth of libraries available for the JVM.
I have heard good things about both Scala and Clojure, though they both
suffer the limitation of requiring the JVM. I plan to give them both a
look this year, as well as Haskell, but have not gotten around to it yet.
>
> I'm pretty sure nobody is talking about the parallel programming
> advantages of VBA, either inside Excel or outside of it.I don't know how Excel works internally but it is completely possible
that evaluation updates are calculated in parallel. This is possible
because Excel knows all the value dependencies between cells.
Oh, I'm sure it does -- but Excel is not a programming language, so I'm
not sure it's meaningful to say that Excel's features as a functional
programming language provide any parallelism benefits.
Which brings me to something I have been wanting to ask: is there
something like a gem containing a DSL for such descriptions? I imagine
building dependency graphs (trees for the start) of tasks where output
of several other tasks can be fed into a task. That then would make
parallel execution pretty easy.
I'm curious about that as well, now.
>
> Maybe you'd like working with a database management system that
> offers some kind of stored procedures or triggered functions
> capabilities more. Excel is to DBMSes as those old Power Wheels toys
> are to actual cars, after all:
>
> Fisher Price Toys & Baby Gear | MattelHmm, I think I disagree. In parts you can use Excel (or any other
spreadsheet like OpenOffice, LibreOffice...) like a relational
database. But organizing and filtering data is just one part of
Excel's functionality - and one where it doesn't shine (once you get
into the 10,000 range of rows at least).
That was sorta my point.
But a spreadsheet application is mostly something different: a smart
way to lay out formulas in 2D to get instant calculations; basically it
is a event processor with user friendly user interface. (Note: in my
observation despite Excel's amazing capabilities many people seem to
feel more at home with stuffing tons of macros in their sheets where a
few smartly connected cell functions or a pivot table would have
sufficed).
That pretty much amounts to utilizing a minimal subset of the
capabilities of a proper DBMS plus some code that maps to the contents of
a DB table -- or, in DBMSes, plus some stored procedures (or stored
functions, or whatever). Is there something I'm missing?
···
On Thu, Mar 31, 2011 at 12:19:25AM +0900, Robert Klemme wrote:
On Wed, Mar 30, 2011 at 4:49 PM, Chad Perrin <code@apotheon.net> wrote:
>
> I disagree. I find myself doing a fair bit of functional style
> programming in small pieces within the larger object oriented style
> structure of code that I write in Ruby, and my code is better for it.And funnily enough I just posted my observation today, that more and
more languages incorporate functional features.
-> "[OT] functional paradigm taking over"
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
That's why it's homework.
···
On Mon, Apr 4, 2011 at 12:15 PM, Johnny Morrice <spoon@killersmurf.com> wrote:
Maths isn't hard
As someone doing his math homework as we speak, I beg to differ
--
Phillip Gawlowski
Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
I've seen some absolutely amazing things done with befunge! Networked
programs, even. Which is more than excel can do.
Sorry, what with all the bullshit I forgot to provide any evidence of
this fact:
http://zem.fi/~fis/fungot.b98.txt
It is not HTML vs PDF, it is the problems inherent in SICP which are
even detailed in some paper.
Basically SICP expects that you take and understand some mildly
advanced math courses before you take the course SICP was written for.
There are chapters with quite obscure examples which could be instead
constructed of problems easier to understand and more accessible to
the general public.
Some also argue that the book suffers from one awesome feature of LISP
- it does not differentiate between data and code.
While the feature is interesting and useful it may make the coding
more confusing for newcomers and make some of the examples needlessly
difficult and hard to understand due to quoting.
Thanks
Michal
···
On 4 April 2011 14:41, Josh Cheek <josh.cheek@gmail.com> wrote:
On Mon, Apr 4, 2011 at 4:28 AM, Stu <stu@rubyprogrammer.net> wrote:
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.htmlI have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
I haven't gone through it yet, but I have a PDF version I can upload if you
don't like the html format of that one. It should be understood, though,
that Ruby's functional support isn't the same as that of the purely
functional languages. That isn't to suggest you won't get insights from that
book, I know a lot of relevant people who have recommended it (ie Uncle Bob,
and Rick DeNetale).
Some problems are hard (generally by virtue of being complex compositions
of mathematical operations that are, taken individually, quite simple).
This does not mean the math itself is hard. The same can be true of
writing programs in Ruby.
···
On Mon, Apr 04, 2011 at 07:15:03PM +0900, Johnny Morrice wrote:
> Maths isn't hard
As someone doing his math homework as we speak, I beg to differ
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
I'd be interested in the pdf formatted version. Thank you.
···
On Mon, Apr 4, 2011 at 7:41 AM, Josh Cheek <josh.cheek@gmail.com> wrote:
On Mon, Apr 4, 2011 at 4:28 AM, Stu <stu@rubyprogrammer.net> wrote:
is this a good book to read to grok functional programming,
http://mitpress.mit.edu/sicp/full-text/book/book.htmlI have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
I haven't gone through it yet, but I have a PDF version I can upload if you
don't like the html format of that one. It should be understood, though,
that Ruby's functional support isn't the same as that of the purely
functional languages. That isn't to suggest you won't get insights from that
book, I know a lot of relevant people who have recommended it (ie Uncle Bob,
and Rick DeNetale).On Mon, Apr 4, 2011 at 6:31 AM, Everett L Williams II > <rett@classicnet.net>wrote:
*You have restated my point in much more pleasant language, and with
commendable precision.Hmm, I thought he deserved to be chastised for making a post almost 90% of
which was about databases. It fits quite nicely with the hypothesis that
he's just trolling.On Mon, Apr 4, 2011 at 7:29 AM, Johnny Morrice <spoon@killersmurf.com>wrote:
> I've seen some absolutely amazing things done with befunge! Networked
> programs, even. Which is more than excel can do.Sorry, what with all the bullshit I forgot to provide any evidence of
this fact:
http://zem.fi/~fis/fungot.b98.txtAmusingly, you added this on a whim, but it's more evidence than the Excel
proponents (sorry, I mean "S# programmers") have provided, despite several
explicit requests for clarification and examples.
Chad Perrin wrote:
Denigrating another person's choice of tools will certainly not make
that person likely to seek your advice again, nor consider you helpful.
I don't think anyone is denigrating the use of spreadsheets for problems
best solved by spreadsheets. People just object to describing MS Excel
as a better programming language than Ruby -- a pretty tall order, given
it is woefully inadequate to many tasks for which programming is done,
and is not in fact a "language" by any definition short of the sort of
mental gymnastics necessary to discuss 4GLs with a straight face.
*Somebody earlier suggested listening to Robert Martin's address to the RailsConf, and I did. It speaks to what can destroy a language, and it pretty much delineates the types of attitudes that are being brought forward here. Excel is being denigrated here, and that is foolish. Many people use spreadsheets all day long to accomplish their work. They are good with spreadsheets and comfortable with them. What is being said here is that they should throw away all that goodness and go to Ruby or something like Ruby, because it is better for some classes of problems. That's a little like taking a jackhammer out to get rid of the spots on your garage floor. Since most of these people will never need to program something that they cannot do in Excel, even if awkwardly, that seems foolish. Because of their familiarity with the tool they use most often, they can accomplish more with it in an hour than they could in days working with Ruby. No matter what tools you use to work with Ruby, it is a complete paradigm shift, and that is difficult for the average person who does not consider themselves a professional programmer. It may have taken them years to learn how to do what they now do in Excel, and Excel is only a stalking horse for a wider point here.
If your current tools, whatever they may be, are slowing or blocking you sufficiently that you must go to a new tool, or if you need an excellent tool for future work, something like Ruby makes all the sense in the world, but every advocate of something like Ruby should realize that Ruby is not an endpoint. In the fairly near future, we are going to progress to machines that never turn off and never reboot, and that do not distinguish applications. Ruby nor any other current language is equipped to deal with that type of environment. Things like genetic programming and fuzzy logic and really, machines that "think" like we do are the goal. Now I realize that eyes are rolling and so forth, but what I am trying to say is that Ruby is not nor will it be in that world, and that future is coming far faster than most imagine. If you get your nose so stuck down to the grindstone that all you can see is Ruby, then you will eventually suffer the same criticism as is being thrown at the guy who is using Excel at the moment. Working like the devil to make Ruby better, and to make it more accessible, are worthy expenditures of energy. Being offensively defensive about it and parsing definitions about what is and is not a programming language are complete wastes of time, and are self defeating.
At the moment, Ruby is not threatening to displace even COBOL and ForTran, much less C/C++ and Assembler, and there are hosts of simple tasks that really should not be done in Ruby or anything but a 4GL, you know, that target of a derisive earlier comment. I used one of the very first 4GL's, Easytrieve, and it allowed me to do in 15 minutes, what COBOL programmers were taking weeks or months to accomplish (note that I did not say good COBOL programmers). For reasonably complex data changes or for reports, it was literally an order of magnitude or two better than COBOL, and there are days that I would give my right arm to still have it. It is commercial and costs more than I can afford for my purposes. In the mean time, I really don't want to write reports in Ruby, though I realize that it is quite possible, and simple data fixes in Ruby, especially on new files for which I don't have schemas, aren't.
Everett L.(Rett) Williams II
** *
[snip]
That was an excellent example to illustrate my point. Thanks.
···
On Wed, Apr 13, 2011 at 01:22:31AM +0900, Phillip Gawlowski wrote:
On Tue, Apr 12, 2011 at 5:56 PM, Chad Perrin <code@apotheon.net> wrote:
>
> No -- it's a descriptive term. A pejorative term would be something like
> "blub language". The term "domain specific language" describes a
> narrower focus, which makes it more suitable to certain tasks than a
> domain nonspecific language, and less suitable to other tasks.
>
> You act as though "domain specific" is a synonym for "crippled", but
> that's not the case at all.To elaborate:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>> Are you saying that you're creating some kind of stand-alone variant
>> of VBA?Unfortunately most people think the words 'Excel' and 'programming'
must equal VBA. I spent a lot on a book called Professional Excel
Development which hardly mentions Excel itself. I think however in ome
circumstances VBA functions may have to be used eg to call realistic
SOAP services. The key is to keep them as functions ie no calling and
waiting. They should look exactly like in-built functions. Also the
accomplished S# programmer only uses them as a last resort.
I know that one can use other languages to manipulate data in Excel, but
when you use those other languages, you use those other languages -- and
not so much Excel (with its embedded macro language, VBA). When you say
"I'm using JScript with Excel," that doesn't mean VBA. When you say "I'm
using Excel," though, that to me *does* mean VBA -- or no programming
language at all.
>>
>> it's three metric tons of VM-like overheadbut seems to load faster than Ruby
Maybe on MS Windows. I hear rumors Ruby is slower on that platform. On
the other hand, on a dual-boot system, Ruby runs quickly enough for the
limited purposes for which I use it on Win7. It's faster on the Unixy
side, though.
Perhaps you're confusing preloaded application being presented to the
user with actually opening the application, though. The default behavior
for MS Office is to load the whole shebang when the OS starts up, and
just hide it from view until the user clicks the appropriate icon, thus
giving the appearance of very fast loading applications. The truth of
the matter is that it just consumes a lot of RAM even when you aren't
using it.
>>
>> Maybe you'd like working with a database management system that
>> offers some kind of stored procedures or triggered functions
>> capabilities more.Your remark is highly relevant. Tedd Codd deliberately designed the
relational model to eliminate the requirement to describe process. SQL
is a very powerful functional programming system. Stored procedures
however are usually...procedural.
By default, it's a bit more declarative than functional -- though with
various procedural extensions to SQL it is quite possible to do some FP
magic as well.
>>
>> Excel is to DBMSes as those old Power Wheels toys are to actual
>> cars, after all.I suspect you can do a lot of real world 'database' processing in Excel
-just like some folks use ActiveRecord (no - don't start me off on
ORMs...). On that basis, I guess a simple web site could use a lot of
functional programming functions without resorting to DBMS facilties.
You can also do a lot of real world traveling with one of those Power
Wheels toys, but it's slow, inefficient, burdened with a frustratingly
limited set of controls, and notably lacking on ability to scale to high
loads. Being able to do something with a given tool by no means suggests
it's a good tool for the job.
As I said earlier, one of the attractions is you have to think
differently.
Sometimes, I like to pretend I'm writing software meant to run in 128KB
of RAM, too.
···
On Thu, Mar 31, 2011 at 02:27:13AM +0900, Mike Stephens wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Chad Perrin wrote in post #990079:
···
On Thu, Mar 31, 2011 at 12:19:25AM +0900, Robert Klemme wrote:
I believe he means that Excel is a processor for dependent formulas
which, by virtue of update event propagation, gives you instantaneous
value updates in all relevant places.Option 2, then.
> okay.
I'd like to throw in Scala here. Although it's not complete yet as a
language there are some interesting concepts (including functional) -
and you can use the wealth of libraries available for the JVM.I have heard good things about both Scala and Clojure, though they both
suffer the limitation of requiring the JVM. I plan to give them both a
look this year, as well as Haskell, but have not gotten around to it
yet.
I don't know if you've seen the Pragmatic Programmer's book "Seven
Languages in Seven weeks". It gives brief overviews of Ruby, Io,
Prolog, Clojure, Scala, Erlang, and Haskell.
--
Posted via http://www.ruby-forum.com/\.