|
I would guess the 70s, yes.
In the early 1970s, programmers in general did not know how to write a compiler. First, the methods were poorly developed, nobody knew  Well, not quite that bad, but lots of "best practice in compiler writing" has come, and become well known, in much later years. Today, any college course in Systems Programming teaches you lots of the basic techniqes before you are out of scool; that certainly wasn't the case (or only to a microscopic degree) in the 1960s (and, I would say, far into the 1980s). When Wirth published the open source code Pascal compiler in 1971, it wasn't just to provide a pedagogical programming language; it was just as much to show how to make a recursive descent compiler.
Nowadays, you have got lots of compilers you can learn from, and lots of good tools. As was already pointed out: In the old days, compilers were essentially written in assembly code. They were usually closely tied to the machine architecture. Transferring knowledge to another architecture was difficult. There was a plethora of quite different languages: Even if you have written a C compiler, how does that help you in making an APL interpreter? A SNOBOL interpreter? A Lisp interpreter? Forth? Erlang? Even writing a Fortran IV parser poses a number of problems: No reserved words, even word tokens need not be separated by spaces, ...
Today, almost everything is a variant of C/C++, syntactically speaking. (Semantically as well, mostly.) So you know a whole lot of it already. Up until around 1980, developing a compiler often involved a lot of effort in defining the language itself. Besides, expectations to languages were a lot higher in the 1970s-1980s. C is a "you asked for it, you got it" language. Older versions had a frightingly high number of "implementation dependent" features. Compare that to e.g. the very rigorous specification of the CHILL lanugage (ITU's language for programming digital phone switches): As a language, it is an excellent design, very advanced (especially for its time - it appeared 1980), with a series of features that didn't appear in the C family until many years later, and then often incomplete, cumbersome and less elegant. I would guess that making a CHILL compiler, satisfying all formal requirements, could take ten times as much effort as making a C compiler.
|
|
|
|
|
I looked at the first kernel of NT 3.51, it weighed in at 90 MB. Current kernel weighs in at 20GB.
So I suspect that "Depends" really applies here. Are those 30 man-years for the first version someone did for "Fun", or the last version when it has gone all in on being community developed?
|
|
|
|
|
i think it is closer to the first version, given that i think the pronouncement comes from the early 70s iirc. I don't remember now where I read it, but it's old.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
public CodeTypeMember Member { get; set; }
public CodeStatement Statement { get; set; }
public CodeExpression Expression { get; set; }
public CodeTypeReference TypeRef { get; set; }
public HashSet<string> VariableNames { get; } = new HashSet<string>();
public HashSet<string> MemberNames { get; } = new HashSet<string>();
public HashSet<string> ArgumentNames { get; } = new HashSet<string>();
public HashSet<string> FieldNames { get; } = new HashSet<string>();
public HashSet<string> MethodNames { get; } = new HashSet<string>();
public HashSet<string> PropertyNames { get; } = new HashSet<string>();
public HashSet<string> EventNames { get; } = new HashSet<string>();
public HashSet<string> ThisTargets { get; } = new HashSet<string>();
public HashSet<string> BaseTargets { get; } = new HashSet<string>();
*sigh*
I really hope the GC doesn't hate me for all this. The class with this gets frequently instantiated all over the place.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You can't put some of those in a static class?
:: I'll be back to add more to this. ::
|
|
|
|
|
Heh. Nope. In fact, this object gets populated with different information every time it lands on an element of code
var cls = CD.Class("Foo", true);
var m = CD.Method("Bar", MemberAttributes.Public, CD.Param(typeof(string), "baz"));
var slang = SlangParser.ParseExpression("baz + \"world\"");
CodeStatement anchor1 = null;
m.Statements.Add(anchor1=(CD.Call(CD.TypeRef(typeof(Console)), "Writeline", slang)));
cls.Members.Add(m);
var ns = new CodeNamespace();
ns.Types.Add(cls);
var ccu = new CodeCompileUnit();
ccu.Namespaces.Add(ns);
var res = new CodeDomResolver();
res.CompileUnits.Add(ccu);
res.Refresh();
var scope = res.GetScope(anchor1);
That is operating on this object model of abstract code:
public class Foo {
public virtual void Bar(string baz) {
System.Console.Writeline((baz + "world"));
}
}
From here we get all of the information about what variables, fields, properties, methods, events, and arguments we have access to, returned from GetScope({statement})
I use this to perform analysis and patch up the code tree.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
cognitive meltdown warning: insert lithium control rods into cerebral cortex to avoid further impairment 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
If not all members are required to exist at all times, you may want to consider using Lazy<T>.
/ravi
|
|
|
|
|
Yeah, I've considered something akin to this approach. It's not the creation of them even that worries me so much but the population of them. I *can* do it on demand, for which Lazy here would be awesome, but I'm getting ahead of myself. As much as I know an operation like this is probably a pig, I want to wait to see before I implement demand population. I've stuck a pin in it mentally (and via some comments) but I want to see what the real world hit is going to be like. I have a low to middling PC to run it on, and plenty of test material to throw at it once it's ready.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Beauty! 
|
|
|
|
|
I hope so. It gets instantiated a lot. I use it during code dom visitation, on any "marked" expression I need to "patch"
Basically, I'm using the CodeDOM as my abstract syntax tree to hold the results of my parse.
But without type information applied to it the tree is ambiguous. That is,
foo.bar.baz()
Could be a delegate invocation of field baz, or a delegate invocation of property baz.
foo could be a variable, a method argument, a type (where bar is a static field), an instance field, etc.
So for you to even know what to compile from this parse, you need to apply type information from the tree.
The CodeDOM has different objects for reference fields, properties, methods and events, plus arguments and variables. So when I parse, i plug the tree with "dummies" - foo is always treated as a variable until it's patched. xxx(...) always refers to a delegate invocation until it's patched.
While I patch, I "visit" each object in the CodeDOM tree, and look for these dummies I inserted. When I find one, I "get scope" which returns one of the monsters the partial code for is above.
I then use that data to match it against the names of each of the dummies I inserted - to see what's a field and what's a method and what's a property, and what's a type, etc. I then use this information to fixup the tree with the appropriate objects, creating compilable code.
Not much different than what the C# compiler does internally.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
The latest in that category would be my CodeDomVisitor class, which does what it says - implements a visitor pattern over a CodeDom graph.
I thought about submitting a tip for it but then i figured, why bother? Who the hell would need something like this other than me? 
TBF, it's one of those things you never need until you do, and then it's a godsend.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Now you're sounding a bit van Goghie 
|
|
|
|
|
I didn't even know Vincent was a developer!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
In development circles, he was known for having kept his ear to the ground.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It was a pity he and his wife divorced - earreconcilable differences, I heard.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
did you really hear though?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Did you know he became a vampire in the end? Vincent Fang Gogh!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was going to take Herself to the Louvre, but we didn't have the Monet to get Degas to make the Van Gogh ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
And the record of most subsequent threads started in The Lounge in roughly an hour
|
|
|
|
|
Not my fault you aren't very chatty.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I've been in the biz for over 40 years, you have a ways to go before you eclipse my "code nobody uses" amount.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
*backs gingerly off of your lawn*
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
