On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote: [...]
> I have spent a huge time in the university learning about compiler development, reading old books and papers from the early computing days.
> 
> So in a general way, and not directed to you now, I saddens me that a great part of that knowledge is lost to most youth nowadays.
> 
> Developers get amazed with JavaScript JIT compilation, and yet it already existed in Smalltalk systems.
> 
> Go advertises fast compilation speeds, and they were already available to some language systems in the late 70's, early 80's.
> 
> We are discussing storing module interfaces directly in the library files, and most seem to never heard of it.
> 
> And the list goes on.
> 
> Sometimes I wonder what do students learn in modern CS courses.
[...]

Way too much theory and almost no practical applications. At least, that was my experience when I was in college. It gets worse the more prestigious the college is, apparently.

I'm glad I spent much of my free time working on my own projects, and doing _real_ coding, like actually use C/C++ outside of the trivial assignments they hand out in class. About 90% of what I do at my job is what I learned during those free-time projects. Only 10% or maybe even less is what I got from CS courses.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley <wiley.andrew.j@gmail.com> wrote:

> On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
> <schveiguy@yahoo.com>wrote:
>
>>
>> I agree that's the case with the current object/linker model.  Something
>> that puts inferred properties into the object file needs a new model, one
>> which does not blindly link code that wasn't compiled from the same sources.
>>
>
> Then all you've done is to make attributes the author can't control part of
> the API, which will force library users to recompile their code more often
> for non-obvious reasons. Avoiding that is one of the points of shared
> libraries.

Shared library entry points have to have *no* inference.  Otherwise you could inadvertently change the public API without explicitly tagging it.

I believe in D, shared library entry points have to be tagged with export.

Not to mention, shared libraries on a certain platform usually have to be linked by the platform's linker.  So we can't exactly overtake that aspect with a new model.

>
> I think we're actually talking about different contexts. I'm speaking in
> the context of shared libraries, where I think the API needs to be exactly
> what the author requests and nothing more. With object files, static
> libraries, and static linking, I agree that this sort of thing could work
> and wouldn't cause the same problems because it's impossible to swap the
> library code without recompiling/relinking the entire program.

OK, that makes sense, I think you are right, we were talking about two different pieces of the model.

-Steve

On 2012-05-07 20:13, H. S. Teoh wrote:
> On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote:

>> Sometimes I wonder what do students learn in modern CS courses.
> [...]
>
> Way too much theory and almost no practical applications. At least, that
> was my experience when I was in college. It gets worse the more
> prestigious the college is, apparently.
>
> I'm glad I spent much of my free time working on my own projects, and
> doing _real_ coding, like actually use C/C++ outside of the trivial
> assignments they hand out in class. About 90% of what I do at my job is
> what I learned during those free-time projects. Only 10% or maybe even
> less is what I got from CS courses.

So true, so true. I feel exactly the same.

-- 
/Jacob Carlborg

On 2012-05-07 17:41, Pierre LeMoine wrote:
> On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
>> If you are interested in getting results rather than reinventing the
>> wheel,
>> I would advice you to have a look at the openwatcom.org wlink, and the
>> forked jwlink as a starting point. The linker is open source, written in
>> C and has user documentation (not source doc unfortunately).
>>
>> Roald
>
> Thanks for the tip! :)
> What level of reinventing the wheel are we talking about? Did you
> suggest i fork (j)wlink or somesuch, or that i take a look at how it's
> implemented instead of reinventing from scratch? :)
> And does anyone know if wlink is able to link programs from dmd? I made
> a half-hearted attempt myself, but didn't manage to get it to work ;p
>
> /Pierre

Perhaps you could have a look at "gold" as well:

http://en.wikipedia.org/wiki/Gold_%28linker%29

-- 
/Jacob Carlborg

Hi,

it seems I have to excuse myself. I could not find anything
from Adele Goldberg.

So my statement is false. Most likely I ended up confusing
Fran Allen's interview in Coders at Work, with some nonsense
in my head.

Still, I leave here a few links I manage to find from Fran Allen.

Some remarks about bad languages on the page 27
http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf

Complaint about C on slide 23
http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf

Another remark about C
http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml

A video recorded at Purdue University, she also talks about C on minute 51
http://www.youtube.com/watch?v=Si3ZW3nI6oA

--
Paulo

Am 07.05.2012 10:41, schrieb Jens Mueller:
> Paulo Pinto wrote:
>> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
>>> Paulo Pinto wrote:
>>>> AST/symbol table manipulation is way faster than reparsing code.
>>>>
>>>> People keep talking about D and Go compilation speed, while I
>>>> was already
>>>> enjoying such compile times back in 1990 with Turbo Pascal in
>>>> computers much
>>>> less powerfull than my laptop.
>>>>
>>>> But C and C++ with their 70's compiler technology, somehow won
>>>> the
>>>> market share,
>>>> and then people started complaining about compilation speeds.
>>>>
>>>> Adele Golberg, once wrote a paper telling how C made the
>>>> compiler technology
>>>> regress several decades.
>>>
>>> Do you happen to remember to exact title of that paper?
>>> Thanks.
>>>
>>> Jens
>>
>> I'll try to find it, as I don't recall the title.
>>
>> I just remember that it made some remarks how primitive C was in
>> regard
>> to Algol toolchains.
>
> Many thanks.
> I couldn't find it myself and I'm interested because Fran Allen said
> something similar in Coders at Work.
> I didn't understand what she meant. Andrei suggested that it is mostly
> (only?) about overlapping pointers to memory. I'm just curious.
>
> Jens

Am 07.05.2012 15:27, schrieb Paulo Pinto:
> I like the idea, need to check what information I could provide.
>
> Wirth's books about Oberon also provide similar information.
>
> --
> Paulo
>
> "dennis luehring" wrote in message news:jo85t1$1n9b$1@digitalmars.com...
>
> Am 07.05.2012 07:53, schrieb Paulo Pinto:
>> I really really think that mankind did a wrong turn when C won over
>> Pascal
>> in the 80's.
>>
>> And that Wirth somehow lost interest in the industry and did not try
>> to push
>> Modula-* or Oberon. There are some papers where he states this.
>>
>> Now we suffer from
>>
>> - daggling pointers
>> - buffer overflows
>> - pre-historic compiler toolchains
>>
>> With luck, Spec#, Go or more nicely D, will put us back on track.
>
> we should collect all the advantages of turbo pascal/delphi
> object-file-formats and make a small description post to show others in
> a clear understandable way how good/and longlife these technics are
>
> so the unit-system (turbo pascal: .pas -> .tpu, delphi: .pas->.dcu, free
> pascal: .pas -> ppu), the tpumover, ppumover for tpl or ppl libraries,
> the dll delphi solution .bpl
>
> and the advantage of controling the output of source inside the source
> program -> exe, unit -> object, library -> dynamic libray etc.
>
> any ideas how to start?

Description of the Free Pascal unit format

http://www.freepascal.org/docs-html/prog/progap1.html#progse67.html

How the dump command works
http://www.freepascal.org/tools/ppudump.htm

The source code of the ppudump utility
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/utils/ppudump.pp?view=markup

--
Paulo

Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?

On 5/8/2012 3:34 AM, Paulo Pinto wrote:
> Hi,
> 
> it seems I have to excuse myself. I could not find anything from Adele Goldberg.
> 
> So my statement is false. Most likely I ended up confusing Fran Allen's interview in Coders at Work, with some nonsense in my head.
> 
> Still, I leave here a few links I manage to find from Fran Allen.
> 
> Some remarks about bad languages on the page 27 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
> 
> Complaint about C on slide 23 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
> 
> Another remark about C http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml
> 
> 
> A video recorded at Purdue University, she also talks about C on minute 51 http://www.youtube.com/watch?v=Si3ZW3nI6oA
> 
> -- 
> Paulo
> 
> Am 07.05.2012 10:41, schrieb Jens Mueller:
>> Paulo Pinto wrote:
>>> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
>>>> Paulo Pinto wrote:
>>>>> AST/symbol table manipulation is way faster than reparsing code.
>>>>>
>>>>> People keep talking about D and Go compilation speed, while I
>>>>> was already
>>>>> enjoying such compile times back in 1990 with Turbo Pascal in
>>>>> computers much
>>>>> less powerfull than my laptop.
>>>>>
>>>>> But C and C++ with their 70's compiler technology, somehow won
>>>>> the
>>>>> market share,
>>>>> and then people started complaining about compilation speeds.
>>>>>
>>>>> Adele Golberg, once wrote a paper telling how C made the
>>>>> compiler technology
>>>>> regress several decades.
>>>>
>>>> Do you happen to remember to exact title of that paper? Thanks.
>>>>
>>>> Jens
>>>
>>> I'll try to find it, as I don't recall the title.
>>>
>>> I just remember that it made some remarks how primitive C was in
>>> regard
>>> to Algol toolchains.
>>
>> Many thanks.
>> I couldn't find it myself and I'm interested because Fran Allen said
>> something similar in Coders at Work.
>> I didn't understand what she meant. Andrei suggested that it is mostly
>> (only?) about overlapping pointers to memory. I'm just curious.
>>
>> Jens
> 

Oops, copy/paste error. :(

I'll check it, when I get back home.

--
Paulo

"Andre Tampubolon"  wrote in message news:joa0lq$1t2k$1@digitalmars.com...

Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?

On 5/8/2012 3:34 AM, Paulo Pinto wrote:
> Hi,
>
> it seems I have to excuse myself. I could not find anything
> from Adele Goldberg.
>
> So my statement is false. Most likely I ended up confusing
> Fran Allen's interview in Coders at Work, with some nonsense
> in my head.
>
> Still, I leave here a few links I manage to find from Fran Allen.
>
> Some remarks about bad languages on the page 27
> http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
>
> Complaint about C on slide 23
> http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
>
> Another remark about C
> http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml
>
>
> A video recorded at Purdue University, she also talks about C on minute 51
> http://www.youtube.com/watch?v=Si3ZW3nI6oA
>
> -- 
> Paulo
>
> Am 07.05.2012 10:41, schrieb Jens Mueller:
>> Paulo Pinto wrote:
>>> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
>>>> Paulo Pinto wrote:
>>>>> AST/symbol table manipulation is way faster than reparsing code.
>>>>>
>>>>> People keep talking about D and Go compilation speed, while I
>>>>> was already
>>>>> enjoying such compile times back in 1990 with Turbo Pascal in
>>>>> computers much
>>>>> less powerfull than my laptop.
>>>>>
>>>>> But C and C++ with their 70's compiler technology, somehow won
>>>>> the
>>>>> market share,
>>>>> and then people started complaining about compilation speeds.
>>>>>
>>>>> Adele Golberg, once wrote a paper telling how C made the
>>>>> compiler technology
>>>>> regress several decades.
>>>>
>>>> Do you happen to remember to exact title of that paper?
>>>> Thanks.
>>>>
>>>> Jens
>>>
>>> I'll try to find it, as I don't recall the title.
>>>
>>> I just remember that it made some remarks how primitive C was in
>>> regard
>>> to Algol toolchains.
>>
>> Many thanks.
>> I couldn't find it myself and I'm interested because Fran Allen said
>> something similar in Coders at Work.
>> I didn't understand what she meant. Andrei suggested that it is mostly
>> (only?) about overlapping pointers to memory. I'm just curious.
>>
>> Jens
> 

The correct link should have been
http://uhaweb.hartford.edu/ccscne/Allen.pdf

Am 08.05.2012 04:33, schrieb Andre Tampubolon:
> Interesting reading.
> I took a look at page 23, and didn't find the mention of C.
> Maybe I didn't read carefully?
>
> On 5/8/2012 3:34 AM, Paulo Pinto wrote:
>> Hi,
>>
>> it seems I have to excuse myself. I could not find anything
>> from Adele Goldberg.
>>
>> So my statement is false. Most likely I ended up confusing
>> Fran Allen's interview in Coders at Work, with some nonsense
>> in my head.
>>
>> Still, I leave here a few links I manage to find from Fran Allen.
>>
>> Some remarks about bad languages on the page 27
>> http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
>>
>> Complaint about C on slide 23
>> http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf
>>
>> Another remark about C
>> http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml
>>
>>
>> A video recorded at Purdue University, she also talks about C on minute 51
>> http://www.youtube.com/watch?v=Si3ZW3nI6oA
>>
>> --
>> Paulo
>>
>> Am 07.05.2012 10:41, schrieb Jens Mueller:
>>> Paulo Pinto wrote:
>>>> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
>>>>> Paulo Pinto wrote:
>>>>>> AST/symbol table manipulation is way faster than reparsing code.
>>>>>>
>>>>>> People keep talking about D and Go compilation speed, while I
>>>>>> was already
>>>>>> enjoying such compile times back in 1990 with Turbo Pascal in
>>>>>> computers much
>>>>>> less powerfull than my laptop.
>>>>>>
>>>>>> But C and C++ with their 70's compiler technology, somehow won
>>>>>> the
>>>>>> market share,
>>>>>> and then people started complaining about compilation speeds.
>>>>>>
>>>>>> Adele Golberg, once wrote a paper telling how C made the
>>>>>> compiler technology
>>>>>> regress several decades.
>>>>>
>>>>> Do you happen to remember to exact title of that paper?
>>>>> Thanks.
>>>>>
>>>>> Jens
>>>>
>>>> I'll try to find it, as I don't recall the title.
>>>>
>>>> I just remember that it made some remarks how primitive C was in
>>>> regard
>>>> to Algol toolchains.
>>>
>>> Many thanks.
>>> I couldn't find it myself and I'm interested because Fran Allen said
>>> something similar in Coders at Work.
>>> I didn't understand what she meant. Andrei suggested that it is mostly
>>> (only?) about overlapping pointers to memory. I'm just curious.
>>>
>>> Jens
>>
>

Am 04.05.2012 01:47, schrieb Trass3r:
>> I'm interested in starting a project to make a linker besides optlink for dmd on windows.
> 
> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy OMF would be more beneficial than yet another linker.
> 
> 
>> My vision is to create a linker in a relatively modern language (D) and to release the project as open source.
> 
> If you do write a linker then make it cross-platform right from the start; and modular so it can support all object file formats.

Yes supporting COFF would be a great benefit on Windows and would allow the user to use other compilers and linkers in conjunction with D.

The other point: Writing a linker as part of GOSC 2013 will be an ease for you if you've implemented COFF since you don't need any furthur ramp-up time ;-).