On 14/08/2012, at 4:43 PM, Dobes Vandermeer wrote:
>
> > Why not use functions instead, like:
> >
> > class Tuple {
> > typedef fun headtype(X) => ... magic ...;
> > typedef fun tailtype(X) => ... magic ...;
> > typedef fun headtailtype(X) => headtype(X)*tailtype(X);
> >
> > fun head[T](x:T):headtype(T) => ... magic ...
> > fun tail[T](x:T):tailtype(t) => ... magic ...
> > fun headtail[T](x:T) => head(x), tail(x);
> > }
>
> Because at present (on todo list!) you cannot use functions in a pattern
> match.
>
> The headtail() version returns a tuple, which you can pattern match on.
that cannot work, because you cannot specify the type of "tail"
or of "head" given a tuple of type T.
> Yes indeed. because normally people in weak languages like C++ use
> RTTI to do that boxing and unboxing, and that means BAD DESIGN and
> RUN TIME ERRORS.
>
> Well ... sure but Java has a lot less of this problem.
On the contrary, Java is entirely constructed out of this
extremely stupid and very bad idiom. Its all you can do in
(the old) Java (without polymorphism hacked in).
That's why I abhor Java and condemn Sun outright
for setting computing back more than a decade.
C++ for all its warts has (somewhat crude) polymorphism and had it
long before Java was invented.
> I'm just thinking of having some extra help from the compiler to generate
> some union types and the operations on them so you don't have to do it
> yourself.
Sure. The compiler already generates some operations.
However some of this had to be removed because it caused
problems.
At one stage I had code which generated "str" for enums.
So you could do
enum X {a,b};
var x = a;
println$ x;
and it would print "a". Cool. Except for one problem: I had enums
binding to C for control of mmap() function.
The problem was some of the options weren't available on OSX.
Only on Linux. And the generated "str" function decoded ALL
the possible enum values and the generated match failed
(at C++ compile time) on OSX because it referred to a non-existant
C enum value.
> You have to deal with inputs - that means runtime errors if the inputs didn't
> match expectations.
Yes but these are NOT run time errors (unless your code fails
to detect them).
By run time error I mean the program encounters an unexpected situation
as a result of a programming error.
> Well, depending what you mean by "runtime error" anyway. If that's
> restricted to only ClassCastException and NullPointerException and
> StackOverflowError then sure, you can do a lot to eliminate those.
You're using Java terminology I'm not familiar with.
There are other errors: division by zero, infinite loops,
and in C/C++ dangling pointers. These are nice errors,
because they're always caught,
The bad errors -- you get the wrong answer.
These are really bad, because you just don't know.
Type systems tend to help ensure correctness,
although getting the wrong answer is still possible.
> I guess it depends on your definition of "bug", but Felix is only catching a
> fairly narrow class of bug - the "type error". Java catches the majority of
> these,
Sure .. at run time. in the clients hands. And often enough
it doesn't catch what *should* have been type errors because the
programmers have no idea how to type things correctly in Java,
because most of the time you simply cannot do so.
How do you code unions (sum types) in Java?
It's bad in C++ too, but not quite so bad.
> Type systems don't know if you've entered the right formula in the first
> place.
Oh yes, most of the time they do, if your type system is good enough.
A trivial example: in physics you know if your formula is likely to be
correct, because you can apply dimensional analysis.
> In a game, your type system can't tell you if your A.I. algorithm is faulty,
> nor can it prevent characters from getting "stuck" in strange geometry, or
> make the game impossible to complete (without restarting) due to some set of
> incorrect logic.
Certainly it can help a lot with this. All you need is way to
easily see and prove suitable properties.
For example if you're doing a "physics" game you can check the
conservation of momentum and energy is preserved.
> C++ is quite good for making games, it strikes a good balance between speed
> and safety. It lets you get low level when you need to. There isn't really
> much in terms of better alternatives since relatively few other languages
> meet the performance criteria.
Felix of course. The coroutines provide a massively superior modelling
tool, than allows NPC's to be independently programmed an interact
in controlled ways: basically "a thread for every NPC" except without
the overhead of pre-emption.
If you think current games are using good technology and achieving
good results ... well you haven't played very many games. you haven't
seen how utterly primitive the gameplay engines are and how totally
useless the logic is. Most games have improved in terms of graphics,
but not because of good programming by game developers,
but because of pre-programmed high level functionality in GPUs.
> "Worst possible programming technology" seems a bit over the top. You seem
> to have a grudge against OO
Of course I do. It is PROVEN to be a total and utter fraud and anyone with
5th form high school mathematics can understand the proof in 10 minutes.
> or C++
I'm an ex member of the ISO Standards committee that designed it.
I'm entitled to be annoyed by the failure of the committee to understand
basic computer science.
the new generation on the committee has a bit more experience
and understanding but it is too late to repair the damage.
> or something that is clouding your judgement. Surely you could agree that
> ECMAScript is worse than C++ and/or Lua for just about everything and yet it
> is growing in popularity due to its "Cross-platform" capabilities.
Javascript + DOM is popular because it is THE language you can use to control
browsers.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
