Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/2013 4:10 AM, Paulo Pinto wrote: Except not everyone has the authorization to place their work code in such public places nor the availability or desire to code after work, just to please job interviewers. True, but your odds of being 'discovered' go up enormously if you make such an effort to make yourself findable with a professional online persona. It reminds me of some music superstars who started out singing at shopping malls, dive bars, weddings, anyplace they could get anyone to listen. They'd do this grind for a couple years until someone discovered them. The Beatles is one of those that comes to mind who did this. Anyhow, I recommend that anyone who wants to promote their 'brand' and increase their prospects do: 1. get a domain name that is "yourname.com" and put on it your resume, links to significant things you've done, etc. 2. use your own name as your handle when posting professionally 3. submit presentation proposals about your work to conferences 4. blog or otherwise write articles about your work or some neat tech thing you figured out 5. get a twitter account & github account in your own name - even if you don't use it, reserve it for when you do want to etc. Essentially, you want to own your online persona. Read any of Donald Trump's books on how he operates, it's the same thing. Gene Simmons is another one who excels at promoting himself.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu wrote: so what's the way to go now? One process per request? Seems heavy to me seeing as most requests last very little. Performance wise, I've found heard very good things about async i/o (like vibe.d) and had very good experience with a process pool (on linux anyway, cgi.d's fastcgi and new embedded_httpd_processes do this, the latter hitting 6,000 requests per second for hello world on my machine!). The process pool forks ahead of time, then they take connections as they become available. Basically it puts the concurrency in the kernel's hands, which does a good job. The zip I linked to yesterday does a simple one thread per connection, multiple requests per connection model. Doesn't scale very well, but works well and with simplicity on light loads.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Monday, 24 June 2013 at 09:22:58 UTC, deadalnix wrote: BTW, this article is full of bullshit and hand wavy stuff. I wanted to write a article destroying it, but I then decided that I had other thing to do than loose my time :D Yeah, it has plenty of bullshit but core idea is the same as one in project I have been engaged in and I can't write article about latter because of NDA, so using this an alternative available in the internet ;)
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Monday, 24 June 2013 at 09:07:54 UTC, Dicebot wrote: Actually, server software with most impressive performance I have seen so far was implemented as single barebone process with all network stack and event library embedded. Slightly similar idea was propsoed here - http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html (found via reddit) BTW, this article is full of bullshit and hand wavy stuff. I wanted to write a article destroying it, but I then decided that I had other thing to do than loose my time :D
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu wrote: On 6/23/13 11:51 AM, Adam D. Ruppe wrote: I think it is just an accident of history that mod_php ever got used. Classic cgi implementations were still slow enough (especially with an interpreted language) that people wanted to try something else, but the other world of options hadn't taken root yet either (I think mod_php even slightly predates fastcgi's introduction), and continues to exist just out of inertia. OK so what's the way to go now? One process per request? Seems heavy to me seeing as most requests last very little. Andrei One process/thread per CPU core + async I/O. FastCGI as simple alternative (it is similar to CGI but does not respawn process after processing request).
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 18:42:12 UTC, Adam D. Ruppe wrote: On Sunday, 23 June 2013 at 18:02:04 UTC, Dicebot wrote: I can see reasons for wanting to keep it behind reverse proxy like nginx, but Apache? Generally, I don't trust random http servers connected to the open internet for correctness, stability, security, and logging. Especially not my code, There's a lot of the http protocol I never implemented, and putting apache, nginx, IIS, whatever, I'm just using Apache here because Andrei mentioned it, out in front will filter some of that out before it gets to my app. Yes, that is why I have said that understand reasoning to use somthing like nginx or lighttpd - it is better to work behind something that has proper implementation of HTTP protocol and focus on application needs. I am using nginx for this on my own and perfectly satisfied with it. But using Apache is just throwing away most part of performance achived by your backend, for nothing. And creating security issues in case your app is run via Apache module is it typically runs from http user in such scenarios and using app-specific UNIX access policies becomes much harder.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 18:24:05 UTC, Andrei Alexandrescu wrote: On 6/23/13 11:04 AM, Dicebot wrote: On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote: On 6/23/13 10:34 AM, Adam D. Ruppe wrote: We should do what php does, it was very successful. I assume it's a dynamic library. And what reason behind this other than "millions of lemmings can't be wrong"? This approach is disaster when it comes to high load. Would separate processes work better under high load? Educate me. Andrei It is not about "process vs dynamic library", it is about basic threaded architecture used in Apache. Every single network server that I know that cares about performance uses some sort of event model and avoids any context switches at all possible costs. It does not matter where request processing code is, only how it fits in bigger picture. Actually, server software with most impressive performance I have seen so far was implemented as single barebone process with all network stack and event library embedded. Slightly similar idea was propsoed here - http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html (found via reddit)
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu wrote: On 6/23/13 11:51 AM, Adam D. Ruppe wrote: I think it is just an accident of history that mod_php ever got used. Classic cgi implementations were still slow enough (especially with an interpreted language) that people wanted to try something else, but the other world of options hadn't taken root yet either (I think mod_php even slightly predates fastcgi's introduction), and continues to exist just out of inertia. OK so what's the way to go now? One process per request? Seems heavy to me seeing as most requests last very little. That is what apache used to do when mod_php was introduced anyway. This whole conversation has gone out of control :D mod_php was a way to reduce the communication overhead and avoid 2 process per request in the first place (instead of one). It become plain obvious that no silver bullet exists here. The solution seems to be a mix of fibers/threads and processes where number of each depends on your workload and the actual hardware it is running on. Most high performance and high scalability system are converging toward one flavor of that pattern.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/23/13 11:51 AM, Adam D. Ruppe wrote: I think it is just an accident of history that mod_php ever got used. Classic cgi implementations were still slow enough (especially with an interpreted language) that people wanted to try something else, but the other world of options hadn't taken root yet either (I think mod_php even slightly predates fastcgi's introduction), and continues to exist just out of inertia. OK so what's the way to go now? One process per request? Seems heavy to me seeing as most requests last very little. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu
wrote:
Awesome!
I realized initializing the runtime might have been a mistake
when loading the .so and moreover I was using the wrong calling
convention. Fixed that and now the shared library thing works. On
Linux at least, I hardcoded ".so" so don't try it anywhere else.
Here's some code:
http://arsdnet.net/dcode/dhp.zip
unzip it, hit make. dhp2.d is the main file here, it also uses
some helper libraries you can see in the arsd folder.
Then run ./dhp2 in another window or something. It is a long
running process that serves http.
Head over to your browser and surf to
http://localhost:8085/
It will take a couple seconds to load the first time, because it
needs to compile the code. Subsequent loads will pull it from a
cache and be faster.
Anyway it will show you some stuff and a link. These pull from
the files in the zip called index.dhp and dhpt.dhp. index is just
html, no D code, although it will compile it since this server
compiles everything.
dhpt.dhp actually includes some D:
Hello, <% cgi.write(cgi.request("name", "user")); %>,
happy to see you.
Note: you access that by going to localhost:8085/dhpt, NOT
/dhpt.dhp. It strips out dots from the url as a way of sanitizing
the filename so keep it simple.
It uses ASP style <% %> tags instead of because my dom.d
already understands them. (BTW this parses the .dhp files to be
well-formed xml, so if you mismatch tags, it will throw. It might
be fun to put the DOM node in scope to inspect too).
There's a Cgi cgi in scope in the function it builds here. Use it
to do communication instead of writeln() etc., as seen in this
example.
Here's where the shared library magic comes in: feel free to edit
one of those .dhp files, or create your own, and go back to it in
the browser. It will recompile and present it to you without
having to restart the server. That's kinda cool. The downside is
if you segfault in here it will take the whole server down so
don't do that.
If you fail compiling though, it will actually read dmd's output
and translate the filename and line number to match the .dhp file
input, instead of the .d file dmd actually sees. So it feels less
like a filthy hack then.
Feel free to look at index.d and dhpt.d in that same folder after
you browse to them to see what the generated code looks like.
S yeah. I'll probably never use this, dom templates rok so
much more than anything asp/php style, but if you wanna play,
feel free and let me know if you want more features or see bugs.
Probably won't be too hard to fix up now that it is started.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
BTW I should mention, I wasn't actually trying to do an Apache module. I wanted to do a D server that watches the files for changes, then recompiles them as needed and reloads the resulting file as a shared lib. I could just run the compiled executable too, cgi style, but here I was more interested in playing with shared libraries than just getting it to work.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote: I assume it's a dynamic library. PHP can work as fastcgi too. But I kinda want to play with this now with shared libraries just for something to do so maybe I will. Awesome! Eh, not so much. I started playing and got a thing saying Runtime.loadLibrary is not yet implemented on posix... so went to do it myself and got random segfaults, relating to the garbage collector (and yes, I tried Runtime.initialize). I've never done a shared library plugin before so I could be doing something wrong, but it seems to me that druntime said it wasn't implemented yet for a reason, must still have some work to do there. Oh well, maybe I'll try again next release.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 18:24:05 UTC, Andrei Alexandrescu wrote: Would separate processes work better under high load? Educate me. One nice thing is you can spread separate processes across several machines. Another advantage of *cgi|embedded_httpd is that it is portable to other web servers too, you can just drop it into a shop that uses nginx or Microsoft IIS and expect it to work, whereas an Apache module is generally apache only. I think it is just an accident of history that mod_php ever got used. Classic cgi implementations were still slow enough (especially with an interpreted language) that people wanted to try something else, but the other world of options hadn't taken root yet either (I think mod_php even slightly predates fastcgi's introduction), and continues to exist just out of inertia.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 18:02:04 UTC, Dicebot wrote: I can see reasons for wanting to keep it behind reverse proxy like nginx, but Apache? Generally, I don't trust random http servers connected to the open internet for correctness, stability, security, and logging. Especially not my code, There's a lot of the http protocol I never implemented, and putting apache, nginx, IIS, whatever, I'm just using Apache here because Andrei mentioned it, out in front will filter some of that out before it gets to my app. And who knows what kinds of hidden bugs my code has, so having a tested and reliable server out there to revive my process if it dies is nice too.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/23/13 11:04 AM, Dicebot wrote: On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote: On 6/23/13 10:34 AM, Adam D. Ruppe wrote: We should do what php does, it was very successful. I assume it's a dynamic library. And what reason behind this other than "millions of lemmings can't be wrong"? This approach is disaster when it comes to high load. Would separate processes work better under high load? Educate me. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote: On 6/23/13 10:34 AM, Adam D. Ruppe wrote: We should do what php does, it was very successful. I assume it's a dynamic library. And what reason behind this other than "millions of lemmings can't be wrong"? This approach is disaster when it comes to high load.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 17:34:52 UTC, Adam D. Ruppe wrote: Would be awesome if an Apache extension would make it trivial to write Web pages in D. Just use cgi or fastcgi, both are really easy to configure on apache (often needing nothing more than copying your executable into /cgi-bin/, or adding three lines to ,htaccess), and being separate processes, if you crash them it is no big deal. No need to do set up a reverse proxy or get your system administrator to load strange new Apache modules. Or if you are just playing, you can skip apache altogether and use a D http server, like my cgi.d and vibe.d both offer (vibe.d's scales way better but mine is simpler). Actually vibe.d embedded HTTP outperforms Apache. With high concurrency - a lot. I can see reasons for wanting to keep it behind reverse proxy like nginx, but Apache? I dream of the day this freaking monstrosity dies together with web app infrastructure it has developed. Please, don't help it survive with D module support. :(
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/23/13 10:34 AM, Adam D. Ruppe wrote: Just use cgi or fastcgi, both are really easy to configure on apache (often needing nothing more than copying your executable into /cgi-bin/, or adding three lines to ,htaccess), and being separate processes, if you crash them it is no big deal. No need to do set up a reverse proxy or get your system administrator to load strange new Apache modules. We should do what php does, it was very successful. I assume it's a dynamic library. Or if you are just playing, you can skip apache altogether and use a D http server, like my cgi.d and vibe.d both offer (vibe.d's scales way better but mine is simpler). But I kinda want to play with this now with shared libraries just for something to do so maybe I will. Awesome! The more I think of it the more I get to the conclusion I should migrate my own website (www.erdani.com) to a 100% D toolchain. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 16:28:56 UTC, Andrei Alexandrescu
wrote:
foreach(ln; stdin.byLine(KeepTerminator.yes)) {
Yeah.
Would be awesome if an Apache extension would make it trivial
to write Web pages in D.
Just use cgi or fastcgi, both are really easy to configure on
apache (often needing nothing more than copying your executable
into /cgi-bin/, or adding three lines to ,htaccess), and being
separate processes, if you crash them it is no big deal. No need
to do set up a reverse proxy or get your system administrator to
load strange new Apache modules.
Or if you are just playing, you can skip apache altogether and
use a D http server, like my cgi.d and vibe.d both offer
(vibe.d's scales way better but mine is simpler).
But I kinda want to play with this now with shared libraries just
for something to do so maybe I will.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/23/13 9:21 AM, Adam D. Ruppe wrote:
http://arsdnet.net/dcode/dhp.d
It works by just reading the file and translating everything outside the
into a giant writeln(string literal), pasting in the D code, then
compile+running it, inserting a bunch of imports so it works.
dom.d now supports those kinds of tags, it could probably be even nicer,
especially with a D lexer so it doesn't think "?>" is the same as ?>.
But as I'm sure I said then, this is a bad idea anyway since mixing code
and html data leads to ugliness, whether the code is php or D.
Nice! (BTW:
foreach(ln; stdin.byLine) {
string line = ln.idup ~ "\n";
is simpler written as
foreach(ln; stdin.byLine(KeepTerminator.yes)) {
string line = ln.idup;
.)
Would be awesome if an Apache extension would make it trivial to write
Web pages in D.
Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Sunday, 23 June 2013 at 16:07:05 UTC, Andrei Alexandrescu wrote: Still buggy. The empty string must be a prefix of any string including the empty string. Huh. Well, that makes sense. Just change while to do while and you've got that. Probably compiles to exactly the same code as your implementation in the link at that point. But this probably told you more about my methods than getting it right the first time would have: I'll just slap something together that's good enough for the test case(s) fed to it and then change it if new stuff arises where it fails. One of the nice things about software is you generally don't have to get it right the first time since it is so easy to change. This is TDD-lite isn't it! lol http://www.serversidemagazine.com/news/10-questions-with-facebook-research-engineer-andrei-alexandrescu/. I definitely remember reading that when you posted it a while ago because I have code that does that ?> laying around. http://arsdnet.net/dcode/dhp.d It works by just reading the file and translating everything outside the into a giant writeln(string literal), pasting in the D code, then compile+running it, inserting a bunch of imports so it works. dom.d now supports those kinds of tags, it could probably be even nicer, especially with a D lexer so it doesn't think "?>" is the same as ?>. But as I'm sure I said then, this is a bad idea anyway since mixing code and html data leads to ugliness, whether the code is php or D.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/13 12:28 PM, Adam D. Ruppe wrote:
On Saturday, 22 June 2013 at 16:38:31 UTC, Andrei Alexandrescu wrote:
Huh, even the shortest impl I can think of is about the same length:
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle) {
assert(haystack !is null);
if(needle is null)
return haystack;
while(*haystack) {
auto h = haystack;
const(char)* n = needle;
while(*n == *h && *n && *h) {
h++;
n++;
}
if(*n == 0)
return haystack;
haystack++;
}
return null;
}
I like this a lot better because it is more straightforward.
Still buggy. The empty string must be a prefix of any string including
the empty string.
I describe the canonical implementation of substring brute for string
search as far as I see it
http://www.serversidemagazine.com/news/10-questions-with-facebook-research-engineer-andrei-alexandrescu/.
Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13 4:02 PM, Walter Bright wrote:
On 6/21/2013 3:35 PM, Andrei Alexandrescu wrote:
On 6/21/13 3:22 PM, Adam D. Ruppe wrote:
Just for laughs I just slapped together a strstr
Post it and I'll destroy it.
Can I play, too? Mine from the Digital Mars C library. Haven't looked at
it since 2001.
==
/*_ strstr.c */
/* Copyright (C) 1985-2001 by Digital Mars */
/* All Rights Reserved */
/* www.digitalmars.com */
/* Written by Walter Bright */
#include
#include
#include
#include
#include
#if 0 /* Smaller but slower under many circumstances. */
char *strstr(const char *s1,const char *s2)
{ size_t len2;
size_t len1;
char c2 = *s2;
len1 = strlen(s1);
len2 = strlen(s2);
if (!len2)
return (char *) s1;
while (len2 <= len1)
{
if (c2 == *s1)
if (memcmp(s2,s1,len2) == 0)
return (char *) s1;
s1++;
len1--;
}
return NULL;
}
#else
I won't comment on the B-M implementation. This brute force
implementation has the problem of calling strlen on both strings
upfront, which is arguably unnecessary. Although it doesn't affect
complexity, it is an inefficiency hard to recover from. (The tradeoff is
that memcmp will help with that.)
Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/2013 12:12 PM, Andrej Mitrovic wrote: Most important? I've never even run across this case. Ok, maybe not that important. It's likely a rare case. Btw, does anyone know if the typical memcmp implementation tries to compare the pointers' addresses first to see if they match? I don't know about typical, but I've never seen one that did.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Saturday, 22 June 2013 at 16:38:31 UTC, Andrei Alexandrescu
wrote:
It's still buggy.
What's the test case? I also forgot the empty string, blargh.
Let's scrap it.
Overly complicated, too - at 21 lines, it's about twice as
large as the canonical implementation.
Huh, even the shortest impl I can think of is about the same
length:
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
{
assert(haystack !is null);
if(needle is null)
return haystack;
while(*haystack) {
auto h = haystack;
const(char)* n = needle;
while(*n == *h && *n && *h) {
h++;
n++;
}
if(*n == 0)
return haystack;
haystack++;
}
return null;
}
I like this a lot better because it is more straightforward. My
first draft was trying to avoid looking at the same character
twice, but obviously that didn't work so fixing that ended up
doing the same thing as this anyway. I guess better to KISS than
be embarrassingly wrong, eh?
You could do it in about ten lines like this:
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
{
while(*haystack) {
auto h = haystack;
const(char)* n = needle;
while(*n == *h && *n && *h)
h++, n++; // LOL COMMA OPERATOR
if(*n == 0)
return haystack;
haystack++;
}
return null;
}
But I really like the null check. Yes, I know the hardware does
it, but it is a pain in the butt to fire up a debugger when a
null hits you in the middle of something. The nice assertion
failure message is so much faster to handle.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/13, Walter Bright wrote: > It's wrapped in #if 0 ... #endif ? :-) Hehe. I should totally use that as an argument in a future interview. I'll wrap all my coding-answers in '#if 0', and if they're wrong I'll just say "oh, but this code doesn't *actually* exist!". :p > The function bodies would be identical - why have two of them? Yeah nevermind, it's C, I was thinking about C++. Then again D would blow them both out the water since it has inout. > Most important? I've never even run across this case. Ok, maybe not that important. It's likely a rare case. Btw, does anyone know if the typical memcmp implementation tries to compare the pointers' addresses first to see if they match?
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote: Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). Paradoxically use of stdlib functions may actually hurt; I've seen people who e.g. call strlen() in a loop in order to implement strstr()! I think it's fair game whatever kind of work you are doing. The tests aren't so much about the algorithm, but showing that the candidate thinks about edge cases, interfaces, possible failure cases etc. These are things you need to think about even if your job is just to essentially glue libraries together. Simple tasks like strstr just provide a nice small task that test these things.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/2013 4:01 AM, Andrej Mitrovic wrote:
On 6/22/13, Walter Bright wrote:
Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
#if 0 /* Smaller but slower under many circumstances. */
char *strstr(const char *s1,const char *s2)
{ size_t len2;
size_t len1;
char c2 = *s2;
len1 = strlen(s1);
len2 = strlen(s2);
if (!len2)
return (char *) s1;
while (len2 <= len1)
{
if (c2 == *s1)
if (memcmp(s2,s1,len2) == 0)
return (char *) s1;
s1++;
len1--;
}
return NULL;
}
Some things i've noticed about this implementation:
It's wrapped in #if 0 ... #endif ? :-)
- c2 is assigned by pointer dereference, but then strlen is called on
s2 and you may get an early exit, meaning c2 was not needed at this
point. I'd move c2 below the strlen call.
Yup.
- The memcp doesn't have to compare len2 amount of chars if you've
already compared the first character, it can call memcmp(s2+1, s1+1,
len2-1). Although I'm not sure whether it's faster to do it this way
(maybe it is, if those variables are actually registers..).
Yup.
And notes about both implementations:
- You're casting a const char * to a char * in the return, you should
instead provide an overload of strstr taking char* and returning
char*.
The function bodies would be identical - why have two of them?
- You seem to have missed the most basic and most important check. You
didn't attempt to compare the memory address of both pointers against
each other before doing any other work. If they both point to the same
memory, the strings are guaranteed to be equal.
Most important? I've never even run across this case.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/13 7:10 AM, Adam D. Ruppe wrote: On Saturday, 22 June 2013 at 13:55:26 UTC, Jérôme M. Berger wrote: I haven't tried running it, but this looks to me like it won't find "ababc" in "abababc"... You're right. I should have went backwards all the way, not just in the one case. This passes all the tests: It's still buggy. Overly complicated, too - at 21 lines, it's about twice as large as the canonical implementation. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Saturday, 22 June 2013 at 13:55:26 UTC, Jérôme M. Berger wrote:
I haven't tried running it, but this looks to me like it won't
find "ababc" in "abababc"...
You're right. I should have went backwards all the way, not just
in the one case.
This passes all the tests:
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
{
assert(haystack !is null);
if(needle is null)
return haystack;
const(char)* where = needle;
inout(char)* gotit;
while(*haystack) {
if(*haystack == *where) {
if(gotit is null)
gotit = haystack;
where++;
if(*where == 0)
return gotit;
} else {
haystack -= where - needle;
where = needle;
gotit = null;
}
haystack++;
}
return null;
}
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
Adam D. Ruppe wrote:
> On Friday, 21 June 2013 at 22:35:55 UTC, Andrei Alexandrescu
> wrote:
>> Post it and I'll destroy it.
>
>
> inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
> {
> assert(haystack !is null);
>
> if(needle is null)
> return haystack;
>
> const(char)* where = needle;
> inout(char)* gotit;
>
> while(*haystack) {
> if(*haystack == *where) {
> if(gotit is null)
> gotit = haystack; // store where the match started
> where++;
> haystack++;
> if(*where == 0)
> return gotit;
> } else {
> // if we were in the middle of a match, we'll want to
> // check the current character again so only advance
> if
> // we're at the beginning
> if(gotit is null)
> haystack++;
> else {
> // partial match, but not complete so no good
> // start over, including the current *haystack
> where = needle;
> gotit = null;
> }
> }
> }
>
> return null;
> }
>
I haven't tried running it, but this looks to me like it won't find
"ababc" in "abababc"...
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/13, Adam D. Ruppe wrote: > On Saturday, 22 June 2013 at 11:01:53 UTC, Andrej Mitrovic wrote: >> - You're casting a const char * to a char * in the return, you >> should instead provide an overload of strstr taking char* and >> returning char*. > > I'm pretty sure the C standard says to do it with the const arg > but mutable return. > > http://en.cppreference.com/w/c/string/byte/strstr > Ah, I momentarily forgot C doesn't have overloading, which is probably where Walter's function was implemented in. In C++ there are overloads of this function: http://www.cplusplus.com/reference/cstring/strstr/
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/22/13, Walter Bright wrote:
> Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
>
> #if 0 /* Smaller but slower under many circumstances. */
> char *strstr(const char *s1,const char *s2)
> { size_t len2;
> size_t len1;
> char c2 = *s2;
>
> len1 = strlen(s1);
> len2 = strlen(s2);
> if (!len2)
> return (char *) s1;
> while (len2 <= len1)
> {
> if (c2 == *s1)
> if (memcmp(s2,s1,len2) == 0)
> return (char *) s1;
> s1++;
> len1--;
> }
> return NULL;
> }
Some things i've noticed about this implementation:
- c2 is assigned by pointer dereference, but then strlen is called on
s2 and you may get an early exit, meaning c2 was not needed at this
point. I'd move c2 below the strlen call.
- The memcp doesn't have to compare len2 amount of chars if you've
already compared the first character, it can call memcmp(s2+1, s1+1,
len2-1). Although I'm not sure whether it's faster to do it this way
(maybe it is, if those variables are actually registers..).
And notes about both implementations:
- You're casting a const char * to a char * in the return, you should
instead provide an overload of strstr taking char* and returning
char*.
- You seem to have missed the most basic and most important check. You
didn't attempt to compare the memory address of both pointers against
each other before doing any other work. If they both point to the same
memory, the strings are guaranteed to be equal.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-22 01:58, H. S. Teoh wrote: And where's the unittest block? ;-) (OK OK, I know this wasn't written in D. But I had to ask. :-P) DMC does support contracts, as an extension. That is, in and out contracts. I don't know about unit test blocks. -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-21 23:33, Andrei Alexandrescu wrote: If there's any need to reach for documentation, the interviewer has failed. When interviewing we (at Facebook) ask problems that are likely to appear in a normal day's work, but for which the typical libraries don't help. (E.g. many libraries don't can't help with implementing unstable remove (see std.algorithm).) Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). Paradoxically use of stdlib functions may actually hurt; I've seen people who e.g. call strlen() in a loop in order to implement strstr()! Yes, if they tell you that from the beginning. Instead they said: "solve it anyway you like", then they started to add restrictions. -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote: If there's any need to reach for documentation, the interviewer has failed. When interviewing we (at Facebook) ask problems that are likely to appear in a normal day's work, but for which the typical libraries don't help. (E.g. many libraries don't can't help with implementing unstable remove (see std.algorithm).) Amongst other thing, I did a merge sort and a quicksort in my FB interviews. It is fair to assume they can be found as libraries. But overall the process is really accurate to assert what a dev can do. Most question were technically challenging, but weren't tricks or overly complicated and useless. For the anecdote, my quicksort was buggy, but my interviewer convinced me it wasn't - when later check (after the interview) demonstrated is indeed was. Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). Paradoxically use of stdlib functions may actually hurt; I've seen people who e.g. call strlen() in a loop in order to implement strstr()! When i was doing interview, I used to ask people to program a function that sort an array of integer. No constraint of performance or anything, the good old 5 lines bubble sort would have been accepted. Most can't.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Fri, Jun 21, 2013 at 04:02:20PM -0700, Walter Bright wrote:
[...]
> /
> See "Algorithms" Second Edition by Robert Sedgewick. Boyer-Moore string
> search routine.
> /
> char *strstr(const char *text, const char * pattern)
> {
[...]
> }
Very nice!
Does it help at all to cast to uint[] and search that instead of just
char[]? Or do the complications caused by non-alignment outweigh the
benefits?
And where's the unittest block? ;-) (OK OK, I know this wasn't written
in D. But I had to ask. :-P)
Also, this is a prime example of code you'll *never* arrive at just by
blind application of TDD. (And there's my feeble attempt to bring this
back on topic. :-P)
T
--
This sentence is false.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 22:35:55 UTC, Andrei Alexandrescu
wrote:
Post it and I'll destroy it.
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
{
assert(haystack !is null);
if(needle is null)
return haystack;
const(char)* where = needle;
inout(char)* gotit;
while(*haystack) {
if(*haystack == *where) {
if(gotit is null)
gotit = haystack; // store where the match started
where++;
haystack++;
if(*where == 0)
return gotit;
} else {
// if we were in the middle of a match, we'll want to
// check the current character again so only advance
if
// we're at the beginning
if(gotit is null)
haystack++;
else {
// partial match, but not complete so no good
// start over, including the current *haystack
where = needle;
gotit = null;
}
}
}
return null;
}
unittest {
void test(string haystack, string needle, size_t line =
__LINE__) {
import core.stdc.string;
import std.conv;
// .ptr is fine because the test uses all string
literals, which are 0 terminated automatically
assert(strstr(haystack.ptr, needle.ptr) is
mystrstr(haystack.ptr, needle.ptr), to!string(line));
}
test("foobar", "f");
test("foobar", "ob");
test("foobar", "o");
test("foobar", "a");
test("foobar", "ar");
test("foobar", "ea");
test("bedtime bedazzled!", "beda");
}
I've heard of Boyer-Moore but don't actually know it, so I'd have
to look it up! The brute force loop is simple enough though
without needing a great deal of thought, though my first run
through did actually fail the unittest, since I neglected the
commented section in the else{} part. So if I was doing it on a
whiteboard, (or didn't immediately use "foo" as a test variable,
with the repeated o) I might not have actually caught that!
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/2013 3:35 PM, Andrei Alexandrescu wrote:
On 6/21/13 3:22 PM, Adam D. Ruppe wrote:
Just for laughs I just slapped together a strstr
Post it and I'll destroy it.
Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
since 2001.
==
/*_ strstr.c */
/* Copyright (C) 1985-2001 by Digital Mars */
/* All Rights Reserved */
/* www.digitalmars.com */
/* Written by Walter Bright */
#include
#include
#include
#include
#include
#if 0 /* Smaller but slower under many circumstances. */
char *strstr(const char *s1,const char *s2)
{ size_t len2;
size_t len1;
char c2 = *s2;
len1 = strlen(s1);
len2 = strlen(s2);
if (!len2)
return (char *) s1;
while (len2 <= len1)
{
if (c2 == *s1)
if (memcmp(s2,s1,len2) == 0)
return (char *) s1;
s1++;
len1--;
}
return NULL;
}
#else
#include /* defines UCHAR_MAX */
/
See "Algorithms" Second Edition by Robert Sedgewick. Boyer-Moore string
search routine.
/
char *strstr(const char *text, const char * pattern)
{
const size_t M = strlen(pattern);
const unsigned long N = strlen(text);
const char *p_p = pattern;
const char *t_p;
size_t skip[UCHAR_MAX + 1];
size_t i, j;
if(M == 0)
return (char *)text;
if(M > N) /* If pattern is longer than the text string. */
return 0;
#if __INTSIZE == 4
_memintset((int *)skip, M, UCHAR_MAX + 1);
#else
{ size_t *s_p = skip + UCHAR_MAX;
do
{
*s_p = M;
}while(s_p-- > skip);
}
#endif
p_p = pattern;
do
{
skip[*(const unsigned char *)p_p] = M - 1 - (p_p - pattern);
} while(*++p_p);
p_p = pattern + M - 1;
t_p = text + M - 1;
while(1)
{
char c;
c = *t_p;
if(c == *p_p)
{
if(p_p - pattern == 0)
return (char *)t_p;
t_p--; p_p--;
}
else
{
size_t step = M - (p_p - pattern);
if (step < skip[(unsigned char)c])
step = skip[(unsigned char)c];
/* If we have run out of text to search in. */
/* Need cast for case of large strings with 16 bit size_t... */
if((unsigned long)(t_p - text) + step >= N)
return 0;
t_p += step;
p_p = pattern + M - 1;
}
}
}
#endif /* #if 0 */
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13 3:22 PM, Adam D. Ruppe wrote: Just for laughs I just slapped together a strstr Post it and I'll destroy it. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13 2:50 PM, Adam D. Ruppe wrote: On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote: brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). But, should the return value be const or not? :P I think I'd write in D just cuz of inout(). That would be a nice touch and bring bonus points, but in most of the cases I tell the candidate to gloss over that detail. Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 22:23:01 UTC, Adam D. Ruppe wrote: being built in to D Or maybe it is because everybody else does it in the documentation and such, since #include in C isn't *that* big of a deal. idk, all I do know for sure is that I do it now and didn't before.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
Just for laughs I just slapped together a strstr and it made me realize a little thing I do in D that I never did in C: assert() I use it all over the place in D, pretty much any time I make an assumption, I slap it down in an assert. But I don't I ever, not once, used any kind of assertion in C or C++. I think this is a fairly significant gain that can be attributed to it being built in to D. It is just silly not to do it when it is there.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Fri, Jun 21, 2013 at 05:33:45PM -0400, Andrei Alexandrescu wrote: [...] > Also it's fair to ask about implementing a stdlib function itself if > the interview concerns some systems-level work; e.g. brute-force > strstr() is fair game and I think any engineer should be able to > lift it off the ground quickly (to my dismay, only a fraction can). Yeah, I was rather dismayed at how many people lacked basic understanding of the programming language they purport to be skilled in. Like not understanding variable shadowing in C, or simple closures in Javascript (not the evilly-nested convolution I tested for in a different test question :-P). > Paradoxically use of stdlib functions may actually hurt; I've seen > people who e.g. call strlen() in a loop in order to implement > strstr()! [...] My favorite example of poor strlen() usage is writing "strlen()==0" in a loop condition. More typical causes of disqualification, though, are what one of my university professors affectionately called "squirrelly code": code that *probably* does what it's supposed to, but does so by roundabout, non-obvious ways, running around here and there doing little things that don't really relate directly to the problem at hand (like squirrels running around hunting for their forgotten stash of nuts). Code like this typically demonstrate a lack of understanding of programming in general, or lack of understanding of the problem at hand, or inability to identify and address the salient points of said problem. Typical symptoms include declaring and using useless variables, calling printf inside a function that shouldn't be doing I/O, doing unnecessary type conversions to perform trivial computations (converting int to string and attempting to do arithmetic on the digits in the string), odd usage of loops and conditionals in unexpected places, using comments to urge the computer to do what one wishes, etc.. The software analogue of Rube Goldberg machines, if you will. :-P T -- Век живи - век учись. А дураком помрёшь.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote: brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). But, should the return value be const or not? :P I think I'd write in D just cuz of inout().
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13 5:59 AM, Jacob Carlborg wrote: On 2013-06-21 07:57, H. S. Teoh wrote: we got to ask HR to first administer a technical test before any interviews are arranged; test results are reviewed before deciding to interview the candidate I done tests like that, they all suck. This is how it usually works: You get a problem to solve. They say: "solve it anyway you want, using any language you want". You solve it farily quickly and straight forward. Then they say, "you are not allowed to use that function". Basically they're saying it's cheating. Then you remove that function and change the implementation accordingly. Then they say, "you are not allowed to use that other function". You change the code accordingly and this dance continues. Then you're thinking to yourself, "Am I supposed to reimplement the standard library?". I would say, most times, it's almost irresponsible to _not_ use the standard library. A bunch of people, a lot smarter than I, have had a good 20 years or so to perfect and fine tune the standard library. Not a chance in hell that I'm going to beat that, on an interview, with code written on a whiteboard. A side note. You're of curse not allowed to look at any documentation at all and you're not allowed to use a text editor. You write the code on a whiteboard, yes a _whiteboard_. That's just so stupid. That's not how programming works in the real world. Why the hell do they think IDE's have built in, easy to read/find, documentation. If there's any need to reach for documentation, the interviewer has failed. When interviewing we (at Facebook) ask problems that are likely to appear in a normal day's work, but for which the typical libraries don't help. (E.g. many libraries don't can't help with implementing unstable remove (see std.algorithm).) Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). Paradoxically use of stdlib functions may actually hurt; I've seen people who e.g. call strlen() in a loop in order to implement strstr()! Andrei
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-21 17:14, H. S. Teoh wrote: Heh, at my job, we're looking for skill in specific languages, so candidates are explicitly asked to write C code. And this is done not in an interview setting (which puts too much pressure on the candidate -- can *you* write code in front of interviewers without panicking at least a bit?), but in a classroom setting. Though, granted, when *I* had to go through the procedure, it felt like I was taking my CS final exams all over again. Not exactly a pleasant experience. :-P I had four, one hour each, interviews in one afternoon. Afterwards my brain was basically fried. That's the sign of a poorly-chosen test question. The kind of question I like to use doesn't focus on nitpicky details like that, but on actual algorithms or domain-specific knowledge, like showing that the candidate understands bit operations, pointer arithmetic, and stuff like that. On that note, it's rather shocking how few candidates know how to use malloc() and free() correctly... I guess I managed to avoid what they actually wanted to test. That's not to say the tests my employer gives have only "good" questions, though; there are some that basically do what you describe: "please re-implement strstr(), please concatenate strings without using strcat()", and the like. When I was involved in hiring, I usually ignore these questions when evaluating the candidate, or cut them a lot of slack. I can also understand that it not that easy to create meaningful tests like these. But I do have a slightly evil streak when it comes to technical tests... once I wrote a Javascript question that requires the candidate to evaluate what a piece of code does, that involves several nested closures and variable shadowing. We hired one of the (very) few candidates who actually got that question right, and she turned out to be an excellent coder. Hehe. Well, I don't think the point of the test is to prove that you can write code that's *superior* to the standard library, but that you *can* write non-trivial functionality from ground up. Yeah, I guess it's hard to find meaningful tests. Well, that's a new one. :-P Our tests are administered as pen-and-paper tests. Not unlike CS final exams, unfortunately. :-/ I hate pen-and-paper tests too. I remember those from the university. I understand that they don't want you to have access to a computer with access to the internet or a compiler. But come on, can I at least get a simple text editor. Half of the time I spend on erasing code because I cannot insert new code in the middle of existing code. Then also writing those annoying curly braces (the actual symbols) which I never get right. Actually, we instruct HR to provide the standard C library manuals if candidates ask for it. That's generous. There *are* some unfair questions that expect you to know, e.g., the exact order of arguments to select() and stuff like that, but like I said, it's not HR who evaluates the tests, but the hiring managers, so it's up to our discretion how much weight we put on questions like that. We usually disregard minor mistakes like using the wrong order of arguments to qsort(), if the intent is clear. We don't (or at least I don't) just blindly look for the highest-scoring test and hire those candidates; I usually take the time to look at the code and ask, "why did they write it that way? what does that show about their coding abilities?". I guess we have different experiences. -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Fri, Jun 21, 2013 at 11:59:12AM +0200, Jacob Carlborg wrote: > On 2013-06-21 07:57, H. S. Teoh wrote: > > >we got to ask HR to first administer a technical test before any > >interviews are arranged; test results are reviewed before deciding to > >interview the candidate > > I done tests like that, they all suck. This is how it usually works: > > You get a problem to solve. They say: "solve it anyway you want, > using any language you want". Heh, at my job, we're looking for skill in specific languages, so candidates are explicitly asked to write C code. And this is done not in an interview setting (which puts too much pressure on the candidate -- can *you* write code in front of interviewers without panicking at least a bit?), but in a classroom setting. Though, granted, when *I* had to go through the procedure, it felt like I was taking my CS final exams all over again. Not exactly a pleasant experience. :-P > You solve it farily quickly and straight forward. Then they say, "you > are not allowed to use that function". Basically they're saying it's > cheating. Then you remove that function and change the implementation > accordingly. Then they say, "you are not allowed to use that other > function". You change the code accordingly and this dance continues. > Then you're thinking to yourself, "Am I supposed to reimplement the > standard library?". That's the sign of a poorly-chosen test question. The kind of question I like to use doesn't focus on nitpicky details like that, but on actual algorithms or domain-specific knowledge, like showing that the candidate understands bit operations, pointer arithmetic, and stuff like that. On that note, it's rather shocking how few candidates know how to use malloc() and free() correctly... That's not to say the tests my employer gives have only "good" questions, though; there are some that basically do what you describe: "please re-implement strstr(), please concatenate strings without using strcat()", and the like. When I was involved in hiring, I usually ignore these questions when evaluating the candidate, or cut them a lot of slack. But I do have a slightly evil streak when it comes to technical tests... once I wrote a Javascript question that requires the candidate to evaluate what a piece of code does, that involves several nested closures and variable shadowing. We hired one of the (very) few candidates who actually got that question right, and she turned out to be an excellent coder. > I would say, most times, it's almost irresponsible to _not_ use the > standard library. A bunch of people, a lot smarter than I, have had > a good 20 years or so to perfect and fine tune the standard library. > Not a chance in hell that I'm going to beat that, on an interview, > with code written on a whiteboard. Well, I don't think the point of the test is to prove that you can write code that's *superior* to the standard library, but that you *can* write non-trivial functionality from ground up. > A side note. You're of curse not allowed to look at any documentation > at all and you're not allowed to use a text editor. You write the > code on a whiteboard, yes a _whiteboard_. Well, that's a new one. :-P Our tests are administered as pen-and-paper tests. Not unlike CS final exams, unfortunately. :-/ > That's just so stupid. That's not how programming works in the real > world. Why the hell do they think IDE's have built in, easy to > read/find, documentation. [...] Actually, we instruct HR to provide the standard C library manuals if candidates ask for it. There *are* some unfair questions that expect you to know, e.g., the exact order of arguments to select() and stuff like that, but like I said, it's not HR who evaluates the tests, but the hiring managers, so it's up to our discretion how much weight we put on questions like that. We usually disregard minor mistakes like using the wrong order of arguments to qsort(), if the intent is clear. We don't (or at least I don't) just blindly look for the highest-scoring test and hire those candidates; I usually take the time to look at the code and ask, "why did they write it that way? what does that show about their coding abilities?". T -- I see that you JS got Bach.
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-21 12:20, Andrej Mitrovic wrote: Oh? That's cool. Which [rpkect? I don't know if it was a particular project but at least one company was interested in several projects, DStep (convert C/Objective-C headers to D modules), Jazz (D frontend) and Orbit (D package manager). https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/jazz https://github.com/jacob-carlborg/orbit -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 05:59:00 UTC, H. S. Teoh wrote: In spite of it all, though, we still sometimes end up hiring people who, 6 months down the road, write code that makes you scratch your head going "huh?! that genius coder we hired wrote *this* junk?!". But maybe some hiring managers are less discerning than others. *shrug* In my (admittedly U.S.-centric) experience: if you're getting people who know how to use external libraries, what a debugger is, more than one programming language (or, indeed, any language other than Java), and any form of source control at all, I'm afraid you're hitting among the cream of the crop as far as CS baccalaureates go. And if you want them to admin a box at the same time, good luck with that. You're often better off with a passionate dropout if you're interested in hiring someone to write code. My hypothesis is this happens because the curricula are heavily skewed toward theoretical aspects of computer science. (In my view, the exemplar for this was OSU before they axed the mandatory RESOLVE/C++ series.) Cheers, Wyatt
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On Friday, 21 June 2013 at 06:34:09 UTC, Andrej Mitrovic wrote: On 6/21/13, H. S. Teoh wrote: In spite of it all, though, we still sometimes end up hiring people who, 6 months down the road, write code that makes you scratch your head going "huh?! that genius coder we hired wrote *this* junk?!". Seems like nowadays it's not too far-fetched to ask for a github/bitbucket/etc username and see the work they've done, the way they write code, contribute, etc. It should give a better "feel" than any interview. Except not everyone has the authorization to place their work code in such public places nor the availability or desire to code after work, just to please job interviewers. -- Paulo
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13, Jacob Carlborg wrote: > I agree. Most interviews I have been on lately is due to my github project. Oh? That's cool. Which [rpkect?
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13, Andrej Mitrovic wrote: > On 6/21/13, Jacob Carlborg wrote: >> I agree. Most interviews I have been on lately is due to my github >> project. > > Oh? That's cool. Which [rpkect? > Looks like I rot13'ed by accident, I meant which project?
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-21 07:57, H. S. Teoh wrote: we got to ask HR to first administer a technical test before any interviews are arranged; test results are reviewed before deciding to interview the candidate I done tests like that, they all suck. This is how it usually works: You get a problem to solve. They say: "solve it anyway you want, using any language you want". You solve it farily quickly and straight forward. Then they say, "you are not allowed to use that function". Basically they're saying it's cheating. Then you remove that function and change the implementation accordingly. Then they say, "you are not allowed to use that other function". You change the code accordingly and this dance continues. Then you're thinking to yourself, "Am I supposed to reimplement the standard library?". I would say, most times, it's almost irresponsible to _not_ use the standard library. A bunch of people, a lot smarter than I, have had a good 20 years or so to perfect and fine tune the standard library. Not a chance in hell that I'm going to beat that, on an interview, with code written on a whiteboard. A side note. You're of curse not allowed to look at any documentation at all and you're not allowed to use a text editor. You write the code on a whiteboard, yes a _whiteboard_. That's just so stupid. That's not how programming works in the real world. Why the hell do they think IDE's have built in, easy to read/find, documentation. -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 2013-06-21 08:33, Andrej Mitrovic wrote: Seems like nowadays it's not too far-fetched to ask for a github/bitbucket/etc username and see the work they've done, the way they write code, contribute, etc. It should give a better "feel" than any interview. I agree. Most interviews I have been on lately is due to my github project. -- /Jacob Carlborg
Re: OT: CS education gone wrong (Was: Re: TDD is BS?)
On 6/21/13, H. S. Teoh wrote: > In spite of it all, though, we still sometimes end up hiring people who, > 6 months down the road, write code that makes you scratch your head > going "huh?! that genius coder we hired wrote *this* junk?!". Seems like nowadays it's not too far-fetched to ask for a github/bitbucket/etc username and see the work they've done, the way they write code, contribute, etc. It should give a better "feel" than any interview.
OT: CS education gone wrong (Was: Re: TDD is BS?)
On Fri, Jun 21, 2013 at 01:14:28AM -0400, Nick Sabalausky wrote: > On Thu, 20 Jun 2013 20:50:08 -0700 > "H. S. Teoh" wrote: [...] > > One of my previous supervisors told me that when he gets resumés, as > > soon as he sees "Ph.D" he chucks it straight into the trash. > > Classic ;) I'd be likely to do the same. > > And I have a friend who's moved up to a management position on a > University's IT dept and he's had similar experiences: When they hire, > they're expected to get their candidates via the HR dept (heh, yea, > right there you know things are gonna go wrong ;) ). And their HR > dept, as with most, makes their selections by blindly grepping for the > biggest degrees (they don't know any better - they're HR people!). > He's told me horror stories about how nearly all of the big-degree > candidates they send him turn out during interview to be flat-out 100% > incompetent. It's not entirely HR's fault. It's the way they're setup to fail. :-P The way it works at my job is that everything still has to go through HR, but it's the hiring managers (who are themselves coders actually writing code for projects) who review resumés and recommend potential hires to HR. HR then arranges the technical tests and interviews, usually with the hiring managers who recommended the candidates plus one or two others whom the candidates will actually be working with, and then take care of all the paperwork and other stuff that hiring managers shouldn't be concerned with. IOW, we don't have HR decide who to interview, but actual technical people look at the resumés to weed out the BS. I was involved with the hiring process for a bit some time ago -- we got to ask HR to first administer a technical test before any interviews are arranged; test results are reviewed before deciding to interview the candidate -- and we get to ask them questions about why they answered a certain test question the way they did. Makes weeding out incompetent applicants much easier. :-) If the code they submitted on the test looks obviously lousy, we don't even bother interviewing them. In spite of it all, though, we still sometimes end up hiring people who, 6 months down the road, write code that makes you scratch your head going "huh?! that genius coder we hired wrote *this* junk?!". But maybe some hiring managers are less discerning than others. *shrug* [...] > When I was a freshman undergrad (at BGSU, near Toledo), I tinkered > around on the side with some PalmOS development. (PalmOS was still > around back then.) A couple years or so later, shortly after I'd > transferred out IIRC, I noticed on BGSU's Computer Science dept's > website that they were bragging - and I mean genuinely bragging - that > their genius *graduate* CS students had (*gasp!*) made software that > ran on a PalmOS device! [...] At least it's not as bad as "Graduates from our wonderful marvellous amazing CS program helped design our sucky non-navigable department website! Don't you wanna come study here and get a degree in HTML?". Sigh... T -- War doesn't prove who's right, just who's left. -- BSD Games' Fortune
