intelligence is a search for satisfaction

"Brandon J. Van Every" <try_vanevery_at_mycompanyname RemoveThis @yahoo.com> wrote in
message news:2nsr2rF4f945U1@uni-berlin.de...
> cr88192 wrote:
>>
>> ok.
>> the bsd liscence is pretty cool imo...
>> similar would likely go for the mit liscence.
>>
>> in your oppinion, how does lgpl compare?
>
> The difficulty with the LGPL is that in commercial practice, you must
> provide your library as a dynamic link library to comply with the license.
> You can't, for instance, just compile the library statically into your
> code.
> I find this to be an annoying futz factor, and in some commercial contexts
> the restriction would be unacceptable. Of course that's the LGPL's point,
> it wants to make certain things unacceptable to commercial development.
> LGPL prioritizes the right of some geek to fiddle with the library as he
> sees fit.
>
ok.

> MIT / BSD doesn't prioritize anybody. You can do whatever you want with
> the
> code. Nothing is in the way. I figure, if you're going to give something
> away, give it away completely. If it's too valuable to give away
> completely, don't! Keep that chunk proprietary.
>
ok.

>> hmm, during the time when I was without my computer a few months ago,
>> I came up with much of the underlying ideas for pdscript (along with
>> a few other things that went nowhere).
>> so I guess designing stuff is possible, but, I tend not to do it for
>> the most part it seems (or at least much more than a few minutes
>> worth).
>
> Probably because you don't enjoy it so much compared to programming and
> aren't so good at it. So, you stick with what you like. This is going to
> limit you, until you decide that you need to tackle certain problems with
> discipline and resolve, rather than simply what you like.
>
ok.

>>> OCaml's syntax is baroque, but not as bad as C++.
>>>
>> yes, but imo most things that don't look like the c family are
>> arguably "strange".
>
> So what? That's called learning something new. In computers you have to
> do
> it all the time, one way or another. I don't believe in learning
> everything, I do believe we should make strategic choices about what we're
> going to bother to learn. But I don't buy this "eew it's strange"
> attitude
> for its own sake. Everything new is strange.
>
but things that are stange can scare off newbies.
c syntax scares off vb programmers, but at least most others wont be scared
off so easily as likely they are more fammiliar with it.

>> pushing it to the level of a python, pascal, or basic style syntax
>> clearly breaks things imo, this is no longer c-style.
>
> There's nothing precious about C style. I see no a priori reason to
> prefer
> C style over some other style. In fact, as languages have evolved I can
> see
> various reasons for getting away from C style. The main reasons to retain
> C
> style are language bridging and low level hardware access.
>
but it is mainstream.
c and c++ comprise most of the software in existance.
c# and java fall way behind, but are still not exactly that small (compared
with most other languages).

I had found it quite annoying that most people I encountered irl, if they
knew any programming, could not understand fragments from my previous langs.

there are lots of people that take classes to try to learn java;
javascript is commonly enough at least lightly handled in web-development
classes;
vb is common in introductory classes.

most things had seemed to point in a single direction.

I had then decided:
I am largely going to stick to c-style syntax;
failing that, I will rip off bits of vb style syntax (as at least it is
common).

it is difficult to avoid drifting too far from the c realm sometimes...

I compare it to the linux and wondows issue:
linux is sufficiently unlike windows (even though lots of effort is put into
cloning it), that many windows users get disorientated and feel hopeless
when faced with linux (or mac for that matter, eg, "what is this menu bar at
the top of the screen? oh, how do I operate these apps?!...").
I will argue that most programmers are largely the same way.

it doesn't matter so much what I am willing to do, but more what I can get
others to be willing to do...

> Also, I don't see the big deal about learning a new language style, in and
> of itself. I've got a big brain, I'm smart, I'm a capable computer guy.
> I
> wouldn't wuss out about any other kind of algorithmic problem, why would I
> wuss out about learning a new style? Be a real man and learn some
> different
> style other than this C stuff.
>
hmm...

err, annoyingly I have come up with something that could allow really cool
features (eg: the ability to handle relational db type stuff in the core
language), but it will likely look quite strange.

db[owner:="Bob", cost:<10000]

managing things like this could be an issue though, since with types like
this there is no longer really a 1d index space for such types.
but it just seemed too cool to not implement.

> Granted, for any given language, that's a time investment. I don't
> believe
> in learning all languages. Rather, I've identified what I'm trying to do
> (3D graphics and AI). So I've looked at the languages that seem most
> applicable to what I'm trying to do. For now that seems to be OCaml, so
> that's where I focus my attention.
>
yes.
this may be a bias driven largely by my lang design instincts.

I will use other languages sometimes (eg: I still do some scheme coding
every so often, and I do write shell scripts), but I will be reluctant to
really support langs that use unusual syntax.

>>>> bad support for functional programming;
>>>> bad support for imperative programming;
>>>
>>> OCaml supports both just fine.
>>>
>> yes, maybe.
>> then the stance is functional-imperative (eg: a more functional core
>> with imperative features) or imperative-functional (an imperative
>> core language with features for assisting in fp).
>
> OCaml is functional-imperative, per your terms.
>
yes.

>>> But the price of "I can fix anything," taken to your extreme limit,
>>> is you never really get anything done. You take too many engineering
>>> responsibilities upon yourself. Sure you code prolifically, but
>>> even the most prolific coder can't get anywhere without a good plan.
>>> A good design.
>>> And good design is *hard*. There's a reason you're not good at it,
>>> it takes
>>> years to hone good design skills. So, you're just going to keep
>>> running into the "too much labor to design" brick wall over and over
>>> again, until you wise up and realize you don't really want to write
>>> everything yourself.
>>> What you want to do, is write a small chunk of stuff yourself that's
>>> core to
>>> your strategic goal. "I can fix anything" isn't a strategic goal.
>>> It's an
>>> undirected dispersal of energy on a perceived, non-critical problem.
>>>
>> hrm...
>> just, if I use existing stuff, given my lack of focus, there is not
>> much for me to do (except for maybe gluing things together).
>
> SO GET A FOCUS!!! Geez!! Hit the nail on the head dude.
>
getting focus is not an easy task...

>>> At present your lack of focus seems to be:
>>> - You like C/UNIX style hacking.
>>> - You like being able to change everything.
>>> - You pick flavor-of-the-month (week??) problems to work on, so
>>> prototyping
>>> must be important to you.
>>> - You don't really care about performance, just getting things
>>> working.
>>>
>>> This puts you in the scripting language camp. So, what do you think
>>> of Lua?
>>> Or Ruby?
>>>
>> lua: looks like pascal, but otherwise seems cool.
>
> Ok, so try writing something in lua. Lua was also designed to be extended
> by guys like you, so try extending it somehow.
>
dunno.

>> I am not sure why so many scripting langs resemble shell scripts
>> though. c-syntax would be awkward at a shell, but otherwise I don't
>> get it that well...
>
> It's historical. The people interested in scripting languages have
> typically been the ones who learned shell languages. Python is the
> opposite
> taste from this. It can do all the scripting jobs, it's quite
> commercially
> proven in that arena, and it is utterly un-Perl-like. As far as syntactic
> taste goes, you're either a Python guy or a Perl guy. FWIW I'm a Python
> guy, in the aesthetic sense.
>
I am still mostly a c guy though.

yes, c has flaws. these can be worked over and cleaned up without making
things too scarily different though.
going, eg, to a linebreak and indentation sensitive syntax is likely to
confuse a great many coders (well, ok, same goes for my objects and scoping,
and I do have a more traditional style syntax for object creation, just I
don't end up using it as much as the much terser "dictionary" syntax).
 >> Stay informed about: intelligence is a search for satisfaction 

["Followup-To:" header set to comp.lang.functional.]
cr88192 wrote:
> err, annoyingly I have come up with something that could allow really cool
> features (eg: the ability to handle relational db type stuff in the core
> language), but it will likely look quite strange.
>
> db[owner:="Bob", cost:<10000]
>
> managing things like this could be an issue though, since with types like
> this there is no longer really a 1d index space for such types.
> but it just seemed too cool to not implement.

You may want to look at haskellDB for inspiration:
http://haskelldb.sourceforge.net/

Overview

HaskellDB is a combinator library for expressing queries and other
operations on relational databases in a type safe and declarative
way. All the queries and operations are completely expressed within
Haskell, no embedded (SQL) commands are needed.

I was playing with it recently and I like it very much. The only problem
was that it insists on using subqueries (even if a join would suffice),
so I couldn't use it on our pre 4.1 production MySQL server.

Best regards,
Tom

--
..signature: Too many levels of symbolic links
 >> Stay informed about: intelligence is a search for satisfaction 

R. Alan Monroe wrote:

> Personally, I seriously doubt voice recognition will catch on.

If all computers were (or rather are going to be) PC:s than perhaps a
guarded yes. The revolution certainly isn't going to start there. But
that's ignoring all the other stuff that could become computerised if
there were only decent interface capabilities today.

Imagine how much more convenient it would be to be able to talk to your
TV or car for example. No futsing about with remotes (invariably lost)
or groping for the radio controls while taking your hands of the wheel
and eyes of the road. Think about the possibility of wearables. Putting
a screen in your glasses is easy enough, but strapping a keyboard to
your stomach is not really practical.

With workable voice recognition and speech synthesis you could put
computers *everywhere*. Carton of milk: "Milk how old are you?" Or
"Milk, tell the fridge when you're one day away from expiration."
Coupled with a biological sensor to actually determine when the milk's
actually gone bad you could forget about the "use by" date. You could
even have the milk tell you: "Please put me back in the fridge now if
you want me to last three more days". And that's just one very silly
example. Chosen because no one is ever going to bother walking over to a
PC to perform those tasks. I've even ignored the obvious ones such as
your mobile, you're already speaking 'to' it, so why anyone would choose
to have a keyboard on there if they didn't have to is beyond me.

When the kids that have grown up in such a surrounding enter the
workplace, they'll find the few people how still use keyboards (I would
probably be one of the geriatric ones) as quaint old dodgers.

Compare the mobile (cell phone for you yanks) revolution. I'm still
irked (though it's wearing off) at meeting people in the corridors at
work speaking straight out into thin air having a conversation via their
handsfree. And we've incidentally let go of all our land lines, relying
completely on GSM (GSM indoors) for all phones, so there's a lot of that
going around. Now I was an adult, well out of university when I got my
first mobile, but all the first graders here have one these days. I
think they'll find land lines just as quaint when they enter the
workforce as their grand children will find keyboards. They'll probably
still be there but people wont use them much, it'll be a specialised
skill/taste. Just like the kids going into university today don't get a
land line for their dorm room. Why should they?

Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
 >> Stay informed about: intelligence is a search for satisfaction 

>>I really must get around to playing more with OCaml. I really love LISP
>>but that's as far as I've ever gone with Functional Languages (except
>>for dabbling briefly with Erlang) and I have to say the 'hard core'
>>functional languages freak me out somewhat ) I just don't get them.
>>Which is all the more reason to put the effort in a learn one properly )
>>
>
>
> Any idea what bugs you? It's a bit weird working without state at first,
> certainly. Well, until you find all the tricks for providing state when
> you really really need it (gee, I'm talking a stateful protocol over the
> network here...).


I think it's just that I've very much settled into the OO way of viewing
the world - solving a problem is creating a bunch of objects which
simulate the problem domain with appropriate behaviours. I think that
philosphically that view point appeals to me since I've always viewed
understanding and theories as a modelling task (you build a model, try
it out and refine it or replace it when it doesn't match obverved /
desired behaviour) FP seems a long way away from that - nothing
neccessarily wrong with FP, more to do with how I think about code.

I guess the other thing is that FP tends to be littered with
mathematical terms and I'm not fond of maths. )
 >> Stay informed about: intelligence is a search for satisfaction 

Peter Ashford wrote:
>
> I think it's just that I've very much settled into the OO way of
> viewing the world - solving a problem is creating a bunch of objects
> which
> simulate the problem domain with appropriate behaviours. I think that
> philosphically that view point appeals to me since I've always viewed
> understanding and theories as a modelling task (you build a model, try
> it out and refine it or replace it when it doesn't match obverved /
> desired behaviour)

The problem is that world view doesn't work in a lot of instances. Lotsa
things aren't self-contained objects, nor do they have clean hierarchical
relationships. Lotsa things are relational and fuzzy, so you have to pick
object boundaries arbitrarily.

> I guess the other thing is that FP tends to be littered with
> mathematical terms and I'm not fond of maths. )

From a marketing standpoint I do agree that blah blahing about "the lambda
calculus" is a dead turnoff to anyone interested in the practical.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 >> Stay informed about: intelligence is a search for satisfaction 

In article <2ntj38F4kpuqU1.RemoveThis@uni-berlin.de>,
try_vanevery_at_mycompanyname.RemoveThis@yahoo.com says...
> Peter Ashford wrote:
> >
> > I think it's just that I've very much settled into the OO way of
> > viewing the world - solving a problem is creating a bunch of objects
> > which
> > simulate the problem domain with appropriate behaviours. I think that
> > philosphically that view point appeals to me since I've always viewed
> > understanding and theories as a modelling task (you build a model, try
> > it out and refine it or replace it when it doesn't match obverved /
> > desired behaviour)
>
> The problem is that world view doesn't work in a lot of instances. Lotsa
> things aren't self-contained objects, nor do they have clean hierarchical
> relationships. Lotsa things are relational and fuzzy, so you have to pick
> object boundaries arbitrarily.

But if the world isn't easily divided neatly into objects, it is even
less easily divided neatly into algorithms.

Personally I'm quite happy to have a class called "MapUtilities" that is
just a bunch of functions for dealing with shortest paths etc. (I'm
using a class where others might use a namespace.)

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

On Wed, 11 Aug 2004, Peter Ashford wrote:

> I think it's just that I've very much settled into the OO way of viewing
> the world - solving a problem is creating a bunch of objects which
> simulate the problem domain with appropriate behaviours. I think that
> philosphically that view point appeals to me since I've always viewed
> understanding and theories as a modelling task (you build a model, try
> it out and refine it or replace it when it doesn't match obverved /
> desired behaviour) FP seems a long way away from that - nothing
> neccessarily wrong with FP, more to do with how I think about code.
>

The approach I take in FP isn't all that different. In a (classed) OO
language, classes form a little language with its own semantics. Monads
also do something similar - I've been trying to figure out the exact
relationship, in some ways monads seem to generalise classes. I suspect
(but may be wrong) that objects are effectively the closure of a monadic
computation.

The main difference this seems to make is that you're encouraged to
rewrite the rules that objects and the like sit on top of - the List monad
being a great example thereof.

--
flippa RemoveThis @flippac.org
 >> Stay informed about: intelligence is a search for satisfaction 

"Andreas Rossberg" <rossberg RemoveThis @ps.uni-sb.de> wrote in message
news:cfcoi0$7c8vg$1@hades.rz.uni-saarland.de...
> Brandon J. Van Every wrote:
>>
>> In a hand-wavy sort of way, I think functional languages are easiest to
>> understand as "having far better templating capabilities than C++ has."
>> That's all the functional paradigm really seems to amount to.
>
> Mhh... I mildly distorted view, I'd say.
>
>> Sure, there's this fixation on copying stuff rather than modifying state,
>> but practical languages like OCaml blow that off. Anally copying
>> everything
>> is a purist notion, borne of the idea that this is going to make theorem
>> proving easier.
>>
>> There may be a point to that, but it sounds remarkably like the argument
>> "if
>> everybody would just do everything in terms of RISC, the world will be
>> such
>> a better place!"
>
> No, it's rather comparable to "if everybody would just stop using GOTOs,
> debugging and maintaining programs would be much less of a nightmare."
>
yes, and gotos were replaced by generally less awkward forms...

I would much rather type
while(x<3)x++;

than

l1:
if(x<3)goto l2;
x++;
goto l1;
l2:

> Mutable state is the GOTO of data structures. (Which does not preclude it
> from being handy some time in a while, if used with care and at the right
> places.)
>
but, unlike goto, many of the attempts to replace it are more awkward.

I will still debate this saying that assignment *is* one of the fundamental
operations in most programming languages.
yes, fp makes it a little less necessary, but for a majority of cases it is
still one of the most straightforward approaches imo...

eg: we have a while loop and assignments vs. a recursive form.
yes, the recursive form is more elegant, but is a little more unruly than
the while loop. yes, via continuations you can jump around or break from the
loop, but this is yet another thing to need to worry about.
though there are cases where recursion makes more sense, in which case
convinient recursion is a nice feature.

I don't think it can be phased out as easily as goto, and the approach of
many fp languages of making it more awkward doesn't fly well imo. yes, it
still exists, but it is longer to type, and doesn't have such nice forms as:
x+=3;
instead we are often left with things more like:
set x=x+3
or similar, along with the issue that we know that it is bad style for that
language to use it...
 >> Stay informed about: intelligence is a search for satisfaction 

cr88192 wrote:
>>
>>>Sure, there's this fixation on copying stuff rather than modifying state,
>>>but practical languages like OCaml blow that off. Anally copying
>>>everything
>>>is a purist notion, borne of the idea that this is going to make theorem
>>>proving easier.
>>>
>>>There may be a point to that, but it sounds remarkably like the argument
>>>"if
>>>everybody would just do everything in terms of RISC, the world will be
>>>such
>>>a better place!"
>>
>>No, it's rather comparable to "if everybody would just stop using GOTOs,
>>debugging and maintaining programs would be much less of a nightmare."
>
> yes, and gotos were replaced by generally less awkward forms...

That's how you judge it from today's perspective, but back in those days
people used pretty similar arguments against the banning of goto as you
hear against discouraging mutable state today. Ask some Fortran veterans.

Like with GOTO, most uses of mutation can be expressed with relative
ease in more structured ways. And similar to mutable state, people had
nifty uses of goto that you cannot easily substitute (i.e. fold into a
loop) - you just don't consider these uses worthwhile today, because you
have been socialised with the conviction of them being evil.

> I will still debate this saying that assignment *is* one of the fundamental
> operations in most programming languages.

True. So?

> yes, fp makes it a little less necessary, but for a majority of cases it is
> still one of the most straightforward approaches imo...
>
> eg: we have a while loop and assignments vs. a recursive form.
> yes, the recursive form is more elegant, but is a little more unruly than
> the while loop.

That's mainly a matter of getting used to. In any case, you code
explicit recursion much less frequently in functional languages than
loops in conventional ones since you normally build higher-order
abstractions for that.

> I don't think it can be phased out as easily as goto, and the approach of
> many fp languages of making it more awkward doesn't fly well imo. yes, it
> still exists, but it is longer to type, and doesn't have such nice forms as:
> x+=3;
> instead we are often left with things more like:
> set x=x+3

That's a strawman. FPLs are tuned for building abstractions. E.g. in SML
just define

infix +=
fun (n += i) = (n := !n+i)

> or similar, along with the issue that we know that it is bad style for that
> language to use it...

Actually, I consider it bad style independent of the language. It's just
that some languages don't support "good style". I try to avoid them for
doing high-level stuff.

To clarify: I'm not dogmatic about state. I use languages that allow me
to fall back to mutable state when I really have to. But I always think
twice before doing so, because pretty much every single use of mutable
state has bitten me in some way sooner or later. And I originally come
from C/C++, too (heck, hard to admit, but there even were days when I
was so dumb that I considered C++ the greatest language on earth - today
I'd say the opposite.)

--
Andreas Rossberg, rossberg.DeleteThis@ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 >> Stay informed about: intelligence is a search for satisfaction 

On Wed, 11 Aug 2004 00:59:24 +0100, Philippa Cowderoy
<flippa.DeleteThis@flippac.org> wrote:

>[2] By which I mean that computations can take computations as
>parameters and return computations as results - if there's an existing
>use of the term that differs from this, could somebody enlighten me
>btw? - this has a consequence, which is that any data the monad keeps
>(state being the classical example) won't branch any - this allows the IO
>monad to represent a function of type world->world without ever trying to
>duplicate the world, thus allowing a pure (if not complete) language to
>express interaction with the outside world without giving too many
>physicists big headaches.

Is that like a statically typed version of Scheme's continuations? If
not, what (apart from the static typing) is the difference?

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
 >> Stay informed about: intelligence is a search for satisfaction 

Andreas Rossberg wrote:
> cr88192 wrote:
>>
>> yes, and gotos were replaced by generally less awkward forms...
>
> That's how you judge it from today's perspective, but back in those
> days people used pretty similar arguments against the banning of goto
> as you
> hear against discouraging mutable state today. Ask some Fortran
> veterans.

The difference is that banishing GOTO actually happened in industrial
practice because it proved rather useful rather quickly. No such claim can
be made for FP purism. In fact, looking at the historical evidence, we
would say that it has been definitively proven that modifying state is too
compelling to give up.

> That's mainly a matter of getting used to. In any case, you code
> explicit recursion much less frequently in functional languages than
> loops in conventional ones since you normally build higher-order
> abstractions for that.

'Normally' for 'normal' algorithms? Why does this reek of domain-specific
bias?

> That's a strawman. FPLs are tuned for building abstractions. E.g. in
> SML just define
>
> infix +=
> fun (n += i) = (n := !n+i)

Why should we desire this grunge code for such a simple operation? Do you
believe that you'll be able to prune the state modification at some point,
if only you add all this verbiage? I'm doubting it. Modifying state is a
software architectural choice. If it were easy to transform programs that
modify state into ones that don't, I think we'd just have those language
technologies and FP adherants wouldn't be complaining about how everyone
shouldn't modify state.

> To clarify: I'm not dogmatic about state. I use languages that allow
> me
> to fall back to mutable state when I really have to. But I always
> think
> twice before doing so, because pretty much every single use of mutable
> state has bitten me in some way sooner or later. And I originally come
> from C/C++, too (heck, hard to admit, but there even were days when I
> was so dumb that I considered C++ the greatest language on earth -
> today I'd say the opposite.)

I can't say that mutable state has ever bitten me in anything I've done in
software. I think the bogdowns come from overoptimizing, core architectural
decisions I can't change, tedious documentation, and libraries that don't
actually work.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 >> Stay informed about: intelligence is a search for satisfaction 

"Andreas Rossberg" <rossberg.RemoveThis@ps.uni-sb.de> wrote in message
news:cfd2ml$7c8vg$2@hades.rz.uni-saarland.de...
> cr88192 wrote:
>>>
>>>>Sure, there's this fixation on copying stuff rather than modifying
>>>>state,
>>>>but practical languages like OCaml blow that off. Anally copying
>>>>everything
>>>>is a purist notion, borne of the idea that this is going to make theorem
>>>>proving easier.
>>>>
>>>>There may be a point to that, but it sounds remarkably like the argument
>>>>"if
>>>>everybody would just do everything in terms of RISC, the world will be
>>>>such
>>>>a better place!"
>>>
>>>No, it's rather comparable to "if everybody would just stop using GOTOs,
>>>debugging and maintaining programs would be much less of a nightmare."
>>
>> yes, and gotos were replaced by generally less awkward forms...
>
> That's how you judge it from today's perspective, but back in those days
> people used pretty similar arguments against the banning of goto as you
> hear against discouraging mutable state today. Ask some Fortran veterans.
>
well, in many langs it is not exactly banned, more just bad style to use it
too heavily.

my lang retains goto, and here is a chink of what it looks like:
function gfun()
{
local i;

i=0;

l0:
i++;
if(i>10)goto l1;
if(i<5)goto l0;
println("gfun ", i);
goto l0;
l1:
}

but, yes, goto is used a lot less anymore...
(I debated adding goto for a while, but eventually decided to add it).

> Like with GOTO, most uses of mutation can be expressed with relative ease
> in more structured ways. And similar to mutable state, people had nifty
> uses of goto that you cannot easily substitute (i.e. fold into a loop) -
> you just don't consider these uses worthwhile today, because you have been
> socialised with the conviction of them being evil.
>
or at least annoying.
goto is a lot more usable, at least in the assembler I use, as they follow
kinds of nesting rules and such absent in many languages...

>> I will still debate this saying that assignment *is* one of the
>> fundamental operations in most programming languages.
>
> True. So?
>
well, in this case it is difficult to remove without people feeling
constrained.

>> yes, fp makes it a little less necessary, but for a majority of cases it
>> is still one of the most straightforward approaches imo...
>>
>> eg: we have a while loop and assignments vs. a recursive form.
>> yes, the recursive form is more elegant, but is a little more unruly than
>> the while loop.
>
> That's mainly a matter of getting used to. In any case, you code explicit
> recursion much less frequently in functional languages than loops in
> conventional ones since you normally build higher-order abstractions for
> that.
>
well, I was using a lot of recursion.

in my lang the syntax for recursion is not quite as elegant as would be
hoped, but it is still usable:
(fun r0(x){(x<=1)?1*r0(x-1)})(10);
fun r0(x) {(x<=1)?1*r0(x-1)} (10);
or:
fun r0(x)x<=1?1*r0(x-1)(10);

all these results in the factorial of 10.

yes, I had considered adding things like let and rlet, but application and
first class functions just work so well (even if they are awkward looking).
yes, I have better ways of calculating numbers like this, but this was an
example.

however, first they need to compete with things like while or for...

>> I don't think it can be phased out as easily as goto, and the approach of
>> many fp languages of making it more awkward doesn't fly well imo. yes, it
>> still exists, but it is longer to type, and doesn't have such nice forms
>> as:
>> x+=3;
>> instead we are often left with things more like:
>> set x=x+3
>
> That's a strawman. FPLs are tuned for building abstractions. E.g. in SML
> just define
>
> infix +=
> fun (n += i) = (n := !n+i)
>
ok.
I am, however, used to this kind of thing being a standard feature of the
language. I retain features that are low level and can promote bad style,
along with those that might promote better use.

I am sticking close to its imperative roots, which is partly why I coined it
as imperative-functional...

>> or similar, along with the issue that we know that it is bad style for
>> that language to use it...
>
> Actually, I consider it bad style independent of the language. It's just
> that some languages don't support "good style". I try to avoid them for
> doing high-level stuff.
>
ok.

> To clarify: I'm not dogmatic about state. I use languages that allow me to
> fall back to mutable state when I really have to. But I always think twice
> before doing so, because pretty much every single use of mutable state has
> bitten me in some way sooner or later. And I originally come from C/C++,
> too (heck, hard to admit, but there even were days when I was so dumb that
> I considered C++ the greatest language on earth - today I'd say the
> opposite.)
>
well, c is by far not that great of a language, but it offers things which
many other languages fall short on:
it is still fairly portable;
it gives you fairly direct control over what is going on;
....

one doesn't have to feel bad about doing ugly things with it, building their
own type and memory management systems, having parts of their source written
by tools, ...
c is a good lang for ugly things.

or something...
 >> Stay informed about: intelligence is a search for satisfaction 

> Personally, I seriously doubt voice recognition will catch on. HR
> people or accountants will never use it because their data is often
> semi-confidential. Programmers aren't likely to use it, at least in
> the near term, because of all the punctuation needed.
> Managers need primarily to interact with other people and don't
> produce loads of output streams, apart from email, which again is
> likely to be semi-confidential. Have you ever worked in an office
> where someone played a radio tuned to a station you don't like?
> Multiply that by five or ten.
>
> Novelists, maybe, would find it useful.

It has its uses. I wrote some VR code about 6 months ago for a company that
wanted a command and control interface for a complex documentation
management system (for the military's "objective force" initiative) and it
hooked straight into our AI so that you could accomplish complicated tasks
with minimal input once there was minor familiarity with the system, the
example wasn't document related, it was a 3D scene and it worked like:

"Look at the humvee"
"Track the humvee"
"hide all buildings"
"hide all vehicles"
"zoom in on the BMP"

Et cetera... All actions which would require computer familiarity or scene
knowledge in order to achieve w/o a VR hooked up to our AI (to interpret the
intention of the voice command [subject, action, et cetera.])

It will have its uses. I'm in the process of wiring my house for automation
and I have already tested out a "Star Trek"-like system where my old 733 Mhz
machine does nothing but listen for the phrase "Computer" by itself. When
it does, it replies "Computer here" via SAPI 5 TTS. Of course, I had to add
the "I'm sorry Dave, I can't do that" clip to the 'unknown goal' responses
.

WTH:)
 >> Stay informed about: intelligence is a search for satisfaction