Re: Variable declarations
Derek Parnell wrote:
>
> <SNIP>
> I know I'm going to be misunderstood by commenting here, but believe me
> I'm not being agressive or confrontational. I'm not big-noting myself, or
> putting anybody down. But....
>
> "the simple design of Euphoria" slips so easily off the tongue. But what
> does one actually mean by it? How is "simple" measured? Can it be measured?
> Are you saying the Euphoria is at the cusp and adding just one more thing
> suddenly pushes it over the edge and makes it no longer simple?
>
> Does simple mean "simple to use", "simple to write interpreters for",
> "simple to explain", ... or some mixture of these.
I don't know if I can define simple.
I was drawn to Euphoria because it seems to offer the simplicity yet power
that I first discovered in Forth. The basis of Forth is simple, but sadly
most implementations for Windows are overly complex.
Now I'm too new to Euphoria to know weather it's the direction I will go
for personal Windows app dev, but I'm optomistic because Euphoria is
providing me something I first liked in Forth, simplicity. A handful of
primitives, clean syntax, straight forward code formatting, and apparent
access to the OS and the machine. This may be because I haven't been
exposed to Euphoria long enough, but time alone will tell.
> Why does adding a test for the variable's "initialized" property make
> Euphoria's design not simple? All variables already have that property. We
> know this because the interpreter can detect it (thus the specific
> error message) and the debugger can detect it (thus the specific warning
> message). Variables already have other properties that we can inquiry
> about (length() for sequences, datatype for all variables) so how is
> this a big change for the language design. The concept already exists
> in the language.
Personally I don't know that adding an "isInitialized( object )" to the
language necessarily makes the design more complex so much as it makes
programs written in EU more complex. See some of my following comments
to see why I say that.
> Currently we have to workaround the issue. By this I mean that we might
> initialize a variable to an impossible value in order to detect if
> it has been 'initialized' by some other process. However, this leads
> to inefficiencies or non-intuitive situations. For example I find myself
> declaring some variables as 'object' so I can initialize them to zero, and
> then later test if they been changed to a sequence or not. If not, then I
> might have to perform some lengthy process to give them a default value.
> And by the way, some default values might not be not available until other
> values have been assigned. I have even created variables to track
> the 'initialized' state of other variables - how bug-inducing is that!
Yes your descriptions of work arounds sound complex and maybe what you are
programming requires that kind of complexity. 9 times out of 10 though
in my own experience I find that my most complex code is due to my own
failure to "see" the simple solution. I tend to over complex a problem.
I don't say that this is your case, only that it's my own experience. I
also don't think that EU should be or can be the "be all-end all" to all
programming problems, that would be true Euphoria, something that can only
be found in Utopia.
Your work arounds may be complex, but on the flip side adding initialization
state functions would also require the elimination of some of the
non-initialized checking in the interpreter. For example you would need
to allow for passing a non-initialized variable to a function/procedure
to do some of what you want to do. That complicates my code because I
can no longer assume that all the arguments passed to my routine are
initialized, I then am required to complicate my code, especially my
reusable code to ensure I have initialized arguments.
> > Personally I despise dealing with
> > Null in other languages, it's too ambiguous.
>
> I don't see this. Its either initialized or not. What is ambiguous?
> Currently, this is true for all variables. Its just that we can't test
> for it programatically.
Ambiguous in that a boolean is true/false/null it is not really a boolean
but a tristate. Ambiguous in that a string is either a value, a null
string ( ie. empty string ), or null. Then to top it all off, Java
allows for nulls with Object based variables but the primitives can't
be null. And then I agree with your following statement about VB, all
different types of Null. Then there's the differences between different
languages about how to handle nulls. Empty in some languages return true
for null values, others return false, so is Null empty? Depends on each
languages interpretation. Then dealing with Nulls in SQL drives me
batty. Some tools I have to use ignore rows that contain a null so I have
to make sure I default null values in my SQL statement, a real PITA.
>
> Visual Basic got it wrong by making it more confusing that it needed to be,
> by having Null, Nothing and Empty.
>
> The D language has implemented this for arrays and classes, but not for
> intrinsic datatypes or structs. Again, not clever.
Reminiscent of Java
> Euphoria already has implemented it for all datatypes, but it just doesn't
> allow programmers access to the property.
>
> >Years ago I used to program
> > in dBase/Foxbase/FoxPro and loved the lack of Null and the automatic
> > defaulting, nums to 0, strings to "", logicals to false. Although the
> > lack of explicit declaration could lead to sloppy code and unexpected
> > errors.
>
> Yes, well this is a whole other issue. Though implictly initialized
> variables can never be uninitialized 
Exactly the point, never an uninitialized state. I would have loved the
dBase approach more if it required variable declaration.
>
> > And as optional arguments go, I have a love/hate relationship with them.
> > While I love the ability to drop some arguments that may not be necessary,
> > I hate how optional arguments can lead to sloppy code. I try to allow for
> > a "NA" state for arguments which may be optional and then test for that
> > state in the function/procedure. This forces me to be specific in calling
> > the function/procedure that if I don't want the argument I must explicitly
> > set it to the "NA" state.
>
> I've gone even further! In trying to implement signature matching for OO
> systems in Euphoria I've done this (I'm still undecided if its a good thing)
> ...
>
> procedure FuncA_2(object Parm1, object Parm2)
> . . .
> end procedure
>
> procedure FuncA_1(object Parm1)
> return FuncA_2(Parm1, defparm2)
> end procedure
>
> procedure FuncA_0()
> return FuncA_2( defparm1, defparm2)
> end procedure
>
> procedure FuncA(sequence parms)
> return call_func(routine_id("FuncA_" & sprintf("%d",length(parms))),
> parms)
> end if
>
> Nasty stuff.
Yes, nasty stuff, but then again I would not consider OOP a simple
programming environment although there are simpler OOP implementations
than others. I think it's funny how many Forth systems have to complicate
themselves with OOP when many of the advantages of OOP are intrinsic to
Forth.
>
> > >
> > > Ooops! Sorry - there I go bad mouthing Euphoria and RDS again. I apologize
> > > to all forum readers who are upset when people do that heinous crime.
> > Since I'm new to Euphoria and this list I wouldn't know your history of
> > "bad mouthing" so my opinion here may show a lack of sensitivity to the
> > situation,
>
> Its nothing. I'm just a little jaded and battle-scarred at the moment.
> I'll get over it and grow-up soon.
Sorry to hear that, I hope it's not because you are trying to use the
wrong tool for the wrong problem.
>
> >but I don't see this as bad mouthing. You might change your
> > choice of "RDS way" to "Euphoria way" to make it a statement of "this is
> > how it is" rather than the more political statement of "this is how it is
> > because this is how RDS wants it".
>
> You're probably right. I don't tend to keep quiet; I'm not a status quo
> man (ironically though, they are one of my favourite bands).
I personally don't think you should stay quiet! What is a good
programming community if there aren't outspoken individuals that keep
everyone thinking. But one of the disadvantages of being that outspoken
person is that sometimes in the ferver challenges either turn into
insults or are interpreted as insults. Don't be cowed into silence though,
just always be ready with an apology when your misinterpreted and be
ready for personal attacks by people not desireous of being challenged to
think.
>
> > Even though the more political
> > statement is true, it goes without saying since Euphoria belongs to RDS.
>
> Does it? This is where I might differ a bit from some. For example, when I
> publish an implementation of Euphoria, I'll have a GOTO facility in it. Not
> because I think it is a good thing, but because some of my customers do,
> and it is not forced on all to use. Sure, a product can't be all things to
> all people. But a product can always be better than it currently is.
>
I'm too new to Euphoria to know what the copyright is etc. And I guess your
right in that even if the language itself is copyrighted, we have seen
many examples of companies getting around that ( for example Microsoft C#
to get around Java )
And yes, any product can be better, but a system that prides itself on
simplicity usually settles on a strong simple "kernel" if you will which
changes very little, and most of the improvements are in the add-ons in the
form of libs etc.
Although I did just think of something that RDS might want to consider.
It might be that features like Un-initialized allowances could be added as
options which default to the current way, but programmers like yourself
who want the features can switch them on without imposing the overhead on
programmers like myself who don't need them. ( ie. like VB's Option Explicit )
I know this would be more complicated than just that for example a generic
lib routine, how does it handle itself if it was written assuming NULLS off
and is called from an app that has NULLS on?
> I'm currently the primary person coordinating the Win32lib library. If
> I could work on it full time, it would be a much improved beastie. There
> are a number of areas that it falls down, with respect to customer
> satisifaction, and I only wish I had the time to address those issues
> properly. Speaking of which, I'm trying to package up the next release
> today.
Haven't yet messed with any of the Win32 stuff yet in Euphoria. I'm working
strictly with console stuff right now figuring I can tackle the frontend
later.
> --
> Derek Parnell
> Melbourne, Australia
>
|
Not Categorized, Please Help
|
|
