Mail Archives: geda-user/2015/07/07/17:45:54.1
On Tue, Jul 07, 2015 at 04:28:23PM -0400, Dave McGuire (mcguire AT neurotica DOT com) [via geda-user AT delorie DOT com] wrote:
> On 07/07/2015 02:33 PM, Ivan Stankovic (pokemon AT fly DOT srk DOT fer DOT hr) [via
> Well sure...and I admit that I live squarely in the embedded world
> now; I usually don't write server code anymore, and the last time I
> wrote user-facing "app" code was 25 years ago. I'd not really have had
> occasion to bump into one of these languages. But it's not like I live
> under a rock; my professional and social groups involve programmers of
> all stripes...and yet these languages still haven't come up on my radar
> as being anything that's in actual USE anywhere.
Yes, that is understandable. That will change, albeit slowly. One
cannot change the industry, especially the very conservative embedded
industry, overnight. But changes will come, that is certain.
One good point raised elsewhere in this thread was that the C is an
ISO standard. This has both good and bad aspects, and the good ones
have already been mentioned. One of the bad ones is that, once a
language becomes an ISO standard, the language progress gets
incredibly slowed down. Just look at how long it took to get C99,
and take into account the time it took popular implementations to
support it.
Even worse example is C++, which I admit I cannot comprehend anymore.
I simply do not have the required number of brain cells to use the
latest features. They've been adding more and more complex features
on top of what already had been a complex language.
One reason those features are being added is that the software
(and firmware!) has to support much more complex devices and
interactions between them. Without major help from the language it
is very hard to produce simple, elegant, maintainable code. In
some cases it is not possible to produce *anything*, because a
language may lack a certain construct.
And one has to admit, the definition of an embedded system
has dramatically expanded to include such things as multi-core devices
with hundreds of MBs and innumerable peripherals. One can hardly
expect that the tools, that haven't changed much in the last several
decades, can be put to optimal use under such different circumstances.
> > I completely agree. Though I have to point out that it all depends
> > on the likelihood of "disappearing into obscurity". I predict that
> > not all of them will be extinct ten, or twenty years from now.
>
> 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.
It is definitely not easy. One criteria that I find useful to predict
these things is the community. The nature of it, the dynamics, the
rate at which things change, conflict resolution etc. Because, in the
end, everything depends on the community. If you have the momentum,
you will succeed. If not, well...
> >> And further (and I apologize if it sounds like I'm picking on you
> >> here), rabid proponents of dozens of "pet" programming languages have
> >> claimed them to be "as fast as C!!" for decades. I didn't believe it
> >> then, and I don't believe it now.
> >
> > You do not need to believe anyone. Measure. Evaluate. Then draw
> > conclusions.
>
> I have, with Perl, Java, and C++. C is consistently the fastest and
> has the smallest memory footprint.
... of those 4. ;-)
> When one raises the conceptual level of programming, one (usually)
> sacrifices flexibility and control, and invariably people explain it
> away with a hand-wave by saying "oh we really didn't want all of that
> flexibility and control anyway, because it made us make mistakes!"
> Everybody makes mistakes, creates buffer overruns and bad pointer
> dereferences etc...but competent developers make fewer mistakes and
> introduce fewer bugs. Lowering the barriers of entry creates more
> programmers...not better ones.
I completely agree.
> Somewhere along the line, I believe in the early 1970s, some idiot
> proclaimed that "programmer time is more precious than processor time".
> This created an excuse for programmer laziness that still affects us to
> this day, giving us such "progress" as operating systems that require
> gigabytes of RAM and several minutes at billions of clock cycles per
> second just to boot. Every time Firefox slows to a crawl or Xilinx ISE
> takes forever to start up, I'm reminded of this.
Ah, Xilinx ISE.... that precious gem of software. Really, one has to
admire the sheer amount of effort that must have been poured into it,
with such results.
> When it takes a minute and a half to open a new web browser window on
> a machine with six 3.2GHz cores, 48MB of cache, 24MB of main memory, and
> fast disks, I very quickly decide that processor time is a whole lot
> more precious than programmer time.
>
> Let's not push gEDA down a path to that same frustration just because
> the language most of it is written in actually requires some skills and
> thought.
Let me assure you: gEDA isn't going anywhere. Literally. :-)
--
Ivan Stankovic, pokemon AT fly DOT srk DOT fer DOT hr
"Protect your digital freedom and privacy, eliminate DRM,
learn more at http://www.defectivebydesign.org/what_is_drm"
- Raw text -