The Artima Developer Community
Sponsored Link

Weblogs Forum
Postfix Typecast Operations

22 replies on 2 pages. Most recent reply: Sep 30, 2005 5:10 PM by Terje Slettebø

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 22 replies on 2 pages [ « | 1 2 ]
Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Postfix Typecast Operations Posted: Sep 28, 2005 10:58 AM
Reply to this message Reply
Advertisement
> Open class, what's that? Is it a class which you can add
> methods to after it is defined? I have heard of such
> things, but I never got close to one. Which languages
> support this? Is there other names for this functionality?
>
>
> Previously, I always automatically dismissed the idea of
> extending classes post-definition as being something
> unclean, and which would lead down the road to spaghetti
> code. Should I rethink this prejudice?

Please don't take this personally but I'm going to rant generally at your expense.

We have people designing programming languages with no experience with dynamic languages?

Here - right here - is why I quit programming and what is wrong with the industry at large. We have people who are half educated designing programming tools with no sense of history and limited PERSPECTIVE which you get from having at least a theoretical understanding of at least half a dozen other kinds of programming systems.

This is the narrow perspective that got us
C++, then Java - both of which are clearly evolutionary dead ends and wrong turns on the evolutionary path towards effective end user computing.

We are in a RUT people and its because even the vanguard is at best half educated.

You should have to get a license to produce a programming language and you'd better show more than a passing familiarity with LISP, CLOS, Smalltalk, C/C++, prolog, something from the type inferencing crowd (ML?), data flow concepts (prograph was entertaining here), SQL, and a couple scripting languages.

Rant over (sorry man).

Meanwhile, let me invite you over to the dark side for a bit. Go get a copy of squeak or buy a Mac and write a cocoa application in Objective C. It'll rock your world and have you rethinking a lot of what you now believe. Also, you might read the traits paper - its all about attaching methods to arbitrary classes after the fact.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Postfix Typecast Operations Posted: Sep 28, 2005 12:18 PM
Reply to this message Reply
> First off, I will start by saying that, in my opinion, the
> reason why your example does not feel right is that your
> casting is done the same way you would use a function.
> Functions use verbs, so our brains make verbs out of them:
> "centimeter the fun minus that", as opposed to your
> prefered "the fun minus that centimeters". Which I'll
> admit does sound nicer, but is it warrented?

This is pointless because the example is completely artificial. You cannot reasonably argue the merits of syntax based on a single example. I was simply countering the previous argument.

> Whenever I see anyone play with the ordering of the
> syntax, it always raises an internal flag

Compared to what? A particular individual's narrow view of what syntax should be? There is no prescribed correct syntax from which to measure. Historically successful programming language syntax is that which maps to the non-programmers conventions, such as those already established for centuries by mathematicians, scientists and engineers.

> ... First of all,
> let's go with a more traditional, less ambiguous way of
> prefixing a cast:

Traditional from what sense?

> do_it((cm)(fun() - that()) / (sec)(something() *
> the_other())

How is it less ambiguous?

> This personally feels just as good as with using a suffix
> (of course, this line of code itself in real code should
> maybe be broken up into parts).
>
> But if trying to map your
> language to English is your concern, tell me how you
> would, for example, make a function that checks if a
> number divides another?

This has nothing to do with postfix typecast operations.

> divides(a, b)? In a stream of
> code, this looks weird, because the verb tense is
> different than all the other function verbs. Of course, in
> normal math, you would do "a divides b", but again that is
> playing with the ordering of your language. Would it be
> worth it in this case too?

No. Some language do support this though (e.g. Scala). This is however entirely unrelated. My goal wasn't to model english but rather to model physical equations.

> I just think that using suffixes can probably be used for
> something better in the future than just another way of
> doing casting. We already have one of those.

What do you mean "we already have one of those"?

> As a side question, will you have a different type for
> every combination, such as having a type that is
> cm^4/sec^2*kg^3?

Yes. This can be defined as needed on the fly using template metaprogramming. Take a look at http://www.boost.org/libs/mpl/doc/tutorial/representing-dimensions.html

> I guess when there is a type that isn't
> used much in the real world, you could have a catch-all
> type that just keeps track of how many of each unittype
> there is.

That is another valid approach.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Postfix Typecast Operations Posted: Sep 29, 2005 7:17 AM
Reply to this message Reply
You might want to take a look at Fortress as well. It has built in support for dimensions and the syntax looks like yours. Fortress is being designed as a Fortran replacement. The designer is Guy L. Steele Jr. In my opinion, he's one of the best language designers around. You can download the spec from the wikipedia entry:

http://en.wikipedia.org/wiki/Fortress_programming_language

Michel Parisien

Posts: 25
Nickname: kriggs
Registered: Jul, 2005

Re: Postfix Typecast Operations Posted: Sep 29, 2005 9:40 AM
Reply to this message Reply
> > First off, I will start by saying that, in my opinion,
> the
> > reason why your example does not feel right is that
> your
> > casting is done the same way you would use a function.
> > Functions use verbs, so our brains make verbs out of
> them:
> > "centimeter the fun minus that", as opposed to your
> > prefered "the fun minus that centimeters". Which I'll
> > admit does sound nicer, but is it warrented?
>
> This is pointless because the example is completely
> artificial. You cannot reasonably argue the merits of
> syntax based on a single example. I was simply countering
> the previous argument.

Yes, I was just counter-countering myself. If the example wasn't there, I would have come up with my own. Feel free to give an example that truly shows the advantage of postfix typecasting at it's fullest.

> > Whenever I see anyone play with the ordering of the
> > syntax, it always raises an internal flag
>
> Compared to what? A particular individual's narrow view of
> what syntax should be? There is no prescribed correct
> syntax from which to measure. Historically successful
> programming language syntax is that which maps to the
> non-programmers conventions, such as those already
> established for centuries by mathematicians, scientists
> and engineers.

You're right, I should have made myself clearer: what irked me was that there were two methods to do the exact same thing. I don't mind if you have something like a + b being represented as well as a._plus(b), or what have you, since it is highly unlikely the _plus will be used for anything else, but I think postfix is a precious syntax rule, and it could be used for something that isn't already implemented some other way.

> > ... First of all,
> > let's go with a more traditional, less ambiguous way
> of
> > prefixing a cast:
>
> Traditional from what sense?

If you don't like traditional, let's stick with less ambiguous. All that I meant is (though I admit "traditional" was the wrong word to express this) I know we both know this way of casting. The exact syntax is not the issue here, as long as it is different from the syntax for something else (in this case, calling a function).

> > do_it((cm)(fun() - that()) / (sec)(something() *
> > the_other())
>
> How is it less ambiguous?

Because cm(...) could be read as a function. It is only after your brain reads it that you realize it is a cast, because it isn't a verb. (cm)(...) on the other hand makes it clear that it is a cast probably before your brain even interprets the meaning of the word inside it, cm. Knowing what something is doing before reading the english that describes it increases the speed of human reading interpretation immensely. I am not saying (x)(...) is the right or only way to cast. It is just, in my opinion, better because it gives context far better than a syntax rule shared with functions.

> > This personally feels just as good as with using a
> suffix
> > (of course, this line of code itself in real code
> should
> > maybe be broken up into parts).
> >
> > But if trying to map your
> > language to English is your concern, tell me how you
> > would, for example, make a function that checks if a
> > number divides another?
>
> This has nothing to do with postfix typecast operations.

Well if matching English, or math, or some other non-programming syntax isn't your concern, then what about postfixing gives you a warm feeling inside that tells you it is right?

> > divides(a, b)? In a stream of
> > code, this looks weird, because the verb tense is
> > different than all the other function verbs. Of course,
> in
> > normal math, you would do "a divides b", but again that
> is
> > playing with the ordering of your language. Would it be
> > worth it in this case too?
>
> No. Some language do support this though (e.g. Scala).
> This is however entirely unrelated. My goal wasn't to
> model english but rather to model physical equations.

Well again, a divides b (which, if the pipe character weren't already reserved in Heron, I could have written as a | b, but the point is that it is something that isn't implemented natively in the language, so let's forget about the pipe) is how it would be represented in physical equations, no?

> > I just think that using suffixes can probably be used
> for
> > something better in the future than just another way of
> > doing casting. We already have one of those.
>
> What do you mean "we already have one of those"?

We already have, in Heron, a method of casting is what I meant. Prefix casting. Unless you're saying you want to get rid of prefix casting, but I wasn't under that impression at all. That would invalidate my whole rebuttle. :)

> Yes. This can be defined as needed on the fly using
> template metaprogramming. Take a look at
> http://www.boost.org/libs/mpl/doc/tutorial/representing-dimensions.html.

Thanks for the link-up.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Postfix Typecast Operations Posted: Sep 29, 2005 6:47 PM
Reply to this message Reply
I know cdiggins doesn't need me defending him, but I would like to offer a different world view:

/* We have people ... designing programming tools with ... [a] limited PERSPECTIVE which you get from having at least a theoretical understanding of at least half a dozen other kinds of programming systems.
*/

I can't say how many languages cdiggins knows. I do know he's interested in Scala (functional programming, http://www.cdiggins.com/presentation.ppt). I also know that, unlike the Java guys, he is making a serious effort to make Heron multi-paradigm. It has contracts from Eiffel, AOP and delegates which are famous from C# (but appear in other languages), it has various C++ techniques, and there's an effort to import functional programming and create an interpreted environment.

I find it interesting that cdiggins' attempts to include these techniques don't count unless he also includes the concept of extending classes at runtime.

/* You should have to get a license to produce a programming language
*/

Or you should be able to produce a language, and if it leads to productive programmers on the market it can be judged a success.

/* Go get a copy of squeak or buy a Mac and write a cocoa application in Objective C.
*/

I don't know how good GNU Objective C is (since it comes with gcc), however I understand it was created by NeXT when Steve Jobs was at the head. The ability to add methods and traits after the fact is also available in JavaScript. At least the spec says it's available (I've never seen it used).

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Postfix Typecast Operations Posted: Sep 29, 2005 6:55 PM
Reply to this message Reply
I always find Larry Wall's arguments regarding language design (eg., references to irregular verbs in natural language) to be very interesting (www.perl.com). One of his tenets is that different concepts should look different. OTOH, Apocalypse 5 makes Perl regexes look like function calls (http://www.perl.com/pub/a/2002/06/04/apo5.html).

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: multi-paradigm languages Posted: Sep 30, 2005 12:13 PM
Reply to this message Reply
After posting last night I did a little reading, so let me set the record straight in regards to dynamic languages:

While I still say that every time I have a variable of one type and need a variable of another, I've always created a new variable.

But I can see valid reasons to add methods to types that have been defined without subclassing. I can even see reasons to add methods to an already existing object. I'm thinking specifically of using objects to represent web servers that offer various web services (SOAP, SOUP, XML-RPC, etc.) that are discoverable at runtime.

There are ways to do that in C++ (see Amulet for the old way http://www.cs.cmu.edu/afs/cs/project/amulet/www/amulet3-release.html#documentation , today I'd use std::map and function-like objects [a.k.a. functors]). However using a language with real support for this would be much easier.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Postfix Typecast Operations Posted: Sep 30, 2005 5:10 PM
Reply to this message Reply
> Please don't take this personally but I'm going to rant
> generally at your expense.

It's a little hard to see how he wouldn't take this personally.

> Here - right here - is why I quit programming and what is
> wrong with the industry at large. We have people who are
> half educated designing programming tools with no sense of
> history and limited PERSPECTIVE which you get from having
> at least a theoretical understanding of at least half a
> dozen other kinds of programming systems.
>
> This is the narrow perspective that got us
> C++, then Java - both of which are clearly evolutionary
> dead ends and wrong turns on the evolutionary path towards
> effective end user computing.

Says someone who has quit the industry. Well, then, if you have all the answers - the "true" way foreword, please enlighten us.

However, I guess it's easier to be a "armchair quarterback", than to actually do the hard work in advancing the industry - which people like Christopher contributes to! And which you don't (not being part of the industry, according to yourself).

Your lack of knowledge about modern C++, such as what generic programming and generic concepts (in C++) are about (at least, so it appears in the "Implicit versus Explicit Dynamic Typing" thread), apparently doesn't stop you from making sweeping statements and judgement about C++. "Don't confuse me with facts, I've made up my mind..."

I've lost count of the number of times "naysayers" have spelt doom for C++ (or even Java), and yet, C++ is as vibrant as ever, with a lot of exciting new proposals, and a new version of the standard in the making. In the words of Bjarne Stroustrup: "C++ will remain a major language for decades to come. It will evolve to meet new challenges. Languages in which useful systems are built don't just fade away." ("The Future of OOP", The Future of Software Magazine, 2000/2001, http://www.utm.mx/~caff/poo/The%20Future%20of%20OOP.pdf)

And I'd add: Long after the latest fads have come and gone.

I'm also reminded of another Stroustrup quote: "There are only two kinds of languages: the ones everybody bicker about and the ones nobody uses".

And speaking of "legacy code or languages":

---
What is "legacy code"?

"Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling.
---

(http://www.research.att.com/~bs/bs_faq.html#legacy)

> You should have to get a license to produce a programming
> language

Maybe there should be a similar "license to criticise": to actually know what you talk about.

Either way, I don't think there should be any such arbitrary constraints on language designers: Christopher has shown himself in discussions to be a very competent person, and has shown a willingness to learn, and a humble approach to people. Such is the mark of a true professional, not a negative "naysayer" who has left the industry.

> Meanwhile, let me invite you over to the dark side for a
> bit. Go get a copy of squeak or buy a Mac and write a
> cocoa application in Objective C. It'll rock your world
> and have you rethinking a lot of what you now believe.
> Also, you might read the traits paper - its all about
> t attaching methods to arbitrary classes after the fact.

Apparently, you think that ridiculing people is the way to get people to listen to your point of view. It seems you could use some learning in the people skills area, as well.

Regards,

Terje

Flat View: This topic has 22 replies on 2 pages [ « | 1  2 ]
Topic: The Temporary Assignment Problem and Transfer Semantics Previous Topic   Next Topic Topic: Metaprogramming on Steroids: Overloaded Type Operators


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us