>> ...which would just mean writing programs as mathematical statements 
>> rather than lists of instructions. It would just be another 
>> programming language. And, you know, people have argued that 
>> programming in Haskell is like programming with mathematics, so...
>  >
>> [One might also mention Mathematica.]
> 
> Another fallacy of that time (and possibly with the functional 
> programming approach) was the assumption that computer programs would 
> always have the purpose of solving inherently mathematical problems - 
> and that programming would therefore always be done by studied 
> mathematicians.
> 
> Now I guess the math required to program a word processor or an e-mail 
> client is not /that/ complicated :-)

Some people might retort that too few programmers realise the deep 
mathematical structure of the programs they're trying to implement. :-P

For example, Darcs is a version control system, much like RCS or CVS 
are. But Darcs has an "algebra of changesets". Basically this dictates 
the possible ways in which changesets can be applied. (If you think this 
is barking mad, recall that databases are based on the relational 
algebra, and that works just fine.)

To my knowledge, nobody has written a word-processor or e-mail client in 
Haskell yet. But they have written an IRC bot, and a text editor along 
the lines of Emacs. [Possibly the least-usable text editor in history...]

"Mathematics" isn't just about calculating things, you know.

> Unfortunately, the functional approach is quite brain-wrecking for 
> anyone not trained in university-level mathematical thinking - or so it 
> appears to me.

Heh, well... I suspect it only appears that way due to the strange 
notation and unusual technical terms. I have no mathematical training of 
any description at all, and I can work it...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 4-10-2009 10:51, Orchid XP v8 wrote:
> Darren New wrote:
> 
>> The real problem is that most hackware is written by people who don't 
>> know what they want. They don't figure out what they want to code to 
>> do before they write the code.
> 
> Personally, I don't know how the program is going to work until I've 
> figured out how to write it.
> 
> (Which probably just means I always implement my programs in the way 
> that's easiest for me to program...)

Next time, after you finished it, try to document how and especially why 
it works. Just as an exercise. I bet you end up documenting (and 
programming) something more efficient and robust.

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> The real problem is that most hackware is written by people who don't 
>> know what they want. They don't figure out what they want to code to 
>> do before they write the code.
> 
> Personally, I don't know how the program is going to work until I've 
> figured out how to write it.

Ah, but right there is the difference between documentation that you can put 
in javadoc and documentation you can't.

"What does this do" is in no way related to "how does it do it".

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 wrote:
> Similarly with CASE, you edit in the case tool and then regenerate the 
> source code.

Yep. This assumes you can put everything into the CASE tool that you need. 
If the CASE tool is only generating the skeleton, you need to be able to go 
back, is what I was saying.

Not being able to go back and forth is one reason the CASE tools are so 
expensive - they can't solve just the part they want to solve. They have to 
solve the whole end-to-end thing.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> Patrick Elliott wrote:
>> Its basically a mode flag, which when turned on, triggers, 
>> "show_grab_handles", and, "disable_control", or something like the 
>> second one. 
> 
> I see.  That's kind of what I thought. I thought you were talking about 
> the control doing something in the IDE, rather than the IDE driving the 
> control.
> 
>> Mind, a lot of this got easier with .NET, 
> 
> Yes. I never got into the design mode of COM stuff.
> 
Yeah. Wish I hadn't. Wasted a lot of time trying to solve something that 
just wasn't obviously solvable. Mind, I am sure you could work it out 
with enough time to play with IDispatch, but I was looking to the 
concrete example. I had wanted to design something that would allow you 
to make a layout for a window, then export the settings to XML, and 
later "reload" it. This would allow someone to make an importable layout 
for different games, which could even be sent over on the fly, as 
needed. The point was to avoid the overhead of needing the compiler 
suite to make the layout, or worse, having to use something like IE to 
"load" script and layout, when the client in question already had its 
own, far more efficient, script system, and just lacked access to a way 
to create custom windows.

Since then, some of these features have been added, but they are far 
more limited than they would have been if you could have just plugged in 
*any* control you wanted, instead of being limited only to those already 
supported (which may be faster than COM, but adds more code and overhead 
*in* the client itself).

The other issue we ran into was working out how to pull and IE and link 
in such controls dynamically, so they didn't have to be "predefined", 
and the client could pass on events from the attached control to the 
script system. That is documented... sort of. The only example shows 
using "one" control, in a very limited instance, doesn't go into detail 
on any other aspects, and gives no example of how to properly handle 
multiple copies of the control, *nor* several different controls. Sort 
of a, "this is how to park your car in a single space, but not in a 
crowded parking lot." In principle, someone with more understanding 
could have worked it out. I didn't even have a "current" version of the 
compiler to work with, which supported the API I needed. :p

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Darren New schrieb:

>> In contract-oriented programming, how could you possibly break the 
>> Order class by a change in the Customer class? 
> 
> By changing the contract of the customer class that the order class 
> relies on.  I haven't seen anything in a language where the order class 
> could say what parts of the customer class's contract it relies upon.

Ah, I get that point now... my mental image had dependency the other way 
round for some obscure reason.

Now that's a problem indeed: Changing a contract is a particularly 
problematic change. Because that's why contracts are there in the first 
place.

Note that a good contract places as many constraints on /both/ parties 
as possible, to get some "room to breathe" in case either side needs to 
be modified.


>>> The point I was making is that there are lots of paradigms
>>
>> I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
>> there are indeed lots of paradigms :-))
> 
> Sorry. There are lots of paradigms that let you do things like change 
> the type of a variable without having to have OO.

Maybe, but at any rate OO has been the most influential of these in the 
last decades.

>> But my primary point was that the OO /paradigm/ was highly influential 
>> in the creation of such type libraries - and that a non-OO approach 
>> doesn't get you there, unless you somehow "emulate" OO behavior.
> 
> Ehn. I'll disagree. I'll agree that container classes and GUIs both 
> benefited tremendously from an OO treatment, but I'll also assert that 
> non-OO modules and libraries (say, Ada83's) did nicely without the need 
> for OO.

As my point is the tremendous benefit thing, I can live with that 
assertion of yours.

Post a reply to this message

Orchid XP v8 schrieb:

> Well, when you compile a C program, you don't then edit the generated 
> machine code. You edit the original C program and recompile.
> 
> Similarly with CASE, you edit in the case tool and then regenerate the 
> source code.

That's the /theory/ :-)

Post a reply to this message

>> Similarly with CASE, you edit in the case tool and then regenerate the 
>> source code.
> 
> Yep. This assumes you can put everything into the CASE tool that you 
> need. If the CASE tool is only generating the skeleton, you need to be 
> able to go back, is what I was saying.
> 
> Not being able to go back and forth is one reason the CASE tools are so 
> expensive - they can't solve just the part they want to solve. They have 
> to solve the whole end-to-end thing.

True enough.

I think the main thing, though, is that there's generally not a huge 
demand for CASE tools. Rational Rose lets me program in a diagram which 
describes exactly how a given function executes, but... it would be 
drastically, *drastically* quicker to type this as text. The diagramming 
tool makes it take 10 times longer to do (more or less) the same job.

I think perhaps the job could be quickER with something like Haskell, 
since there are so few primitives to deal with. But even then, typing is 
likely to be faster. (OTOH, with fewer primitives, maybe the reverse 
transformation becomes more feasible...)

Post a reply to this message

Darren New schrieb:

>>> Actually, Ada can do this too, I'm pretty sure, even without using 
>>> its OO features.
>>
>> "Non-OO mainstream (imperative) language"?
>>
>> These languages all don't appear to fit that bill.
> 
> You don't think Ada or Tcl is mainstream?  Just because you haven't run 
> into them doesn't mean they're not widely used.

My copy of Wikipedia categorizes Tcl as "multi-paradigm: 
object-oriented, functional, procedural, event-driven programming" 
(emphasis added; I haven't done enough Tcl coding to verify this claim) 
- even though it does appear to be mainstream indeed, it doesn't seem to 
fit the bill of "Non-OO ... (imperative) language".

As for Ada: When I think "mainstream", I don't usually think avionics, 
weapon systems or spacecraft - or any other embedded or real-time 
application, for that matter.

>> Though it wouldn't stand in the way of that.
> 
> To some extent it would, depending on how your OO is integrated with the 
> rest of your system. OO tends to have many references to one object 
> scattered about in other objects. You have to avoid that if you're going 
> to incrementally upgrade code as it runs.

As I said, it depends on the runtime. If for instance the runtime would 
store object references as a combination of a "data address" and a "type 
identifier", it would be more than problematic to add data fields (due 
to inability to move the object on the heap), or to "upgrade" only some 
objects to the new implementation; if the runtime instead stores object 
references as pointers to memory blocks including both the data and a 
virtual method table, data size may still not grow, but implementation 
could be changed for individual objects of a type; and a runtime that 
happens to use chained references for garbage collection would have all 
the necessary power to actually relocate objects on the heap, thus 
allowing for arbitrary changes to the data structure. With such a 
runtime, your "object network" can be arbitrarily complex. Similar 
flexibility can be achieved by adding a level of indirection between the 
reference and the actual data.

Post a reply to this message

clipka wrote:
> Now that's a problem indeed: Changing a contract is a particularly 
> problematic change. Because that's why contracts are there in the first 
> place.

Right. This is why I laugh at all the people that tell me to just write unit 
tests and everything will be fine.

> Note that a good contract places as many constraints on /both/ parties 
> as possible, to get some "room to breathe" in case either side needs to 
> be modified.

This assumes you're not making fundamental changes like adding a new level 
of heirarchy to the product catalog or a new kind of management operation or 
whatever.  Depending on what you code in your contracts, they can really get 
in the way.

> Maybe, but at any rate OO has been the most influential of these in the 
> last decades.

Yes. See OP. ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message