Don Clugston wrote:

<snip>

>>
>> I couldn't have said it better myself. :)
>>
>> A pleasant side-effect from all this is that it may help increase code-mobility
>> across the windows/linux/mac divide, for any dynamic D binaries (x86 object
>> files that comply with the D ABI) that are free from OS-specific code.
>> Provided, that's just theory for now, but it should be possible.  While that's
>> not "run-everywhere", it gets you far enough to make certain styles of plugin
>> architectures very possible.
>>
>> - EricAnderton at yahoo
> 
> 
> In digitalmars.com digitalmars.D:35128, Walter said of the difference in reals between Linux and Windows:
> 
>  > > pragma's DDL lets you (to some extent) mix Linux and Windows .objs.
>  > > Eventually, we may need some way to deal with the different padding.
> 
> I think it's a pipe dream to expect to be able to mix obj files between
> operating systems. The 96 bit thing is far from the only difference.
> 
> Now, he's quite knowledgeable, but I'd love to prove him wrong on this one. I find it hard to believe that it would be impossible. I guess the question is, will the subset of functionality that works be sufficient to be useful? I guess we won't know until the ELF side is working.
> 


One thing I would rather see in portable object formats is hierarchical formats rather than linear ones.  Code is inherently tree-like, yet Java byte codes(and other binaries) are in linear, stack based format.

The slim binaries idea from Oberon used tree byte codes, and it compiled  modules it loaded on the fly!

-DavidM

Disclaimer:

I'M JUST BLURTING OFF-HAND HERE, ANYONE IN A HURRY, OR LOOKING FOR
WORTHWHILE CONTENT, OUGHT TO SKIP THIS POST.


pragma wrote:
> In article <dvs41e$1ae5$1@digitaldaemon.com>, Sean Kelly says...
> 
>> pragma wrote:
>> 
>>> In article <dvrrca$103i$1@digitaldaemon.com>, Don Clugston says...
>>> 
>>>> In digitalmars.com digitalmars.D:35128, Walter said of the difference in reals between Linux and Windows:
>>>> 
>>>>>> pragma's DDL lets you (to some extent) mix Linux and Windows .objs. Eventually, we may need some way to deal with the different padding.

If we specify a new spec, we could have library files that are usable in several architectures. The compiler could even automatically generate them as multi-platform binaries. As to the main executable, this might be harder.

>>>> I think it's a pipe dream to expect to be able to mix obj files
>>>> between operating systems. The 96 bit thing is far from the only difference.

The obj files the compiler makes, don't necessarily need to have anything to do with the OS or OS calls. If all system calls go through the runtime library, then it can sort out any OS-specific stuff. And, especially now that Win, Lin, and Mac all run on the same processors, large parts of the .obj files should look the same already.

Having the end result runnable on all three OSs may be an unnecessary thing. But accepting that _targeting_ will be per os, then the .obj files could theoretically be the same for all of them. At the end of the day the .objs of an app get linked together, and with the OS-specific runtime library and startup code.

This would be neat -- if every processor was IA. But since we want to write D for other processors (and hopefully for embedded processors too), the one-obj-for-all-archs is wasted savings.

And of course, if the calling conventions are different, then it may present an obstacle. But then again, as long as all calls to non-D stuff go through the runtime library, then we're safe. Except for efficiency issues.

>>> I read Walter's remark, and it came to me like a shot from the blue.

Having 80=96 bit floats is handled in Linux -- after all, it's Linux itself that "wants" it. The math unit returns 80 bit entities, which are then stored in 96 bits. No problem.

For program portability, there are mainly two issues here:

 - internal representation
 - user defined data structures

The issues with the internal representation are fixed already (why else could one stay oblivious of the fact), in Linux.

Storing these floats in user defined data structures may be another thing. Ideally this could be solved with a convention (or standard), where they are stored as 80 bit or 96 bit, whatever is commonly agreed upon. (For example, D for Windows could decide simply to store 80 bit floats as 96 bits, period.) Code for calling system calls or libraries could take care of the alignment.

>>>> Now, he's quite knowledgeable, but I'd love to prove him wrong on this one. I find it hard to believe that it would be impossible. I guess the question is, will the subset of functionality that works be sufficient to be useful? I guess we
>>>>  won't know until the ELF side is working.
>>>> 
>>>> "Compile once, run everywhere that matters"? (Win, Linux, Intel
>>>>  Mac).

Truly multi-OS applications would be cool, of course. But then again, wouldn't software vendors like to sell two boxes instead of one? "You want to run this on both x and y, right!" Besides, there's all the GUI related differences too. If the binaries would be multi-OS by default, then the programmer should have to (at least) have a general idea of what not to do.

>>> Pipe dream or not, I think its worth looking into.  And you're right: the portable subset of features may be just barely usable.
>>> Until we get some people really pounding away on this, we'll never quite know.

I think it's doable. But as to if it is worth the effort, I'd need some persuasion.

If not else, the resulting app could by default become a small (OS-dependent) "loader" plus the binary. So you'd always get 4 files: the three (mac, lin, win) loaders, and the "real program".

>> For what it's worth, there was a thread on comp.std.c++ recently about a standard shared library format, and someone said that library formats have recently become sufficiently similar that this
>> is a possibility.
> 
> Ahh, thanks for the info Sean (and for reminding me what a godsend *this* particular NG is).  Its funny looking at the posts that go back a year or two to see folks lobbying around a "Module format" or "module include" (read: import) operator.  Overall, I think we're on the right track with D and DDL.  If any ABI for cross-platform binaries/libraries/modules is going to come about, it'll likely come up later out of necessity - so far I've been *anticipating* need rather than satisfying it.
> 
> On an unrelated note, I also stumbled into Bjarne's proposal on XTI which is just flat-out scary:
> 
> http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

XTI, Extended Type Information (possibly classes or trees)
XPR, External Program Representation (Human + computer readable)

Incidentally, XPR looks Pascal like, to me.

An idea I got the other year was, to have the IDE not use program source code at all. "Source" files would be binary representations of the source code (probably as trees), and the only place where "conventional source code" would exist, is only on the screen of the program editor.

(Yes, I do know this has been implemented (to various extents) already elsewhere since way back, no problem. But now I'm thinking D.)

As an aside, this would let one have comments, drawings and such stuff directly "in the source code". It would also enable faster compilation, since tokenizing, parsing and semantics would already be done. (And of course, there'd be an Export to "normal source code", for long term backups and such.)

Since any modern editor needs all kinds of intellisense, bells and whistles, keeping the code in an IPR (internal program representation) would make this much easier. If a standard file format existed, then every programmer could have his own program layout (meaning curly brace placement, indentation, comment style and formatting, etc.) on his screen, even if he collaborates with others.

Processing of binary source would be very easy compared with textual source, as even Bjarne points out in the pdf. One could do all kinds of automatic processing, testing and measurement, and automatic derivation and analysis, or convenient automated refactoring. And conversion of source code to/from XML would be trivial.

Search and replace and such would then be more intelligent! You could globally replace a word in one sense and not in others.

D can already exist in HTML, enabling in-source pictures and a rich "source experience", theoretically with sound and videos embedded in the source code. (The usefulness of these remains to be seen.) One big problem witht this is debugging and editing, they become more work for the programmer, so currently the HTML-D format mainly suits education.

Georg Wrede wrote:
> Walter Bright wrote:
>> These are a lot of very interesting observations that never occurred
>> to me.
>>
>> Are you teaching D as a first language, or just thinking about it?
> 
> In 2000 I was _dragged_ out of the university, to do Java development. When I left, I told everyone on the department that I'll be back unless I get rich quick. Now I'm [more than] toying with the idea that I'll go back to teaching, and get my Ph.D. on the side.
> 
> Additionally I am collecting material and doing research on "Introduction to Programming, Using D". Vol 1 would be a general introduction to stuff that every first year CS student should know, and Vol 2 would contain advanced stuff for the second and third year.
> 
> (I'm still catching my breath after the divorce, but it's downright likely that's where I'll be once I get half a grip.)

My university teaches Scheme as the first language, modeled after the MIT curricula, where the course is based on SICP (the purple book). Seems a good idea to me, as Scheme is much more simple than Java and D, and so the teaching can focus on the general programming concepts.

Frankly I really don't see D as much better/simpler than Java for the purposes of a first language.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Matthias Spycher wrote:
> Dave wrote:
> 
>>> 2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization.
>>>
>>
>> If you're talking about the famous "pointer alias problem" then Java is
>> certainly not immune to that (maybe even less so because of all of the
>> references floating around).
>>
> 
> True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
> 
> [snip]
> 
> Matthias

Garbage collection is absolutely not a requirement of scaling to support large, long-running applications.  Take a look at Apache and Subversion for their use of memory pools (both use the APR).

However, If your point was to show 'accurate' garbage collection as a requirement over 'conservative' collection, then yes I agree. :)

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Unknown W. Brackets wrote:
> Well, what you can do is wait for the game to get old, and then release the source.  You won't lose much doing that, but others will gain from the source and that will feed back to you.

Ah yes, that would be best most likely.

> Hopefully my comments are of some help to you :).

Yes, thanks.

Hasan Aljudy wrote:
> Do you know what Valve did with their games? (Half-Life/Half-Life2)
> 
> They released the source to the game engine (*not* the graphics engine, only the game logic, which by the way, is huge), and allowed hobyists to modify it and distribute their modifications (aka Mods). That's how Counter-Strike was born.

Ah yes. I knew about the Half-Life mod stuff, but never actually used it myself. But I believe it is similar to Tribes, now the Torque engine made by GarageGames which I've used a little. It's basically an engine done in C/C++ with many of the functions available through a scripting language. The biggest problem with those engines though is that they are very geared towards FPS games/style. But yes, that could be another way to do it.

Bruno Medeiros wrote:

> My university teaches Scheme as the first language, modeled after the MIT curricula, where the course is based on SICP (the purple book). Seems a good idea to me, as Scheme is much more simple than Java and D, and so the teaching can focus on the general programming concepts.

I went through a class using SICP. The teacher was as new to the stuff as we were. At the time, the local bookstores refused to carry the book just for us, and the WWW or Amazon didn't exist. (Later he got fired for this, since SICP+Scheme is just a bit too steep to teach off-hand. (That is, without a profound knowledge of it yourself.) At the end of the year, nobody actually got credits!) It was tough, but this was so long ago that one had to lie, cheat and steal to even get the interpreter. Not all did. (And yes, I do know that of all languages, Lisp is the one that can actually be taught without access to computers. But as students, at the time, we didn't understand this!)

Anyhow, I still consider this as one of the most eye-opening CS classes I've ever taken. And it has made a life long difference in how I program, how I think about programming, and how I evaluate programming languages and paradigms.

> Frankly I really don't see D as much better/simpler than Java for the purposes of a first language.

This might sound offending, condescending, patronising and whatever, but:

Learning to program (in school/university, vs. on your own) does contain issues one never notices. The choice of language, the "scene" at the time, the predicted future of the students (and of course what they never tell you: access to knowledgeable teachers in the various choices), all do play a role. The faculty (hopefully) makes a choice genuinely based _only_ on their combined experience which (in the best case) might today be like n * 30 years, n being the number of professors participating in the decision.

There is no way for the individual student to match this combined knowledge, and its implicit implications. Still, if the faculty is not able to explain the decision adequately, students may feel that "it's a dumb choice". But then again, that's _exactly_ why universities do exist. They're there to tell you what to learn. Anybody who "thinks he knows better" might be better off studying on their own. (Like, if you really _do_ know better, then do it, honestly(!), but if you only _believe_ you know better, then your future isn't all that rosy.)

The absolute top universities are in a position to not have to explain their choices. (What they do, actually _defines_ what is best! But then, this is a burden and a responsibility such universities usually can carry!)

---

A SICP course _as_a_first_language_, I'd teach (maybe) to students of Philosoply, Law, or theoretical Physics. But never to CS students.

I admit this is a personal opinion, and I don't expect the world to agree. (Wouldn't be the first time.) After three of four languages, then I think CS students _would_ get orders of magnitude more Real Hard Core mental tools to think with.

((

Think about it: anybody using Emacs and not being fluent in Lisp, is a joke. The key bindings suck hard, and a mental model of the workings and True Interface of Emacs just never become clear to you unless you're fluent enough to from the hip do short Lisp programs for one-shot needs while writing a source file.

The only thing left are (First) being able to tell everybody you're a Real Programmer (and, way later as Second) possibly using some of the innumerable "modes" and "emacs extensions" that are readily available.

))

---

Back to Philosoply, Law, or theoretical Physics, these folks need some rigor to their thinking. Early on. And such rigor is very hard to teach without a tool that only accepts correct thinking and punishes you for anything vague. (Rigor being just another tool in their chest, by no means the master.)

(( I'm actually not expecting anyone here to agree, or even understand, since I haven't made much effort of a sufficient explanation. My bad, I confess. I'm not even sure I bother to argue if somebody starts shooting this down. This really is not a venue for that discussion. ))

Georg Wrede wrote:
> Walter Bright wrote:
> 
>> If, for example, one had a comprehensive compiler test suite for
>> various platforms, and one prevented calling any that didn't pass it
>> a "D compiler", one could do just as well.
> 
> This might not be a bad idea for D.

Ever heard of dstress? ;-)

Georg Wrede wrote:
> Bruno Medeiros wrote:
> 
>> Frankly I really don't see D as much better/simpler than Java for the purposes of a first language.
> 
> This might sound offending, condescending, patronising and whatever, but:
> 
> Learning to program (in school/university, vs. on your own) does contain issues one never notices. The choice of language, the "scene" at the time, the predicted future of the students (and of course what they never tell you: access to knowledgeable teachers in the various choices), all do play a role. The faculty (hopefully) makes a choice genuinely based _only_ on their combined experience which (in the best case) might today be like n * 30 years, n being the number of professors participating in the decision.

Oddly, this topic came up at SDWest as well--someone asked Bjarne how he felt about universities switching from C++ to Java as a teaching language.  He said that this change often coincided with a general "watering down" of the curriculum (to something more suitable for a BA program, I assume), but that aside... he said that recently there's been a push from the industry to re-instate C++ as a teaching language because it's used far more broadly than Java and companies wanted graduates to have experience in the language they were likely to use professionally.  Apparently, Texas A&M just switched from Java back to C++, though there's no saying whether this has anything to do with Bjarne teaching there.

> Back to Philosoply, Law, or theoretical Physics, these folks need some rigor to their thinking. Early on. And such rigor is very hard to teach without a tool that only accepts correct thinking and punishes you for anything vague. (Rigor being just another tool in their chest, by no means the master.)

I like that you group Philosophy in with Theoretical Physics.  Most people seem to think Philosophers are all either goofballs with their heads in the clouds or clueless name-droppers.


Sean

Georg Wrede wrote:
> (Walter,) anytime somebody doubts D as a superior Academic Language, have them talk with me.
> 
> Another thing, if we can get D popular in the academia, both research and teaching will gain a lot. And as an aside, 5 years after that, who'll ever want to do programming in any other language???

Don't you think some high-level language of declarative nature such as Scheme, Haskell, Ruby or Python (or even Boo, O'Caml or Scala for that matter) would serve better as a first language?

Scheme and Haskell really concentrate on expressing computational problems in their own domain, hence reputed as "executable specification".

Even though D is very nice it really can't compete in "high-levelness" with the aforementioned languages. I personally see D more as a professional's tool for building real-life software as academic research language.

As a side note, unfortunately none of the academic research languages are used widely for building real-life software, although they are *designed* to allow easy expression of computational ideas, i.e. to be easy to use. I for one would be extremely happy of getting a chance of using something like Haskell at work. Come to think of it, I would be extremely happy to use D.

For some reason IT industry is both extremely sadistic and masochistic by insisting it's workers to use the worst languages available (C++) for all work (especially if the language doesn't suit the problem domain at all), constantly doing huge layoffs, offshoring and delivering products so bad and faulty that any traditional industry would be out of business  on the first day.

-- 
Niko Korhonen
SW Developer