[snip]
However, as a person who is fluent in both Forth and Haskell, I have
to cast my vote for OCaml or Haskell. Forth is a VERY capable
[snip]
There is no poll or election here. Silly me, I had no idea
my little post would spawn yet another My language is better than
yours thread.
On Thu, 2007-08-30 at 01:09 -0400, Dave McGuire wrote:
On Aug 30, 2007, at 1:01 AM, Erik de Castro Lopo wrote:
Early code in a predecessor to gnucap was written ratfor, later
converted to C, still later converted to C++. I made the
transition to C at the best time. I waited too long to
On Thu, 2007-08-30 at 02:58 +, Ales Hvezda wrote:
Hi,
I was referer log surfing and came across these links:
www.fritzing.org
and more specifically:
www.fritzing.org/development/market-overview
Here's what this group is apparently planning (wrt KiCad):
Yeah, I have also written a ton of C++ code over the last decade or
so. g++ is a fine compiler now, but back then (in '97) it was far
from perfect.
I started with cfront 1.0, long before g++ came out. Even then, C++
was a reasonable language choice. This was, oh, 1990-ish. 17 years
ago.
It sounds to me like you are one of the six or seven competent C++
programmers in the world.
The guy that taught me C++ claimed that I was the only one he'd trust
with a C++ compiler. Besides himself, of course.
___
geda-user mailing list
On 8/30/07, Ales Hvezda [EMAIL PROTECTED] wrote:
There is no poll or election here. Silly me, I had no idea
Nobody said there was. But if you're going to undermine any and every
hypothetical discussion on the list, it's a miracle there's any
discussion at all.
Not trying to be rude or
On Thu, Aug 30, 2007 at 11:13:42AM -0400, DJ Delorie wrote:
At this point, there's no technical reason to avoid C++, but if one
chooses to migrate,
... I'd say start by redesigning the data structures! PCB could be so
much more OO even without C++. A lot of the code would be about 1/20th
... I'd say start by redesigning the data structures! PCB could be
so much more OO even without C++. A lot of the code would be
about 1/20th the size if you could just do things like
foo-Move(dx,dy) without having to worry about the type of foo.
You're not the first to think of that ;-)
On Aug 30, 2007, at 1:01 PM, Ben Jackson wrote:
At this point, there's no technical reason to avoid C++, but if one
chooses to migrate,
... I'd say start by redesigning the data structures! PCB could be so
much more OO even without C++. A lot of the code would be about
1/20th
the size
On Thu, 2007-08-30 at 13:10 -0400, DJ Delorie wrote:
... I'd say start by redesigning the data structures! PCB could be
so much more OO even without C++. A lot of the code would be
about 1/20th the size if you could just do things like
foo-Move(dx,dy) without having to worry about the
On 8/30/07, Dave McGuire [EMAIL PROTECTED] wrote:
they've given great benefits, without the bloat and glacial slowness
that is typical of so many packages written in C++.
As much as I dislike C++, I have to defend it here: it is actually not
glacially slow. It may be slower to compile,
On Thu, Aug 30, 2007 at 06:19:14PM +0100, Peter Clifton wrote:
I'm not sure what the performance hit might be in removing it, and using
a test on the object's type.
You've basically hit on the two techniques that have been used extensively
in UNIX kernels:
struct foo_operations {
int
Sent from my iPhone
On Aug 30, 2007, at 10:19 AM, Peter Clifton [EMAIL PROTECTED] wrote:
On Thu, 2007-08-30 at 13:10 -0400, DJ Delorie wrote:
... I'd say start by redesigning the data structures! PCB could be
so much more OO even without C++. A lot of the code would be
about 1/20th the
I'm not sure what the performance hit might be in removing it, and
using a test on the object's type.
From a gcc developer's point of view...
A C++ method call off a pointer is two loads and an indirect call.
Three opcodes.
The type way is a load, compare, perhaps a switch statement (which
You take a big hit for the compare/switch because it always checks
for out-of-bounds cases, so you end up with a lot of compares and
jumps, which are bad for performance.
What if the code guarantees type is correct, so we don't need to
compare before indexing the vfunc array?
The only
It is interesting to me how this discussion centres around programming
languages rather than exploring and extolling the benefits of gEDA.
I'm relatively new to using gEDA and this is the first time I've heard
of KiCad - what I'm most interested in is which is a better tool to
achieve what I want
On Aug 30, 2007, at 1:23 PM, Samuel A. Falvo II wrote:
they've given great benefits, without the bloat and glacial slowness
that is typical of so many packages written in C++.
As much as I dislike C++, I have to defend it here: it is actually not
glacially slow.
Our experiences have been
On Thu, 2007-08-30 at 14:03 -0400, DJ Delorie wrote:
C, not C++. Go read the pcb code; it has tables and switch statements
all over the place that check the object type.
If you're using vtables anyway, you might as well put a pointer to the
vtable in the structure and skip all the type
Nobody said there was. But if you're going to undermine any and every
Okay, so what is with this statement:
... I have to cast my vote for OCaml or Haskel ...
seems like you are trying to vote for something? Again this
thread is about the fritzing project, not about language
Ales Hvezda wrote:
Nobody said there was. But if you're going to undermine any and every
Okay, so what is with this statement:
... I have to cast my vote for OCaml or Haskel ...
Jeez, my original mention of Ocaml and Haskell was enclosed in
troll tags :-). It was meant to show
Guys -
On Thu, Aug 30, 2007 at 04:24:43PM -0700, Samuel A. Falvo II wrote:
On 8/30/07, Ales Hvezda [EMAIL PROTECTED] wrote:
This list is *not* about hypothetical discussions. As far as
Then, I would like to suggest that you clamp down on EVERYONE who even
dares ask a what-if or
Ales Hvezda [EMAIL PROTECTED] wrote:
However, if you are going to write an free software EDA tool in
any language (of your choice), then by all means, discuss here to your
heart's content
Really? Does this mean that discussion of uEDA and uschem would be
on-topic here?
At least the uEDA
Ales Hvezda wrote:
Nobody said there was. But if you're going to undermine any and every
Okay, so what is with this statement:
... I have to cast my vote for OCaml or Haskel ...
seems like you are trying to vote for something? Again this
thread is about the fritzing
On 8/30/07, Dan McMahill [EMAIL PROTECTED] wrote:
and my typical question.. are those really well supported on a wide
variety of operating systems on a wide variety of hardware platforms?
From a purely pragmatic point of view, I agree that this is a valid
and important question. The
Hi,
I was referer log surfing and came across these links:
www.fritzing.org
and more specifically:
www.fritzing.org/development/market-overview
Here's what this group is apparently planning (wrt KiCad):
tech.groups.yahoo.com/group/kicad-devel/message/482
In some of the threads there are some
quote 1
gEDA is a suite of several tools (some of them independent)
around EDA tasks. It has quite a long history and is
extensively developed. The GUI however is quite cumbersome and
outdated.
quote 2
KiCad is also a suite of tools, but more tightly integrated.
It's much
quote
If I remember it is written in C, and I think so out
of religious grounds. Being religiously opposed to C++ is
silly at this point. Being religiously opposed to the use of
the more exotic parts of C++ might make sense.
On Wednesday 29 August 2007, Ales Hvezda wrote:
Not
al davis wrote:
Early code in a predecessor to gnucap was written ratfor, later
converted to C, still later converted to C++. I made the
transition to C at the best time. I waited too long to make
the transition to C++.
troll
May I humbly make a suggestion that you forget about C++
On 8/29/07, Dave McGuire [EMAIL PROTECTED] wrote:
FORTH FORTH FORTH!!
Forth lacks a consistent library mechanism, and for that matter,
consistency across implementations. ANSI Forth compilers addressed
the latter issue, but GForth is still *the* Forth environment to use
if you want full ANSI
29 matches
Mail list logo
