Check out nemerle for a more generic feature, macros.
You can define a 'from' macro that does all this in just a few minutes. This is not new stuff, and I can't believe this Anders guy is billing it as a great new thing when it's been done before - for a.Net language no less - in a far more generic and powerful way.
if i'm reading this properly light based circuits could be decimal based, which may be an advantage if it's possible. with decimal based architecture: 1 - less hardware can store higher values (greater capacity per memory cell). 2 - comp sci will be MUCH easier and more intuitive =) 3 - you could have the processors/circuitry operating on the visible spectrum, offering the most awesome looking case mods imaginable! YARR!
Regarding these points in turn
Base three is better (base e is ideal, but being a non-integer base makes it useless for a godawful lot of applications - not to mention remarkably difficult to implement:).
No way, base 10 is the least intuitive when you start doing computation, base 2 makes much more sense.
no they don't, but Intel make Xeons that can interpret AMD64 instructions - thus being amd64 xeons - just like AMD make "Intel Architecture 32bit" only Athlons and Semprons. I'm not sure if they're available for sale though.
> Is it possible that diminishing returns is kicking in on the register set size, or simply bad compilers (or use thereof)?
Bad compilers or more likely they haven't hand optimised their inner loops.
Most high performance ia32 (Intel Architecture 32 bit) software has hand tuned assembler for the tight inner loops, but it takes time, experience and skill to create such assembler. Some discussions I've seen put recent gcc compiling generic C for amd64 at close to the performance of hand optimised assembler for ia32 on the same Athlon 64 (for tight inner loops).
There was an article about an assembler version of a cryptographic function that showed amd64 was capable of a *huge* performance increase over ia32, due to its increased register set.
However it can also come down to implementation quality. IIRC, benchmarks of early amd64 xeon chips showed that they performed worse than ia32 on the same chip for tests that athlon 64 shows a performance *boost* in its 64 bit mode.
> defending them (a requirement for them to be valid)
That is for trademarks, you have to defend them to prevent the words from taking on a meaning that refers to the class of product instead of the product itself, ie "hoover" now means the same as "vacuum cleaner" and the trademark is thus lost since they didn't sue housewives for discussing their new hoovers when really they bought a hoover from Electrolux(TM) or Dyson(TM).
> infringement is much more cut and dried for copyright.
It certainly isn't, to infringe on a patent you must simply have distributed or used something that works in the manner described in the patent - subject to first sale. For copyright infringement you must have actually *copied* something from the original. Independent authoring of similar work (common in matters of logic and mathematics as for many problems there is one or maybe a couple of calculable "right answers") is permitted in copyright law since you didn't copy it.
They certainly are not, any compiler author will tell you that. Go read up on GCCs DFA scheduler - modern CPUs are pipelined which is a simplified parallelism. There are far fewer barriers than not in most ordinary programs.
> even two CPUs won't give nearly the benefit a single twice-as-fast CPU.
Yes, See Athlon vs Pentium 4. Pentium 4 has a much longer pipeline, so it is a simplified hugely parallel design whilst Athlon has a much shorter pipeline and is thus less parallel. The Athlon is actually a few fast clocks instead of many slow clocks. Due to the pipeline simplification of parallel designs made possibly by a discrete clock (hard edges that looks approximately the same at any scale) the out of phase clocks can be combined into one signal that is mathematically equivalent to one faster clock.
I hope this explains why the regular Hz quote is the same as quoting four times the Hz of four parallel CPUs (ie, the regular Hz quote *is* several times the Hz of several processing units).
> It's akin to having four people each running 10 miles per hour. They cannot reach 40 mph that way
No its not, clock cycles are discrete, miles is continuous. It's akin to having four people each take 60 strides per minute, they *do* reach 240 strides per minute between them.
And that's supposed to be a bad thing? OO2's word completion is utter crap. It should't insert the word when you try to enter a return instead of a letter - typing while something is selected replaces the selection... except if you type return. This is completely contrary to any GUI interface guideline I know of, and is very, very dumb.
> In other words a system with four processors running at 1.7GHz aren't going to deliver 6.8GHz of processing ability.
processing ability isn't measured in Hz (the unit of cycles per second), the rate at which a small group of transistors and capacitors will wiggle at is measured in Hz. Since modern CPUs have several clocks, the Hz for a single CPU is just as made up as that for a group of four CPUs.
6.8GHz is as real as 1.7 GHz and just as uninteresting.
> If you're trying to insert invlaid data, you're the only one to blame.
That would be fine if the database were compiled into the application and strongly type-checked by the compiler. Even small software can't be reliably checked by humans, and the database is connected to at runtime so the compiler can't really do it.
With schemas this can be done better. The compiler could know the types that the database supports and the software is compiled against the schema specification, then as you connect ot the database, the schema is checked for agreement and the compiler had assured the types (and the database author had provided classes to compile against). Then you can be *reasonably* safe, but shit can still happen (database version changes, nearly compatible competitor is substituted, etc). When that shit happens, you need to know that the database has its shovel ready. Its because of the loose connection between the application and database that the database must provide this assurance and it can't just be left to the application compiler to check everything at compile time.
> if you REALLY need the logic to reject things like blank inputs in web forms then you should be doing that in your application logic anyway....
Yes, you should often try not to submit data that the database cannot represent since it reduces the overhead, but you should also be allowed to sometimes assume that the data is correct and the database will tell you if it is unable to do what you ask. That is the premise behind exceptions, you act like its going to work, and wait until you are told that it doesn't, then the database can be tuned by extending lengths, accepting 4 dimensional GIS data, etc and the application doesn't have to be changed.
The database is responsible for the data that can be represented, and there is often a functional specification that the application should export the representational capabilities of the storage backend. That defines a functional boundary at the DB/App and exceptions on invalid data are an absolute *requirement*. There is a whole range of programmes that cannot be written if that is not there (ie those programs where the DB part is supposed to be swappable for a new version with greater domain).
For the class of applications that need some default to be substituted for invalid data, with the exceptional style the application can just wait for an exception then try the same again with the default substituted.
MySQL's biggest problem is that if you try to update or insert with invalid data, in many cases it successfully inserts wrong data. PostgreSQL doesn't do that.
PostgreSQL has this nice Object-Relational model where tables can be derived from each other, but there are some nasty bugs that mean I think those features are still best avoided.
Overall, though, I think PostgreSQL is by far the better RDBMS.
> We have a problem here with two overlapping rules: not allowing other companies to manufacture ink cartridges for your printer, and not allowing you to refill the cartridges your manufacturer sells. I don't think either should be legal,
I don't have to buy my tyres from peugeot and I can pump more air into them when they go a bit flat, I don't have to get my keys cut by yale and I can replace them instead of buying a new lock, I don't have to buy my shoe polish from Marks and Spencer, I don't have to buy my sugar from Tetley and I don't have to buy my guitar strings from Fender. Why should it be illegal for someone other than, say, lexmark to supply the cartridges for *my* printer, and why should I be prohibited from refilling them with my *own* ink that I've made or bought from elsewhere?
The point of anuetronic fusion is that they are *not* planning to transfer the heat to a steam turbine (who the hell wants a steam turbine - that's why current powerstations cost so much to build and maintain - and why they're so inefficient).
In a neutronic reaction such as D + T -> He + n high energy neutrons are transfer their energy to water and a steam turbine takes a little bit of that energy back out and coverts a little bit of what it takes into electricity. This is very bad for the environment as it releases huge amounts of waste heat.
In an aneutronic reaction such as p + B11 (5+) -> 3He (2+) high energy helium ions (alpha radiation) is released. This is a large current (moving charge) which can directly induce a current in a coil.
pB11 reactions don't seem to be expected to acheive ignition (ie become self sustaining), the are expected to be pulsed reactions, where a portion of their output is immediated consumed to prepare and force another reaction. All that is needed then to be a useful power source is break even.
However, p + B11 -> 3He is not the only reaction to occur, but I don't know what consequences to expect from that.
The problem with poor technology products is in product direction, that is not a job for an IT manager - that is a job for product management (a role within the programme management umbrella) in liaison with the developers. The problem with many IT related products is that they do not have a competent product manager - but an IT manager is not a product manager and a product manager is not an IT manager. If product management can specify a direction that is both practical and profitable (with advise from developers regarding whether it is practical and leaves the product in a good position for future direction changes), then developers can set priorities to follow that direction.
This middle management fad will wear off and those trained in middle management skills will become accountants and stress councellors, cost only what they're worth, and the consumer will be much better off for it.
> except he doesn't touch on whether or not he is a good MANAGER.
His description suggests he doesn't know anything about IT, so...
> Can he assign resource well?
He doesn't know what it takes to perform a task. so no.
> Can he assign priorities?
Managers are not required for that. Individual developers/admins/teams can do that far more cost effectively.
> does he tell his boss when the teams work load in too much?
The team is more than capable of doing that. What do you need a manager in there for?
> If this person can do all that, then do not fire him, just relize he is there to MANAGE technical resources, not perform technical duties.
That is the most common misconception of management there is. Managers are there to make sure the "people" (note that I don't refer to them as mere resources) that do the work have the necessary tools, time and information to do what needs to be done.
Mostly that means asking those people how important things are, doing the budget calculations for them, then asking them if they concur, rinse and repeat.
>Contrary to the/. mind think, you do not have to have technical skills to be a good technical manager, you just need to know what your team knows(as in area of expected knowledge) and assign the properly.
No, this is how it should work. Board sets a direction, programme managers reify the direction to measurable changes in eg, product positioning, infrastructure efficiency, etc. Programme managers know who has a fair amount of familiarity with a feature to be changed and brings them from the complete pool of talent with a project manager and representatives of stakeholders within the company - they do not go through a politician firewall. Programme management bring a project mandate to this table, and the project brief and approach are defined by those at the table and anybody they seek input from. The project manager produces plans without seeking approval from programme management, but rather seeks approval from the people that will do the work - he does not tell those people how it is gonna be. There should be various bean-counters on hand for the use of the people involved in a project - the bean counters are subservient.
I respect my immediate manager a great deal. He is knowlegable but recognises that his team members have their own areas of expertise. He doesn't gloat if you make a mistake or don't know something, and he laughs a lot. I say you can't get better than that, and nor would you expect to.
Apparantly, the Kliper will run on KDE (that's why its got a silly name) and thus be more user friendly than the USA's GNU/Shuttle. The developers hope that will reduce the number of crashes, and that the more solid frontend won't break into bits and damage the wings. Whilst it will be based on a Linux(R) kernel, it will not use the name "Linux(R)" as Russia can't afford a license to use the word.
Linux(R) is a trademark of Linus Torvalds, and its use has now been restricted to those with money and editorial comment - even the non-profits and private individuals have to have money to spare.
Slashdot Mirror
> It is not quite perpetual-mostion
I read that as perpetual moisten! Imagine all the energy you could generate from sex if you had a perpetual moisten machine!
Check out nemerle for a more generic feature, macros.
.Net language no less - in a far more generic and powerful way.
You can define a 'from' macro that does all this in just a few minutes. This is not new stuff, and I can't believe this Anders guy is billing it as a great new thing when it's been done before - for a
fraid not, but you'll probably be able to find it on lkml archives.
no they don't, but Intel make Xeons that can interpret AMD64 instructions - thus being amd64 xeons - just like AMD make "Intel Architecture 32bit" only Athlons and Semprons. I'm not sure if they're available for sale though.
and am64 xeon is one that can interpret amd64 instructions, as opposed to an ia32-only xeon that can only interpret ia32 instructions.
> Is it possible that diminishing returns is kicking in on the register set size, or simply bad compilers (or use thereof)?
Bad compilers or more likely they haven't hand optimised their inner loops.
Most high performance ia32 (Intel Architecture 32 bit) software has hand tuned assembler for the tight inner loops, but it takes time, experience and skill to create such assembler. Some discussions I've seen put recent gcc compiling generic C for amd64 at close to the performance of hand optimised assembler for ia32 on the same Athlon 64 (for tight inner loops).
There was an article about an assembler version of a cryptographic function that showed amd64 was capable of a *huge* performance increase over ia32, due to its increased register set.
However it can also come down to implementation quality. IIRC, benchmarks of early amd64 xeon chips showed that they performed worse than ia32 on the same chip for tests that athlon 64 shows a performance *boost* in its 64 bit mode.
> this thing is going to output 200000/0.5 = 4GW of power.
>I suspect chernobyl probably got close to that power output, just not for very long.
I suspect chernobyl was capable of outputting an awful lot more. Oxfordshire has a plain old coal fired power station that is rated at 2GW.
On patents:
> defending them (a requirement for them to be valid)
That is for trademarks, you have to defend them to prevent the words from taking on a meaning that refers to the class of product instead of the product itself, ie "hoover" now means the same as "vacuum cleaner" and the trademark is thus lost since they didn't sue housewives for discussing their new hoovers when really they bought a hoover from Electrolux(TM) or Dyson(TM).
> infringement is much more cut and dried for copyright.
It certainly isn't, to infringe on a patent you must simply have distributed or used something that works in the manner described in the patent - subject to first sale. For copyright infringement you must have actually *copied* something from the original. Independent authoring of similar work (common in matters of logic and mathematics as for many problems there is one or maybe a couple of calculable "right answers") is permitted in copyright law since you didn't copy it.
> A single CPU can only execute a single instruction at a time. Of course many instructions take more than one clock cycle to execute
That hasn't been true for years.
> programs are far more sequential than parallel
They certainly are not, any compiler author will tell you that. Go read up on GCCs DFA scheduler - modern CPUs are pipelined which is a simplified parallelism. There are far fewer barriers than not in most ordinary programs.
> even two CPUs won't give nearly the benefit a single twice-as-fast CPU.
Yes, See Athlon vs Pentium 4. Pentium 4 has a much longer pipeline, so it is a simplified hugely parallel design whilst Athlon has a much shorter pipeline and is thus less parallel. The Athlon is actually a few fast clocks instead of many slow clocks. Due to the pipeline simplification of parallel designs made possibly by a discrete clock (hard edges that looks approximately the same at any scale) the out of phase clocks can be combined into one signal that is mathematically equivalent to one faster clock.
I hope this explains why the regular Hz quote is the same as quoting four times the Hz of four parallel CPUs (ie, the regular Hz quote *is* several times the Hz of several processing units).
> It's akin to having four people each running 10 miles per hour. They cannot reach 40 mph that way
No its not, clock cycles are discrete, miles is continuous. It's akin to having four people each take 60 strides per minute, they *do* reach 240 strides per minute between them.
> For instance, Word doesn't have word completiom
And that's supposed to be a bad thing? OO2's word completion is utter crap. It should't insert the word when you try to enter a return instead of a letter - typing while something is selected replaces the selection... except if you type return. This is completely contrary to any GUI interface guideline I know of, and is very, very dumb.
> In other words a system with four processors running at 1.7GHz aren't going to deliver 6.8GHz of processing ability.
processing ability isn't measured in Hz (the unit of cycles per second), the rate at which a small group of transistors and capacitors will wiggle at is measured in Hz. Since modern CPUs have several clocks, the Hz for a single CPU is just as made up as that for a group of four CPUs.
6.8GHz is as real as 1.7 GHz and just as uninteresting.
When they say "clockless" I might pay attention.
> If you're trying to insert invlaid data, you're the only one to blame.
That would be fine if the database were compiled into the application and strongly type-checked by the compiler. Even small software can't be reliably checked by humans, and the database is connected to at runtime so the compiler can't really do it.
With schemas this can be done better. The compiler could know the types that the database supports and the software is compiled against the schema specification, then as you connect ot the database, the schema is checked for agreement and the compiler had assured the types (and the database author had provided classes to compile against). Then you can be *reasonably* safe, but shit can still happen (database version changes, nearly compatible competitor is substituted, etc). When that shit happens, you need to know that the database has its shovel ready. Its because of the loose connection between the application and database that the database must provide this assurance and it can't just be left to the application compiler to check everything at compile time.
> if you REALLY need the logic to reject things like blank inputs in web forms then you should be doing that in your application logic anyway....
Yes, you should often try not to submit data that the database cannot represent since it reduces the overhead, but you should also be allowed to sometimes assume that the data is correct and the database will tell you if it is unable to do what you ask. That is the premise behind exceptions, you act like its going to work, and wait until you are told that it doesn't, then the database can be tuned by extending lengths, accepting 4 dimensional GIS data, etc and the application doesn't have to be changed.
The database is responsible for the data that can be represented, and there is often a functional specification that the application should export the representational capabilities of the storage backend. That defines a functional boundary at the DB/App and exceptions on invalid data are an absolute *requirement*. There is a whole range of programmes that cannot be written if that is not there (ie those programs where the DB part is supposed to be swappable for a new version with greater domain).
For the class of applications that need some default to be substituted for invalid data, with the exceptional style the application can just wait for an exception then try the same again with the default substituted.
MySQL's biggest problem is that if you try to update or insert with invalid data, in many cases it successfully inserts wrong data. PostgreSQL doesn't do that.
PostgreSQL has this nice Object-Relational model where tables can be derived from each other, but there are some nasty bugs that mean I think those features are still best avoided.
Overall, though, I think PostgreSQL is by far the better RDBMS.
> We have a problem here with two overlapping rules: not allowing other companies to manufacture ink cartridges for your printer, and not allowing you to refill the cartridges your manufacturer sells. I don't think either should be legal,
I don't have to buy my tyres from peugeot and I can pump more air into them when they go a bit flat, I don't have to get my keys cut by yale and I can replace them instead of buying a new lock, I don't have to buy my shoe polish from Marks and Spencer, I don't have to buy my sugar from Tetley and I don't have to buy my guitar strings from Fender. Why should it be illegal for someone other than, say, lexmark to supply the cartridges for *my* printer, and why should I be prohibited from refilling them with my *own* ink that I've made or bought from elsewhere?
> Typically a ratio of less than 1% is considered "aneutronic", although I still wouldn't want to stand too close to such a reactor.
Yes, I heard that 1% is a ratio to expect. And I heard that if you were exposed to that, you would drop to the ground, dead, in 3 seconds flat.
> Personally, I'd rather not pay the price of losing Scotland in order to see the happy result of London being rendered uninhabitable.
I'm looking forward to both!
The point of anuetronic fusion is that they are *not* planning to transfer the heat to a steam turbine (who the hell wants a steam turbine - that's why current powerstations cost so much to build and maintain - and why they're so inefficient).
In a neutronic reaction such as D + T -> He + n high energy neutrons are transfer their energy to water and a steam turbine takes a little bit of that energy back out and coverts a little bit of what it takes into electricity. This is very bad for the environment as it releases huge amounts of waste heat.
In an aneutronic reaction such as p + B11 (5+) -> 3He (2+) high energy helium ions (alpha radiation) is released. This is a large current (moving charge) which can directly induce a current in a coil.
pB11 reactions don't seem to be expected to acheive ignition (ie become self sustaining), the are expected to be pulsed reactions, where a portion of their output is immediated consumed to prepare and force another reaction. All that is needed then to be a useful power source is break even.
However, p + B11 -> 3He is not the only reaction to occur, but I don't know what consequences to expect from that.
The problem with poor technology products is in product direction, that is not a job for an IT manager - that is a job for product management (a role within the programme management umbrella) in liaison with the developers. The problem with many IT related products is that they do not have a competent product manager - but an IT manager is not a product manager and a product manager is not an IT manager. If product management can specify a direction that is both practical and profitable (with advise from developers regarding whether it is practical and leaves the product in a good position for future direction changes), then developers can set priorities to follow that direction.
This middle management fad will wear off and those trained in middle management skills will become accountants and stress councellors, cost only what they're worth, and the consumer will be much better off for it.
> except he doesn't touch on whether or not he is a good MANAGER.
/. mind think, you do not have to have technical skills to be a good technical manager, you just need to know what your team knows(as in area of expected knowledge) and assign the properly.
His description suggests he doesn't know anything about IT, so...
> Can he assign resource well?
He doesn't know what it takes to perform a task. so no.
> Can he assign priorities?
Managers are not required for that. Individual developers/admins/teams can do that far more cost effectively.
> does he tell his boss when the teams work load in too much?
The team is more than capable of doing that. What do you need a manager in there for?
> If this person can do all that, then do not fire him, just relize he is there to MANAGE technical resources, not perform technical duties.
That is the most common misconception of management there is. Managers are there to make sure the "people" (note that I don't refer to them as mere resources) that do the work have the necessary tools, time and information to do what needs to be done.
Mostly that means asking those people how important things are, doing the budget calculations for them, then asking them if they concur, rinse and repeat.
>Contrary to the
No, this is how it should work. Board sets a direction, programme managers reify the direction to measurable changes in eg, product positioning, infrastructure efficiency, etc. Programme managers know who has a fair amount of familiarity with a feature to be changed and brings them from the complete pool of talent with a project manager and representatives of stakeholders within the company - they do not go through a politician firewall. Programme management bring a project mandate to this table, and the project brief and approach are defined by those at the table and anybody they seek input from. The project manager produces plans without seeking approval from programme management, but rather seeks approval from the people that will do the work - he does not tell those people how it is gonna be. There should be various bean-counters on hand for the use of the people involved in a project - the bean counters are subservient.
I respect my immediate manager a great deal. He is knowlegable but recognises that his team members have their own areas of expertise. He doesn't gloat if you make a mistake or don't know something, and he laughs a lot. I say you can't get better than that, and nor would you expect to.
Apparantly, the Kliper will run on KDE (that's why its got a silly name) and thus be more user friendly than the USA's GNU/Shuttle. The developers hope that will reduce the number of crashes, and that the more solid frontend won't break into bits and damage the wings. Whilst it will be based on a Linux(R) kernel, it will not use the name "Linux(R)" as Russia can't afford a license to use the word.
Linux(R) is a trademark of Linus Torvalds, and its use has now been restricted to those with money and editorial comment - even the non-profits and private individuals have to have money to spare.