My father's an electronic engineer (one of those "real engineering" disciplines). Strangely, they also have good and bad engineers. They even have "real engineers" (similar to "real programmers").
It's probably true that the average electronic engineer is more useful than the average programmer. But they're far from all being equally useful.
I recall an interview at Stanford when I was just starting out in my career. I'd only ever worked at MIT as research staff since graduating with my Bachelor's, and I was interviewing with a PostDoc there. He was very arrogant and said to me, "I can't tell you what you'll be making, but I can tell you what you won't be making, which is $39K."
A confused postdoc. Postdocs have shitty salaries (approximately 2x a grad student salary), at universities at least. I'd expect staff to be paid better tham them.
But back to the University and Politics, the other thing is that if you're not a PhD, then you probably won't get to be Principal Investigator on grant proposals, and that means you'll be constantly in the shadow of someone else no matter how good the work you do is.
A confused poster. Principal investigator is a research position, and for various rather obvious reasons (e.g., the funding agency will expect it...), it's expected to be filled by a researcher. A PhD is a "token" that others believe you can do research, without one you'll need some other evidence that you can do that job (e.g., you're famous in the field). A bit of a catch-22 of course, but what do you expect?
True, but several of the optimizations that used to be found only in commercial compilers were figured out[by gcc]through a reverse-engineering process.
I don't believe you. Cite some evidence, and, while you're at it, name some significant compiler optimisation which isn't published.
And, in the field in question, i.e., CS, the good conferences have highly rigorous review, while the journals are languishing. Typical exchange: "What should we do with this rejected conference paper?" "Well, we could submit it to a journal..." "Shouldn't we try the 'next' conference?"
I think you should learn which are the good conferences before making such sweeping generalisations. There's no way papers in the good conferences in any particular subfield (programming languages, networking, machine learning, etc) could be even remotely described as "buzzword-laden crap".
However, there are typically only two top conferences in every subfield, and maybe half-a-dozen or so good ones. The rest tend to be of "uneven" quality...
I could've sworn I had several cookery books in the same style (list of ingredients, list of instructions). Strangely, they weren't marketed as "cooking for engineers", rather they tend to be basic cookery books.
An example: ISBN: 0140460179. Original edition: 1952 (predates slashdot, and most (99.99%?) of the computer industry).
There is something to be said for 13 days of "sick leave" (yeah right, that system isn't abused) and 13 of annual right off the bat (and 20 after 3 years is a great deal).
Muahaha. 1: Ethical people don't abuse sick leave. 2: Ethical countries don't limit sick leave. (and, 3: 13 days sucks, 20 days is a minimum)
Some amount of misinformation, as usual;-) A few corrections:
- The Berkeley lablet was *not* created because of excitement over sensor networks. The Berkeley (and the other) lablets were created as part of a new approach to industrial research labs, in close collaboration with universities. Sensor networks was the first project undertaken at the Berkeley lablet (and, given that it was mentioned, PlanetLab was the second).
- The UC Berkeley project in question is (currently) the NEST project (http://webs.cs.berkeley.edu), funded by DARPA. This project was inspired by the Smart Dust project, but its emphasis has mostly been on the software (operating systems, languages, networking, applications, etc) rather than the hardware.
I just made myself a nice cup of tea. Left it to brew for a bit, then poured it into a mug. Its temperature in the mug was 84C (183F). It's quite easy to sip at that temperature as long as you blow on the surface first... I think the previous poster has no clue how hot 60C or 80C is;-)
I could believe that the average cup of tea served in US restaurants is at 60C...
It's a component-based OS, and there's lots of components you could use... (including support for different platforms and different sensor boards). However, only the components you actually use end up in your application.
There's also a bunch of Java code in the distribution for the PC side of things.
The 200 bytes is just the scheduler and initialisation code, any system components your application use are "extra".
Try
let x = cons(1, x) in...
in a purely functional language (e.g., Haskell) and let us know how it compares to
x = cons(1, x)
in C (or something similar in Forth, for that matter)
[syntax arbitratry, assuming an appropriate linked-list type for C]
Hint: the results are not the same.
Have you actually got a PhD, are you repeating random bullshit?
It's probably true that the average electronic engineer is more useful than the average programmer. But they're far from all being equally useful.
Now the practical energy is a different question, of course...
A confused postdoc. Postdocs have shitty salaries (approximately 2x a grad student salary), at universities at least. I'd expect staff to be paid better tham them.
But back to the University and Politics, the other thing is that if you're not a PhD, then you probably won't get to be Principal Investigator on grant proposals, and that means you'll be constantly in the shadow of someone else no matter how good the work you do is.
A confused poster. Principal investigator is a research position, and for various rather obvious reasons (e.g., the funding agency will expect it...), it's expected to be filled by a researcher. A PhD is a "token" that others believe you can do research, without one you'll need some other evidence that you can do that job (e.g., you're famous in the field). A bit of a catch-22 of course, but what do you expect?
You must be a member of the flat earth society.
I don't believe you. Cite some evidence, and, while you're at it, name some significant compiler optimisation which isn't published.
Does anyone know if it got in?
And, in the field in question, i.e., CS, the good conferences have highly rigorous review, while the journals are languishing. Typical exchange: "What should we do with this rejected conference paper?" "Well, we could submit it to a journal..." "Shouldn't we try the 'next' conference?"
I think you should learn which are the good conferences before making such sweeping generalisations. There's no way papers in the good conferences in any particular subfield (programming languages, networking, machine learning, etc) could be even remotely described as "buzzword-laden crap".
However, there are typically only two top conferences in every subfield, and maybe half-a-dozen or so good ones. The rest tend to be of "uneven" quality...
Strange. I could've sworn every single grant proposal came with deliverables. Maybe you live on a different planet than most CS professors?
And it (explicitly) limits itself to pre-personal-computer stuff, which is strange.
Though it's a bit more complicated if online shopping allows (makes it easier, whatever) you to do without a car at all...
I could've sworn I had several cookery books in the same style (list of ingredients, list of instructions). Strangely, they weren't marketed as "cooking for engineers", rather they tend to be basic cookery books. An example: ISBN: 0140460179. Original edition: 1952 (predates slashdot, and most (99.99%?) of the computer industry).
Nothing like Slashdot for gross misinformation. From Logitech's web site:
Founded
1981 -- Apples, Switzerland
(I found it pretty amusing when, years ago, I was using a mouse from "Apples" with an Apple IIe. It was a rather sucky mouse back then, mind you...)
Of course, these days its a large multinational company, so claiming it for any particular country is just pointless nationalism.
Muahaha. 1: Ethical people don't abuse sick leave. 2: Ethical countries don't limit sick leave. (and, 3: 13 days sucks, 20 days is a minimum)
Some amount of misinformation, as usual ;-) A few corrections:
;-)
- The Berkeley lablet was *not* created because of excitement over sensor networks. The Berkeley (and the other) lablets were created as part of a new approach to industrial research labs, in close collaboration with universities. Sensor networks was the first project undertaken at the Berkeley lablet (and, given that it was mentioned, PlanetLab was the second).
- The UC Berkeley project in question is (currently) the NEST project (http://webs.cs.berkeley.edu), funded by DARPA. This project was inspired by the Smart Dust project, but its emphasis has mostly been on the software (operating systems, languages, networking, applications, etc) rather than the hardware.
David Gay - not speaking for Intel
I just made myself a nice cup of tea. Left it to brew for a bit, then poured it into a mug. Its temperature in the mug was 84C (183F). It's quite easy to sip at that temperature as long as you blow on the surface first... I think the previous poster has no clue how hot 60C or 80C is ;-)
I could believe that the average cup of tea served in US restaurants is at 60C...
It's a component-based OS, and there's lots of components you could use... (including support for different platforms and different sensor boards). However, only the components you actually use end up in your application.
There's also a bunch of Java code in the distribution for the PC side of things.
The 200 bytes is just the scheduler and initialisation code, any system components your application use are "extra".
This is where TinySec comes in handy ;-)
(making sure that at least one Berkeley reference shows up in this thread ;-))
Try let x = cons(1, x) in ...
in a purely functional language (e.g., Haskell) and let us know how it compares to
x = cons(1, x)
in C (or something similar in Forth, for that matter)
[syntax arbitratry, assuming an appropriate linked-list type for C]
Hint: the results are not the same.