Lack of bit field instructions in x86 instruction set because of patents ?

No, its a good thing, because people will see his bad attitude, and constant attacks on the skills of others, while giving no reason to do business with his company.

--
http://improve-usenet.org/index.html

Goggle Groups, and Web TV users must request to be white listed, or I
will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
Reply to
Michael A. Terrell
Loading thread data ...

Feel free.

I got my own PDP-8 in about 1969.

You use asynchronous processors?

John

Reply to
John Larkin

age

se

Several possible solutions to that:

  1. ask to write some code right on the spot, but choose a problem appropriately: shouldn't be very hard to understand, nor should take long to write
  2. before they come to the interview, just a day or two in advance give them a problem to write a solution for. Cancel the interview if the code is too bad. Yes, there's an issue here, how do you know if they got the solution themselves or somebody or something helped them? Also, in this case your problem is more likely to appear on the internet or it will make it there faster.

It would be ideal to see their home or open projects. I actually wonder, if it's possible to be a good programmer and never have such projects.

Alex

Reply to
Alexei A. Frounze

That's almost as good a laugh as when I pointed out to the management at Sperry/Honeywell Satellite Division that a public mailbox _inside_ the facility made it trivial to steal parts _and_ secrets.

It was moved to outside the guard shack entrance the next week ;-)

...Jim Thompson

--
| James E.Thompson, P.E.                           |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
With all this hope and change, all you need is a dab of mayonaisse
and you\'ll have a tasty lunch on which you will choke to death.
Reply to
Jim Thompson

One of the guards at Cincinnati Electronics was bragging about how secure the pushbutton door locks were, so i walked over to it, took a quick look and punched four buttons and opened the door. The head of security demanded to know who gave me the code, since the door I opened had nohing to do with my department. I smiled and told him, The janitors. Which one? All of them. They are too lazy to keep those fancy locks clean, and I could tell by looking which buttons to push, and in what order. He didn't believe me, so I walked down the hall, opening one door after another, each with a different combination. Then I explained how to spot the combination and he turned red.

The next day the janitors were told that every lock had to be wiped down every day, and get a through cleaning every Saturday. Maintenance was pissed, for having to recode so many doors, and hundreds of people had to learn new combinations. :)

--
http://improve-usenet.org/index.html

Goggle Groups, and Web TV users must request to be white listed, or I
will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
Reply to
Michael A. Terrell

I can see "which buttons", but how did you get the order?

Reply to
Joe Pfeiffer

ow

ose

hen

First buttons were the dirtiest?

Alex

Reply to
Alexei A. Frounze

That won't tell us what we want to know.

A program should start with context: who wrote it when, what it does, what compiler/processor it's for, what is its revision history, anything else that would be useful. And it should be carefully commented alongside the code. A quick "coding" test won't show that.

Most of the code we see is just a jumble. You have to figure out what version of which language it's in (C? C++? Java? Python?) by examining it line by line. Ditto trying to find out what it's supposed to do.

Crap.

That's better; it will show their style.

Seems unlikely.

John

Reply to
John Larkin

Good point. I don't like to work with priggish, crabby people. They quench ideas.

John

Reply to
John Larkin

Of course. So do you. So does everyone else posting here.

You don't need asynchronous logic for a processor to be asynchronous and, in fact, I said 'machine' (and you don't need asynchronous processors for a machine to be asynchronous). That's been the case since the early 1960s, and has been common knowledge even among non-experts for well over a decade.

Regards, Nick Maclaren.

Reply to
nmm1

It isn't:

The only way to become really good at anything is to practice, and practice is a lot easier to keep up if you like doing it.

The rule of thumb seems to be 10 years/10 k hours.

I do all my really hard-core/low-level programming with pen&paper: It is the only way I know to write something so that I really know if I understand all the issues or not.

Most of my "production" code is perl glue logic, which I'll happily sit down and just write, but that's because there's far less actual thinking involved.

Terje

--
- 
"almost all programming can be viewed as an exercise in caching"
Reply to
Terje Mathisen

As I am a REALLY slow handwriter, and have difficulty in reading what I have written, I tend to use a computer. But that means crude, ad-hoc pseudo-code and flow charts in an editor screen. If the task is really tricky, I then write that up in semi-formal pseudo-code, or ad-hoc 'standardese', which can be included as comments.

Coding is then the FOURTH stage[*] :-)

Yes. Except Python, shell, Fortran and C in my case. I am just doing it for Mathematica, but I don't need a description of how to do mere powering and exponentiation, even in symbolic form, as it's more or less engraved on my brain. Using Mathematica isn't :-(

[*] The first being the basic mathematical design, which has to be done in one's head, on scrappy bits of paper, exploratory programs and whatever else is needed to design a new algorithm.

Regards, Nick Maclaren.

Reply to
nmm1

Yes, and the clean button was the one that wasn't used.

--
http://improve-usenet.org/index.html

Goggle Groups, and Web TV users must request to be white listed, or I
will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
Reply to
Michael A. Terrell

Logic. ;-)

--
http://improve-usenet.org/index.html

Goggle Groups, and Web TV users must request to be white listed, or I
will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
Reply to
Michael A. Terrell

He and Sloman should work together, and see who snaps first. Then it will be smashed keyboards and tubes of DIP 555s at ten paces. :)

--
http://improve-usenet.org/index.html

Goggle Groups, and Web TV users must request to be white listed, or I
will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
Reply to
Michael A. Terrell

They probably have no joy in writing programs - poor guys.

Styles differ - from your other posting I see that you have some special expectations. I find most code ghastly, too, but maybe for different reasons ;-).

Hm, a significant part of what you are looking at here is in the VCS, not in the source. Like who wrote it when (blame command), revision history (log command). Programming is about using tools. Not using a VCS is worse than just writing ghastly code.

Comments? Depends on the strategy. For some projects, literate programming is appropriate - e.g. you teach the user how to write such a software, and understand the rationale behind. If you do test-driven development, your documentation would be a spec plus tests. If you write a library, you would use something like doxygen, where you document the use of each function together with its implementation. The purpose here is to produce a user manual out of the source code.

Actually writing in plain text what you already wrote in the programming language (typical assembler-style along-side documentation) is IMHO not good style for high level languages. Using proper function and variable names helps a lot, more is only for the reader who doesn't understand the programming language. This is pointless most of the time - a programmer must understand the programming language he uses and read it as fluently as English text. Comments like

a += c; // add c to a foo(a, c); // call foo with parameters a and c

don't add any value, except if the program is meant as beginner's introduction into this particular programming language. Most projects shouldn't fall into this category.

Language should be already identified by file name extension - what it is supposed to do (briefly) by the file basename - at least for the smaller programs you could discuss at an interview (larger programs might have code-named parts, where you can't see function from filename. My widget library is called MINOS, the widget editor Theseus - the programs live in files with these names - of course, the first line in these files describe briefly what it actually is). When you look on printouts, use frame-generating software like a2ps (including syntax highlighting).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Reply to
Bernd Paysan

I don't see why not. If you have an interesting enough job to satisfy your enthusiasm for programming, why would you not spend your home time on the other things that interest you?

Reply to
Ken Hagan

r =A0

=A0

Theoretically that's possible. Practically, it doesn't seem like everyone gets the right job, not all the time at least. Sometimes you have to fight for the interesting job (on the market or already on the job). On some projects and in some companies you grow beyond your project and it's not satisfying anymore. Or your management won't let you do some cool stuff because to them that's something they don't understand or something unnecessary or they want/need you to do X, not Y. Sometimes you're tied to a job for a reason and you don't quite enjoy what you have to do. In those cases if you're a programmer at heart, if you have some free time on hand and don't have many other things to do, you'll do some programming work elsewhere for pleasure, to grow, etc.

Alex

Reply to
Alexei A. Frounze

essage

ponse

Um, if it happens before your eyes, that's probably too much to ask for an exercise. :)

Unless you're very strict with that (and you may be due to contractual obligations), solid code is much more important than those little bits. Don't get me wrong. Comprehensible comments are good and at times necessary. What I'm trying to say is, if the code's logic is bad or convoluted or based on wrong assumptions or the code's too fragile or it's often missing the necessary error condition checks, then no amount of comments or revision history will help. And it's fairly easy to give problems where you naturally expect certain design decisions and implementation details, including those checks. And that's IMO the first thing to look at.

:) You don't hire just anybody, do you? I think the scope of project and the work you're planning to give to the new employee already implies certain languages. And so does a resume. Anyhow, you can explicitly communicate the requirements, including the acceptable language options and the fact that the code must contain a comment explaining what is used to build it and how.

Alex

Reply to
Alexei A. Frounze

This is interesting. I've seen such a figure somewhere recently and it seems like it's about right.

I prefer a pencil or a writing board so I can redo it. :)

If the language frees you up from thinking about things you don't really want or need to think, it's great. I think Perl has some merit here (compared to C or ASM:).

Alex

Reply to
Alexei A. Frounze

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.