X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Message-ID:	<1436305751.678.145.camel@ssalewski.de>
Subject:	Re: [geda-user] gEDA/gschem still alive?
From:	Stefan Salewski <mail AT ssalewski DOT de>
To:	geda-user AT delorie DOT com
Date:	Tue, 07 Jul 2015 23:49:11 +0200
In-Reply-To:	<559C3667.7030402@neurotica.com>
References:	<20150703030409 DOT 32398 DOT qmail AT stuge DOT se>
	<CAFC5WMoa2-z6bNca_bQN+jmMR260UBmoJQybUzH=L2TrBpzNNA AT mail DOT gmail DOT com>
	<1436006726 DOT 677 DOT 13 DOT camel AT ssalewski DOT de>
	<20150706200609 DOT GD24178 AT localhost DOT localdomain>
	<CAC4O8c9f0pLsLu_dyuO5ggh7RmHY1vAA=UUhk9AE0JYZb4mhBQ AT mail DOT gmail DOT com>
	<CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com>
	<20150707060409 DOT GB14357 AT localhost DOT localdomain>
	<CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com>
	<1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de> <559C0F7E DOT 7010009 AT neurotica DOT com>
	<20150707183339 DOT GA1817 AT alpha2> <559C3667 DOT 7030402 AT neurotica DOT com>
X-Mailer:	Evolution 3.12.11
Mime-Version:	1.0
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 2015-07-07 at 16:28 -0400, Dave McGuire (mcguire AT neurotica DOT com)
[via geda-user AT delorie DOT com] wrote:
>   One can hope, but one never knows.  But how does one decide which
> one
> to "get behind"?  If you choose the wrong one, all the code you've
> written in it effectively becomes obsolete very quickly.  It's not an
> easy problem to solve.

Porting clean DRY code is not that hard. The mentioned modern languages
are some sort of similar. That makes learning them easier, and porting
too. Even porting clean C code to modern languages is generally easy,
because C is generally a subset of modern languages. (There are
exceptions, my feeling is that Crystal and Julia do not support things
like bit operations very well.) The problem is all the garbage code. If
I remember correctly, KiCad has one million lines of C++ code. Why that
large? I guess all the kids have always added without much thinking,
being proud: I have 1000 lines of code in KiCad?

For porting my 6k lines of Ruby Peted code to Nim I am still unsure how
long it may take, 400+-100 hours is my current guess. Porting Python is
more easy.

> 
>   I have, with Perl, Java, and C++.  C is consistently the fastest and
> has the smallest memory footprint.
> 
>   People often seem to forget the fact that programming in
> higher-level
> languages usually involves importing huge blocks of code as binary
> blobs
> over which they have no control, either of what's included and what's
> omitted, or what's executed and what isn't.

Memory footprint is important indeed. For Nim it is very low, similar to
C. I think for Rust too. For Crystal I am not sure, for Go large
executable size is indeed a known problem.

With the bloob: Yes, buggy bytecode interpreters can be a problem. That
is for Ruby, with Ruby 2.2 I have some random GC related crashes
currently. But for the other languages there are no blobs.

C++ and Rust suffer from long compiling time unfortunately. Here Nim and
Crystal are much better. I think the Nim compiler has 100k lines of code
only, and compiles itself in a few seconds!

- Raw text -