You don't need to go high up in the mountains even, you just need to go further away from the coast for the temperatures to drop quickly. Karasjok is, I believe, at an elevation of 141 meters, and it can be fairly cold there (record is -51.4C or close to that).
Also: length. Closer to 2800 km of mostly windy roads crossing mountain passes and twisting around whatever terrain or moose was in the way when they built it if you go between Lindesnes and Kirkenes;-)
A lot of these factors caused people to be sceptical towards electrical cars, and many people still are. Reducing taxes on the cars is one way of coercing people into trying.
For myself, I bought a plug in hybrid in 2014 (no tax benefits), and I just ordered a new one. 4WD electric or hybrids are really nice on slippery roads (especially for hills). We did consider a fully electric car, but the charging infrastructure in the northern parts of the country are still not quite there for a one car family (unless you can justify buying a Tesla;-) ).
I totally agree. It feels like we've landed in the stone age, but with pretty makeup.
Two of the features I'm missing in any of the web based forums: a) tracking which messages I have read and which are new, and b) scoring (which was possible to do with more than killfiles).
With usenet it was actually possible to follow discussions that developed over time without spending too much time on it. With web based forums, you have to remember and filter out manually what you have read. It feels more like drive-by-discussions where people shout quick opinions out of the car window, but you never get to discuss stuff with them before they are gone.
Did you ever try the Microsoft Sidewinder Force Feedback pro? The fan in that joystick (yes!) made more noise than one of our 8-way HP servers. I don't think the power supply gave it enough juice though. It sounded like the fan lost speed when you pushed against the stick with the force feedback enabled.
The protocol it used was in one way pretty clever, using the 4 button bits from the old-style joystick port to send a binary 48-bit (I think) packet with information about the state of the joystick, and at the same time pretty annoying: it looked like they had scrambled the bits, so for a 7-bit value, you would find bits 0-2 in one place, bit 3 in another, and so forth.
It never broke though, but then again I hardly ever used it because of the noise. Occasionally, we'd bring it out in the lab, turn it on, have a good laugh and pack it back down again.
The brits did something like this during the second world war (google for "bouncing bomb").
One rather short story here:
http://www.chm.bris.ac.uk/webprojects2001/moorcr af t/The%20Bouncing%20Bomb.htm
The Discovery Channel aired an interesting program about this (I think it was called "Dambusters"). One of the problems they had to solve was avoiding damage to the plane from the bombs first splash.
...but you can probably hand-optimize its assembler output to be yet faster....
That is true (at least for some cases). Actually, some of the more modern[1] Lisp systems allow you to program Assembly directly from the Lisp system. You never need to leave the Lisp system for that last bit of assembly squeezing. The nice thing about this is that you can dynamically write and add/change assembly-implemented functions, so you can even make Lisp-functions which modify and recompile your hand-optimized "template functions" based on the particular input-data on this run of the system (adding the benefit of dynamic/run-time optimization to the static optimization you do with handcrafted assembly). Of course, you can also do this using standard compiled lisp functions.
I mostly use Assembly for kernel-level things that are hard to do from a C compiler though.
1. I assume this was the case for some of the older ones as well
I just want to take issue with one of your points which sounds like a misunderstanding (the rest sound mostly like flamebait to me):
3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.
One of the things I love about Lisp is that you don't start by optimizing your solution before you know it. You start by solving the problem (correctly!), then you start optimizing the solution. This can either be done by recoding (considering the first code as a prototype) or evolving the code (typically choosing more optimal constructs and adding type annotations).
I have personally gotten a Lisp implementation to perform within 10-15 percent of C code on computationally intensive code. I could perhaps have gotten even closer if it had been important to me. Or I could have chosen to use C functions for the "inner loops" (which is in fact simpler than doing the same from Python). I sometimes do the latter when I need to squeeze the last few bits out (or when I already have optimized C solutions for known algorithms available).
The whole point is not to spend time on optimizing something which is already fast enough. When you do need to optimize the code, you profile it and start optimizing the bits that eat up your time instead of optimizing parts which are not contributing much to your run time.
Re:The question is not whether you re done coding
on
Coder or Architect?
·
· Score: 1
> As it turned out however I found that my concentration had gone long before I was 30.
I had a similar experience with this. I just ran out of steam around the age of 25-26, but the reason wasn't the age. It was partly due to overwork (studying and working at the same time), and partly due to increased experience.
When you have churned out X hundred thousand lines of C++ code, you start noticing that you tend to spend a depressing amount of time on:
write the same or equivalent code over and over again before you get to start on the real problems. Code reuse isn't alway practical or even possible (the reasons can be both "political" and technical).
solve and code trivial problems which basically are just boring (but were challenging when you first started to learn programming) before you get to start on the fun problems
wrestling with the wrong problems (the language gets in the way with the types of abstractions it can support, and the language mindframe forces your designs to be unneccesary clumsy)
A solution for me was to ditch C++ for most of my work. I still use it, but most of my time nowadays goes to coding in Common Lisp, Python and C (as well as other languages when needed, or when I just want to play with something).
The major problem of being multilingual is integration of the languages (SWIG doesn't always cut it for instance), and interfacing with other programmers which don't want to learn more than the language they know. But that's usually solvable (especially if you show a little restraint and avoid throwing too many tools into the soup).
I think I'm even more productive these days than I used to be. Not in the number of lines of code produced (I tend to remove more code than I add by restructuring the code), but in the functionality I can add corretly to a system over a given time.
It's like learning to walk and run. When you start learning to run, you don't want to keep using tools that force you to crawl for days before you're allowed to run for 5 minutes.
That probably means that it's natural for some to migrate to architecture and design (which can be thought of as very high level languages - think of the coding slaves as manual compilers;-)), simply because they want to work with something that challenges them more than low-level coding.
For me, it's been a combination. I use C when I need to code optimized algorithms or kernel coding, and higher level languages for things such as gui and application coding. And I currently moonlight as an architect for a simulation framework.
We already are off loading video processing to specialty built video hardware. Were not doing this very much with sound (yes, you can get you high end cards to add base and sound fields, but you cant do OpenGL like sound calls - play the
sound I uploaded to you before like it was coming from (x,y,z) with this ambient sound....)
We used something like that on SGIs Onyx some years ago using an add-on box. You could download sounds, pitch them, specify full 3D positioning (great if you had enough speakers), speed (for doppler effects) etc.
Maybe somebody would see a market in it if people start buying more than 2 speakers (8 perhaps?;-)) for their PCs.
Slashdot Mirror
You don't need to go high up in the mountains even, you just need to go further away from the coast for the temperatures to drop quickly. Karasjok is, I believe, at an elevation of 141 meters, and it can be fairly cold there (record is -51.4C or close to that).
Also: length. Closer to 2800 km of mostly windy roads crossing mountain passes and twisting around whatever terrain or moose was in the way when they built it if you go between Lindesnes and Kirkenes ;-)
A lot of these factors caused people to be sceptical towards electrical cars, and many people still are. Reducing taxes on the cars is one way of coercing people into trying.
For myself, I bought a plug in hybrid in 2014 (no tax benefits), and I just ordered a new one. 4WD electric or hybrids are really nice on slippery roads (especially for hills). We did consider a fully electric car, but the charging infrastructure in the northern parts of the country are still not quite there for a one car family (unless you can justify buying a Tesla ;-) ).
10 types perhaps ;-)
What? Are we related somehow? I've pondered over the blue lint for years ;-)
I guess this calls for a new product name: the ipad stretch ;)
I totally agree. It feels like we've landed in the stone age, but with pretty makeup.
Two of the features I'm missing in any of the web based forums: a) tracking which messages I have read and which are new, and b) scoring (which was possible to do with more than killfiles).
With usenet it was actually possible to follow discussions that developed over time without spending too much time on it. With web based forums, you have to remember and filter out manually what you have read. It feels more like drive-by-discussions where people shout quick opinions out of the car window, but you never get to discuss stuff with them before they are gone.
How much would you typically pay in the US to run a red light or drive the wrong way on the motorway, something that actually endangers lives?
Did you ever try the Microsoft Sidewinder Force Feedback pro? The fan in that joystick (yes!) made more noise than one of our 8-way HP servers. I don't think the power supply gave it enough juice though. It sounded like the fan lost speed when you pushed against the stick with the force feedback enabled.
The protocol it used was in one way pretty clever, using the 4 button bits from the old-style joystick port to send a binary 48-bit (I think) packet with information about the state of the joystick, and at the same time pretty annoying: it looked like they had scrambled the bits, so for a 7-bit value, you would find bits 0-2 in one place, bit 3 in another, and so forth.
It never broke though, but then again I hardly ever used it because of the noise. Occasionally, we'd bring it out in the lab, turn it on, have a good laugh and pack it back down again.
X = Y + Z;
Mind you, it was impossible to understand why the code was adding those numbers, nor, for that matter, what the function was doing.
I found a lot of comments like that in some commercial code once. One of the nicest was: /* Set X to Y + Z */
X = Y + Z;
Except of course that the comment was in French.
Sometimes I wish I could. Especially when the kids change their minds about how they want their eggs done.
The brits did something like this during the second world war (google for "bouncing bomb").
r af t/The%20Bouncing%20Bomb.htm
One rather short story here:
http://www.chm.bris.ac.uk/webprojects2001/moorc
The Discovery Channel aired an interesting program about this (I think it was called "Dambusters"). One of the problems they had to solve was avoiding damage to the plane from the bombs first splash.
I tried growing a beard once, but gave up when I discovered that my beard had four different colours. Maybe I should get a DNA test.... ;-)
> You may have to wait a bit for it to load
Yes, especially up here in the arctic.
That is true (at least for some cases). Actually, some of the more modern[1] Lisp systems allow you to program Assembly directly from the Lisp system. You never need to leave the Lisp system for that last bit of assembly squeezing. The nice thing about this is that you can dynamically write and add/change assembly-implemented functions, so you can even make Lisp-functions which modify and recompile your hand-optimized "template functions" based on the particular input-data on this run of the system (adding the benefit of dynamic/run-time optimization to the static optimization you do with handcrafted assembly). Of course, you can also do this using standard compiled lisp functions.
I mostly use Assembly for kernel-level things that are hard to do from a C compiler though.
1. I assume this was the case for some of the older ones as well
One of the things I love about Lisp is that you don't start by optimizing your solution before you know it. You start by solving the problem (correctly!), then you start optimizing the solution. This can either be done by recoding (considering the first code as a prototype) or evolving the code (typically choosing more optimal constructs and adding type annotations).
I have personally gotten a Lisp implementation to perform within 10-15 percent of C code on computationally intensive code. I could perhaps have gotten even closer if it had been important to me. Or I could have chosen to use C functions for the "inner loops" (which is in fact simpler than doing the same from Python). I sometimes do the latter when I need to squeeze the last few bits out (or when I already have optimized C solutions for known algorithms available).
The whole point is not to spend time on optimizing something which is already fast enough. When you do need to optimize the code, you profile it and start optimizing the bits that eat up your time instead of optimizing parts which are not contributing much to your run time.
I had a similar experience with this. I just ran out of steam around the age of 25-26, but the reason wasn't the age. It was partly due to overwork (studying and working at the same time), and partly due to increased experience.
When you have churned out X hundred thousand lines of C++ code, you start noticing that you tend to spend a depressing amount of time on:
A solution for me was to ditch C++ for most of my work. I still use it, but most of my time nowadays goes to coding in Common Lisp, Python and C (as well as other languages when needed, or when I just want to play with something).
The major problem of being multilingual is integration of the languages (SWIG doesn't always cut it for instance), and interfacing with other programmers which don't want to learn more than the language they know. But that's usually solvable (especially if you show a little restraint and avoid throwing too many tools into the soup).
I think I'm even more productive these days than I used to be. Not in the number of lines of code produced (I tend to remove more code than I add by restructuring the code), but in the functionality I can add corretly to a system over a given time.
It's like learning to walk and run. When you start learning to run, you don't want to keep using tools that force you to crawl for days before you're allowed to run for 5 minutes.
That probably means that it's natural for some to migrate to architecture and design (which can be thought of as very high level languages - think of the coding slaves as manual compilers ;-)), simply because they want to work with something that challenges them more than low-level coding.
For me, it's been a combination. I use C when I need to code optimized algorithms or kernel coding, and higher level languages for things such as gui and application coding. And I currently moonlight as an architect for a simulation framework.
We used something like that on SGIs Onyx some years ago using an add-on box. You could download sounds, pitch them, specify full 3D positioning (great if you had enough speakers), speed (for doppler effects) etc.
Maybe somebody would see a market in it if people start buying more than 2 speakers (8 perhaps? ;-)) for their PCs.