Hacker News Reader

Comment by catfish17 | Hacker News Reader

>That said, C# solves this problem near perfectly.

Hadn't it already been solved in Java even better before? It doesn't look right to praise C# for resolving the problem when C# merely took that idea from Java. C# came up with the templates part though.

What C# didn't copy was the idea of turning every source file into a binary file. A library is just a zip archive of those .class binary files. What's the advantage for C# to not have .class files and to pack everything into a 'proprietary' library format? Why haven't they copied the zip-idea, too?

View on HN

Gentle reminder that architect of C# was snatched by Microsoft from Borland. Before that he was main guy at Borland for Pascal/Delphi. So I'm not so sure he simply copied from Java anything.

https://en.wikipedia.org/wiki/Anders_Hejlsberg

His first job at Microsoft was creating J++.

He was not snatched, he left Borland unhappy with its management and Microsoft was the obvious choice as next employer.

> Gentle reminder that architect of C# was snatched by Microsoft from Borland.

snatching wutt? They could have paid more to keep him.

Not a Microsoft fan either, but Borland managers have no right to complain :)

No duplication. There's a single file where every type reference or method reference exists once. Note that it's not a library file. The compiled dll or exe has no relationship to the original way it was stored in .cs file. Instead it's a set of tables which hold all types, all members.

Partial types.

The main reason is to have a library-scope name table and a bunch of global indexes. Can't beat that in terms of performance.

Worth noting that Java has this too now, it's called the "jimage" format. However it's not used for redistribution of compiled artifacts, that's still JARs. Instead a jimage file is created when JARs are "jlinked" into a runtime image.

This requires modules and it's a new technique that post-dates Java 8, so not many Java shops use it yet. However Java 9+ comes optimised this way by default, that's what the 'modules' file is in the JDK lib directory. Class files have their strings extracted and placed into a single string table are compressed, and their offsets then placed into a "perfect hash table" that's guaranteed to satisfy lookups in O(1) or O(2) time.

You can look back at least as far as Ada83 to find a specification for a library manager as part of the system, where precompiled modules are stored in a format that lends itself to faster compilation.

However the Ada library manager has a reputation for being complicated, slow, and fragile. Gnat was able to compile Ada much faster by using a C-style compilation model instead! https://dwheeler.com/essays/make-it-simple-dewar.html

Oh, definitely, but just because the implementation sucks doesn't mean that the idea isn't there.

Modula-3 was also pretty slow compiling, but it also compiled interfaces so that it could refer to them. Unfortunately, the underlying objects could change during a compilation because of partial revelation, so parts of the system would have to be recompiled when the builder found those cases. I'm sure Modula-2 could have been faster in that regard, not having the opportunity for a type to be elaborated more in later compilation units.

Reply on news.ycombinator.com