SL viewers not written in C++?

That will depend on the person doing the learning.

Learning C++ is a non-trivial task.

I'd suggest going to http://www.microsoft.com/express/vc/ and getting the free Visual C++ Express Edition, assuming you are on a Windows system.

They've got enough tutorials and help information to consume the entire rest of a person's life.

All free.

It will be somewhat roughly as hard as taking several years of college math.

I found free educational resource place on it too through these colleges that give free classes online from some educational links someone posted here bit back ago but I have been bit intimidated to tempt it.
Yet now I got this stand alone island on hard drive I have been having these fantasies of personal viewer.
I really like my own personal viewer if I can't brain to rezz how to do this.
I am using the stand alone version in RealXtend from Open Life, but I do here the hippo version at least lets you change appearance and music in the stand alone version.
But I have been having my own fantasies of what I would want in my own personal viewer if I could pull it off, issue is knowing how and figuring out not to break the client while figuring it out before I do something more complex like ability to get animations or poses to work or features not even in SL or any where else.
Is the possibilities limitless if I can figure out C+++ or will I hit some walls? Is it possible to have multiple types of appearance screens one for special custom UVs for my private world and testing one for SL?

You're quite free to believe that, just as I'm quite free to believe the opposite (well, just the waste of time / portability / up to the job parts; I don't dispute it is written in C++ ).



There's no evidence that a port would introduce "significant bugs". In fact, ports often find and correct "significant bugs" that were obscured by language constructs as well as developer inexperience with the original language.

You're right that ports could always be playing "catch up", just as all the third-party viewers do today, assuming that the intent isn't to fork from a snapshot to begin with. There's no hard-and-fast rule that says a port (or any alternate viewer, for that matter) HAS to remain identical in functionality to the original. Similar enough to be functional (again, assuming that is the intent), to be sure, but not enough to make the "catch up" game a priority.

You're also right that it is a significant amount of work. Still, it is doable.

There are lots of reasons why people would want to do a port, not necessarily just for fun, and NO one here is suggesting that LL should be the one doing it, or even remotely supporting it. They don't have to.

I have ZERO desire to work on a C++ viewer. I can; that's not the issue. I just don't enjoy working with C++. I've been a Pascal/Delphi programmer for almost 30 years, and it is the language I like. *shrug* I don't consider it a "waste of resources better spent elsewhere". I have done ports of all kinds of applications; I learn and I make them better. I don't consider any of that to be a "waste".

I pity anyone that would try to rewrite it in ASM.... and yet I can't help bu wonder at all the fun optimizations that could be made (and promptly broken by a required patch or update requiring an oh so fun disection and debugging to keep up)

but hey for real fun how about dhtml? though I'm not quite sure to handle caching with jscript minus the server backend.

Thanks so much SuzanneC, will check it out. I love math so feelin hopeful.

Any nontrivial work results in significant bugs ... even work to reduce bugs and increase reliability, oddly enough, but hopefully in that case the net effect is a reduction. True that porting finds and fixes bugs, esp unknown ones (and often, unexperienced ones: ones that are bugs that never actually happen).

And you call this person a FRIEND? LISP is very cool, but I wouldn't recommend it for starters exept for exceptionally gifted people who are extremely serious about programming (and sticking with programming).

My point exactly.

Maybe they'd get the rotation code fixed, finally.

Well written Forth generally involves creating a custom metalanguage with the objects you're most interested in as first class types.

But really, the viewer should be implemented in GNU Smalltalk.

What would you say exactly is your reasoning about that?

bah you know exactly who you should be asking about this!

MBASIC?

A very dear friend.
I guess he thought that if I was going to put the time in, I should learn what he thought was the best language going. And aren't most of us in SL gifted?

Wait, in order to make the code more accessible you're porting it away from C and into Delphi? Why not just go with something more popular like BrainF*ck?

I think that Lisp (or any fully functional programming language, which Lisp isn't) would be easier to learn if one didn't have prior exposure and practice with procedural languages. It's just so off the wall once you're in the procedural frame of mind. I know I have to learn Lisp all over again every time I need to do something in it.

Anyway, there's nothing wrong with C++. It builds character.

LISP is a very powerful language, but it's also very abstract. For someone with the mental horsepower for it, it might be a great introductory language to programming. They might find any other language unnecessarily restrictive. However, learning LISP doesn't help much to learn most other languages (with exceptions like TCL, which are very LISP-like), and most people would find it too much to grasp at once for learning purposes. Explaining quoting is hurdle enough for many, even though it's such a simple thing (use versus mention).

I would recommend Java or Python instead. I don't know C#, but I suspect I'd put it in the same category -- but maybe not, if it's to C-like in its ability to obfuscate.

However, I think LSL is a great first language. It's missing an important aspect (data structuring abilities, since you have neither structures nor lists of lists built into the language). But it has a great advantage in that you can do very cool stuff with extremely little code. It's actually a very compact language in terms of how little you have to learn (about the language) to get a lot done. It does require learning a bit about the world, of course, but then so does any RL coding, and the cost there (in terms of doing anything remotely as directly useful and operable and impacting your world) is SO much higher. You have to do a LOT of coding in RL to get anywhere near as cool of stuff as you can get with a relatively simple script in LSL. So, it wins from the standpoint of motivation. It loses in terms of learning higher structure, which is important -- but usually that stuff comes later anyway.

LISP is the coolest language going, from the theoretical point of view. There's no distinction between code and data: basically, the code *is* data, but data that gets interpreted. Or, data is code that doesn't get interpreted -- take your pick; both are oversimplifications. And coolest of all, since both code and data are represented the same way, your code can build code (as "data" and then execute it (as "code". How cool is that?

Note that I said "exceptionally gifted", and also "serious about programming". I should also add, someone who's very good at abstractions; who picks up radical notions quickly and runs with them.

LISP code tends to be challenging to read. With LSL, you can read it pretty clearly, one thing happens after the other, loops and conditionals are nicely indented, etc. It's a descendent of a long line of languages that were designed to make it easy to read what the code is *doing* (thus being called a "procedural" language).

The designers of LISP weren't thinking about making the code easy to read or understand. They were thinking about a very high level abstraction of what programming *could be*, and took it from there. With lisp, you tend to think more about what the code "is" than what it "does". Sartre woulda dug it, understanding as he did that to do is to be, and that the two are just different aspects of the same thing. If you followed that, then LISP might just be for you. But it's certainly not the best first language for most.

Actually, the Lisp syntax was almost an accident. The intention was that they were going to have a more conventional language and the s-expression syntax was just going to be internal and for bootstrapping. Then they found out how powerful it was.

The version of Lisp I learned on (Lisp 1.5) had a flag to change the syntax from:

(foo bar baz)

to:

foo(bar baz)

which seems to have been left-over from the original plan.

Lisp can be a very fun language, but as noted is NOT optimized for linear thinkers, not that a linear thought process isn't workable.

TBH I would recommend people just starting to try jscript, since it's very accessible, and is strong enough to create useful content without being tied to a specific platform or environment. then tackle something like VB or Java, before C and it's variants... by the time you get to your second language you'll have structure down, and after that most languages are just variations in syntax. don't get me wrong, LSL mas it's merits for teaching, but it ingrains some concepts you don't see used elswhere, at least not in the same context.

Dijkstra claimed that teaching people Basic caused brain damage.

I've been having to use Visual Basic. To misquote Terry Pratchett, things can happen to programmers in Visual Basic's libraries that make having your face torn off by tentacled monstrosities from the Dungeon Dimensions seem like a light massage by comparison.

VB makes Applescript look good. And that's hard work.

*Shudders*

No, you've got that backwards. C is closer to BrainF*ck than Pascal.

C is closer to assembler than Pascal, but what C has over Pascal is that it's possible to write a non-trivial but portable program using one implementation of C, then take it to another implementation, and have it work with at most minor modifications.

That's NEVER been the case for any Pascal-family language, thanks to Knuth's neglect of I/O. Even with Modula 2, the third or fourth generation of the Pascal family, I was unable to write a program that would work with two different implementations of M2 even on the same computer. The only reason that Modula-3 has been portable is that the main implementation of Modula-3 was written in portable C.

And by "non-trivial" I'm not talking about a program as complicated as Second Life, I'm talking about something like a newsreader.

I used to be a big Pascal booster, back in the '70s and early '80s, but the first time I tried to use it for anything *real*... *shudder*. Talk about lock-in. You were better off writing your program in Fortran or Forth if you wanted to use it outside the hothouse compiler you wrote it in in the first place.

It's been a few decades; maybe you should look at it again. Both Delphi/Kylix and FreePascal are quite portable.

Modula 3 is quite portable, too. It's cross-platform portability that counts.

Can you write a non-trivial program in Delphi and have it run in FreePascal without modification? I've had C programs I wrote 25 years ago... on MS-DOS and AmigaDOS, 16-bit... compile and run unmodified 20 years later... on Tru64 UNIX on Alpha with DEC's compiler, and on Solaris with Sun's, and on OS X with GCC.