[OT] functional paradigm taking over
Robert Klemme
just notice there seems to be a trend in industry to include
functional language features everywhere - now it's even in the new
C++:
http://www2.research.att.com/~bs/C++0xFAQ.html#lambda
JDK 8 will also include lambda support:
http://blogs.oracle.com/henrik/2010/10/java_roadmap_from_javaone_2010.html
It seems that in times of excessive CPU capacity and multiple cores
people turn to features which give more dynamic as well as easier
implementation of concurrent applications (no synchronization needed
when going strict functional). Amazing that Lisp is one of the oldest
languages around still in use and its family seems to be prepared to
finally reach mainstream. :-)
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Mike Stephens
functional programming at the moment. Not, by the way, deeply
mathematical languages like F#, Haskell etc but a new very simple
easy-to-use language called S#.
Well it's not new at all. It's just Excel but you can't say that at
parties so I had to make up a new name.
People talk about the parallel programming advantages but what I like is
1) You can easily see what's going on. Every time you write a line of
code, you immediately see the consequences of what you've written. You
don't need to run anything, debug anything. That's of course a feature
of Excel in its role as an IDE that autocalculates.
2) Excel is innately efficient. It can run millions of calculations per
second.
3) It's good fun devising new algorithms. You've spent all your life
thinking in terms of iterations. Now you have to think of evaluating
variable length data structures and picking out the outcomes after
they've all 'run'. For example, if you want to service a web request,
you have to generate both the normal and error pages at the same time,
as you only have one shot in functional programming.
I got into this accidentally. I was working on using Ruby to script a
spreadsheet to provide insurance quotes. The more I looked at it the
more I could see Excel doing the logic until I wondered whether I could
virtually eliminate Ruby apart from web server handling - capturing the
incoming parameters and translating the output pages into HTML.
Most people would not want to pursue this line of thinking but I mention
it because it seems to me that you should either do functional or
imperative. Languages like Ruby which let you mix paradigms are going to
lead you into difficult decisions about what you use where.
My other feeling is that typical functional languages (like typical
imperative languages) are unnecessily complicated. People struggle to
develop the most terse solution and gain great pleasure from doing so,
but as an old fashioned programmer, I don't immediately see what they
gain, apart from the sort of pointless satisfaction you get from
finishing a cryptic crossword. It would be nice if any move towards
functional approaches didn't ignore opportunities to make things easier
as well.
--
Posted via http://www.ruby-forum.com/.
Robert Klemme
> On Wed, Mar 30, 2011 at 06:38:19PM +0900, Mike Stephens wrote:
>>
>> Although a Ruby fan, I must say I'm spending all my time looking at
>> functional programming at the moment. Not, by the way, deeply
>> mathematical languages like F#, Haskell etc but a new very simple
>> easy-to-use language called S#.
>>
>> Well it's not new at all. It's just Excel but you can't say that at
>> parties so I had to make up a new name.
>
That's usually where the intellectual fun begins. :-)
> 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.
> 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.
>> People talk about the parallel programming advantages but what I like
>
> 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. 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.
>> 1) You can easily see what's going on. Every time you write a line of
>> code, you immediately see the consequences of what you've written. You
>> don't need to run anything, debug anything. That's of course a feature
>> of Excel in its role as an IDE that autocalculates.
>>
>> 2) Excel is innately efficient. It can run millions of calculations per
>> second.
>>
>> 3) It's good fun devising new algorithms. You've spent all your life
>> thinking in terms of iterations. Now you have to think of evaluating
>> variable length data structures and picking out the outcomes after
>> they've all 'run'. For example, if you want to service a web request,
>> you have to generate both the normal and error pages at the same time,
>> as you only have one shot in functional programming.
>>
>> I got into this accidentally. I was working on using Ruby to script a
>> spreadsheet to provide insurance quotes. The more I looked at it the
>> more I could see Excel doing the logic until I wondered whether I could
>> virtually eliminate Ruby apart from web server handling - capturing the
>> incoming parameters and translating the output pages into HTML.
>
> 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:
>
> http://www.fisher-price.com/us/powerwheels/
Hmm, 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). 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).
>> Most people would not want to pursue this line of thinking but I
>> mention it because it seems to me that you should either do functional
>> or imperative. Languages like Ruby which let you mix paradigms are
>> going to lead you into difficult decisions about what you use where.
>
> 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"
Kind regards
Mike Stephens
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.
Martin DeMello
<short...@googlemail.com> wrote:
>
> It seems that in times of excessive CPU capacity and multiple cores
> people turn to features which give more dynamic as well as easier
> implementation of concurrent applications (no synchronization needed
> when going strict functional). Amazing that Lisp is one of the oldest
> languages around still in use and its family seems to be prepared to
> finally reach mainstream. :-)
I think the same thing is happening with closures, but we haven't
gotten as far. It's still possible to promulgate a language like Java
that doesn't have practical closures. At the time I started writing,
Python didn't have closures at all and I heard Guido van Rossum say
that they weren't important. I think that's wrong, and that in another
thirty years people will laugh at anyone who tries to invent a
language without closures, just as they'll laugh now at anyone who
tries to invent a language without recursion.
-- Mark Jason Dominus, in an interview on "Higher Order Perl"
http://www.theperlreview.com/Interviews/mjd-hop-20050407.html
martin
7stud --
> 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.
>
>
>
>> > 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.
>>
>> http://www.scala-lang.org/
>
> 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.
Phillip Gawlowski
>
> 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.
Not a Turing-complete language, anyway.
It's basically a(n econ) math and statistics library lacking a decent
programming language.
> 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?
Authentication and authorization, and table/row/cell locking.
--
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.
Mike Stephens
> I don't think it really qualifies as a language at all. It's more like
> an extensible set of cupboards with (non-graphing) calculators from the
> early '90s built into them.
You may be interested in this
http://www.programmingforums.org/thread15823.html which shows Excel
solving Dijkstra's Algorithm.
Excel is probably Turing complete (opinions differ) if you exclude the
notion of infinite sets.
If you consider a web site that collects user details, generates an
insurance quote and takes payment, then my initial assessment (I've not
built it yet) is Excel has the required features, including
authentication, logging, cookies etc. You would need a web server to
launch each Excel 'program', and you would need a module that converts
formatted Excel pages into HTML. Some functions like calling web
services and HTML formatting might practically have to be implemented as
non-Excel code (eg VBA or Ruby) but as these would require only simple
configuration they could be viewed as extensions to the inbuilt
functions and would not require programming ability on the part of the
user.
The issue (sometimes called the Turing Tarpit) is that Excel is a
programming alnguage but without many of the sophistications you see in
the likes of Ruby, and therefore may be unnecessarily awkward to program
in.
Nevertheless I think it is instructive. If you can imagine solving
practical problems in Excel then you should be able to solve the same
problems in the more accepted functional languages without being tempted
to slip back into imperative habits.
I guess my little bit of tinkering with this leads me to ask "Why should
I have to instruct the computer how to navigate data structures and code
my own error capturing? Why can't I just define what I want to see, and
then look at whether it turns out as I expected?"
Phillip Gawlowski
>
>> Authentication and authorization, and table/row/cell locking.
>
> DBMSes that do stored functions/procedures, like PostgreSQL and Oracle,
> do not?
The opposite. Definitely the opposite!
Josh Cheek
Coding everything in Excel might be an interesting paradigm to play with. It
might even reveal new ways of looking at problems that you hadn't previously
considered. But does it really warrant a title like "lambda shambda" and the
suggestion that it is easier than real languages like Haskell? It might be
possible (I'm skeptical) to write a web app in Excel, but is this really
something you'd want to do for anything other than an exercise?
I'm having a hard time telling whether you're just a little too excited
about this idea, trolling, or legitimately serious.
Mike Stephens
> is this really something you'd want to do for anything other than an
> exercise?
Excel is somewhat incidental to this discussion. It is not like
functional languages people normally think of. What I was saying is it
is interesting to think of new algorithms/patterns.
However, since you ask: Excel is by far the World's most widely used
programming language. We recently had someone on this channel asking how
to build an application to compare performance of schools. Something
like Rails is a huge jump for a newby. Leveraging Excel knowledge could
make this kind of thing so much more accessible.
But the other point is why does everybody make languages so difficult
these days? I have a degree in Physics but couldn't face trying to
unravel F# or Haskell. Don't tell me trying to fathom out complex
recursive functions is a good way to spend your day.
Of course, you have to encourage people to invent Lambda Calculus and
then turn it into a computing language but such university thesis ideas
shouldn't be seen as the model for real world products.
Phillip Gawlowski
>
> However, since you ask: Excel is by far the World's most widely used
> programming language.
As Carl Sagan once said: Extraordinary claims require extraordinary evidence.
Excel is an automation tool, certainly, but I wouldn't call a finance
sheet, sales report, or statistical analysis of data in a diagram
"programming".
> We recently had someone on this channel asking how
> to build an application to compare performance of schools. Something
> like Rails is a huge jump for a newby. Leveraging Excel knowledge could
> make this kind of thing so much more accessible.
But is the resulting product of similar quality as one done in an
actual programming language?
Across the metrics of code maintenance, compatibility (just hope that
MS doesn't ever change the behavior of a function your spreadsheet
happens to rely on, and that your spreadsheet works on all Excel
variants your clients might be running, since shelling out for a new
Excel version ain't cheap, nor is a corporate roll out easy to do),
and speed of development?
What about non-trivial applications, like a stock trading agent?
> But the other point is why does everybody make languages so difficult
> these days? I have a degree in Physics but couldn't face trying to
> unravel F# or Haskell. Don't tell me trying to fathom out complex
> recursive functions is a good way to spend your day.
Argument from authority. That you have a physics degree doesn't make
you a programmer. Nor does it make you particularly smart nor stupid,
or gives you the mindset a programmer should have. It makes you a
physicist, nothing more. That's kind of like saying that a bookkeeper
is a programmer because (s)he uses spreadsheets.
And really, if you have problems with recursiveness, I dare say that
you didn't enjoy college, considering the importance of maths in the
natural sciences. Just plain ol' acceleration is a recursive function:
changes of velocity over time are easiest calculated by recursion,
wouldn't you say?
Functional programming requires a particularly, let's say
anal-retentive, mindset, given the importance of type safety, and that
variables, usually, aren't variables. On the flipside, it makes
concurrency easier, and is a boon for critical code (you know,
robotics, MRI scanners, &c.).
> Of course, you have to encourage people to invent Lambda Calculus and
> then turn it into a computing language but such university thesis ideas
> shouldn't be seen as the model for real world products.
Yet there were ~7000 LISP machines sold (at, say, 100 000 per unit,
that's still quite a bit of revenue):
http://en.wikipedia.org/wiki/Lisp_machine
Robert Klemme
> On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens<rub...@recitel.net> wrote:
>> But the other point is why does everybody make languages so difficult
>> these days?
I am not sure I fully agree to this observation. First, I believe
languages are rather becoming simpler than more complex these days. On
the other hand with increased power of hardware and increased volume of
library code the problems that we tackle today are becoming increasingly
complex. Also, the mere fact that we need to utilize concurrency to
solve problems (because single CPU isn't going to grow that much in the
near future) does make applications more complex.
>> I have a degree in Physics but couldn't face trying to
>> unravel F# or Haskell. Don't tell me trying to fathom out complex
>> recursive functions is a good way to spend your day.
>
> Argument from authority. That you have a physics degree doesn't make
> you a programmer. Nor does it make you particularly smart nor stupid,
> or gives you the mindset a programmer should have. It makes you a
> physicist, nothing more. That's kind of like saying that a bookkeeper
> is a programmer because (s)he uses spreadsheets.
>
> And really, if you have problems with recursiveness, I dare say that
> you didn't enjoy college, considering the importance of maths in the
> natural sciences. Just plain ol' acceleration is a recursive function:
> changes of velocity over time are easiest calculated by recursion,
> wouldn't you say?
>
> Functional programming requires a particularly, let's say
> anal-retentive, mindset, given the importance of type safety, and that
> variables, usually, aren't variables. On the flipside, it makes
> concurrency easier, and is a boon for critical code (you know,
> robotics, MRI scanners,&c.).
Personally what I find most difficult to grasp about functional
programming is not the paradigm itself but rather the feature of Lisp
that macros and functions are syntactically indistinguishable. While
this makes for elegant solutions on one hand it can be confusing to read
on the other (and just think about the various quoting mechanisms of
Lisp). YMMV though.
>> Of course, you have to encourage people to invent Lambda Calculus and
>> then turn it into a computing language but such university thesis ideas
>> shouldn't be seen as the model for real world products.
>
> Yet there were ~7000 LISP machines sold (at, say, 100 000 per unit,
> that's still quite a bit of revenue):
>
> http://en.wikipedia.org/wiki/Lisp_machine
Even if there weren't where's the argument? All engineering is based on
results of science of one form or another (and math is often one of
them). If research turns up something which can be used to model real
world phenomena of a particular class more efficiently than other
approaches then it should (and will) be used. There's still enough room
to apply other approaches and nobody forces Mike to go functional, does he?
Johnny Morrice
> should I have to instruct the computer how to navigate data
> structures and code my own error capturing?
Gee if only you had strong typing you wouldn't get those errors. And
if only the compiler could generate the code for your specific use case
on a specific data structure, given that you could prove it held
certain properties...
.but wait, that sounds like that horrible functional school! SHUN
THOSE TECHNIQUES, SHUN THEM MY PRETTIES!
> You would need a web server to launch each Excel 'program', and you
> would need a module that converts formatted Excel pages into HTML.
> Some functions like calling web services and HTML formatting might
> practically have to be implemented as non-Excel code (eg VBA or Ruby)
> but as these would require only simple configuration they could be
> viewed as extensions to the inbuilt functions and would not require
> programming ability on the part of the user.
Assuming our developers are possessed of sound mind, they
may instead choose to achieve your aims in this manner:
1. Data is generated from the spreadsheet and inserted into a
database.
2. Then a dynamic website (not written in Excel) reads from the
database.
This is an example of how different software tools, each specialized
for a different task, work together to perform a cohesive action.
Everything has its place.
IMO that is the way of the Tao. Choosing Excel above all
else does not lead to the Tao. Instead it leads down the path of Rube
Goldberd, that you illustrate above.
Cheers
Johnny
Phillip Gawlowski
<short...@googlemail.com> wrote:
>
> I am not sure I fully agree to this observation. First, I believe languages
> are rather becoming simpler than more complex these days. On the other hand
> with increased power of hardware and increased volume of library code the
> problems that we tackle today are becoming increasingly complex. Also, the
> mere fact that we need to utilize concurrency to solve problems (because
> single CPU isn't going to grow that much in the near future) does make
> applications more complex.
Further, if anyone thinks that using a modern language is complex and
/ or difficult, I recommend some quality time with x86 assembly.
I still have nightmares from IT class back in school, and it's been *years* ;)
> Personally what I find most difficult to grasp about functional programming
> is not the paradigm itself but rather the feature of Lisp that macros and
> functions are syntactically indistinguishable. While this makes for elegant
> solutions on one hand it can be confusing to read on the other (and just
> think about the various quoting mechanisms of Lisp). YMMV though.
Though, I'd be careful in calling LISP a functional programming
language. While it *does* use the lambda calculus, it doesn't
guarantee that functions are free from side effects. And its raison de
entrée is that data and code are mutable, which is antithetical to
pure-bred functional programming languages.
Though, considering that LISP was one of, if not the, first language
to use the lambda calculus as basis for a programming language, it is
certainly a forefather of today's crop of functional programming
languages, like Scheme, ML, Erlang, Haskell, or F#.
Everett L Williams II
*Let's not pay too much attention to the code snobs on here. I've yet to
see a recursive function that is more efficient than a more linearly
coded function that accomplishes the same thing, and there is always the
problem of curtailing recursion. People often mistake shortest code for
the most efficient or effective, and that is seldom true. In addition,
there are a whole host more people who can write acceptable programs in
Excel than there are who can do so in Ruby or probably the sum of all
the languages that are in that category. Most of them are not as pretty
to the mind of someone who programs for a living, but I have seen a
whole lot more things written in Excel..repeat...repeat. That does not
mean that it is desirable to write highly complex and detailed projects
in Excel, largely because of the distribution cost. If Excel were free,
you would see even more stuff written in it. The other main defects in
Excel are that it is hard to control a product written in it because you
are dependent on Microsoft-ian whims. The latter is the least of the
problems. You also have to have a lot more financial muscle to get into
the Excel game at the commercial level. And last, there is the question
of portability/compatibility across various environments. If you are
after the 80-90% of intel x86 compatible machines that run Windows, that
is not an issue. I won't even say that maintenance is a bigger problem
in Excel, though the issue can be argued in many different ways.
Once you have made up your mind to use a tool like Ruby, you have to
pick a flavor, and you really need to know C/C++ as well as Ruby to
really be able to use Ruby. If you intend to have cross-platform
support, you need to understand the subtleties of the various platforms
you intend to support, which is a problem in almost any language. Perl
and Python and especially java should also be considered, especially if
there is a history of coding in one of those languages within your
organization. All that aside, Ruby is an excellent and well supported
tool, well worth your time and effort, but something that should be
considered is that the simplest tool that is effective should usually be
used. Good luck.
Everett L.(Rett) Williams II
*
Phillip Gawlowski
<re...@classicnet.net> wrote:
> *Let's not pay too much attention to the code snobs on here. I've yet to see
> a recursive function that is more efficient than a more linearly coded
> function that accomplishes the same thing, and there is always the problem
> of curtailing recursion. People often mistake shortest code for the most
> efficient or effective, and that is seldom true.
Which you are doing at the moment, it appears. It's a straw man,
anyway: nobody was talking about performance.
> In addition, there are a whole host more people who can write acceptable programs in Excel than there
> are who can do so in Ruby or probably the sum of all the languages that are
> in that category.
Extraordinary claims require extraordinary evidence. So, show the
evidence, please. Also: define "acceptable".
> If you are after the 80-90% of intel x86 compatible machines
> that run Windows, that is not an issue. I won't even say that maintenance is
> a bigger problem in Excel, though the issue can be argued in many different
> ways.
How many of these machines run Excel, and in a compatible flavour to
whatever you want to sell based off of Excel?
If we are arguing market segments, we all should be writing software
in ActionScript, and distribute Flash files (95% or so market
penetration across all x86 machines installed world-wide, and a major
chunk of the Android market in smart phones).
> Once you have made up your mind to use a tool like Ruby, you have to pick a
> flavor, and you really need to know C/C++ as well as Ruby to really be able
> to use Ruby. If you intend to have cross-platform support, you need to
> understand the subtleties of the various platforms you intend to support,
> which is a problem in almost any language. Perl and Python and especially
> java should also be considered, especially if there is a history of coding
> in one of those languages within your organization. All that aside, Ruby is
> an excellent and well supported tool, well worth your time and effort, but
> something that should be considered is that the simplest tool that is
> effective should usually be used. Good luck.
Yeah, and I doubt that in 99% of all cases that aren't spreadsheets or
statistics, Excel is the tool one should use.
Anecdote:
My EE prof used Excel to invert a matrix. Took about 30 minutes, and
was far from obvious (I forgot how it was done, since it was
definitely something Excel wasn't designed to do), when a specialized
tool (Maple in this case), did the same job in one line of code,
following the mathematical notation (M_inverse := M^-1).
Thus, I wouldn't use Excel to write a tool to analyse an electrical network.
Martin DeMello
<cmdja...@googlemail.com> wrote:
> On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens <rub...@recitel.net> wrote:
>>
>> However, since you ask: Excel is by far the World's most widely used
>> programming language.
>
> As Carl Sagan once said: Extraordinary claims require extraordinary evidence.
>
> Excel is an automation tool, certainly, but I wouldn't call a finance
> sheet, sales report, or statistical analysis of data in a diagram
> "programming".
No less a person than Simon Peyton Jones has called Excel "the world's
most popular functional language".
http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/
martin
Mike Stephens
> Anecdote:
> My EE prof used Excel to invert a matrix. Took about 30 minutes, and
> was far from obvious (I forgot how it was done, since it was
> definitely something Excel wasn't designed to do), when a specialized
> tool (Maple in this case), did the same job in one line of code,
> following the mathematical notation (M_inverse := M^-1).
Would that remark still apply if Excel had - let's say - a function
MINVERSE() - a similar single line of code?
Well, interestingly, I do believe it does.
Have a look at eg
http://www.chem.mtu.edu/~tbco/cm3450/Excel_Array_Formulas.pdf
I suspect people don't realise what power Excel has, because hardly
anyone talks about it. They either talk about everyday corporate number
crunching or conventional programming lnaguages. Few people think about
taking Excel's components and mixing them together to solve
simultanaeous linear equations.
Josh Cheek
On Sun, Apr 3, 2011 at 6:50 AM, Phillip Gawlowski <
cmdja...@googlemail.com> wrote:
>
> Though, considering that LISP was one of, if not the, first language
> to use the lambda calculus as basis for a programming language, it is
> certainly a forefather of today's crop of functional programming
> languages, like Scheme, ML, Erlang, Haskell, or F#.
>
>
I'm not particularly familiar with its history, but I don't think Common
Lisp was the original dialect of Lisp.
On Sun, Apr 3, 2011 at 7:17 AM, Everett L Williams II
<re...@classicnet.net>wrote:
> *Let's not pay too much attention to the code snobs on here. I've yet to
> see a recursive function that is more efficient than a more linearly coded
> function that accomplishes the same thing,
There are many types of efficiency, there is also efficiency of
comprehension, and implementation, and it is much easier to comprehend and
implement recursion in many situations.
Here is an example of a Binary Search Tree with a recursive_print method and
a "linearly coded function that that accomplishes the same thing" (I assume
by "linear" you mean "imperative"). I can barely comprehend the linear
version, and I wrote it. If you can come up with a better version, please
post it.
class BST
attr_accessor :left , :right , :data
def << new_data
if !data
self.data = new_data
elsif new_data <= data
( self.left ||= BST.new ) << new_data
else
( self.right ||= BST.new ) << new_data
end
self
end
# this is for simplicity of the exercise, in reality it
# would be an each method and the code using it
# would make it print
def recursive_print
left && left.recursive_print
data && puts(data)
right && right.recursive_print
end
def iterative_print
todo = []
crnt = self
loop do
if crnt && crnt.left
todo.push crnt
crnt = crnt.left
elsif crnt && crnt.right
puts crnt.data
crnt = crnt.right
else
puts crnt.data if crnt && crnt.data
crnt = todo.pop
break unless crnt
puts crnt.data if crnt.data
crnt = crnt.right
end
end
end
end
root = BST.new << 7 << 3 << 1 << 0 << 2 << 5 << 4 \
<< 6 << 11 << 9 << 8 << 10 << 13 << 12 << 14
root.recursive_print
puts
root.iterative_print
I decided to benchmark it, just to see how much faster it really is. And it
actually turns out to be slower. In this case, the recursive version is not
only elegant, easier to read, write, and comprehend, but it is also faster.
def no_output
stdout = Object.new
def stdout.write(*params) end
def stdout.puts(param) end
$stdout = stdout
yield
ensure
$stdout = STDOUT
end
require 'benchmark'
Benchmark.bm 10 do |b|
b.report "recursive" do
no_output do
100_000.times { root.recursive_print }
end
end
b.report "linear" do
no_output do
100_000.times { root.iterative_print }
end
end
end
# RESULTS
# user system total real
# recursive 0.840000 0.000000 0.840000 ( 0.843655)
# linear 1.040000 0.010000 1.050000 ( 1.059313)
On Sun, Apr 3, 2011 at 8:13 AM, Martin DeMello <martin...@gmail.com>wrote:
>
> No less a person than Simon Peyton Jones has called Excel "the world's
> most popular functional language".
>
> http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/
>
> martin
>
>
It might be easier if you guys could show how one writes a program in excel.
OP was talking about a web app, complete with authentication, authorization,
cookies, "etc". I can't even conceive of how one would go about doing such a
thing. I wouldn't even know how to execute an Excel program (do you make an
executable? do you invoke it on the command line? is there an interpreter?
compiler?). Here are some examples of programs I've written this semester in
Ruby:
* A Shoes app to help me in my Chem lab by watching the time and telling me
to take a measurement every n seconds. (
http://img209.imageshack.us/img209/2602/93593675.png)
* A program to go through my music and rename all my mp3s to
"#{mp3.tag['artist']} - #{mp3.tag['title']}", it is invoked on the command
line, you pass it the directory with the mp3s that it should rename.
* A program to create Conway's game of life videos (
http://vimeo.com/21594165)
Is it even possible (let alone viable) to do any of this in Excel? And if
so, then why do they bother bundling VBA with Excel? Seems redundant.
Phillip Gawlowski
> Phillip Gawlowski wrote in post #990664:
>
> MINVERSE() - a similar single line of code?
>
> Well, interestingly, I do believe it does.
Just for giggles, let's compare Maple and Excel. Since you nicely
provided the Excel 2007/2010 example, I'll provide a real-world
example* of matrix inversion in Maple**.
<code>
with(LinearAlgebra):
M := Matrix([ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]);
M_inverted := M^(-1);
</code>
* Modified a bit, since I doubt anyone cares about the exact details
of what the matrix contains.
** I have Maple 14, but AFAIK, the package LinearAlgebra/linalg usage
hasn't changed between versions, though LinearAlgebra is the New and
Improved flavour.
The worksheet version is nicer, since it provides proper formatting,
but is difficult to show off when sticking to plain text email.
> I suspect people don't realise what power Excel has, because hardly
> anyone talks about it. They either talk about everyday corporate number
> crunching or conventional programming lnaguages. Few people think about
> taking Excel's components and mixing them together to solve
> simultanaeous linear equations.
Considering the hoops I have to jump through to pull the same thing in
Excel, I'll stick with picking the right tool for the job.
Sure, I can get a sledgehammer and make the square peg fit the round
hole, but what, aside from a broken hole, do I gain?
For other operations, like polynominal division, Excel becomes pretty
useless, since it can't add up numbers properly (resulting in
fantastically large results, when the excepted result is something
like "y = 4" for a singularity on the x-axis). Nor does it support
polar form representation of complex numbers (very, very, very nice to
have to do a network analysis with alternating current, especially if
you want to minimize rounding errors).
All that makes Excel a rather bad choice when it comes to engineering.
That doesn't even touch on programming yet: Excel can't deal with a
problem space outside of statistics and finance.
TL;DR: You don't need to be a programmer to program, but the tool of
choice needs to be able to support what you want to do, and do so
efficiently (in time spent by the user, not CPU cycles).
BTW: "matrix" and "linear system of equations" are *not* synonymous.
Johnny Morrice
> It might be easier if you guys could show how one writes a program in
> excel. OP was talking about a web app, complete with authentication,
> authorization, cookies, "etc". I can't even conceive of how one would
> go about doing such a thing.
There are some fun looking Excel games
http://www.cpearson.com/excel/games.htm
Don't have excel to hand so I haven't tried them
(Note that I wouldn't have this problem if they were written in pretty
much any other language)
> * A program to create Conway's game of life videos (
> http://vimeo.com/21594165)
That's pretty cool! I made something similar, it rendered wireworld
cellular automatons to animated gifs with smalltalk and gnu plotter.
Great fun that sort of thing :)
Cheers
Johnny
Phillip Gawlowski
>
> They aren't all "so difficult". They just reward a different approach to
> automation than Excel -- an approach that does not overconsume resources
> so much, that scales better, that allows for easier composition of
> complex algorithms from simple algorithms, and that supports greater
> productivity for the expert.
And provides a certain beauty in clarity and logic, that only maths
can provide, IME.
> Actually, the consequences of that kind of thinking results in
> programming languages that allow us to leverage our capabilities much
> more efficiently (and I'm not just talking about clock cycles, here), so
> that we can build upon past advances to produce more substantial and
> amazing advances in the future.
Like concurrency being a "free by" of functional languages, thanks to
immutable data, and lambda calculus allows for easy parallelization,
since the algorithm is already broken down into its simplest pieces.
> Giving up on the cutting edge just
> because you don't understand it yet only limits you.
Considering that the idea of a "compiler" appeared around 1952 (with
the first complete compiler appearing in '57, called FORTRAN,
apparently), and LISP was formalized in 1958, it's not really that
cutting edge, either. Nor is functional programming, if we consider
APL from 1957*...
It's just that compilers moved into the mainstream relatively fast,
and only now that Moore's Law is breaking down, and we are thus using
multiple cores even in the cheapest hardware (there's dual-core phones
now, ferchrissakes), that the issues of concurrency and
parallelization come to the fore, and with them functional
programming.
* I consider immutable data to be key to functional programming, and
LISP doesn't work that way, so *I* don't see it as a functional
language. YMMV, of course.
Josh Cheek
Hmm, when you post, it fragments into a new thread in my gmail. I assume
because you change the subject. I'm trying to figure out how to fix it (
http://www.google.com/support/forum/p/gmail/thread?tid=63a2a74c9f70e02d) but
doesn't look like it will happen any time soon. Meanwhile, I'd be
appreciative if you could just make the new subject be "Re:
#{original_subject}"
(musing: I wonder how ruby-forum knows they are part of the same thread.)
serialhex
@Josh
ruby == magic
therefore:
ruby-talk magically knows where your posts are supposed to be :P
hex
Chris
>> (musing: I wonder how ruby-forum knows they are part of the same thread.)
Message-Id: <BANLkTimyG9fY4whP...@mail.gmail.com>
In-Reply-To: <BANLkTincwvtAjiJC...@mail.gmail.com>
References: <BANLkTimKuriDuVMQRFSTs_=7W_iy...@mail.gmail.com>
<3ab1912e670b0821...@ruby-forum.com>
<20110330143...@guilt.hydra>
<BANLkTin=+Bo2dnUKeyXGH...@mail.gmail.com>
<20110330192...@guilt.hydra>
<AANLkTinFH7qX=vyRr8qMQMbbXgHO...@mail.gmail.com>
<20110331053...@guilt.hydra>
<7631a84ea921373c...@ruby-forum.com>
<AANLkTinN-VCZ-L=kvPq0Rme489QDx...@mail.gmail.com>
<f15449f5b9c44881...@ruby-forum.com>
<BANLkTikT8Vqz6rJGOZz91_58-8g=FQX...@mail.gmail.com>
<4D98655...@classicnet.net>
<BANLkTik5iY7z3JaN...@mail.gmail.com>
<121ff4897c1b5f72...@ruby-forum.com>
<BANLkTincwvtAjiJC...@mail.gmail.com>
http://en.wikipedia.org/wiki/Email
Josh Cheek
On Sun, Apr 3, 2011 at 3:06 PM, Johnny Morrice <sp...@killersmurf.com>wrote:
>
> > It might be easier if you guys could show how one writes a program in
> > excel. OP was talking about a web app, complete with authentication,
> > authorization, cookies, "etc". I can't even conceive of how one would
> > go about doing such a thing.
>
> There are some fun looking Excel games
> http://www.cpearson.com/excel/games.htm
>
> Don't have excel to hand so I haven't tried them
> (Note that I wouldn't have this problem if they were written in pretty
> much any other language)
>
>
Yeah, I don't have Excel, either :/
The page says "All of the VBA code is unprotected, so you are free to see
how it works." So that implies to me that this is not what we are talking
about, though, because it was Chad Perrin's initial assumption that
programming in Excel meant VBA, but Mike responded with "Unfortunately most
people think the words 'Excel' and 'programming' must equal VBA. [...] the
accomplished S# programmer only uses [VBA] as a last resort." ("S#" seems to
be a name Mike made up for programming in Excel).
I did try loading it up in Open Office, but it uses VBA macros, which I
couldn't get to work. I was surprised to see that it looked decent (
https://s3.amazonaws.com/josh.cheek/scratch/excel-game.png) so apparently
Excel has more powerful formatting capabilities than I realized. But, web
browsers have powerful formatting, and that doesn't make them programming
languages.
> > * A program to create Conway's game of life videos (
> > http://vimeo.com/21594165)
>
> That's pretty cool! I made something similar, it rendered wireworld
> cellular automatons to animated gifs with smalltalk and gnu plotter.
> Great fun that sort of thing :)
>
>
Thanks ^_^
On Sun, Apr 3, 2011 at 3:07 PM, Phillip Gawlowski <
cmdja...@googlemail.com> wrote:
>
> * I consider immutable data to be key to functional programming, and
> LISP doesn't work that way, so *I* don't see it as a functional
> language. YMMV, of course.
>
>
Common Lisp doesn't, but other Lisp dialects do (Scheme, Clojure).
I've noticed several different uses of "functional" though, some mean purely
functional (no side effects) like you are saying, ie Haskell and Clojure.
And others just mean that you basically have support for closures and first
order functions (Common Lisp, Ruby, JavaScript).
So it is sometimes difficult to talk about :/ I typically tell people that
Ruby "supports a functional paradigm", but that maybe doesn't identify
important nuances, and as Robert pointed out, most languages are headed in
that direction.
Johnny Morrice
Perhaps he was thinking of the matrix of coefficients used when solving
such systems.
I'm rather astounded this debate could last so long, it seems so silly.
Anyway, here are some points of non-issue I feel have emerged.
* Excel isn't a proper programming language
* But if you do consider it a language, then it would be a functional
language.
* Functional programming, despite its faults, isn't particularly weird
or difficult at all. Which isn't so strange Mike, when you consider
the last point.
* Please Mike, go write us something cool in Excel and send it back to
the list, to show us how awesome it is when compared to other
languages. Josh has some suggestions!
Cheers
Johnny
Petite Abeille
On Apr 3, 2011, at 10:34 PM, serialhex wrote:
> ruby-talk magically knows where your posts are supposed to be :P
Not quite magic, just the 'In-Reply-To' and 'References' email header.
http://tools.ietf.org/html/rfc2822#section-3.6.4
More on the subject of message threading, courtesy of Jamie Zawinski:
http://www.jwz.org/doc/threading.html
Chris
>
> More on the subject of message threading, courtesy of Jamie Zawinski:
>
> http://www.jwz.org/doc/threading.html
>
+1 for this one, well written (but sad) and the uber-cool menu ;)
http://www.jwz.org
Phillip Gawlowski
>
> I don't really give a crap what's popular, nor who has said it was
> popular, when choosing something for merit. I'm also not entirely
> convinced he thinks popularity is any kind of sign of quality (given his
> involvement in GHC development, which is nothing at all like Excel), nor
> that his statement of popularity of Excel as a functional "language" is
> unbiased, given his employment at Microsoft employee for a dozen years or
> so.
Though, Microsoft Research is a different beast than MS proper (as
much as a "MS proper" can exist with such a corporation), and doesn't
have to toe the party line as much as the Office Business Unit would
have to, for example.
> Excel is a *spreadsheet* -- which happens to have a programming language
> embedded in it (and not a very good one, at that).
That's a bit harsh. After all, Excel doesn't have to *be* a language VM.
Thus, it only needs a DSL, and Excel's DSL is a damned good one, and
thorough in tackling its problem space. Further, Excel doesn't need to
be Turing-complete: Spreadsheets have many areas that they can be used
in, and in pretty much all of them the business rules are too complex,
or too much of a moving target, to make programming in the more
traditional sense feasible.
And that's why MS provides OLE Automation, and makes it relatively
easy to develop Office add-ins for specific needs.
Mike Stephens
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
etc
What this represented was
2011/Q1 Sales = £200
2011/Q2 Sales = £300
2011/Q2 Sales = £150
Worse still you would have:
12
200
27
300
etc
which meant:
2011/Q1 Sales = £200
2011/Q1 Units = 12
2011/Q2 Sales = £300
2011/Q2 Units = 27
etc
Tedd 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
etc
Whilst- 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?
Johnny Morrice
> 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?
Your argument is fap: programming isn't an abstract philosophy.
Meaningful debate is impossible without evidence.
Please provide specific examples. Show us something you don't
understand.
Cheers
Johnny
Everett L Williams II
Phillip Gawlowski wrote:
> On Sun, Apr 3, 2011 at 2:17 PM, Everett L Williams II
> <re...@classicnet.net> wrote:
>
>> *Let's not pay too much attention to the code snobs on here. I've yet to see
>> a recursive function that is more efficient than a more linearly coded
>> function that accomplishes the same thing, and there is always the problem
>> of curtailing recursion. People often mistake shortest code for the most
>> efficient or effective, and that is seldom true.
>>
> Which you are doing at the moment, it appears. It's a straw man,
> anyway: nobody was talking about performance.
>
*And, of course, since we were talking about making a practical decision
about which tool to use, performance cannot possibly matter. There is
also this overriding compulsion amongst coders to produce the most
abbreviated code possible, assuming that such demonstrates their special
skills and that such code is the most desirable. Any study of
algorithmic efficiency will show clearly that the shortest code is
almost never the fastest code, especially in unoptimized code.*
>
>> In addition, there are a whole host more people who can write acceptable programs in Excel than there
>> are who can do so in Ruby or probably the sum of all the languages that are
>> in that category.
>>
> Extraordinary claims require extraordinary evidence. So, show the
> evidence, please. Also: define "acceptable".
>
*If this were an extraordinary claim, your comment would hold true, but
only exceptional arrogance would cause any other claim to be made.
"Acceptable" means satisfactory to the person doing the programming, who
is usually some grunt just trying to get his job done, rather than
someone who is a proponent of any particular thing. I'll try not talk
about "fanboys" here.*
>> If you are after the 80-90% of intel x86 compatible machines
>> that run Windows, that is not an issue. I won't even say that maintenance is
>> a bigger problem in Excel, though the issue can be argued in many different
>> ways.
>>
> How many of these machines run Excel, and in a compatible flavour to
> whatever you want to sell based off of Excel?
>
*When I am responsible for something, unless some feature in the current
version is absolutely necessary, I tend to drop back one or two versions
to cover most of my market, not to mention to avoid the hazards of being
on the bleeding edge.*
> If we are arguing market segments, we all should be writing software
> in ActionScript, and distribute Flash files (95% or so market
> penetration across all x86 machines installed world-wide, and a major
> chunk of the Android market in smart phones).
>
*You said it. I didn't. Remember what I said about using the simplest
tool that will get the job done.*
>
>> Once you have made up your mind to use a tool like Ruby, you have to pick a
>> flavor, and you really need to know C/C++ as well as Ruby to really be able
>> to use Ruby. If you intend to have cross-platform support, you need to
>> understand the subtleties of the various platforms you intend to support,
>> which is a problem in almost any language. Perl and Python and especially
>> java should also be considered, especially if there is a history of coding
>> in one of those languages within your organization. All that aside, Ruby is
>> an excellent and well supported tool, well worth your time and effort, but
>> something that should be considered is that the simplest tool that is
>> effective should usually be used. Good luck.
>>
> Yeah, and I doubt that in 99% of all cases that aren't spreadsheets or
> statistics, Excel is the tool one should use.
>
*Having made the progression from Assembler to COBOL and FORTRAN and on
to dozens of other languages, I would have agreed with you until I
started seeing people write all sorts of stuff in Excel. Again, I would
never have recommended those uses, but they seemed to do the job.*
> Anecdote:
> My EE prof used Excel to invert a matrix. Took about 30 minutes, and
> was far from obvious (I forgot how it was done, since it was
> definitely something Excel wasn't designed to do), when a specialized
> tool (Maple in this case), did the same job in one line of code,
> following the mathematical notation (M_inverse := M^-1).
>
> Thus, I wouldn't use Excel to write a tool to analyse an electrical network.
>
>
*No, if I were going to do a lot of work with matrices, I would use
Mathlab or one of the various libraries that specialize in that kind of
work. Actually, "I" would probably use APL or one of the variants,
because it is flatly designed for work with matrices and can do in one
line what would take a whole page of equations. Of course, I wouldn't
really recommend APL, because it is one of those languages that is
almost impossible to maintain if you did not write it yourself. APL is
famous for having working code that no one can figure out. On the other
hand, matrices are not the only method for working such problems. From
what I know of it, I wouldn't use Excel for huge classes of problems,
but some people seem to be able to twist it to do things that I would
never have guessed. "To the man with a hammer, everything looks like a
nail."...even when a screw or glue might do a better job. The point is
that he knows how to use the hammer and can get prodigious amounts of
work done with it, so he has to think very carefully when someone tells
him he has to learn this new and completely different tool while the
work gets behind.
About 50% of the real newbies to programming who come on this site with
a complex project that requires unstable parts of the Ruby pantheon,
should be told to use another tool, one that is simpler, more mature,
and that does a better job of handholding, but people who spend most of
their time on Ruby tend to think with their hammer, so to speak, or
maybe, they don't really know anything else.
Everett L.(Rett) Williams II
Everett L
*
Johnny Morrice
Stu
http://mitpress.mit.edu/sicp/full-text/book/book.html
I have done some lisp but interested in gaining the skillset with ruby,
any nice thick comp sci books for recommendation?
Phillip Gawlowski
<re...@classicnet.net> wrote:
>
> *And, of course, since we were talking about making a practical decision
> about which tool to use, performance cannot possibly matter. There is also
> this overriding compulsion amongst coders to produce the most abbreviated
> code possible, assuming that such demonstrates their special skills and that
> such code is the most desirable. Any study of algorithmic efficiency will
> show clearly that the shortest code is almost never the fastest code,
> especially in unoptimized code.*
Strawman, again.
We were not talking about performance. 'sides, premature optimization
is the root of all evil. Once there's benchmarks and solid data on
load and usage, we can talk about optimizing for performance. Enjoy
making an Excel spreadsheet multi-threaded, though. Excel 2007 isn't
cheap (which introduced multi-threading for spreadsheets).
> *If this were an extraordinary claim, your comment would hold true, but only
> exceptional arrogance would cause any other claim to be made. "Acceptable"
> means satisfactory to the person doing the programming, who is usually some
> grunt just trying to get his job done, rather than someone who is a
> proponent of any particular thing. I'll try not talk about "fanboys" here.*
It's called burden of proof. You make a claim, you go prove it.
Further: given your definition of acceptable, any code at all,
qualifies as "acceptable", no matter its performance (you brought it
up), maintainability (the comptroller will bring *that* up), or
buggyness (So what if the application crashes and burns if a variable
isn't formatted as expected?).
> *When I am responsible for something, unless some feature in the current
> version is absolutely necessary, I tend to drop back one or two versions to
> cover most of my market, not to mention to avoid the hazards of being on the
> bleeding edge.*
How many of all machines running Windows run Excel as well, and in
which versions?
What you tend to do is irrelevant, I want to know if a tool based off
of Excel has a viable market.
> *Having made the progression from Assembler to COBOL and FORTRAN and on to
> dozens of other languages, I would have agreed with you until I started
> seeing people write all sorts of stuff in Excel. Again, I would never have
> recommended those uses, but they seemed to do the job.*
Well, then you can provide a non-trivial example of an Excel
spreadsheet that doesn't use VBA, right?
> On the other hand, matrices are not the only method
> for working such problems.
In EE, it's the fastest, least error-prone method to analyze networks,
since you can use Kirchhoff's circuit laws.
> From what I know of it, I wouldn't use Excel for
> huge classes of problems, but some people seem to be able to twist it to do
> things that I would never have guessed. "To the man with a hammer,
> everything looks like a nail."...even when a screw or glue might do a better
> job. The point is that he knows how to use the hammer and can get prodigious
> amounts of work done with it, so he has to think very carefully when someone
> tells him he has to learn this new and completely different tool while the
> work gets behind.
And that is the rub: People don't know better. The reasons are
multiple, but that's what it comes down. If all I know is how to drive
a car with automatic transmission, I won't be able to get the best out
of a car with manual transmission.
> About 50% of the real newbies to programming who come on this site with a
> complex project that requires unstable parts of the Ruby pantheon, should be
> told to use another tool, one that is simpler, more mature, and that does a
> better job of handholding, but people who spend most of their time on Ruby
> tend to think with their hammer, so to speak, or maybe, they don't really
> know anything else.
Take a look at the archives of ruby-talk, then. You'll be surprised.
Phillip Gawlowski
>
> 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?
A) Provide examples that functional programming leads to "terseness"
(BTW, the Laconians of old Greece preferred to say as much as possible
in as few words as possible; one man's virtue is one man's sin, it
seems).
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)?
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.
D) Wouldn't a person with less capability be aided by code that
follows simple, logical rules?
*sigh* This'll be the ORM debate all over again, I bet.
Johnny Morrice
As someone doing his math homework as we speak, I beg to differ :p
Phillip Gawlowski
>> Maths isn't hard
>
> As someone doing his math homework as we speak, I beg to differ :p
That's why it's homework. :P
Robert Klemme
<cmdja...@googlemail.com> wrote:
> On Mon, Apr 4, 2011 at 11:23 AM, Everett L Williams II
> <re...@classicnet.net> wrote:
>>
>> *And, of course, since we were talking about making a practical decision
>> about which tool to use, performance cannot possibly matter. There is also
>> this overriding compulsion amongst coders to produce the most abbreviated
>> code possible, assuming that such demonstrates their special skills and that
>> such code is the most desirable. Any study of algorithmic efficiency will
>> show clearly that the shortest code is almost never the fastest code,
>> especially in unoptimized code.*
I'm not sure how you want to prove that given that the number of
algorithms is potentially unlimited, but anyway: the discussion has
digressed so far from the original topic that I don't find it useful
to dive further. I also wonder what you are trying to accomplish by
suggesting that most people here strive for shortest code over fast or
even correct code. I don't think this is the case - at all.
>> About 50% of the real newbies to programming who come on this site with a
>> complex project that requires unstable parts of the Ruby pantheon, should be
>> told to use another tool, one that is simpler, more mature, and that does a
>> better job of handholding, but people who spend most of their time on Ruby
>> tend to think with their hammer, so to speak, or maybe, they don't really
>> know anything else.
>
> Take a look at the archives of ruby-talk, then. You'll be surprised.
I disagree as well. Everett, you'll find plenty of postings
- suggesting a different tool,
- showing that the poster is fluent in at other languages.
in here. In fact, discussions comparing features of Ruby with other
programming languages' features (boy, did I get the plural right?) and
how one or the other can be better utilized to solve a given problem
are among the most interesting and insightful ones.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Everett L Williams II
*Mike,*
Mike Stephens 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.
>
>
>
> 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.
I happen to be a person with 45 years in the computing field, with
specific knowledge of lambda calculus, Turing completeness, object
orientation, structured programming, relational databases, and an host
of other such things, but I have also learned that the real purpose of
computer programs is to get work done unless I am specifically
researching computing as a science. "Turing completeness" is a term of
art that could be replaced in the minds of 99.9% of even fairly
technically competent programmers with any other reference for which
they have poor understanding. If being TC means that the tool can get
the job done accurately and efficiently, including the time that it
takes to create a program, then they are all for it. Most could not even
accurately describe a Turing machine in the original sense of that
definition.
Denigrating another person's choice of tools will certainly not make
that person likely to seek your advice again, nor consider you helpful.
If you have confused your switchblade with a Swiss Army knife, then you
are more foolish than the person you are denigrating. Since this is a
Ruby forum, sometimes the best answer is to refer a person to docs
and/or books for deeper learning rather than try to answer the first
problem that they run into as if that will really help them make
efficient use of Ruby. Help with installing and making Ruby work
properly are always appropriate, but only time and study and practice
will actually allow people to program with any confidence. 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.
Eveerett L.(Rett) Williams II
*
Robert Dober
> is this a good book to read to grok functional programming,
> http://mitpress.mit.edu/sicp/full-text/book/book.html
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
--
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.
Johnny Morrice
> 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.
Johnny Morrice
> 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
Josh Cheek
On Mon, Apr 4, 2011 at 4:28 AM, Stu <s...@rubyprogrammer.net> wrote:
> is this a good book to read to grok functional programming,
> http://mitpress.mit.edu/sicp/full-text/book/book.html
>
> I 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
<re...@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.
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.
Michal Suchanek
> On Mon, Apr 4, 2011 at 4:28 AM, Stu <s...@rubyprogrammer.net> wrote:
>
>> is this a good book to read to grok functional programming,
>> http://mitpress.mit.edu/sicp/full-text/book/book.html
>>
>> I 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).
>
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
Phillip Gawlowski
>
> This is true, of course -- but there is still an influence there where
> research publications will surely be expected to serve some end Microsoft
> executive policy finds worth of approval. After all, if Microsoft
> Research consistently failed to serve Microsoft's bottom line in some
> way, it would be shut down.
There's more to the bottom line than, well, the bottom line. That can
be, for example, public relations, or staying on the cutting edge of a
market. I doubt that something like Microsoft Surface will ever be
produced. OTOH, MS research created .NET, PhotoSynth, and Kinect.
But that doesn't matter: The paper linked in this thread credits two
researcher from non-MS institutions.
> You're not making the same claim here that was originally made.
That could be because I'm not making the same the claim. OTOH, your
statement was drifting too much into the opposite direction (i.e.
spreadsheets being useless without a proper programmer, to exaggerate
a bit).
> Sure. That doesn't change what was actually said prior to this, however.
> Reorienting the pro-Excel argument so that it agrees with things others
> (including me) have already said does not make the preceding pro-Excel
> arguments any less wrong.
Considering that I am making the same argument I always have in this
threat (that Excel isn't the best choice of tool, and is highly
specialized), that isn't all that surprising. ;)
I'm not, nor have I ever been, a member of the Commu^W^W^W^Wproponent
of Excel as a language VM.
Johnny Morrice
> that common?
It's a different language, befunge is a 2d language. Your text file is
like a grid. IIRC, among the commands > < ^ v change direction right,
left, up and down, respectively. So this would be an infinite loop:
>v
^<
The link was to an IRC bot, I think it runs in perl's Inline::Befunge
module, but I really don't know. If you wanted to track it down, I'd
recommend asking at #esoteric on freenode. Also, see this for more on
befunge http://esoteric.voxelperfect.net/wiki/Befunge
Hey, I don't know if there's a ruby interpreter for it! Making
one would definitely be a fun evening with a beer.
Nor seemingly does there seem to be an interpreter in excel...
actually I think Excel would be great for this sort of thing, seeing as
it's a 2d grid.
You could have one part of the sheet containing the program
instructions, and have another part of the sheet contain the registers
(I think it uses registers?) and the 2-dimensional program counter.
The formula would just have to update the state based on the position
of the program counter and the instruction at that point. Then it
would have to update the program counter...
Michal Suchanek
>> I have not seen "befunge" as a euphemism for brainfuck before. Is
>> that common?
>
> It's a different language, befunge is a 2d language. Your text file is
> like a grid. IIRC, among the commands > < ^ v change direction right,
> left, up and down, respectively. So this would be an infinite loop:
>
>>v
> ^<
>
OMG yeah, this explains the ASCII art style.
And it makes it at least as much or more twisted as using Excel for programming.
Awesome thing to show people ;-)
Thanks
Michal
Iain Barnett
> On 3 Apr 2011, at 08:48, Phillip Gawlowski wrote:
>
>> On Sun, Apr 3, 2011 at 7:29 AM, Mike Stephens <rub...@recitel.net> wrote:
>>
>>> But the other point is why does everybody make languages so difficult
>>> these days? I have a degree in Physics but couldn't face trying to
>>> unravel F# or Haskell. Don't tell me trying to fathom out complex
>>> recursive functions is a good way to spend your day.
>>
>> Argument from authority. That you have a physics degree doesn't make
>> you a programmer. Nor does it make you particularly smart nor stupid,
>> or gives you the mindset a programmer should have. It makes you a
>> physicist, nothing more. That's kind of like saying that a bookkeeper
>> is a programmer because (s)he uses spreadsheets.
Argument by authority is not an absolute fallacy and would only apply if he was using that authority to overrule any other view than his, and regardless, the point being made was by comparison/contrast. Having studied physics at that level does show a certain ability in concentration, mathematics, and abstract thought, and would (hopefully) mean that you'd be able to pick up things in fields where those abilities are useful.
I liked using Haskell for a while, and I found producing code that looked beautiful and dealt with things that were (usually) hard in other languages was easy. Getting it to do anything easy was (sometimes) very difficult though.
YMMV, I dropped out of my physics degree (partially) because it was too difficult :)
And I like recursion! (Though Ruby's recursion too often fails me to bother with it for anything that shouldn't fail*)
Regards,
Iain
* which is almost everything
Stu
Phillip Gawlowski
> I'd be interested in the pdf formatted version. Thank you.
http://dl.dropbox.com/u/4294562/15556326-Structure-and-Interpretation-of-Computer-Programs-SICP.pdf
Here you go. :)
And before anyone asks: SICP is Creative Commons licensed.
Stu
Everett L Williams II
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
** *
Josh Cheek
On Thu, Apr 7, 2011 at 10:51 AM, Everett L Williams II
<re...@classicnet.net>wrote:
> Excel is being denigrated here, and that is foolish.
>
>
I haven't seen it denigrated at all, I'm honestly surprised that people have
been as accommodating as they have.
>
> 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.
>
>
Certainly no one said what you just paraphrased, all anyone has done is to
reject the claims that Excel is a programming language (named S#) that
should be used for everything (including web applications), that we don't
need real programming languages and that recursion is always harder and
inferior to "a more linearly coded function".
But, we've also said that you are free to show us how Excel could be a
programming language -- I even went and tried to find an example, and
offered several suggestions of programs I had written this semester that you
could duplicate in Excel to prove your point.
Alex Stahl
Mike Stephens
>
> you found a 4GL very useful within its narrow domain of
> intended applicability
Chad , you have a rather prejudiced view of languages that don't look
like what you're used to.
For a few decades of my career, 4GLs paid the mortgage for me. I did a
North Sea Oil system in ADS/On-line. Focus (with a touch of Rexx) ran
the second biggest direct insurer in the UK for a while. It was the most
efficient and fast-moving corporate IT department I've ever worked in.
Focus provided ETL and data warehousing for the biggest card aquirer in
the UK - hundreds of million of transactions per month. It managed loans
of hundreds of millions to the biggest corporations in the World. What
have your precious 'proper' programming languages done?
I cut my teeth in IT before the advent of the Object-oriented Era.
Everyone was excited when OO arrived. However what I often see from
people taught OO from the cradle is a kind of religiousity, arrogance,
intolerance - this is is the only true path to righteousness; every
thing else should be burned. It's not really as black and white as that.
You need to live-and-let-live.
Johnny Morrice
language, because *you* made money using similar tools.
My sister is a dentist. She makes lots of money. Therefore, by
your logic, dental surgery constitutes a programming language. WTF?!
Just because your particular career didn't involve much proper
programming doesn't change the fact that teeth aren't algorithms, Excel
is a spreadsheet application, that many careers actually do!
I think the guys who wrote Excel program for a living too.
It's as if you're trying to convince people on this list that they would
be better giving up their jobs, giving up their study and going to work
in an insurance broking making excel spreadsheets.
Well thanks for the offer of employment advice, but it's not what I
want to do.
Thanks
Johnny
Everett L Williams II
*Mike,
As attractive a tool as Ruby is, with the attitudes being evince here, I
think that I will take my playtoys elsewhere. Ruby has some of the best
features of a whole group of current languages, but it is not well
standardized and it does not offer the level of leverage offered by even
the fairly mediocre 4GL's. Ruby is just a free version of some things
that would otherwise cost money, and it has not even achieved the level
of acceptance of some of the other free tools. Unfortunately, the best
of languages that I have seen out there are commercial and almost or
completely proprietary. That would be Eiffel and MainSAIL. Both are far
more powerful than Ruby, and both offer better diagnostic facilities as
well as a far tighter development cycle. I think that until I have some
project that just cries out for some facility only available in Ruby
(and I cannot imagine what that might be), I will drop out of this
forum. You might consider just how important Ruby is to you with this
set of attitudes being displayed.
Everett L.(Rett) Williams II
*
Mike Stephens
Generally speaking it's a calm, friendly, rational community, so don't
leave Ruby behind just because of tbis thread.
I've just learnt that with strangers - don't get into discussions about
sex, religion, politics or programming languages :)
Josh Cheek
On Fri, Apr 8, 2011 at 4:04 PM, Mike Stephens <rub...@recitel.net> wrote:
> I've just learnt that with strangers - don't get into discussions about
> sex, religion, politics or programming languages :)
>
>
Or spreadsheets ;)~
Robert Dober
> That makes sense -- and could be another fun evening with a beer.
It was IIRC ;)
http://rubyquiz.strd6.com/quizzes/184-befunge
Cheers
Robert
Kevin
Aren't all programs languages as the program describes a particular problem
or set of problems? It seems that saying that a program is not a language
is a bit of an artificial distinction. Mathematics is a language. Ruby or
C++ are languages that can be used to construct entirely new languages.
Even pictures can form the basis of language. Every program that exists
possesses the vocabulary to deal with a given problem domain, so why bother
trying to claim that something like Excel does not have these qualities?
Aside from adherence to useless jargon of course.
As for issues like terseness, it isn't really a virtue at all. That you can
say or do more with less is not very important if people have a distinct bit
of trouble understanding what is being communicated. The goal should be
clarity, not trying to condense everything into the fewest possible symbols,
ultimately to say that you could.
Kevin
One more thing the SQL programming language as it currently exists was in
fact designed to allow people who were not programmers by trade or training
to be able to comprehend the system. (Look on Wikipedia you can find a PDF
of the original proposal.) It is the reason that the syntax took the form
that it did.
Phillip Gawlowski
> One more thing the SQL programming language as it currently exists was in
> fact designed to allow people who were not programmers by trade or training
> to be able to comprehend the system. (Look on Wikipedia you can find a PDF
> of the original proposal.) It is the reason that the syntax took the form
> that it did.
Just to refresh everyone's memory what an INSERT statement looks like:
INSERT INTO table (column1, column2) VALUES (value1, value2);
Compare to UPDATE:
UPDATE table SET column1 = data WHERE column1 = NULL;
Contrast with SELECT:
SELECT column1, column2 FROM Table WHERE column1 = column2;
Not to put too fine a point to it: Well meant isn't well done.
Phillip Gawlowski
> Aren't all programs languages as the program describes a particular problem
> or set of problems?
Programs are solutions to problems.
> It seems that saying that a program is not a language
> is a bit of an artificial distinction. Mathematics is a language. Ruby or
> C++ are languages that can be used to construct entirely new languages.
> Even pictures can form the basis of language. Every program that exists
> possesses the vocabulary to deal with a given problem domain, so why bother
> trying to claim that something like Excel does not have these qualities?
> Aside from adherence to useless jargon of course.
You are confusing computer science with linguistics.
> As for issues like terseness, it isn't really a virtue at all. That you can
> say or do more with less is not very important if people have a distinct bit
> of trouble understanding what is being communicated. The goal should be
> clarity, not trying to condense everything into the fewest possible symbols,
> ultimately to say that you could.
That isn't a problem of terseness, but a problem of semantics, and how
well something can be understood and learned.
Kevin
No I'm not confusing them, all programs provide the vocabulary (Means of
expression. Look it up if you don't believe me.) necessary to deal with a
particular problem or problem domain. Furthermore what you said hardly
distinguishes computer programs from every other language humans have ever
or will ever create. All of those solve particular problems just as much as
computer programs do. What a program is, is a system as opposed to a
singular object like a table or a chair. The system is itself the tool and
the system exists solely to allow humans to express their will to machines.
Terseness is a problem the moment it causes people to prioritize it above
superior semantics. It might be a great idea to use the mathematical symbol
for lambda to refer to a lambda function but it is not necessarily a great
idea to use an ellipsis to refer to an exclusive range like we do in Ruby.
Both use very few characters to get the job done, but one is not only much
more distinct, it is far easier to explain since it matches a subject more
people are likely to associate correctly with very little in the way of
explanation. (Though I think that Ruby explains things nicely without
getting into the whole lambda/closure thing right out of the gate.) Why the
ellipsis is used for excluding the last number in a range is not readily
explainable, the use of the lambda symbol to refer to lambda functions
however is.
Phillip Gawlowski
> No I'm not confusing them, all programs provide the vocabulary (Means of
> expression. Look it up if you don't believe me.) necessary to deal with a
> particular problem or problem domain.
That doesn't make them languages, or languages useful for everything.
Or do you really believe the Egyptians spoke in little pictures of
birds, eyes and waves?
> Furthermore what you said hardly
> distinguishes computer programs from every other language humans have ever
> or will ever create.
The difference between the two is so obvious, I don't think it needs
to be spelled out (The Latin and Asian languages suffer from a
distinct lack of looping constructs, as well as disambiguity, for
example).
> All of those solve particular problems just as much as
> computer programs do.
Human languages don't solve problems. They facilitate communications
which, considering the circumstances, enables problem solving in
groups.
Very different thing from programming languages which exist to solve
problems (there are of course levels of abstractions with languages
providing richer or poorer semantics to deal with particular problems,
or to provide other trade offs).
> What a program is, is a system as opposed to a
> singular object like a table or a chair. The system is itself the tool and
> the system exists solely to allow humans to express their will to machines.
Superficially correct, but programs exist to do stuff. Be that data
storage, data analysis, or whatever, but programs don't impose a
user's will on a machine. They enable users to accomplish a task
easier and faster (ideally), than the lack of a tool would allow.
Mike Stephens
of reference about what qualifies as a language.
If you are religious the terms 'good' and 'evil' have a very clear and
self-evident meaning. If you are an atheist they seem to be two sets of
rather similar things that appear to be rather arbitrary. The Christian
Old Testament said 'evil' was marrying people from other ethnic groups,
whereas killing them and their animals was 'good'. The Christian New
Testament changed those set memberships a bit.
Ruby is a very powerful language that also has the merit of being able
to express complexity in an elegant way. However if you don't
particularly need all that power then you shouldn't write off languages
which do some things easily but become contorted when you try and
replicate complex Ruby capabilities.
'Domain Specific Language' is a perjorative term. It's just saying I
can't conveniently do certain things I'm used to doing in the way I
prefer. To say that matters, you need to show that typical domains
definitely require such capabilities. My point earlier was not that I
was a superior being (I don't know where that came from) but that from
my experience in the oil, banking, insurance, corflakes and fragances
business, most programming is using quite basic features. OK, that might
not extend to nuclear fission reactors, but let's keep a sense of
proportion here.
There certainly is an argument that functional languages are more easily
mapped to multi-core computers. If I buy one of those S-word platforms,
I get sophisticated parallel processing built in for free. For Ruby, I
would have to carefully program that as Ruby has no general purpose
model/vocabulary/semantics for conveying or deducing dependancies.
Or has it?
Phillip Gawlowski
>
>> 'Domain Specific Language' is a perjorative term.
>
> "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:
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.
Kevin
Why don't you actually go take a look at the definition of language,
specifically definitions three,four,five, and seven here:
http://dictionary.reference.com/browse/language Also have a look at
definition four in the second set. While you are at it take a look at
vocabulary definitions four and five in the first set and four in the second
set here: http://dictionary.reference.com/browse/vocabulary
Your degree of ignorance about what the word language means does not help
communication. I specifically mentioned to Phillip to look up the words in
a dictionary, so that he would understand why I made the points I did the
way I did. You really should have heeded my advice rather than attempting to
resort to sarcasm. Furthermore you totally missed my point about the use of
the ellipsis for exclusive ranges in Ruby, the symbology of the ellipsis
does not give you any indication whatsoever that 1...10 is going to return 1
through 9, on top of that it can be easily confused with "..". Now compare
that with using the lambda symbol for a lambda function: It is a symbol
really only used in mathematics, it is not easily confused with a common
operator, it even manages to retain its' connection to the mathematics
responsible for the concept itself, making it need less explanation for more
people since more people will know about lambda calculus than will expect an
ellipsis to stand for an exclusive range.
Oh and by the way do you know what every program that has ever been or ever
will be created has that your easy chair will not simply with moving parts?
The ability to express a set of human thoughts, like math, Ruby, Latin and
Java. These four unlike your easy chair do not simply do, they were created
to be understood by humans. But please do attempt more sarcasm, to cover up
for your inability to actually look at a dictionary.
On Tue, Apr 12, 2011 at 11:45 AM, Chad Perrin <co...@apotheon.net> wrote:
> On Tue, Apr 12, 2011 at 04:47:17PM +0900, Kevin wrote:
> >
> > No I'm not confusing them, all programs provide the vocabulary (Means
> > of expression. Look it up if you don't believe me.) necessary to deal
> > with a particular problem or problem domain. Furthermore what you said
> > hardly distinguishes computer programs from every other language humans
> > have ever or will ever create. All of those solve particular problems
> > just as much as computer programs do. What a program is, is a system
> > as opposed to a singular object like a table or a chair. The system is
> > itself the tool and the system exists solely to allow humans to express
> > their will to machines.
>
> I guess, by your phrasing, we simply do not "understand" your "language",
> because the "language" you are making is "spoken" upon "semantics" that
> do not exist in anyone else's "metalanguages".
>
> Put another way, we do not "agree with" your "argument", because the
> "argument" you are making is "predicated" upon "premises" that do not
> exist in anyone else's "experience".
>
> I don't think taking your approach to labeling everything under the Sun a
> "language" really aids communication.
>
> Your attempt to bend software into the shape of a language by calling it
> a "system", then contrasting the fact it basically has moving parts with
> the case of tables and chairs to say it's not just a "singular object",
> is flawed. Recliners and collapsible card tables are not "languages"
> just because they are complex systems of moving parts any more than my
> mail user agent is a "language" for the same reason.
>
>
> >
> > Terseness is a problem the moment it causes people to prioritize it
> > above superior semantics. It might be a great idea to use the
> > mathematical symbol for lambda to refer to a lambda function but it is
> > not necessarily a great idea to use an ellipsis to refer to an
> > exclusive range like we do in Ruby.
>
> Really? What's wrong with using ellipsis points to stand in for a range?
> Are you saying that software would be easier to read and write (and
> understand) if we had to type every single number between 1 and 1000 into
> a program to create an array containing all those numbers? What if we
> want to exclude number 347? I think this:
>
> foo = ((1...347).to_a + (348..1000).to_a).flatten
>
> . . . is much easier to quickly read and properly understand than the
> alternative:
>
> foo = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 # . . . and so on
>
> Of course, in this case the exclusive ellipsis is probably not the best
> option, and instead my example of using ellipsis points should look like
> this instead:
>
> foo = ((1..346).to_a + (348..1000).to_a).flatten
>
> There are times that three ellipsis points are more appropriate, though.
>
>
> >
> > Both use very few characters to get the job done, but one is not only
> > much more distinct, it is far easier to explain since it matches a
> > subject more people are likely to associate correctly with very little
> > in the way of explanation. (Though I think that Ruby explains things
> > nicely without getting into the whole lambda/closure thing right out of
> > the gate.) Why the ellipsis is used for excluding the last number in a
> > range is not readily explainable, the use of the lambda symbol to refer
> > to lambda functions however is.
>
> It's easy to explain how ellipsis points work in Ruby:
>
> Three points are "up to"; two points are "through". If you want "one
> through ten", use two points, because the last number in the series
> essentially *is* the third point. If you want "one to ten", use three
> points, showing that it ends with that third point. It's a pretty simple
> rule and, while it may not match with exactly what *you* expect, it is
> still consistent and meaningful, and easily explained.
>
> Also . . . is there any chance we can get you to stop top-posting
> everything? TOFU posting is kind of annoying.
>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>
Josh Cheek
On Wed, Apr 13, 2011 at 12:53 AM, Kevin <darki...@gmail.com> wrote:
> Why don't you actually go take a look at the definition of language,
> specifically definitions three,four,five, and seven here:
> http://dictionary.reference.com/browse/language
>
>
The rest of us are talking about definition twelve.
Kevin
That is all well and good. But does that fact make the definitions I am
using incorrect in any way? Does it necessarily make the suggestion that
excel is a programming language incorrect? Someone posted a link to an
animation done in Excel (I've seen something similar in the past.), is that
not giving instructions to a computer as per definition twelve? Heck if you
were to speak to a computer using English you could give instructions to a
computer. As voice recognition technology gets better and hopefully cheaper
people who are not great at typing may do just that in order to create
programs that would be no different from the ones we type currently.
Kevin
Before anyone bothers syntax would still apply even if one could simply use
English to give instructions and we were able to skip over the symbols, by
that time it would probably be possible to type English in order to create a
program or a subset of it.
Josh Cheek
On Wed, Apr 13, 2011 at 1:38 AM, Kevin <darki...@gmail.com> wrote:
> That is all well and good. But does that fact make the definitions I am
> using incorrect in any way?
>
>
Yes. In the way that your equivocal definition is meaningless in context.
Why don't you quit playing with words take an explicit position: "puts
'hello world'" is a program, are you willing to say it is also a programming
language, according definition 12 at your own link (
http://dictionary.reference.com/browse/language)?
Phillip Gawlowski
>
> That is all well and good. But does that fact make the definitions I am
> using incorrect in any way?
It's worse: They are not applicable.
Kevin
@Phillip: Yes they are applicable, jargon does not supersede the rest of the
language. Especially not when the subject being discussed (In part) whether
or not Excel can be considered a programming language is answered by those
definitions. Why do you think that the word language is even a part of the
phrase "programming language"? It is because of the way the word language
could be and is used by people who are not a part of this field. It was not
in any way random that such a phrase came to describe tools like Ruby, or
C++.
@Josh: It would not be according to definition twelve, but Excel would be in
fact. Seeing as how it provides symbols and ways to deliver instructions to
a computer. You can even use it to create animations. Also the other
definitions I pointed out do not cease to exist because definition twelve
exists, the definitions are not even contradictory. They are complimentary.
Also people are not equivocating just because they do not use the definition
you want them to (Ultimately incorrectly to boot.) That you do not
understand why the phrase "programming language" is possible let alone why
it is used does not make the definitions being applied meaningless in
context. In the context of whether something is a programming language one
must examine what a language even is before deciding that question.
Phillip Gawlowski
> @Phillip: Yes they are applicable, jargon does not supersede the rest of the
> language.
jargon*, n.:
- (uncountable) A technical terminology unique to a particular subject.
- (countable) Language characteristic of a particular group.
- (uncountable) Speech or language that is incomprehensible or
unintelligible; gibberish.
Yes, it does. That's why jargon develops in the first place.
> Especially not when the subject being discussed (In part) whether
> or not Excel can be considered a programming language is answered by those
> definitions.
language*, n:
(computing, countable) A computer language.
That's the definition that applies. If you want to use another one:
that's called "moving the goal posts".
> Why do you think that the word language is even a part of the
> phrase "programming language"? It is because of the way the word language
> could be and is used by people who are not a part of this field. It was not
> in any way random that such a phrase came to describe tools like Ruby, or
> C++.
*facepalm*
Language is ambiguous to start with (compare US English and American
English on the use of the word "fag" in slang). Words evolve, and
change meaning (see also: "gay").
"programming language" is used for the same reason that airplanes use
a similar terminology to ships: The words match, at least roughly, and
get everyone on the same page with ease. From there, additional
meanings develop. Just ask Google about how happy they are that
"googling" is a verb now, or ask Kleenex about what "trademark
dilution" means.
Or are you really suggesting that, since the words are the same, a
captain of a ship is as qualified to navigate the seas as a ship's
captain, just because the spelling is the same? Is driving a car the
same as driving a nail? Is a meter the same as 1 meter?
This whole thing is called "semantics". You are, in fact, arguing
semantics (in English: meaning). Badly.
* definitions sourced from Wiktionary.org
Peter Hickman
There seems to be an inverse relationship between number of words
being used and what is being communicated.
Kevin
No a jargon or slang does not put aside the language it exists inside of.
To try and argue this is ridiculous, the definitions used within the
standard language do not become invalid just because you speak to a specific
group. Now you accuse me of moving the goal posts because I utilize
standard as opposed to nonstandard meanings of terminology to point out that
one may feel free to call any program a language? A jargon only supersedes
the standard usage of a term when it is no longer specific to a single
group, at which point it stops being a jargon.
serialhex
STOP THE FSCKING FLAME WAR!!!! THIS OT POST HAS BECOME OT FOR ITSELF!!!!
(recursively OT??) i'm sure we all understand that a decently powerful
spreadsheet program can do interesting things. i've heard of people using
them as databases & running a companies banking in excel. but that is not
the point. the point is that - like any other flame war - this argument is
going to get EVERYONE NOWHERE!
so if you all would please: STOP THIS MADNESS BEFORE YOU BREAK OPEN A RIFT
AND RELEASE CTHULHU FROM HIS WATERY PRISON AND HE DEVOURS US ALL!!!!!!
thank you for your time and attention...
hex
On Wed, Apr 13, 2011 at 3:02 PM, Chad Perrin <co...@apotheon.net> wrote:
> On Thu, Apr 14, 2011 at 01:18:58AM +0900, Kevin wrote:
> > No a jargon or slang does not put aside the language it exists inside
> > of. To try and argue this is ridiculous, the definitions used within
> > the standard language do not become invalid just because you speak to a
> > specific group. Now you accuse me of moving the goal posts because I
> > utilize standard as opposed to nonstandard meanings of terminology to
> > point out that one may feel free to call any program a language? A
> > jargon only supersedes the standard usage of a term when it is no
> > longer specific to a single group, at which point it stops being a
> > jargon.
>
> In short . . . yes, you're saying that driving a nail is the same as
> driving a car. When I ask "Can you drive?" and you say "Yes," thinking
> you know how to pound nails into wood, you think I should loan you my
> car.
>
> You give a whole new meaning to the comment that when all you have is a
> hammer, everything looks like a nail. I am not, however, inclined to let
> you pound the crap out of my car with a hammer.
>
> By the way . . . the way you want to use "programming language" is
> definitely the nonstandard usage in this context. Context matters.
Gregory Vella
beginning the flame war:
http://groups.google.com/group/comp.lang.ruby/msg/27cebe32ec304c83
Anyone with a passing knowledge of the field would know that Excel is
Turing-complete because it can model Turing-complete cellular automata
(for instance the Game of Life). Also see Wolfram's NKS (though
Wolfram has become crank-like in other respects, he certainly knows CA).
History shows that Phillip will persist despite being factually
disputed. No doubt he will attempt to twist his way out of this one.
See him get refuted here:
http://groups.google.com/group/ruby-talk-google/msg/abb343631960cdad
Note his bizarre cockiness despite being totally wrong:
http://groups.google.com/group/ruby-talk-google/msg/da8cbb09529977d1
In order to understand who you're dealing with here, read Philip's
messages in that thread regarding IEEE infinity.
Kevin
Kevin
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. The problem with that idea is
what do you say when you start talking about languages built expressly for
designing what we are used to calling programming languages. Is the thing
output by an Antlr grammar spec a single unit that is not expressive, or is
it a system that is expressive? If one considers all programs systems that
express a subset of human thoughts the definitions of what these things are
remains consistent even at the level of language design.
Kevin
Ah yes, the old "Oh look specific context" therefore stop reading
definition. You cannot properly understand the phrase "programming
language" without understanding both terms. The most important term in this
case being language. The entire reason the phrase programming language
works is because language is recognized as an expressive system. In reality
definition twelve takes for granted the kind of input that could be used to
deliver instructions to a machine, it assumes that the method used to
deliver the instructions is of a symbolic nature. What happens if you are
dealing with a computer that is not digital such as one that functions with
gears? What happens if some genius manages to use specific frequencies of
sound to deliver instructions to the machine? Is the system of sounds that
the instructions take the form of not to be considered a language?
You say I shot myself in the foot but here is something that might interest
you: By your own logic Ruby is not a programming language. Here's why. You
wish to separate the Excel environment from the macro system or interpreter
that it contains. Ruby and all other programming languages can
theoretically be separated in this way as well, the problem here is that if
you separate these things your input is meaningless because the system is
incomplete. How could you give instructions with Ruby style input without
something that can tell the machine what all those instructions mean? The
interpreter or compiler allows the computer to understand the directions you
give it in a particular language. In other words a unit of a system is not
the system. You cannot separate the Excel environment from the interpreter
and retain results that are meaningful to a computer. By the same token C++
or Ruby code cannot be separated from the compiler or interpreter and remain
meaningful to a computer.
Just for your information a computer used to refer to a person that did
computations. Around the time that digital computers were coming online one
of the major reasons for their adoption in military circles was the fact
that the mathematics human computists had to deal with were just too
difficult to deal with accurately and in a timely fashion. Oh and for the
record if we did have a good enough system for interpreting english for a
computer the communication process would be programming because program as
in giving instructions is not limited to machines, we program humans all the
time. Humans are conditioned (programmed) to read characters almost
instantly, we are not born doing that, the necessary instructions are
inserted by being spoken to or made to go through drills that explain the
formal rules of a language.
On Wed, Apr 13, 2011 at 2:44 PM, Chad Perrin <co...@apotheon.net> wrote:
> On Wed, Apr 13, 2011 at 03:38:23PM +0900, Kevin wrote:
> > That is all well and good. But does that fact make the definitions I am
> > using incorrect in any way?
>
> It does not make them incorrect definitions. It does, however, pertain
> to this specific context, whereas the definitions you identified do not
> pertain to this specific context that way.
>
>
> >
> > Does it necessarily make the suggestion that excel is a programming
> > language incorrect?
>
> You *just* shot your argument in the foot. You said "programming
> language" which, in the specific, is not the same as "language" in the
> generic. By saying "programming language", you have confined your usage
> of "language" to the particular case of definition 12, thus excluding the
> generalities of definitions three, four, five, and seven. It's like the
> difference between "card" and "greeting card", where referring to the
> latter, more specific usage of card excludes the ace of spades, my
> busines cards, and a 3x5 notecard with notes on it related to some kind
> of eXtreme Programming construct.
>
> Even if you did not exclude them, though, they do not really apply to
> your usage except by bending them so far out of shape as to render them
> almost meaningless.
>
>
> >
> > Someone posted a link to an animation done in Excel (I've seen
> > something similar in the past.), is that not giving instructions to a
> > computer as per definition twelve?
>
> No, not really.
>
> Is pushing the power button on my laptop not giving instructions to a
> computer? What about pressing the J key while typing this sentence? You
> might as well call the power button and the keyboard "programming
> languages" the way you're trying to define the term. The whole problem
> with your approach to using the terms "language" in general and
> "programming language" in particular is that you are hand-waving away any
> specificity and context of meaning and usage, stretching the terms into
> such generic, all-encompassing shapes as to strip them of any substantive
> meaning at all. By the time you're done, we'll probably be able to
> define death as a programming language.
>
> Is not the fact of brain death, which causes the EEG to change its
> behavior, not instructions given to a computer, making it a programming
> language by your hopelessly inclusive "definition"?
>
> (Scare quotes used here because I'm stretching the definition of
> "definition" just to accomodate the way you define things.)
>
>
> >
> > Heck if you were to speak to a computer using English you could give
> > instructions to a computer. As voice recognition technology gets
> > better and hopefully cheaper people who are not great at typing may do
> > just that in order to create programs that would be no different from
> > the ones we type currently.
>
> If we get to the point where all communication with computers is done via
> natural language, that will not make English a programming language.
> That will make the communication process no longer "programming".
Kevin
So I take it you are taking your ball home now? You invent a magic
restriction and I applied your restriction to something that you would
consider a programming language to illustrate the problem with your
restriction. Namely that the language does not exist unless the machine can
interpret it, a delivery system is required before something can be
considered a language since you want to ignore the human who is also capable
of deriving meaning from code. I also pointed out problems with the
definition you want so badly to misread. You routinely use examples that
have nothing to do with anything being discussed here and I am the one
guilty of "moving the goal posts" and sophistry? I have maintained from the
beginning that all programs are systems of expression, I haven't moved any
goal posts. When I mentioned your easy chair example I was trying to point
out that your statements about an easy chair being a mechanism while not
being a language were unimportant because I wasn't saying that all systems
are languages, I have been saying that all systems that can/do express human
thoughts are languages and that a computer program (and not the physical
computer itself) is such a system.
Earlier you said that I was making an analogy with pictures and language and
that said analogy was false because pictures are statements and not
language this is false. I said that pictures can form the basis of a
language I did not say that they were the language itself. Furthermore you
claimed that definition seven in set one was being used metaphorically in
the sense that it is not literally applicable. The problem with that is
that no symbol can be literally applied to anything. In point of fact
symbol and metaphor are synonymous with one another. So according to you
language is a set of metaphors that stand for instructions in this context
but definition seven in set one of language is invalid because it is
metaphorical even though rejecting definition seven in this manner requires
you to also reject definition twelve since it says that within this context
language is a set of metaphors applied with certain rules that can be used
to give instructions to a computer. (A system that is expressive.) In short
according to you definition twelve is not appropriate for this discussion
since you reject the use of metaphorical definitions. Even if you don't
accept that there really is a set of definitions for flowers so no
definition seven in set one was not being used metaphorically (As a simile.)
it was being used quite literally, the language of flowers being an example
of a communication system. If you look at the second example "the language
of art"; depending on which definition of art you use, such a statement may
be understood in terms of definition one of language since definition one of
language pretty much defines jargon.
On Wed, Apr 13, 2011 at 7:51 PM, Chad Perrin <co...@apotheon.net> wrote:
> On Thu, Apr 14, 2011 at 08:44:05AM +0900, Kevin wrote:
>
> [snip]
> blah blah blah sophistry
> [/snip]
>
> I have no interest in continuing this discussion, where your rhetorical
> techniques basically consist of moving the goal posts every six minutes.
>
>
> >
> > Just for your information a computer used to refer to a person that did
> > computations.
>
> I'm aware of this.
>
> Oh, look -- the goalposts are moving again.
Mike Stephens
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.
Robert Klemme
> 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. As the originator of this thread I am sorry where all
this went. My intent was to hear how other people view the tendency
to include functional features in other programming languages or
create hybrids from the start. Or hear whether they disagree that
such a tendency exists.
Unfortunately I am myself guilty of following that "Excel is (not) a
(functional) language" branch of the discussion that you lured us
into. :-) That is an interesting topic in itself but not what I had
in mind originally.
If there's still anybody out there who wishes to comment along the
original line of thought, please let's hear it.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Josh Cheek
On Thu, Apr 14, 2011 at 3:29 AM, Robert Klemme
<short...@googlemail.com>wrote:
> On Thu, Apr 14, 2011 at 9:28 AM, Mike Stephens <rub...@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.
>
>
IDK, likening your adversaries to terrorists seems a bit extreme to me.
Michal Suchanek
> 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.
>
This is not about world views, it's about term borders nitpicking, really.
This distinction was made because earlier somebody said that "true S#
programmers use the macro language only as the last resort".
Indeed, the macro language(s) that can be used from excel are
definitely programming languages but VBA is not funtional or otherwise
interesting in any way.
The expressions you put into the cells are kind of functional with a
solver which might somewhat remind one of Prolog and constraint
solving systems based off it but I have no idea how it works
internally and how formulating problems to be solvable in Excel
compares to formulating problems to be solvable in constraint solvers.
As for Turing completeness, game of life or x86 machine code is Turing
complete and nobody in their right mind would call it a programming
language.
Calling something a programming language does in my book imply that
- it is meant to be used by humans
- it is meant to give instructions to some system, such as a
computer, an application, etc.
This implies that Excel is not a programming language but the
expressions in its cells or VBA which can be used from Excel might,
meaning that Excel is an application that includes or integrates one
or more languages.
Since this is further strengthened by the fact the same or similar
expressions can be used in other applications (VBA in other parts of
MS office, cell expressions in OpenOffice Calc) I would say Excel is
not the language but an implementation or a runtime or a development
environment for it.
Note that a language can be defined eg. in mathematical sense as a set
of words which in turn are defined as succession (or string if you
want) of symbols of an alphabet which in turn is defined as a set of
symbols
While this definition is useful for analyzing properties of
programming language grammar it is not the definition which makes
something a programming language.
Regards
Michal
Mike Stephens
> Calling something a programming language does in my book imply that
> - it is meant to be used by humans
> - it is meant to give instructions to some system, such as a
> computer, an application, etc.
>
> This implies that Excel is not a programming language
Michal, there have been many such non-sequiturs in this thread, but that
is the most elegantly simple.
I apologise for bringing Excel into the discussion - which was supposed
to be about people's thoughts on functional programming languages. Excel
- like functional languages - makes you come up with new patterns.
My defence is it's like introducing a new recruit to the village cricket
team, then people find out he's gay. I'm not to know in advance whether
they find that peripheral aspect irrelevant, interesting or an extremely
serious matter.
Going back to functional languages in the normal sense, few people on
this thread seem to be
that interested, and when I've mentioned them in a work context
(typically .NET), nobody's bothered.