Ask a question - edaboard.com
elektroda.net NewsGroups Forum Index - Verilog Language - I'd rather switch than fight!
Goto page Previous 1, 2, 3, 4 ... 9, 10, 11 Next
Patrick Maupin
Guest
Guest
Fri Apr 16, 2010 1:30 am
On Apr 15, 4:58 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
Quote:
Of course, there's also a ton of stuff that Verilog can do
but VHDL can't. And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies.
but VHDL can't. And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies.
Agreed completely.
Quote:
But it is NEVER a good idea to trivialize the discussion.
Well, you have to talk to others about that. Somebody else brought up
the stupid Verilog contest, and David, apparently agreeing with some
sentiment there, said:
Quote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
To which the only sane answer was my flippant "it's not the
same" (and, of course the very first thing that's not the same is who
the purported winner was). I don't think either contest is worth a
hoot, but I do find it interesting that you found it necessary to pen
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.
Regards,
Pat
David Brown
Guest
Guest
Fri Apr 16, 2010 10:15 am
On 15/04/2010 23:31, Muzaffer Kal wrote:
Quote:
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
The contest in question was a substantial programming project over a
longer period - weeks rather than hours. I don't remember how much time
was actually spend on debugging rather than coding, but it certainly
worked out that the Ada team were finished long before the C team.
David Brown
Guest
Guest
Fri Apr 16, 2010 10:31 am
On 16/04/2010 00:30, Patrick Maupin wrote:
Quote:
On Apr 15, 4:58 pm, Jonathan Bromley<s...@oxfordbromley.plus.com
wrote:
Of course, there's also a ton of stuff that Verilog can do
but VHDL can't. And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies.
Agreed completely.
But it is NEVER a good idea to trivialize the discussion.
Well, you have to talk to others about that. Somebody else brought up
the stupid Verilog contest, and David, apparently agreeing with some
sentiment there, said:
wrote:
Of course, there's also a ton of stuff that Verilog can do
but VHDL can't. And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies.
Agreed completely.
But it is NEVER a good idea to trivialize the discussion.
Well, you have to talk to others about that. Somebody else brought up
the stupid Verilog contest, and David, apparently agreeing with some
sentiment there, said:
I wasn't agreeing with the validity of the Verilog/VHDL contest,
although I suppose by not saying that, it looked like I agreed with it.
It would have been more useful if I'd given a little more detail. The
Ada / C contest was over a much longer time scale, using a real-world
project - and thus is a much more valid contest (though obviously, like
any test or benchmark, you can't apply it thoughtlessly to other contexts).
It was an indication of where the stronger typing and generally stricter
compiler and language was demonstrated to give a faster development time
in a real case. I can't say whether those results could carry over to a
comparison between VHDL and Verilog, or how much the results are the
effect of strong typing. But since VHDL is often though of as being a
similar style of language to Ada, and Verilog is similarly compared to
C, it may be of interest.
I couldn't find references to the study I was thinking of, but I found
one in a similar vain:
<http://www.adaic.org/whyada/ada-vs-c/cada_art.html#conclusion>
Of course, I haven't scoured the net looking for enough articles to give
a balanced view here. So if my comments here are of interest or use to
anyone, that's great - if not, I'll not complain if you ignore them!
Quote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
To which the only sane answer was my flippant "it's not the
same" (and, of course the very first thing that's not the same is who
the purported winner was). I don't think either contest is worth a
hoot, but I do find it interesting that you found it necessary to pen
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.
Regards,
Pat
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
To which the only sane answer was my flippant "it's not the
same" (and, of course the very first thing that's not the same is who
the purported winner was). I don't think either contest is worth a
hoot, but I do find it interesting that you found it necessary to pen
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.
Regards,
Pat
David Brown
Guest
Guest
Fri Apr 16, 2010 10:38 am
On 15/04/2010 23:27, Patrick Maupin wrote:
Quote:
On Apr 15, 2:23 pm, Andy<jonesa...@comcast.net> wrote:
The benefits of a "strongly typed" language, with bounds checks, etc.
are somewhat different between the first time you write/use the code,
and the Nth time reuse and revise it. Strong typeing and bounds
checking let you know quickly the possibly hidden side effects of
making changes in the code, especially when it may have been a few
days/weeks/months since the last time you worked with it.
For this usage, a good testbench will catch more bugs and make strong
type and bounds checking redundant.
The benefits of a "strongly typed" language, with bounds checks, etc.
are somewhat different between the first time you write/use the code,
and the Nth time reuse and revise it. Strong typeing and bounds
checking let you know quickly the possibly hidden side effects of
making changes in the code, especially when it may have been a few
days/weeks/months since the last time you worked with it.
For this usage, a good testbench will catch more bugs and make strong
type and bounds checking redundant.
A testbench does not make checks redundant, for two reasons. First, the
earlier in the process that you find the mistakes, the better - its
easier to find the cause of the mistake, and it's faster to find them,
fix them, and re-compile.
Secondly, a testbench does not check everything. It is only as good as
the work put into it, and can be flawed in the same way as the code
itself. A testbench's scope for non-trivial projects is always limited
- it is not practical to test everything. If you have some code that
has a counter, your testbench may not go through the entire range of the
counter - perhaps doing so would take simulation times of years. Your
testbench will then not do bounds checking on the counter.
The old joke about Ada is that when you get your code to compile, it's
ready to ship. I certainly wouldn't go that far, but testing is
something you do in cooperation with static checking, not as an alternative.
mvh.,
David
Jonathan Bromley
Guest
Guest
Fri Apr 16, 2010 10:47 am
On Apr 15, 11:30 pm, Patrick Maupin <pmau...@gmail.com> wrote:
Quote:
I do find it interesting that you found it necessary to pen
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.
I try to write on things I know something about :-)
I am painfully familiar with the Cooley Verilog-vs-VHDL nonsense,
but know nothing about that C-Ada contest.
In any case, I wasn't particularly responding to you. I took an
opportunity to say something I've wanted to say for a long time
about an exceedingly faulty part of the HDL mythology.
--
Jonathan Bromley
Symon
Guest
Guest
Fri Apr 16, 2010 11:30 am
On 4/15/2010 3:33 PM, Patrick Maupin wrote:
Quote:
On Apr 15, 12:20 am, Matthew Hicks<mdhic...@uiuc.edu> wrote:
In comp.arch.fpga rickman<gnu...@gmail.com> wrote: (snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
It does seem likely that people will let down their guard and code
more sloppily knowing that the compiler will catch errors.
One of my least favorite is the Java check on variable initialization.
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
Sorry, but I have to call BS on this whole line og "logic". Unless you can
point to some studies that prove this, my experiences are contrary to your
assertions. I don't change the way I code when I code in Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my stupid
mistakes, allowing me to get things done faster.
---Matthew Hicks
Pat,
In comp.arch.fpga rickman<gnu...@gmail.com> wrote: (snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
It does seem likely that people will let down their guard and code
more sloppily knowing that the compiler will catch errors.
One of my least favorite is the Java check on variable initialization.
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
Sorry, but I have to call BS on this whole line og "logic". Unless you can
point to some studies that prove this, my experiences are contrary to your
assertions. I don't change the way I code when I code in Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my stupid
mistakes, allowing me to get things done faster.
---Matthew Hicks
Pat,
If your email client was less agile and performed better 'typing
checking' you wouldn't have sent this blank post.
HTH, Syms.
Brian Drummond
Guest
Guest
Fri Apr 16, 2010 12:22 pm
On Fri, 16 Apr 2010 11:15:35 +0200, David Brown
<david_at_westcontrol.removethisbit.com> wrote:
Quote:
On 15/04/2010 23:31, Muzaffer Kal wrote:
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
The contest in question was a substantial programming project over a
longer period - weeks rather than hours. I don't remember how much time
was actually spend on debugging rather than coding, but it certainly
worked out that the Ada team were finished long before the C team.
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
The contest in question was a substantial programming project over a
longer period - weeks rather than hours. I don't remember how much time
was actually spend on debugging rather than coding, but it certainly
worked out that the Ada team were finished long before the C team.
Was it John McCormick's model railroad?
http://www.adaic.org/atwork/trains.html
Possibly not - the C students apparently never did deliver.
- Brian
David Brown
Guest
Guest
Fri Apr 16, 2010 12:30 pm
On 16/04/2010 13:22, Brian Drummond wrote:
Quote:
On Fri, 16 Apr 2010 11:15:35 +0200, David Brown
david_at_westcontrol.removethisbit.com> wrote:
On 15/04/2010 23:31, Muzaffer Kal wrote:
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
The contest in question was a substantial programming project over a
longer period - weeks rather than hours. I don't remember how much time
was actually spend on debugging rather than coding, but it certainly
worked out that the Ada team were finished long before the C team.
Was it John McCormick's model railroad?
http://www.adaic.org/atwork/trains.html
Possibly not - the C students apparently never did deliver.
david_at_westcontrol.removethisbit.com> wrote:
On 15/04/2010 23:31, Muzaffer Kal wrote:
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
pmaupin_at_gmail.com> wrote:
On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com
wrote:
Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.
Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.
There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
The contest in question was a substantial programming project over a
longer period - weeks rather than hours. I don't remember how much time
was actually spend on debugging rather than coding, but it certainly
worked out that the Ada team were finished long before the C team.
Was it John McCormick's model railroad?
http://www.adaic.org/atwork/trains.html
Possibly not - the C students apparently never did deliver.
I suppose there have been many such studies through the ages. The one I
remember was a real project rather than a student project (I think it
was a large commercial company, but it may have been some sort of
government organisation).
whygee
Guest
Guest
Fri Apr 16, 2010 6:53 pm
rickman wrote:
Quote:
Hmmm... The date on that article is 04/07/2003 11:28 AM EDT. Seven
years later I still don't see any sign that VHDL is going away... or
did I miss something?
years later I still don't see any sign that VHDL is going away... or
did I miss something?
I had the same thought.
Furthermore it was about only one company who wanted to push one
technology. Bold statements followed, and... 7 years later,
VHDL and Verilog are still the Vi vs Emacs of EDA.
Quote:
Rick
yg
yg
--
http://ygdes.com / http://yasep.org
Bernd Paysan
Guest
Guest
Fri Apr 16, 2010 7:24 pm
rickman wrote:
Quote:
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete.
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete.
My practical experience is that strong typing creates another class of bugs,
simply by making things more complicated. I've last seen VHDL in use more
than 10 years ago, but the typical pattern was that a designer wanted a bit
vector, and created a subranged integer instead. Seems to be identical, but
isn't. If you increment the subranged integer, it will stop simulation on
overflow, if you increment the bit vector, it will wrap around. My coworker
who did this subranged integer stuff quite a lot ended up with code like
if foo = 15 then foo <= 0 else foo <= foo + 1 endif;
And certainly, all those lines had started out as
foo <= foo + 1;
and were only "fixed" later when the simulation crashed.
The good news is that the synthesis tool really generates the bitvector
logic for both, so all those simulator crashes were only false alarms.
--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/
Bernd Paysan
Guest
Guest
Fri Apr 16, 2010 7:56 pm
Andy wrote:
Quote:
IMHO, they missed the point. Any design that can be completed in a
couple of hours will necessarily favor the language with the least
overhead. Unfortunately, two-hour-solvable designs are not
representative of real life designs, and neither was the contest's
declared winner.
couple of hours will necessarily favor the language with the least
overhead. Unfortunately, two-hour-solvable designs are not
representative of real life designs, and neither was the contest's
declared winner.
Well, we pretty much know that the number of errors people make in
programming languages basically depends on how much code they have to write
- a language which has less overhead and is more terse is being written
faster and has less bugs. And it goes non-linear, i.e. a program with 10k
lines of code will have less bugs per 1000 lines than a program with 100k
lines of code. So the larger the project, the better the more terse
language is.
--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/
Patrick Maupin
Guest
Guest
Fri Apr 16, 2010 8:50 pm
On Apr 16, 5:30 am, Symon <symon_bre...@hotmail.com> wrote:
Quote:
Pat,
If your email client was less agile and performed better 'typing
checking' you wouldn't have sent this blank post.
HTH, Syms.
If your email client was less agile and performed better 'typing
checking' you wouldn't have sent this blank post.
HTH, Syms.
Absolutely true!
But it keeps me young trying to keep up with it.
Pat
rickman
Guest
Guest
Fri Apr 16, 2010 8:56 pm
On Apr 14, 10:07 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
Quote:
In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
(snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
(snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
Are you making this up? I have never heard that any of the other
added safety features don't save lives overall. I have heard that
driving a sportier car does allow you to drive more aggressively, but
this is likely not actually the result of any real analysis, but just
an urban myth. Where did you hear that air bags don't save lives
after considering all?
Quote:
It does seem likely that people will let down their guard and
code more sloppily knowing that the compiler will catch errors.
code more sloppily knowing that the compiler will catch errors.
If you can show me something that shows this, fine, but otherwise this
is just speculation.
Quote:
One of my least favorite is the Java check on variable initialization.
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
I saw a warning the other day that my VHDL signal initialization "is
not synthesizable". I checked and it was appropriately initialized on
async reset, it was just complaining that I also used an
initialization in the declaration to keep the simulator from giving me
warnings in library functions. You just can't please everyone!
Then again I had to make a second trip to the customer yesterday
because of an output that got disconnected in a change and I didn't
see the warning in the ocean of warnings and notes that the tools
generate. Then I spent half an hour going through all of it in detail
and found a second disconnected signal. Reminds me of the moon
landing where there was a warning about a loss of sync which kept
happening so much it overloaded the guidance computer and they had to
land manually. TMI!
Rick
rickman
Guest
Guest
Fri Apr 16, 2010 8:58 pm
On Apr 15, 10:37 am, Patrick Maupin <pmau...@gmail.com> wrote:
Quote:
On Apr 15, 12:20 am, Matthew Hicks <mdhic...@uiuc.edu> wrote:
In comp.arch.fpga rickman <gnu...@gmail.com> wrote: (snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
It does seem likely that people will let down their guard and code
more sloppily knowing that the compiler will catch errors.
One of my least favorite is the Java check on variable initialization..
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
Sorry, but I have to call BS on this whole line og "logic". Unless you can
point to some studies that prove this, my experiences are contrary to your
assertions. I don't change the way I code when I code in Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my stupid
mistakes, allowing me to get things done faster.
You can "call BS" all you want, but the fact that you don't change the
way you code in Verilog vs. VHDL or or C vs. Java indicates that your
experiences are antithetical to mine, so I have to discard your
datapoint.
Regards,
Pat
In comp.arch.fpga rickman <gnu...@gmail.com> wrote: (snip)
People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?
Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.
It does seem likely that people will let down their guard and code
more sloppily knowing that the compiler will catch errors.
One of my least favorite is the Java check on variable initialization..
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.
Sorry, but I have to call BS on this whole line og "logic". Unless you can
point to some studies that prove this, my experiences are contrary to your
assertions. I don't change the way I code when I code in Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my stupid
mistakes, allowing me to get things done faster.
You can "call BS" all you want, but the fact that you don't change the
way you code in Verilog vs. VHDL or or C vs. Java indicates that your
experiences are antithetical to mine, so I have to discard your
datapoint.
Regards,
Pat
That is certainly a great way to prove a theory. Toss out every data
point that disagrees with your theory!
Rick
rickman
Guest
Guest
Fri Apr 16, 2010 9:05 pm
On Apr 15, 3:23 pm, Andy <jonesa...@comcast.net> wrote:
Quote:
The benefits of a "strongly typed" language, with bounds checks, etc.
are somewhat different between the first time you write/use the code,
and the Nth time reuse and revise it. Strong typeing and bounds
checking let you know quickly the possibly hidden side effects of
making changes in the code, especially when it may have been a few
days/weeks/months since the last time you worked with it.
A long time ago there was a famous contest for designing a simple
circuit in verilog vs. vhdl to see which language was better. The
requirements were provided on paper, and the contestents were given an
hour or two (don't remember how long, but it was certainly not even a
day), and whoever got the fastest and the smallest (two winners)
correct synthesized circuit, their chosen language won. Verilog won
both, and I don't think vhdl even finished.
are somewhat different between the first time you write/use the code,
and the Nth time reuse and revise it. Strong typeing and bounds
checking let you know quickly the possibly hidden side effects of
making changes in the code, especially when it may have been a few
days/weeks/months since the last time you worked with it.
A long time ago there was a famous contest for designing a simple
circuit in verilog vs. vhdl to see which language was better. The
requirements were provided on paper, and the contestents were given an
hour or two (don't remember how long, but it was certainly not even a
day), and whoever got the fastest and the smallest (two winners)
correct synthesized circuit, their chosen language won. Verilog won
both, and I don't think vhdl even finished.
Maybe this was repeated, but the first time they tried this *NO ONE*
finished in time which is likely much more realistic compared to real
assignments in the real world. If you think it will take a couple of
hours, allocate a couple of days!
Rick
elektroda.net NewsGroups Forum Index - Verilog Language - I'd rather switch than fight!
