Re: [OT] Re: Andrei's list of barriers to D adoption
On Saturday, 11 June 2016 at 12:19:52 UTC, Jonathan M Davis wrote: LOL. 10x that would be cheap in the US, and I don't think that your average school will let folks sit in on courses (though some will). For your average college in the US, I would only expect anyone to take classes if they're actually working towards a degree, though I'm sure that there are exceptions in some places. I remember that we sometimes had older programmers taking some courses, maybe to ge a degree? But not often. The $100/semester fee isn't for tuition though, it is for student activities/facilities, paper copies etc. Tuition is free. It works better when the school itself is really hard to get into. For instance, my dad went to MIT, and according to him, you usually don't have much of a need for weeder courses there, because it was already hard enough to get into the school that folks who can't hack it won't even be there - and it's an engineering school, so you're typically going to get very smart, well-prepared students who want to do engineering. It sorts itself out at higher levels, although I once had a project group at the master level that came to the hallway outside my office to get help, and it eventually dawned on me that none of the three boys knew that they should end sentences with ";"... I couldn't help laughing... and I kinda felt bad about it, but they laughed too, so I guess it was ok. I was so totally unprepared for that kind of problem at a master level course. I assume they came from some other field, as it was a web-oriented course. These things with uneven knowledge levels are more of a problem in "hip" project oriented courses, not so much in the courses that are proper compsci and are based on individual final exams. It kinda work out ok as long as students of the same level go on the same group, but it creates a lot of friction if you get a mixed group where the better students feel the other ones are freeloaders. You freqeuntly either end up with the school trying to weed out a lot of folks up front by having very hard beginning courses or making their beginning classes easy in an attempt to make it so that everyone has a chance, though I think that tends to just delay the inevitable for many students. Yep, exactly, but the problem was that the introduction course in programming was required by other fields such as getting a master in bio-chemistry or so. That didn't go very well when the lecturer once came up with a "clever exam" where you got stuck if you didn't master the first task. So 40% failed on their final exam, 200 angry students? That would've made me feel bad. After that they softened the tasks a bit... making failure harder. In the math department they had one more narrow calculus course for those who wanted to specialise in math and a broader more pragmatic calculus course for those who were more to use math as an applied tool in other fields. Probably a better solution. to be able to program. So, I agree that it would be nice if there were some sort of aptitude test up front that at least indicated whether you were likely have a very hard time with programming. But I don't think that I've ever heard of any schools doing anything like that (though obviously, some could be, and I just haven't heard of it). And I don't know how you would even go about making such a test, though I expect that there are computer science professors out there who would. Well, I don't know. I guess having average or above in math would work out. Not that you have to know math, but general problem solving. I noticed that people from other fields that was working on their master picked up programming faster, perhaps because they had acquired skills in structuring and problem solving. Then again, pure theoretical topics kill motivation for me. Like, I could never find any interest in solving tricky integrals analytically as it seemed like a pointless exercise. And to be honest, I've never found the need to do it. But as you said, some topics become more meaningful later in life and I'd probably put more energy into topics like program verification and combinatorics today than I did in my youth.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote: On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 1. this is heavily OT. ;-) I didn't forget to mark it! :-) 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d). I couldn't for the life of me find a link to this. sorry. Wyatt kindly fixed that for me. ;-) also, you can replace code generation in compiler with direct execution, and you will get AST-based interpreter. just create a new AA with local variables on NodeFCall (this will serve as "stack frame"), and make `compileExpr` return value instead of stack slot index. then it is as easy as: (NodeBinarySub n) => compileExpr(n.el)-compileExpr(n.er); and so on. also, fix `compileVarAccess` and `compileVarStore` to use your "stack frame" AA. this whole bussines is not hard at all. i'd say it is easier than many other programming tasks.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Saturday, June 11, 2016 08:06:21 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Friday, 10 June 2016 at 18:59:02 UTC, Jonathan M Davis wrote: > > then as it is later. In some ways, it would actually be very > > beneficial to actually go back to school to study that stuff > > after having programmed professionally for a while, but that's > > a pain to pull off time-wise, and the classes aren't really > > designed with that in mind anyway. > > I am definitively considering it, maybe on some topics that I've > read on my own, to fill in the missing bits. Or topics that has > had some advances since the 90s. It wouldn't be too much of a > pain as I could get there in 15 minutes on a bike, so it would > just be exercise. I believe lectures at the University of Oslo > are open to the public if there is enough space, and the fee at > the University of Oslo is at $100/semester so the threshold for > signing up is low. And I don't even have to do the exam, which > probably makes it more enjoyable. LOL. 10x that would be cheap in the US, and I don't think that your average school will let folks sit in on courses (though some will). For your average college in the US, I would only expect anyone to take classes if they're actually working towards a degree, though I'm sure that there are exceptions in some places. > > world. I don't envy teachers having to figure out how to teach > > basic programming concepts. > > Yes, some people are simply never going to be able to do > programming well... I'm talking having trouble reading code with > basic input - output loops (not even writing it) after having it > carefully explained to them many times. With some students you > know they will never be able to pass the exam after the first few > sessions. But you cannot tell them to quit... so you have to > encourage them, basically encouraging them to strive towards a > certain failure. That's frustrating. > > Educational institutions should probably have an aptitude test. > At the entry level courses maybe 30% are never going to be able > to become even mediocre programmers. It works better when the school itself is really hard to get into. For instance, my dad went to MIT, and according to him, you usually don't have much of a need for weeder courses there, because it was already hard enough to get into the school that folks who can't hack it won't even be there - and it's an engineering school, so you're typically going to get very smart, well-prepared students who want to do engineering. Contrast that with schools where almost anyone can get in, and there are always problems with folks entering engineering programs where they can't hack it - especially computer science, since it doesn't obviously involve the really hard math and science that would scare many of those folks away. You freqeuntly either end up with the school trying to weed out a lot of folks up front by having very hard beginning courses or making their beginning classes easy in an attempt to make it so that everyone has a chance, though I think that tends to just delay the inevitable for many students. I can appreciate wanting to give everyone a chance, and I'm sure that there are folks who have a hard time at first who get it later, but many folks just don't seem to think the right way to be able to program. So, I agree that it would be nice if there were some sort of aptitude test up front that at least indicated whether you were likely have a very hard time with programming. But I don't think that I've ever heard of any schools doing anything like that (though obviously, some could be, and I just haven't heard of it). And I don't know how you would even go about making such a test, though I expect that there are computer science professors out there who would. - Jonathan M Davis
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 18:59:02 UTC, Jonathan M Davis wrote: then as it is later. In some ways, it would actually be very beneficial to actually go back to school to study that stuff after having programmed professionally for a while, but that's a pain to pull off time-wise, and the classes aren't really designed with that in mind anyway. I am definitively considering it, maybe on some topics that I've read on my own, to fill in the missing bits. Or topics that has had some advances since the 90s. It wouldn't be too much of a pain as I could get there in 15 minutes on a bike, so it would just be exercise. I believe lectures at the University of Oslo are open to the public if there is enough space, and the fee at the University of Oslo is at $100/semester so the threshold for signing up is low. And I don't even have to do the exam, which probably makes it more enjoyable. When I started out in school, C++ was the main language, but it quickly changed to Java, which removes all kinds of certain problems, but it still has a lot of extra cruft (like forcing everything to be in a class and a ton of attributes forced to be on main), and it doesn't at all prepare students to properly deal with pointers and memory. So, students starting out with Java have some fun problems when they then have to deal with C or C++. Alternatively, there are folks in favor of starting with functional languages, which has certain advantages, but it's so different from how folks would program normally that I'm not sure that it's ultimately a good idea. I went to a high school that had programming/digital circuits on the curriculum. In the programming we started with Logo, which actually is kind of neat, as you are working with very concrete intuitive geometric problems. Then we went on to Turbo Pascal. It wasn't challenging enough, so the better students went with digital circuits and machine language for the last year. At the uni the entry level courses used Simula, but later courses used C, Beta, Scheme, etc, based on the topic. In several courses I could use whatever language I wanted for projects as long as the assistant teacher could read it. Made sense since the grades usually were based on a final exam only. world. I don't envy teachers having to figure out how to teach basic programming concepts. Yes, some people are simply never going to be able to do programming well... I'm talking having trouble reading code with basic input - output loops (not even writing it) after having it carefully explained to them many times. With some students you know they will never be able to pass the exam after the first few sessions. But you cannot tell them to quit... so you have to encourage them, basically encouraging them to strive towards a certain failure. That's frustrating. Educational institutions should probably have an aptitude test. At the entry level courses maybe 30% are never going to be able to become even mediocre programmers.
[OT] Re: Andrei's list of barriers to D adoption
On Friday, June 10, 2016 17:20:29 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Friday, 10 June 2016 at 15:27:03 UTC, Jonathan M Davis wrote: > > Most developers have titles like "Software Engineer" or "Senior > > Softweer Engineer." They'e frequently called programmers and/or > > software developers when not talking about titles. > > Neither academia or businesses use Computer Scientist as a job > title... tough? In academia, you'd be a professor of Computer Science or a professor in the Computer Science department. You wouldn't normally be called a Computer Scientist - certainly not as a job title. And in businesses, the only companies that even _might_ have Computer Scientist as a title would be where it was a very research-heavy job, which would not be at all normal. Research-heavy jobs like that do exist in some large companies, but in the vast majority of cases, programmers are hired as Software Engineers to write code for actual products. > > Yeah. Most universities in the US have a Computer Science > > degree, but some have Software Engineering as a separate > > degree. My college had Computer Science, Software Engineer, and > > Computer Engineering, which is atypical. All of them took > > practical courses, but the SE guys didn't have to take some of > > the more theoretical stuff and instead took additional classes > > focused on working on projects in teams and whatnot. > > Sounds like a good setup. At my uni we could pick freely what > courses we wanted each semester, but needed a certain combination > of fields and topics to get a specific degree. Like for entering > computer science you would need the most feared topic, Program > Verification taught by Ole-Johan Dahl (co-creator of Simula) who > was very formal on the blackboard... I felt it was useless at the > time, but there are some insights you have to be force-fed... > only to be appreciated later in life. It is useless, but still > insightful. > > Not sure if those more narrow programs are doing their students a > favour, as often times the hardest part is getting a good > intuition for the basics of a topic, while getting the "expert" > knowledge for a specific task is comparatively easier. Especially > now we have the web. So, being "forced" to learning the basics of > a wider field is useful. I tend to be of the opinion that the best colloge program has all of the more theoretical stuff, because it provides a solid base for real life programming, but project-based, real world stuff is also very important to help prepare students for actual jobs. Too many college programs do very little with helping prepare students for actual programming jobs, but at the same time, I think that skipping a lot of the theoretical stuff will harm students in the long run. But striking a good balance isn't exactly easy, and it's definitely the case that a lot of the more theoretical stuff isn't as obviously useful then as it is later. In some ways, it would actually be very beneficial to actually go back to school to study that stuff after having programmed professionally for a while, but that's a pain to pull off time-wise, and the classes aren't really designed with that in mind anyway. > I'm rather sceptical of choosing C++ as a language for instance. > Seems like you would end up wasting a lot of time on trivia and > end up students hating programming... Choosing the right language for teaching is an endless debate with all kinds of pros and cons. Part of the problem is that good languages for professional work tend to be complicated with advantages aimed at getting work done rather than teaching, which causes problems for teaching, but picking a language that skips a lot of the compilications means that students aren't necessarily well-prepared to deal with the more complicated aspects of a language. When I started out in school, C++ was the main language, but it quickly changed to Java, which removes all kinds of certain problems, but it still has a lot of extra cruft (like forcing everything to be in a class and a ton of attributes forced to be on main), and it doesn't at all prepare students to properly deal with pointers and memory. So, students starting out with Java have some fun problems when they then have to deal with C or C++. Alternatively, there are folks in favor of starting with functional languages, which has certain advantages, but it's so different from how folks would program normally that I'm not sure that it's ultimately a good idea. All around, it's a difficult problem, and I don't know wha the right choice is. In general, there are serious problems with teaching with real world languages, and teaching with a language that was designed for teaching doesn't necessarily prepare students for the real world. I don't envy teachers having to figure out how to teach basic programming concepts. Regardless, I think that students should be at least exposed to both the imperative/OO languages and the functional languages
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:59:15 UTC, Adam D. Ruppe wrote: What's the PrototypeObject sc I see everywhere doing? sc is short for "scope" - it refers to the chain of local variables. So consider the following: [snip] Cool. Thanks.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:36:02 UTC, jmh530 wrote:
Ah, it produces mixin("1+2") and evaluates that.
Sort of, 1 and 2 are both runtime variables there so it really
produces mixin("a+b") after setting a = 1 and b = 2 above.
But yeah, that's the idea - it just hoists that mixin to runtime
for scripting.
What's the PrototypeObject sc I see everywhere doing?
sc is short for "scope" - it refers to the chain of local
variables. So consider the following:
var a = 1;
function foo() {
var b = 4;
var c = a + b;
}
foo();
So as this is interpreted by my thing, it is like it runs the
following D code:
// this happens as part of the interpreter initialization
auto globalScope = new
PrototypeObject(globals_the_d_programmer_passed);
// now it starts running
auto currentScope = globalScope;
// var a = 1;
currentScope["a"] = 1; // it holds the local variables!
call_function("foo", []); // script foo();
// when we enter the new scope inside the function, it
// creates a new object, based on the old one
currentScope = new PrototypeObject(currentScope);
// var b = 4;
currentScope["b"] = 4; // remember the scope changed above, so
this is local to the function now
// var c = a + b;
currentScope["c"] = currentScope["a"] + currentScope["b"];
/*
OK, so at this point, we get two variables: a and b. That's
what the sc object in the script.d source represents - what
I called currentScope here.
The opIndex does two things: check the current scope for the
name. If it is there, return that value. If not, go up to
the parent scope and look there. Continue until you find it,
of if it isn't there, throw a "no such variable" exception.
It'd find b in the current scope and return the
function-local variable, and it'd find a in the parent scope.
*/
// and now that the function is over, we pop off the local
// variables from the function by setting the current back
// to the old parent
currentScope = currentScope.parent;
So yeah, the sc in the interpreter is just the currentScope from
the pseudocode, a chain of AAs holding the local variables.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 17:02:06 UTC, Adam D. Ruppe wrote:
https://github.com/adamdruppe/arsd/blob/master/script.d#L879
The function is pretty simple: interpret the left hand side
(here it is 1, so it yields int(1)), interpret the right hand
side (yields int(2)), combine them with the operator ("+") and
return the result.
Notice that interpreting the left hand side is a recursive call
to the interpret function - it can be arbitrarily complex, and
the recursion will go all the way down, then all the way back
up to get the value.
Ah, it produces mixin("1+2") and evaluates that.
What's the PrototypeObject sc I see everywhere doing?
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote:
Let's say you have something simple like 1+2, you would build
an AST that looks something like
+
/ \
1 2
What would be the next step?
https://github.com/adamdruppe/arsd/blob/master/script.d#L879
The function is pretty simple: interpret the left hand side (here
it is 1, so it yields int(1)), interpret the right hand side
(yields int(2)), combine them with the operator ("+") and return
the result.
Notice that interpreting the left hand side is a recursive call
to the interpret function - it can be arbitrarily complex, and
the recursion will go all the way down, then all the way back up
to get the value.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote: On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 1. this is heavily OT. ;-) I didn't forget to mark it! :-) Well, yeah, we should start a new thread, but compiler programming isn't really off topic at all on a forum where we talk about programming a compiler! Knowing the idea helps reading dmd source too.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:40:45 UTC, Wyatt wrote: He linked it earlier: http://repo.or.cz/gaemu.git/tree/HEAD:/gaem/parser -Wyatt Cheers.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote: On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d). I couldn't for the life of me find a link to this. He linked it earlier: http://repo.or.cz/gaemu.git/tree/HEAD:/gaem/parser -Wyatt
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote: 1. this is heavily OT. ;-) I didn't forget to mark it! :-) 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d). I couldn't for the life of me find a link to this.
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote: On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step? https://en.wikipedia.org/wiki/Tree_traversal#Post-order
Re: [OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote: On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step? 1. this is heavily OT. ;-) 2. you may take a look at my gml engine. it has clearly separated language parser and AST builder (gaem.parser), and AST->VM compiler (gaem.runner/compiler.d).
[OT] Re: Andrei's list of barriers to D adoption
On Friday, 10 June 2016 at 14:25:37 UTC, Adam D. Ruppe wrote: To make an interpreter, you can just add a method to the AST objects that interprets and gives a result boom, it works! Given my limited knowledge of compilers/interpreters, this part kind of seems like magic. Let's say you have something simple like 1+2, you would build an AST that looks something like + / \ 1 2 What would be the next step?
