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 over the course of school if they're going to be well-rounded programmers. So, a lot of the question is how to best teach the beginning concepts than what to use later later in the curriculum. To some extent, once you've got the basic stuff down, the language doesn't necessarily matter much.

I did think that it was funny though when in the networking course that I took, the teacher said that we were doing it in C, because if we did it in Java, then there wouldn't be much of a class. We basically implemented TCP on top of UDP as part of the course, whereas in Java, it would be a lot more likely to use RMI or the like and not even deal with sockets, let alone memory.

- Jonathan M Davis

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once and for all ...
> well ... just day dreaming ...

Started a new thread for that.

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.

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

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.

On Friday, 10 June 2016 at 15:29:01 UTC, Chris wrote:
> DScript. Your scripting language already fulfills things that were on my wishlist (easy D interop).

hey, both GML and DACS has some of that too! ;-)

VM["print"] = (string s) { writeln(s); };
VM["add"] = (int a, int b) => a+b;

wow, now we can print things from script, and (for some unknown reason) use function to add two numbers. with DACS you still have to declare function prototypes, but with GML it will "just work" (including conversion from internal nan-boxed doubles to strings and ints, and back).

GML is somewhat limited, but can be extended, and it almost as fast as Lua. DACS, with it's JIT, is sometimes even comparable to gcc -O2 (but only sometimes, lol; and LuaJIT still makes it look like a snail).

On Friday, 10 June 2016 at 17:09:18 UTC, Russel Winder wrote:

> Whatever you read, the writer didn't really know what they were talking about. At least not in general, and if they were talking of the Javaverse as a whole. Java 8 features such as lambda expressions, Streams, method references, etc. are no longer even controversial. There is a world-wide activity in transforming Java 6 and Java 7 code to Java 8. Yes some of this is pull rather than push, and I am sure there are islands of intransigence (*). However the bulk of Java programmers will eventually get and use the features.
>
> Of course many people have stopped using Java and use Kotlin, Ceylon, or Scala (**). The crucial point here is that the Javaverse is much, much more than just the Java language.

This only proves my point. This happens in languages that are "feature resistant". For years you have to write awkward code[1], and once a feature got accepted you have to revise your old code and jazz it up. And then of course you get conservative programmers who loath changes, they are a direct consequence of feature resistance. The more progressive ones turn to other languages like Clojure and Kotlin.

All this proves that being feature resistant is not healthy for a language.

[1] E.g. Java event listeners, Runnable etc.

> (*) Usually people who think Java 5 was a bad move and stick with Java
> 1.4.2.
>
> (**) There are others but these are the main players.

On Saturday, 11 June 2016 at 12:44:54 UTC, ketmar wrote:
> On Friday, 10 June 2016 at 15:29:01 UTC, Chris wrote:
>> DScript. Your scripting language already fulfills things that were on my wishlist (easy D interop).
>
> hey, both GML and DACS has some of that too! ;-)
>
> VM["print"] = (string s) { writeln(s); };
> VM["add"] = (int a, int b) => a+b;
>
> wow, now we can print things from script, and (for some unknown reason) use function to add two numbers. with DACS you still have to declare function prototypes, but with GML it will "just work" (including conversion from internal nan-boxed doubles to strings and ints, and back).
>
> GML is somewhat limited, but can be extended, and it almost as fast as Lua. DACS, with it's JIT, is sometimes even comparable to gcc -O2 (but only sometimes, lol; and LuaJIT still makes it look like a snail).

Cool. Maybe we should continue this here

http://forum.dlang.org/thread/njfdch$2627$1@digitalmars.com

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.

On Tuesday, 7 June 2016 at 20:41:21 UTC, Jonathan M Davis wrote:
> In principle, I think that you're very right that @safe needs to be implemented as a whitelist. Security in general does not work as a blacklist, and I think that @safe has the same problem. The problem is code breakage. Even assuming that the change in implementation were straightforward (and I have no idea whether it is or not), it would be pretty much guranteed that we would break a lot of code marked @safe if we were to switch to a whitelist. Some of that code is not truly @safe and really should be fixed, but just throwing the switch like that is too sudden. We'd probably be forced to have both a whitelist and a blaklist and treat the whitelist results as warnings temporarily before switching fully to the whitelist implementation. And that's likely feasible, but it seems like it would be a bit of a mess. So, I don't know if we reasonably can switch to a whitelist or not. But I think that it's clearly that we ideally would.

I think you meant "treat the non-whitelist results as warnings".

Seems to me the proper answer is simple.  Stuff on the whitelist
should pass without comment.  Stuff on neither the whitelist nor
the blacklist should generate warnings.  Stuff on the blacklist
should generate errors.  A compiler flag similar to gcc's -Werror
that turns all warnings into errors would allow the end-user to
select whether or not to worry, during a phase of transition.

This way, those warnings could be pushed back upstream to the
compiler maintainers as "hey, your whitelist/blacklist division
omits certain real-world cases".  And gradually, the graylist
would be narrowed over successive compiler releases.